Android 中的堆栈内存
我正在编写一个应用程序，它具有前台服务、内容提供程序和活动前端，该前端绑定到服务并使用 AIDL 返回对象列表。该服务确实工作并更新数据库。
如果我将活动打开 4-8 小时以上，然后转到手机 (Nexus One) 设置下的“运行服务”部分，则会显示正在使用的内存量异常大（~42MB）。
我认为有泄漏。当我检查堆内存时，我得到堆大小：~18MB，~2MB 已分配，~16MB 空闲。分析 Eclipse MAT 中的 hprof 似乎没问题，这让我推断堆栈上存在内存泄漏。这可能吗？如果是，我可以采取什么措施来阻止或调查泄漏？ android 的“运行服务”部分报告的内存使用情况是否正确（我认为是）？
另请注意：当 UI 未启动时（仅运行服务），我无法重现此问题
I'm writing an app that has a foreground service, content provider, and a Activity front end that binds to the service and gets back a List of objects using AIDL. The service does work and updates a database.
If I leave the activity open for 4-8+ hours, and go to the "Running Services" section under settings on the phone (Nexus One) an unusually large amount of memory being used is shown (~42MB).
I figure there is a leak. When I check the heap memory i get Heap size:~18MB, ~2MB allocated, ~16MB free. Analyzing the hprof in Eclipse MAT seems fine, which leads me to theorize that memory is leaking on the stack. Is this even possible? If it is, what can I do to stop or investigate the leak? Is the reported memory usage on the "Running Services" section of android even correct (I assume it is)?
Another note: I have been unable to reproduce this issue when the UI is not up (with only the service running)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果这只是一个应用程序，请摆脱 AIDL 并摆脱内容提供程序。或者，至少，不要自己使用它们——这些是供其他应用程序使用的。它们增加了您自己的虚拟机中不需要的开销。
并不真地。主应用程序线程堆栈非常小。其他线程的堆栈可能会变得更大，但如果您以这种方式消耗 42MB，我会感到惊讶。
由于您已经完成了无 UI 测试的“尖峰解决方案”并确定这是可以的，因此我会慢慢地重新引入 UI，看看您何时开始遇到问题。一个可能的候选问题领域是从后台线程更新活动，因此您可以将其关闭并看看会发生什么。
由于您的问题不在堆本身，我的猜测是您的问题与位图或其他具有大量堆外 RAM 使用量的东西有关。你头像中的相机是这个方向的另一个暗示。 :-) 确保你正在
recycle()-ing你的位图等，看看这是否有帮助。If that's all just one application, get rid of the AIDL and get rid of the content provider. Or, at least, don't use them yourself -- those are for other applications to use. They add overhead that you do not need for stuff inside your own VM.
Not really. The main application thread stack is trivially small. Other threads have stacks that could get a lot bigger, but I'll be surprised if you are chewing up 42MB that way.
Since you already did a "spike solution" of testing sans UI and determining that is OK, I'd slowly reintroduce the UI and see when you start getting the problem. One likely candidate problem area would be updating the activity from a background thread, so you might turn that off and see what happens.
Since your problem isn't in the heap itself, my guess is that your problem is tied to bitmaps or other things that have lots of off-heap RAM usage. The camera in your avatar is another hint in this direction. :-) Make sure you are
recycle()-ing your bitmaps and such, and see if that helps any.