优化AndroidBroadcastReceiver时需关注的关键事项与最佳实践

今天在 android 的 BroadcastReceiver 里面写一些代码的时候出现了意想不到的异常。情况是这样的&＃xff1a;

当我在广播类里面这样定义一个Dialog&＃xff0c;然后再在这个类里面调用dimiss方法时&＃xff0c;对话框始终不消失&＃xff0c;这让我纳闷了很久。。。

 private ProgressDialog dialogDataUpload &＃61; null;private void dimiss() {if (dialogDataUpload !&＃61; null) {dialogDataUpload.dismiss();dialogDataUpload &＃61; null;}}

后来仔细端详这个类里面的dimiss方法&＃xff0c;发现 Eclipse有一个警告&＃xff1a;“This Handler class should be static or leaks might occur”&＃xff0c;这让我隐约联想到了以前看到的关于 BroadcastReceiver 的注意事项。后来通过详细地了解 BroadcastReceiver&＃xff0c;发现其生命周期只有十秒左右&＃xff0c;如果在 onReceive() 内做超过十秒内的事情&＃xff0c;就会报ANR(Application No Response) 程序无响应的错误信息&＃xff0c;如果需要完成一项比较耗时的工作 , 应该通过发送 Intent 给 Service, 由Service 来完成 . 这里不能使用子线程来解决 , 因为 BroadcastReceiver 的生命周期很短 , 子线程可能还没有结束BroadcastReceiver 就先结束了 .BroadcastReceiver 一旦结束 , 此时 BroadcastReceiver 的所在进程很容易在系统需要内存时被优先杀死 , 因为它属于空进程 ( 没有任何活动组件的进程 ). 如果它的宿主进程被杀死 , 那么正在工作的子线程也会被杀死 . 所以采用子线程来解决是不可靠的。

通过这段解释&＃xff0c;让我明白了出现的问题应该是由于我执行了超过10秒的操作&＃xff0c;所以在执行取消对话框的操作时广播类的对象已销毁&＃xff0c;这样 dimiss 方法肯定不起作用了。所以&＃xff0c;我的解决方法是在申明的 Dialog 前面加上 static 属性&＃xff0c;这样当广播的生命周期已结束时&＃xff0c;由于 static 的属性&＃xff0c;dimiss方法就会起作用了。当然最好的办法是按照前面说的&＃xff0c;如果是比较耗时的操作&＃xff0c;最好启动一个 Service 来处理。