来自 lockCanvas 方法的游戏循环中的偶尔卡顿/滞后

Posted

技术标签:

【中文标题】来自 lockCanvas 方法的游戏循环中的偶尔卡顿/滞后【英文标题】:Occasional Stutter/Lag in game loop from lockCanvas method 【发布时间】:2012-05-14 15:23:48 【问题描述】:

我正在以给定的速度平滑滚动位图。我正在使用游戏循环来执行此操作。 它滚动非常流畅,大约 60 fps,除了偶尔的口吃/跳跃。这些跳跃发生在任何地方,从每秒一次到每秒几次。通常它们会在运行几秒钟后开始或变得更加频繁,但我不确定这是否是一个大线索。

跳跃的原因是偶尔运行循环的迭代会花费大约两倍的时间,因此位图会在一个地方停留一段时间,然后进一步跳跃以赶上并保持其恒定速度。我使用插值根据经过的时间计算出每次更新时位图的新位置。当比平时更长的时间过去时,我尝试进行几次小更新,而不是一次移动整个距离,但暂停的位图仍然非常明显。

我运行了 traceview,而额外的时间花在了 lockCanvas 中。大多数情况下,此方法大约需要 10 毫秒,但在这些较长的情况下,大约需要 24 毫秒。当我追踪四秒钟时,这种情况发生了 7 次。

在下面的代码中,如果它运行得很快,我会让它休眠一会儿,但这实际上并没有什么区别。如果我摆脱那部分代码,我的问题就没有解决。不需要恒定的帧速率,因为我只是根据经过的时间来计算位置。

@Override
    public void run() 


         long beginTime = 0;     // the time when the cycle begun
         long timeDiff;      // the time it took for the cycle to execute
         int sleepTime;      // ms to sleep (<0 if we're behind)
         sleepTime = 0;
        while (mRun) 
            Canvas c = null;

            try 
                beginTime = System.currentTimeMillis();

                c = mSurfaceHolder.lockCanvas(null);
                synchronized (mSurfaceHolder) 

                    if (mMode == STATE_RUNNING) 
                        updatePhysics();
                    
                    doDraw(c);
                


             catch(Exception e)
                System.out.println(e.getStackTrace());
            finally 

                if (c != null) 
                    mSurfaceHolder.unlockCanvasAndPost(c);
                
            
            timeDiff = System.currentTimeMillis() - beginTime;

            sleepTime = (int)(FRAME_PERIOD - timeDiff);

            if(sleepTime > 0)

                 try 
                    Thread.sleep(sleepTime);
                  catch (InterruptedException e) 
            
        
    

updatePhysics() 和 doDraw() 的代码会做一些数学运算,我已尝试使其尽可能高效。基本上他们只是根据时间和速度计算位图的新位置。我只有一个位图,并且不会每次都重新分配它或类似的东西。

另外,我确信我的 surfaceHolder 已准备就绪,因此我通过搜索 google 找到的常见答案不是重复调用未就绪的 surfaceHolder 已被限制。

任何想法可能导致这种情况?我的表面支架使用 PixelFormat.RGB_565 并且我的位图被编码为 Bitmap.Config.RGB_565 如果这有所不同。我最初是从我制作的相对布局中获得位图的。

【问题讨论】:

FWIW,类似的问题在这里:***.com/questions/21838523/…。如今,“systrace”在确定时间花在哪里方面非常有效,尽管您需要一个有根设备才能获取一些信息。 【参考方案1】:

一种可能的解释是,您的代码会生成大量短期对象,并且垃圾收集器会定期启动以回收内存。

这些明显的停顿是 Java 早期版本中开发人员的祸根,直到分代垃圾收集几乎消除了这个问题。但是,据我所知,android 的 Dalvik 虚拟机不采用分代垃圾回收,因此您应该谨慎创建立即丢弃的对象,尤其是在循环中。

分析内存分配将更清楚地说明这个问题。

如果这确实是问题所在,您可以尝试重用对象,或使用原语处理数据。

【讨论】:

FWIW,一个“大部分并发”的垃圾收集器随 Gingerbread 一起提供,显着减少了暂停时间。然而,最好的停顿是没有停顿。在最近的版本中,您可以将“dalvik”添加到 systrace 标记列表中,以查看跟踪输出中的 GC 暂停;如果他们是问题,那将很明显。如果不出意外,在 logcat 中会记录 GC,因此可以将暂停与日志输出相关联。

以上是关于来自 lockCanvas 方法的游戏循环中的偶尔卡顿/滞后的主要内容,如果未能解决你的问题,请参考以下文章

使用 OpengL Surface 为 Android 制作游戏循环的最佳方法

使用 lockCanvas() 的 Android TextureView 硬件加速

改变游戏循环中的价值

Java中的循环和条件

如何在opengl游戏循环中使用双核?

从分离线程停止主游戏循环的最佳方法