当前位置: 代码迷 >> Android >> Android内存泄漏监测(MAT)及解决方法
  详细解决方案

Android内存泄漏监测(MAT)及解决方法

热度:51   发布时间:2016-04-28 02:44:37.0
Android内存泄漏监测(MAT)及解决办法
http://ttlnews.blogspot.com/2010/01/attacking-memory-problems-on-android.html 

这篇文章是2010年1月份写的,其中有些已经不适合现在的Android机制了 

我将内存问题分为两种:OOM和堆栈溢出 
一个Android进程可以分配的最大堆内存(heap memory)为 16M(现在各个定制版本的Android系统都不一样)

如果你将重复打开关闭一个Activity20次,就有可能出现内存溢出,那么在哪里内存溢出了,在哪里可以被GC回收? 

adb shell procrank 
使用这个命令可以获得一些应用的内存数据,但是只能获取很简单的数据 

adb shell dumpsys meminfo 
使用这个命令可以得到更多相关数据 

如果想要了解更多关于内存分配和回收的细节就需要 Eclipse Memory Analyzer Tool (MAT)工具。 
MAT工具使用方法:
 
MAT可以显示的内容
 
 

最佳实践:

1.在onDestroy()中最好将匿名listeners都设置为null,比如view.setOnClickListener(null) ; 

2.即使没有静态drawable变量,但drawable对象中引用了view,view对象引用了Context,所以Activity可能会泄漏;

//Android源码片段   Drawable对象中引用View对象
public class View implements Drawable.Callback, KeyEvent.Callback, AccessibilityEventSource { public void setBackgroundDrawable(Drawable background) { ..... background.setCallback(this); ...... } } public abstract class Drawable { public final void setCallback(Callback cb) { mCallback = new WeakReference<Callback>(cb); } } 

所以最好在 onDestroy() 中调用view.getBackground().setCallback(null); 
在stackoverflow的相关问答中出现了通用的unbindDrawables方法 
http://stackoverflow.com/questions/9461364/exception-in-unbinddrawables 

@Override protected void onDestroy() { super.onDestroy(); unbindDrawables(findViewById(R.id.top_layout)); System.gc(); Drawables(View view) { if (view.getBackground() != null) { view.getBackground().setCallback(null); view.setBackground(null); //添加} if (view instanceof ViewGroup && !(view instanceof AdapterView)) { for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) { unbindDrawables(((ViewGroup) view).getChildAt(i)); } ((ViewGroup) view).removeAllViews(); } } 
【补充】上述方法对ListView和GridView无用
 
3. 在onDestroy()中设置object = null 虽然设置object = null不是必要的,但是可以让GC加快一点; 

4.让所有对象设置为null,虽然是很方便,但是也容易出错,最优的方法是通过MAT工具来监测哪些对象可能会泄漏,然后在 onDestroy()中置null。不然的话如果一个后台线程还在运行并且需要调用这些对象,那么就容易出现NullPointerExceptions。 

5.Images(Bitmaps)不像一般Java对象一样分配内存而是通过调用natvie方法,所以bitmap占用了非Dalvik堆的内存。所以使用MAT工具时会发现用procrank和dumpsys命令查看的内存会比MAT中的大很多。 
【补充】 
 摘自https://developer.android.com/training/displaying-bitmaps/manage-memory.html (翻译:) http://su1216.iteye.com/blog/1931629  

(1) Android2.2及之前版本,GC时应用的线程都会停止,这样会引起延迟,导致性能降低。所以在2.3中添加了并发GC机制,所以只要bitmap不再被引用,所占内存就马上会被回收。 

(2) 在2.3及之前版本,bitmap的像素数据是存储在native memory中的,并不是和bitmap对象一起存储在Dalvik heap里的,会导致native memory中的像素数据不能被显式回收,造成应用超出内存大小限制而崩溃。 
在2.3 (API level 11)之后的版本,像素数据就和bitmap对象一起存储在Dalvik heap上了。 

6.加载网络如片在Android中会比较难以操作,只是加载几个200x200像素的图片就会导致内存占用的暴涨,20k大小的200x200的png图片需要占用160K左右的内存(每个像素占用4bytes)[200x200x4/1024 = 156.25k ]
推荐使用下列方法【摘自 http://android-developers.blogspot.com/2008/09/android-photostream.html】 
(1) 首先获得图片的的大小(像素)
BitmapFactory.Options options = new BitmapFactory.Options(); //只加载图片的部分信息,减少内存占用   options.inJustDecodeBounds = true; Bitmap tmpBitmap = BitmapFactory.decodeStream(new ByteArrayInputStream(new URL(url).openStream()), null, options); //获取图片的长宽像素   int height = options.outHeight; int width = options.outWidth; 

(2) 这样就在下载网络图片之前就可以知道图片的大小了,然后根据最终需要显示的图片大小进行压缩(通常Android会在绘制的时候缩放图片) 

options = new BitmapFactory.Options(); options.inSampleSize = sampleSize;//压缩比列,如果是3,就会压缩到1/3 bitmap = BitmapFactory.decodeStream(new ByteArrayInputStream(new URL(url).openStream()), null, options); 

这样获取的图片内存占用会小一点。 

(3) 更好的办法是将图片下载到本地,在使用的时候根据大小重新缩放。
将不再需要图片对象时调用bitmap.recyce()来释放掉图片的内存占用,但是如果你调用了recycle(),之后又试图绘制这个bitmap,你会得到 错误:“Canvas: trying to use a recycled bitmap”(适合Android2.3及之前版本)。 

7.ListView的convertView缓存方式 【网上资料很多】 

8.debug的时候会保持对象处于可用状态,内存不能被回收。所以内存分析(使用MAT工具)的时候不要使用debug。并且在heap dump之前多进行几次GC操作
【原因:http://groups.google.com/group/android-developers/browse_thread/thread/7b0ea57d9507d33f】 


文章的回复里有个问题 
问题: 
我写了一个简单的demo,只有两个activity,重复打开SecondActivity 6次,使用MAT工具查看内存发现有6个SecondActivity对象,为什么会这样? 
回答: 
可能导致上述问题的原因 
(1) 怎么打开和关闭SecondActivity的,是通过Intent吗?是通过硬件返回按钮关闭SecondActivity的吗? 
(2) 在SecondActivity中重载onDestroy(),打上log,重复打开SecondActivity 6次,onDestroy()中的log会打印6次吗? 
(3) 用多快速度重新打开和关闭SecondActivity的?最好是当看见一个GC log时再重新打开,可能是还没有来得及GC,所以内存中会有多个对象(可有可能是你的demo内存占用太小,没有达到需要GC的条件) 
(4)检查一下6个SecondActivity对象的状态是否为unknown,MAT也会统计unkown状态的对象。【补充:可以使用adb shell dumpsys meminfo 命令查看当前内存中Activity存在的数目】 
1楼码魂
更关心的是4+的版本...,2.x版本的产品直接忽略了...
  相关解决方案