什么是内存泄漏？
有些对象只有有限的生命周期。当它们的任务完成之后，它们将被垃圾回收。如果在对象的生命周期本该结束的时候，这个对象还被一系列的引用，这就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。
内存泄漏造成什么影响？
它是造成应用程序OOM的主要原因之一。由于android系统为每个应用程序分配的内存有限，当一个应用中产生的内存泄漏比较多时，就难免会导致应用所需要的内存超过这个系统分配的内存限额，这就造成了内存溢出而导致应用Crash。
什么是LeakCanary？
leakCanary是Square开源框架，是一个Android和Java的内存泄露检测库，如果检测到某个 activity 有内存泄露，LeakCanary 就是自动地显示一个通知，所以可以把它理解为傻瓜式的内存泄露检测工具。通过它可以大幅度减少开发中遇到的oom问题，大大提高APP的质量。
LeakCanary捕获常见内存泄漏以及解决办法
1.）错误使用单例造成的内存泄漏
在平时开发中单例设计模式是我们经常使用的一种设计模式，而在开发中单例经常需要持有Context对象，如果持有的Context对象生命周期与单例生命周期更短时，或导致Context无法被释放回收，则有可能造成内存泄漏，错误写法如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
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则会出现内存泄漏。
|
1
|
LoginManager.getInstance(
this
).dealData();
|
LeakCanary检测结果如下：
解决 办法要保证Context和AppLication的生命周期一样，修改后代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
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线程之间通讯的桥梁，只是现在大量开源框架对其进行了封装，我们这里模拟一种常见使用方式来模拟内存泄漏情形。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
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);就行了。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
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更新结果：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
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()方法，避免任务在后台执行浪费资源，进而避免内存泄漏的发生。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
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方法导致某些参数重新初始化，我们一般会选择创建一个内部类和一个静态实例来保存这些参数，比如以下实现：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
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的引用即可，修改后的代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
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代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
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);
}
@Override
protected
void
onDestroy() {
super
.onDestroy();
LApplication.getRefWatcher().watch(
this
);
}
}
|
xml布局文件：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<?
xml
version
=
"1.0"
encoding
=
"utf-8"
?>
<
LinearLayout
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中调用如下代码也是没有任何作用。
|
1
2
3
4
5
6
7
8
9
|
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掉进程。由于系统的内存分配是以进程为准的，进程关闭后，系统会自动回收所有内存。
修改后的代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
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);
}
@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配置如下：
|
1
2
3
|
<
activity
android:name
=
".MainActivity5"
android:process
=
"com.whoislcj.webview"
/>
|
6.）资源未关闭造成的内存泄漏
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。例如获取媒体库图片地址代码在查询结束的时候一定要调用
Cursor 的关闭方法防止造成内存泄漏。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
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检测到的内存泄漏情况以及解决办法。