Android中OpenGL ES调用glDrawElements是否立即执行屏幕绘制

开发Android游戏时观测到如下现象：

• 仅统计GLSurfaceView.Renderer（所有图形相关计算逻辑均放置于此）内的耗时时，测得帧率为300fps
• 统计单帧全流程总耗时时，帧率仅为10fps

核心疑问：在Android平台调用GLES30.glDrawElements()时，是会阻塞当前程序立即启动绘制流程，还是会将该绘制调用加入指令列表，待程序退出GLSurfaceView相关逻辑后，由Android系统在Activity或SurfaceView的更新间隙，在后台遍历执行所有绘制调用完成屏幕绘制？实际执行流程对应以下哪一种？

候选流程1 #

Android call update
||
Draw call
||
Drawing
||
Continue program
||
Loops

候选流程2 #

Android call update
||
Draw call
||
Add to list
||
Continue program and exit GLSurfaceView
||
Android goes through all draw calls and draws to the screen.
||
Loops

核心结论：整体逻辑和流程2匹配，但存在部分细节偏差，glDrawElements()不会阻塞等待绘制完成，GPU渲染是异步执行的，不存在系统等退出GLSurfaceView后才统一遍历执行指令的逻辑。
具体机制如下：

• 包括GLES30.glDrawElements()在内的所有OpenGL ES API本质都是非阻塞调用：CPU执行到这类方法时，只会把对应的GPU渲染指令打包提交到驱动维护的命令队列，就立刻返回执行后续代码，完全不会等待GPU完成实际的顶点计算、光栅化、片元着色等绘制工作。你在Renderer回调内部统计到的耗时，仅仅是CPU侧组织、提交指令的开销，这部分速度极快，才会测出300fps的虚高值，完全没有覆盖GPU实际渲染的耗时。
• GLSurfaceView的内置逻辑会在你的onDrawFrame回调执行结束后，自动调用eglSwapBuffers()完成帧缓冲交换，这是渲染流程的第一个强制同步点：如果此时GPU还没执行完你之前提交的所有渲染指令，CPU会阻塞在这个方法调用上，直到GPU把当前帧所有内容渲染到后台缓冲，才会交换前后缓冲，把渲染完成的帧交给系统SurfaceFlinger服务做最终的屏幕合成显示。
• 你测到全流程帧率仅10fps，根本原因是提交的渲染指令GPU负载过高：比如shader逻辑复杂、三角面数过多、纹理采样开销过大等，GPU执行每帧指令需要约100ms，这部分耗时全部卡在eglSwapBuffers()的等待阶段，完全不会被你在Renderer回调内部的时间统计捕捉到。
• 不存在“退出GLSurfaceView逻辑后系统才遍历执行绘制调用”的机制：GPU只要从命令队列拿到渲染指令就会顺序调度执行，和当前是否在GLSurfaceView的回调逻辑里没有关系，只是在eglSwapBuffers()执行完成前，所有渲染内容都存储在后台缓冲中，不会被提交到屏幕上显示。

内容的提问来源于stack exchange，提问作者user14587078