java - 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？

例如，来自同一个 session ，这里是我的应用程序使用 Log.debug 的日志:

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

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

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

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

3) 我正在使用 ddms 的事实是否会导致 GC？

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

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

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

Answer 1

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

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