問題

自Android Ice Cream Sandwich發布后， 這個問題就開始在StackOverflow彌散開來：

我的應用在Android2.x上運行良好，但是在3.x 和4.x系統上總是強退，是什么導致的？

這是一個很棒的問題，畢竟開發者總是希望基于舊版本系統開發的應用在新版本的Android系統仍能兼容。在我看來，問題的原因可能多種多樣。 但大多數時候，原因非常簡單：你把一個可能非常耗時的操作放進了UI線程。

什么是UI線程？

應用的主UI線程的概念及其重要性是每個Android開發者都應理解。當一個應用啟動，系統會為應用創建一個名為“main”的主線程。這個主線程（也就是UI主線程）主要負責把事件分發給合適的view或者widget， 因此它非常重要。它也是你的應用和應用的UI交互的線程。例如，如果你點擊了屏幕上的一個按鈕，UI線程會把點擊時間交給view處理，view接到事件后會設置它的pressed狀態，然后向事件隊列中發送一個invalidate請求。 UI線程會依次讀取隊列并且告訴view去重繪自己。

除非你的Android應用實現的非常合理，否則這個單線程模型會使性能變得極低。在極端情況下，如果UI線程負責整個應用中的所有操作，進行耗時的操作比如發送網絡請求，或者數據庫查詢等都會導致用戶界面的阻塞。這些操作在未完成之前，所有的時間包括繪制和觸屏事件都不會被派發。從用戶的角度來看，程序似乎是卡死了。

在這些情況下，即時的反饋相當重要。研究表明0.1s是用戶感覺系統是否流暢的臨界值。任何比臨界值更慢的都被認為延遲（Miller 1968; Card et al. 1991）。雖然1秒看起來沒什么影響，但在GooglePlay中，即便是十分之一秒也可能是好評和差評的區別。更糟糕的是，如果UI線程被阻塞5秒以上，用戶會收到“程序未響應”（ANR）的提示對話框，并且會強制退出。

為什么Android會使應用崩潰

應用在2.x系統運行良好，在3.0及以上平臺上崩潰的主要原因在于，3.0以上平臺在處理UI線程資源濫用上更加嚴格。比如說，3.0平臺檢測到UI線程中有網絡請求時，會拋出NetworkOnMainThreadExceptionwill的異常：

E/AndroidRuntime(673): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example/com.example.ExampleActivity}: android.os.NetworkOnMainThreadException

Android developer網站文檔中也對此進行了很好的解釋：

當應用試圖在主線程中進行網絡操作，NetworkOnMainThreadException會被拋出。只有在運行Honeycomb SDK及更高的版本中會被拋出。更早版本的SDK允許在主事件循環線程中進行網絡操作，但是非常非常不鼓勵這么做。

列出一些ICS和Honeycomb不允許在UI線程中進行的操作：

打開套接字連接 (i.e. new Socket()).

HTTP 請求 (i.e. HTTPClient and HTTPUrlConnection).

試圖連接遠程的 MYSQL 數據庫.

下載文件 (i.e.Downloader.downloadFile()).

如果你要在UI線程中進行某些操作，一定要把它們打包到一個工作線程中。其中最簡單的方式是使用AsyncTask， 它允許你在你的用戶界面中進行一些異步的操作。AsyncTask會把阻塞操作放到工作線程中，并把結果返回到UI線程，而你不需要處理任何與線程相關的工作。

結論

我決定寫這篇主題的念頭來源于我在StackOerflow和其它論壇上無數次看到了這個問題。問題的主要來源是在UI線程進行了耗時的操作。為了確保用戶界面保持流暢，有必要把執行套接字連接、HTTP請求、文件下載和其他的耗時操作放到一個單獨的線程中。最簡單的方法就是把操作打包到AsyncTask中，它會幫助你啟動新的線程并讓他們與你的用戶界面異步交互。

有幫助的鏈接

這些資料可能會幫助你熟悉AsyncTask

AsyncTask documentation

Multithreading For Performance