我正在为安卓手机构建一个应用程序，并遇到了一些奇怪的"节流"。我相信这是因为信号灯被调用来停止应用程序正在执行的任何操作以处理手机中的其他内容。虽然我不是肯定的。
我很好奇是否有一种方法可以分散这些突破或其他方法，让用户不那么明显地看到该应用程序几乎没有延迟峰值。
编辑：一些进一步的信息，我目前正在运行的是图像的 2d 数组 - 在实例化 ~8000 中一次只绘制大约 80 个。他们只在颜色不是RGB0（漆黑）时绘制。更新中的运行时循环检查哪些图像最接近播放器，并为其提供 RGB 0.2f 的基本最小照明。除此之外，更新中还包含基本事件处理程序和移动/视口循环。请注意，我使用的是 Libgdx 框架，而不是 android 原生的。所以OpenGL等
编辑：我想指出，问题不在于你想象的那样。我发送的 vector2 大约是渲染的 3800 次 - 但不仅仅是"发送"一个，而是声明新的 Vector2 并以这种方式发送参数。垃圾收集者不会容忍这种暴行。现在运行顺利，因为我只发送了 2 个浮标。我的坏._。
除非有多个活动进程同时运行，否则不应发生这种情况。
我的猜测（没有看到代码）是垃圾收集器踢得太多了。您是否在循环中初始化对象？如果是这样，您可以重用这些对象吗？
对象可以是任何东西，特别是视图。确保重复使用视图，而不是创建新视图。
要考虑的另一点是完整的布局重绘：您可以只重绘屏幕的一部分而不是全部吗？（即，使用view.invalidate(rect);而不是view.invalidate();）
最后，你的布局是否太深了？尽量让它们变得平坦。例如，使用 RelativeLayout 而不是嵌套LinearLayouts 。
花点时间观看此视频：Romain Guy的Google I/O 2009演讲。从那里可以获得很多信息。
更新后，我看到您有8K图像要绘制。如果您实例化所有这些，则内存中很可能没有太多空间容纳其他任何东西，因此 GC 将需要不断收集任何可能的内容。这意味着，减慢整个系统的速度。在同一视频中，查看大约53-55分钟的问答。他建议，在像你这样的情况下，将所有对位图的引用都放在软引用的 HashMap 中，这样 GC 就可以在需要时收集未使用的图像。这将阻止收集其他任何东西。我还会根据需要批量实例化它们，而不是在开始时全部实例化。
绘制/更新中看到滞后，则您可能正在 UI 线程上执行一些长时间运行的过程（网络、数据库、媒体、位图解码）。
您应该在后台线程上执行长时间运行的任务。为此，请使用 AsyncTask。