cocos android分析

时间 2019-11-12

原文原文链接

来自：http://xiebaochun.github.io/html

cocos2d-x Android环境搭建java

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\androidproject。熟悉Android的一看就发现，事实上这自己就是一个Javaproject，咱们刚才的操做仅仅是当中jni的部分，供Java如下的调用实现而已
Eclipse中运行Build Project。生成R.java
Run

Make
ndk的Make是在GNU的Make的基础上的一种封装，如下咱们来分析一下./build_native.sh都作了哪些操做。

简单说主要是资源拷贝和代码编译。

资源拷贝在个人cygwin里面发现有问题。拷贝后的文件是错误的，且不能删除我没有深究，本身手动拷贝了一下。和shell一致，很是easy理解，再也不深究。

ndk-build编译HelloWorldproject。编译jni目录如下的Android.mk,和makefile基本类似，指定需要编译的文件。include路径，依赖projectcocos2dx_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++库所用。android

$(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层的框架也很是easy。这里并无多Accelerometer和Music、Sound等进行分析，仅仅是对涉及到显示相关的进行分析。Java层面流程例如如下：

如上，假设熟悉Android界面开发，可以从基类了解到Java层面是经过Activity、GLSuffaceView来进行的显示。c++

这里不具体介绍。假设有兴趣。可以看一下《剖析游戏开发用view仍是surfaceView》,View相似传统的二维静态界面，数据驱动显示，而SurfaceView则相似三维机制，实时渲染。git

因为Cocos2d是OpenGL的。这也好解释。

对于整个框架事实上要说的也很是多，只是我对Java还不太了解。因此有些东西看的不必定透。也不免有一些问题。

Renderer
Renderer类负责每一帧的渲染驱动，调用步骤如图里面的1和2。在2中调用jni里面的nativeRender实现一帧的渲染。而GLSurfaceView则负责UI交互的监听。

这样的机制的优势是在Java中Renderer渲染器是独立线程调用。所以和UI之间没有交互性。这样既保证了用户体验（用户的事件经过GLSurfaceView监听，终于经过Renderer传递至C++层面来响应），也保证了渲染过程的抗干扰，依然经过C++层面进行渲染。github

，整个显示过程用到的jni封装主要例如如下：

shell

 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封装
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仅仅是一个虚的窗体，并无实质功能。仅仅是为了便于架构理解。
bash

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++ 保持平台一致,都作的仍是很是合理的.