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

前言:

最近公司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检测到的内存泄漏情况以及解决办法。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Android内存泄漏排查利器LeakCanary

    本文为大家分享了Android内存泄漏排查利器,供大家参考,具体内容如下 开源地址:https://github.com/square/leakcanary 在 build.gralde 里加上依赖, 然后sync 一下, 添加内容如下 dependencies { .... debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5' releaseCompile 'com.squareup.leakcanary:leakcanar

  • Android中LeakCanary检测内存泄漏的方法

    最近要对产品进行内存泄漏的检查,最后选择了使用Square公司开源的一个检测内存泄漏的函数库LeakCanary,在github上面搜索了一下竟然有1.6w个star,并且Android大神JakeWharton也是这个开源库的贡献者.那么就赶快拿来用吧. 先说一下我遇到的坑,我当时是直接google的,然后就直接搜索到稀土掘金的一篇关于LeakCanary的介绍,我就按照他们的文章一步步的操作,到最后才发现,他们那个build.gradle中导入的库太老了,会报这样的错误Closed Fail

  • 使用Android Studio检测内存泄露(LeakCanary)

    内存泄露,是Android开发者最头疼的事.可能一处小小的内存泄露,都可能是毁千里之堤的蚁穴. 怎么才能检测内存泄露呢? AndroidStudio 中Memory控件台(显示器)提供了一个内存监视器.我们可以通过它方便地查看应用程序的性能和内存使用情况,从而也就可以找到需要释放对象,查找内存泄漏等. 熟悉Memory界面 打开日志控制台,有一个标签Memory ,我们可以在这个界面分析当前程序使用的内存情况. 运行要监控的程序(APP)后,打开Android Monitor控制台窗口,可以看到

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

    前言: 最近公司C轮融资成功了,移动团队准备扩大一下,需要招聘Android开发工程师,陆陆续续面试了几位Android应聘者,面试过程中聊到性能优化中如何避免内存泄漏问题时,很少有人全面的回答上来.所以决定抽空学习总结一下这方面的知识,以及分享一下我们是如何检测内存泄漏的.我们公司使用开源框架LeakCanary来检测内存泄漏. 什么是内存泄漏? 有些对象只有有限的生命周期.当它们的任务完成之后,它们将被垃圾回收.如果在对象的生命周期本该结束的时候,这个对象还被一系列的引用,这就会导致内存泄漏

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

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

  • Android性能优化方法

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

  • 浅谈Android性能优化之内存优化

    1.Android内存管理机制 1.1 Java内存分配模型 先上一张JVM将内存划分区域的图 程序计数器:存储当前线程执行目标方法执行到第几行. 栈内存:Java栈中存放的是一个个栈帧,每个栈帧对应一个被调用的方法.栈帧包括局部标量表, 操作数栈. 本地方法栈:本地方法栈主要是为执行本地方法服务的.而Java栈是为执行Java方法服务的. 方法区:该区域被线程共享.主要存储每个类的信息(类名,方法信息,字段信息等).静态变量,常量,以及编译器编译后的代码等. 堆:Java中的堆是被线程共享的,

  • Android性能优化系列篇UI优化

    目录 前言 一.UI优化 1.1 系统做的优化 1.1.1 硬件加速 1.2 优化方案 1.2.1 java代码布局 1.2.2 View重用 1.2.3 异步创建view 1.2.4 xml布局优化 1.2.5 异步布局框架Litho 1.2.6 屏幕适配 1.2.7 Flutter 1.2.8 Jetpack Compose 1.3 工具篇 1.3.1 Choreographer 1.3.2 LayoutInspector/Android Device Monitor 1.3.3 Systr

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

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

  • 简单了解Android性能优化方向及相关工具

    开发一款性能优良的应用是每一个Android开发者都必须经历的挑战.在移动端资源有限的前提下,提高应用的性能显得尤为重要.常见的提高APP性能的优化方向有三个:布局和渲染优化.内存优化.功耗优化. 一:布局优化 所谓布局优化,就是尽量减少布局的嵌套层级,减少无用的布局.主要的优化方法有: (1)优先使用RelativeLayout来减少布局嵌套层数,否则尽量使用LinearLayout.这是因为RelativeLayout能够在不嵌套的情况下完成复杂的布局,而当布局比较简单时优先使用Linear

  • 详解Android性能优化之启动优化

    1.为什么要进行启动优化 网上流行一种说法,就是8秒定律,意思是说,如果用户在打开一个页面,在8秒的时间内还没有打开,那么用户大概的会放弃掉,意味着一个用户的流失.从这里就可以看出,启动优化的重要性了. 2.启动的分类 2.1 冷启动 先来看看冷启动的流程图 从图中可以看出,APP启动的过程是:ActivityManagerProxy 通过IPC来调用AMS(ActivityManagerService),AMS通过IPC启动一个APP进程,ApplicationThread通过反射来创建App

  • Android 性能优化系列之bitmap图片优化

    背景 Android开发中,加载图片过多.过大很容易引起OutOfMemoryError异常,即我们常见的内存溢出.因为Android对单个应用施加内存限制,默认分配的内存只有几M(具体视不同系统而定).而载入的图片如果是JPG之类的压缩格式(JPG支持最高级别的压缩,不过该压缩是有损的),在内存中展开会占用大量的内存空间,也就容易形成内存溢出.那么高效的加载Bitmap是很重要的事情.Bitmap在Android中指的是一张图片,图片的格式有.jpg .jpg .webp 等常见的格式. 如何

随机推荐