近日在用cocos2dx3.4的时候使用了JNI调用，发现一个现象
当不使用jni的时候全然正常。使用了jni后回去的全部文字都变成黑块，而且有概率程序崩溃。附带出了两个log
call to OpenGL ES API with no current context 和 Fatal signal 11
但相同的cocos2dx ，相同的jni代码，还有一个项目却正常。找寻了好久之后发现了原因
cocos2dx 3.x以后版本号 不再是一个进程跑究竟：
引用：“Cocos2d-x从2.x版本号到上周刚刚才公布的Cocos2d-x 3.0 Final版。其引擎驱动核心依然是一个单线程的“死循环”，一旦某一帧遇到了“大活儿”，比方Size非常大的纹理资源载入或网络IO或大量计算，画面将 不可避免出现卡顿以及响应迟缓的现象。从古老的Win32 GUI编程那时起，Guru们就告诉我们：别堵塞主线程(UI线程)，让Worker线程去做那些“大活儿”吧。 手机游戏，即便是休闲类的小游戏。往往也涉及大量纹理资源、音视频资源、文件读写以及网络通信。处理的稍有不甚就会出现画面卡顿。交互不畅的情况。尽管引 擎在某些方面提供了一些支持，但有些时候还是自己祭出Worker线程这个法宝比較灵活。以下就以Cocos2d-x 3.0 Final版游戏初始化为例（针对Android平台）。说说怎样进行多线程资源载入。 我们常常看到一些手机游戏，启动之后首先会显示一个带有公司Logo的闪屏画面(Flash Screen)，然后才会进入一个游戏Welcome场景。点击“開始”才正式进入游戏主场景。而这里Flash Screen的展示环节往往在后台还会做另外一件事，那就是载入游戏的图片资源。音乐音效资源以及配置数据读取。这算是一个“障眼法”吧。目的就是提高用 户体验。这样兴许场景渲染以及场景切换直接使用已经cache到内存中的数据就可以。无需再行载入。”
那问题就出在cocos2dx新版本号事实上分了两个线程 openglview的绘制线程和程序主线程。
当jni回调c++的函数中有类似sprite创建、删除、改动等。则会出现上述两个错误。导致整个内存都乱了。
再去分析了一下还有一个正常项目，发如今这个项目内的jni回调中没有做不论什么载入图片等动作，仅仅是更新了数据，改了文字，所以没有出现大问题。
分析可能是载入图片这类操作不能在主线程里面做，而activity直接回调jni则属于主线程，所以，解决的方法也非常easy，就是把回调放到openglsurfaceview中例如以下
class EventHandler extends Handler {
@Override
public void handleMessage(Message msg) {
{
Cocos2dxGLSurfaceView.getInstance().queueEvent(new Runnable() {
@Override
public void run() {
payResultCode(mPayId, 0);
}
});
}
}
}
核心就在这里。请大家注意一下。