ANR (Application Not Responding)
所以一个流畅的合理的应用程序中不能出现anr,而让用户每次都要处理这个对话框。因此,在程序里对响应性能的设计非常重要,这样系统不会显示ANR给用户。
第一:什么会引发ANR?
1.在5秒内没有响应输入的事件(比如。按键按下,屏幕触摸)
2.BroadcastReceiver在10秒内没有运行完成
造成以上两点的原因有非常多。比方在主线程中做了非常耗时的操作,比方说是下载,io异常等。
然而,不是说你的主线程堵塞在那里等待子线程的完毕——也不是调用 Thread.wait()或是Thread.sleep()。
替代的方法是,主线程应该为子线程提供一个Handler,以便完毕时可以提交给主线程。以这样的方式设计你的应用程序。将能保证你的主线程保持对输入的响应性并能避免因为5秒输入事件的超时引发的ANR对话框。
第二:怎样避免ANR?
1、执行在主线程里的不论什么方法都尽可能少做事情。
特别是,Activity应该在它的关键生命周期方法(如onCreate()和onResume())里尽可能少的去做创建操作。
(能够採用又一次开启子线程的方式。然后使用Handler+Message的方式做一些操作,比方更新主线程中的ui等)
2、应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务(由于 BroadcastReceiver的生命周期短),替代的是,假设响应Intent广播须要运行一个耗时的动作的话,应用程序应该启动一个 Service。(此处须要注意的是能够在广播接受者中启动Service,可是却不能够在Service中启动broadcasereciver,关于原因兴许会有介绍。此处不是本文重点)
3、避免在Intent Receiver里启动一个Activity。由于它会创建一个新的画面,并从当前用户正在执行的程序上抢夺焦点。
假设你的应用程序在响应Intent广 播时须要向用户展示什么。你应该使用Notification Manager来实现。
总结:anr异常也是在程序中自己经常遇到的问题。基本的解决的方法自己最经常使用的就是不要在主线程中做耗时的操作,而应放在子线程中来实现,比方採用Handler+mesage的方式,或者是有时候须要做一些和网络相互交互的耗时操作就採用asyntask异步任务的方式(它的底层事实上Handler+mesage有所差别的是它是线程池)等,在主线程中更新UI。