建议所有暴露给用户的接口都是线程安全的，不要让用户去处理多线程，因为用户压根不知道引擎有多少个线程在工作，哪些函数应该在哪个线程执行，而且一般的逻辑开发人员可能一辈子都搞不清多线程是什么玩意，比如jsb.reflection.callStaticMethod，这个方法可以在上层包一个在主线程执行的一层，还有那个原生回调js的接口，应该引擎在接口里就让调用去GL线程执行。
最简单的方法，用户能接触到的所有代码都是在同一个线程。
3赞
ScriptingCore::getInstance()->evalString 这个玩意内部就应该去Director::getInstance()->getScheduler()->performFunctionInCocosThread
当然可能带来其它问题，就是这玩意是异步的。
用户应该自己保证引擎 API 在主线程被调用，如果不能保证，就不应该用多线程。
现在这个情况主要是接第三方SDK出现的，有时多线程，根本不是用户自己开的，是SDK开的。
那同样是能避免的
都是有办法可以避免，当然，就是成本高了，现在一个线程问题，要试好多次也许会闪退一次，特别是SDK的调用，不过有经验都，都默认全在执行前包上performFunctionInCocosThread类似的，如果是一个新手，学习成本就高了。
看不下去了，你转行吧
你应该跟着jare大神多学习几年再回帖。
由于第三方 SDK 的回调都是用户注册的，回调函数中直接使用 ScriptingCore 的接口，比如 evalString，executeFunction 之类的，我们如果对所有 ScriptingCore 的接口都做类似的兼容，其实不是很合理，实际上它超出了接口本身定义的功能范畴。
所以才提供了 performFunctionInCocosThread 这种封装，如果有更好的封装建议欢迎提供。
与这个相对应该的安卓下有在native的UI主线程执行的方法runOnUiThread,在ios下有没有对应的方法？jsb.reflection.callStaticMethod这个一般应该去native的UI主线程执行，我没有深入研究cocos的线程有多少，怎么处理的，没办给了很详细的建议，我只是第一感觉这些接口应该要是线程安全的才对。
iOS 下可以直接调用 C++ 接口，就是这个 performFunctionInCocosThread。
callStaticMethod 是主动调用没啥问题，问题主要在于 JAVA 代码中设置的回调，这种回调多数在 JAVA 的 UI 线程回调，肯定要用 runOnGlThread 来派发到 GL 线程执行，所以封装 callStaticMethod 没用
iOS 下oc调用js是用performFunctionInCocosThread，但js调用oc是哪个，java下是可以用runOnUiThread。
mark
performFunctionInCocosThread根本无法传递参数，因为子线程被释放，参数也一并丢失了。
资源加载过图的时候，加载进度条卡死，这个有处理办法吗？试过Promise，web预览可以，但安卓打包后就卡死，都执行完毕后，才进行后续的回调进度条展示，像卡死了一样