FPS限制(?) - 使手机的更新/绘制周期更平滑?

时间:2011-05-14 21:25:12

标签: java android opengl-es frame-rate libgdx

我正在为Android手机构建一个应用程序,并且正在经历一些奇怪的“限制”。我相信这是因为正在调用信号量来停止应用程序正在做的任何事情来处理手机中的其他内容。虽然我不是积极的。

我很好奇是否有办法传播这些突破或其他内容,以使用户看不到应用程序可以说话的延迟很少。

编辑:一些进一步的信息,我目前正在运行的是一个二维图像阵列 - 在实例~8000时只绘制了大约80个图像。如果它们的颜色不是RGB0(漆黑),它们只会绘制。更新中的运行时循环检查哪些图像最接近播放器,并为它们提供RGB 0.2f的基本最小照明。除了基本事件处理程序和移动/视图端口循环在更新中。请注意,我使用的是Libgdx框架,而不是android native。所以OpenGL等等

编辑:我想指出问题不是你认为的那样。我发送了一个大约3800次渲染的vector2 - 但不仅仅是'发送'一个,而是声明新的Vector2并以这种方式发送参数。垃圾收集者不会容忍这种不确定性。现在我只发送2个花车,运行顺利。我的坏._。

2 个答案:

答案 0 :(得分:4)

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

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

对象可以是任何东西,特别是视图。确保重复使用视图而不创建新视图。

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

最后,您的布局是否太深?尽量让它们尽量平坦。例如,使用RelativeLayout而不是嵌套LinearLayouts

花一些时间观看此视频:Romain Guy's Google I/O 2009 talk。从那里获得大量信息。

更新后,我看到您要绘制8K图像。如果你实例化所有这些内容,那么内存中没有太多空间用于其他任何事情,因此GC需要不断收集它所能做的任何事情。这意味着,减慢整个系统。在大约53-55分钟的同一视频中查看Q& A.在像你这样的情况下,他建议在软引用的HashMap中对位图进行所有引用,这样GC就可以在需要时收集未使用的图像。这会阻止收集任何其他东西。 我也会根据需要分批实例化它们,而不是在开始时全部实现它们。

答案 1 :(得分:0)

如果您在UI绘制/更新中看到滞后,那么您可能正在UI线程上执行一些长时间运行的过程(网络,数据库,媒体,位图解码)。

您应该在background thread上执行长时间运行的任务。请使用AsyncTask