Android学习系列(37)--App调试内存泄露之Context篇(下)
接着《Android学习系列(36)--App调试内存泄露之Context篇(上)》继续分析。
5. AsyncTask对象
我N年前去盛大面过一次试，当时面试官极力推荐我使用AsyncTask等系统自带类去做事情，当然无可厚非。
但是AsyncTask确实需要额外注意一下。它的泄露原理和前面Handler，Thread泄露的原理差不多，它的生命周期和Activity不一定一致。
解决方案是：在activity退出的时候，终止AsyncTask中的后台任务。
但是，问题是如何终止？
AsyncTask提供了对应的API：public final boolean cancel (boolean mayInterruptIfRunning)。
它的说明有这么一句话：
|
1
2
|
// Attempts to cancel execution of this task. This attempt will fail if the task has already completed, already been cancelled, or could not be cancelled for some other reason.
// If successful, and this task has not started when cancel is called, this task should never run. If the task has already started, then the mayInterruptIfRunning parameter determines whether the thread executing this task should be interrupted in an attempt to stop the task.
|
cancel是不一定成功的，如果正在运行，它可能会中断后台任务。怎么感觉这话说的这么不靠谱呢？
是的，就是不靠谱。
那么，怎么才能靠谱点呢？我们看看官方的示例：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {
protected Long doInBackground(URL... urls) {
int count = urls.length;
long totalSize = 0 ;
for ( int i = 0 ; i < count; i++) {
totalSize += Downloader.downloadFile(urls[i]);
publishProgress(( int ) ((i / ( float ) count) * 100 ));
// Escape early if cancel() is called
// 注意下面这行，如果检测到cancel，则及时退出
if (isCancelled()) break ;
}
return totalSize;
}
protected void onProgressUpdate(Integer... progress) {
setProgressPercent(progress[ 0 ]);
}
protected void onPostExecute(Long result) {
showDialog( "Downloaded " + result + " bytes" );
}
}
|
官方的例子是很好的，在后台循环中时刻监听cancel状态，防止没有及时退出。
为了提醒大家，google特意在AsyncTask的说明中撂下了一大段英文：
|
1
|
// AsyncTask is designed to be a helper class around Thread and Handler and does not constitute a generic threading framework. AsyncTasks should ideally be used for short operations (a few seconds at the most.) If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent pacakge such as Executor, ThreadPoolExecutor and FutureTask.
|
可怜我神州大陆幅员辽阔，地大物博，什么都不缺，就是缺对英语阅读的敏感。
AsyncTask适用于短耗时操作，最多几秒钟。如果你想长时间耗时操作，请使用其他java.util.concurrent包下的API，比如Executor, ThreadPoolExecutor 和 FutureTask.
学好英语，避免踩坑！
6. BroadcastReceiver对象
... has leaked IntentReceiver ... Are you missing a call to unregisterReceiver()?
这个直接说了，种种原因没有调用到unregister()方法。
解决方法很简单，就是确保调用到unregister()方法。
顺带说一下，我在工作中碰到一种相反的情况，receiver对象没有registerReceiver()成功(没有调用到)，于是unregister的时候提示出错：
|
1
|
// java.lang.IllegalArgumentException: Receiver not registered ...
|
有两种解决方案：
方案一：在registerReceiver()后设置一个FLAG，根据FLAG判断是否unregister()。网上搜到的文章几乎都这么写，我以前碰到这种bug，也是一直都这么解。但是不可否认，这种代码看上去确实有点丑陋。
方案二：我后来无意中听到某大牛提醒，在Android源码中看到一种更通用的写法：
|
1
2
3
4
5
6
7
8
9
|
// just sample, 可以写入工具类
// 第一眼我看到这段代码，靠，太粗暴了，但是回头一想，要的就是这么简单粗暴，不要把一些简单的东西搞的那么复杂。
private void unregisterReceiverSafe(BroadcastReceiver receiver) {
try {
getContext().unregisterReceiver(receiver);
} catch (IllegalArgumentException e) {
// ignore
}
}
|
7. TimerTask对象
TimerTask对象在和Timer的schedule()方法配合使用的时候极容易造成内存泄露。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
private void startTimer(){
if (mTimer == null ) {
mTimer = new Timer();
}
if (mTimerTask == null ) {
mTimerTask = new TimerTask() {
@Override
public void run() {
// todo
}
};
}
if (mTimer != null && mTimerTask != null )
mTimer.schedule(mTimerTask, 1000 , 1000 );
}
|
泄露的点是，忘记cancel掉Timer和TimerTask实例。cancel的时机同cursor篇说的，在合适的时候cancel。
|
1
2
3
4
5
6
7
8
9
10
|
private void cancelTimer(){
if (mTimer != null ) {
mTimer.cancel();
mTimer = null ;
}
if (mTimerTask != null ) {
mTimerTask.cancel();
mTimerTask = null ;
}
}
|
8. Observer对象。
Observer对象的泄露，也是一种常见、易发现、易解决的泄露类型。
先看一段正常的代码：
|
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
|
// 其实也非常简单，只不过ContentObserver是系统的例子，有必要单独拿出来提示一下大家，不可掉以轻心
private final ContentObserver mSettingsObserver = new ContentObserver( new Handler()) {
@Override
public void onChange( boolean selfChange, Uri uri) {
// todo
}
};
@Override
public void onStart() {
super .onStart();
// register the observer
getContentResolver().registerContentObserver(Settings.Global.getUriFor(
xxx), false , mSettingsObserver);
}
@Override
public void onStop() {
super .onStop();
// unregister it when stoping
getContentResolver().unregisterContentObserver(mSettingsObserver);
}
|
看完示例，我们来看看病例：
|
1
2
3
4
5
6
7
8
|
private final class SettingsObserver implements Observer {
public void update(Observable o, Object arg) {
// todo ...
}
}
mContentQueryMap = new ContentQueryMap(mCursor, Settings.System.XXX, true , null );
mContentQueryMap.addObserver( new SettingsObserver());
|
靠，谁这么偷懒，把SettingObserver搞个匿名对象传进去，这可如何是好？
所以，有些懒是不能偷的，有些语法糖是不能吃的。
解决方案就是, 在不需要或退出的时候delete这个Observer。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
private Observer mSettingsObserver;
@Override
public void onResume() {
super .onResume();
if (mSettingsObserver == null ) {
mSettingsObserver = new SettingsObserver();
}
mContentQueryMap.addObserver(mSettingsObserver);
}
@Override
public void onStop() {
super .onStop();
if (mSettingsObserver != null ) {
mContentQueryMap.deleteObserver(mSettingsObserver);
}
mContentQueryMap.close();
}
|
注意一点，不同的注册方法，不同的反注册方法。
|
1
2
3
4
5
6
7
8
|
// 只是参考，不必死板
/*
addCallback <==> removeCallback
registerReceiver <==> unregisterReceiver
addObserver <==> deleteObserver
registerContentObserver <==> unregisterContentObserver
... ...
*/
|
9. Dialog对象
android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@438afa60 is not valid; is your activity running?
一般发生于Handler的MESSAGE在排队，Activity已退出，然后Handler才开始处理Dialog相关事情。
关键点就是，怎么判断Activity是退出了，有人说，在onDestroy中设置一个FLAG。我很遗憾的告诉你，这个错误很有可能还会出来。
解决方案是：使用isFinishing()判断Activity是否退出。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
Handler handler = new Handler() {
public void handleMessage(Message msg) {
switch (msg.what) {
case MESSAGE_1:
// isFinishing == true, 则不处理，尽快结束
if (!isFinishing()) {
// 不退出
// removeDialog()
// showDialog()
}
break ;
default :
break ;
}
super .handleMessage(msg);
}
};
|
早完早释放！
10. 其它对象
以Listener对象为主，"把自己搭进去了，切记一定要及时把自己放出来"。
11. 小结
结合本文Context篇和前面Cursor篇，我们枚举了大量的泄露实例，大部分根本原因都是相似的。
通过分析这些例子后，我们应该能理解APP层90%的内存泄露情况了。
至于怎么发现和定位内存泄露，这是另外一个有意思的话题，现在只能说，有方法有工具。
文章来源: blog.csdn.net，作者：悟空胆好小，版权归原作者所有，如需转载，请联系作者。
原文链接：blog.csdn.net/xushx_bigbear/article/details/45008405
- 点赞
- 收藏
- 关注作者
评论（0）