正文

*本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布

一、写在前面

　　对于C++来说，内存泄漏就是new出来的对象没有delete，俗称野指针；而对于java来说，就是new出来的Object放在Heap上无法被GC回收；而这里就把我之前的一篇内存泄漏的总结翻新，做一个更加全面规范的讲解，希望能帮到各位。

二、一些杂谈

　　1、这里先安利一下java的内存分配：

　　　　a)　　静态存储区：编译时就分配好，在程序整个运行期间都存在。它主要存放静态数据和常量；

　　　　b)　　栈区：当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放内存；

　　　　c)　　堆区：通常用来存放new出来的对象。由java垃圾回收期回收。

　　2、四种引用类型的介绍

　　　　a)　　强引用(StrongReference)：JVM 宁可抛出 OOM ，也不会让 GC 回收具有强引用的对象；

　　　　b)　　软引用(SoftReference)：只有在内存空间不足时，才会被回的对象；

　　　　c)　　弱引用(WeakReference)：在 GC 时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存；

　　　　d)　　虚引用(PhantomReference)：任何时候都可以被GC回收，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用，来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志。

　　3、内存抖动，这样的图很熟悉有木有？当这样的时候，说明你的内存真的在变少了。

三、内存泄漏检测工具

　　在这里先推荐两种内存检查的方式：

            leakcanary是一个开源项目，一个内存泄露自动检测工具，是著名的GitHub开源组织Square贡献的，它的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心，缺点在于还存在一些bug，不过正常使用百分之九十情况是OK的，其核心原理与MAT工具类似。

因为配置十分简单，只需要几句话就好！！！这里就不多说了，大家可以看官方文档，简单直白。

四、内存泄漏解析 

1）永远的Singleton

       单例的使用在我们的程序中随处可见，因为使用它可以完美的解决我们在程序中重复创建对象的问题，不过可别小瞧它。由于单例的静态特性，使得它的生命周期和应用的生命周期会一样长，所以一旦使用有误，小心无限制的持有Activity的引用而导致内存泄漏。比如，下面的例子。

%201%20package%20com.example.nanchen.anrsolutiondemo.singleton;%202%20%203%20import%20android.content.Context;%204%20%205%20/**%206%20%20*%20@author%20nanchen%207%20%20*%20@fileName%20ANRSolutionDemo%208%20%20*%20@packageName%20com.example.nanchen.anrsolutiondemo.singleton%209%20%20*%20@date%202016/09/23%20%2011:2710%20%20*/11%20public%20class%20SingletonBad%20{12%20%20%20%20%20private%20static%20SingletonBad%20singletonBad;13%20%20%20%20%20private%20Context%20context;14%2015%20%20%20%20%20private%20SingletonBad(Context%20context){16%20%20%20%20%20%20%20%20%20this.context%20=%20context;17%20%20%20%20%20}18%2019%20%20%20%20%20public%20static%20SingletonBad%20getInstance(Context%20context){20%20%20%20%20%20%20%20%20%20if%20(singletonBad%20==%20null){21%20%20%20%20%20%20%20%20%20%20%20%20%20singletonBad%20=%20new%20SingletonBad(context);22%20%20%20%20%20%20%20%20%20}23%20%20%20%20%20%20%20%20%20return%20singletonBad;24%20%20%20%20%20}25%20}
这个错误在生活中再普遍不过，很正常的一个单例模式，可就由于传入的是一个Context，而这个Context的生命周期的长短就尤为重要了。如果我们传入的是Activity的Context，当这个Context所对应的Activity退出的时候，由于该Context的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前Activity退出时它的内存并不会回收，这造成的内存泄漏就可想而知了。
正确的方式应该是把传入的Context换为和应用的生命周期一样长的application的Context;
%201%20package%20com.example.nanchen.anrsolutiondemo.singleton;%202%20%203%20import%20android.content.Context;%204%20%205%20/**%206%20%20*%20@author%20nanchen%207%20%20*%20@fileName%20ANRSolutionDemo%208%20%20*%20@packageName%20com.example.nanchen.anrsolutiondemo.singleton%209%20%20*%20@date%202016/09/23%20%2011:2910%20%20*/11%20public%20class%20SingletonGood%20{12%20%20%20%20%20private%20static%20SingletonGood%20singletonGood;13%20%20%20%20%20private%20Context%20context;14%2015%20%20%20%20%20private%20SingletonGood(Context%20context){16%20%20%20%20%20%20%20%20%20this.context%20=%20context.getApplicationContext();//获取Application的context避免内存泄漏17%20%20%20%20%20}18%2019%20%20%20%20%20public%20static%20SingletonGood%20getInstance(Context%20context){20%20%20%20%20%20%20%20%20%20if%20(singletonGood%20==%20null){21%20%20%20%20%20%20%20%20%20%20%20%20%20singletonGood%20=%20new%20SingletonGood(context);22%20%20%20%20%20%20%20%20%20}23%20%20%20%20%20%20%20%20%20return%20singletonGood;24%20%20%20%20%20}25%20}
当然，你也可以直接连Context都不用传入了。重写application，提供静态的getContext方法
%201%20package%20com.example.nanchen.anrsolutiondemo.singleton;%202%20%203%20import%20android.app.Application;%204%20import%20android.content.Context;%205%20%206%20/**%207%20%20*%20@author%20nanchen%208%20%20*%20@fileName%20ANRSolutionDemo%209%20%20*%20@packageName%20com.example.nanchen.anrsolutiondemo.singleton10%20%20*%20@date%202016/09/23%20%2011:3211%20%20*/12%20public%20class%20DemoApplication%20extends%20Application%20{13%20%20%20%20%20private%20static%20DemoApplication%20demoApplication;14%2015%20%20%20%20%20public%20static%20DemoApplication%20getInstance(){16%20%20%20%20%20%20%20%20%20return%20demoApplication;17%20%20%20%20%20}18%2019%20%20%20%20%20public%20static%20Context%20getContext(){20%20%20%20%20%20%20%20%20%20return%20demoApplication.getApplicationContext();21%20%20%20%20%20}22%2023%20%20%20%20%20@Override24%20%20%20%20%20public%20void%20onCreate()%20{25%20%20%20%20%20%20%20%20%20super.onCreate();26%20%20%20%20%20%20%20%20%20demoApplication%20=%20this;27%20%20%20%20%20}28%20}
自然就可以直接不用传入Context
%201%20package%20com.example.nanchen.anrsolutiondemo.singleton;%202%20%203%20import%20android.content.Context;%204%20%205%20/**%206%20%20*%20@author%20nanchen%207%20%20*%20@fileName%20ANRSolutionDemo%208%20%20*%20@packageName%20com.example.nanchen.anrsolutiondemo.singleton%209%20%20*%20@date%202016/09/23%20%2011:3210%20%20*/11%20public%20class%20SingletonGoodNew%20{12%20%20%20%20%20private%20static%20SingletonGoodNew%20singletonGoodNew;13%2014%20%20%20%20%20private%20Context%20context;15%20%20%20%20%2016%20%20%20%20%20private%20SingletonGoodNew(){17%20%20%20%20%20%20%20%20%20this.context%20=%20DemoApplication.getContext();18%20%20%20%20%20}19%2020%20%20%20%20%20public%20static%20SingletonGoodNew%20getInstance(){21%20%20%20%20%20%20%20%20%20if%20(singletonGoodNew%20==%20null){22%20%20%20%20%20%20%20%20%20%20%20%20%20singletonGoodNew%20=%20new%20SingletonGoodNew();23%20%20%20%20%20%20%20%20%20}24%20%20%20%20%20%20%20%20%20return%20singletonGoodNew;25%20%20%20%20%20}26%20}
 
 
2）令人心塞的Handler
 %20 %20 %20 这个东西在我最近遇到的最多了，而它也是我们在内存泄漏中最为常见的，也许你的一个小忽略就会导致内存泄漏。在android的新版本中，我们被要求必须把网络任务等耗时操作置于新线程来处理，我们通常会采用Handler。但Handler不是万能的，若是我们的编写不规范就有可能会造成内存泄漏。另外，我们知道，Handler、Message和MessageQueue都是相互关联在一起的，万一Handler发送的Message尚未被处理，则该Message及发送它的Handler对象将会被线程MessageQueue一直持有。
 %20 %20 %20 由于Handler属于TLS（Thread%20Local%20Storage）变量，生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟View或者Activity的生命周期一致，故很容易导致无法正确释放。比如：
%201%20package%20com.example.nanchen.anrsolutiondemo.handler;%202%20%203%20import%20android.os.Bundle;%204%20import%20android.os.Handler;%205%20import%20android.os.Message;%206%20import%20android.support.v7.app.AppCompatActivity;%207%20%208%20import%20com.example.nanchen.anrsolutiondemo.R;%209%2010%20public%20class%20HandlerBadActivity%20extends%20AppCompatActivity%20{11%2012%20%20%20%20%20private%20final%20Handler%20handler%20=%20new%20Handler(){13%20%20%20%20%20%20%20%20%20@Override14%20%20%20%20%20%20%20%20%20public%20void%20handleMessage(Message%20msg)%20{15%20%20%20%20%20%20%20%20%20%20%20%20%20super.handleMessage(msg);16%20%20%20%20%20%20%20%20%20}17%20%20%20%20%20};18%2019%20%20%20%20%20@Override20%20%20%20%20%20protected%20void%20onCreate(Bundle%20savedInstanceState)%20{21%20%20%20%20%20%20%20%20%20super.onCreate(savedInstanceState);22%20%20%20%20%20%20%20%20%20setContentView(R.layout.activity_handler_bad);23%2024%20%20%20%20%20%20%20%20%20//%20延迟10s发送一个消息25%20%20%20%20%20%20%20%20%20handler.postDelayed(new%20Runnable()%20{26%20%20%20%20%20%20%20%20%20%20%20%20%20@Override27%20%20%20%20%20%20%20%20%20%20%20%20%20public%20void%20run()%20{28%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20//%20write%20something29%20%20%20%20%20%20%20%20%20%20%20%20%20}30%20%20%20%20%20%20%20%20%20},1000*60*5);31%2032%20%20%20%20%20%20%20%20%20this.finish();33%20%20%20%20%20}34%20}
在例子中，我们申明了一个延迟5分钟执行的消息Message。当该Activity被finish的时候，延迟任务的Message还存在于主线程中，它持有该Activity的Handler引用，所以此时Finish掉的Activity就不会回收了，所以造成了内存泄漏（因handler为非静态内部类，它会持有外部类的引用，在这里就是当前的Activity）。
修复：这个解决也是可以通过把其声明为static的，则其存活期就跟activity的生命周期无关了。不过倘若用到Context等外部类的非static对象，还是应该通过弱引用传入。比如：
%201%20package%20com.example.nanchen.anrsolutiondemo.handler;%202%20%203%20import%20android.os.Bundle;%204%20import%20android.os.Handler;%205%20import%20android.os.Message;%206%20import%20android.support.v7.app.AppCompatActivity;%207%20%208%20import%20com.example.nanchen.anrsolutiondemo.R;%209%2010%20import%20java.lang.ref.WeakReference;11%2012%20public%20class%20HandlerGoodActivity%20extends%20AppCompatActivity%20{13%2014%20%20%20%20%20private%20static%20final%20class%20MyHandler%20extends%20Handler{15%20%20%20%20%20%20%20%20%20private%20final%20WeakReference<HandlerGoodActivity>%20mActivity;16%2017%20%20%20%20%20%20%20%20%20public%20MyHandler(HandlerGoodActivity%20activity){18%20%20%20%20%20%20%20%20%20%20%20%20%20this.mActivity%20=%20new%20WeakReference<HandlerGoodActivity>(activity);//使用弱引用19%20%20%20%20%20%20%20%20%20}20%2021%20%20%20%20%20%20%20%20%20@Override22%20%20%20%20%20%20%20%20%20public%20void%20handleMessage(Message%20msg)%20{23%20%20%20%20%20%20%20%20%20%20%20%20%20super.handleMessage(msg);24%20%20%20%20%20%20%20%20%20%20%20%20%20HandlerGoodActivity%20activity%20=%20mActivity.get();25%20%20%20%20%20%20%20%20%20%20%20%20%20if%20(activity%20!=%20null){26%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20//%20write%20something27%20%20%20%20%20%20%20%20%20%20%20%20%20}28%20%20%20%20%20%20%20%20%20}29%20%20%20%20%20}30%2031%20%20%20%20%20private%20final%20MyHandler%20myHandler%20=%20new%20MyHandler(this);32%2033%20%20%20%20%20//%20匿名内部类在static的时候绝对不会持有外部类的引用34%20%20%20%20%20private%20static%20final%20Runnable%20RUNNABLE%20=%20new%20Runnable()%20{35%20%20%20%20%20%20%20%20%20@Override36%20%20%20%20%20%20%20%20%20public%20void%20run()%20{37%2038%20%20%20%20%20%20%20%20%20}39%20%20%20%20%20};40%2041%20%20%20%20%20@Override42%20%20%20%20%20protected%20void%20onCreate(Bundle%20savedInstanceState)%20{43%20%20%20%20%20%20%20%20%20super.onCreate(savedInstanceState);44%20%20%20%20%20%20%20%20%20setContentView(R.layout.activity_handler_good);45%2046%20%20%20%20%20%20%20%20%20myHandler.postDelayed(RUNNABLE,1000*60*5);47%20%20%20%20%20}48%20}
综述：推荐使用静态内部类+弱引用WeakReference这种方式，但要注意每次使用前判空。
说到若引用，这里再提下java的几种引用类型：Strong%20reference,SoftReference,WeakReference和PhatomReference
在android开发中，为了防止内存溢出，在处理一些占用内存大并且生命周期较长的对象的时候，可以尽量地使用软引用和弱引用技术。
比如，保存Bitmap的软引用到HashMap。
%201%20package%20com.example.nanchen.anrsolutiondemo.photo;%202%20%203%20import%20android.graphics.Bitmap;%204%20import%20android.graphics.BitmapFactory;%205%20%206%20import%20java.lang.ref.SoftReference;%207%20import%20java.util.HashMap;%208%20%209%20/**10%20%20*%20@author%20nanchen11%20%20*%20@fileName%20ANRSolutionDemo12%20%20*%20@packageName%20com.example.nanchen.anrsolutiondemo.photo13%20%20*%20@date%202016/09/23%20%2011:5814%20%20*/15%20public%20class%20CacheBySoftRef%20{16%2017%20%20%20%20%20//%20首先定义一个HashMap,保存软应用对象18%20%20%20%20%20private%20HashMap<String,SoftReference<Bitmap>>%20imageCache%20=%20%20new%20HashMap<>();19%20%20%20%20%20//%20再来定义一个方法，保存Bitmap的软引用到HashMap20%20%20%20%20%20public%20void%20addBitmapToCache(String%20path){21%20%20%20%20%20%20%20%20%20//%20强引用的Bitmap对象22%20%20%20%20%20%20%20%20%20Bitmap%20bitmap%20=%20BitmapFactory.decodeFile(path);23%20%20%20%20%20%20%20%20%20//%20软引用的Bitmap对象24%20%20%20%20%20%20%20%20%20SoftReference<Bitmap>%20softBitmap%20=%20new%20SoftReference<Bitmap>(bitmap);25%20%20%20%20%20%20%20%20%20//%20添加该对象到Map使其缓存26%20%20%20%20%20%20%20%20%20imageCache.put(path,softBitmap);27%20%20%20%20%20}28%2029%20%20%20%20%20//%20获取的时候，可以通过SoftReference的get()的方法得到Bitmap对象30%20%20%20%20%20public%20Bitmap%20getBitmapByPath(String%20path){31%20%20%20%20%20%20%20%20%20//%20从缓存中取软引用的Bitmap对象32%20%20%20%20%20%20%20%20%20SoftReference<Bitmap>%20softBitmap%20=%20imageCache.get(path);33%20%20%20%20%20%20%20%20%20//%20判断是否存在软引用34%20%20%20%20%20%20%20%20%20if%20(softBitmap%20==%20null){35%20%20%20%20%20%20%20%20%20%20%20%20%20return%20null;36%20%20%20%20%20%20%20%20%20}37%20%20%20%20%20%20%20%20%20//%20通过软引用取出Bitmap对象，如果由于内存不足Bitmap被回收，则取得空；38%20%20%20%20%20%20%20%20%20//%20如果未被回收，则可重复使用，提高速度39%20%20%20%20%20%20%20%20%20Bitmap%20bitmap%20=%20softBitmap.get();40%20%20%20%20%20%20%20%20%20return%20bitmap;41%20%20%20%20%20}42%20}
使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。
如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。
另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。
ok，继续回到主题。前面所说的，创建一个静态Handler内部类，然后对%20Handler%20持有的对象使用弱引用，这样在回收时也可以回收%20Handler%20持有的对象，但是这样做虽然避免了%20Activity%20泄漏，不过%20Looper%20线程的消息队列中还是可能会有待处理的消息，所以我们在%20Activity%20的%20Destroy%20时或者%20Stop%20时应该移除消息队列%20MessageQueue%20中的消息。
下面几个方法都可以移除%20Message：
 
 
3）匿名内部类/非静态内部类，它们方便却暗藏杀机
       android开发经常会继承实现Activity或者Fragment或者View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的
%201%20package%20com.example.nanchen.anrsolutiondemo.innerClass;%202%20%203%20import%20android.os.Bundle;%204%20import%20android.support.v7.app.AppCompatActivity;%205%20%206%20import%20com.example.nanchen.anrsolutiondemo.R;%207%20%208%20public%20class%20MainActivity%20extends%20AppCompatActivity%20{%209%2010%20%20%20%20%20private%20static%20TestInnerBad%20testInnerBad%20=%20null;11%2012%20%20%20%20%20class%20TestInnerBad{13%2014%20%20%20%20%20}15%2016%20%20%20%20%20@Override17%20%20%20%20%20protected%20void%20onCreate(Bundle%20savedInstanceState)%20{18%20%20%20%20%20%20%20%20%20super.onCreate(savedInstanceState);19%20%20%20%20%20%20%20%20%20setContentView(R.layout.activity_inner_bad);20%2021%20%20%20%20%20%20%20%20%20if%20(testInnerBad%20==%20null){22%20%20%20%20%20%20%20%20%20%20%20%20%20testInnerBad%20=%20new%20TestInnerBad();23%20%20%20%20%20%20%20%20%20}24%2025%20%20%20%20%20%20%20%20%20Runnable%20runnable1%20=%20new%20MyRunnable();26%20%20%20%20%20%20%20%20%20Runnable%20runnable2%20=%20new%20Runnable()%20{27%20%20%20%20%20%20%20%20%20%20%20%20%20@Override28%20%20%20%20%20%20%20%20%20%20%20%20%20public%20void%20run()%20{29%2030%20%20%20%20%20%20%20%20%20%20%20%20%20}31%20%20%20%20%20%20%20%20%20};32%20%20%20%20%20}33%2034%20%20%20%20%20private%20static%20class%20MyRunnable%20implements%20Runnable{35%2036%20%20%20%20%20%20%20%20%20@Override37%20%20%20%20%20%20%20%20%20public%20void%20run()%20{38%2039%20%20%20%20%20%20%20%20%20}40%20%20%20%20%20}41%2042%20}
runnable1%20和%20runnable2的区别就是，runnable2使用了匿名内部类，我们看看引用时的引用内存
可以看到，runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。
 
4）前辈箴言——善用static成员变量
      前面就很明显，当我们的成员变量是static的时候，那么它的生命周期将和整个app的生命周期一致。
      这必然会导致一系列问题，如果你的app进程设计上是长驻内存的，那即使app切到后台，这部分内存也不会被释放。按照现在手机app内存管理机制，占内存较大的后台进程将优先回收，因为如果此app做过进程互保保活，那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。
这里修复的方法是：
不要在类初始时初始化静态成员。可以考虑lazy初始化（延迟加载）。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。
 
5）远离非静态内部类和匿名类，多用private static class。
      在我们的日常代码中，这样的情况似乎很常见，及直接写一个class就这么光秃秃的情况。
      
　　　
这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。正确的做法为：
将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请按照上面推荐的使用Application 的 Context。当然，Application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的Context的应用场景如下：
其中： NO1表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能创建
 
6） 集合对象善清除，以免内存泄漏触不及防
　　我们通常会把一些对象的引用加入到集合容器（比如ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
　　所以在退出程序之前，将集合里面的东西clear，然后置为null，再退出程序，如下：
 1 private List<String> nameList; 2     private List<Fragment> list; 3  4     @Override 5     public void onDestroy() { 6         super.onDestroy(); 7         if (nameList != null){ 8             nameList.clear(); 9             nameList = null;10         }11         if (list != null){12             list.clear();13             list = null;14         }15     }
 
7）webView虽火，内存泄漏却也火的其所
　　当我们不再需要使用webView的时候，应该调用它的destory()方法来销毁它，并释放其占用的内存，否则其占用的内存长期也不能回收，从而造成内存泄漏。
　　解决方案：
　　　　为webView开启另外一个进程，通过AIDL与主线程进行通信，webView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
　　而另外一些诸如listView的Adapter没有缓存之类的这里就不再多提了。
8）做一个小的总结
构造Adapter时，没有使用缓存的 convertViewBitmap对象不在使用时调用recycle()释放内存Context使用不当造成内存泄露：不要对一个Activity Context保持长生命周期的引用。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换。非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit();才不会泄露。对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。不要在执行频率很高的方法或者循环中创建对象（比如onmeasure），可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放。
 
回到顶部
五、真相只有一个
　　内存泄漏实在太普遍了，真是防不胜防。不过我想告诉广大的小伙伴，程序员嘛，谁还不踩个坑，跳出来，拍拍身上的灰尘，总结一下，过两天又是一条帮帮的coder。你可以的。