【原创】Android 系统稳定性 - ANR（三）

文章都为原创，转载请注明出处，未经允许而盗用者追究法律责任。

很久之前写的了，留着有点浪费，共享之。

编写者：李文栋

1.4如何避免ANR

1.4.1ANR发生在主线程，不要阻塞主线程

Android应用程序的所有标准组件全部运行在一个单一的主线程中，在主线程中所做的任何耗时的操作都有可能造成ANR，因为这些耗时的操作会使得主线程没有机会处理用户输入事件或者广播事件。

因此在主线程中执行的任何函数所做的工作都应该尽可能的少，特别是对于Activity的生命周期函数来说。网络和数据库操作，以及诸如位图变换的一些耗时的操作，都应该放在子线程中完成。主线程不需要等待子线程的执行，主线程应该创建一个与其绑定的Handler对象，子线程执行完毕后通过Handler通知主线程。

创建子线程的方式有很多，Android中提供了很多相关的API，例如HandlerThread、AsyncTask、AsyncQueryHandler等，当然也可以创建简单的线程或线程池。不过需要注意的是，不要制造太多的“野”线程，例如在Android原生代码中经常会见到在某个函数中new了一个Thread对象，调用其start函数启动后就不再管理了。笔者对这种写法并不认同，这种写法的优点是避免了子线程对某些对象的强引用，以免内存泄漏，但是反而有潜在的风险会造成“线程泄漏”，也就是说可能会多次执行相同的操作创建大量的子线程，而这些子线程很可能由于某种原因被阻塞而都无法正常退出，大量的线程本身就会占用内存和CPU，抢占临界资源，而且执行的多是重复的操作。所以笔者建议将子线程“管理”起来，无论是用标志位还是用成员变量，总之不要让线程随意的被创建，用有限数量的线程或线程池处理所有的请求，可以用Handler将请求队列化，去除重复的请求减少资源浪费，同时应该在适当的时候（例如Activity销毁时）考虑停止子线程，避免不必要的操作和内存泄漏。

BroadcastReceiver通常是用来在后台执行一些小型的、琐碎的工作，例如保存程序设置。不要在BR中执行需要长时间运行的操作，这些操作应该放到Serivce中。另外，不要在BR中启动一个Activity，因为那样会创建一个新的窗口，新窗口会抢夺屏幕焦点，用户原先正在交互的窗口失去焦点后就不会再接收到输入事件。新窗口的突然出现可能会让用户很诧异，或者也有可能出现由于旧窗口的层（Window的type属性）比较高，新窗口没能显示，但是输入事件又被新窗口抢夺的情况。如果在BR中有消息要提示用户，可以考虑使用NotificationManager在状态栏中显示通知来达到目的。

1.4.2消除停顿感

通常人们感知界面有停顿感的时间需要100到200毫秒，所以为了给用户更好的体验，在避免ANR的基础上更进一步来消除停顿感，有以下几个建议：

如果应用程序正在后台执行耗时工作，可以使用ProgressBar或者ProgressDialog来提示用户工作进度；

对于游戏类的应用，应该使用子线程去做位置计算；

如果应用程序的初始化过程比较耗时，可以在初始化时显示一个过场动画或者图片，也可以先快速的显示主界面然后再异步的加载初始化数据。