call to OpenGL ES API with no current context 和Fatal signal 11

近日在用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则属于主线程,所以,解决办法也很简单,就是把回调放到openglsurfaceview中如下


class EventHandler extends Handler {
@Override
public void handleMessage(Message msg) {
{


   Cocos2dxGLSurfaceView.getInstance().queueEvent(new Runnable() {
   @Override
     public void run() {
    payResultCode(mPayId, 0);
     }
   });

 }

}
}


核心就在这里,请大家注意一下。

你可能感兴趣的:(技术天下)