Android程式員必須掌握的知識點-多進程和多線程

標籤：要求   roi   上傳   程式員   沒有   允許   何事   介紹   task   

當某個應用組件啟動且該應用沒有運行其他任何組件時，Android 系統會使用單個執行線程為應用啟動新的 Linux 進程。預設情況下，同一應用的所有組件在相同的進程和線程（稱為“主”線程）中運行。 如果某個應用組件啟動且該應用已存在進程（因為存在該應用的其他組件），則該組件會在此進程內啟動並使用相同的執行線程。 但是，您可以安排應用中的其他組件在單獨的進程中運行，並為任何進程建立額外的線程。

本文介紹進程和線程在 Android 應用中的工作方式。

進程
預設情況下，同一應用的所有組件均在相同的進程中運行，且大多數應用都不會改變這一點。 但是，如果您發現需要控制某個組件所屬的進程，則可在資訊清單檔中執行此操作。

各類組件元素的資訊清單檔條目—activity、service、receiver 和 provider—均支援 android:process 屬性，此屬性可以指定該組件應在哪個進程運行。您可以設定此屬性，使每個組件均在各自的進程中運行，或者使一些組件共用一個進程，而其他組件則不共用。 此外，您還可以設定 android:process，使不同應用的組件在相同的進程中運行，但前提是這些應用共用相同的 Linux 使用者識別碼 並使用相同的認證進行簽署。

此外，application 元素還支援 android:process 屬性，以設定適用於所有組件的預設值。

如果記憶體不足，而其他為使用者提供更緊急服務的進程又需要記憶體時，Android 可能會決定在某一時刻關閉某一進程。在被終止進程中啟動並執行應用組件也會隨之銷毀。 當這些組件需要再次運行時，系統將為它們重啟進程。

決定終止哪個進程時，Android 系統將權衡它們對使用者的相對重要程度。例如，相對於託管可見 Activity 的進程而言，它更有可能關閉託管螢幕上不再可見的 Activity 的進程。 因此，是否終止某個進程的決定取決於該進程中所運行組件的狀態。 下面，我們介紹決定終止進程所用的規則。

進程生命週期
Android 系統將盡量長時間地保持應用進程，但為了建立進程或運行更重要的進程，最終需要移除舊進程來回收記憶體。 為了確定保留或終止哪些進程，系統會根據進程中正在啟動並執行組件以及這些組件的狀態，將每個進程放入“重要性階層”中。 必要時，系統會首先消除重要性最低的進程，然後是重要性略遜的進程，依此類推，以回收系統資源。

重要性階層一共有 5 級。
以下列表按照重要程度列出了各類進程（第一個進程最重要，將是最後一個被終止的進程）：

前台進程
使用者當前操作所必需的進程。如果一個進程滿足以下任一條件，即視為前台進程： 託管使用者正在互動的 Activity（已調用 Activity 的 onResume() 方法） 託管某個 Service，後者綁定到使用者正在互動的 Activity 託管正在“前台”啟動並執行 Service（服務已調用 startForeground()） 託管正執行一個生命週期回調的 Service（onCreate()、onStart() 或 onDestroy()） 託管正執行其 onReceive() 方法的 BroadcastReceiver 通常，在任意給定時間前台進程都為數不多。只有在記憶體不足以支援它們同時繼續運行這一萬不得已的情況下，系統才會終止它們。 此時，裝置往往已達到記憶體分頁狀態，因此需要終止一些前台進程來確保使用者介面正常響應。

可見進程
沒有任何前台組件、但仍會影響使用者在螢幕上所見內容的進程。 如果一個進程滿足以下任一條件，即視為可見進程： 託管不在前台、但仍對使用者可見的 Activity（已調用其 onPause() 方法）。例如，如果前台 Activity 啟動了一個對話方塊，允許在其後顯示上一 Activity，則有可能會發生這種情況。 託管綁定到可見（或前台）Activity 的 Service。 可見進程被視為是極其重要的進程，除非為了維持所有前台進程同時運行而必須終止，否則系統不會終止這些進程。

服務進程
正在運行已使用 startService() 方法啟動的服務且不屬於上述兩個更高類別進程的進程。儘管服務進程與使用者所見內容沒有直接關聯，但是它們通常在執行一些使用者關心的操作（例如，在背景播放音樂或從網路下載資料）。因此，除非記憶體不足以維持所有前台進程和可見進程同時運行，否則系統會讓服務進程保持運行狀態。

後台進程
包含目前對使用者不可見的 Activity 的進程（已調用 Activity 的 onStop() 方法）。這些進程對使用者體驗沒有直接影響，系統可能隨時終止它們，以回收記憶體供前台進程、可見進程或服務進程使用。 通常會有很多後台進程在運行，因此它們會儲存在 LRU （最近最少使用）列表中，以確保包含使用者最近查看的 Activity 的進程最後一個被終止。如果某個 Activity 正確實現了生命週期方法，並儲存了其目前狀態，則終止其進程不會對使用者體驗產生明顯影響，因為當使用者導航回該 Activity 時，Activity 會恢複其所有可見狀態。 有關儲存和恢複狀態的資訊，請參閱 Activity文檔。

空進程
不含任何活動應用組件的進程。保留這種進程的的唯一目的是用作緩衝，以縮短下次在其中運行組件所需的啟動時間。 為使總體系統資源在進程緩衝和底層核心緩衝之間保持平衡，系統往往會終止這些進程。 根據進程中當前活動組件的重要程度，Android 會將進程評定為它可能達到的最進階別。例如，如果某進程託管著服務和可見 Activity，則會將此進程評定為可見進程，而不是服務進程。

此外，一個進程的層級可能會因其他進程對它的依賴而有所提高，即服務於另一進程的進程其層級永遠不會低於其所服務的進程。 例如，如果進程 A 中的內容提供者為進程 B 中的用戶端提供服務，或者如果進程 A 中的服務綁定到進程 B 中的組件，則進程 A 始終被視為至少與進程 B 同樣重要。

由於運行服務的進程其層級高於託管後台 Activity 的進程，因此啟動長時間運行操作的 Activity 最好為該操作啟動服務，而不是簡單地建立背景工作執行緒，當操作有可能比 Activity 更加持久時尤要如此。例如，正在將圖片上傳到網站的 Activity 應該啟動服務來執行上傳，這樣一來，即使使用者退出 Activity，仍可在後台繼續執行上傳操作。使用服務可以保證，無論 Activity 發生什麼情況，該操作至少具備“服務進程”優先順序。 同理，廣播接收器也應使用服務，而不是簡單地將耗時冗長的操作放入線程中。

線程
應用啟動時，系統會為應用建立一個名為“主線程”的執行線程。 此線程非常重要，因為它負責將事件指派給相應的使用者介面小組件，其中包括繪圖事件。 此外，它也是應用與 Android UI 工具包組件（來自 android.widget 和 android.view 軟體包的組件）進行互動的線程。因此，主線程有時也稱為 UI 線程。

系統不會為每個組件執行個體建立單獨的線程。運行於同一進程的所有組件均在 UI 線程中執行個體化，並且對每個組件的系統調用均由該線程進行指派。 因此，響應系統回調的方法（例如，報告使用者操作的 onKeyDown() 或生命週期回調方法）始終在進程的 UI 線程中運行。

例如，當使用者觸控螢幕幕上的按鈕時，應用的 UI 線程會將觸摸事件指派給小組件，而小組件反過來又設定其按下狀態，並將失效請求發布到事件隊列中。 UI 線程從隊列中取消該請求並通知小組件應該重繪自身。

在應用執行繁重的任務以響應使用者互動時，除非正確實現應用，否則這種單線程模式可能會導致效能低下。 具體地講，如果 UI 線程需要處理所有任務，則執行耗時很長的操作（例如，網路訪問或資料庫查詢）將會阻塞整個 UI。 一旦線程被阻塞，將無法指派任何事件，包括繪圖事件。 從使用者的角度來看，應用顯示為掛起。 更糟糕的是，如果 UI 線程被阻塞超過幾秒鐘時間（目前大約是 5 秒鐘），使用者就會看到一個讓人厭煩的“應用無響應”(ANR) 對話方塊。如果引起使用者不滿，他們可能就會決定退出並卸載此應用。

此外，Android UI 工具包並非安全執行緒工具包。因此，您不得通過背景工作執行緒操縱 UI，而只能通過 UI 線程操縱使用者介面。 因此，Android 的單線程模式必須遵守兩條規則：

不要阻塞 UI 線程
不要在 UI 線程之外訪問 Android UI 工具包

背景工作執行緒
根據上述單線程模式，要保證應用 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 線程之外訪問 Android UI 工具包 — 此樣本從背景工作執行緒（而不是 UI 線程）修改了 ImageView。 這可能導致出現不明確、不可預見的行為，但要跟蹤此行為困難而又費時。

為解決此問題，Android 提供了幾種途徑來從其他線程訪問 UI 線程。

以下列出了幾種有用的方法：
Activity.runOnUiThread(Runnable) View.post(Runnable) 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();
}
現在，上述實現屬於安全執行緒型：在單獨的線程中完成網路操作，而在 UI 線程中操縱 ImageView。

但是，隨著操作日趨複雜，這類代碼也會變得複雜且難以維護。 要通過背景工作執行緒處理更複雜的互動，可以考慮在背景工作執行緒中使用 Handler 處理來自 UI 線程的訊息。當然，最好的解決方案或許是擴充 AsyncTask 類，此類簡化了與 UI 進行互動所需執行的背景工作執行緒任務。

使用 AsyncTask
AsyncTask 允許對使用者介面執行非同步作業。 它會先阻塞背景工作執行緒中的操作，然後在 UI 線程中發布結果，而無需您親自處理線程和/或處理常式。

要使用它，必須建立 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 的工作方法，但要全面瞭解如何使用此類，您應閱讀 AsyncTask 參考文檔：

可以使用泛型指定參數類型、進度值和任務最終值 方法 doInBackground() 會在背景工作執行緒上自動執行 onPreExecute()、onPostExecute() 和 onProgressUpdate() 均在 UI 線程中調用 doInBackground() 返回的值將發送到 onPostExecute() 您可以隨時在 doInBackground() 中調用publishProgress()，以在 UI 線程中執行 onProgressUpdate() 您可以隨時取消任何線程中的任務 注意：使用背景工作執行緒時可能會遇到另一個問題，即：運行時配置變更（例如，使用者更改了螢幕方向）導致 Activity 意外重啟，這可能會銷毀背景工作執行緒。 要瞭解如何在這種重啟情況下堅持執行任務，以及如何在 Activity 被銷毀時正確地取消任務，請參閱書架樣本應用的原始碼。

安全執行緒方法
在某些情況下，您實現的方法可能會從多個線程調用，因此編寫這些方法時必須確保其滿足安全執行緒的要求。

這一點主要適用於可以遠程調用的方法，如綁定服務中的方法。如果對 IBinder 中所實現方法的調用源自運行 IBinder 的同一進程，則該方法在調用方的線程中執行。但是，如果調用源自其他進程，則該方法將在從線程池選擇的某個線程中執行（而不是在進程的 UI 線程中執行），線程池由系統在與 IBinder 相同的進程中維護。 例如，即使服務的 onBind() 方法將從服務進程的 UI 線程調用，在 onBind() 返回的對象中實現的方法（例如，實現 RPC 方法的子類）仍會從線程池中的線程調用。 由於一個服務可以有多個用戶端，因此可能會有多個池線程在同一時間使用同一 IBinder 方法。因此，IBinder 方法必須實現為安全執行緒方法。

同樣，內容提供者也可接收來自其他進程的資料請求。儘管 ContentResolver 和 ContentProvider 類隱藏了如何管理處理序間通訊的細節，但響應這些請求的 ContentProvider 方法（query()、insert()、delete()、update() 和 getType() 方法）將從內容提供者所在進程的線程池中調用，而不是從進程的 UI 線程調用。 由於這些方法可能會同時從任意數量的線程調用，因此它們也必須實現為安全執行緒方法。

處理序間通訊
Android 利用遠端程序呼叫 (RPC) 提供了一種處理序間通訊 (IPC) 機制，通過這種機制，由 Activity 或其他應用組件調用的方法將（在其他進程中）遠程執行，而所有結果將返回給調用方。 這就要求把方法調用及其資料分解至作業系統可以識別的程度，並將其從本地進程和地址空間傳輸至遠程進程和地址空間，然後在遠程進程中重新組裝並執行該調用。 然後，傳回值將沿相反方向傳輸回來。 Android 提供了執行這些 IPC 事務所需的全部代碼，因此您只需集中精力定義和實現 RPC 編程介面即可。

要執行 IPC，必須使用 bindService() 將應用綁定到服務上

Android程式員必須掌握的知識點-多進程和多線程