以下內容爲Android文檔中文翻譯:
進程
默認情況下,同一個應用程序內的所有組件都是運行在同一個進程中的,大部分應用程序也不會去改變它。不過,如果需要指定某個特定組件所屬的進程,則可以利用manifest 文件來達到目的。
manifest文件中的每種組件元素——、 、 和——都支持定義android:process屬性,用於指定組件運行的進程。設置此屬性即可實現每個組件在各自的進程中運行,或者某幾個組件共享一個進程而其它組件運行於獨立的進程。設置此屬性也可以讓不同應用程序的組件運行在同一個進程中——實現多個應用程序共享同一個Linux用戶ID、賦予同樣的權限。
元素也支持android:process屬性,用於指定所有組件的默認進程。
如果內存不足,可又有其它爲用戶提供更緊急服務的進程需要更多內存,Android可能會決定關閉一個進程。在此進程中運行着的應用程序組件也會因此被銷燬。當需要再次工作時,會爲這些組件重新創建一個進程。
在決定關閉哪個進程的時候,Android系統會權衡它們相對用戶的重要程度。比如,相對於一個擁有可見activity的進程,更有可能去關閉一個activity已經在屏幕上看不見的進程。也就是說,是否終止一個進程,取決於運行在此進程中組件的狀態。終止進程的判定規則將在後續內容中討論。
進程的生命週期
Android系統試圖儘可能長時間地保持應用程序進程,但爲了新建或者運行更加重要的進程,總是需要清除過時進程來回收內存。爲了決定保留或終止哪個進程,根據進程內運行的組件及這些組件的狀態,系統把每個進程都劃入一個“重要性層次結構”中。重要性最低的進程首先會被清除,然後是下一個最低的,依此類推,這都是恢復系統資源所必需的。
重要性層次結構共有5級,以下列表按照重要程度列出了各類進程(第一類進程是最重要的,將最後一個被終止):
1. 前臺進程
用戶當前操作所必須的進程。滿足以下任一條件時,進程被視作處於前臺:
其中運行着正與用戶交互的Activity(Activity對象的onResume()]方法已被調用)。
其中運行着被正與用戶交互的activity綁定的服務。
其中運行着“前臺”服務——服務以[startForeground()方式被調用。
其中運行着正在執行生命週期回調方法(onCreate()、onStart()或onDestroy())的服務。
其中運行着正在執行onReceive()方法的BroadcastReceiver。
一般而言,任何時刻前臺進程都是爲數不多的,只有迫不得已——當內存不足以維持它們同時運行時——纔會被終止。通常,設備這時候已經到了使用虛擬內存的地步,終止一些前臺進程是爲了保證用戶界面的及時響應。
2. 可見進程
沒有前臺組件、但仍會影響用戶在屏幕上所見內容的進程。滿足以下任一條件時,進程被認爲是可見的:
其中運行着不在前臺的Activity,但用戶仍然可見到此activity(onPause()方法被調用了)。比如以下場合就可能發生這種情況:前臺activity打開了一個對話框,而之前的activity還允許顯示在後面。
其中運行着被可見(或前臺)activity綁定的服務。
可見進程被認爲是非常重要的進程,除非無法維持所有前臺進程同時運行了,它們是不會被終止的。
3. 服務進程
此進程運行着由startService()方法啓動的服務,它不會升級爲上述兩級別。儘管服務進程不直接和用戶所見內容關聯,但他們通常在執行一些用戶關心的操作(比如在後臺播放音樂或從網絡下載數據)。因此,除非內存不足以維持所有前臺、可見進程同時運行,系統會保持服務進程的運行。
4. 後臺進程
包含目前用戶不可見activity(Activity對象的onStop()方法已被調用)的進程。這些進程對用戶體驗沒有直接的影響,系統可能在任意時間終止它們,以回收內存供前臺進程、可見進程及服務進程使用。通常會有很多後臺進程在運行,所以它們被保存在一個LRU(最近最少使用)列表中,以確保最近被用戶使用的activity最後一個被終止。如果一個activity正確實現了生命週期方法,並保存了當前的狀態,則終止此類進程不會對用戶體驗產生可見的影響。因爲在用戶返回時,activity會恢復所有可見的狀態。關於保存和恢復狀態的詳細信息,請參閱Activity文檔。
5. 空進程
不含任何活動應用程序組件的進程。保留這種進程的唯一目的就是用作緩存,以改善下次在此進程中運行組件的啓動時間。爲了在進程緩存和內核緩存間平衡系統整體資源,系統經常會終止這種進程。
依據進程中目前活躍組件的重要程度,Android會給進程評估一個儘可能高的級別。例如:如果一個進程中運行着一個服務和一個用戶可見的activity,則此進程會被評定爲可見進程,而不是服務進程。
此外,一個進程的級別可能會由於其它進程的依賴而被提高——爲其它進程提供服務的進程級別永遠不會低於使用此服務的進程。比如:如果A進程中的content provider爲進程B中的客戶端提供服務,或進程A中的服務被進程B中的組件所調用,則A進程至少被視爲與進程B同樣重要。
因爲運行服務的進程級別是高於後臺activity進程的,所以,如果activity需要啓動一個長時間運行的操作,則爲其啓動一個服務會比簡單地創建一個工作線程更好些——尤其是該操作時間比activity的生存期還要長的情況下。比如,一個activity要把圖片上傳至Web網站,就應該創建一個服務來執行之,即使用戶離開了此activity,上傳還是會在後臺繼續運行。不論activity發生什麼情況,使用服務可以保證操作至少擁有“服務進程”的優先級。同理,廣播接收器broadcast receiver也是使用服務來處理耗時任務的,而不是簡單地把它放入線程中。
線程
應用程序啓動時,系統會爲它創建一個名爲“main”的主線程。主線程非常重要,因爲它負責把事件分發給相應的用戶界面widget——包括屏幕繪圖事件。它也是應用程序與Android UI組件包(來自android.widget和android.view包)進行交互的線程。因此,主線程有時也被叫做UI線程。
系統並不會爲每個組件的實例都創建單獨的線程。運行於同一個進程中的所有組件都是在UI線程中實例化的,對每個組件的系統調用也都是由UI線程分發的。因此,對系統回調進行響應的方法(比如報告用戶操作的onKeyDown()或生命週期回調方法)總是運行在UI線程中。
舉個例子,當用戶觸摸屏幕上的按鈕時,應用程序的UI線程把觸摸事件分發給widget,widget先把自己置爲按下狀態,再發送一個顯示區域已失效(invalidate)的請求到事件隊列中。UI線程從隊列中取出此請求,並通知widget重繪自己。
如果應用程序在與用戶交互的同時需要執行繁重的任務,單線程模式可能會導致運行性能很低下,除非你的應用程序設計得很精妙。尤其是UI線程要處理所有任務時,那些耗時很長的操作——諸如訪問網絡或查詢數據庫等——將會阻塞整個UI(線程)。一旦線程被阻塞,所有事件都不能被分發,包括屏幕繪圖事件。從用戶的角度看來,應用程序看上去像是掛起了。更糟糕的是,如果UI線程被阻塞超過一定時間(目前大約是5秒鐘),用戶就會被提示那個可惡的“應用程序沒有響應”(ANR)對話框。如果引起用戶不滿,他可能就會退出並刪除這個應用程序。
此外,Andoid的UI組件包並不是線程安全的。因此不允許從工作線程中操作UI——只能從UI線程中操作用戶界面。於是,Andoid的單線程模式必須遵守兩個規則:
不要阻塞UI線程。
不要在UI線程之外訪問Andoid的UI組件包。
工作線程
根據以上對單線程模式的描述,要想保證程序界面的響應能力,關鍵是不能阻塞UI線程。如果操作不能很快完成,應該讓它們在單獨的線程中運行(“後臺”或“工作”線程)。
例如:以下響應鼠標點擊的代碼實現了在單獨線程中下載圖片並在ImageView顯示:
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
Bitmap b = loadImageFromNetwork("http://example.com/image.png");
mImageView.setImageBitmap(b);
}
}).start();
}
乍看起來,這段代碼似乎能運行得很好,因爲創建了一個新的線程來處理訪問網絡的操作。可是它違反了單線程模式的第二條規則:不要在UI線程之外訪問Andoid的UI組件包——以上例子在工作線程裏而不是UI線程裏修改了ImageView。這可能導致不明確、不可預見的後果,要跟蹤這種情況也是很困難很耗時間的。
爲了解決以上問題,Android提供了幾種途徑來從其它線程中訪問UI線程。下面列出了有助於解決問題的幾種方法:
- Activity.runOnUiThread(Runnable)
- View.post(Runnable)
- long) View.postDelayed(Runnable, long)
比如說,可以使用View.post(Runnable)方法來修正上面的代碼:
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
final Bitmap bitmap = loadImageFromNetwork("http://example.com/image.png");
mImageView.post(new Runnable() {
public void run() {
mImageView.setImageBitmap(bitmap);
}
});
}
}).start();
}
以上代碼的執行現在是線程安全的了:網絡相關的操作在單獨的線程裏完成,而ImageView是在UI線程裏操縱的。
不過,隨着操作變得越來越複雜,這類代碼也會變得很複雜很難維護。爲了用工作線程完成更加複雜的交互處理,可以考慮在工作線程中用Handler來處理UI線程分發過來的消息。當然,最好的解決方案也許就是繼承使用異步任務類AsyncTask,此類簡化了一些工作線程和UI交互的操作。
使用異步任務
異步任務AsyncTask 允許以異步的方式對用戶界面進行操作。它先阻塞工作線程,再在UI線程中呈現結果,在此過程中不需要對線程和handler進行人工干預。
要使用異步任務,必須繼承AsyncTask類並實現doInBackground()回調方法,該對象將運行於一個後臺線程池中。要更新UI時,須實現onPostExecute()方法來分發doInBackground()返回的結果,由於此方法運行在UI線程中,所以就能安全地更新UI了。然後就可以在UI線程中調用execute()來執行任務了。
例如,可以利用AsyncTask來實現上面的那個例子:
public void onClick(View v) {
new DownloadImageTask().execute("http://example.com/image.png");
}
private class DownloadImageTask extends AsyncTask<String, Void, Bitmap> {
/** The system calls this to perform work in a worker thread and
* delivers it the parameters given to AsyncTask.execute() */
protected Bitmap doInBackground(String... urls) {
return loadImageFromNetwork(urls[0]);
}
/** The system calls this to perform work in the UI thread and delivers
* the result from doInBackground() */
protected void onPostExecute(Bitmap result) {
mImageView.setImageBitmap(result);
}
}
現在UI是安全的,代碼也得到簡化,因爲任務分解成了工作線程內完成的部分和UI線程內完成的部分。
要全面理解這個類的使用,須閱讀AsyncTask的參考文檔。以下是關於其工作方式的概述:
- 可以用generics來指定參數、進度值和任務最終值的類型。
- 工作線程中的doInBackground()方法會自動執行。
- onPreExecute()、onPostExecute()和onProgressUpdate()方法都在UI線程中調用。
- doInBackground()的返回值會傳給onPostExecute()。
- 在doInBackground()內的任何時刻,都可以調用publishProgress()來執行UI線程中的onProgressUpdate()。
- 可以在任何時刻、任何線程內取消任務。
注意:在使用工作線程時,可能遇到的另一個問題是由於運行時配置的改變(比如用戶改變了屏幕方向)導致activity意外重啓,這可能會銷燬該工作線程。要了解如何在這種情況下維持任務執行、以及如何在activity被銷燬時正確地取消任務,請參見Shelves例程的源代碼。
線程安全的方法
在某些場合,方法可能會從不止一個線程中被調用,因此這些方法必須是寫成線程安全的。
對於能被遠程調用的方法——比如bound服務中的方法,這是理所當然的。如果對IBinder所實現方法的調用發起於IBinder所在進程的內部,那麼這個方法是執行在調用者的線程中的。但是,如果調用發起於其他進程,那麼這個方法將運行於線程池中選出的某個線程中(而不是運行於進程的UI線程中),該線程池由系統維護且位於IBinder所在的進程中。例如,即使一個服務的onBind()方法是從服務所在進程的UI線程中調用的,onBind()所返回對象中的方法(比如,執行了RPC方法的一個子類)仍會從線程池中的線程被調用。因爲一個服務可以有不止一個客戶端,所以同時可以有多個線程池與同一個IBinder方法相關聯。因此IBinder方法必須實現爲線程安全的。
類似地,內容提供者(content provider)也能接收來自其它進程的數據請求。儘管ContentResolver類、ContentProvider類隱藏了進程間通訊管理的細節,ContentProvider中響應請求的方法——query()、insert()、delete()、update()和getType()方法——是從ContentProvider所在進程的線程池中調用的,而不是進程的UI線程。因爲這些方法可能會從很多線程同時調用,它們也必須實現爲線程安全的。
本文內容參見:http://www.android-doc.com/guide/components/processes-and-threads.html