android游戏循环与渲染线程中的更新

Question

我正在制作一个 android 游戏，但目前没有获得我想要的性能。我在自己的线程中有一个游戏循环，它更新对象的位置。渲染线程将遍历这些对象并绘制它们。当前的行为看起来像是断断续续/不均匀的运动。我无法解释的是，在我将更新逻辑放在自己的线程中之前，我在 onDrawFrame 方法中，就在 gl 调用之前。在那种情况下，动画非常流畅，当我尝试通过 Thread.sleep 限制更新循环时，它只会变得断断续续/不均匀。即使我让更新线程狂暴(不休眠)，动画也很流畅，只有当涉及到Thread.sleep时才会影响动画质量。

我创建了一个骨架项目来查看是否可以重现该问题，下面是渲染器中的更新循环和 onDrawFrame 方法:
更新循环

    @Override
public void run() 
{
    while(gameOn) 
    {
        long currentRun = SystemClock.uptimeMillis();
        if(lastRun == 0)
        {
            lastRun = currentRun - 16;
        }
        long delta = currentRun - lastRun;
        lastRun = currentRun;

        posY += moveY*delta/20.0;

        GlobalObjects.ypos = posY;

        long rightNow = SystemClock.uptimeMillis();
        if(rightNow - currentRun < 16)
        {
            try {
                Thread.sleep(16 - (rightNow - currentRun));
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

这是我的 onDrawFrame 方法:

        @Override
public void onDrawFrame(GL10 gl) {
    gl.glClearColor(1f, 1f, 0, 0);
    gl.glClear(GL10.GL_COLOR_BUFFER_BIT |
            GL10.GL_DEPTH_BUFFER_BIT);

    gl.glLoadIdentity();

    gl.glBindTexture(GL10.GL_TEXTURE_2D, textures[0]);
    gl.glTranslatef(transX, GlobalObjects.ypos, transZ);
    //gl.glRotatef(45, 0, 0, 1);
    //gl.glColor4f(0, 1, 0, 0);

    gl.glEnableClientState(GL10.GL_VERTEX_ARRAY);
    gl.glEnableClientState(GL10.GL_TEXTURE_COORD_ARRAY);

    gl.glVertexPointer(3,  GL10.GL_FLOAT, 0, vertexBuffer);
    gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, uvBuffer);

    gl.glDrawElements(GL10.GL_TRIANGLES, drawOrder.length,
              GL10.GL_UNSIGNED_SHORT, indiceBuffer);

    gl.glDisableClientState(GL10.GL_VERTEX_ARRAY);
    gl.glDisableClientState(GL10.GL_TEXTURE_COORD_ARRAY);
}

我查看了副本岛的源代码，他在一个单独的线程中执行更新逻辑，并使用 Thread.sleep 对其进行节流，但他的游戏看起来非常流畅。有没有人有任何想法或有没有人经历过我所描述的？

---编辑:1/25/13---
我花了一些时间思考并大大简化了这个游戏引擎。我的处理方式可能会亵渎或侮辱实际的游戏程序员，因此请随时纠正这些想法。

基本思想是保持更新、绘制...更新、绘制...的模式，同时保持时间增量相对相同(通常不受您控制)。
我的第一个行动方案是以这样一种方式同步我的渲染器，它只在被通知它被允许这样做后才绘制。这看起来像这样:

public void onDrawFrame(GL10 gl10) {
        synchronized(drawLock)
    {
        while(!GlobalGameObjects.getInstance().isUpdateHappened())
        {
            try
            {
                Log.d("test1", "draw locking");
                drawLock.wait();
            } 
            catch (InterruptedException e) 
            {
                e.printStackTrace();
            }
        }
    }

当我完成更新逻辑时，我调用 drawLock.notify()，释放渲染线程来绘制我刚刚更新的内容。这样做的目的是帮助建立更新、绘制...更新、绘制...等的模式。

一旦我实现了它，它就变得相当流畅，尽管我仍然偶尔会遇到运动跳跃。经过一些测试，我发现在 ondrawFrame 的调用之间发生了多次更新。这导致一帧显示两个(或更多)更新的结果，比正常跳跃更大。

我为解决这个问题所做的是将两次 onDrawFrame 调用之间的时间增量限制为某个值，例如 18 毫秒，并将额外时间存储在剩余时间中。如果他们可以处理，这个剩余部分将在接下来的几次更新中分配给后续的时间增量。这个想法可以防止所有突然的长跳，从本质上平滑多帧的时间峰值。这样做给了我很好的结果。

这种方法的缺点是在一段时间内，物体的位置不会随着时间的推移而准确，实际上会加速以弥补这种差异。但它更平滑，速度变化不是很明显。

最后，我决定考虑到上述两个想法来重写我的引擎，而不是修补我最初制作的引擎。我对线程同步做了一些优化，也许有人可以评论。

我当前的线程交互如下:
-更新线程更新当前缓冲区(双缓冲区系统，以便同时更新和绘制)，然后如果前一帧已绘制，则将此缓冲区提供给渲染器。
- 如果前一帧还没有绘制，或者正在绘制，更新线程将等待直到渲染线程通知它已经绘制。
- 渲染线程等待，直到更新线程通知已发生更新。
- 当渲染线程绘制时，它会设置一个“最后绘制的变量”，指示它最后绘制了两个缓冲区中的哪一个，并通知更新线程是否正在等待绘制前一个缓冲区。

这可能有点令人费解，但这样做是为了发挥多线程的优势，因为它可以在第 n-1 帧正在绘制时执行第 n 帧的更新，同时如果渲染器正在绘制，还可以防止每帧多次更新迭代很久。进一步解释一下，如果检测到 lastDrawn 缓冲区与刚刚更新的缓冲区相等，则更新线程锁定会处理这种多次更新的情况。如果它们相等，则向更新线程表明之前的帧尚未绘制。

到目前为止，我得到了很好的结果。如果有人有任何意见，请告诉我，很高兴听到您对我所做的任何事情的看法，无论是对还是错。

谢谢

Answer 1

(Blackhex 的回答提出了一些有趣的观点，但我不能把所有这些都塞进评论中。)

两个线程异步运行必然会导致这样的问题。这样看:驱动动画的事件是硬件“vsync”信号，即Android表面合成器向显示硬件提供一个充满数据的新屏幕的点。每当 vsync 到达时，您都希望拥有一个新的数据帧。如果您没有新数据，则游戏看起来很不稳定。如果你在那段时间生成了 3 帧数据，其中两帧会被忽略，你只是在浪费电池生命周期。

(CPU 满负荷运行也可能导致设备升温，从而导致热节流，从而减慢系统中的所有内容……并且可能使您的动画断断续续。)

与显示保持同步的最简单方法是在 onDrawFrame() 中执行所有状态更新。 .如果有时执行状态更新和渲染帧所需的时间超过一帧，那么您看起来会很糟糕，需要修改您的方法。简单地将所有游戏状态更新转移到第二个核心并不会像您希望的那样有多大帮助——如果核心 #1 是渲染器线程，而核心 #2 是游戏状态更新线程，那么核心 #1 将会运行在核心 #2 更新状态时闲置，之后核心 #1 将在核心 #2 闲置时继续执行实际渲染，并且将花费同样长的时间。要真正增加每帧可以执行的计算量，您需要有两个(或更多)内核同时工作，这会引发一些有趣的同步问题，具体取决于您如何定义分工(请参阅 http://developer.android.com/training/articles/smp.html，如果您想走那条路)。

正在尝试使用 Thread.sleep()管理帧率通常会很糟糕。您无法知道 vsync 之间的时间段有多长，或者下一个到达之前需要多长时间。每个设备都不同，在某些设备上它可能是可变的。你最终会得到两个时钟——vsync 和 sleep——相互对抗，结果是动画断断续续。最重要的是，Thread.sleep()不对准确性或最短 sleep 时间做出任何具体保证。

我还没有真正浏览过副本岛的来源，但在 GameRenderer.onDrawFrame()您可以看到他们的游戏状态线程(创建要绘制的对象列表)和 GL 渲染器线程(仅绘制列表)之间的交互。在他们的模型中，游戏状态只在需要时更新，如果没有任何变化，它只会重新绘制之前的绘制列表。此模型适用于事件驱动的游戏，即当发生某些事情时屏幕上的内容会更新(您按下键、计时器触发等)。当一个事件发生时，他们可以做一个最小的状态更新并根据需要调整抽签列表。

从另一个角度来看，渲染线程和游戏状态是并行工作的，因为它们并没有严格绑定(bind)在一起。游戏状态只是根据需要不断更新内容，渲染线程将它锁定在每个 vsync 并绘制它找到的任何内容。只要双方都没有把任何东西锁得太久，他们就不会明显地干涉。唯一有趣的共享状态是绘制列表，由互斥锁保护，因此它们的多核问题被最小化。

对于 Android Breakout ( http://code.google.com/p/android-breakout/ )，游戏中有一个连续运动的球在周围弹跳。我们希望在显示器允许的情况下尽可能频繁地更新我们的状态，因此我们从 vsync 驱动状态更改，使用前一帧的时间增量来确定事情进展了多远。每帧计算量很小，而且对于现代 GL 设备而言，渲染非常简单，因此它可以在 1/60 秒内轻松完成。如果显示器更新得更快(240Hz)，我们可能偶尔会丢帧(同样，不太可能被注意到)，并且我们会在帧更新时消耗 4 倍的 CPU(这是不幸的)。

如果由于某种原因这些游戏之一错过了垂直同步，玩家可能会也可能不会注意到。状态按耗时前进，而不是固定持续时间“帧”的预设概念，例如球将在两个连续帧中的每一帧中移动 1 个单位，或在一帧中移动 2 个单位。根据帧速率和显示器的响应能力，这可能不可见。 (这是一个关键的设计问题，如果您根据“滴答声”来设想您的游戏状态，可能会弄乱您的头脑。)

这两种方法都是有效的。关键是每当onDrawFrame时绘制当前状态被调用，并尽可能不频繁地更新状态。

其他碰巧读到这篇文章的人请注意:不要使用 System.currentTimeMillis() .问题中使用的示例 SystemClock.uptimeMillis() ，它基于单调时钟而不是挂钟时间。那个，或者 System.nanoTime() ，是更好的选择。 (我正在对 currentTimeMillis 进行小幅讨伐，它在移动设备上可能会突然向前或向后跳跃。)

更新:我写了一个 even longer answer到一个类似的问题。

更新 2:我写了一个 even longer longer answer关于一般问题(见附录 A)。