ANR定義：在Android上，如果你的應用程式有一段時間響應不夠靈敏，系統會向用戶顯示一個對話方塊，這個對話方塊稱作應用程式無響應（ANR：Application Not Responding）對話方塊。使用者可以選擇“等待”而讓程式繼續執行，也可以選擇“強制關閉”。所以一個流暢的合理的應用程式中不能出現anr，而讓使用者每次都要處理這個對話方塊。因此，在程式裡對響應效能的設計很重要，這樣系統不會顯示ANR給使用者。

    預設情況下，在android中Activity的最長執行時間是5秒，BroadcastReceiver的最長執行時間則是10秒。

第一：什麼會引發ANR？

    在Android裡，應用程式的響應性是由Activity Manager和WindowManager系統服務監視的

1.在5秒內沒有響應輸入的事件（例如，按鍵按下，螢幕觸控）
2.BroadcastReceiver在10秒內沒有執行完畢

造成以上兩點的原因有很多，比如在主執行緒中做了非常耗時的操作，比如說是下載，io異常等。

    潛在的耗時操作，例如網路或資料庫操作，或者高耗時的計算如改變點陣圖尺寸，應該在子執行緒裡（或者以資料庫操作為例，通過非同步請求的方式）來完成。然而，不是說你的主執行緒阻塞在那裡等待子執行緒的完成——也不是呼叫 Thread.wait()或是Thread.sleep()。替代的方法是，主執行緒應該為子執行緒提供一個Handler，以便完成時能夠提交給主執行緒。以這種方式設計你的應用程式，將能保證你的主執行緒保持對輸入的響應性並能避免由於5秒輸入事件的超時引發的ANR對話方塊。

第二：如何避免ANR？

1、執行在主執行緒裡的任何方法都儘可能少做事情。特別是，Activity應該在它的關鍵生命週期方法（如onCreate()和onResume()）裡儘可能少的去做建立操作。（可以採用重新開啟子執行緒的方式，然後使用Handler+Message的方式做一些操作，比如更新主執行緒中的ui等）

2、應用程式應該避免在BroadcastReceiver裡做耗時的操作或計算。但不再是在子執行緒裡做這些任務（因為 BroadcastReceiver的生命週期短），替代的是，如果響應Intent廣播需要執行一個耗時的動作的話，應用程式應該啟動一個 Service。（此處需要注意的是可以在廣播接受者中啟動Service，但是卻不可以在Service中啟動broadcasereciver,關於原因後續會有介紹，此處不是本文重點）

3、避免在Intent Receiver裡啟動一個Activity，因為它會建立一個新的畫面，並從當前使用者正在執行的程式上搶奪焦點。如果你的應用程式在響應Intent廣 播時需要向用戶展示什麼，你應該使用Notification Manager來實現。

總結：anr異常也是在程式中自己經常遇到的問題，主要的解決辦法自己最常用的就是不要在主執行緒中做耗時的操作，而應放在子執行緒中來實現，比如採用Handler+mesage的方式，或者是有時候需要做一些和網路相互互動的耗時操作就採用asyntask非同步任務的方式（它的底層其實Handler+mesage有所區別的是它是執行緒池）等，在主執行緒中更新UI。