關於異常

異常?

異常就是一種程式中沒有預料到的問題，既然是沒有預料到的，就可能不在原有邏輯處理範圍內,脫離了程式碼控制,軟體可能會出現各種奇怪的現象。比如：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》

工具獲取路徑：

標籤：按鈕   root   loaded   缺陷   reads   src   img   detail   touch   

原文地址：http://www.cnblogs.com/xiyuan2016/p/6740623.html