ANR

 

本文部分内容摘自http://rayleeya.iteye.com/blog/1955652，并进行了总结和修改

1.1 ANR简介

ANR，"Application Not Responding"的缩写，中文意思为"应用程序无响应"。在Android中，ActivityManagerService(简称AMS)和WindowManagerService(简称WMS)会监测应用程序的响应时间，如果应用程序主线程（即UI线程）在超时时间内对输入事件没有处理完毕(例如多线程同步造成的资源竞争)，或者对特定操作(例如，接收特定的广播、服务执行特定的生命周期回调等)没有执行完毕，就会出现ANR。对于输入事件没有处理完毕产生的ANR，Android会显示一个对话框，提示用户当前应用程序没有响应，用户可以选择继续等待或者关闭这个应用程序（也就是杀掉这个应用程序的进程）。

1.2 为什么会有ANR

ANR的产生需要同时满足三个条件：

    主线程：只有应用程序进程的主线程响应超时才会产生ANR；
    超时时间：产生ANR的上下文不同，超时时间也会不同，但只要在这个时间上限内没有响应就会ANR；
    输入事件/特定操作：输入事件是指按键、触屏等设备输入事件，特定操作是指BroadcastReceiver和Service的生命周期中的各个函数，产生ANR的上下文不同，导致ANR的原因也会不同；

 

 

 

 

针对这三个条件，有以下三种情况会触发ANR，详细说明如下。

1.2.1 主线程对输入事件在5秒内没有处理完毕

我们先简单了解一下产生这种ANR的整个流程。

当应用程序的Window处于Active状态并且能够接收输入事件（例如按键事件、触摸事件等）时，系统底层上报的事件就会被InputDispatcher分发给这个应用程序，应用程序的主线程通过InputChannel读取输入事件并交给界面视图处理，界面视图是一个树状结构，DecorView是视图树的根，事件从树根开始一层一层向端点(例如一个Button)传递。我们通常会注册一个监听器来接收并处理事件。
InputDispatcher运行在系统进程(进程名为system_server)的一个单独的线程中，应用程序的主线程在处理事件的过程中，InputDispatcher会不断的检测处理过程是否超时，一旦超时，会通过一系列的回调通知WMS的notifyANR函数，最终会调用到AMS中mHandler对象里的SHOW_NOT_RESPONDING_MSG这个case，此时界面上就显示系统提示对话框了，同时使用logcat命令查看log也可以看到关于ANR的信息。InputDispatcher就是那个爱打"小报告"的家伙。


名词解释：
    Window：具体指的是PhoneWindow对象，表示一个能够显示的窗口，它能够接收系统分发的各种输入事件；
    InputDispatcher：将系统上报的输入事件分发给当前活动的窗口；
    InputChannel：InputDispatcher和应用程序分别运行在两个不同的进程中，InputDispatcher就是通过InputChannel将事件对象传递给应用进程的。


注意：产生这种ANR的前提是要有输入事件，如果用户没有触发任何输入事件，即便是主线程阻塞了，也不会产生ANR，因为InputDispatcher没有分发事件给应用程序，当然也不会检测处理超时和报告ANR了。


1.2.2 主线程在执行BroadcastReceiver的onReceive函数时10秒内没有执行完毕

BroadcastReceiver（简称BR）的onReceive函数运行在主线程中，当这个函数超过10秒钟没有返回就会触发ANR。不过对这种情况的ANR系统不会显示对话框提示，仅是输出log而已。


1.2.3 主线程在执行Service的各个生命周期函数时20秒内没有执行完毕

Service的各个生命周期函数也运行在主线程中，当这些函数超过20秒钟没有返回就会触发ANR。同样对这种情况的ANR系统也不会显示对话框提示，仅是输出log。

 
三种ANR中只有第1种会显示系统提示对话框，因为用户正在做界面交互操作，如果长时间没有任何响应，给用户的体验肯定是非常糟糕的。
三种ANR发生时都会在log中输出错误信息，你会发现各个应用进程和系统进程的函数堆栈信息都输出到了一个/data/anr/traces.txt的文件中，这个文件是分析ANR原因的关键文件，同时在日志中还会看到当时的CPU使用率，这也是重要信息。

这三种ANR不是孤立的，有可能会相互影响。例如一个应用程序进程中同时有一个正在显示的Activity和一个正在处理消息的BroadcastReceiver，它们都运行在这个进程的主线程中。如果BR的onReceive函数没有返回，此时用户点击屏幕，而onReceive超过5秒仍然没有返回，主线程无法处理用户输入事件，就会引起第1种ANR。如果继续超过10秒没有返回，又会引起第2种ANR。


 1.3 如何分析ANR问题

引起ANR问题的根本原因，总的来说可以归纳为两类：

应用进程自身引起的，例如：
    主线程阻塞、挂起、死循环。
    应用进程的其他线程的CPU占用率高，使得主线程无法抢占到CPU时间片
    
其他进程间接引起的，例如：
    当前应用进程进行进程间通信请求其他进程，其他进程的操作长时间没有反馈
    其他进程的CPU占用率高，使得当前应用进程无法抢占到CPU时间片

分析ANR问题时，以上述可能的几种原因为线索，通过分析各种日志信息，大多数情况下你就可以很容易找到问题所在了。

注意：有一些ANR问题很难调查清楚，因为整个系统不稳定的因素很多，例如Linux Kernel本身的bug引起的内存碎片过多、硬件损坏等。这类比较底层的原因引起的ANR问题往往无从查起，并且这根本不是应用程序的问题，浪费了应用开发人员很多时间，如果你从事过整个系统的开发和维护工作的话会深有体会。所以不能保证了解了本章的所有内容后能够解决一切ANR问题，如果出现了很疑难的ANR问题，建议最好去和做驱动和内核的朋友聊聊，或者，如果问题只是个十万分之一的偶然现象，不影响程序的正常运行，我倒是建议不去理它。


 1.3.1 分析ANR的利器

Android会在ANR发生时输出很多有用的信息帮助分析问题原因，我们先来看一下ANR的异常信息，使用logcat命令查看会得到类似如下的log：
 

//WindowManager所在的进程是system_server，进程号是127

I/WindowManager( 127): Input event dispatching timed out sending to com.example.anrdemo/com.example.anrdemo.ANRActivity


//system_server进程中的ActivityManagerService请求kernel向5033进程发送SIGNAL_QUIT请求

//你可以在shell中使用命令达到相同的目的：adb shell kill -3 5033

//和其他的Java虚拟机一样，SIGNAL_QUIT也是Dalvik内部支持的功能之一

I/Process ( 127): Sending signal. PID: 5033 SIG: 3

 

//5033进程的虚拟机实例接收到SIGNAL_QUIT信号后会将进程中各个线程的函数堆栈信息输出到traces.txt文件中

//发生ANR的进程正常情况下会第一个输出

I/dalvikvm( 5033): threadid=4: reacting to signal 3

I/dalvikvm( 5033): Wrote stack traces to '/data/anr/traces.txt'

... ...//另外还有其他一些进程

 

//随后会输出CPU使用情况

E/ActivityManager( 127): ANR in com.example.anrdemo (com.example.anrdemo/.ANRActivity)

//Reason表示导致ANR问题的直接原因

E/ActivityManager( 127): Reason: keyDispatchingTimedOut

E/ActivityManager( 127): Load: 3.85 / 3.41 / 3.16

 

从log中能够知道，发生ANR时Android为我们提供了“利器”：traces文件。以上做了简单注释，稍后再详细分析。


1.3.2 ANR的案例

traces.txt在目标机里，通过一项命令导出，并分析。
>C:\Users\Administrator\AppData\Local\Android\sdk\platform-tools\adb shell cat /data/anr/traces.txt
adb shell cat /data/anr/traces.txt > 指定输出目录/traces.txt
案例1：死锁问题。

"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 obj=0x747e8fb0 self=0xf46f6500
  | sysTid=14656 nice=-1 cgrp=top_visible sched=0/0 handle=0xf743fb38
  | state=S schedstat=( 4692594920 409697080 5544 ) utm=412 stm=57 core=3 HZ=100
  | stack=0xff371000-0xff373000 stackSize=8MB
  | held mutexes=
  at tendyron.akey.controls.IBank$5.onFind(IBank.java:339)
  - waiting to lock <0x098f3234> (a java.lang.Object) held by thread 27
  at tendyron.provider.io.comm.bt.ble.BTDeviceScan.callListener(BTDeviceScan.java:35)
  - locked <0x0b7c685d> (a java.util.HashMap)
  at tendyron.provider.io.comm.bt.ble.BleManager.onFindNewDevice(BleManager.java:141)
  - locked <0x00b2f5d2> (a java.util.HashMap)
  at tendyron.provider.io.comm.bt.ble.BleManager.access$100(BleManager.java:23)
  at tendyron.provider.io.comm.bt.ble.BleManager$1.onLeScan(BleManager.java:64)
  at android.bluetooth.BluetoothAdapter$2.onScanResult(BluetoothAdapter.java:2299)
  at android.bluetooth.le.BluetoothLeScanner$BleScanCallbackWrapper$1.run(BluetoothLeScanner.java:361)
  at android.os.Handler.handleCallback(Handler.java:743)
  at android.os.Handler.dispatchMessage(Handler.java:95)
  at android.os.Looper.loop(Looper.java:150)
  at android.app.ActivityThread.main(ActivityThread.java:5665)
  at java.lang.reflect.Method.invoke!(Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:799)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:689)



 
  "Thread-661" prio=5 tid=27 Blocked
  | group="main" sCount=1 dsCount=0 obj=0x12c73be0 self=0xd650bd00
  | sysTid=19861 nice=0 cgrp=top_visible sched=0/0 handle=0xd749a930
  | state=S schedstat=( 3929120 3967080 25 ) utm=0 stm=0 core=2 HZ=100
  | stack=0xd7398000-0xd739a000 stackSize=1038KB
  | held mutexes=
  at tendyron.provider.io.comm.bt.ble.BleManager.unRegisteOnFindBleDevice(BleManager.java:102)
  - waiting to lock <0x00b2f5d2> (a java.util.HashMap) held by thread 1
  at tendyron.provider.io.comm.bt.BtManagerFactory.unRegisteOnFindBleDevice(BtManagerFactory.java:82)
  at tendyron.akey.controls.IBank.scanBLEDevice(IBank.java:376)
  - locked <0x098f3234> (a java.lang.Object)
  at tendyron.akey.controls.IBank.BleConnect(IBank.java:193)
  at tendyron.akey.controls.IBank.access$200(IBank.java:54)
  at tendyron.akey.controls.IBank$2.getDefaultComm(IBank.java:127)
  at tendyron.provider.io.CommControler.getSelectedComm(CommControler.java:74)
  at tendyron.provider.io.CommControler.getComm(CommControler.java:53)
  at tendyron.provider.sdk.AKeyWorkBase.rebuildComm(AKeyWorkBase.java:186)
  at tendyron.provider.sdk.AKeyWorkBase.getComm(AKeyWorkBase.java:179)
  at tendyron.provider.sdk.AKeyWorkBase.init(AKeyWorkBase.java:227)
  at tendyron.akey.abc.impl.ABCBaseWorking.init(ABCBaseWorking.java:27)
  at tendyron.provider.sdk.AKeyWorkBase.runSync(AKeyWorkBase.java:437)
  at tendyron.provider.sdk.AKeyWorkBase.access$000(AKeyWorkBase.java:49)

  at tendyron.provider.sdk.AKeyWorkBase$6.run(AKeyWorkBase.java:419)


这是出问题的源码：此方法是在子线程中运行的。

 

private IBLEDevice scanBLEDevice(final String sn) throws AKeyException {
    final IBLEDevice[] reDevice = new IBLEDevice[1];
    final IBTManager bm = mIoControler.getBTManager(mContext);

    OnFindBleDevice onFindBleDevice = new OnFindBleDevice() {

        @Override
        public void onFind(IBLEDevice arg0) { //此方法是在主线程中执行的
            try {
                // ......省略
                
                synchronized (scanLock) {
                    reDevice[0] = arg0;
                    scanLock.notify();
                }
            } catch (Exception e) {
                if (Build.DEBUG) {
                    e.printStackTrace();
                }
            }
        }
    };
    bm.registeOnFindBleDevice(onFindBleDevice);
    bm.startScan(new OnScanListener() {

        @Override
        public void onStop() {
            if (Build.DEBUG) {
                AKeyLog.v(this, "scanBLEDevice.onStop");
            }
        }

        @Override
        public void onStart() {
            if (Build.DEBUG) {
                AKeyLog.v(this, "scanBLEDevice.onStart");
            }
        }
    });

    synchronized (scanLock) {
        try {
            scanLock.wait(30 * 1000);
        } catch (InterruptedException e) {
            AKeyLog.e(this, e);
        } finally {
            bm.stopMonitor();
            if (onFindBleDevice != null) {
                bm.unRegisteOnFindBleDevice(onFindBleDevice);
            }
        }
    }
}

public void registeOnFindBleDevice(OnFindBleDevice onFindBleDevice) {
    synchronized (mOnFindBleDevices) {
        if (!mOnFindBleDevices.containsKey(onFindBleDevice)) {
            BTDeviceScan btDeviceScan = new BTDeviceScan(mContext, onFindBleDevice);
            mOnFindBleDevices.put(onFindBleDevice, btDeviceScan);
        }
    }
}

public void unRegisteOnFindBleDevice(OnFindBleDevice onFindBleDevice) {
    synchronized (mOnFindBleDevices) {
        if (mOnFindBleDevices.containsKey(onFindBleDevice)) {
            mOnFindBleDevices.remove(onFindBleDevice);
        }
    }
} 

 

原因：主线程和子线程形成了死锁。改正：

 

 

    try {
            synchronized (scanLock) {    
                scanLock.wait(30 * 1000);
            }
            
        } catch (InterruptedException e) {
            AKeyLog.e(this, e);
        } finally {
            bm.stopMonitor();
            if (onFindBleDevice != null) {
                bm.unRegisteOnFindBleDevice(onFindBleDevice);
            }
        }

案例2：关键词:ContentResolver in AsyncTask onPostExecute, high iowait

Process:com.android.email
Activity:com.android.email/.activity.MessageView
Subject:keyDispatchingTimedOut
CPU usage from 2550ms to -2814ms ago:
5%187/system_server: 3.5% user + 1.4% kernel / faults: 86 minor 20major
4.4% 1134/com.android.email: 0.7% user + 3.7% kernel /faults: 38 minor 19 major
4% 372/com.android.eventstream: 0.7%user + 3.3% kernel / faults: 6 minor
1.1% 272/com.android.phone:0.9% user + 0.1% kernel / faults: 33 minor
0.9%252/com.android.systemui: 0.9% user + 0% kernel
0%409/com.android.eventstream.telephonyplugin: 0% user + 0% kernel /faults: 2 minor
0.1% 632/com.android.devicemonitor: 0.1% user + 0%kernel
100%TOTAL: 6.9% user + 8.2% kernel +84%iowait


-----pid 1134 at 2010-12-17 17:46:51 -----
Cmd line:com.android.email

DALVIK THREADS:
(mutexes: tll=0 tsl=0tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 WAIT
|group="main" sCount=1 dsCount=0 obj=0x2aaca180self=0xcf20
| sysTid=1134 nice=0 sched=0/0 cgrp=[fopen-error:2]handle=1876218976
at java.lang.Object.wait(Native Method)
-waiting on <0x2aaca218> (a java.lang.VMThread)
atjava.lang.Thread.parkFor(Thread.java:1424)
atjava.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48)
atsun.misc.Unsafe.park(Unsafe.java:337)
atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
atjava.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:808)
atjava.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:841)
atjava.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1171)
atjava.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:200)
atjava.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:261)
atandroid.database.sqlite.SQLiteDatabase.lock(SQLiteDatabase.java:378)
atandroid.database.sqlite.SQLiteCursor.<init>(SQLiteCursor.java:222)
atandroid.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:53)
atandroid.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1356)
atandroid.database.sqlite.SQLiteDatabase.queryWithFactory(SQLiteDatabase.java:1235)
atandroid.database.sqlite.SQLiteDatabase.query(SQLiteDatabase.java:1189)
atandroid.database.sqlite.SQLiteDatabase.query(SQLiteDatabase.java:1271)
atcom.android.email.provider.EmailProvider.query(EmailProvider.java:1098)
atandroid.content.ContentProvider$Transport.query(ContentProvider.java:187)
atandroid.content.ContentResolver.query(ContentResolver.java:268)
atcom.android.email.provider.EmailContent$Message.restoreMessageWithId(EmailContent.java:648)
atcom.android.email.Controller.setMessageRead(Controller.java:658)
atcom.android.email.activity.MessageView.onMarkAsRead(MessageView.java:700)
atcom.android.email.activity.MessageView.access$2500(MessageView.java:98)
atcom.android.email.activity.MessageView$LoadBodyTask.onPostExecute(MessageView.java:1290)
atcom.android.email.activity.MessageView$LoadBodyTask.onPostExecute(MessageView.java:1255)
atandroid.os.AsyncTask.finish(AsyncTask.java:417)
atandroid.os.AsyncTask.access$300(AsyncTask.java:127)
atandroid.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:429)
atandroid.os.Handler.dispatchMessage(Handler.java:99)
atandroid.os.Looper.loop(Looper.java:123)
atandroid.app.ActivityThread.main(ActivityThread.java:3652)
atjava.lang.reflect.Method.invokeNative(Native Method)
atjava.lang.reflect.Method.invoke(Method.java:507)
atcom.android.internal.os.ZygoteIn

原因：IOWait很高，说明当前系统在忙于I/O，因此数据库操作被阻塞

原来：

 

finalMessagemessage=Message.restoreMessageWithId(mProviderContext,messageId);
if(message==null){
   return;
}

Accountaccount=Account.restoreAccountWithId(mProviderContext,message.mAccountKey);

if(account==null){
   return;//isMessagingController returns false for null, but let's make itclear.
}

if(isMessagingController(account)){
   new Thread(){
       @Override
       public void run(){
          mLegacyController.processPendingActions(message.mAccountKey);
       }
   }.start();
}

解决后：

 

 

 

newThread() {
    finalMessagemessage=Message.restoreMessageWithId(mProviderContext,messageId);

    if(message==null){
        return;
    }

    Accountaccount=Account.restoreAccountWithId(mProviderContext,message.mAccountKey);

    if(account==null){
       return;//isMessagingController returns false for null, but let's make itclear.
    }

    if(isMessagingController(account)) {
        mLegacyController.processPendingActions(message.mAccountKey);
    }
}.start();

 

关于AsyncTask:http://developer.android.com/reference/android/os/AsyncTask.html


案例3：关键词:在UI线程进行网络数据的读写

ANRin process: com.android.mediascape:PhotoViewer (last incom.android.mediascape:PhotoViewer)
Annotation:keyDispatchingTimedOut
CPU usage:
Load: 6.74 / 6.89 / 6.12
CPUusage from 8254ms to 3224ms ago:
ovider.webmedia: 4% = 4% user +0% kernel / faults: 68 minor
system_server: 2% = 1% user + 0%kernel / faults: 18 minor
re-initialized>: 0% = 0% user + 0%kernel / faults: 50 minor
events/0: 0% = 0% user + 0%kernel
TOTAL:7% = 6% user + 1% kernel

DALVIKTHREADS:
""main"" prio=5 tid=3 NATIVE
|group=""main"" sCount=1 dsCount=0 s=Yobj=0x4001b240 self=0xbda8
| sysTid=2579 nice=0 sched=0/0cgrp=unknown handle=-1343993184
atorg.apache.harmony.luni.platform.OSNetworkSystem.receiveStreamImpl(NativeMethod)
atorg.apache.harmony.luni.platform.OSNetworkSystem.receiveStream(OSNetworkSystem.java:478)
atorg.apache.harmony.luni.net.PlainSocketImpl.read(PlainSocketImpl.java:565)
atorg.apache.harmony.luni.net.SocketInputStream.read(SocketInputStream.java:87)
atorg.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection$LimitedInputStream.read(HttpURLConnection.java:303)
atjava.io.InputStream.read(InputStream.java:133)
atjava.io.BufferedInputStream.fillbuf(BufferedInputStream.java:157)
atjava.io.BufferedInputStream.read(BufferedInputStream.java:346)
atandroid.graphics.BitmapFactory.nativeDecodeStream(Native Method)
atandroid.graphics.BitmapFactory.decodeStream(BitmapFactory.java:459)
atcom.android.mediascape.activity.PhotoViewerActivity.getPreviewImage(PhotoViewerActivity.java:4465)
atcom.android.mediascape.activity.PhotoViewerActivity.dispPreview(PhotoViewerActivity.java:4406)
atcom.android.mediascape.activity.PhotoViewerActivity.access$6500(PhotoViewerActivity.java:125)
atcom.android.mediascape.activity.PhotoViewerActivity$33$1.run(PhotoViewerActivity.java:4558)
atandroid.os.Handler.handleCallback(Handler.java:587)
atandroid.os.Handler.dispatchMessage(Handler.java:92)
atandroid.os.Looper.loop(Looper.java:123)
atandroid.app.ActivityThread.main(ActivityThread.java:4370)
atjava.lang.reflect.Method.invokeNative(Native Method)
atjava.lang.reflect.Method.invoke(Method.java:521)
atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
atdalvik.system.NativeStart.main(Native Method)

关于网络连接，在设计的时候可以设置个timeout的时间或者放入独立的线程来处理。

关于Handler的问题，可以参考：http://developer.android.com/reference/android/os/Handler.html

案例4：

关键词：Memoryleak/Thread leak

11-1621:41:42.560 I/ActivityManager( 1190): ANR in process:android.process.acore (last in android.process.acore)
11-1621:41:42.560 I/ActivityManager( 1190): Annotation:keyDispatchingTimedOut
11-16 21:41:42.560 I/ActivityManager(1190): CPU usage:
11-16 21:41:42.560 I/ActivityManager( 1190):Load: 11.5 / 11.1 / 11.09
11-16 21:41:42.560 I/ActivityManager(1190): CPU usage from 9046ms to 4018ms ago:
11-16 21:41:42.560I/ActivityManager( 1190): d.process.acore:98%= 97% user + 0% kernel / faults: 1134 minor
11-16 21:41:42.560I/ActivityManager( 1190): system_server: 0% = 0% user + 0% kernel /faults: 1 minor
11-16 21:41:42.560 I/ActivityManager( 1190): adbd:0% = 0% user + 0% kernel
11-16 21:41:42.560 I/ActivityManager(1190): logcat: 0% = 0% user + 0% kernel
11-16 21:41:42.560I/ActivityManager( 1190): TOTAL:100% = 98% user + 1% kernel

Cmdline: android.process.acore

DALVIK THREADS:
"main"prio=5 tid=3 VMWAIT
|group="main" sCount=1 dsCount=0 s=N obj=0x40026240self=0xbda8
| sysTid=1815 nice=0 sched=0/0 cgrp=unknownhandle=-1344001376
atdalvik.system.VMRuntime.trackExternalAllocation(NativeMethod)
atandroid.graphics.Bitmap.nativeCreate(Native Method)
atandroid.graphics.Bitmap.createBitmap(Bitmap.java:468)
atandroid.view.View.buildDrawingCache(View.java:6324)
atandroid.view.View.getDrawingCache(View.java:6178)
atandroid.view.ViewGroup.drawChild(ViewGroup.java:1541)
……
atcom.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:1830)
atandroid.view.ViewRoot.draw(ViewRoot.java:1349)
atandroid.view.ViewRoot.performTraversals(ViewRoot.java:1114)
atandroid.view.ViewRoot.handleMessage(ViewRoot.java:1633)
atandroid.os.Handler.dispatchMessage(Handler.java:99)
atandroid.os.Looper.loop(Looper.java:123)
atandroid.app.ActivityThread.main(ActivityThread.java:4370)
atjava.lang.reflect.Method.invokeNative(Native Method)
atjava.lang.reflect.Method.invoke(Method.java:521)
atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
atdalvik.system.NativeStart.main(Native Method)

"Thread-408"prio=5 tid=329 WAIT
|group="main" sCount=1 dsCount=0 s=N obj=0x46910d40self=0xcd0548
| sysTid=10602 nice=0 sched=0/0 cgrp=unknownhandle=15470792
at java.lang.Object.wait(Native Method)
-waiting on <0x468cd420> (a java.lang.Object)
atjava.lang.Object.wait(Object.java:288)
atcom.android.dialer.CallLogContentHelper$UiUpdaterExecutor$1.run(CallLogContentHelper.java:289)
atjava.lang.Thread.run(Thread.java:1096)

分析：

atdalvik.system.VMRuntime.trackExternalAllocation(NativeMethod)内存不足导致block在创建bitmap上

**MEMINFO in pid 1360 [android.process.acore] **
native dalvik other total
size: 17036 23111 N/A 40147
allocated: 16484 20675 N/A 37159
free: 296 2436 N/A 2732

解决：如果机器的内存族，可以修改虚拟机的内存为36M或更大，不过最好是复查代码，查看哪些内存没有释放

 

 

 

1.4 如何避免ANR

1.4.1 ANR发生在主线程，不要阻塞主线程
        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来提示用户工作进度；
        对于游戏类的应用，应该使用子线程去做位置计算；
        如果应用程序的初始化过程比较耗时，可以在初始化时显示一个过场动画或者图片，也可以先快速的显示主界面然后再异步的加载初始化数据。