Android性能优化之利用LeakCanary检测内存泄漏及解决办法(转)
Posted WYH_Healer
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android性能优化之利用LeakCanary检测内存泄漏及解决办法(转)相关的知识,希望对你有一定的参考价值。
利用LeakCanary检测内存泄漏及解决办法
- 什么是内存泄漏?
- 内存泄漏造成什么影响?
- 什么是LeakCanary?
- LeakCanary捕获常见内存泄漏以及解决办法
- 结束语
本文转载于博客园的总李写代码的文章http://www.cnblogs.com/whoislcj/p/6001422.html
什么是内存泄漏?
有些对象只有有限的生命周期。当它们的任务完成之后,它们将被垃圾回收。如果在对象的生命周期本该结束的时候,这个对象还被一系列的引用,这就会导致内存泄漏。随着泄漏的累积,app将消耗完内存。
内存泄漏造成什么影响?
它是造成应用程序OOM的主要原因之一。由于android系统为每个应用程序分配的内存有限,当一个应用中产生的内存泄漏比较多时,就难免会导致应用所需要的内存超过这个系统分配的内存限额,这就造成了内存溢出而导致应用Crash。
什么是LeakCanary?
leakCanary是Square开源框架,是一个Android和Java的内存泄露检测库,如果检测到某个 activity 有内存泄露,LeakCanary 就是自动地显示一个通知,所以可以把它理解为傻瓜式的内存泄露检测工具。通过它可以大幅度减少开发中遇到的oom问题,大大提高APP的质量。
本篇不介绍如何使用LeakCanary,关于LeakCanary使用参考以下文章:
1.LeakCanary: 让内存泄露无所遁形
https://www.liaohuqiu.net/cn/posts/leak-canary/
2.LeakCanary 中文使用说明
https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/
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网页,就如下面这种方式:
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();
结束语
在一个项目完成之后,都应该对项目进行检测,优化,处理内存的问题。上述转载文章中已经做了很详细的解释。我的理解就是能抽取在基类中处理的尽量抽取,不仅节省时间,而且优化了代码量。在这里我要推荐用butterknife代替findViewById,因为注解可以在onDestroy中进行释放,解除控件的引用;还有就是尽量少用Application对象当上下文或者使用static,这些生命周期都比较长,有时候页面关闭了还在保持对页面的引用导致内存泄漏,最好还是用当前的上下文对象。以上纯属个人意见,希望有误的地方大牛们帮我指出错误,谢谢大家咯。
以上是关于Android性能优化之利用LeakCanary检测内存泄漏及解决办法(转)的主要内容,如果未能解决你的问题,请参考以下文章
Android性能优化之利用Rxlifecycle解决RxJava内存泄漏
Android 性能优化之 LeakCanary 的使用及项目中的实际运用
前端性能优化之利用 Chrome Dev Tools 进行页面性能分析