FPS限制 - 如何使手机的更新/绘制周期更加平滑？

Question

我正在为Android手机构建一个应用程序，但遇到了一些奇怪的“节流”现象。我认为这是因为调用了信号量来停止应用程序处理手机内部其他任务。虽然我不确定。

我想知道是否有一种方法可以将这些中断分散或其他方法使其对用户不太明显，从而减少应用程序出现小的延迟峰值。

编辑：进一步说明，我目前正在运行一个二维图像数组 - 每次只绘制约80个实例化的8000个图像。它们仅在其颜色色调不是RGB0（深黑色）时绘制。更新中的运行时循环检查哪些图像最接近玩家，并为它们提供基本的最小照明RGB 0.2f。除此之外，更新中还包括基本事件处理程序和移动/视口循环。请注意，我使用的是Libgdx框架，而不是Android本地框架。因此，涉及OpenGL等等。

编辑：我想指出问题不是你想象中的那样。我每次渲染都会发送一个Vector2约3800次，但不仅仅是“发送”一个，而是声明新的Vector2并以这种方式发送参数。垃圾收集器无法容忍这种暴行。现在我只发送了2个浮点数，所以运行顺畅了。我的错。._.

- Remm

Answer 1

除非同时运行多个活动进程，否则不应该发生这种情况。

我的猜测（没有看到代码）是垃圾回收器工作过于频繁。您是否在循环中初始化对象？如果是，请尝试重用对象。

对象可以是任何东西，特别是视图。确保重用您的视图而不是创建新的视图。

另一个要考虑的问题是完整布局重绘：您能否只重新绘制屏幕的一部分而不是全部？（即使用view.invalidate(rect);而不是view.invalidate();）

最后，您的布局是否太深？尽量使它们尽可能平坦。例如，使用RelativeLayout而不是嵌套的LinearLayouts。

花些时间观看这个视频：Romain Guy's Google I/O 2009 talk。有很多信息可以从中获取。 更新后，我看到您需要绘制8K张图片。如果您实例化所有图片，很可能内存中没有足够的空间来存储其他内容，因此垃圾回收器将需要不断地回收任何可回收的内容。这意味着会减缓整个系统的速度。在同一视频中，请查看大约53-55分钟的问答部分。他建议，在您这种情况下，将所有位图引用放入软引用的HashMap中，以便垃圾回收器在需要时回收未使用的图像。这将防止回收其他任何内容。我还建议根据需要批量实例化它们，而不是在开始时全部实例化。

- Aleadam

---

初始化之后，没有创建任何东西。只是使用已经放置好的内容。如果我有太多方法级别的变量 - 奇怪的 int 或 String - 这会减慢速度吗？虽然我不认为会有足够的变量来造成如此大的差距。 - Remm

@Remm 我认为任何数量的整数都不会成为问题。我将详细解释一下答案。 - Aleadam

遗憾的是，布局方面的东西或多或少不适用。你说的视图是指共享内存吗？目前没有使用共享内存。不过视频很棒，我一定会看的。 - Remm

@Remm 那是在你更新之前的事了。我在那里又添加了几个想法。 - Aleadam

Answer 2

如果您在UI绘制/更新中看到延迟，那么您可能正在UI线程上执行一些长时间运行的进程（网络、数据库、媒体、位图解码）。

您应该在后台线程上执行长时间运行的任务。为此，请使用AsyncTask。

- Peter Knego