Android OpenGL跟踪墙时间与线程时间

我已经苦苦挣扎了好几天，试图弄明白为什么我在Android上的OpenGL ES 2.0应用程序不稳定。每秒帧数相当高，通常保持在一致的60帧/秒，但是游戏看起来并不流畅。在排除了诸如我的timestep（同一个应用程序使用OpenGL ES 1.0运行良好）和重载数学和帧（应用程序已简化为一个简单的旋转三角形）等简单问题后，我遇到了OpenGL跟踪

我找不到任何确切解释OpenGL跟踪的信息。所以我在这里有点茫然，但我看到了一些奇怪的行为，比如glClear（mask=256）函数占用2533190纳秒的墙时间，而线程时间只占用61040纳秒。这将发生一次，然后在几帧内一切正常

另一个例子是元素。274684纳秒壁时间，61040线程时间

这可能向我暗示，通过我尝试和错误的方法来理解跟踪中的任何信息，在引擎盖下发生的某些事情导致了减速

这实际上意味着什么？标准的还是奇怪的行为？如果奇怪的话，这种行为的原因是什么

如果你愿意的话，有谁能给我指一下信息，这样我就能理解我在追踪中看到了什么

---

我正在尽我最大的努力，希望能够重新开始我的申请工作。感谢阅读。

尝试为单个OpenGL（ES）API调用的执行计时是一个非常糟糕的主意。OpenGL将这些调用缓冲到命令队列中，并在需要时刷新它们（例如，满队列、您实际手动请求刷新等）。绘制调用通常是命令刷新的来源，绘制调用之前发生的许多状态更改必须最终确定，绘制调用的成本实际上是非常可变的。桌面GL中引入了计时器查询对象，用于计算任意一系列操作在管道中所需的时间。不幸的是，OpenGL ES中不存在这样的模拟。也就是说，API调用返回所需的时间与执行命令所需的时间几乎没有关系。。。API调用有义务执行诸如验证输入参数和立即设置错误状态之类的操作，但由于GL是客户机/服务器体系结构，返回所需的时间仅为等式的一半。最终，服务器将执行API调用生成的命令，这就是为什么要执行管道级（服务器）计时而不是API（客户端）计时。