cocos android分析
浏览数：26 /
时间：2015年06月11日
cocos2d-x Android环境搭建
cocos2d-x环境搭建比较简单，但是小问题还是不少，我尽量都涵盖的全面一些。
下载软件
cygwin、NDK(ADT):C++相关
如果之前没有Android开发环境，还需要Android SDK，Eclipse
cocos2d-x源码
我的环境为ndk r7，cygwin1.7，Android SDK为2.2和3.0.另外,我是通过真机调试,在模拟器上不行,估计还是我T410显卡的问题.
安装cygwin，在cygwin文件进行路径设置
在cygwin\home\Administrator的.bash_profile中添加如下代码
1: ANDROID_NDK_ROOT=/cygdrive/e/ADT/android-ndk-r7c
2: export ANDROID_NDK_ROOT
3: NDK_ROOT=/cygdrive/e/ADT/android-ndk-r7c
4: export NDK_ROOT
将libgnustl_static.a从NDK中的android-ndk-r7c\sources\cxx-stl\gnu-libstdc++\libs\armeabi拷贝至cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android\obj\local\armeabi，这个从解决方案上看应该是stl的引用不一致导致的问题，但编译中会报错“png.a can not find”，但是path路径确实没什么问题，所以比较坑爹，总之这样就搞定了，我也没怎么深究。
进入cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android目录下修改如下内容到指定路径
1: NDK_ROOT_LOCAL=/cygdrive/e/ADT/android-ndk-r7c
2: COCOS2DX_ROOT_LOCAL=/cygdrive/f/cocos2d-1.0.1-x-0.13.0-beta
cygwin中进入cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android目录下，执行./build_native.sh,编译C++，JNI接口，供Android Java使用，如果成功，在在libs中生成libhelloworld.so动态库，我们都是为了它做了这么多工作
在Eclipse中导入cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android工程，熟悉Android的一看就发现，其实这本身就是一个Java工程，我们刚才的操作只是其中jni的部分，供Java下面的调用实现而已
Eclipse中执行Build Project，生成R.java
Run
Make
ndk的Make是在GNU的Make的基础上的一种封装，下面我们来分析一下./build_native.sh都做了哪些操作。简单说主要是资源拷贝和代码编译。
资源拷贝在我的cygwin里面发现有问题，拷贝后的文件是错误的，且不能删除我没有深究，自己手动拷贝了一下。和shell一致，很容易理解，不再深究。
ndk-build编译HelloWorld工程，编译jni文件夹下面的Android.mk,和makefile基本相似，指定需要编译的文件，include路径，依赖工程cocos2dx_static，进行编译，例如HelloWorld的makefile大致如下：
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := helloworld_shared
LOCAL_MODULE_FILENAME := libhelloworld
LOCAL_SRC_FILES := helloworld/main.cpp \
../../Classes/AppDelegate.cpp \
../../Classes/HelloWorldScene.cpp
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../Classes
LOCAL_WHOLE_STATIC_LIBRARIES := cocos2dx_static
include $(BUILD_SHARED_LIBRARY)
$(call import-module,cocos2dx)
LOCAL_PATH := $(call my-dir)：指定当前路径为为LOCAL_PATH
include $(CLEAR_VARS)：清空除LOCAL_PATH之外的其他环境变量的干扰
LOCAL_MODULE&LOCAL_MODULE_FILENAME：模块名称&生成库名称
LOCAL_SRC_FILES：编译的C++ Source
LOCAL_WHOLE_STATIC_LIBRARIES：依赖的静态库
BUILD_SHARED_LIBRARY:生成的为共享库。因为Android的动态库都为JNI所用，所以称为共享库，而静态库只为其他C++库所用。
$(call import-module,<name>)：通过NDK_MODULE_PATH环境变量引用的模块<name>的目录列表，并且将其自动包含到Android.mk中
这样，一个编译环境的include，library，target基本指定，则编译出最终的目标文件，和makefile思路上没什么区别，另外这里需要编译出cocos2dx.a，静态库，是通过cocos2d文件夹中的make编译而成，这个脚本则要复杂一些，不过思想并无不同。更多NDK Make可以参考：《Android Make》
JNI交互
C++接口封装完毕后，我们就开始看一下Java代码，了解一下最终实现的流程和效果，Java代码如下：
Java层的框架也很简单，这里并没有多Accelerometer和Music、Sound等进行分析，只是对涉及到显示相关的进行分析。Java层面流程如下：
如上，如果熟悉Android界面开发，可以从基类了解到Java层面是通过Activity、GLSuffaceView来进行的显示。这里不详细介绍，如果有兴趣，可以看一下《剖析游戏开发用view还是surfaceView》,View类似传统的二维静态界面，数据驱动显示，而SurfaceView则类似三维机制，实时渲染。因为Cocos2d是OpenGL的，这也好解释。
对于整个框架其实要说的也很多，不过我对Java还不太了解，所以有些东西看的不一定透，也难免有一些问题。
Renderer
Renderer类负责每一帧的渲染驱动，调用步骤如图里面的1和2，在2中调用jni里面的nativeRender实现一帧的渲染，而GLSurfaceView则负责UI交互的监听。
这种机制的好处是在Java中Renderer渲染器是独立线程调用，因此和UI之间没有交互性，这样既保证了用户体验（用户的事件通过GLSurfaceView监听，最终通过Renderer传递至C++层面来响应），也保证了渲染过程的抗干扰，依旧通过C++层面进行渲染。，整个显示过程用到的jni封装主要如下：
jni的封装主要有两部分，一个是cocos2d自己的JNI封装，这部分封装主要是为了在Java中调用cocos2d的jni接口，一个是HelloWorld中自己的jni接口封装。这一块本来是我比较感兴趣的地方，因为jni封装还是挺繁琐的一件事情，最后发现cocos2d在本质上也没有什么区别，麻烦的还是得封装。第二点，cocos2d主要是游戏引擎，所以基本所有功能都是由C++层面来实现，一帧的渲染，事件的处理，而Java层主要负责逻辑处理，最终通过jni调用C++接口来实现。第三点来说，cocos2d本身封装的还是很简洁的，这点我觉得做的还是很优雅的，在设计这块，是以Java的逻辑为依据来进行划分，我觉得这个很可取，虽然cocos2d是C++做起来的，但是并没有为了保证各个平台的一致性而强迫接口的一致，而是在jni层按照SDK在具体平台的应用特点来进行封装，这样减低了实现难度，提高了代码的易用度，牺牲就是应用平台接口的局部不一致性。jni层面主要是事件传递和窗口渲染部分的接口封装，针对游戏开发者而言，最核心的部分都可以在Windows平台下完成，然后在Android部分完成特有事件的传递，渲染部分直接采用cocos2d给出的标准范例实现即可，大大简化了开发者自己封装jni的工作。
窗口绑定
窗口绑定我理解的并不太透彻，首先，我认为CCEGLView_Android只是一个虚的窗口，并没有实质功能，只是为了便于架构理解。
函数一是Java层调用onSurfaceCreated时调用函数，用来获取GLView窗口，用来下一步的渲染，而这个View窗口并没有类似Windows下的handle绑定，而接下来函数二是Java中onDrawFrame渲染每一帧时进行调用，最终调用底层的Director渲染，完成一帧绘制（详细内容可参考《cocos2d-x之HelloWorld范例分析(一)》）。
怎么来理解这种窗口绑定方式，保证我现在调用的gl函数，就能够绘制在窗口呢，通篇没有一个类似的handle从Java传递给JNI，通篇C++层面的View也只是一个只有Width和Height属性的结构体，所以我理解的是GLSurfaceView.Renderer默认在自己的线程中进行了封装，已经自己完成了和OpenGL的绑定。这个我觉得应该是靠谱的吧，而且自己来实时的每一帧渲染，下面的就不管里，你自己愿意调Java的接口也行，自己调gl的渲染也可以。这样也挺好的，都不用我顾虑这个事情了，只要给我高度宽度知道位置信息，我直接渲染。
文字
其他图形图像的绘制，都是和系统无关的。整个的渲染过程，也是跨平台的，一个平台的整合，主要是环境搭建、不同语言之间的消息传递、View的映射这些，前面也都阐述了，只是文字有一定的特殊，在Windows下使用CDC，在Linux是Freetype，在Android下如何实现？我觉得cocos2d实现思路也是不错的：C++通过JNI在Java层绘制，生成一张BitMap给C++，然后贴图完成。这个优点是简单，缺点就是如果文字太多的话，效率损失还是有的，其实我觉得如果有机会，还是用Freetype来画应该也可以尝试一下。
当然，也新学了一招，C++调用Java的方式，在jni里面也提供了，呵呵，代码在下面贴一下：
参照里面的注释,C++驱动Java实现绘制,Java完成绘制后,调用Java_org_cocos2dx_lib_Cocos2dxBitmap_nativeInitBitmapDC接口,实现内存的拷贝,而s_BmpDC中的m_pData用来保存,进行下一步的纹理贴图,完成整改流程的传递.
总结
介绍完毕,整个过程中,cocos2d使用的技术并不神秘,主要是一个熟悉的过程.最值得称赞的是JNI封装的比较使用,本身做游戏开发,基本所有功能都会在C++中封闭实现,只需要提供一个规范的Java外壳就可以,既跨平台有高效.另外,就是cocos2d对各个平台的语言取舍,哪些用Java方便,哪些用C++ 保持平台一致,都做的还是很合理的.
cocos2d-x环境搭建比较简单，但是小问题还是不少，我尽量都涵盖的全面一些。
下载软件
cygwin、NDK(ADT):C++相关
如果之前没有Android开发环境，还需要Android SDK，Eclipse
cocos2d-x源码
我的环境为ndk r7，cygwin1.7，Android SDK为2.2和3.0.另外,我是通过真机调试,在模拟器上不行,估计还是我T410显卡的问题.
安装cygwin，在cygwin文件进行路径设置
在cygwin\home\Administrator的.bash_profile中添加如下代码
1: ANDROID_NDK_ROOT=/cygdrive/e/ADT/android-ndk-r7c
2: export ANDROID_NDK_ROOT
3: NDK_ROOT=/cygdrive/e/ADT/android-ndk-r7c
4: export NDK_ROOT
将libgnustl_static.a从NDK中的android-ndk-r7c\sources\cxx-stl\gnu-libstdc++\libs\armeabi拷贝至cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android\obj\local\armeabi，这个从解决方案上看应该是stl的引用不一致导致的问题，但编译中会报错“png.a can not find”，但是path路径确实没什么问题，所以比较坑爹，总之这样就搞定了，我也没怎么深究。
进入cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android目录下修改如下内容到指定路径
1: NDK_ROOT_LOCAL=/cygdrive/e/ADT/android-ndk-r7c
2: COCOS2DX_ROOT_LOCAL=/cygdrive/f/cocos2d-1.0.1-x-0.13.0-beta
cygwin中进入cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android目录下，执行./build_native.sh,编译C++，JNI接口，供Android Java使用，如果成功，在在libs中生成libhelloworld.so动态库，我们都是为了它做了这么多工作
在Eclipse中导入cocos2d-1.0.1-x-0.13.0-beta\HelloWorld\android工程，熟悉Android的一看就发现，其实这本身就是一个Java工程，我们刚才的操作只是其中jni的部分，供Java下面的调用实现而已
Eclipse中执行Build Project，生成R.java
Run
Make
ndk的Make是在GNU的Make的基础上的一种封装，下面我们来分析一下./build_native.sh都做了哪些操作。简单说主要是资源拷贝和代码编译。
资源拷贝在我的cygwin里面发现有问题，拷贝后的文件是错误的，且不能删除我没有深究，自己手动拷贝了一下。和shell一致，很容易理解，不再深究。
ndk-build编译HelloWorld工程，编译jni文件夹下面的Android.mk,和makefile基本相似，指定需要编译的文件，include路径，依赖工程cocos2dx_static，进行编译，例如HelloWorld的makefile大致如下：
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := helloworld_shared
LOCAL_MODULE_FILENAME := libhelloworld
LOCAL_SRC_FILES := helloworld/main.cpp \
../../Classes/AppDelegate.cpp \
../../Classes/HelloWorldScene.cpp
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../Classes
LOCAL_WHOLE_STATIC_LIBRARIES := cocos2dx_static
include $(BUILD_SHARED_LIBRARY)
$(call import-module,cocos2dx)
LOCAL_PATH := $(call my-dir)：指定当前路径为为LOCAL_PATH
include $(CLEAR_VARS)：清空除LOCAL_PATH之外的其他环境变量的干扰
LOCAL_MODULE&LOCAL_MODULE_FILENAME：模块名称&生成库名称
LOCAL_SRC_FILES：编译的C++ Source
LOCAL_WHOLE_STATIC_LIBRARIES：依赖的静态库
BUILD_SHARED_LIBRARY:生成的为共享库。因为Android的动态库都为JNI所用，所以称为共享库，而静态库只为其他C++库所用。
$(call import-module,<name>)：通过NDK_MODULE_PATH环境变量引用的模块<name>的目录列表，并且将其自动包含到Android.mk中
这样，一个编译环境的include，library，target基本指定，则编译出最终的目标文件，和makefile思路上没什么区别，另外这里需要编译出cocos2dx.a，静态库，是通过cocos2d文件夹中的make编译而成，这个脚本则要复杂一些，不过思想并无不同。更多NDK Make可以参考：《Android Make》
JNI交互
C++接口封装完毕后，我们就开始看一下Java代码，了解一下最终实现的流程和效果，Java代码如下：
Java层的框架也很简单，这里并没有多Accelerometer和Music、Sound等进行分析，只是对涉及到显示相关的进行分析。Java层面流程如下：
如上，如果熟悉Android界面开发，可以从基类了解到Java层面是通过Activity、GLSuffaceView来进行的显示。这里不详细介绍，如果有兴趣，可以看一下《剖析游戏开发用view还是surfaceView》,View类似传统的二维静态界面，数据驱动显示，而SurfaceView则类似三维机制，实时渲染。因为Cocos2d是OpenGL的，这也好解释。
对于整个框架其实要说的也很多，不过我对Java还不太了解，所以有些东西看的不一定透，也难免有一些问题。
Renderer
Renderer类负责每一帧的渲染驱动，调用步骤如图里面的1和2，在2中调用jni里面的nativeRender实现一帧的渲染，而GLSurfaceView则负责UI交互的监听。
这种机制的好处是在Java中Renderer渲染器是独立线程调用，因此和UI之间没有交互性，这样既保证了用户体验（用户的事件通过GLSurfaceView监听，最终通过Renderer传递至C++层面来响应），也保证了渲染过程的抗干扰，依旧通过C++层面进行渲染。，整个显示过程用到的jni封装主要如下：
private static native void nativeTouchesBegin(int id, float x, float y); private static native void nativeTouchesEnd(int id, float x, float y); private static native void nativeTouchesMove(int[] id, float[] x, float[] y); private static native void nativeTouchesCancel(int[] id, float[] x, float[] y); private static native boolean nativeKeyDown(int keyCode); private static native void nativeRender(); private static native void nativeInit(int w, int h); private static native void nativeOnPause(); private static native void nativeOnResume();
jni的封装主要有两部分，一个是cocos2d自己的JNI封装，这部分封装主要是为了在Java中调用cocos2d的jni接口，一个是HelloWorld中自己的jni接口封装。这一块本来是我比较感兴趣的地方，因为jni封装还是挺繁琐的一件事情，最后发现cocos2d在本质上也没有什么区别，麻烦的还是得封装。第二点，cocos2d主要是游戏引擎，所以基本所有功能都是由C++层面来实现，一帧的渲染，事件的处理，而Java层主要负责逻辑处理，最终通过jni调用C++接口来实现。第三点来说，cocos2d本身封装的还是很简洁的，这点我觉得做的还是很优雅的，在设计这块，是以Java的逻辑为依据来进行划分，我觉得这个很可取，虽然cocos2d是C++做起来的，但是并没有为了保证各个平台的一致性而强迫接口的一致，而是在jni层按照SDK在具体平台的应用特点来进行封装，这样减低了实现难度，提高了代码的易用度，牺牲就是应用平台接口的局部不一致性。jni层面主要是事件传递和窗口渲染部分的接口封装，针对游戏开发者而言，最核心的部分都可以在Windows平台下完成，然后在Android部分完成特有事件的传递，渲染部分直接采用cocos2d给出的标准范例实现即可，大大简化了开发者自己封装jni的工作。
窗口绑定
窗口绑定我理解的并不太透彻，首先，我认为CCEGLView_Android只是一个虚的窗口，并没有实质功能，只是为了便于架构理解。
void Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeInit(JNIEnv* env, jobject thiz, jint w, jint h)
{
if (!cocos2d::CCDirector::sharedDirector()->getOpenGLView())
{
cocos2d::CCEGLView *view = &cocos2d::CCEGLView::sharedOpenGLView();
view->setFrameWidthAndHeight(w, h);
// if you want to run in WVGA with HVGA resource, set it
// view->create(480, 320); Please change it to (320, 480) if you're in portrait mode.
cocos2d::CCDirector::sharedDirector()->setOpenGLView(view);
AppDelegate *pAppDelegate = new AppDelegate();
cocos2d::CCApplication::sharedApplication().run();
}
}
void Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeRender(JNIEnv* env)
{
cocos2d::CCDirector::sharedDirector()->mainLoop();
}
函数一是Java层调用onSurfaceCreated时调用函数，用来获取GLView窗口，用来下一步的渲染，而这个View窗口并没有类似Windows下的handle绑定，而接下来函数二是Java中onDrawFrame渲染每一帧时进行调用，最终调用底层的Director渲染，完成一帧绘制（详细内容可参考《cocos2d-x之HelloWorld范例分析(一)》）。
怎么来理解这种窗口绑定方式，保证我现在调用的gl函数，就能够绘制在窗口呢，通篇没有一个类似的handle从Java传递给JNI，通篇C++层面的View也只是一个只有Width和Height属性的结构体，所以我理解的是GLSurfaceView.Renderer默认在自己的线程中进行了封装，已经自己完成了和OpenGL的绑定。这个我觉得应该是靠谱的吧，而且自己来实时的每一帧渲染，下面的就不管里，你自己愿意调Java的接口也行，自己调gl的渲染也可以。这样也挺好的，都不用我顾虑这个事情了，只要给我高度宽度知道位置信息，我直接渲染。
文字
其他图形图像的绘制，都是和系统无关的。整个的渲染过程，也是跨平台的，一个平台的整合，主要是环境搭建、不同语言之间的消息传递、View的映射这些，前面也都阐述了，只是文字有一定的特殊，在Windows下使用CDC，在Linux是Freetype，在Android下如何实现？我觉得cocos2d实现思路也是不错的：C++通过JNI在Java层绘制，生成一张BitMap给C++，然后贴图完成。这个优点是简单，缺点就是如果文字太多的话，效率损失还是有的，其实我觉得如果有机会，还是用Freetype来画应该也可以尝试一下。
当然，也新学了一招，C++调用Java的方式，在jni里面也提供了，呵呵，代码在下面贴一下：
bool getBitmapFromJava(const char *text, int nWidth, int nHeight, CCImage::ETextAlign eAlignMask, const char * pFontName, float fontSize)
{
JniMethodInfo methodInfo;
if (! JniHelper::getStaticMethodInfo(methodInfo, "org/cocos2dx/lib/Cocos2dxBitmap", "createTextBitmap",
"(Ljava/lang/String;Ljava/lang/String;IIII)V"))
{
CCLOG("%s %d: error to get methodInfo", __FILE__, __LINE__);
return false;
}
jstring jstrText = methodInfo.env->NewStringUTF(text);
jstring jstrFont = methodInfo.env->NewStringUTF(pFontName);
methodInfo.env->CallStaticVoidMethod(methodInfo.classID, methodInfo.methodID, jstrText,
jstrFont, (int)fontSize, eAlignMask, nWidth, nHeight);
methodInfo.env->DeleteLocalRef(jstrText);
methodInfo.env->DeleteLocalRef(jstrFont);
methodInfo.env->DeleteLocalRef(methodInfo.classID);
return true;
}
static bool getStaticMethodInfo_(cocos2d::JniMethodInfo &methodinfo, const char *className, const char *methodName, const char *paramCode)
{
jmethodID methodID = 0;
JNIEnv *pEnv = 0;
if (! getEnv(&pEnv))
{
break;
}
jclass classID = getClassID_(className, pEnv);
methodID = pEnv->GetStaticMethodID(classID, methodName, paramCode);
参照里面的注释,C++驱动Java实现绘制,Java完成绘制后,调用Java_org_cocos2dx_lib_Cocos2dxBitmap_nativeInitBitmapDC接口,实现内存的拷贝,而s_BmpDC中的m_pData用来保存,进行下一步的纹理贴图,完成整改流程的传递.
总结
介绍完毕,整个过程中,cocos2d使用的技术并不神秘,主要是一个熟悉的过程.最值得称赞的是JNI封装的比较使用,本身做游戏开发,基本所有功能都会在C++中封闭实现,只需要提供一个规范的Java外壳就可以,既跨平台有高效.另外,就是cocos2d对各个平台的语言取舍,哪些用Java方便,哪些用C++ 保持平台一致,都做的还是很合理的.
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
