在 iPhone 8 上的测试例也是应用内切换的，测试时我尽可能的关掉了后台，测试进行到后期时，手机发热比较严重（可能会影响到准确性），不过同一组数据，是在基本同样的发热条件下测试的。
这里面 Debug 模式，和 Release 模式差别这么大，这个信息也很重要。
我在一个低端android上进行测试.
华为 畅玩5 CUN-AL00 cpu 4核1.3
我用原生android控件在屏幕左上角分别显示
调用Cocos2dxRenderer.nativeRender();的时间和 两次onDrawFrame()调用的时间差
发现Cocos2dxRenderer.nativeRender()实际只用了35-40ms, 但是onDrawFrame()的调用间隔已经达到将近200ms.
Cocos2dxRenderer.nativeRender()的时间和左下角update和render的时间可以说是差不多吻合.
现在有点迷惑, 除了 nativeRender 这个方法,还有其他地方影响到onDrawFrame的再一次调用了吗?
glDrawElements方法是CPU把像素传输给GPU, 这里面包含实际渲染吗?
@minggo 求大佬解惑, 这消失的100多ms去哪了
另外, 合并drawcall对FPS的提升在android设备上,可以说是相当明显
我刚才用 iPhoneX 测试时发现，不合并 draw call 时帧率比较高，CPU 的的消耗也提升到 90% 以上（合并批次才 60%) 左右，从这里也可以侧面说明当不合并批次时被切换到了大核。
gl 的调用都没保证实际渲染，它是客户端、服务器模式，只有在 glSwapBuffer() 返回才确保这一帧的所有 gl 调用都被执行了。在 Android，glSwapBuffer 是系统调用的，是在 onDrawFrame 之后进行的。
1赞
最后解决方案呢？我也遇到这个问题，游戏序列帧比较多，内存只耗40M，cpu占90%，怎么办，开始进去不卡，玩一会儿手机烫了就奇卡无比。有没有解决方法。
我曹 挖坟了。。我也mark下