ANR與Crash

實際開發過程當中，ANR和Crash常常會出現，若是要想辦法避免他們的出現，首先就要了解他們

ANR

ANR即（application not responding），即應用無響應，程序會彈出一個dialog提示用戶程序無響應，而這對於用戶體驗無疑是很很差的

至於程序爲什麼會「無響應」，主要有如下幾個緣由

1：InputDispatching (5 seconds) --主要類型

按鍵或觸摸等輸入事件在特定時間內無響應

2：BroadcastTimeout(10 seconds)

BroadcastReceiver在特定時間內沒法處理完成

3：ServiceTimeout(20 seconds) --小几率類型

Service在特定的時間內沒法處理完成

看起來好像略複雜，其實能夠換個角度來理解，通常對於正常的APP而言，能形成長時間操做的主要就是耗時操做，大致上分爲兩類，其一是網絡操做，其二是文件，數據庫的讀寫操做

若是耗時操做在UI線程，也就是主線程內進行操做，並且也確實「耗時」的狀況下，就會形成UI線程的堵塞，也就形成了ANR

因此簡而言之，可以解決ANR的辦法就是不在主線程內進行耗時操做

這裏就提出了一個概念，異步

異步說的簡單些，就是多開線程，在其餘線程內處理這些耗時操做，處理完畢以後，返回所須要的參數給主線程，主線程再作操做（因此之因此主線程又叫作UI線程，是由於咱們應該只在主線程內處理UI操做）

異步的實現就說來話長了，從最開始的Thread+Handler，到後面的AsyncTask，再到Rxjaca，這裏就很少作說明了

經過異步，咱們可讓UI線程不堵塞或者儘可能低可能性的堵塞，這樣就極大避免了ANR的出現

Crash

crash，即崩潰，和ANR同樣，系統會彈出一個dialog提示用戶該應用已崩潰，同理，用戶體驗很糟糕

之因此會出crash，一句話歸納，基本就是由於異常的出現

在程序中可能會出現你未捕獲到的異常，這就形成了崩潰，可是這種狀況下即便出現了crash咱們也應該換一種對用戶較爲友好的方式來告知用戶

那麼如何改掉crash的提示方式呢，比較原始的方法，附上任玉剛大神的一篇博文

Android程序Crash時的異常上報

固然了，這麼久過去了，如今處理的方式也能夠接入第三方的SDK來解決，遠的不說，騰訊的Bugly就是其中一種解決方案