内存泄漏专题分析

最新推荐文章于 2024-08-21 16:43:46 发布

Jarry_le

最新推荐文章于 2024-08-21 16:43:46 发布

阅读量3.1k

点赞数

本文链接：https://blog.csdn.net/u011677209/article/details/52778074

版权

本文详细分析了一次内存泄漏问题，通过dumpsys和procrank工具观察到Launcher内存持续增长，主要由Ashmem占用。开启mmap调试发现SoundPoolThread可能存在的泄漏，但实际上并非泄漏，而是由于mmap debug机制的限制无法检测到ashmem的释放。进一步分析揭示，真正的泄漏源头在于MemoryHeapBase的申请未释放，问题的根本原因在于客制化代码错误导致sound resource无法释放。解决方案是修复相关代码。

摘要由CSDN通过智能技术生成

问题背景

用Launcher跑monkey时存在泄露，2个小时USS从65M涨到205

分析过程

打开debug 15复测，adb shell dumpsys meminfo查看launcher memory用量如果大于300M时，
(1)adb shell dumpsys meminfo <pid> 抓取一份launcher memory使用信息
(2)adb shell kill -11 <pid>生成DB
将memory信息和mtklog 一起提供过来。

在测试中用procrank查看uss一直在涨，但用dumpsys meminfo查看Native heap和Dalvik Heap，都涨的很慢，Native heap一直没有涨到128M ：

用procrank抓取的信息如下，USS已经到达250M：
C:\Windows\System32>adb shell procrank | findstr launcher3
1698 2801540K 368192K 257240K 250476K com.android.launcher3

用dumpsys抓取的信息如下：
C:\Windows\System32>adb shell dumpsys meminfo 1698
Applications Memory Usage (kB):
Uptime: 12807842 Realtime: 21690528

** MEMINFO in pid 1698 [com.android.launcher3] **
Pss Private Private Swapped Heap Heap Heap
Total Dirty Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------
Native Heap 29363 28016 0 0 78080 70795 7284
Dalvik Heap 7911 7768 0 0 64595 61187 3408
Dalvik Other 43303 43072 0 0
Stack 1244 1244 0 0
Ashmem 155002 154972 0 0
Other dev 4 0 4 0
.so mmap 2307 516 92 0
.apk mmap 1454 0 96 0
.ttf mmap 106 0 28 0
.dex mmap 1112 4 1108 0
.oat mmap 923 0 116 0
.art mmap 3106 2804 24 0
Other mmap 32 8 0 0
EGL mtrack 7989 7989 0 0
GL mtrack 44356 44356 0 0
Unknown 11308 10660 0 0
TOTAL 309520 301409 1468 0 142675 131982 10692

从dump出来的memory info可以看到，总共309520，也即300多M，其中 Ashmem 155002 ，就占了151M，这个应该才是leak的原因。