Android性能优化之利用强大的LeakCanary检测内存泄漏及解决办法

概述前言：最近公司C轮融资成功了，移动团队准备扩大一下，需要招聘Android开发工程师，陆陆续续面试了几位Android应聘者，面试过程中聊到性能优化中如何避免内存泄漏问题时，很少有人全面的回答上来。所以决定抽空学习

前言：

最近公司C轮融资成功了，移动团队准备扩大一下，需要招聘AndroID开发工程师，陆陆续续面试了几位AndroID应聘者，面试过程中聊到性能优化中如何避免内存泄漏问题时，很少有人全面的回答上来。所以决定抽空学习总结一下这方面的知识，以及分享一下我们是如何检测内存泄漏的。我们公司使用开源框架LeakCanary来检测内存泄漏。

什么是内存泄漏？

有些对象只有有限的生命周期。当它们的任务完成之后，它们将被垃圾回收。如果在对象的生命周期本该结束的时候，这个对象还被一系列的引用，这就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。

内存泄漏造成什么影响？

它是造成应用程序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检测结果如下：

解决 办法要保证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检测结果如下：

要想避免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");      }    },3 * 60 * 1000);    finish();  }  @OverrIDe  protected voID onDestroy() {    super.onDestroy();    mHandler.removeCallbacksAndMessages(null);    mHandler=null;    LApplication.getRefWatcher().watch(this);  }}

3.)线程造成的内存泄漏

最早时期的时候处理耗时 *** 作多数都是采用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,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检测结果：

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

public class MainActivity3 extends AppCompatActivity {  private AsyncTask<VoID,"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);  }}

 4.）非静态内部类创建静态实例造成的内存泄漏

有时我们需要一个可以随着屏幕旋转的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检测内存泄漏结果如下：

对于这种泄漏的解决办法就是将内部类改成静态内部类，不再持有对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;    }  }}

 5.）由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);  }}

xml布局文件：

<?xml version="1.0" enCoding="utf-8"?><linearLayout  xmlns:androID="http://schemas.androID.com/apk/res/androID"  androID:ID="@+ID/activity_main"  androID:layout_wIDth="match_parent"  androID:layout_height="match_parent"  androID:orIEntation="vertical">  <WebVIEw    androID:ID="@+ID/web"    androID:layout_wIDth="wrap_content"    androID:layout_height="wrap_content"/></linearLayout>

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

private voID destroyWebVIEw() {    if (mWebVIEw != null) {      mlinearLayout.removeVIEw(mWebVIEw);      mWebVIEw.pauseTimers();      mWebVIEw.removeAllVIEws();      mWebVIEw.destroy();      mWebVIEw = null;    }  }

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

该如何解决呢？这个查了不少资料，其中一种就是使用getApplicationgContext作为参数构建WebVIEw，然后动态添加到一个VIEwGroup中，最后退出的时候调用webVIEw的销毁的函数，虽然也达到了防止内存溢出的效果，但是在有些网页d出时候需要记住密码的对话框的时候，会出现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;    }  }}

manifest中对应的activity配置如下：

<activity  androID:name=".MainActivity5"  androID:process="com.whoislcj.webvIEw"/>

6.）资源未关闭造成的内存泄漏

 对于使用了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);    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();    }

总结：

以上就是通过LeakCanary检测到的内存泄漏情况以及解决办法。希望对大家的学习有所帮助，也希望大家多多支持编程小技巧。

总结

以上是内存溢出为你收集整理的Android性能优化之利用强大的LeakCanary检测内存泄漏及解决办法全部内容，希望文章能够帮你解决Android性能优化之利用强大的LeakCanary检测内存泄漏及解决办法所遇到的程序开发问题。

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