cocos android分析

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封装主要如下:

 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只是一个虚的窗口,并没有实质功能,只是为了便于架构理解。

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

cocos android分析,布布扣,bubuko.com

时间: 2024-10-12 14:06:26

cocos android分析的相关文章

Android分析第三方应用layout的神器

hierarchyviewer.bat或者monitor.bat一直都是分析layout的神器,不过,很多时候不好用,连不上真机,害的我不得不使用模拟器来分析layout. 今天发现了另外一个申请,就在ADT里面,它就躺在那,我怎么一直就没发现? Dump View Hierarchy for UI Automator Android分析第三方应用layout的神器

android分析之消息处理

前序:每个APP对应一个进程,该进程内有一个ActivityThread的线程,称为主线程(即UI主线程),此外,还有其他线程,这个再论. android的消息系统分析. 每个Thread只对应一个Looper 每个Looper只对应一个MessageQueue 每个MessageQueue中有N个Message 每个Message中最多指定一个Handler来处理事件 一个Thread可以对应多个Handler Looper负责从消息队列中(MessageQueue)取出消息(Message/

android分析之Binder 01

终于还是得写一篇关于Binder的文章了.从最初接触Android到花大把时间研究Android源码,Binder一直是分析道路的拦路虎.看了几本最流行的Android源码分析书籍,每次基本上都不能把Binder相关知识看完.读透.好在一直没有放弃,第一次理解不了就跳过,下一次重新读,每次读都有新的收获.现在是时候整理整理了. 我理解的Binder是什么?一种IPC(跨进程通信)的实现方式.注意“跨进程”,表明数据从一个进程“流向”了另一个进程.首先要了解为什么跨进程那么难?因为应用程序的地址空

android分析之自定义圆形头像

package de.hdodenhof.circleimageview; public class CircleImageView extends ImageView { private static final ScaleType SCALE_TYPE = ScaleType.CENTER_CROP;//决定了图片在View上显示时的样子,如进行何种比例的缩放,及显示图片的整体还是部分,等等 private static final Bitmap.Config BITMAP_CONFIG =

Android分析应用程序的构建过程

为了方便Android应用开发要求我们Androidproject编制和包装有了更深入的了解,例如,我们知道这是做什么的每一步,境和工具.输入和输出是什么.等等. 在前文<命令行下Android应用开发>中我们已经知道怎样创建一个Androidproject和编译执行可调试版本号的应用程序.本文将介绍Androidproject的整个编译过程. 首先来分析Ant怎样将Androidproject编译打包成APK文件 运行ant debug命令时ant 脚本build.xml各target之间的

Android分析破解-秒脱360加固大法

Android相比iOS,安全问题往往比较突出,各种漏洞和破解层出不穷.对破解方法的了解,能在开发中进行预防,加强应用的安全性.本系列文章会对Android应用的破解和保护两方面做个探讨,给开发的同学一些借鉴.Andoid开发的同学可能会遇到需要做竞品分析的情况,APK加固常常会成为分析的障碍.360渠道做为Android应用分发的最大渠道,很多apk都使用了360加固.本文就来聊聊如何过掉这个坑.360加固后的apk,在arm设备上首先会将assets目录下的libjiagu.so拷贝到fil

Android 分析工具 APKAnalyser

APKAnalyser 是 Android 静态,虚拟分析工具,用来测试和验证 Android 应用的开发工作.ApkAnalyser 是个完整的工具链,可以修改二进制应用.用户可以改装,安装,运行,验证 logcat 的结果.ApkAnalyser 同时支持资源分析,可以解码 XML,查找资源指向和检测应用潜在问题. ApkAnalyser 是个独立的 J2SE 应用,遵循 Apache 开源协议,完全使用 Java 编写.

[Android] 分析一个CalledFromWrongThreadException崩溃

1 问题描述 问题本身比较清晰简单,但推敲的过程中发现了不少有意思的东西. 在C++ SDK回调JNI至Java Observer函数中,直接操作了UI界面textView.setText(msg),第一次回调没有崩溃,第二次回调(或者退出Activity)时才会崩溃.奇怪不?崩溃栈信息如下: 07-02 16:04:07.503 32666 665 W ackor : [KLH]OnNotifyClick - 1 jenv=0x920544c0 07-02 16:04:07.503 32666

android分析之Binder 02

分析Java层的ServiceManager,看看Binder在Java层是如何实现的. public final class ServiceManager { private static final String TAG = "ServiceManager"; private static IServiceManager sServiceManager;//IserviceManager是一个接口,定义了通用(公共)方法. private static HashMap<Str