Android 常见内存泄露& 解决方案

概述前言 内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃 (OOM) 等严重后果。 那什么情况下不能被 前言

内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃 (OOM) 等严重后果。

那什么情况下不能被回收呢？

目前 java 垃圾回收主流算法是虚拟机采用 GC Roots Tracing 算法。算法的基本思路是：通过一系列的名为 GC Roots （GC 根节点）的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径，当一个对象到GC Roots没有任何引用链相连（图论说：从GC Roots 到这个对象不可达）时， 证明此对象是不可用的。

关于可达性的对象，便是能与 GC Roots 构成连通图的对象，如下图：

根搜索算法的基本思路就是通过一系列名为 "GC Roots" 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链 ( Reference Chain)，当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。

从上图，reference1、reference2、reference3 都是 GC Roots，可以看出：

reference1-> 对象实例1；

reference2-> 对象实例2；

reference3-> 对象实例4；

reference3-> 对象实例4 -> 对象实例6；

可以得出对象实例1、2、4、6都具有 GC Roots 可达性，也就是存活对象，不能被 GC 回收的对象。

而对于对象实例3、5直接虽然连通，但并没有任何一个 GC Roots 与之相连，这便是 GC Roots 不可达的对象，这就是 GC 需要回收的垃圾对象。

在了解 GC 之后，开始去了解 AndroID 的内存泄露情况了。

AndroID 内存泄露场景 

 下面会详细介绍一些常见的内存泄露场景，以及对应的修复办法。

 非静态内部类的静态实例

比如我们在 Activity 内部定义了一个内部类 InnerClass，同时定义了一个静态变量 inner，并给予赋值。假设你在 onDestory 的时候没有将 inner 置 null；那么就会引起内存泄露。原因是静态变量持有了内部类的实例，内部类会对外部类有个引用，从而导致 Activity 得不到释放。

    private static Object inner;               voID createInnerClass() {           class InnerClass {            }            inner = new InnerClass();        }        VIEw icbutton = findVIEwByID(R.ID.ic_button);    icbutton.setonClickListener( VIEw.OnClickListener() {        @OverrIDe public  onClick(VIEw v) {            createInnerClass();            nextActivity();        }    });

记得在生命周期结束的时候，将不需要的静态变量置 null。

多线程相关的匿名内部类/非静态内部类

和非静态内部类一样，匿名内部类也会持有外部类实例的引用。多线程相关的类有 AsyncTask 类，Thread 类和 Runnable 接口的类等，它们的匿名内部类如果做耗时 *** 作
就可能发生内存泄露，这里以 AsyncTask 的匿名内部类举例，如下所示：

     startAsyncTask() {        new AsyncTask<VoID,VoID,VoID>() {            @OverrIDe protected VoID doInBackground(VoID... params) {                while(true);            }        }.execute();    }        super.onCreate(savedInstanceState);    setContentVIEw(R.layout.activity_main);    VIEw aicbutton = findVIEwByID(R.ID.at_button);    aicbutton.setonClickListener( onClick(VIEw v) {            startAsyncTask();            nextActivity();        }    });

当异步任务在后台执行耗时任务期间，Activity 不幸被销毁了（比如：用户退出，系统回收），这个被 AsyncTask 持有的 Activity 实例就不会被垃圾回收器回收，直到异步任务结束。
解决方法是继承 AsyncTask 新建一个静态内部类，用静态内部类创建实例就不会存在对外部实例的引用了。

 

Handler 内存泄露

同样道理，Handler 的 message 被传递到消息队列 MessageQueue 中，在 Message 消息没有被处理之前，handler 的实例也不无法被回收，如果 handler 实例不是静态的，就会导致引用它的 activity 或者 service 不能被回收，于是就会发生内存泄漏。

     createHandler() {         Handler() {            @OverrIDe  handleMessage(Message message) {                .handleMessage(message);            }        }.sendMessageDelayed(Message.obtain(),60000);    }            VIEw hbutton = findVIEwByID(R.ID.h_button);    hbutton.setonClickListener( onClick(VIEw v) {            createHandler();            nextActivity();        }    });

 对于上述问题，有两种解决办法，一种是使用一个静态的 handler 内部类，并且其持有的对象都改成弱引用形式进行引用。还有一种是在销毁 activity 的时候，将发送的消息进行移除。

myHandler.removeCallbackAndMessages(null);

这种有个问题就是 Handler 中的消息可能无法全部被处理完。

另外还有一个要注意的是，最好不要直接使用 VIEw#post 来做一些 *** 作。如果要用，确保要用的话，确保 vIEw 已经被 attach 到了 window。

具体可以参考：View的post方法导致的内存泄漏分析

静态 Activity 或 VIEw在类中定义了静态Activity变量，把当前运行的Activity实例赋值于这个静态变量。
如果这个静态变量在Activity生命周期结束后没有清空，就导致内存泄漏。因为 static 变量是贯穿这个应用的生命周期的，所以被泄漏的 Activity 就会一直存在于应用的进程中，不会被垃圾回收器回收。

 Activity activity;         setStaticActivity() {      activity = this;    }        VIEw sabutton = findVIEwByID(R.ID.sa_button);    sabutton.setonClickListener( VIEw.OnClickListener() {      @OverrIDe  onClick(VIEw v) {        setStaticActivity();        nextActivity();      }    });

为了能够被回收，需要在不需要使用的时候进行置 null *** 作。比如销毁当前 activity 的时候。

特殊情况：如果一个 VIEw 初始化耗费大量资源，而且在一个 Activity 生命周期内保持不变，那可以把它变成 static，加载到视图树上 (VIEw HIErachy)，像这样，当 Activity 被销毁时，应当释放资源。

 vIEw;         setStaticVIEw() {      vIEw = findVIEwByID(R.ID.sv_button);    }        VIEw svbutton = findVIEwByID(R.ID.sv_button);    svbutton.setonClickListener( onClick(VIEw v) {        setStaticVIEw();        nextActivity();      }    });

同样的，为了解决内存泄露的问题，在 Activity 销毁的时候把这个 static vIEw 置 null 即可，但是还是不建议用这个 static vIEw的方法。

Eventbus 等注册监听造成的内存泄露

相信很多同学都在项目里面会用到 Eventbus。对于一些没有经验的同学在使用的时候经常会出现一些问题。比如说在 onCreate 的时候进行注册，却忘了反注册，或者说，在onStop的时候进行反注册，这些都会导致 Eventbus 的内存泄露。

@OverrIDe onCreate(@Nullable Bundle savedInstanceState) {    .onCreate(savedInstanceState);    EventBus.getDefault().register(this);// 注意在onCreate()方法中注册}@OverrIDe onDestroy() {    EventBus.getDefault().unregister( 注意在onDestory()方法中注册    .onDestroy();}

注册和反注册（取消注册）是对应的，必须要添加，否则会引起组件的内存泄漏。因为注册的时候组件是被 EventBus 内部的单例队列所持有引用的。

如果你是在 VIEw 里面注册 Eventbus 的，记得是在 VIEw 的生命周期 onAttachedToWindow 和 onDetachedFromWindow 的时候进行注册和反注册。

最近跟我的同事进行聊天的时候发现，他们为了解决 eventbus 导致的内存泄露问题（已经成对注册和反注册还是存在内存泄露问题），于是打算创建一个 object 的实例，用这个来进行注册与反注册，这样即使发生内存泄露也只会占用很小的内存空间。

单例引起的内存泄露

项目中，经常会存在很多单例。有时候需要我们将当前 Activity 实例传给单例，然后去做一些事情。如下面的代码：

 SingleInstance {    private Context mContext;     SingleInstance instance;      SingleInstance(Context context) {        this.mContext = context;    }      SingleInstance getInstance(Context context) {        if (instance == null) {            instance =  SingleInstance(context);        }        return instance;    }}

 上述单例中传入一个 context ，就会导致 context 的生命时长和应用的生命时长一样。就会造成内存泄露。

对于这种有三种解决办法：

1、采用弱引用的方式进行引用，确保能够被回收；

2、在对应的 context 要被销毁的时候，进行置 null；确保不会长于原本的生命时长；

3、看是否能够使用 APP context；这样就不会存在内存泄露的问题了。

资源对象没关闭造成内存泄漏

当我们打开资源时，一般都会使用缓存。比如读写文件资源、打开数据库资源、使用 Bitmap 资源等等。当我们不再使用时，应该关闭它们，使得缓存内存区域及时回收。虽然有些对象，如果我们不去关闭，它自己在 finalize() 函数中会自行关闭。但是这得等到 GC 回收时才关闭，这样会导致缓存驻留一段时间。如果我们频繁的打开资源，内存泄漏带来的影响就比较明显了。

解决办法：及时关闭资源

 

WebVIEw 

不同的AndroID 版本的 webVIEw 会有差异，加上不同的厂商定制的 ROM 的 webVIEw 差异，这就导致 webVIEw 存在很大的兼容性问题。weVIEw 都会存在内存泄露问题，在应用中只要使用一次，内存就不会被释放。通常的做法是为 webVIEw 单独开一个进程，使用 AIDL 与应用的主进程进程通信。webVIEw 进程可以根据业务的需求，在合适的时机进行销毁。

 

 参考文献：

1、《AndroID进阶解密》

2、Android内存泄漏的八种可能 

 

总结

以上是内存溢出为你收集整理的Android 常见内存泄露 & 解决方案全部内容，希望文章能够帮你解决Android 常见内存泄露 & 解决方案所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。