Android 内存泄漏

• 内存泄漏的原因
• 常见的内存泄漏与解决方法
• 检测内存泄漏

认识内存泄漏

根本原因就是当一个对象理应被回收的时候，因为在某个地方持有该对象的引用，导致它不能正常被 JVM 回收，而停留在堆内存中。
在 Android 中具体的例子大部分是：当我们关闭了一个 Activity/Fragment 时，此时 Activity/Fragment 变为不可见，内存中的实例也应当被回收，假如这时候还有别的对象实例强引用了 Activity/Fragment 的实例导致一直无法回收，则出现了内存泄漏。

关于 JAVA 的内存分配和回收，引用一段：

Java内存划分为栈、堆、方法区等区域，其中栈保存的是方法的局部变量，随方法起随方法灭，不需要GC；
堆保存所有对象的实例和数组，是GC和泄露的重点区；
方法区保存的是类信息、常量、静态变量等静态信息，也需要GC。
堆内存的回收中，判断对象存活的算法有引用计数算法和可达性分析算法，引用计数算法无法解决对象间循环引用的问题，虚拟机通常采用可达性分析算法。
常见的垃圾回收算法有：标记 - 清除法、复制算法、标记 - 整理法、分代回收算法。
常见的垃圾回收器种类有：Serial、ParNew、Parallel Scavenge等。

关于强引用：
对应的常用概念还有软引用、弱引用。

强引用特点是 JVM 即使内存耗尽也不会去自动回收该对象：

Object o = new Object();//强引用

而软引用在内存不足时，会被 JVM 回收：

Staff bean = new Staff();//仅用于创建软引用的实例
SoftReference<Staff> staffSR = new SoftReference<Staff>(bean);

//实际调用
String StaffID = staffSR.get().getId();

弱引用的使用和软引用类似，不同的是当 JVM 触发了 GC 时，不管当前内存空间足够与否，都会被回收：

Staff bean = new Staff();//仅用于创建弱引用的实例
WeakReference<Staff> staffWR = new WeakReference<Staff>(bean);

//实际调用
String StaffID = staffSR.get().getId();

内存泄漏的实例

日常的内存泄漏其实追溯到最后还是间接或直接的持有了 Activity/Fragment 的实例，但是有些确实防不胜防。一不注意就会踩雷。

• 单例造成的内存泄露

这个就是老生常谈了，因为单例的生命周期同应用一样长，又常有构造方法中需要传入 context 的情况。
这时候就要注意，如果传入了 Activity 的 Context，一不小心就会使这个单例持有了 Activity 的实例而出现内存泄漏。
所以这种情况下，一般用 Application 的 Context 来构造单例对象的实例。

((Activity)context).getApplicationContext();

• 非静态内部类造成内存泄漏

首先要回忆内部类的特性，内部类可以访问外部类的实例。
对于 JVM 来说，内部类和外部类其实是两个不同的类，正常来说两个类之间调用方法自然是通过两者的实例调用。
而非静态内部类之所以能访问外部类的方法，关键在于非静态内部类会默认隐性的持有外部类的实例。
但静态的内部类则不会持有外部类的实例。

相关的典型代码：

public class TestActivity extends Activity {

  private final Handler mTestHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
      //TODO
    }
  }
}

这时候的 Handler 是非静态的，所以该实例持有了 TestActivity 的实例。
当调用：

//延时发送消息
mTestHandler.postDelayed(new Runnable() {
    @Override
    public void run() { 
        //TODO
    }
}, 1000);

如果不清楚 Handler 的原理和源码的是时候去补习一下了。这时候 Handler 发送了 Message 实例，而这个 Message 实例引用了 Handler 实例，同时 Message 被主线程的 Looper 引用，此时的引用链：
Looper -> Message -> Handler -> Activity
这个时候即使调用 ((Activity)context).finish() Activity 也不能被回收。

所以上面的情况下要将 Handler 转化成静态类即可，或者继承 Handler 将隐性引用的 Activity 实例改为弱引用：

private static class MyHandler extends Handler {
    private final WeakReference<TestActivity> mActivity;

    public MyHandler(TestActivity activity) {
        mActivity = new WeakReference<TestActivity>(activity);
    }

    @Override
    public void handleMessage(Message msg) {
        TestActivity activity = mActivity.get();

        if (activity != null) {
                //TODO
        }
    }
}

和这个问题类似的还有线程造成的泄漏，两者的原因都是因为用了非静态的内部类：

public class ThreadTestActivity extends Activity {  

    private class MyThread extends Thread {  
        @Override  
        public void run() {  
            super.run();  
            //TODO 
        }  
    } 

• 关于非静态内部类还有另一个注意点：
  如果在非静态内部类中创建了一个静态的实例，这个操作相当于上面说的用 Activity 的实例来创建单例对象的实例：静态实例会一直持有 Activity(外部类) 的实例。

• 资源未关闭导致

Cursor、InputStream/OutputStream、File 等资源文件，如果仅仅是在使用结束后将引用赋为 null，而不调用关闭的方法，还是有可能会造成内存泄漏。

特别是 Cursor，使用数据库时如果没有处理好可能会出现 OOM 或 Could not allocate CursorWindow，就是因为没有关闭导致：

Cursor c ;
//TODO get Cursor
try { 
    c = query();  
    //TODO something
    c.close(); 
    //如果 try 中抛出异常,上面的 cursor.close() 很大可能不会执行
} catch (Exception e) { 

} finally{
    //如果没有 finally 块会容易出错
    if (c != null) {
        c.close();
    }
}

类似的还有广播、EventBus 等需要注册的同时也要记得在合适的地方注销。

• Android 5.0 以下的 Dialog 造成

这次负责的其中一个项目是运行在固定的设备上：Android 4.4.2 的大平板上，所以这个坑是实实在在的踩下去了。
AlertDialog 中的监听回调都是靠 Handler 来实现的：

/*
 * 以下代码出自 android-23 - android - app - Dialog
 */
public void show() {
    if (mShowing) {
        if (mDecor != null) {
            if (mWindow.hasFeature(Window.FEATURE_ACTION_BAR)) {
                mWindow.invalidatePanelMenu(Window.FEATURE_ACTION_BAR);
            }
            mDecor.setVisibility(View.VISIBLE);
        }
        return;
    }
    
    //省略部分代码

    try {
        mWindowManager.addView(mDecor, l);
        mShowing = true;

        sendShowMessage();
    } finally {
    }
}

@Override
public void dismiss() {
    if (Looper.myLooper() == mHandler.getLooper()) {
        dismissDialog();
    } else {
        mHandler.post(mDismissAction);
    }
}

而我们使用 Dialog 时 .setPositiveButton()、.setNegativeButton()、.setNeutralButton() 都以非静态内部类的形式实现，而这些点击的事件同样是通过 Handler 回调，这就会将这些内部类包装成一个 Message 传给 Dialog，这个 Message 就强引用了 Activity 的实例。
而 Dialog 在使用这些 Message 的时候会拷贝一个对象而不是用原来的对象：

private void sendDismissMessage() {
    if (mDismissMessage != null) {
        // Obtain a new message so this dialog can be re-used
        Message.obtain(mDismissMessage).sendToTarget();
    }
}

也就是说后面使用的是 Message 的拷贝。所以原来的 Message 从没有被发送，因此不会被回收，所以永久保存着它的内容，直到发生垃圾回收。

所以现在的引用链：
Thread(CookieSyncManager) -> Message -> AlertDialog$3(OnDismissListener) -> AlertDialog -> Activity

当然 5.0 以上已经解决了这个问题，所以这个案例可以看一看就过。

检测内存泄漏

不管用什么工具和方法，检测是否内存泄漏的方法都依靠 heap dump 文件。
heap dump 文件是一个二进制文件，保存了某一时刻 JVM 堆中对象使用情况，就是生成文件时的 Java 堆栈的快照。我们可以选择用 Heap Analyzer 分析 heap dump 文件，看哪些对象占用了太多的堆栈空间，或者哪些对象应该被回收却还在内存中。而 Leakcanary 等框架可以帮助我们省去一部分的工作。

• Leakcanary

build.gradle 中添加如下依赖：

dependencies {
    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.1'
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'
 }

在 Application 初始化：

public class MyApplication extends Application {

    private RefWatcher mWatcher;

    @Override 
    public void onCreate() {
        super.onCreate();
        mWatcher = LeakCanary.install(this);//此时已经可以检测到 Activity 的内存泄漏
    }

    public static RefWatcher getWatcher(Context context){
        return ((MyApplication)context.getApplicationContext()).mWatcher;
    }
}

检测 Fragment :

@Override
public void onDestroy() {
    super.onDestroy();
    //watch() 也可以传入别的对象实例来检测是否泄露
    MyApplication.getWatcher().watch(this);
}

Leakcanary 的 install(application) 相当于在 Activity 的 onDestroy() 中调用 watch(this)。

其原理是在 Activity / Fragment 销毁后，先手动促发一次 GC（系统 GC 并不会在销毁后立刻发生）
如果 watch(Object bean) 中传入的 bean 实例依然存在在内存中，则 dump heap 到本地，
dump 完成后启动 HeapAnalyzerService 服务读取本地 dump下来的文件，使用 HAHA 库进行分析。
如果检测到内存泄漏，将结果返回给 DisplayLeakService 服务，并且弹窗显示通知。

• Android Studio

在不想额外的依赖 Leakcanary 等框架是，利用 AS 自带的 Monitor 同样可以检测内存泄漏，只是多了一些步骤。

Android Monitor -> Monitor

Monitors

从左到右：
Initiate GC // 手动触发 GC。
Jump java heap// 获取 hprof 分析文件。
Start Allocation Tracking// 开始分配追踪。

在 Jump java heap 之前还是要记得触发一次 GC。点击后会生成一个 后缀为 hprof 的文件，在 AS 打开：

hprof

右边的 Analyzer Tasks 打开分析窗口：

Analyzer Tasks

右上角开始，在 Results 可以看到分析结果。