《android项目内存泄露排查》由会员分享，可在线阅读，更多相关《android项目内存泄露排查（6页珍藏版）》请在装配图网上搜索。
1、现象一：项目XXX在真机或者模拟器上操作一段时间后，应用突然黑屏然后恢复界面，但是Applilca tion中保存的全局变量全部丢失。排査步骤：1. 检查 logcat 日志，没有发现从项目 XXX 代码抛出的异常，只发现一条：INFO/ActivityManager(209): Process com.xxx (pid 18396) has died.说 明进程死掉了，应用被重启了，所有类都被初始化。初步推测是内存泄漏导致进程被kill 了。2排查内存泄漏，打开ddms, update heap视图，然后测试应用。最终发现在某两个界面来回切换时，heap堆空间占用会持续增长，最终进程重启。3
2、打开ddms中的upda teheap视图，重复切换问题页面，当发现heap快被撑爆时生成dump文件。用MAT分析，发现自定义的Applica tion对象中有个 List聚集了大量的某个Act ivi ty的Con text引用，导致该很多Activity占用的heap内存泄漏，修改代码后该泄漏点解决，再测试时候打开upda teheap 视图监测heap内存占用情况，一切正常。总结：l. Application对象的生命周期与整个App的生命周期一致，可以用来存放全局变量，但是注意不要引起内存泄露。2系统给应用的heap堆内存是动态分配的，不够了会增加，但是有上限，约24MB。如果长时间
3、低于30%左右used,堆内存会被系统回收一部分。现象二：上一次heap堆内存泄漏解决后没过两天，测试发现同样是上一次的两个activity来回切换，在android2.3.5上会进程重启，而android4.0.3 上一切正常。排査步骤：1. 分别在android2.3.5和android4.0.3上监测heap使用情况，来回切换问题页面，发现heap堆内存使用情况一切正常，内存使用率都稳定在50%左 右。但是在andorid2.3.5上如此操作一段时间后进程会重启，但是在android4.0.3上不会重启，这次感觉不像是内存泄漏。2. 上网搜索后无果，项目组开始考虑用其它方式来保存全局的共
4、享数据，准备使用Sqlite （要注意序列化与反序列化的问题）或者SharedPreferences （不能保存对象）来保存数据，但发现都不靠谱。Android官方是推荐使用Application来保存全局对象的，这种数据共享方式应该不存在问题的，所以还是回归到分析问题本质的路线上来。3分别取得android2.3.5和4.0.3上的heap dump，用mat对比分析发现都不存在内存泄漏。问题陷入僵局，试着开始研究andorid的内存管理机制， 每个android应用对应有一个自己的Dalvik VM,而每个Dalvik VM的Instance都对应于Linux内核中的一个进程。androi
5、d应用会使用两部分空 间，native和heap。Dalvik VM负责管理堆内存，与应用产生的垃圾对象的gc,所以ddms上只能看到Dalvik虚拟机使用的heap堆内存，看不到虚拟 机宿主的linux进程所使用的native堆的情况。Native所用的空间由linux统一管理，实现各个进程共享使用的，主要是JNI调用C会使用到。4. 在android2.3.3下测试应用，然后执行adb shell dumpsys meminfo com.xxx应用包名），看到系统为进程分配了大量的nat ive空间，反复切换问题 页面后native空间占用迅速增加，发现有一个arial. ttf字体文件被
6、多次创建，且不释放io st ream资源，如下图：Hasize : allocated: free : : dirtv: dirtp：nativedaluikothertotal498525959N/A55811495392687N/fi522263123272N/A358431021795470225191922201868493690242776484508447908Objec twUiews:0UiewRoots:AppContex:0Retiuitiew:Assets :120As set Managers :Local Binders:6Proxy Binders:Death R
7、ec ipients:1OpenSSL Sockets:0SQLMEMOR_USED： MALLOC_SIZE:0000heap： PA GECA CH E_OU ERFLOW:Csharedd. exe410 0 02in vi ini c m359K359K359K359K359K 359K 359K 2匚ftsset fillocat ionszip: Zdata/app/com. test-2 .apk: ZresoLirees . arse : 1Hzip: Zdata/app/com. test一2 .apk: /assets/f ont/arial. ttf : zip: Zda
8、ta/app/con. test-2 .apk: Zassets/Font/arial. ttf : zip: Zdata/app/con test2 .apk: Zassets/f ont/arial tt ： zip:Zdata/app/com test-2 .apk:Zassets/font/arial.ttf : zip: Zdata/app/con. test一2 .apk:Zassets/f ont/arial. ttF : zip:Zdata/app/con. test-2 .apk：Zassets/f ont/arial. 1: zip:Zdata/app/com test-2
9、 .apk:Zassets/Font/arial.ttf : Xtfl zi#- /o o 4- O =krw mt 5. 在android4.0.3下测试应用，然后监控native空间使用情况，发现反复切换问题页面的时候。arial. ttf会被分配很多次，native占用也会突然增 加，但是很快native分配的空间会被释放。6. 以上测试说明在使用自定义字体时候，android2.3.5会泄漏native空间。上网搜索发现这个bug是JNI调用C泄漏了 native内存(相关资料： android2.3.5 平台上，每次 Typeface.createFromAsset 的时候就会 泄漏
10、一次ttf字体文件操作的io st ream，因为项目界面统一使用了这个自定义字体，所以很快就可以泄漏几百MB na tive空间，导致进程被linux管 理机制给强行kill。7. 修改代码，问题解决。workaround的做法是将Typeface缓存，不要每次都执行Typeface.crea teFromAsse t.即能避免android2.3及以下平台上的这个 bug,又可以提高使用效率，不用每次渲染组件的时候都去创建新的字体文件。总结：1. android应用会使用两部分空间，native空间和heap堆。Dalvik Vm负责管理自己的heap堆内存，与应用产生的垃圾对象的gc, ddms上只能看到Dalvik 虚拟机对应的heap堆内存；native所用的空间由linux统一管理，实现各个进程共享使用的，主要是JNI调用C会使用到,ddms看不到native堆的情况。2. native堆空间可以一直耗光设备的所有可用的RAM,在小米手机(android2.3.5 1G RAM)上，字体泄露的问题可以消耗掉600多MB native空间，然后 设备实在没有可用空间分配了就会杀掉占用最多空间的应用。
android项目内存泄露排查
