永远的Singleton
单例的使用在我们的程序中随处可见，因为使用它可以完美的解决我们在程序中重复创建对象的问题，不过可别小瞧它。由于单例的静态特性，使得它的生命周期和应用的生命周期会一样长，所以一旦使用有误，小心无限制的持有Activity的引用而导致内存泄漏。比如，下面的例子。
public class SingletonBad {
private Context context;
private static SingletonBad singletonBad ;
private SingletonBad(Context context){
this.context = context;
}
public static SingletonBad getInstance(Context context){
if (singletonBad==null) {
singletonBad = new SingletonBad(context);
}
return singletonBad;
}
}
这个错误在生活中再普遍不过，很正常的一个单例模式，可就由于传入的是一个 Context，而这个 Context 的生命周期的长短就尤为重要了。如果我们传入的是 Activity 的 Context，当这个 Context 所对应的 Activity 退出的时候，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会回收，这造成的内存泄漏就可想而知了。
正确的方式应该是把传入的 Context 换为和应用的生命周期一样长的 Application 的 Context：
public class SingletonGood {
private Context context;
private static SingletonGood singletonGood;
private SingletonGood(Context context){
this.context = context.getApplicationContext();
}
public static SingletonGood getInstance(Context context){
if (singletonGood==null) {
singletonGood = new SingletonGood(context);
}
return singletonGood;
}
}
当然，你也可以直接连 Context 都不用传入了。重写 application，提供静态的 getContext 方法：
public class MyApplicaton extends Application {
private static MyApplicaton myApplicaton = null;
@Override
public void onCreate() {
super.onCreate();
myApplicaton = this;
}
public static MyApplicaton getInstance(){
return myApplicaton;
}
public static Context getContext(){
return myApplicaton.getApplicationContext();
}
}
自然就可以直接不用传入Context:
public class SingletonGoodNew {
private Context context;
private static SingletonGoodNew singletonGoodNew ;
private SingletonGoodNew(){
this.context = MyApplicaton.getContext();
}
public static SingletonGoodNew getInstance(){
if (singletonGoodNew==null) {
singletonGoodNew = new SingletonGoodNew();
}
return singletonGoodNew;
}
}
令人心塞的Handler
这个东西在我最近遇到的最多了，而它也是我们在内存泄漏中最为常见的，也许你的一个小忽略就会导致内存泄漏。在Android的新版本中，我们被要求必须把网络任务等耗时操作置于新线程来处理，我们通常会采用 Handler。
但 Handler 不是万能的，若是我们的编写不规范就有可能会造成内存泄漏。另外，我们知道，Handler、Message 和 MessageQueue 都是相互关联在一起的，万一 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象将会被线程 MessageQueue 一直持有。
由于 Handler 属于 TLS（Thread Local Storage）变量，生命周期和 Activity 是不一致的。因此这种实现方式一般很难保证跟 View 或者 Activity 的生命周期一致，故很容易导致无法正确释放。比如：
public class HandlerBadActivity extends AppCompatActivity {
private final Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler_bad);
handler.postDelayed(new Runnable() {
@Override
public void run() {
}
},1000*60*5);
this.finish();
}
}
在例子中，我们申明了一个 延迟5分钟 执行的消息 Message。当该 Activity 被 finish 的时候，延迟任务的 Message 还存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish 掉的 Activity 就不会回收了，所以造成了内存泄漏（因 handler 为非静态内部类，它会持有外部类的引用，在这里就是当前的 Activity）。
修复：这个解决也是可以通过把其声明为 static 的，则其存活期就跟 activity 的生命周期无关了。不过倘若用到 Context 等外部类的 非static 对象，还是应该通过弱引用传入。比如：
package com.loaderman.memoryanalyzedemo;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity;
import java.lang.ref.WeakReference;
public class handerGooodActivity extends AppCompatActivity {
private static final class MyHadner extends Handler {
private final WeakReference<handerGooodActivity> mActivity;
private MyHadner(handerGooodActivity activity) {
//使用弱引用
this.mActivity = new WeakReference<handerGooodActivity>(activity);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
handerGooodActivity activity =mActivity.get();
if (activity!=null) {
}
}
}
//匿名的内部类在static的时候绝对不会持有外部类 引用
private final MyHadner myHadner = new MyHadner(this) ;
private static final Runnable RUNNABLE = new Runnable() {
@Override
public void run() {
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_hander_goood);
myHadner.postDelayed(RUNNABLE,1000*60*5);
}
}
综述：推荐使用静态内部类+弱引用 WeakReference 这种方式，但要注意每次使用前判空。
说到若引用，这里再提下java的几种引用类型：Strong, reference,SoftReference,WeakReference 和 PhatomReference:
在 Android 开发中，为了防止内存溢出，在处理一些占用内存大并且生命周期较长的对象的时候，可以尽量地使用 软引用 和 弱引用 技术。
比如，保存 Bitmap 的软引用到 HashMap:
package com.loaderman.memoryanalyzedemo;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import java.lang.ref.SoftReference;
import java.util.HashMap;
/**
* Created by JCF on 2017/3/2.
*/
public class CacheBySoftRef {
//定义一个hashmap,保存软引用对象
private HashMap<String ,SoftReference<Bitmap>> imgCache = new HashMap<>() ;
//添加Bitmap的软应用到HashMap
public void addBitmapToCache(String path){
//强引用的Bitmap对象
Bitmap bitmap = BitmapFactory.decodeFile(path);
//软引用的Bitmao对象
SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap) ;
//添加对象map使其缓存
imgCache.put(path,softBitmap);
}
//获取bitmap对象
public Bitmap getBitMapToCache(String path){
SoftReference<Bitmap> softBitmap = imgCache.get(path);
//判断是否存在软引用
if (softBitmap==null) {
return null;
}
//通过软引用取出对象,如果内存不足bitmap被回收,则取出空
//如果未被回收,则可重复使用,提供速度
Bitmap bitmap =softBitmap.get();
return bitmap ;
}
}
使用软引用以后，在 OutOfMemory 异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。如果只是想避免 OutOfMemory 异常的发生，则可以使用 软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用 弱引用。另外可以根据对象是否经常使用来判断选择 软引用 还是 弱引用。如果该对象可能会经常使用的，就尽量用 软引用。如果该对象不被使用的可能性更大些，就可以用 弱引用。
前面所说的，创建一个 静态Handler内部类，然后对 Handler 持有的对象使用弱引用，这样在回收时也可以回收 Handler 持有的对象，但是这样做虽然避免了 Activity 泄漏，不过 Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。
下面几个方法都可以移除 Message：
匿名内部类/非静态内部类
它们方便却暗藏杀机。Android开发经常会继承实现 Activity 或者 Fragment 或者 View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的：
package com.loaderman.memoryanalyzedemo;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
public class MainActivity extends AppCompatActivity {
class TestInnerBad{};
private static TestInnerBad testInnerBad = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if (testInnerBad==null) {
testInnerBad = new TestInnerBad() ;
}
Runnable runnable1 = new MyRunnable();
System.out.println("runnable1"+runnable1);
Runnable runnable2 = new Runnable() {
@Override
public void run() {
}
} ;
System.out.println("runnable2"+runnable2);
}
private static class MyRunnable implements Runnable {
@Override
public void run() {
}
}
}
runnable1 和 runnable2 的区别就是，runnable2 使用了匿名内部类，我们看看引用时的引用内存：
可以看到，runnable1 是没有什么特别的。但 runnable2 多出了一个 MainActivity 的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。
善用static成员变量
前面就很明显，当我们的成员变量是 static 的时候，那么它的生命周期将和整个app的生命周期一致。
这必然会导致一系列问题，如果你的app进程设计上是长驻内存的，那即使app切到后台，这部分内存也不会被释放。按照现在手机app内存管理机制，占内存较大的后台进程将优先回收，因为如果此app做过进程互保保活，那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。
这里修复的方法是：
不要在类初始时初始化静态成员。可以考虑 lazy初始化（延迟加载）。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。
远离非静态内部类和匿名类，多用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 中才能创建。
集合对象善清除，以免内存泄漏触不及防
我们通常会把一些对象的引用加入到集合容器（比如 ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是 static 的话，那情况就更严重了。
所以在退出程序之前，将集合里面的东西 clear，然后置为 null，再退出程序，如下：
private List list ;
@Override
protected void onDestroy() {
super.onDestroy();
if (list!=null) {
list.clear();;
list=null;
}
}
webView虽火，内存泄漏却也火的其所
当我们不再需要使用 webView 的时候，应该调用它的 destory() 方法来销毁它，并释放其占用的内存，否则其占用的内存长期也不能回收，从而造成内存泄漏。
解决方案：
为 webView 开启另外一个进程，通过AIDL与主线程进行通信，webView 所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
而另外一些诸如 listView 的 Adapter 没有缓存之类的等
总结
构造 Adapter 时，没有使用缓存的 convertView
Bitmap 对象不在使用时调用 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，这样的设计谁都得不到释放。