java - FPS 节流(？)- 使手机的更新/绘图周期更顺畅？

Question

我正在为 Android Phone 构建应用程序，但遇到了一些奇怪的“节流”。我相信这是因为正在调用信号量来停止应用程序正在做的任何事情来处理手机中的其他内容。虽然我不是积极的。

我很好奇是否有一种方法可以分散这些中断或其他方法来减少用户对应用程序几乎没有延迟尖峰的可见性。

编辑:一些进一步的信息，我目前正在运行的是一个二维图像数组——在实例化 ~8000 的时候只绘制了大约 80 个图像。只有当它们的色调不是 RGB0(深黑色)时，它们才会绘制。更新中的运行时循环会检查哪些图像最接近玩家，并为它们提供 RGB 0.2f 的基本最小光照。除此之外，基本的事件处理程序和移动/视口(viewport)循环也在更新中。请注意，我使用的是 Libgdx 框架，而不是 android native。所以 OpenGL 等等等等

编辑:我想指出的是，问题并不是您想象的那样。我发送一个 vector2 大约 3800 次渲染 - 但不仅仅是“发送”一个，而是声明新的 Vector2 并以这种方式发送参数。垃圾收集器不会容忍这种暴行。现在我只发送 2 个 float ，运行顺利。我的坏._.

Answer 1

除非有多个 Activity 进程同时运行，否则这不应该发生。

我的猜测(没有看到代码)是垃圾收集器 踢得太多了。你在循环中初始化对象吗？如果是这样，您可以重用这些对象吗？

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

要考虑的另一点是完整布局重绘:您可以只重绘屏幕的一部分而不是全部吗？ (即，使用 view.invalidate(rect); 而不是 view.invalidate();)

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

花点时间观看这个视频:Romain Guy's Google I/O 2009 talk .从那里可以获得很多信息。

更新后，我看到你有8K的图片要画。如果您将它们全部实例化，很可能内存中没有太多空间用于其他任何东西，因此 GC 将需要不断地收集它可以收集的任何东西。这意味着，减慢整个系统。在同一视频中查看大约 53-55 分钟的问答。他建议，在像您这样的情况下，将所有对位图的引用都放在软引用的 HashMap 中，以便 GC 可以在需要时收集未使用的图像。这将阻止收集任何其他东西。我还会根据需要分批实例化它们，而不是一开始就全部实例化。