Android内存泄露调试.docx
《Android内存泄露调试.docx》由会员分享，可在线阅读，更多相关《Android内存泄露调试.docx（14页珍藏版）》请在冰豆网上搜索。
Android内存泄露调试
Android 内存泄漏调试 一、概述 如果我们编写的代码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。
为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，即每个应用程序都是在属于自己的进程中运行的。
一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的 进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。
另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉。
Android为应用进程分配的内存上限如下所示：
位置：
/ANDROID_SOURCE/system/core/rootdir/init.rc部分脚本
```#Definetheoom_adjvaluesfortheclassesofprocessesthatcanbekilledbythekernel.#TheseareusedinActivityManagerService.
setpropro.FOREGROUND_APP_ADJ0
setpropro.VISIBLE_APP_ADJ1
setpropro.SECONDARY_SERVER_ADJ2
setpropro.BACKUP_APP_ADJ2
setpropro.HOME_APP_ADJ4
setpropro.HIDDEN_APP_MIN_ADJ7
setpropro.CONTENT_PROVIDER_ADJ14
setpropro.EMPTY_APP_ADJ15#Definethememorythresholdsatwhichtheaboveprocessclasseswillbekilled.#Thesenumbersareinpages（4k）.
setpropro.FOREGROUND_APP_MEM1536
setpropro.VISIBLE_APP_MEM2048
setpropro.SECONDARY_SERVER_MEM4096
setpropro.BACKUP_APP_MEM4096
setpropro.HOME_APP_MEM4096
setpropro.HIDDEN_APP_MEM5120
setpropro.CONTENT_PROVIDER_MEM5632
setpropro.EMPTY_APP_MEM6144#Writevaluemustbeconsistentwiththeaboveproperties.#Notethatthedriveronlysupports6slots,sowehaveHOME_APPatthesamememorylevelas
services.
write/sys/module/lowmemorykiller/parameters/adj0,1,2,7,14,15
write/proc/sys/vm/overmit_memory1
write/proc/sys/vm/min_free_order_shift4
write/sys/module/lowmemorykiller/parameters/minfree1536,2048,4096,5120,5632,6144#Setinititsforkedchildren'soom_adj.
write/proc/1/oom_adj-16
∙1
∙2
∙3
∙4
∙5
∙6
∙7
∙8
∙9
∙10
∙11
∙12
∙13
∙14
∙15
∙16
∙17
∙18
∙19
∙20
∙21
∙22
∙23
∙24
∙25
∙26
∙27
∙28
∙29
∙30
∙1
∙2
∙3
∙4
∙5
∙6
∙7
∙8
∙9
∙10
∙11
∙12
∙13
∙14
∙15
∙16
∙17
∙18
∙19
∙20
∙21
∙22
∙23
∙24
∙25
∙26
∙27
∙28
∙29
∙30
二、常见的内存使用不当的情况
（一）查询数据库没有关闭游标 描述：
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。
如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况 下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
示例代码：
Cursorcursor=getContentResolver（）.query（uri...）;if（cursor.moveToNext（））{......}
∙1
∙2
∙1
∙2
修正示例代码：
Cursorcursor=null;try{
cursor=getContentResolver（）.query（uri...）;if（cursor!
=null&&cursor.moveToNext（））{......}
}
finally{if（cursor!
=null）{try{cursor.close（）;}catch（Exceptione）{}}
}
∙1
∙2
∙3
∙4
∙5
∙6
∙7
∙8
∙1
∙2
∙3
∙4
∙5
∙6
∙7
∙8
（二）构造Adapter时，没有使用缓存的convertView 描述：
以构造ListView的BaseAdapter为例，在BaseAdapter中提高了方法：
publicViewgetView（intposition,ViewconvertView,ViewGroupparent）来向ListView提供每一个item所需要的view对象。
初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象缓存起来。
当向上滚动ListView时，原先位于最上面的listitem的view对象会被回收，然后被用来构造新出现的最下面的listitem。
这个构造过程就是由getView（）方法完成的，getView（）的第二个形参ViewconvertView就是被缓存起来的listitem的view对象（初始化时缓存中没有view对象则convertView是null）。
由此可以看出，如果我们不去使用convertView，而是每次都在getView（）中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。
ListView回收listitem的view对象的过程可以查看:
android.widget.AbsListView.Java –>voidaddScrapView（Viewscrap）方法。
示例代码：
publicViewgetView（intposition,ViewconvertView,ViewGroupparent）{
Viewview=newXxx（...）;......returnview;
}
∙1
∙2
∙3
∙4
∙1
∙2
∙3
∙4
修正示例代码：
publicViewgetView（intposition,ViewconvertView,ViewGroupparent）{
Viewview=null;if（convertView!
=null）{view=convertView;populate（view,getItem（position））;...}else{view=newXxx（...）;...}returnview;
}
∙1
∙2
∙3
∙4
∙5
∙6
∙1
∙2
∙3
∙4
∙5
∙6
（三）Bitmap对象不在使用时调用recycle（）释放内存 描述：
有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用 的时候，可以调用Bitmap.recycle（）方法回收此对象的像素所占用的内存，但这不是必须 的，视情况而定。
可以看一下代码中的注释：
/*Freeupthememoryassociatedwiththisbitmap'spixels,andmarkthe*bitmapas"dead",
meaningitwillthrowanexceptionifgetPixels（）or*setPixels（）iscalled,andwill
drawnothing.Thisoperationcannotbe*reversed,soitshouldonlybecalledifyouaresurethere
arenofurtherusesforthebitmap.Thisisanadvancedcall,andnormallyneed*notbecalled,sincethenormalGCprocesswillfreeupthismemorywhen*therearenomore
referencestothisbitmap.*/
∙1
∙2
∙3
∙4
∙5
∙6
∙1
∙2
∙3
∙4
∙5
∙6
（四）释放对象的引用 描述：
举两个例子进行说明。
示例A：
假设有如下操作
publicclassDemoActivityextendsActivity{......
privateHandlermHandler=...privateObjectobj;
publicvoidoperation（）{
obj=initObj（）;...
mHandler.post（newRunnable（）{
publicvoidrun（）{useObj（obj）;}}）;
}}
∙1
∙2
∙3
∙4
∙5
∙6
∙7
∙8
∙1
∙2
∙3
∙4
∙5
∙6
∙7
∙8
我们有一个成员变量obj，在operation（）中我们希望能够将处理obj实例的操作post到 某个线程的MessageQueue中。
在以上的代码中，即便是mHandler所在的线程使用完了 obj所引用的对象
，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。
所
以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的
引
用，而代码可以修改为：
……
publicvoidoperation（）{
obj=initObj（）;...finalObjecto=obj;
obj=null;
mHandler.post（newRunnable（）{publicvoidrun（）{useObj（o）;}}
}
∙1
∙2
∙3
∙4
∙5
∙6
∙7
∙1
∙2
∙3
∙4
∙5
∙6
∙7
示例B:
假设我们希望在锁屏界面（LockScreen）中，监听系统中的服务以获取一些信息（如信号强度等），则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。
对于LockScreen对象，当需要显示锁屏界面的时候就会创 建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。
如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。
总之当一个生命周期较短的对象A，被一个生命周期较长的对象B保有其引用的情况下，在A的生命周期结束时，要在B中清除掉对A的引用。
（五）其他 Android应用程序中最典型的需要注意释放资源的情况是在Activity的生命周期中，在onPause（）、onStop（）、onDestroy（）方法中需要适当的释放资源的情况。
由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity生命周期的介绍，以明确何时应该释放哪些资源。
三、不健壮代码的特征及解决办法
1、尽早释放无用对象的引用。
好的办法是使用临时变量的时候，让引用变量在退出活动域 后，自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。
对于仍然有指针指向的实例，jvm就不会回收该资源,因为垃圾回收会将值为null的对象 作为垃圾，提高GC回收机制效率；
2、我们的程序里不可避免大量使用字符串处理，避免使用String，应大量使用
StringBuffer，每一个String对象都得独立占用内存一块区域。
Stringstr="aaa";Stringstr2="bbb";Stringstr3=str+str2;//假如执行此次之后str,str2以后再不被调用,那它
∙1
∙2
∙3
∙4
∙1
∙2
∙3
∙4
就会被放在内存中等待Java的gc去回收,程序内过多的出现这样的情况就会报上面的那 个错误,建议在使用字符串时能使用StringBuffer就不要用String,这样可以省不少开 销；
3、尽量少用静态变量，因为静态变量是全局的，GC不会回收的；
4、避免集中创建对象尤其是大对象，JVM会突然需要大量内存，这时必然会触发GC优化 系统内存环境；显示的声明数组空间，而且申请数量还极大。
使用jspsmartUpload作文件上传,运行过程中经常出现java.outofMemoryError的 错误，检查之后发现问题：
组件里的代码
m_totalBytes=m_request.getContentLength（）;
m_binArray=newbyte[m_totalBytes];//问题原因是totalBytes这个变量得
∙1
∙2
∙1
∙2
到的数极大，导致该数组分配了很多内存空间，而且该数组不能及时释放。
5、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易 引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理， 然后解决一块释放一块的策略。
6、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。
可以适当的使用 hashtable，vector创建一组对象容器，然后从容器中去取那些对象，而不用每次new 之后又丢弃。
7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成OutOfMemoryError的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。
四、内存泄露监测工具DDMS（DalvikDebugMonitorService：
Dalvik虚拟机调试监控服务）
这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情况类似。
用Heap监测应用进程使用内存情况的步骤如下：
1.启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的。
2.将手机通过USB连接电脑，时需要确认手机是处于“USB调试”模式，而不是作 为“MassStorage”。
3.成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正 在运行的部分进程信息。
4.点击选中想要监测的进程，例讯飞输入法.iflytek.inputmethod进程。
5.点击选中Devices视图界面中最上方一排图标中的“UpdateHeap”图标。
6.点击Heap视图中的“CauseGC”按钮。
7.此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况，如图所示：
说明：
a）点击“CauseGC”按钮相当于向虚拟机请求了一次GC操作； b）当内存使用信息第一次显示以后，无须再不断的点击“CauseGC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化。
如何才能知道我们的程序是否有内存泄漏的可能性呢。
这里需要注意一个值：
Heap视图 中部有一个Type叫做dataobject，即数据对象，也就是我们的程序中大量存在的类类型的对象。
在dataobject一行中有一列是“TotalSize”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。
可以这样判断：
a）不断的操作当前应用，同时注意观察dataobject的TotalSize值； b）正常情况下TotalSize值都会稳定在一个有限的X围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平； c）反之如果代码中存在没有释放对象引用的情况，则dataobject的TotalSize值在每次GC后不会有明显的回落，随着操作次数的增多TotalSize的值会越来越大，直到到达一个上限后导致进程被kill掉。
五、内存泄露分析工具MAT（MemoryAnalyzerTool）
MAT是一个Eclipse插件，官方下载地址：
download.eclipse.org/mat/1.1/update-site/。
（一）生成.hprof文件
1.打开eclipse并切换到DDMS透视图，同时确认Devices、Heap和LogCat视图已经打开。
2.将手机设备到电脑，并确保使用“USB调试”模式，而不是“MassStorage“模式。
3.成功后在Devices视图中就会看到设备的序列号，和设备中正在运行的部分进程。
4.点击选中想要分析的应用的进程，在Devices视图上方的一行图标按钮中，同时选中“UpdateHeap”和“DumpHPROFfile”两个按钮。
此时DDMS工具将会自动生成当前选中进程的.hprof文件，如图所示：
（二）使用MAT导入.hprof文件
在Eclipse中点击Windows->OpenPerspective->Other->MemoryAnalyzer，或者打MemoryAnalyzerTool的RCP。
在MAT中点击File->OpenFile，浏览并导入刚刚转换而得到的.hprof文件。
（三）使用MAT的视图工具分析内存
1.导入.hprof文件以后，MAT会自动解析并生成报告，点击DominatorTree，并按Package分组。
2.选择自己所定义的Package类点右键，在弹出菜单中选择Listobjects->Withiningreferences。
这时会列出所有可疑类，右键点击某一项，并选择PathtoGCRoots-> excludeweak/softreferences，会进一步筛选出跟程序相关的所有有内存泄露的类。
据此，可以追踪到代码中的某一个产生泄露的类。
总之使用MAT分析内存查找内存泄漏的根本思路，就是找到哪个类的对象的引用没有被释放，找到没有被释放的原因，也就可以很容易定位代码中的哪些片段的逻辑有问题了。
如上图所示，“ProblemSuspect”均有可能是代码中存在内存泄露的地方。
升级会员 