在Android 项目时的防止Memory leak 要注意的事项

如何查看Memory leak的问题

如果怀疑有memory leak的问题，可先执行那个apk在emulator上，然后在PC上执行adb shell,，然后执行ps，查看你的process 的pid。

在apk上执行有memory leak可疑的动作后，可以做下面的诊断

1.  执行 dumpsysmeminfo <pid>

这个指令显示pid的memory资料。注意是 Activity的 数量，如果数量是不断上升，那就是有memory leak。 注意，因为在未执行Gargage Collect前，Activity是不会被释放的。可以在DDMS上执行手动的Gargage Collect。

2. 把process 的memory dump 出来，看memory leak的所在

先执行 chmod 777 /data/misc，然后执行 kill -10 <pid> ，在/data/misc 上会看到那个pid 的memoryleak，（如heap-dump-tm1265266619-pid1673.hprof ）

用adb pull (如adb pull /data/misc/heap-dump-tm1265266619-pid1673.hprof 1673.hprof )把这个档案拷回电脑上。

然后，用在PC上执行hprof-conv (如hprof-conv  1673.hprof 1673_a.hprof) 把那个拷回来的hprof转换成Eclipse Memory Tool 可以支持的格式。

用Eclipse Memory Tool (http://www.eclipse.org/mat/),打开转换了的memory dump。 在EclipseMemory Tool 上，按OQL，输入 “select* from instanceof android.app.Activity” , 这个指令可以找所以在系统上是android.app.Activity 的 instance。

如果在object的旁带有“Unknown”的话，那object是可以被Gargage Collect的。要看其他的object是什么原因不可以被Gargage Collect 的话，可以在那个object上right-click，然后选Path to GC Roots, excludeweak/soft reference 。 （weak 和softreference 都是可以被VM查到的，所以是可以GargageCollect的。）

在Path to GC Roots 中，可以看到WidgetManagerHome 是因为Toast中的inner class TN 把 这个WidgetManagerHome抓住了。