Activity中onStop和onDestroy方法延迟调用BUG解决

阅读更多

Activity中onStop和onDestroy方法延迟调用BUG解决

     这个礼拜一功能开发完后，发现一个很奇葩的问题，我写了一个Activity，反复进去和退出，这样重复20次，TV的内存居然从53M升到了惊人的 170M，尝试了解决内存泄露的常规方法的几个步骤：

    (1)  在退出Activity时，把handler的Message和Runnable给干掉

        

  if(getHander() != null){
       getHander().removeCallbacksAndMessages(null);
 }

  

     (2)  Activity context引用不当导致退出时，整个Activity无法回收。程序中我会尽量使用   

           ApplicationContext

 

    (3)  检查添加了Listener接口回调后，没有反注册掉

 

    (4)  List，HashMap等集合类，在退出时clear掉，并置为空

 

    (5)  单例类中是否引用了ActivityContext

 

    在确认按照以上步骤，在我写的代码中都实践了后。结果内存还是老样子，为此我纠结了许久，加上最近看书走火入魔，胡思乱想，最后我居然为此失眠了3天。( ˇˍˇ ) 

   

   后来我又发现了更奇葩的问题，进入该页面一直在loading，而我取消请求只会在onDestroy中进行，后来打印log才发现，原来onStop和onDestory方法在我finish Activity后7秒之后才调用。问题终于找到了。解决呗

     思路：肯定是onStop和onDestroy方法执行了特别耗时的操作，导致Activity的方法阻塞了？

     最终在onDestroy方法中发现了，其他伙伴加的一个语音SDK退出的方法，我把该方法注释

掉了，然后重新启动，看看内存情况，发现onDestroy方法能及时调用了，但是返回退出，结果

onDestroy方法还是会延迟调用。/(ㄒoㄒ)/~~

     后来我发现语音SDK中，有很多的List和map数据，还有好几个回调监听，会不会是这些数据没有干掉引起的？于是我把集合类和监听都在onDestroy方法中给干掉，最后再重新编译下

果然反复退出和进入该Activity，内存始终保持在60M左右。问题终于解决了。。。

     查看语音的SDK发现，Activity启动事会请求接口获取一个很大的HashMap对象，没有把这个对象给干掉，居然造成每次3-5M的内存增加。可见每次在onDestroy时把网络请求的列表数据干掉，是很有必要的。

    总结：onStop方法和onDestroy方法延迟调用是由于语音的SDK内存泄露引起的