请问大家做原生开发时，自己写的java代码通常放在哪里？

Creator 3.x
#1

以前我用android studio开发非游戏类app时，一些工具类的方法通常都放在一些自己定义的目录下的文件里，比如自己建个util目录，然后里面是各种工具类的java文件。

现在想用cocos creator的反射机制来调用自己编写的工具类java文件，不知道大家通常都把这些java文件放在什么目录下？我看网上有人干脆就直接在jsb-link\frameworks\runtime-src\proj.android-studio\app\src\org\cocos2dx\javascript\AppActivity.java 这个文件里写各种方法，比如自己写个getNetworkInfo的静态方法，直接放在AppActivity.java 里面。

上述方法倒不是不行（而且也省事），因为是静态方法，放哪里都可以对吧，但总觉得放在AppActivity.java 里面是不是不太规范啊，毕竟，直觉上AppActivity.java 里面应该放和Activity界面相关的处理。

所以，想请教大家一般都把自己写的java文件放在哪里？是自己重新定义个包名，然后再在包里面放各种自己写的java文件吗？

本人的一贯思想就是随大流，特别在cocos creator 开发方面，本人就是个小学生，所以跟着主流走肯定安全稳妥。如果大家都在AppActivity.java直接写，那我也这么干了。

请各位老师多指教，也希望官方老师给些建议，谢谢！

#2

1：自己定义一个包，里面写自己工程常用的函数，这样可以在别的工程可以复制过来直接使用（这个是比较常用的方式）。

2：自己写一个单独的Android工程导出Jar，接入到自己项目里面使用（这种方式比接入SDK简单好用）。

不太建议在AppActivity类里面写太多的东西

#3

嗯嗯，感觉您说的很对。那自己定义包的话，也是放在jsb-link\frameworks\runtime-src\proj.android-studio\app\src\ 这底下吧？就是说放在和官方那个org\cocos2dx\javascript包相同层次的位置吧？主要是没经验，搞不清cocos creator的机制，怕放错位置，然后cocos creator重新构建时代码都被清除了。。。

#4

在AppActivity.java 直接写静态方法的，99%的是因为担心写在其他地方会导致出错，或者不愿意花时间研究自定义的文件位置，越老手越是这样，不是研究不明白，而是几个规范变量名和分割线就能区分的事，没必要去研究。
为了规范而规范，属于低效率行为，谨代表个人观点。

#5

嗯，您说的有道理。我前面也说了，我随大流，并不强求一定要规范。

我是DOS年代的老年程序员了，做了很多金融之类的严谨项目，导致有吹毛求疵的强迫症（就是变量名起得有点瑕疵都睡不着觉）。

但现在已经无心特别研究技术了，也觉得应该改变强迫症了（特别是游戏这东西，没必要特别较真）。所以我需要的就是基本框架和主流吻合就行了。

另外，我刚才还在想呢，其实AppActivity.java 直接写静态方法也有好处，起码拿context挺方便（或者说需要拿context的时候，好像也只能写在AppActivity.java里面了），不知道我这理解对不对。唉，自己的技术是越来越落伍了，手机的开发经验也少，有时候也懒得琢磨，有做伸手党的倾向了。。。

反正现在觉得好像有点没辙，我要获取android id，即使我单写个工具类，终归是需要context这个参数的，所以感觉最终还是要在AppActivity.java里写个静态方法，把context传给那个工具类里面的方法。因此，感觉好像逃脱不掉在AppActivity.java里写静态方法了。

要么就是再建个MyApplication类（里面弄个静态getInstance）继承于Application，然后在工具类里面直接MyApplication.getInstance()来获取context感觉好像也行得通。

android studio开发也是以前做了一阵，半吊子水平，而且也忘的差不多了。请各位老师指点吧，谢谢！

#6

专门搞一个工具类，用来拿context，context从application里set进去。

#7

感谢回复，我的理解就是建个MyApplication类（里面弄个静态getInstance）继承于Application，然后在需要用context的任何工具类的方法里先调用MyApplication.getInstance()来获取context就应该可以了吧？

#8

我是准备这么搞了，感觉相对比较省事，比如获取网络信息（getNetworkInfo）的时候：
js里反射调用这样写
jsb.reflection.callStaticMethod(“org/cocos2dx/javascript/AppActivity”, “getNetworkInfo”, “()Ljava / lang / String;”);

因为js里的反射调用没法传context参数对吧，所以，就在AppActivity.java里定义一个没有任何参数的静态方法getNetworkInfo来作为入口，在这个getNetworkInfo里面自己先拿一下当前的context，然后传给工具类（MyUtil）里面同名的带context参数的getNetworkInfo方法来实现具体细节。

大概意思就是说js里的反射调用是要调AppActivity里面的静态方法getNetworkInfo，这是个入口，里面第一步就是单纯的先获取context，第二步再调用具体工具类里面的同名方法（getNetworkInfo）来具体实现细节。这样呢，AppActivity里面的代码量不会太多（因为只是单纯的入口，代码量就是上述的第一步和第二步两行代码而已，因为上面有老师说AppActivity的代码量太多了不好，我觉得也确实是，所以就只是在AppActivity里面写各种作为入口的静态方法了）

到目前为止还没具体写代码,现在说的这些都是脑子里想的伪代码，各位老师觉得这种流程行吗？说到底，死抠这些地方的流程就是以后发布原生的时候就可能都按这个流程走了，怕自己脑子想歪了，那以后的所有游戏可能就都歪了，所以才反复确认。请多多指教，谢谢！

package org.cocos2dx.javascript;

import org.cocos2dx.lib.Cocos2dxActivity;
import android.content.Context;
import org.cocos2dx.javascript.MyUtil;//这是个自己定义的工具类，里面实现各种细节

public class AppActivity extends Cocos2dxActivity {
	private static Context mContext;

    。。。

   //这里只是个入口，因为js调用的时候，没法传递context参数对吧
	public static String getNetworkInfo(){
	    mContext = AppActivity.getContext();//先拿自己的context（第一步）
	    return MyUtil.getNetworkInfo(mContext);//具体细节放在工具类里实现（第二步）
	}
}
#9

一切以实用为主
写 js/ts 代码的时候，不会把所有东西都写在一个类里面吧，也就刚开始学习的人会这么干吧。

#10

感谢回复，嗯，建个MyApplication类（里面弄个静态getInstance）继承于Application，然后在需要用context的任何工具类的方法里先调用MyApplication.getInstance()来获取context，这样就能不往AppActivity里面写静态方法了。js反射调用直接调用工具类，感觉这样最规范。

但是，想想呢，毕竟游戏主要的处理都在js里实现了，需要写的原生代码不是很多，未必百分百像纯原生开发那样规范。所以就最终决定把需要js反射调用的静态方法都写在AppActivity里面了，但就像我上面说的，AppActivity里面的静态方法仅仅是调取自己工具类的入口，具体的实现细节还是在工具类里面。

这样，算是中庸之道吧，AppActivity里面有点入口代码（接受了您的这里代码别太多的建议），但主要实现还是封装在工具类里面了。

主要是我的需要js反射调用的方法都依赖context，放在AppActivity确实省事。不然，我是万万不愿意往AppActivity里写的。另外就是我现在为了获取android id，用的这个context可以是来自于Application,确实可以不往AppActivity里写，但没准以后什么地方用的context就必须是Activity的，那时还是要往AppActivity里写。所以为了代码统一，干脆就统统放AppActivity里面了。

#11

思路没问题，就是把Java的代码全放在AppActivity里，后面会很难受。个人感觉，需要用到context的地方，就用全局的application context就行，不一定要用AppActivity的context，我是直接写了个一个工具类来做这些事情。

还有就是我还是建议涉及到js调用Java接口的，单独放在一个bridge层里来向js层提供服务。

#12

我是像我上面说的那样，AppActivity里面只是作为入口（或者叫桥梁也行），放一个没有参数的静态方法的。这个静态方法里其实就两行代码，第一行是获取context，第二行是调取工具类里面的同名静态方法（参数是在第一行获取的context）来实现具体细节。所以，即使有很多这样的入口静态方法，AppActivity里面的程序量也不会太大（因为具体实现细节的代码都被封装在工具类里面了）。

另外，application的context和AppActivity的context还是有区别的，基本上AppActivity的context可以替代application的context用（比如我这次为了获取android id，所以用哪个context都行），但反过来，application的context是无法在任何场合都替代AppActivity的context的（比如要在窗口弹框时，就必须用AppActivity的context）。我很久没搞开发了，但我记得应该是这么个概念。