安卓-内存泄露处理

发表于 更新于 分类于 ，

对于开发老手，这个问题想必已经深入你的心；若是一名新手或者一直对内存泄漏这个东西模模糊糊的工程师，你的答案可能让面试官并不满意，这里将从底到上对内存泄漏的原因、排查方法和一些经验为你做一次完整的解剖。

处理内存泄漏的问题是将软件做到极致的一个必须的步骤，尤其是那种将被用户高强度使用的软件。

案例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class PendingOrderManager {
    private static PendingOrderManager instance;
    private Context mContext;

    public PendingOrderManager(Context context) {
        this.mContext = context;
    }

    public static PendingOrderManager getInstance(Context context) {
        if (instance == null) {
            instance = new PendingOrderManager(context);
        }
        return instance;
    }
　　 public void func(){
     ...
    }
...
}

然后让你的某个 Activity 去使用这个 PendingOrderManager 单例，并且某个时候退出这个 Activity:

1
2
3
4
5
//belong to some Activity
PendingOrderManager.getInstance(this).func();

...
finish()

这个时候内存泄漏已经发生：你退出了你的这个 Activity 本以为 java 的垃圾回收会将它释放，但实际上 Activity 一直被 PendingOrderManager 持有着。Acitivity 这个 Context 被长生命周期个体（单例一旦被创建就是整个 app 的生命周期）持有导致了这个 Context 发生了内存泄漏。

这个例子和上面的例子是相通的，上面的 C 的例子因为忘记了手动执行 free 一个 10 字节内存导致内存泄漏。而下面这个例子是垃圾回收机制“故意忘记”了回收 Context 的内存而导致了内存泄漏。下面两节将对这个里面到底发生了什么进行说明。

静态、堆和栈

编译原理说软件内存分配的时候一般会放在三种位置：静态存储区域、堆和栈，他们的位置、功能、速度都各不相同，区别如下：

  • 静态存储区：内存在程序编译的时候就已经分配好，这块内存在程序整个运行期间都存在。它主要存放静态数据、全局static数据和常量
  • 栈：就是 CPU 的寄存器（并不是内存），特点是容量很小但是速度最快，函数或者方法的的方法体内声明的变量或者指向对象的引用、局部变量即分配在这里，生命周期到该函数或者方法体尾部即止
  • 堆：就是动态内存分配去（就是实体的内存 RAM），C 中 malloc 和 fee，java 中的 new 和垃圾回收直接操作的就是这里的区域，类的成员变量分配在这里
    从上面即可看出静态存储区域是编译时已经分配好的，栈是CPU自动控制的，那么我们所讨论的内存泄漏的问题实际上就是分配在堆里面的内存出现了问题，一般问题在于两点：
  1. 快速不断的进行 new 操作。比如Android的自定义View的时候你在 onDraw 里面 new 出对象，就会导致这个自定义 View 的绘制特别卡，这是因为 onDraw 是快速重复执行的方法，在这个方法里面每次都 new 出对象会导致连续不断的 new 出新的对象，也导致 gc 也在不断的执行从而不断的回收堆内存。由于堆位于内存RAM上，这样子就导致了内存的不断的分配和回收消耗了 CPU，同时导致了内存出现“空洞”（因为堆内存不是连续的）
  2. 忘记释放。如果你忘记了手动释放应该释放的内存，或者 gc 误判导致没有释放本应该释放的内存，那么久导致了内存泄漏。由于 Android 给一个 app 可在堆上（可以在 AndroidManifest 设置一个 largeHeap=“true” 增大可分配量）分配的内存量是有限的，如果内存泄漏不断的发生，总有一天会消耗完毕，从而导致 OOM

Java有了垃圾回收（GC）为什么依然会内存泄漏

在Java中，内存的分配是由程序完成的，而内存的释放是由垃圾收集器(Garbage Collection，GC)完成的，程序员不需要通过调用函数来释放内存，但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间。但是误判是经常发生的，有些内存实际上已经没有用处了，但是 GC 并不知道。这里简单介绍下GC的机制：

上面一节说过栈上的局部变量可以引用堆上的分配的内存，所以 GC 发生的时候，一般是遍历一下静态存储区、栈从而列出所有堆上被他们引用的内存（对象）集合，这些内存都是有个引用计数，那么除此之外，其他的内存就是没有被引用的（或者说引用计数归零），这些内存就是要被释放的，随后 GC 开始清理这些内存（对象）

那么这里第一节的两个例子就很好理解了，那个单例模式由于生命周期太长（可以把他看作一个虚拟的栈中的局部变量）并且一直引用了Context（即 Activity），所以 GC 的时候发现这个 Activity 的引用计数还是大于1，所以回收内存的时候把他跳过，但实际上我们已经不需要这块内存了。这样就导致了内存泄漏。

Android使用弱引用和完美退出app的方法

从上面来看，内存泄漏因为对象被别人引用了而导致，java为了避免这种问题（假如你的单例模式必须要传入个Context），特地提供了几个特殊引用类型，其中一个叫做弱引用 WeakReference，当它引用一个对象的时候，即使该 WeakReference 的生命周期更长，但是只要发生GC，它就立即释放所被引用的内存而不会继续持有。

这里有一个常用的例子：

通常我们会在自定义的 Application 中来记住 app 中创建的 Activity，从而中途在某个 Activity 中需要完全退出 app 时可以完全的销毁所有已经打开的 Activity，这里我们可以对自定义 Application 改造，让其只有一个对 Activity 的弱引用的 HashMap，大致的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public class CustomApplication extends Application {

    private HashMap<String, WeakReference<Activity>> activityList = new HashMap<String, WeakReference<Activity>>();
    private static CustomApplication instance;

    public static CustomApplication getInstance() {
        return instance;
    }

    public void addActivity(Activity activity) {
        if (null != activity) {
            L.d("********* add Activity " + activity.getClass().getName());
            activityList.put(activity.getClass().getName(), new WeakReference<>(activity));
        }
    }


    public void removeActivity(Activity activity) {
        if (null != activity) {
            L.d("********* remove Activity " + activity.getClass().getName());
            activityList.remove(activity.getClass().getName());
        }
    }


    public void exit() {

        for (String key : activityList.keySet()) {
            WeakReference<Activity> activity = activityList.get(key);
            if (activity != null && activity.get() != null) {
                L.d("********* Exit " + activity.get().getClass().getSimpleName());
                activity.get().finish();
            }
        }

        System.exit(0);
        android.os.Process.killProcess(android.os.Process.myPid());
    }

}

我们在自定义的Activity的基类BaseActivity中的onCreate执行：
CustomApplication.getInstance().addActivity(this);

在BaseActivity的onDestroy中执行：
CustomApplication.getInstance().removeActivity(this);

哪些情况会导致内存泄漏

到此你应该对内存泄漏的本质已经有所了解了，这里列举出一些会导致内存泄漏的地方，可以作为排查内存泄漏的一个checklist

  • 某个集合类（List）被一个 static 变量引用，同时这个集合类没有删除自己内部的元素
  • 单例模式持有外部本应该被释放的对象（第一节中那个例子）
  • Android 特殊组件或者类忘记释放，比如：BraodcastReceiver 忘记解注册、Cursor 忘记销毁、Socket 忘记close、TypedArray 忘记 recycle、callback 忘记 remove。如果你自己定义了一个类，最好不要直接将一个Activity 类型作为他的属性，如果必须要用，要么处理好释放的问题，要么使用弱引用
  • Handler。只要 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象将被线程 MessageQueue 一直持有。由于 Handler 属于 TLS(Thread Local Storage) 变量, 生命周期和 Activity 是不一致的。因此这种实现方式一般很难保证跟 View 或者 Activity 的生命周期保持一致，故很容易导致无法正确释放。如上所述，Handler 的使用要尤为小心，否则将很容易导致内存泄露的发生。
  • Thread。如果 Thread 的 run 方法一直在循环的执行不停，而该 Thread 又持有了外部变量，那么这个外部变量即发生内存泄漏。
  • 网络请求或者其他异步线程。之前 Volley 会有这样的一个问题，在 Volley 的 response 来到之前如果 Activity 已经退出了而且 response 里面含有 Activity 的成员变量，会导致该 Activity 发生内存泄漏，该问题一直没有找到合适的解决办法。不过看来 Volley 官网已经注意到这个问题了，目前最新的版本已经 fix this leak。

使用 leakcanary

之前 Android 开发通常使用 MAT 内存分析工具来排查 heap 的问题，之类的文章比较多，大家可以自己找。这里推荐一个叫做 leakcanary 的工具，他可以集成在你的代码里面。这个东西大家可以参考：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0509/2854.html

特别鸣谢

文章改编于: 内存泄漏弄个明白 - soaringEveryday - 博客园
http://www.cnblogs.com/soaringEveryday/p/5035366.html