LeakCanary检测内存泄漏及解决办法

内存泄漏定义

内存泄漏造成的影响

LeakCanary工具

LeakCanary捕获常见内存泄漏以及解决办法

1、错误使用单例造成的内存泄漏

2、Handler造成的内存泄漏

3、Activity 内部类接口回调监听

4、线程造成的内存泄漏

5、非静态内部类创建静态实例造成的内存泄漏

6、由WebView引起的内存泄漏

7、资源未关闭造成的内存泄漏

8、集合类

内存泄漏定义

内存泄露是指无用对象(不再使用的对象)持续占有内存或无用对象的内存得不到及时释放，从而造成的内存空间的浪费称为内存泄露。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。

内存泄漏的根本原因是长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象已经不再需要，但由于长生命周期对象持有它的引用而导致不能被回收。

内存泄漏造成的影响

它是造成应用程序OOM的主要原因之一。由于android系统为每个应用程序分配的内存有限，当一个应用中产生的内存泄漏比较多时，就难免会导致应用所需要的内存超过这个系统分配的内存限额，这就造成了内存溢出而导致应用Crash。

LeakCanary工具

leakCanary是Square开源框架，是一个Android和Java的内存泄露检测库，如果检测到某个 activity 有内存泄露，LeakCanary 就是自动地显示一个通知，所以可以把它理解为傻瓜式的内存泄露检测工具。通过它可以大幅度减少开发中遇到的oom问题，大大提高APP的质量。

LeakCanary捕获常见内存泄漏以及解决办法

1、错误使用单例造成的内存泄漏

在平时开发中单例设计模式是我们经常使用的一种设计模式，而在开发中单例经常需要持有Context对象，如果持有的Context对象生命周期与单例生命周期更短时，或导致Context无法被释放回收，则有可能造成内存泄漏，错误写法如下：

public class LoginManager {
    private static LoginManager mInstance;
    private Context mContext;

    private LoginManager(Context context) {
        this.mContext = context;
    }


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

    public void dealData() {
    }

}

若我们在一个Activity中调用的，然后关闭该Activity则会出现内存泄漏。

LoginManager.getInstance(this).dealData();

LeakCanary检测结果如下：

LeakCanary检测内存泄漏及解决办法

解决办法要保证Context和AppLication的生命周期一样，修改后代码如下：

public class LoginManager {
    private static LoginManager mInstance;
    private Context mContext;

    private LoginManager(Context context) {
    //生命周期
        this.mContext = context.getApplicationContext();
    }


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

    public void dealData() {
    }

}

2、Handler造成的内存泄漏

Handler的使用频率还是蛮高的，它是工作线程与UI线程之间通讯的桥梁，只是现在大量开源框架对其进行了封装，我们这里模拟一种常见使用方式来模拟内存泄漏情形。

public class MainActivity extends AppCompatActivity {
    private Handler mHandler = new Handler();
    private TextView mTextView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView) findViewById(R.id.text);//模拟内存泄露
        mHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                mTextView.setText("lcj");
            }
        }, 3 * 60 * 1000);
        finish();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        LApplication.getRefWatcher().watch(this);
    }
}

上述代码通过内部类的方式创建mHandler对象,此时mHandler会隐式地持有一个外部类对象引用这里就是MainActivity，当执行postDelayed方法时，该方法会将你的Handler装入一个Message，并把这条Message推到MessageQueue中，MessageQueue是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息，而消息队列中的Message持有mHandler实例的引用，mHandler又持有Activity的引用，所以导致该Activity的内存资源无法及时回收，引发内存泄漏。

LeakCanary检测结果如下：

LeakCanary检测内存泄漏及解决办法

要想避免Handler引起内存泄漏问题，需要我们在Activity关闭退出的时候的移除消息队列中所有消息和所有的Runnable。上述代码只需在onDestroy()函数中调用mHandler.removeCallbacksAndMessages(null);就行了。

public class MainActivity1 extends AppCompatActivity {
    private Handler mHandler = new Handler();
    private TextView mTextView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView) findViewById(R.id.text);
        //模拟内存泄露
        mHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                mTextView.setText("lcj"); //主线程更新ui
            }
        }, 3 * 60 * 1000);
        finish();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
        mHandler=null;
        LApplication.getRefWatcher().watch(this);
    }
}

handler基本使用 https://blog.csdn.net/ly502541243/article/details/52062179/

//handler内存泄露的解决方案

方法一：通过程序逻辑来进行保护。

1.在关闭Activity的时候停掉你的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。

2.如果你的Handler是被delay的Message持有了引用，那么使用相应的Handler的removeCallbacks()方法，把消息对象从消息队列移除就行了。

方法二：将Handler声明为静态类。

PS:在Java 中，非静态的内部类和匿名内部类都会隐式地持有其外部类的引用，静态的内部类不会持有外部类的引用。

静态类不持有外部类的对象，所以你的Activity可以随意被回收。由于Handler不再持有外部类对象的引用，导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用（WeakReference）。

static class MyHandler extends Handler
    {
        WeakReference<Activity> mWeakReference;
        public MyHandler(Activity activity) 
        {
            mWeakReference=new WeakReference<Activity>(activity);
        }
        @Override
        public void handleMessage(Message msg)
        {
            final Activity activity=mWeakReference.get();
            if(activity!=null)
            {
                if (msg.what == 1)
                {
                    noteBookAdapter.notifyDataSetChanged();
                }
            }
        }
    }

说明:

WeakReference弱引用，与强引用（即我们常说的引用）相对，它的特点是，GC在回收时会忽略掉弱引用，即就算有弱引用指向某对象，但只要该对象没有被强引用指向（实际上多数时候还要求没有软引用，但此处软引用的概念可以忽略），该对象就会在被GC检查到时回收掉。对于上面的代码，用户在关闭Activity之后，就算后台线程还没结束，但由于仅有一条来自Handler的弱引用指向Activity，所以GC仍然会在检查的时候把Activity回收掉。这样，内存泄露的问题就不会出现了。

3、Activity 内部类接口回调监听

在编码中常常会定义各种接口回调，类似有点击时间监听OnClickListener，这些回调监听有时候就定义在Activity内部，或者直接用Activity对象去实现这个接口，到时候设置监听的时候直接调用setListener(innerListener)或者setListener(this)，innerListener是Activity内部定义的，this就是Activity对象，那么问题来了，回调监听并不一定马上返回，只有在触发条件满足的时候才会回调，这个时间是无法确定的，因此在Activity退出的时候应该显示的把回调监听都移除掉setListener(null)，既释放了回调监听对象占用的内存，也避免回调监听继续持有activity引用；对与内部类还有一种解决方式，和内部Handler相似，定义成static内部类，然后把Activity对象的弱引用传递进去，这样也就万无一失

4、线程造成的内存泄漏

最早时期的时候处理耗时操作多数都是采用Thread+Handler的方式，后来逐步被AsyncTask取代，直到现在采用RxJava的方式来处理异步。这里以AsyncTask为例，可能大部分人都会这样处理一个耗时操作然后通知UI更新结果：

public class MainActivity extends AppCompatActivity {
    private AsyncTask<Void, Void, Integer> asyncTask;
    private TextView mTextView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView) findViewById(R.id.text);
        testAsyncTask();
        finish();
    }

    private void testAsyncTask() {
        asyncTask = new AsyncTask<Void, Void, Integer>() {
            @Override
            protected Integer doInBackground(Void... params) {
                int i = 0;
                //模拟耗时操作
                while (!isCancelled()) {
                    i++;
                    if (i > 1000000000) {
                        break;
                    }
                    Log.e("LeakCanary", "asyncTask---->" + i);
                }
                return i;
            }

            @Override
            protected void onPostExecute(Integer integer) {
                super.onPostExecute(integer);
                mTextView.setText(String.valueOf(integer));
            }
        };
        asyncTask.execute();

    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        LApplication.getRefWatcher().watch(this);
    }

}

对于上面的例子来说，在处理一个比较耗时的操作时，可能还没处理结束MainActivity就执行了退出操作，但是此时AsyncTask依然持有对MainActivity的引用就会导致MainActivity无法释放回收引发内存泄漏。

LeakCanary检测结果：

LeakCanary检测内存泄漏及解决办法

如何解决这种内存泄漏呢？在使用AsyncTask时，在Activity销毁时候也应该取消相应的任务AsyncTask.cancel()方法，避免任务在后台执行浪费资源，进而避免内存泄漏的发生。

public class MainActivity3 extends AppCompatActivity {
    private AsyncTask<Void, Void, Integer> asyncTask;
    private TextView mTextView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView) findViewById(R.id.text);
        testAsyncTask();
        finish();
    }

    private void testAsyncTask() {
        asyncTask = new AsyncTask<Void, Void, Integer>() {
            @Override
            protected Integer doInBackground(Void... params) {
                int i = 0;
                //模拟耗时操作
                while (!isCancelled()) {
                    i++;
                    if (i > 1000000000) {
                        break;
                    }
                    Log.e("LeakCanary", "asyncTask---->" + i);
                }
                return i;
            }

            @Override
            protected void onPostExecute(Integer integer) {
                super.onPostExecute(integer);
                mTextView.setText(String.valueOf(integer));
            }
        };
        asyncTask.execute();

    }

    private void destroyAsyncTask() {
        if (asyncTask != null && !asyncTask.isCancelled()) {
            asyncTask.cancel(true);
        }
        asyncTask = null;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        destroyAsyncTask();
        LApplication.getRefWatcher().watch(this);
    }

}

如果内部线程的生命周期比Activity的生命周期要长，那么内部线程任然默认持有Activity的引用，导致Activity对象无法被回收，但是当这个线程执行完了之后，Activity对象就能被成功的回收了，这会造成一个崩溃风险，可能在线程里面有调用到一些Activity的内部对象，但是在Activity退出后这些对象有可能有些已经被回收了，就变成null了，这时候要是不进行null的判断就会报空指针异常，如果这个线程是一直跑的，那就会造成Activity对象一直不会被回收了，因此，在activity退出后一定要做相关的清理操作，中断线程，取消网络请求等等

5、非静态内部类创建静态实例造成的内存泄漏

注意:静态变量的生命周期和应用程序一致%

我们先来看看非静态内部类（non static inner class）和静态内部类（static inner class）之间的区别

LeakCanary检测内存泄漏及解决办法

可以看到非静态内部类自动获得外部类的强引用，而且它的生命周期甚至比外部类更长，这便埋下了内存泄露的隐患。如果一个 Activity 的非静态内部类的生命周期比 Activity 更长，那么 Activity 的内存便无法被回收，也就是发生了内存泄露，而且还有可能发生难以预防的空指针问题。

有时我们需要一个可以随着屏幕旋转的Activity，比如视频播放Activity，这时我们为了防止多次调用onCreate方法导致某些参数重新初始化，我们一般会选择创建一个内部类和一个静态实例来保存这些参数，比如以下实现：

public class MainActivity extends AppCompatActivity {
    private static Config mConfig;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //模拟内存泄露
        if (mConfig == null) {
            mConfig = new Config();
            mConfig.setSize(18);
            mConfig.setTitle("老九门");
        }
        finish();
    }


    @Override
    protected void onDestroy() {
        super.onDestroy();
        LApplication.getRefWatcher().watch(this);
    }

    class Config {
        private int size;
        private String title;

        public int getSize() {
            return size;
        }

        public void setSize(int size) {
            this.size = size;
        }

        public String getTitle() {
            return title;
        }

        public void setTitle(String title) {
            this.title = title;
        }
    }
}

上述代码看着没有任何问题，其实内部类都会持有一个外部类引用，这里这个外部类就是MainActivity，然而内部类实例又是static静态变量其生命周期与Application生命周期一样，所以在MainActivity关闭的时候，内部类静态实例依然持有对MainActivity的引用，导致MainActivity无法被回收释放，引发内存泄漏。LeakCanary检测内存泄漏结果如下：

LeakCanary检测内存泄漏及解决办法

对于这种泄漏的解决办法就是将内部类改成静态内部类，不再持有对MainActivity的引用即可，修改后的代码如下：

public class MainActivity extends AppCompatActivity {
    private static Config mConfig;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //模拟内存泄露
        if (mConfig == null) {
            mConfig = new Config();
            mConfig.setSize(18);
            mConfig.setTitle("老九门");
        }
        finish();
    }


    @Override
    protected void onDestroy() {
        super.onDestroy();
        LApplication.getRefWatcher().watch(this);
    }

    static class Config {
        private int size;
        private String title;

        public int getSize() {
            return size;
        }

        public void setSize(int size) {
            this.size = size;
        }

        public String getTitle() {
            return title;
        }

        public void setTitle(String title) {
            this.title = title;
        }
    }
}

6、由WebView引起的内存泄漏

在目前的开发中多多少少会用到Hybrid开发方式，这样我们就会用WebView去承载Html网页，就如下面这种方式：

java代码：

public class MainActivity5 extends AppCompatActivity {
    private WebView mWebView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_web);
        mWebView = (WebView) findViewById(R.id.web);
        mWebView.loadUrl("http://www.cnblogs.com/whoislcj/p/5720202.html");
    }


    @Override
    protected void onDestroy() {
        super.onDestroy();
        LApplication.getRefWatcher().watch(this);
    }

}

WebView解析网页时会申请Native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。及时Activity关闭时在onDestroy中调用如下代码也是没有任何作用。

private void destroyWebView() {
        if (mWebView != null) {
            mLinearLayout.removeView(mWebView);
            mWebView.pauseTimers();
            mWebView.removeAllViews();
            mWebView.destroy();
            mWebView = null;
        }
    }

先看下LeakCanary检测到的结果如下：

LeakCanary检测内存泄漏及解决办法

该如何解决呢？这个查了不少资料，其中一种就是使用getApplicationgContext作为参数构建WebView，然后动态添加到一个ViewGroup中，最后退出的时候调用webView的销毁的函数，虽然也达到了防止内存溢出的效果，但是在有些网页弹出时候需要记住密码的对话框的时候，会出现Unable to add window -- token null is not for an application 的错误，所以这里采用的解决办法是通过把使用了WebView的Activity(或者Service)放在单独的进程里。然后在检测到应用占用内存过大有可能被系统干掉或者它所在的Activity(或者Service)结束后，调用android.os.Process.killProcess(android.os.Process.myPid());，主动Kill掉进程。由于系统的内存分配是以进程为准的，进程关闭后，系统会自动回收所有内存。

修改后的代码如下：

public class MainActivity5 extends AppCompatActivity {
    private WebView mWebView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_web);
        mWebView = (WebView) findViewById(R.id.web);
        mWebView.loadUrl("http://www.cnblogs.com/whoislcj/p/5720202.html");
    }

    @Override
    protected void onDestroy() {
        destroyWebView();
        android.os.Process.killProcess(android.os.Process.myPid());
        super.onDestroy();
        LApplication.getRefWatcher().watch(this);

    }

    private void destroyWebView() {
        if (mWebView != null) {
            mWebView.pauseTimers();
            mWebView.removeAllViews();
            mWebView.destroy();
            mWebView = null;
        }
    }

}

7、资源未关闭造成的内存泄漏

对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。例如获取媒体库图片地址代码在查询结束的时候一定要调用

Cursor 的关闭方法防止造成内存泄漏。

String columns[] = new String[]{
                MediaStore.Images.Media.DATA, MediaStore.Images.Media._ID, MediaStore.Images.Media.TITLE, MediaStore.Images.Media.DISPLAY_NAME
        };
        Cursor cursor = this.getContentResolver().query(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, columns, null, null, null);
        if (cursor != null) {
            int photoIndex = cursor.getColumnIndexOrThrow(MediaStore.Images.Media.DATA);
            //显示每张图片的地址，但是首先要判断一下，Cursor是否有值
            while (cursor.moveToNext()) {
                String photoPath = cursor.getString(photoIndex); //这里获取到的就是图片存储的位置信息
                Log.e("LeakCanary", "photoPath---->" + photoPath);
            }
            cursor.close();
        }

8、集合类

集合类添加元素后，仍引用着集合元素对象，导致该集合中的元素对象无法被回收，从而导致内存泄露，举个例子：

static List<Object> objectList = new ArrayList<>();
   for (int i = 0; i < 10; i++) {
       Object obj = new Object();
       objectList.add(obj);
       obj = null;
    }

在这个例子中，循环多次将 new 出来的对象放入一个静态的集合中，因为静态变量的生命周期和应用程序一致，而且他们所引用的对象 Object 也不能释放，这样便造成了内存泄露。

解决方法:

在集合元素使用之后从集合中删除，等所有元素都使用完之后，将集合置空。

objectList.clear();
    objectList = null;

转载链接：LeakCanary检测内存泄漏及解决办法

LeakCanary检测内存泄漏及解决办法

内存泄漏定义

内存泄漏造成的影响

LeakCanary工具

LeakCanary捕获常见内存泄漏以及解决办法

1、错误使用单例造成的内存泄漏

2、Handler造成的内存泄漏

3、Activity 内部类接口回调监听

4、线程造成的内存泄漏

5、非静态内部类创建静态实例造成的内存泄漏

6、由WebView引起的内存泄漏

7、资源未关闭造成的内存泄漏

8、集合类

继续阅读

专访邓凡平：深入理解Android

与专家面对面：Android开发入门问与答

Android MVP架构MVCMVP

mvp初探

Android常用工具类简介目录

android常用工具类转载自：http://www.trinea.cn/android/android-common-utils/Android常用工具类

Android常用工具类ToastUtilsSizeUtilsLogUtilsRetrofitManagerAnimUtil

Android Studio 0.8.0解决 Failure [INSTALL_FAILED_OLDER_SDK] 问题

Android – ListView 中添加按钮，动态删除添加ItemView的操作

Kotlin的ListView与RecyclerView的简单应用

关于公司的那些坑：Android Studio篇

android SQLite事务和kotlin协程

无法正常编译错误Compilation failed to complete

关于Gradle配置的小结

AOP编程_Android优雅权限框架(1)概念基础，2021金三银四前言正文大纲正文

Android APK文件反编译Android APK文件反编译