android平台程式崩潰大家都應該遇到過，force close和anr應該是大家遇到較多的。
這裡把android平台程式崩潰的各種型別做乙個簡述和原因列舉。
1.anr（可見anr）：
發生場景：應用發生anr。
崩潰症狀：系統彈出視窗詢問使用者選擇「force close」或者「wait」。
「force close」將殺掉發生anr的應用程序。「wait」將會等待系統擇機恢復此應用程序。
發生原因：
（1）應用主線程卡住，對其他請求響應超時。
（2）死鎖。
（3）系統反應遲鈍。
（4）cpu負載過重。
2.force close （fc）：
發生場景：應用程序崩潰。
崩潰症狀：系統彈出視窗提示使用者某程序崩潰。
發生原因：空指向異常或者未捕捉的異常。
3.tombstones：
發生場景：native層崩潰
崩潰症狀：如果發生崩潰的native層和ui有關聯（比如browser），我們可以在ui上發現這個崩潰。
如果發生崩潰的native層是在後台並且和ui沒有直接聯絡，那麼對於使用者來說是不可見的，如果
是debug版本可能會有log列印出當時的底層現場。
發生原因：各種各樣，需要具體情況具體分析。
4.系統服務崩潰（system server crash）：
發生場景：系統服務是android核心程序，此服務程序發生崩潰。
崩潰症狀：手機重啟到android啟動介面
發生原因：
（1）系統服務看門狗發現異常。
（2）系統服務發生未捕獲異常。
（3）oom。
（4）系統服務native發生tombstone。
5.kernel panics：
發生場景：linux核心發生嚴重錯誤
崩潰症狀：手機從bootloader開始完全重啟
發生原因：
（1）linux核心記憶體空間發生記憶體崩潰。
（2）核心看門狗發現異常。
（3）空指標操作核心。
iOS開發之常見crash
作為開發人員難免會遇到一些令人匪夷所思的crash.這裡我總結幾個常見的crash.可以說大多都是平時寫 時嚴謹點的話完全可以 避免的。首先，要說的是型別判斷。當我們拿到傳過來的乙個陣列或是字典或者字串的時候。我們是否應該考慮容錯問題。加入伺服器給我 們傳的不是這種型別的資料呢。因此我們以字典為例 ...
Android 使用NDK定位Crash
02 27 10 57 15.736 a libc 32000 fatal signal 11 sigsegv at 0x0000000c code 1 thread 32014 thread 1461 02 27 10 57 15.736 a libc 32000 send stop signal...
Android程式Crash異常處理
在寫程式時，肯定會碰到各種問題，在解決這些問題肯定要去看控制台列印的異常資訊，根據控制台列印的異常資訊來進行針對性的解決。那麼要解決程式執行在使用者手機上崩潰的問題，必須得找到問題的原因。因此就要收集崩潰資訊，也就是log日誌。android程式crash時我們可以做的操作 1 將crash資訊存到...