#### 15.1.4 響應速度優化和ANR日志分析
響應速度優化的核心思想是避免在主線程中做耗時操作，但是有時候的確有很多耗時操作，怎么辦呢？可以將這些耗時操作放在線程中去執行，即采用異步的方式執行耗時操作。響應速度過慢更多地體現在Activity的啟動速度上面，如果在主線程中做太多事情，會導致Activity啟動時出現黑屏現象，甚至出現ANR。Android規定，Activity如果5秒鐘之內無法響應屏幕觸摸事件或者鍵盤輸入事件就會出現ANR，而BroadcastReceiver如果10秒鐘之內還未執行完操作也會出現ANR。在實際開發中，ANR是很難從代碼上發現的，如果在開發過程中遇到了ANR，那么怎么定位問題呢？其實當一個進程發生ANR了以后，系統會在/data/anr目錄下創建一個文件traces.txt，通過分析這個文件就能定位出ANR的原因，下面模擬一個ANR的場景。下面的代碼在Activity的onCreate中休眠30s，程序運行后持續點擊屏幕，應用一定會出現ANR：
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
SystemClock.sleep(30 ＊ 1000);
}
這里先假定我們無法從代碼中看出ANR，為了分析ANR的原因，可以到處traces文件，如下所示，其中．表示當前目錄：
adb pull /data/anr/traces.txt .
traces文件一般是非常長的，下面是traces文件的部分內容：
----- pid 29395 at 2015-05-31 16:14:36-----
Cmd line: com.ryg.chapter_15
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 TIMED_WAIT
| group="main" sCount=1 dsCount=0 obj=0x4185b700 self=0x4012d0b0
| sysTid=29395 nice=0 sched=0/0 cgrp=apps handle=1073954608
| schedstat=( 0 0 0 ) utm=3 stm=2 core=2
at java.lang.VMThread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:1031)
at java.lang.Thread.sleep(Thread.java:1013)
at android.os.SystemClock.sleep(SystemClock.java:114)
at com.ryg.chapter_15.MainActivity.onCreate(MainActivity.java:42)
at android.app.Activity.performCreate(Activity.java:5086)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.
java:1079)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.
java:2056)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.
java:2117)
at android.app.ActivityThread.access$600(ActivityThread.java:140)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1213)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4914)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:808)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:575)
at dalvik.system.NativeStart.main(Native Method)
"Binder_2" prio=5 tid=10 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x42296d80 self=0x69068848
| sysTid=29407 nice=0 sched=0/0 cgrp=apps handle=1750664088
| schedstat=( 0 0 0 ) utm=0 stm=0 core=1
#00 pc 0000cc50 /system/lib/libc.so (__ioctl+8)
#01 pc 0002816d /system/lib/libc.so (ioctl+16)
#02 pc 00016f9d /system/lib/libbinder.so (android::IPCThreadState::
talkWithDriver(bool)+124)
#03 pc 0001768f /system/lib/libbinder.so (android::IPCThreadState::
joinThreadPool(bool)+154)
#04 pc 0001b4e9 /system/lib/libbinder.so
#05 pc 00010f7f /system/lib/libutils.so (android::Thread::_threadLoop
(void＊)+114)
#06 pc 00048ba5 /system/lib/libandroid_runtime.so (android::Android-
Runtime::javaThreadShell(void＊)+44)
#07 pc 00010ae5 /system/lib/libutils.so
#08 pc 00012ff0 /system/lib/libc.so (__thread_entry+48)
#09 pc 00012748 /system/lib/libc.so (pthread_create+172)
at dalvik.system.NativeStart.run(Native Method)
從traces的內容可以看出，主線程直接sleep了，而原因就是MainActivity的42行。第42行剛好就是SystemClock.sleep(30 * 1000)，這樣一來就可以定位問題了。當然這個例子太直接了，下面再模擬一個稍微復雜點的ANR的例子。
下面的代碼也會導致ANR，原因是這樣的，在Activity的onCreate中開啟了一個線程，在線程中執行testANR()，而testANR()和initView()都被加了同一個鎖，為了百分之百讓testANR()先獲得鎖，特意在執行initView()之前讓主線程休眠了10ms，這樣一來initView()肯定會因為等待testANR()所持有的鎖而被同步住，這樣就產生了一個稍微復雜些的ANR。這個ANR是很參考意義的，這樣的代碼很容易在實際開發中出現，尤其是當調用關系比較復雜時，這個時候分析ANR日志就顯得異常重要了。下面的代碼中雖然已經將耗時操作放在線程中了，按道理就不會出現ANR了，但是仍然要注意子線程和主線程搶占同步鎖的情況。
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new Runnable() {
@Override
public void run() {
testANR();
}
}).start();
SystemClock.sleep(10);
initView();
}
private synchronized void testANR() {
SystemClock.sleep(30 ＊ 1000);
}
private synchronized void initView() {
}
為了分析問題，需要從traces文件著手，如下所示。
----- pid 32662 at 2015-05-31 16:40:21-----
Cmd line: com.ryg.chapter_15
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x4185b700 self=0x4012d0b0
| sysTid=32662 nice=0 sched=0/0 cgrp=apps handle=1073954608
| schedstat=( 0 0 0 ) utm=0 stm=4 core=0
at com.ryg.chapter_15.MainActivity.initView(MainActivity.java:～62)
- waiting to lock <0x422a0120> (a com.ryg.chapter_15.MainActivity) held
by tid=11 (Thread-13248)
at com.ryg.chapter_15.MainActivity.onCreate(MainActivity.java:53)
at android.app.Activity.performCreate(Activity.java:5086)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.
java:1079)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.
java:2056)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.
java:2117)
at android.app.ActivityThread.access$600(ActivityThread.java:140)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1213)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4914)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:808)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:575)
at dalvik.system.NativeStart.main(Native Method)
"Thread-13248" prio=5 tid=11 TIMED_WAIT
| group="main" sCount=1 dsCount=0 obj=0x422b0ed8 self=0x683d20c0
| sysTid=32687 nice=0 sched=0/0 cgrp=apps handle=1751804288
| schedstat=( 0 0 0 ) utm=0 stm=0 core=0
at java.lang.VMThread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:1031)
at java.lang.Thread.sleep(Thread.java:1013)
at android.os.SystemClock.sleep(SystemClock.java:114)
at com.ryg.chapter_15.MainActivity.testANR(MainActivity.java:57)
at com.ryg.chapter_15.MainActivity.access$0(MainActivity.java:56)
at com.ryg.chapter_15.MainActivity$1.run(MainActivity.java:49)
at java.lang.Thread.run(Thread.java:856)
上面的情況稍微復雜一些，需要逐步分析。首先看主線程，如下所示。可以看得出主線程在initView方法中正在等待一個鎖<0x422a0120>，這個鎖的類型是一個MainActivity對象，并且這個鎖已經被線程id為11（即tid=11）的線程持有了，因此需要再看一下線程11的情況。
at com.ryg.chapter_15.MainActivity.initView(MainActivity.java:～62)
- waiting to lock <0x422a0120> (a com.ryg.chapter_15.MainActivity) held
by tid=11 (Thread-13248)
tid是11的線程就是“Thread-13248”，就是它持有了主線程所需的鎖，可以看出“Thread-13248”正在sleep, sleep的原因是MainActivity的57行，即testANR方法。這個時候可以發現testANR方法和主線程的initView方法都加了synchronized關鍵字，表明它們在競爭同一個鎖，即當前Activity的對象鎖，這樣一來ANR的原因就明確了，接著就可以修改代碼了。
上面分析了兩個ANR的實例，尤其是第二個ANR在實際開發中很容易出現，我們首先要有意識地避免出現ANR，其次出現ANR了也不要著急，通過分析traces文件即可定位問題。
- 前言
- 第1章 Activity的生命周期和啟動模式
- 1.1 Activity的生命周期全面分析
- 1.1.1 典型情況下的生命周期分析
- 1.1.2 異常情況下的生命周期分析
- 1.2 Activity的啟動模式
- 1.2.1 Activity的LaunchMode
- 1.2.2 Activity的Flags
- 1.3 IntentFilter的匹配規則
- 第2章 IPC機制
- 2.1 Android IPC簡介
- 2.2 Android中的多進程模式
- 2.2.1 開啟多進程模式
- 2.2.2 多進程模式的運行機制
- 2.3 IPC基礎概念介紹
- 2.3.1 Serializable接口
- 2.3.2 Parcelable接口
- 2.3.3 Binder
- 2.4 Android中的IPC方式
- 2.4.1 使用Bundle
- 2.4.2 使用文件共享
- 2.4.3 使用Messenger
- 2.4.4 使用AIDL
- 2.4.5 使用ContentProvider
- 2.4.6 使用Socket
- 2.5 Binder連接池
- 2.6 選用合適的IPC方式
- 第3章 View的事件體系
- 3.1 View基礎知識
- 3.1.1 什么是View
- 3.1.2 View的位置參數
- 3.1.3 MotionEvent和TouchSlop
- 3.1.4 VelocityTracker、GestureDetector和Scroller
- 3.2 View的滑動
- 3.2.1 使用scrollTo/scrollBy
- 3.2.2 使用動畫
- 3.2.3 改變布局參數
- 3.2.4 各種滑動方式的對比
- 3.3 彈性滑動
- 3.3.1 使用Scroller7
- 3.3.2 通過動畫
- 3.3.3 使用延時策略
- 3.4 View的事件分發機制
- 3.4.1 點擊事件的傳遞規則
- 3.4.2 事件分發的源碼解析
- 3.5 View的滑動沖突
- 3.5.1 常見的滑動沖突場景
- 3.5.2 滑動沖突的處理規則
- 3.5.3 滑動沖突的解決方式
- 第4章 View的工作原理
- 4.1 初識ViewRoot和DecorView
- 4.2 理解MeasureSpec
- 4.2.1 MeasureSpec
- 4.2.2 MeasureSpec和LayoutParams的對應關系
- 4.3 View的工作流程
- 4.3.1 measure過程
- 4.3.2 layout過程
- 4.3.3 draw過程
- 4.4 自定義View
- 4.4.1 自定義View的分類
- 4.4.2 自定義View須知
- 4.4.3 自定義View示例
- 4.4.4 自定義View的思想
- 第5章 理解RemoteViews
- 5.1 RemoteViews的應用
- 5.1.1 RemoteViews在通知欄上的應用
- 5.1.2 RemoteViews在桌面小部件上的應用
- 5.1.3 PendingIntent概述
- 5.2 RemoteViews的內部機制
- 5.3 RemoteViews的意義
- 第6章 Android的Drawable
- 6.1 Drawable簡介
- 6.2 Drawable的分類
- 6.2.1 BitmapDrawable2
- 6.2.2 ShapeDrawable
- 6.2.3 LayerDrawable
- 6.2.4 StateListDrawable
- 6.2.5 LevelListDrawable
- 6.2.6 TransitionDrawable
- 6.2.7 InsetDrawable
- 6.2.8 ScaleDrawable
- 6.2.9 ClipDrawable
- 6.3 自定義Drawable
- 第7章 Android動畫深入分析
- 7.1 View動畫
- 7.1.1 View動畫的種類
- 7.1.2 自定義View動畫
- 7.1.3 幀動畫
- 7.2 View動畫的特殊使用場景
- 7.2.1 LayoutAnimation
- 7.2.2 Activity的切換效果
- 7.3 屬性動畫
- 7.3.1 使用屬性動畫
- 7.3.2 理解插值器和估值器 /
- 7.3.3 屬性動畫的監聽器
- 7.3.4 對任意屬性做動畫
- 7.3.5 屬性動畫的工作原理
- 7.4 使用動畫的注意事項
- 第8章 理解Window和WindowManager
- 8.1 Window和WindowManager
- 8.2 Window的內部機制
- 8.2.1 Window的添加過程
- 8.2.2 Window的刪除過程
- 8.2.3 Window的更新過程
- 8.3 Window的創建過程
- 8.3.1 Activity的Window創建過程
- 8.3.2 Dialog的Window創建過程
- 8.3.3 Toast的Window創建過程
- 第9章 四大組件的工作過程
- 9.1 四大組件的運行狀態
- 9.2 Activity的工作過程
- 9.3 Service的工作過程
- 9.3.1 Service的啟動過程
- 9.3.2 Service的綁定過程
- 9.4 BroadcastReceiver的工作過程
- 9.4.1 廣播的注冊過程
- 9.4.2 廣播的發送和接收過程
- 9.5 ContentProvider的工作過程
- 第10章 Android的消息機制
- 10.1 Android的消息機制概述
- 10.2 Android的消息機制分析
- 10.2.1 ThreadLocal的工作原理
- 10.2.2 消息隊列的工作原理
- 10.2.3 Looper的工作原理
- 10.2.4 Handler的工作原理
- 10.3 主線程的消息循環
- 第11章 Android的線程和線程池
- 11.1 主線程和子線程
- 11.2 Android中的線程形態
- 11.2.1 AsyncTask
- 11.2.2 AsyncTask的工作原理
- 11.2.3 HandlerThread
- 11.2.4 IntentService
- 11.3 Android中的線程池
- 11.3.1 ThreadPoolExecutor
- 11.3.2 線程池的分類
- 第12章 Bitmap的加載和Cache
- 12.1 Bitmap的高效加載
- 12.2 Android中的緩存策略
- 12.2.1 LruCache
- 12.2.2 DiskLruCache
- 12.2.3 ImageLoader的實現446
- 12.3 ImageLoader的使用
- 12.3.1 照片墻效果
- 12.3.2 優化列表的卡頓現象
- 第13章 綜合技術
- 13.1 使用CrashHandler來獲取應用的crash信息
- 13.2 使用multidex來解決方法數越界
- 13.3 Android的動態加載技術
- 13.4 反編譯初步
- 13.4.1 使用dex2jar和jd-gui反編譯apk
- 13.4.2 使用apktool對apk進行二次打包
- 第14章 JNI和NDK編程
- 14.1 JNI的開發流程
- 14.2 NDK的開發流程
- 14.3 JNI的數據類型和類型簽名
- 14.4 JNI調用Java方法的流程
- 第15章 Android性能優化
- 15.1 Android的性能優化方法
- 15.1.1 布局優化
- 15.1.2 繪制優化
- 15.1.3 內存泄露優化
- 15.1.4 響應速度優化和ANR日志分析
- 15.1.5 ListView和Bitmap優化
- 15.1.6 線程優化
- 15.1.7 一些性能優化建議
- 15.2 內存泄露分析之MAT工具
- 15.3 提高程序的可維護性