Android DDMS 和分配跟踪 - 识别导致 GC 触发的原因以及原因

Question

下午好。

我一直在为 android 制作一个基于 openGL 的小型应用程序，它以正常的 60 fps 循环并执行各种奇妙的事情。

我一直在关注我的帧速率，并在我前进的过程中尽可能地进行优化。我最近注意到，当我的程序运行时，有时会出现轻微的停顿。我立即怀疑可能是垃圾收集器在运行，在 LogCat 中查看时，在 fps 下降的时候出现了一些可疑的 GC。

但是我不确定是否是我的应用导致了收集。

以下是我关于 GC 的问题：

1) 当我从 LogCat 获取日志记录时，它包含一个 PID（进程 ID？），这是我收到的典型 GC 示例：

12-14 14:52:40.647: DEBUG/dalvikvm(492): GC_EXPLICIT freed 3831 objects / 203576 bytes in 32ms

492 是 PID。这个 PID 会属于执行 GC 的进程吗？还是手机上运行的进程也需要 GC？

例如，来自同一会话的日志来自我的应用程序使用 Log.debug：

12-14 13:50:42.717: DEBUG/Curve(2298): LIFECYCLE - OnStart

我的应用程序的 PID 不是 492，而是 2298。这是否意味着 GC 不是由于我的应用程序造成的？

使用分配跟踪器，我很少发生分配。几行日志记录导致生成一些字符串，并且在用户按下时偶尔会生成 Rect（我已经修复了这个问题，所以它现在只会分配一次......）所以我看不到我的应用程序本身将如何生成需要 GC。

2) 如果不是我的应用程序在分配内存，而只是其他进程正在愉快地占用内存，那么它是否会影响我的应用程序？

3) 我使用 ddms 的事实会导致 GC 吗？

4) 当我查看分配跟踪器时，有一些条目不是来自我自己运行/经历的任何代码。其中之一与线程统计有关，这可能是 ddms 吗？

对不起，如果这真的是几个问题，但这都与我在 Logcat 中看到的 GC 日志是否真的来自我的应用程序有关。

请记住，目前我的手机没有运行我的应用程序，并且我仍然得到了 5 - 15 秒的小型 GC。这些通常运行 33 毫秒，并且似乎内存量很小。所以我想这意味着他们不是因为我。 - 再次基本上是关于 PID 及其显示的内容。

Answer 1

您在 1) 上是正确的。只有一部分 GC 日志记录 Logcat 属于您的应用，并且具有您应用的 pid。

打嗝很可能是由于后台服务请求少量分配。我建议您对游戏中帧之间的增量时间应用低通滤波器，或限制最大 FPS 以获得整体更流畅的体验。即使在 iOS 上，让您的游戏以 60FPS 的速度运行而最终不出现故障也是极其困难的。