關於異常
異常?
異常就是一種程式中沒有預料到的問題，既然是沒有預料到的，就可能不在原有邏輯處理範圍內,脫離了程式碼控制,軟體可能會出現各種奇怪的現象。比如：android系統常見異常現象有應用無響應、應用停止執行、凍屏、重啟、當機等，這些異常系統有統一的異常處理機制，出現異常系統就會執行相應的操作，最終有相應的現象體現出來。另外，一些不在預料之中的介面顯示問題，操作問題，執行卡頓問題等也可以歸於異常，只不過這種異常是人為邏輯缺陷，對系統來說是正常的，但這些缺陷在異常現象中佔比卻相當大，直接體現出軟體的質量。
架構決定邏輯,邏輯決定異常多少
異常重要性
都說ISO比android系統好，iphone手機比android手機好，為什麼呢？其實最基本原因就是ISO系統穩定性和體驗做得好，很少出現異常，使用一段時間後執行還是很穩健，且它的介面、操作、執行速度等體驗也做的非常好，所以才被大家認可。
異常關係一個軟體的穩定性
缺陷關係一個軟體的效能和體驗
打造精品，追求卓越，對軟體開發人員來說就是追求零異常、零缺陷。我們做的軟體，負責的模組應用質量怎麼樣，是不是精品都是通過異常數量和缺陷數量來體現的。這篇文件主要講的是log分析，屬於事後處理，處理的是使用者的抱怨和不滿，處理的是我們開發時埋下的雷或未挖掘出的雷，是被動的。所以，更重要的是軟體量產前開發工作中，怎樣去減少異常和缺陷，保證軟體質量。
(公司戰略,對研發部門要求)
異常分類
Android是一個龐大而複雜的系統，涉及多種語言，所以其異常也很複雜。根據android系統架構層次，我們也把android異常層次化，分為JE、NE、KE、EE、其他類別
l JE (Java layer exception) 一般是在應用層和框架層發生的異常，通常是由Java程式碼，XML程式碼引起的。比如各種RuntimeException, ANR（Application Not Responding）、SWT（Software Watchdog Timeout）等
l NE (Native layer exception) 發生在Linux使用者空間的異常，通常是由C/C++程式碼和庫檔案引起的。比如核心發出的NE訊號（SIGILL、 SIGABRT、 SIGBUS等）
l KE (Kernel layer execption) 通常指核心故障或核心錯誤，由於在核心模式下出錯，這類異常是非常嚴重的，往往會導致重啟、當機或無法開機等
l EE (External (Modem) exception) 從名字看就能猜到Modem這一部分是比較特殊的，獨立的。Modem有自己的記憶體空間和程式碼，為手機通訊提供服務，一旦這一部分發生異常，需要MDlog，此log需用AEE-LogVie工具解析，解析是需要對應版本的資料檔案，具體使用可參考《GAT_User_Guide(Customer).pdf》文件
l 其他 除了以上型別外，還有些異常可能沒有明顯的類別，例如一些由硬體引起的異常
Android系統架構圖
異常復現和日誌列印
異常復現
解決異常的關鍵之一就是復現異常。比如，對於偶現異常，如果能要找到必現路徑，那問題就變得容易多了。解決異常問題首先要了解異常，清楚異常怎麼發生的，什麼條件下發生的。下面是異常復現需要注意的地方。
異常復現注意點：
l 仔細閱讀異常描述，弄清楚異常產生步驟、異常概率、異常預置條件，並預判屬於哪一類異常
l 復現前，確認是否打LOG，如果是偶現問題，務必開啟此異常型別需要LOG
l 根據描述復現異常，如果是偶現問題，注意條件，儘量找出異常必現路徑
l 如果沒有復現異常，和異常資訊提供人溝通，再次復現
客戶報的異常可能是正常的
日誌列印
解決異常的關鍵之二就是抓取有效的LOG。比如，ANR異常必須抓取bugreport或trace.txt檔案，NE異常必須抓取aee_exp， EE異常必須抓取MDLog。根據不同異常型別抓取不同LOG，有針對性的分析。下面是異常日誌列印需要注意的地方。
一份錯誤的LOG是分析問題的, 發生了異常,沒有抓到正確的LOG, 就可能浪費掉一次補救機會
異常列印注意點：
l 抓LOG前，清除SD卡和內部儲存裡原有的LOG檔案，減少不必要的LOG帶來的分析困擾
l 抓log前，設定好異常產生的預置條件，特別是需要對比的異常，確保預置條件一樣
l 根據異常型別，開啟必須的LOG。任何異常，mtklog都是必要的，重啟、當機異常，儘量多抓LOG
l 抓LOG後，記錄下異常出現的手機顯示時間，必要時截圖，連同異常描述一起備註在log裡
異常分析之ANR
ANR種類
l Key Dispatch Timeout (8s)
No response to an input event(e.g. key press, screen touch) within 8 seconds
l Broadcast Timeout
A BroadcastReceiver hasn’t finished executing within setting seconds
BROADCAST_FG_TIMEOUT: 10s
BROADCAST_BG_TIMEOUT: 60s
l Service Timeout （20s）
Request service failed within 20 seconds
按鍵或廣播等事件在特定時間內未響應，這裡特定時間在系統裡設定的，各平臺可能不一樣，上面的時間是KK平臺預設超時時間，一般定義在ActivityManagerService.java類中，如：
static final int KEY_DISPATCHING_TIMEOUT = 5*1000
ANR產生原因
l 應用程式有一個主執行緒（main thread）和一個資訊佇列(main message queue)main thead == activity thread
l 主執行緒負責處理像Draw、Listen、receive等UI事件
l 主執行緒負責從訊息佇列中取出資訊並分發它
l 主執行緒在完成當前資訊處理之前，不會再取資訊佇列中的資訊
l 如果主執行緒在處理當前資訊時卡住，沒有及時分發，ANR就會出現
如何避免ANR
l UI執行緒儘量只做跟UI相關的工作
l 耗時的工作（比如資料庫操作，I/O，連線網路或者別的有可能阻礙UI執行緒的操作）把它放入單獨的執行緒處理
l 儘量用Handler來處理UI thread和別的thread之間的互動
ANR分析需要的LOG
l MTKlog，主要是其中的Aee_exp和MobileLog
l Trace.txt檔案（data/anr目錄下）或者bugreport日誌（使用adb bugreport > bugreport.txt或者GAT工具輸出）
ANR分析流程
由於ANR型別多，觸發ANR的條件也多，且LOG中沒有像RuntimeException異常那樣有明顯的關鍵字Fatal來準確定位問題點，所以，ANR分析相對比較麻煩點，但是隻要有完整的LOG，按照方法去分析還是很快的。下圖是MTK分析ANR的流程圖，通過ANR觸發型別一步一步查詢排除
MTK分析ANR的流程圖
l 首先，檢查log中是否有ANR資訊
events_log
00:28:19.999 544 564 I am_anr : [0,3003,com.example.test,11058758,keyDispatchingTimedOut]
main_log 或 Sys_log
00:28:31.193 544 564 E ANRManager: ANR in com.example.test (com.example.test/.MainActivity)
traces.txt
----- pid 3003 at 2013-06-01 00:28:20 -----
Cmd line: com.example.test
JNI: CheckJNI is off; workarounds are off; pins=0; globals=147
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 SUSPENDED
| group="main" sCount=1 dsCount=0 obj=0x40d5ea18 self=0x40d4e0d8
| sysTid=3003 nice=0 sched=0/0 cgrp=apps handle=1074645084
| state=S schedstat=( 16757266877 27764681051 104147 ) utm=1184 stm=491 core=0
#00 pc 0002746c /system/lib/libc.so (__futex_syscall3+8)
#01 pc 0000f694 /system/lib/libc.so (__pthread_cond_timedwait_relative+48)
………
#12 pc 00020580 [stack]
at libcore.io.Posix.strerror(Native Method)
at libcore.io.ForwardingOs.strerror(ForwardingOs.java:128)
at libcore.io.ErrnoException.getMessage(ErrnoException.java:52)
at java.lang.Throwable.getLocalizedMessage(Throwable.java:187)
at java.lang.Throwable.toString(Throwable.java:361)
at java.lang.Throwable.printStackTrace(Throwable.java:321)
at java.lang.Throwable.printStackTrace(Throwable.java:355)
at java.lang.Throwable.printStackTrace(Throwable.java:288)
at java.lang.Throwable.printStackTrace(Throwable.java:236)
at com.example.test.MainActivity.monitorANR(MainActivity.java:200)
at com.example.test.MainActivity$1.handleMessage(MainActivity.java:38)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:194)
l 如果定位不到資訊點，再看看CUP使用情況
main_log
06-01 00:28:31.193 544 564 E ANRManager: ANR in com.example.test (com.example.test/.MainActivity)
06-01 00:28:31.193 544 564 E ANRManager: Reason: keyDispatchingTimedOut
06-01 00:28:31.193 544 564 E ANRManager: Load: 10.5 / 11.94 / 6.06
06-01 00:28:31.193 544 564 E ANRManager: Android time :[2013-06-01 00:28:31.176] [454.712]
06-01 00:28:31.193 544 564 E ANRManager: CPU usage from 0ms to 11736ms later:
06-01 00:28:31.193 544 564 E ANRManager: 34% 3003/com.example.test: 26% user + 8.4% kernel / faults: 708 minor 10 major
06-01 00:28:31.193 544 564 E ANRManager: 32% 3018/logcat: 10% user + 21% kernel / faults: 4143 minor
06-01 00:28:31.193 544 564 E ANRManager: 23% 379/mobile_log_d: 8.7% user + 14% kernel / faults: 10 minor 1 major
06-01 00:28:31.193 544 564 E ANRManager: 19% 171/adbd: 1.7% user + 17% kernel / faults: 423 minor
06-01 00:28:31.193 544 564 E ANRManager: 18% 544/system_server: 8.5% user + 9.8% kernel / faults: 899 minor 2 major
06-01 00:28:31.193 544 564 E ANRManager: 14% 132/mobile_log_d: 1.7% user + 13% kernel
……
06-01 00:28:31.193 544 564 E ANRManager: 96% TOTAL: 36% user + 60% kernel + 0% iowait
從CPU使用率可以看出
如果CPU使用量接近100%，說明當前裝置很忙(記憶體不足，迴圈處理等)
如果CPU使用量很少，說明主執行緒被BLOCK了（Activity超過5秒等）
如果IOwait很高，說明ANR有可能是主執行緒在進行I/O操作造成的（資料庫操作、檔案操作、網路操作等）
l 根據CPU使用情況，在main_log和event_log中查詢有用資訊
main_log
l 結合log看程式碼，找到原因
為了讓ANR出現,在onClick裡面用了while(true),不斷的檔案讀寫，報錯不斷列印（不要這樣打log）
等待鎖引起的ANR
l events_log
22:05:22.819934 732 755 I am_anr : [0,24992,com.example.test,8961606,Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)
l main_log或 Sys_log
01-01 22:05:22.857387 732 755 E ANRManager: ANR in com.example.test (com.example.test/.MainActivity)
01-01 22:05:22.857387 732 755 E ANRManager: Reason: Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)
l traces.txt
----- pid 29364 at 2014-01-01 22:05:22 ----- Cmd line: com.example.test
JNI: CheckJNI is off; workarounds are off; pins=0; globals=263
DALVIK THREADS: (mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 MONITOR | group="main" sCount=1 dsCount=0 obj=0x419cede0 self=0x419bd8a8
| sysTid=29364 nice=0 sched=0/0 cgrp=apps handle=1074139524
| state=S schedstat=( 265882702 297191749 665 ) utm=19 stm=7 core=0
at com.example.test.MainActivity$ANRBroadcast.onReceive(MainActivity.java:~120)
- waiting to lock <0x41edc968> (a java.lang.Object) held by tid=11 (Thread-720) at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:798) at android.os.Handler.handleCallback(Handler.java:808)
l 對應程式碼
異常分析之OOM
OOM產生原因
Android應用記憶體管理機制是在Java記憶體管理機制基礎上改進的，所以造成OOM的原因兩者差不多，即所有物件都在堆上分配空間，堆是有大小限制的，當分配的物件不能被回收仍然佔據堆空間，新分配的物件不能獲取足夠的堆空間時，就會OOM。為什麼會這樣呢？這就是GC不足的地方，GC只能回收自己記錄（有向樹）裡面不可達的物件，對可達物件認為是有用的，不會被回收。但是可達物件並非一定是有用物件，他們可能是廢棄物件（死物件、冗餘物件、電燈泡，殭屍），但卻無法被GC回收，佔據著程式堆空間，下面是網上的一個物件例項化簡圖
各種OOM情景
l 資源物件沒有回收，如cursor，bitmap等
通常關閉Cursor的方法：
Cursor cursor = mDownloadManager.query(new Query());
try {
if (cursor.moveToFirst()) {
do {
int index = cursor.getColumnIndex(DownloadManager.COLUMN_ID);
long downloadId = cursor.getLong(index);
ids.add(downloadId);
} while (cursor.moveToNext());
}
} finally {
cursor.close();
}
另外，在adapter中使用cursor時，需在cursor改變的時候先關閉原來的cursor， 但通常我們都是用android提供的CursorAdapter，其changeCursor函式會將原來的Cursor釋放掉，並替換為新的Cursor，所以你不用擔心原來的Cursor沒有被關閉。
l 註冊沒有對應的去註冊，如各種監聽
l 生命週期問題引起的無法回收，如果static、執行緒等
l 其他
所有發生OOM情景最終都可以認為是物件沒有被回收，如，cursor沒有close()，bitmap沒有recycle()，監聽沒有unregister…()等等都是因為物件沒有被回收，GC認為這些物件是可達的、正在使用的，導致這些應該被回收的物件不能被回收，最終造成OOM。
大多數的回收方法，如close()、recycle()、unregister…()，其實都是把不再使用的物件置為null，這樣GC就能回收原來物件所佔空間。所以在程式設計的時候，對全域性變數，特別是容器之類的物件和status 修飾物件，要關注其生命週期，不再需要就及時置為null或呼叫相應的回收方法
OOM LOG分析
發生OOM異常後，如果僅僅只有mtklog，只能從Log中知道發生了OOM，但怎麼發生的卻看不出來，所以通常需要OOM分析工具，下面以MAT工具為例
在eclipse中，監視你需要分析OOM的程式，某種規律下，發現程式記憶體一直在漲，抓取hprof檔案：
這裡的某種規律，是指某種操作下，不斷重複就會出現OOM。經常導致OOM的操作有來回切換介面、回來滑動list、不斷的點選某個按鈕等，這些操作都是不斷更新介面，不斷的生產物件，生產的物件導致堆空間越來越大，最終發生OOM
DDMS dump 出來的hprof檔案需要經過SDK下hprof-conv（位於sdk/tools下）轉換後才能被MAT工具使用
hprof-conv xxx.hprof d:/xxxold.hprof
然後使用MAT工具開啟
1. Cache洩漏
多次插拔耳機後，發現記憶體一直在漲：
點選Details進入下面頁面：
點選Patch To GC Root：
發現一個靜態變數 sAnimators，此為懷疑的地方，檢視程式碼，加點log，編譯除錯：
Log.d("CWW", "sAnimators.size() = " + sAnimators.size());
可以看出，插拔耳機操作後，sAnimators.size一直會增大。
處理方法：防止快取過大，可以設定上限，也可以定期清理下！
對記憶體敏感的應用，防止快取過大，除了設定上限外，同時使用SoftReference，當記憶體吃緊時可以回收快取，這預防程式設計的一個技巧，但是使用SoftReference時，注意對null情況的處理，因為獲取物件可能已經被回收，獲取返回就null
2. 執行緒未釋放導致的洩漏
後臺播放音樂，不停切換主題，最後Launcher OOM
如下圖，5個AppsCustomizePagedView例項，明顯洩漏了：
點選
，選中一個例項，Path To GC Roots：
已經看到被CircleProgress.java的MyTimerTask持有：
再看程式碼，修改後，除錯記憶體，正常：
這樣改記憶體洩露解決了, 但是後面引入了新的功能問題, 重新修改了。所以修改類似問題時多小心，確認生命週期已經完成後再執行回收
結束語：
這些問題大多是比較難解的問題，大部分都是隨機的，往往都是很難復現的，找出規律是很重要的！
另外，記憶體洩露不容易發現，一些輕微的洩露，可能要使用一個月才能發現，所以對自己的模組，要自己去檢查有沒有OOM，可以下班時掛上monkey，有時候是能跑出來的
從OOM聯想到效能問題，效能問題很多是介面重新整理、物件生命週期、冗餘操作、不必要的執行緒等引起的……
異常分析之SWT
認識SWT
SWT是指Android Watchdog Timeout，應用層看門狗超時，通常我們說的WDT（Watchdog Timeout）是HWT，硬體看門狗超時。應用層Watchdog主要實現是在frameworks/base/services/java/com/android/server/Watchdog.java裡，其實現原理看看這個類就知道，主要邏輯是：
1. Watchdog是單例模式，監控系統幾個比較重要的Service，如：MountService、ActivityManagerService、InputManagerService等，這些Service在啟動時通過呼叫Watchdog.getInstance().addMonitor(this); 加入到Watchdog的監控列表中
2. 在SystemServer的 ServerThread執行緒中，初始化watchdog並啟動它
3. Watchdog執行緒向ServerThread執行緒傳送一個MONITOR message，同時將mCompleted標誌位置為false
4. 然後Watchdog執行緒Sleep 60秒(不包含系統睡眠的時間)，如果mCompleted標誌位不為true，則認為發生watchdog超時，之後Android就會重啟.
5. ServerThread收到這個訊息後會依次執行之前每個Service Object的monitor()函式，當執行完後會將mCompleted標誌位置為true.
SWT LOG分析
SWT也是一種ANR，普通ANR是某個AP的主執行緒在一段時間內沒有做完某件事情；SWT是SystemServer程式的ServerThread執行緒在一段時間內沒有做完某件事情。所以SWT的分析方法和ANR分析方法是一樣的，只是現象不一樣，發生SWT手機會重啟
分析方法：
1. 從eventlog中以watchdog為關鍵字搜尋，記錄下這個時刻。
2. 然後分析所有Service Object的monitor()為何在這個時刻之前1分鐘內沒有做完。具體資訊主要查詢log檔案有sys_log和mtklog\aee_exp\db.fatal.00.SWT\db.fatal.00.SWT.dbg.DEC
3. 後面具體的分析方法和ANR一樣
重啟當機
重啟
從異常分類來看，重啟異常大多數和NE、KE和硬體問題有關，JE方面引起重啟當機大多是和系統程式有關，如system_process程式發生了Crash、SWT、JVM Error，AP應用一般是不會引起重啟當機的，但偶爾也會
72平臺上，傳送簡訊內容為‘==’時會重啟
雖然是Mms引起的，但最終也是System_process掛掉了，導致重啟
重啟異常分析步驟（JE）：
1. 確認異常型別（用QAAT跑一下做初步判斷，如果是NE、KE讓驅動人員幫忙解決）
2. 找到第一時間發生錯誤的地方，因為後面的錯誤多半是因為前面錯誤引起的，那就沒有意義
3. 根據JE型別，結合對應工具分析LOG
當機
這裡說的當機就是凍屏，停留在一個介面沒反應。當機問題很少遇到，且大多不是一個用層問題，下面簡單說下可能造成當機的原因和分析需要資訊
當機可能原因：
1. 輸入系統或者輸入驅動問題
2. 系統邏輯問題或阻塞
3. Surfacefinger問題
4. 顯示系統或LCM驅動問題
相關資訊和抓log：
1. 確認adb是否可用
2. 抓取bugreport，adb bugreport > d:/bugreport.txt
3. 抓取dumpstate資訊，adb shell dumpstate > d:/dumpstate.txt
4. 抓取CPU資訊，adb shell top –t –m 5 > d:/cpu.txt
5. 確認是否可以撥打電話，adb shell am start –a android.intent.action.CALL tel:10086(看介面是否能夠更新)
6. 檢視按鍵和觸屏報點，adb shell getevent
7. 抓取Surfacefinger程式資訊，先adb shell ps –p找出pid，然後使用adb shell rtt –f bt –p pid > rtt.txt
LOG相關工具
MTK提供了多種抓取和檢視LOG的工具, 如:mtklogger，GAT，Catcher，LogView，QAAT等，這些工具在文件《MediaTek_Logging_SOP.pdf》中都有描述
Mtklogger:
Mtklogger是抓取log的apk，整合了ModemLog，MobileLog，NetworkLog and SystemLogger，在工程模式操作就可以打相關log了。
GAT：
基於SDK除錯開發的GUI工具，新增了Log Recoder，Debug Configuration Setting，DBpuller，adb command，Process Information view，Profiling Tools，LogView，Plug-in Script。是除錯和抓log的神器，使用說明閱讀文件《GAT_User_Guide(Customer).pdf》
工具獲取路徑（以W1444版本為例）：
\\192.168.1.75\rd\MTK_TOOL\AndroidTool\W1444\W1444_full.zip\Debugging Tools (Binary)\GAT
Catcher：
是抓取和解析ModemLog的PC端工具，我們經常使用來檢視ModemLog，使用說明閱讀文件《Catcher_User_Manual_for_Customer.pdf》
工具獲取路徑：
\\192.168.1.75\rd\MTK_TOOL\AndroidTool\W1444\W1444_full.zip\Catcher
LogView：
可以檢視APlog，Taglog，MTKlog，但最常用的是用來檢視NE時產生的AEE DB檔案裡的log，具體使用參考《GAT_User_Guide(Customer).pdf》
工具獲取路徑：
此工具已整合到GAT
QAAT：
快速分析log的工具，涵蓋錯誤型別較廣，很多地方都可以用，其實他的原理就是過濾關鍵字，把各種型別的錯誤過濾出來，是一個分析LOG非常便捷的工具，具體使用參考《MediaTek_Logging_SOP.pdf》
工具獲取路徑：
附件或者\\192.168.1.75\rd\MTK_TOOL\AndroidTool
