Android ANR

来源:互联网 发布:python replace 正则 编辑:程序博客网 时间:2024/05/19 23:12

ANR

StartActivity), time=10630578622 Reason: keyDispatchingTimedOut

keyDispatchingTimedOut 很有可能是msg在队列里面来不及处理,所以返回时 找不到之前的VIEW, 所以就一直等待,导致ANR。 这个是在一个论坛看到的解释。
但是还不知道为什么会导致CPU占用这么高。
你是在跑monkey时候出现的这个问题么? 如果是,建议你延长event间隔时间,再试一下。


可能楼主把需要长时间加载的逻辑放在了 oncreate里面进行了操作。就会出现这个问题。。
记住一但oncreate里面的代码逻辑执行时间过长就会出现,尽量避免 这个情况。
一般需要长时间的东东,比如下载内容,逻辑不能放oncreate里面做,要保证oncreate里面的东西迅速加载完成,可以在oncreate启一个线程来(比如task)完成相应内容。
我们一个项目中就是这样,一直出现这个破错误,搞的很恼火,后来加了异步线程来处理,就好了。。。。


我已说过了,检查你的代码,耗时间的代码逻辑不要放在oncreate里面。不然会影响事件分发,还会报ANR问题

 

解决ANR异常概述:   

考虑上面的ANR定义,让我们来研究一下为什么它会在Android应用程序里发生和如何最佳构建应用程序来避免ANR。
Android应用程序通常是运行在一个单独的线程(例如,main)里。这意味着你的应用程序所做的事情如果在主线程里占用了太长的时间的话,就会引发ANR对话框,因为你的应用程序并没有给自己机会来处理输入事件或者Intent广播。
因此,运行在主线程里的任何方法都尽可能少做事情。特别是,Activity应该在它的关键生命周期方法(如onCreate()和onResume())里尽可能少的去做创建操作。潜在的耗时操作,例如网络或数据库操作,或者高耗时的计算如改变位图尺寸,应该在子线程里(或者以数据库操作为例,通过异步请求的方式)来完成。然而,不是说你的主线程阻塞在那里等待子线程的完成——也不是调用Thread.wait()或是Thread.sleep()。替代的方法是,主线程应该为子线程提供一个Handler,以便完成时能够提交给主线程。以这种方式设计你的应用程序,将能保证你的主线程保持对输入的响应性并能避免由于5秒输入事件的超时引发的ANR对话框。这种做法应该在其它显示UI的线程里效仿,因为它们都受相同的超时影响。
引起ANR异常的常见情况:
1、在主线程内进行网络操作,获取服务器上的资源

2、在主线程内进行一些缓慢的磁盘操作(
应用应该在5秒或者10秒内响应
一般来说,在应用程序里,100到200ms是用户能感知阻滞的时间阈值。因此,这里有一些额外的技巧来避免ANR,并有助于让你的应用程序看起来有响应性。
如果你的应用程序为响应用户输入正在后台工作的话,可以显示工作的进度(ProgressBar和ProgressDialog对这种情况来说很有用)。
通过Handler解决ANR异常:
方式一:
1.开启一个新的线程,进行数据请求,此线程内包含了比较耗时操作的代码
2. 获取数据后,调用handler.sendMessage方法
3. 在主线程中调用  handleMessgae(Message msg) 方法接收数据并更新UI
 
方式二:
 利用handler.post(new Runnable(){
              public void run(){ 
             -------------------- 耗时操作的代码


           }}

        );
 
给创建handler对象的线程发送一个runnable,自动执行run方法


////////////////////////////////////
Android开发中ANR问题出现及解决
写在前面:Application Not Responding。在Android上,如果你的应用程序有一段时间响应不够灵敏,系统会向用户显示一个对话框,这个对话框称作应用程序无响应(ANR:Application Not Responding)对话框。用户可以选择“等待”而让程序继续运行,也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr,而让用户每次都要处理这个对话框。因此,在程序里对响应性能的设计很重要,这样系统不会显示ANR给用户。默认情况下,在android中Activity的最长执行时间是5秒,BroadcastReceiver的最长执行时间则是10秒。

第一:什么会引发ANR?
在Android里,应用程序的响应性是由Activity Manager和WindowManager系统服务监视的 。当它监测到以下情况中的一个时,Android就会针对特定的应用程序显示ANR:

1.在5秒内没有响应输入的事件(例如,按键按下,屏幕触摸)
2.BroadcastReceiver在10秒内没有执行完毕

造成以上两点的原因有很多,比如在主线程中做了非常耗时的操作,比如说是下载,io异常等。

第二:如何避免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。

 

原创粉丝点击