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

我正在为Android Phone构建应用程序,并且遇到了一些奇怪的“限制”.我相信这是因为调用信号灯是为了终止应用程序为处理电话中其他内容所做的任何操作.虽然我不是很积极.

我很好奇,是否有一种方法可以传播这些突破,或者通过其他方式使用户看不到该应用程序可以说的滞后峰值.

编辑：一些进一步的信息,我当前正在使用的是2d图像数组-实例化的〜8000一次仅绘制了约80个.它们仅在其色度不是RGB0(深黑色)的情况下才绘制.更新中的运行时循环检查哪些图像最接近播放器,并为它们提供RGB 0.2f的基本最小照明.除此以外,基本事件处理程序和移动/查看端口循环都在更新中.请注意,我使用的是Libgdx框架,而不是android native.所以OpenGL等

编辑：我想指出的是问题不是您想的那样.我发送的vector2大约是渲染的3800倍-但不仅仅是“发送”一个,而是声明新的Vector2并以这种方式发送参数.垃圾收集器将不容忍这种暴行.现在,我只发送了2个浮点数,因此运行平稳​​.我的错 ._.

解决方法:

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

我的猜测(没有看到代码)是垃圾收集器投入过多.您是否正在循环初始化对象？如果是这样,您可以重用对象吗？

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

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

最后,您的布局太深了吗？尽量使它们平整.例如,使用RelativeLayout而不是嵌套的LinearLayouts.

花点时间看一下这个视频：Romain Guy’s Google I/O 2009 talk.从那里可以获得很多信息.

更新后,我看到您要绘制8K图像.如果您实例化所有实例,那么很可能内存中没有足够的空间容纳其他任何东西,因此GC将需要连续收集所有可能的东西.这意味着减慢整个系统的速度.在大约53-55分钟的同一视频中,查看问题与解答.他建议在像您这样的情况下,在软引用的HashMap中拥有对位图的所有引用,以便GC可以在需要时收集未使用的图像.那会阻止收集其他任何东西.
我还将根据需要分批实例化它们,而不是一开始就全部完成.

标签：frame-rate,opengl-es,libgdx,java,android
来源： https://codeday.me/bug/20191102/1992874.html