Android性能优化之利用强大的LeakCanary检测内存泄漏及解决办法_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, 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, 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);
  }

}

 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的销毁的函数，虽然也达到了防止内存溢出的效果，但是在有些网页弹出时候需要记住密码的对话框的时候，会出现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, 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
leakcanary、leakcanary使用教程、leakcanary eclipse、android leakcanary、leakcanary github，以便于您获取更多的相关知识。

时间： 2024-08-04 01:43:44

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

Android app启动时黑屏或者白屏的原因及解决办法_Android

1.产生原因 其实显示黑屏或者白屏实属正常,这是因为还没加载到布局文件,就已经显示了window窗口背景,黑屏白屏就是window窗口背景. 示例: 2.解决办法 通过设置设置Style (1)设置背景图Theme 通过设置一张背景图. 当程序启动时,首先显示这张背景图,避免出现黑屏 <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar"> <item name=&qu

Android Fragment中使用SurfaceView切换时闪一下黑屏的解决办法_Android

重构了下之前自己的一个新闻客户端,全部使用了Fragment来进行页面切换,只有一个入口Activity作为程序的启动Activity,其中有一个界面需要调用摄像头识别二维码,于是就会用到SurfaceView进行预览,那么问题来了,当切换到对应的Fragment时,屏幕会黑一下,黑了1秒左右就显示出正常的界面,而且这种现象只有第一次进入该Fragment才会出现,之后进入都不会出现,解决方法是无意在github上看到了,试了一下,可以行的通,下面贴出解决方法. 方法一.在Activity的on

Android性能优化之利用Rxlifecycle解决RxJava内存泄漏详解

前言: 其实RxJava引起的内存泄漏是我无意中发现了,本来是想了解Retrofit与RxJava相结合中是如何通过适配器模式解决的,结果却发现了RxJava是会引起内存泄漏的,所有想着查找一下资料学习一下如何解决RxJava引起的内存泄漏,就查到了利用Rxlifecycle开源框架可以解决,今天周末就来学习一下如何使用Rxlifecycle. 引用泄漏的背景: RxJava作为一种响应式编程框架,是目前编程界网红,可谓是家喻户晓,其简洁的编码风格.易用易读的链式方法调用.强大的异步支持等使得R

Android群英传笔记——第十章：Android性能优化

Android群英传笔记--第十章:Android性能优化 随着Android应用增多,功能越来越复杂,布局也越来越丰富了,而这些也成为了阻碍一个应用流畅运行,因此,对复杂的功能进行性能优化是创造高质量应用的基础,本章节将为大家展示几种性能优化的方法,帮助开发者快速的构建运行速度快,相应速度快的应用程序 布局优化 内存优化 使用各种工具进行分析,优化 一.布局优化 系统在渲染图片的时候需要消耗大量的资源,一个好的UI,不仅要有良好的视觉体验,更应该具有良好的使用体验,因此布局优化就显得很重要了

Android性能优化典范 - 第2季

Google前几天刚发布了Android性能优化典范第2季的课程,一共20个短视频,包括的内容大致有:电量优化,网络优化,Wear上如何做优化,使用对象池来提高效率,LRU Cache,Bitmap的缩放,缓存,重用,PNG压缩,自定义View的性能,提升设置alpha之后View的渲染性能,以及Lint,StictMode等等工具的使用技巧. 下面是对这些课程的总结摘要,认知有限,理解偏差的地方请多多指教! 1)Battery Drain and Networking 对于手机程序,网络操作相

Android性能优化方法_Android

GPU过度绘制  •打开开发者选型,"调试GPU过度绘制",蓝.绿.粉红.红,过度绘制依次加深  •粉红色尽量优化,界面尽量保持蓝绿颜色  •红色肯定是有问题的,不能忍受 使用HierarchyView分析布局层级  •删除多个全屏背景:应用中不可见的背景,将其删除掉  •优化ImageView:对于先绘制了一个背景,然后在其上绘制了图片的,9-patch格式的背景图中间拉伸部分设置为透明的,Android 2D渲染引擎会优化9-patch图中的透明像素.这个简单的修改可以消除头像上的

Android性能优化以及数据优化方法_Android

Android性能优化-布局优化 今天,继续Android性能优化 一 编码细节优化. 编码细节,对于程序的运行效率也是有很多的影响的.今天这篇主题由于技术能力有限,所以也不敢在深层去和大家分享.我将这篇主题分为以下几个小节: (1)缓存 (2)数据 (3)延迟加载和优先加载 1> 缓存 在Android中缓存可以用在很多的地方:对象.IO.网络.DB等等..对象缓存能减少内存分配,IO缓存能对磁盘的读写访问,网络缓存能减少对网络的访问,DB缓存能减少对数据库的操作. 缓存针对的场景在Andro

Android性能优化典范（一）

2015年伊始,Google发布了关于Android性能优化典范的专题,一共16个短视频,每个3-5分钟,帮助开发者创建更快更优秀的Android App.课程专题不仅仅介绍了Android系统中有关性能问题的底层工作原理,同时也介绍了如何通过工具来找出性能问题以及提升性能的建议.主要从三个方面展开,Android的渲染机制,内存与GC,电量优化.下面是对这些问题和建议的总结梳理. 1) Render Performance 大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能.从设计师

Android性能优化典范

2015新年伊始,Google发布了关于Android性能优化典范的专题,一共16个短视频,每个3-5分钟,帮助开发者创建更快更优秀的Android App.课程专题不仅仅介绍了Android系统中有关性能问题的底层工作原理,同时也介绍了如何通过工具来找出性能问题以及提升性能的建议.主要从三个方面展开,Android的渲染机制,内存与GC,电量优化.下面是对这些问题和建议的总结梳理. 0)Render Performance 大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能.从设计师