Android平臺提供了多種log輸出，這裏主要針對常見的幾種問題提供一些基礎的分析指南。
1. Java Crash
Java Crash是我們最爲常見的嚴重錯誤了。在Logcat中，可以找到其報錯的地方，通過其標註的位置開始調查代碼。
例如：
|
1
2
3
4
|
11-21 07:26:07.273 E/AndroidRuntime( 3755): FATAL EXCEPTION: main11-21 07:26:07.273 E/AndroidRuntime( 3755): java.lang.NullPointerException11-21 07:26:07.273 E/AndroidRuntime( 3755): at com.csi.player.mediaCallback(SourceFile:422)... |
在這裏，log裏面已經明確說明了錯誤的類型爲"java.lang.NullPointerException", 和發現這個問題的代碼"mediaCallback.java"的422行。
常見的嚴重錯誤有如下幾類：
-
NullPointerException: 空對象錯誤
IllegalStateException：非法狀態，比如在View沒有刷出來的時候去觸摸。
IndexOutOfBoundsException
IllegalArgumentException
ExceptionInInitializerError
ClassCastException
RuntimeException
UnknownFormatConversionException
UnsupportContentTypeException
CursorIndexOutOfBoundsException
2.ANR
ANR是一種常見的嚴重錯誤，在logcat中會直接給出造成ANR的原因，例如：
|
1
2
|
11-01 18:16:15.966 E/ActivityManager( 344): ANR in com.android.systemui11-01 18:16:15.966 E/ActivityManager( 344): Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x40000014 (has extras) } |
以上這個ANR就是由BroadcastTimeout引起的。
常見的ANR原因有如下：
| KeyDispatchTimeout(5 seconds) |
Key事件響應超時 |
| BroadcastTimeout(10 seconds) | BroadcastReceiver超時 |
| ServiceTimeout(20 seconds) |
Service超時 |
當ANR發生時，我們可以在/data/anr/下面發現響應的trace.txt裏面會有ANR的callstack，有助於我們定位問題。
3. Tombstone
tombstone一般是由Dalvik錯誤、狀態監視調試器、C層代碼以及libc的一些問題導致的。當系統發生tombstone的時候，kernel首先會上報一個嚴重的警告信號（serious signal）,上層接收到之後，進程的調試工具會把進程中當時的調用棧現場保存起來，並在系統創建了data/tombstones目錄後把異常時的進程信息寫在此目錄裏面，開發者需要通過調用棧來分析整個調用流程來找出出問題的點。
這裏主要介紹一下常用的分析步驟：
a. 首先查看日誌文件，搜索"SEGV_MAPERR" 或者 "SEGV_ACCERR"，
注： SEGV_MAPERR地址沒有映射到對象，SEGV_ACCERR對映射的對象沒有權限
例如：
|
1
2
3
4
5
6
|
pid: 122, tid: 14745, name: Binder_2 >>> /system/bin/mediaserver <<<signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000058 eax 00000000 ebx 41bbf784 ecx 00000000 edx 00000009 esi 450578f0 edi 40378054 xcs 00000073 xds 0000007b xes 0000007b xfs 00000000 xss 0000007b eip 4088a5c2 ebp 45e15cb8 esp 45e15ca0 flags 00010297 |
b. 再看backtrace
|
1
2
3
4
5
6
7
|
#00 pc 000085c2 /system/lib/libcameraservice.so (android::CameraHardwareInterface::__set_buffer_count(preview_stream_ops*, int)+34) #01 pc 0003b6fa /system/lib/hw/camera.XXXX.so (android::PreviewThread::allocateGfxPreviewBuffers(int)+154) #02 pc 0003ce83 /system/lib/hw/camera.XXXX.so (android::PreviewThread::threadLoop()+1203) #03 pc 0001a2bc /system/lib/libutils.so (android::Thread::_threadLoop(void*)+556) #04 pc 0000dda8 /system/lib/libc.so (__thread_entry+248) #05 pc 0001b031 /system/lib/libc.so #06 pc 00001f2c /system/lib/libc.so |
從這段log來看，發現問題發生時，出錯的lib爲libcameraservice.so。
c. 如果需要進一步分析，需要動用symbol文件，具體步驟這次就不詳述了。
4. Memory Leak
在Logcat輸出中，會出現
|
1
2
3
4
5
6
7
8
9
10
|
E/AndroidRuntime(1112):Caused by: java.lang.OutOfMemoryError: bitmap sizeexceeds VM budgetE/AndroidRuntime(1112):at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)E/AndroidRuntime(1112):at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:447)E/AndroidRuntime(1112):at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:323)E/AndroidRuntime(1112): |
這裏1112是進程的pid，代表出現OOM的應用。如果需要詳細分析，一般來說需要先製造出來hprof文件，詳細做法請參考Memaory debug。
5. Kernel Panic
通過demsg命令可以查看到內核log輸出。查找kernel panic和Bug等字樣就能找到。
