Android学习系列(37)--App调试内存泄露之Context篇(下)

举报
aiot_bigbear 发表于 2022/09/25 03:53:48 2022/09/25
【摘要】 接着《Android学习系列(36)--App调试内存泄露之Context篇(上)》继续分析。 5. AsyncTask对象     我N年前去盛大面过一次试,当时面试官极力推荐我使用AsyncTask等系统自带类去做事情,当然无可厚非。     但是AsyncTask确实需要额外注...

接着《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

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。