【面经】安卓常见内存泄漏及处理

前言

内存泄漏可以说伴随着我们的开发进程一直存在，为了更好的用户体验，我们需要进行相应的内存优化，下面列出的一些内存泄漏的场景能更好的帮助我们定位问题。

内存泄漏的定义

从有一组定义为gc root的根节点到目标对象的路径，称为可达性，此类对象也就是存活对象，不可达的对象就是应该被Gc垃圾回收机制进行回收的对象.在当前应用的生命周期内不再使用的对象，依然被gc root引用，导致无法回收，既造成了内存泄漏。

内存泄漏的问题

1、资源性对象未关闭

对于资源性对象不再使用时，应该立即调用它的close()函数，将其关闭，然后再置为null。例如Bitmap等资源未关闭会造成内存泄漏，此时我们应该在Activity销毁时及时关闭。

2、注册对象未注销各种Listener

例如BraodcastReceiver、EventBus未注销造成的内存泄漏，我们应该在Activity销毁时及时注销。

3、类的静态变量持有大数据对象

尽量避免使用静态变量存储数据，特别是大数据对象，建议使用数据库存储。

4、单例造成的内存泄漏

优先使用Application的Context，如需使用Activity的Context，可以在传入Context时使用弱引用进行封装，然后，在使用到的地方从弱引用中获取Context，如果获取不到，则直接return即可。

public class Singleton {
    private static Singleton instance;
    private Context mContext;
    private Singleton(Context context){
        this.mContext = context;
    }

    public static Singleton getInstance(Context context){
        if (instance == null){
            synchronized (Singleton.class){
                if (instance == null){
                    instance = new Singleton(context);
                }
            }
        }
        return instance;
    }
}

5、非静态内部类的静态实例

该实例的生命周期和应用一样长，这就导致该静态实例一直持有该Activity的引用，Activity的内存资源不能正常回收。此时，我们可以将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，尽量使用Application Context，如果需要使用Activity Context，就记得用完后置空让GC可以回收，否则还是会内存泄漏。

6、Handler临时性内存泄漏

Message发出之后存储在MessageQueue中，在Message中存在一个target，它是Handler的一个引用，Message在Queue中存在的时间过长，就会导致Handler无法被回收。如果Handler是非静态的，则会导致Activity或者Service不会被回收。并且消息队列是在一个Looper线程中不断地轮询处理消息，当这个Activity退出时，消息队列中还有未处理的消息或者正在处理的消息，并且消息队列中的Message持有Handler实例的引用，Handler又持有Activity的引用，所以导致该Activity的内存资源无法及时回收，引发内存泄漏。解决方案如下所示：

• 1、使用一个静态Handler内部类，然后对Handler持有的对象（一般是Activity）使用弱引用，这样在回收时，也可以回收Handler持有的对象。
• 2、在Activity的Destroy或者Stop时，应该移除消息队列中的消息，避免Looper线程的消息队列中有待处理的消息需要处理。

private static class MyHandler extends Handler{
        private WeakReference<MainActivity> mActivity;
        private MyHandler(MainActivity activity){
            mActivity = new WeakReference<MainActivity>(activity);
        }
        @Override
        public void handleMessage(@NonNull Message msg) {
            MainActivity mainActivity = mActivity.get();
            if(mainActivity != null){
                
            }
            super.handleMessage(msg);
        }
    }

需要注意的是，AsyncTask内部也是Handler机制，同样存在内存泄漏风险，但其一般是临时性的。对于类似AsyncTask或是线程造成的内存泄漏，我们也可以将AsyncTask和Runnable类独立出来或者使用静态内部类。

7、容器中的对象没清理造成的内存泄漏

在退出程序之前，将集合里的东西clear，然后置为null，再退出程序

@Override
    protected void onDestroy() {
        mList.clear();
        mList = null;
        super.onDestroy();
    }

8、WebView

WebView都存在内存泄漏的问题，在应用中只要使用一次WebView，内存就不会被释放掉。我们可以为WebView开启一个独立的进程，使用AIDL与应用的主进程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，达到正常释放内存的目的。

9、使用ListView时造成的内存泄漏

在构造Adapter时，使用缓存的convertView。

10、使用第三库传递context

在项目中经常会使用各种三方库，有些三方库的初始化需要我们传入一个 Context 对象,尽量使用 Context.getApplicationContext，不要直接将 Activity 传递给其他组件。

内存泄漏检测

这里直接推荐内存泄漏检测神器LeakCanary。

LeakCanary 是 Square 公司的一个开源库。通过它可以在 App 运行过程中检测内存泄漏，当内存泄漏发生时会生成发生泄漏对象的引用链，并通知程序开发人员。

欢迎关注公众号：君伟说，后台回复“技术交流”，邀你进群，一起进步