关闭

About ANR and OOM

标签: oomANR
946人阅读 评论(0) 收藏 举报
分类:

1. ANR

    1.1 什么是ANR? ANR(Application Not Responding)

        在Android上,如果你的应用程序有一段时间响应不够灵敏,系统会向用户显示一个对话框,这个对话框称作应用程序无响应(ANR:ApplicationNotResponding)对话框。用户可以选择“等待”而让程序继续运行,也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr,而让用户每次都要处理这个对话框。

          默认情况下,在android中Activity的最长执行时间是5秒,BroadcastReceiver的最长执行时间则是10秒 (厂商可以定制 这个时间)


    1.2 产生ANR的原因?

        1.在5秒内没有响应输入的事件。
        2.BroadcastReceiver在制定时间内完成

        具体点的原因: 1) IO操作耗时 。  2)数据库操作复杂耗时。 3)主线程  非主线程 产生死锁等待。 4)网络加载/图片操作耗时。  5)硬件操作耗时。

                                     1) service binder 数量达到上限。 2)Service忙导致超时无响应。


    1.3 ANR是哪里报出来的?

        ActivityManagerService 管理每个应用程序是否发生了ANR  。按照ANR发生的不同类型,细致一点的说:

        1)KeyDispatchTimeout :每次dispatch 触摸事件的时候都会检查当前接收事件的app是否 ready 去处理下一个事件,判断的过程中会检查是否发生了ANR。检查的办法是ActivityManagerService对比上次记录的该pid的处理时间和当前时间的差值,是否大于系统规定的ANR超时时间。

        2)BroadcastTimeout:ActivityManagerService 管理着几个broadcastQueue,这些broadcastQueue 管理者不同类型的broadcast。每个broadcast发送给注册的对象都有一个时间限制,BroadCastQueue会记录每次发送的开始时间以及结束时间,如果超过了ANR规定时间就会发生ANR。通过调用AMS中的AppNotResponding来弹出系统弹窗。

        3)ServiceTimeout:与KeyDispatchTimeout 类似。(没有具体的看)

    1.4 如何尽力避免ANR?

        1)运行在主线程里的任何方法都尽可能少做事情。特别是,Activity应该在它的关键生命周期方法(如onCreate()和onResume())里尽可能少的去做创建操作。(可以采用重新开启子线程的方式,然后使用Handler+Message的方式做一些操作,比如更新主线程中的ui等)

        2)应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务(因为BroadcastReceiver的生命周期短),替代的是,如果响应Intent ,应用程序应该启动一个Service。

        3)避免在IntentReceiver里启动一个Activity,因为它会创建一个新的画面,并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广播时需要向用户展示什么,你应该使用Notification Manager来实现。

    1.5 出现ANR如何解决。

        解决ANR 主要通过 报错log和Trace文件分析解决。 从产生的原因入手。 具体方法可以参考一下: http://www.cnblogs.com/purediy/p/3225060.html


2. Crash

    Crash 包括很多情况,在进行系统debug的时候很容易区分。 例如JAVA层的Fatal 错误, 在log中会明确的打印出具体原因, 是数组越界/未初始化变量/空指针等。又比如C/C++层的错误,会打印出相应的信息,我们可以通过addr2line  来进行debug。 应用层的crash 是我们常说的FC。  system service 的crash 会导致 系统不能启动/重启等问题。

http://blog.csdn.net/god2469/article/details/9713395   (常见的SIG错误以及含义)


3. OOM

    OOM是指Out Of Memory。每个android应用单独使用一个Dalvik虚拟机,每个虚拟机使用的堆内存是有限的,超过了限制就会引发oom错误。造成OOM几乎都是自己的代码结构导致的不良。常见的原因:

   1)不恰当的使用static关键字。 尽量不要使用static保存对象。

   2)内部类对Activity的引用。 内部类对象如果引用Activity对象,同时有很长的声明周期的话会导致 Activity对象释放不及时。

   3)Bitmap使用。 大量的bitmap会导致 程序包和运行时的内存消耗变大。

   4)游标cursor的使用。 Cursor 对象用完应该及时关闭

   5)其他的内容。 我个人不能列举所有的情况。其他的是我暂时没有想到的 欢迎指教

文章中有一些引用的地方。不算原创。

1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:136707次
    • 积分:1024
    • 等级:
    • 排名:千里之外
    • 原创:20篇
    • 转载:12篇
    • 译文:0篇
    • 评论:6条
    文章分类
    最新评论