Android 内存泄漏情形及解决办法汇总

---

内存泄漏对于从事Android开发的人员都不陌生，而且也很头疼，本篇博文讲带领大家走进内存泄漏的王国，体会一下它的奥秘

你将了解

• 什么叫内存泄漏
• Java内存分配策略是怎样的
• Java是如何进行内存管理的
• Android中的内存泄漏

一、内存泄漏定义

该释放的没有释放，一直被某实例所持有而又不使用他，GC无法回收导致的。

二、Java内存分配策略

程序运行内存分配有三种形式：静态分配，栈式分配，堆式分配
对应使用的内存空间–>静态储存区（方法区） 、栈区，堆区。

来看看三种分配策略的区别

内存空间	存放内容	特点
方法区	静态数据，全局static数据和常量	此内存在编译时就分配好，并在程序整个运行期间都存在
栈区	方法体内的局部变量（包括基础数据类型，对象的引用）	方法执行这些变量都在栈上创建并分配，方法结束（当超过该变量的作用域后），这些变量所持有的内存将会自动被释放，该内存空间可被重新使用
堆区	放直接new出的对象（包括该对象中的所有成员变量和数组）	这部分内存在不使用时将有GC负责回收

在堆中产生了一个数组或者对象后，还可以在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。

列子

public class Sample {
    int s1 = 0;
    Sample mSample1 = new Sample();//在堆中产生了一个数组或者对象

    public void method() {
        //Sample 类的局部变量s2和引用变量mSample2存于栈中(方法块中创建)，mSample2指向的对象存在于堆上new的
        int s2 = 1;
        Sample mSample2 = new Sample();
    }
}
//mSample3指向的对象实体存于堆上，包括这个对象的所有成员变量s1、mSample1而它自己存于栈中。
Sample mSample3 = new Sample();

结论

1、局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。—— 因为它们属于方法中的变量，生命周期随方法而结束。
2、成员变量全部存储与堆中（包括基本数据类型，引用和引用的对象实体）—— 因为它们属于类，类对象终究是要被new出来使用的

Java内存管理

• 定义
  就是对象的分配和释放问题，
• 分配方法：
  通过关键字new为每个对象分配内存空间，（基本类型除外），都在堆中分配
• 分配释放关键人物
  GC决定和执行对象的释放，内存分配由程序决定，（达成收支两条线简化程序的同时加重JVM工作–》java程序运行速度慢原因之一，
• GC的监视
  为了更加准确地、及时地释放对象，GC必监控每一对象的运行状态，包括对象的申请，引用，被引用，赋值）
• 释放对象的根本原则
  对象不再被引用

Java内存回收机制

对象的创建都是在堆中分配，所有对象的回收由java虚拟机通过垃圾回收机制完成
GC监控每个对象的运行状态，对他们的申请引用，被引用，复制等状态进行监控java使用有向图的方法进行管理内存实时监控对象是否可以到达如果不可到达就将其回收这样也消除引用循环的问题

java判断达到垃圾回收的标准：

• 1：給对象赋予了空值null一下再没有调用过
• 2：另一个就是给对象赋予了新值，重新分配了内存空间

Java内存泄漏引起的原因

• 长生命周期的对象持有短生命周期对象的引用有可能

Android内存泄漏场景及优化方案

集合类造成的

仅有添加元素的方法，而无相应的删除机制，导致内存被占用。如果这个集合类是全局性的变量 (比如类中的静态属性，全局性的 map 等即有静态引用或 final 一直指向它)，那么没有相应的删除机制，很可能导致集合所占用的内存只增不减从而内存泄漏。

单列造成的

由于单例的静态特性使得其生命周期跟应用的生命周期一样长，所以如果使用不恰当的话，很容易造成内存泄漏。比如下面一个典型的例子，

public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context;
}
public static AppManager getInstance(Context context) {
if (instance == null) {
instance = new AppManager(context);
}
return instance;
}
}

• 分析

  因为这里要传入一个Context,这个Context的生命周期长短很重要，
  1、当传入的是Appliation的Context，因为Application的生命周期就是整个应用的生命周期，所以这没有任何问题
  2、传入的是Activity的Context，当Context对应的Activity退出时由于该Context的引用被单列对象所持有，其生命周期等于整个应用的生命周期所以当前Activity退出时它的内存并不会被回收，即造成内存泄漏

• 正确方式

public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context.getApplicationContext();// 使用Application 的context
}
public static AppManager getInstance(Context context) {
if (instance == null) {
instance = new AppManager(context);
}
return instance;
}
}

或者这样写，连 Context 都不用传进来了：

在你的 Application 中添加一个静态方法，getContext() 返回 Application 的 context，

...

context = getApplicationContext();

...
   /**
     * 获取全局的context
     * @return 返回全局context对象
     */
    public static Context getContext(){
        return context;
    }

public class AppManager {
private static AppManager instance;
private Context context;
private AppManager() {
this.context = MyApplication.getContext();// 使用Application 的context
}
public static AppManager getInstance() {
if (instance == null) {
instance = new AppManager();
}
return instance;
}
}

匿名内部类/非静态内部类和异步线程造成的

• 非静态内部类创建静态实例造成的内存泄漏
  有的时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，可能会出现这种写法：

 public class MainActivity extends AppCompatActivity {
        private static TestResource mResource = null;
        @Override
        protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        if(mManager == null){
        mManager = new TestResource();
        }
        //...
        }
        class TestResource {
        //...
        }
        }

分析错误

这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收

解决办法

将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例

• 匿名内部类
  android开发经常会继承实现Activity/Fragment/View，此时如果你使用了匿名类，并被异步线程持有了，那要小心了，如果没有任何措施这样一定会导致泄露

   public class MainActivity extends Activity {
    ...
    Runnable ref1 = new MyRunable();
    //ref2使用匿名内部类
    Runnable ref2 = new Runnable() {
        @Override
        public void run() {

        }
    };
       ...
    }

运行时两个引用的内存

可以看到，ref1没什么特别的。
但ref2这个匿名类的实现对象里面多了一个引用：
this$0这个引用指向MainActivity.this，也就是说当前的MainActivity实例会被ref2持有，如果将这个引用再传入一个异步线程，此线程和此Acitivity生命周期不一致的时候，就造成了Activity的泄露。

Handler造成的

Handler不陌生哈,他也容易造成内存泄漏，比如为避免ANR我们不在主线程中进行耗时操作，网络请求就借助Handler,我们知道Handler,Message,MessageQueue都是连在一起的，万一Handler发送的Messave尚未被处理，则该Message发送它的Handler对象将被线程MessageQueue一直持有

下面我们结合列子分析

问题所在

public class SampleActivity extends Activity {
    private final Handler mLeakyHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
      // ...
    }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // 延迟10分钟执行的消息Message,mLeakyHandler 将其push进了消息队列MessageQueue里
    mLeakyHandler.postDelayed(new Runnable() {
      @Override
      public void run() { /* ... */ }
    }, 1000 * 60 * 10);

    // 当activity被fish()掉的时候，延迟延迟执行任务的 Message 还会继续存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish() 掉的 Activity 就不会被回收了从而造成内存泄漏（因 Handler 为非静态内部类，它会持有外部类的引用，在这里就是指 SampleActivity）。
    finish();
    }
}

修复方法

在Activity中避免使用非静态内部类
推荐使用静态内部类 + WeakReference 这种方式。每次使用前注意判空

public class SampleActivity extends Activity {

  /**
   * 将Handler声明为静态的，则其存活期跟Activity的生命周期就无关了
   * 
   */
  private static class MyHandler extends Handler {
    private final WeakReference<SampleActivity> mActivity;

    public MyHandler(SampleActivity activity) {
      //通过弱引用的方式引入Activity避免直接将Activity作为context传进去
      mActivity = new WeakReference<SampleActivity>(activity);
    }

    @Override
    public void handleMessage(Message msg) {
      SampleActivity activity = mActivity.get();
      if (activity != null) {
        // ...
      }
    }
  }
  private final MyHandler mHandler = new MyHandler(this);
  private static final Runnable sRunnable = new Runnable() {
      @Override
      public void run() { /* ... */ }
  };

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
    finish();
  }
}

创建一个静态Handler内部类，然后对 Handler 持有的对象使用弱引用，这样在回收时也可以回收 Handler 持有的对象，但是这样做虽然避免了 Activity 泄漏，不过 Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。

下面几个方法都可以移除 Message：

public final void removeCallbacks(Runnable r);

public final void removeCallbacks(Runnable r, Object token);

public final void removeCallbacksAndMessages(Object token);

public final void removeMessages(int what);

public final void removeMessages(int what, Object object);

Application，Service，Activity三者的Context的应用场景

---

其中： NO1表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能创建