Android DDMS 和分配跟踪 - 确定导致 GC 触发的原因及其原因
下午好。
我一直在为 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 不是由我的应用程序引起的？
使用分配跟踪器，我发生的分配很少。几行日志记录导致生成一些字符串，并且偶尔在用户按下时生成矩形（我已经修复了这个问题，所以现在只会分配一次......）所以我看不到我的应用程序本身将如何生成需要GC。
2）如果不是我的应用程序分配掉，而只是其他一些正在愉快地占用内存的进程，它是否会影响我的应用程序？
3) 我使用 ddms 的事实是否会导致 GC？
4）当我查看分配跟踪器时，有一些条目并非来自我自己运行/执行的任何代码。其中之一与线程统计相关，这可能是 ddms 吗？
抱歉，如果这确实是几个问题，但这都与我在 Logcat 中看到的 GC 日志是否实际上来自我的应用程序有关。
请记住，目前我的手机未运行我的应用程序，并且我仍然会收到 5 - 15 秒的小型 GC。这些通常运行 33 毫秒，并且看起来内存量相当小。所以我想这意味着它们不是我造成的。 - 再次基本上是关于 PID 及其显示的内容。
Good afternoon.
I have been making a small openGL based app for android that loops at the normal 60 fps and does various wondrous things.
I have been keeping an eye on my frame rate and trying to optimise where possible as I am going along. I recently noticed that whilst my program is running sometimes there will be a slight pause. I immediatly suspected that it might be the Garbage Collector running and looking in LogCat there were a few suspect GC's appearing around the times of the dips in fps.
However I am unsure if it is my app that is causing the collects.
So these are my questions about the GC:
1) When I get logging from LogCat it contains a PID (process id?) and here is an example of a typical GC i receive:
12-14 14:52:40.647: DEBUG/dalvikvm(492): GC_EXPLICIT freed 3831 objects / 203576 bytes in 32ms
The 492 is the PID. Is this PID going to be of the process that performs the GC? Or is it a process running on the phone that is also needing a GC?
For example from the same session here is a log from my app using Log.debug:
12-14 13:50:42.717: DEBUG/Curve(2298): LIFECYCLE - OnStart
The PID for my app is not 492, it is 2298. Does this mean the GC was not due to my app?
Using the allocation tracker I have very few allocations occuring. A few lines of logging causing some strings to be generated and the occasional Rect being generated on a user press (I have fixed this so it will only be allocated once now...) So I cannot see how my app itself will be generating the need for GC's.
2) If it is not my app allocating away and is simply some other process that is eating into memory happily should it affect my app at all?
3) Could the very fact I am using the ddms be causing GC's?
4) When I look in to the allocation tracker there are some entries which do not come from any code that I am running / going through myself. One of which was related to thread stats, could this be the ddms?
Sorry if this is really several questions but it is all related to really whether the GC logs I see in my Logcat are actually from my application or not.
Bearing in mind that at the moment my phone is sat not running my app and I am still getting small GC's 5 - 15 seconds. These normally run for 33ms and seems quite small amounts of memory. So I guess this means they are not due to me. - Again basically about the PID and what that shows.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你在1）上是正确的。只有 GC 日志 Logcat 的一个子集属于您的应用程序，并且这些子集具有您应用程序的 pid。
出现问题很可能是由于后台服务请求少量分配造成的。我建议您对游戏中帧之间的时间差应用低通滤波器，或者限制最大 FPS，以获得整体更流畅的体验。即使在 iOS 上，让游戏以 60FPS 运行而不出现任何问题也是极其困难的。
You are correct on 1). Only a subset of the GC logs ing Logcat belong to your app, and those have your app's pid.
Most likely the hiccups are due to background services requesting small allocations. I'd suggest you apply a low-pass filter to the delta time between frames in your game or cap the maximum FPS for an overall smoother experience. Even on iOS it's extremelly difficult to have your game running at 60FPS without eventual hiccups.