我正在为 android Phone 构建一个应用程序，并且正在经历一些奇怪的“节流”。我相信这是因为正在调用信号量来停止应用程序正在执行的处理电话中其他内容的任何操作。虽然我不积极。
我很好奇是否有办法传播这些突破或其他方式，以使用户不那么容易看到应用程序几乎没有滞后尖峰可以这么说。
编辑：一些进一步的信息，我目前正在运行的是一个二维图像数组 - 在实例化〜 8000 时只绘制了大约 80 个。只有当他们的颜色不是 RGB0（黑色）时，他们才会绘制。更新中的运行时循环检查哪些图像最接近播放器，并为它们提供 RGB 0.2f 的基本最小照明。除此之外，基本事件处理程序和移动/视口循环也在更新中。请注意，我使用的是 Libgdx 框架，而不是 android native。所以OpenGL等
编辑：我想指出问题不是你想的那样。我发送了大约 3800 次渲染的 vector2 - 但不仅仅是“发送”一个，而是声明新的 Vector2 并以这种方式发送参数。垃圾收集器不会容忍这种暴行。现在我只发送 2 个浮点数，运行顺利。我的错 。_。
除非有多个活动进程同时运行，否则不应发生这种情况。
我的猜测（没有看到代码）是垃圾收集器太多了。您是否在循环中初始化对象？如果是这样，您可以重用这些对象吗？
对象可以是任何东西，特别是视图。确保您重复使用您的视图而不是创建新视图。
要考虑的另一点是完整的布局重绘：您可以只重绘屏幕的一部分而不是全部吗？（即，使用view.invalidate(rect);而不是view.invalidate();）
最后，你的布局是不是太深了？尽量把它们弄平。例如，使用RelativeLayout而不是嵌套LinearLayouts。
花点时间观看此视频：Romain Guy 的 Google I/O 2009 演讲。很多信息可以从那里得到。
更新后，我看到你有 8K 图像要绘制。如果您将它们全部实例化，则很可能内存中没有太多空间可以容纳其他任何东西，因此 GC 将需要不断收集它可以收集的任何东西。这意味着，减慢整个系统的速度。在同一视频中查看大约 53-55 分钟的问答。他建议，在像您这样的情况下，将所有对位图的引用都放在软引用的 HashMap 中，这样 GC 可以在需要时收集未使用的图像。那将阻止收集其他任何东西。我还会根据需要分批实例化它们，而不是一开始就全部实例化。
If you see lags in UI draw/update then you are possibly doing some long running process (network, database, media, bitmap decoding) on the UI thread.
You should do long-running tasks on a background thread. Use AsyncTask for that.