任務和返回棧

　　一個應用程式當中通常都會包含很多個Activity，每個Activity都應該設計成為一個具有特定的功能，並且可以讓使用者進行操作的元件。另外，Activity之間還應該是可以相互啟動的。比如，一個郵件應用中可能會包含一個用於展示郵件列表的Activity，而當用戶點選了其中某一封郵件的時候，就會開啟另外一個Activity來顯示該封郵件的具體內容。

　　除此之外，一個Activity甚至還可以去啟動其它應用程式當中的Activity。打個比方，如果你的應用希望去傳送一封郵件，你就可以定義一個具有”send”動作的Intent，並且傳入一些資料，如對方郵箱地址、郵件內容等。這樣，如果另外一個應用程式中的某個Activity宣告自己是可以響應這種Intent的，那麼這個Activity就會被開啟。在當前場景下，這個Intent是為了要傳送郵件的，所以說郵件應用程式當中的編寫郵件Activity就應該被開啟。當郵件傳送出去之後，仍然還是會回到你的應用程式當中，這讓使用者看起來好像剛才那個編寫郵件的Activity就是你的應用程式當中的一部分。所以說，即使有很多個Activity分別都是來自於不同應用程式的，Android系統仍然可以將它們無縫地結合到一起，之所以能實現這一點，就是因為這些Activity都是存在於一個相同的任務(Task)當中的。

　　任務是一個Activity的集合，它使用棧的方式來管理其中的Activity，這個棧又被稱為返回棧(back stack)，棧中Activity的順序就是按照它們被開啟的順序依次存放的。

　　手機的Home介面是大多數任務開始的地方，當用戶在Home介面上點選了一個應用的圖示時，這個應用的任務就會被轉移到前臺。如果這個應用目前並沒有任何一個任務的話(說明這個應用最近沒有被啟動過)，系統就會去建立一個新的任務，並且將該應用的主Activity放入到返回棧當中。

　　當一個Activity啟動了另外一個Activity的時候，新的Activity就會被放置到返回棧的棧頂並將獲得焦點。前一個Activity仍然保留在返回棧當中，但會處於停止狀態。當用戶按下Back鍵的時候，棧中最頂端的Activity會被移除掉，然後前一個Activity則會得重新回到最頂端的位置。返回棧中的Activity的順序永遠都不會發生改變，我們只能向棧頂新增Activity，或者將棧頂的Activity移除掉。因此，返回棧是一個典型的後進先出(last in, first out)的資料結構。下圖通過時間線的方式非常清晰地向我們展示了多個Activity在返回棧當中的狀態變化：

　　如果使用者一直地按Back鍵，這樣返回棧中的Activity會一個個地被移除，直到最終返回到主螢幕。當返回棧中所有的Activity都被移除掉的時候，對應的任務也就不存在了。

　　任務除了可以被轉移到前臺之外，當然也是可以被轉移到後臺的。當用戶開啟了一個新的任務，或者點選Home鍵回到主螢幕的時候，之前任務就會被轉移到後臺了。當任務處於後臺狀態的時候，返回棧中所有的Activity都會進入停止狀態，但這些Activity在棧中的順序都會原封不動地保留著，如下圖所示：

　　這個時候，使用者還可以將任意後臺的任務切換到前臺，這樣使用者應該就會看到之前離開這個任務時處於最頂端的那個Activity。舉個例子來說，當前任務A的棧中有三個Activity，現在使用者按下Home鍵，然後點選桌面上的圖示啟動了另外一個應用程式。當系統回到桌面的時候，其實任務A就已經進入後臺了，然後當另外一個應用程式啟動的時候，系統會為這個程式開啟一個新的任務(任務B)。當用戶使用完這個程式之後，再次按下Home鍵回到桌面，這個時候任務B也進入了後臺。然後使用者又重新打開了第一次使用的程式，這個時候任務A又會回到前臺，A任務棧中的三個Activity仍然會保留著剛才的順序，最頂端的Activity將重新變為執行狀態。之後使用者仍然可以通過Home鍵或者多工鍵來切換回任務B，或者啟動更多的任務，這就是Android中多工切換的例子。

由於返回棧中的Activity的順序永遠都不會發生改變，所以如果你的應用程式中允許有多個入口都可以啟動同一個Activity，那麼每次啟動的時候就都會建立該Activity的一個新的例項，而不是將下面的Activity的移動到棧頂。這樣的話就容易導致一個問題的產生，即同一個Activity有可能會被例項化很多次，如下圖所示：

　　但是呢，如果你不希望同一個Activity可以被多次例項化，那當然也是可以的，馬上我們就將開始討論如果實現這一功能，現在我們先把預設的任務和Activity的行為簡單概括一下：

• 當Activity A啟動Activity B時，Activity A進入停止狀態，但系統仍然會將它的所有相關資訊保留，比如滾動的位置，還有文字框輸入的內容等。如果使用者在Activity B中按下Back鍵，那麼Activity A將會重新回到執行狀態。

• 當用戶通過Home鍵離開一個任務時，該任務會進入後臺，並且返回棧中所有的Activity都會進入停止狀態。系統會將這些Activity的狀態進行保留，這樣當用戶下一次重新開啟這個應用程式時，就可以將後臺任務直接提取到前臺，並將之前最頂端的Activity進行恢復。

• 當用戶按下Back鍵時，當前最頂端的Activity會被從返回棧中移除掉，移除掉的Activity將被銷燬，然後前面一個Activity將處於棧頂位置並進入活動狀態。當一個Activity被銷燬了之後，系統不會再為它保留任何的狀態資訊。

• 每個Activity都可以被例項化很多次，即使是在不同的任務當中。

儲存Activity的狀態

當系統為了恢復記憶體而銷燬某項 Activity 時，Activity 物件也會被銷燬，因此係統在繼續 Activity 時根本無法讓其狀態保持完好，而是必須在使用者返回Activity時重建 Activity 物件。但使用者並不知道系統銷燬 Activity 後又對其進行了重建，因此他們很可能認為 Activity 狀態毫無變化。 在這種情況下，您可以實現另一個回撥方法對有關 Activity 狀態的資訊進行儲存，以確保有關 Activity 狀態的重要資訊得到保留：onSaveInstanceState()。

系統會先呼叫 onSaveInstanceState()，然後再使 Activity 變得易於銷燬。系統會向該方法傳遞一個 Bundle，您可以在其中使用 putString() 和 putInt() 等方法以名稱-值對形式儲存有關 Activity 狀態的資訊。然後，如果系統終止您的應用程序，並且當用戶返回您的 Activity，則系統會重建該 Activity，並將 Bundle 同時傳遞給 onCreate() 和 onRestoreInstanceState()。您可以使用上述任一方法從 Bundle 提取您儲存的狀態並恢復該 Activity 狀態。如果沒有狀態資訊需要恢復，則傳遞給您的 Bundle 是空值（如果是首次建立該 Activity，就會出現這種情況）。

在兩種情況下，Activity 重獲使用者焦點時可保持狀態完好：系統在銷燬 Activity 後重建 Activity，Activity 必須恢復之前儲存的狀態；系統停止 Activity 後繼續執行 Activity，並且 Activity 狀態保持完好。

注：無法保證系統會在銷燬您的 Activity 前呼叫 onSaveInstanceState()，因為存在不需要儲存狀態的情況（例如使用者使用“返回” 按鈕離開您的 Activity 時，因為使用者的行為是在顯式關閉 Activity）。 如果系統呼叫 onSaveInstanceState()，它會在呼叫 onStop() 之前，並且可能會在呼叫 onPause() 之前進行呼叫。

不過，即使您什麼都不做，也不實現 onSaveInstanceState()，Activity 類的 onSaveInstanceState() 預設實現也會恢復部分 Activity 狀態。具體地講，預設實現會為佈局中的每個 View 呼叫相應的 onSaveInstanceState() 方法，讓每個檢視都能提供有關自身的應儲存資訊。Android 框架中幾乎每個小工具都會根據需要實現此方法，以便在重建 Activity 時自動儲存和恢復對 UI 所做的任何可見更改。例如，EditText 小工具儲存使用者輸入的任何文字，CheckBox 小工具儲存複選框的選中或未選中狀態。您只需為想要儲存其狀態的每個小工具提供一個唯一的 ID（通過 android:id 屬性）。如果小工具沒有 ID，則系統無法儲存其狀態。

您還可以通過將android:saveEnabled 屬性設定為”false” 或通過呼叫setSaveEnabled() 方法顯式阻止佈局內的檢視儲存其狀態。您通常不應將該屬性禁用，但如果您想以不同方式恢復 Activity UI 的狀態，就可能需要這樣做。

注：由於無法保證系統會呼叫 onSaveInstanceState()，因此您只應利用它來記錄 Activity 的瞬態（UI 的狀態）—— 切勿使用它來儲存永續性資料，而應使用 onPause() 在使用者離開 Activity 後儲存永續性資料（例如應儲存到資料庫的資料）。

管理任務

Android系統管理任務和返回棧的方式，正如上面所描述的一樣，就是把所有啟動的Activity都放入到一個相同的任務當中，通過一個“後進先出”的棧來進行管理的。這種方式在絕大多數情況下都是沒問題的，開發者也無須去關心任務中的Activity到底是怎麼樣存放在返回棧當中的。但是呢，如果你想打破這種預設的行為，比如說當啟動一個新的Activity時，你希望它可以存在於一個獨立的任務當中，而不是現有的任務當中。或者說，當啟動一個Activity時，如果這個Activity已經存在於返回棧中了，你希望能把這個Activity直接移動到棧頂，而不是再建立一個它的例項。再或者，你希望可以將返回棧中除了最底層的那個Activity之外的其它所有Activity全部清除掉。這些功能甚至更多功能，都是可以通過在manifest檔案中設定元素的屬性，或者是在啟動Activity時配置Intent的flag來實現的。

在元素中，有以下幾個屬性是可以使用的：

taskAffinity

launchMode

allowTaskReparenting

clearTaskOnLaunch

alwaysRetainTaskState

finishOnTaskLaunch

而在Intent當中，有以下幾個flag是比較常用的：

FLAG_ACTIVITY_NEW_TASK

FLAG_ACTIVITY_CLEAR_TOP

FLAG_ACTIVITY_SINGLE_TOP

注意：大多數應用都不得中斷 Activity 和任務的預設行為： 如果確定您的 Activity 必須修改預設行為，當使用“返回”按鈕從其他 Activity 和任務導航回到該 Activity 時，請務必要謹慎並確保在啟動期間測試該 Activity 的可用性。請確保測試導航行為是否有可能與使用者的預期行為衝突。

定義啟動模式

啟動模式允許您定義 Activity 的新例項如何與當前任務關聯。 您可以通過兩種方法定義不同的啟動模式：

Intent標識優先順序高於在AndroidManifest中定義的啟動模式。

使用清單檔案

在清單檔案中宣告 Activity 時，您可以使用 元素的 launchMode 屬性指定 Activity 應該如何與任務關聯。

launchMode 屬性指定有關應如何將 Activity 啟動到任務中的指令。您可以分配給 launchMode 屬性的啟動模式共有四種：

• “standard”（預設模式）
  預設。系統在啟動 Activity 的任務中建立 Activity 的新例項並向其傳送 Intent。Activity 可以多次例項化，而每個例項均可屬於不同的任務，並且一個任務可以擁有多個例項。

• “singleTop”
  如果當前任務的頂部已存在 Activity 的一個例項，則系統會通過呼叫該例項的 onNewIntent() 方法向其傳送 Intent，而不是建立 Activity 的新例項。Activity 可以多次例項化，而每個例項均可屬於不同的任務，並且一個任務可以擁有多個例項（但前提是位於返回棧頂部的 Activity 並不是 Activity 的現有例項）。

  效果同Intent新增”FLAG_ACTIVITY_SINGLE_TOP”

  注：為某個 Activity 建立新例項時，使用者可以按“返回”按鈕返回到前一個 Activity。 但是，當 Activity 的現有例項處理新 Intent 時，則在新 Intent 到達 onNewIntent() 之前，使用者無法按“返回”按鈕返回到 Activity 的狀態。

• “singleTask”

  這種啟動模式表示，系統會建立一個新的任務，並將啟動的Activity放入這個新任務的棧底位置。但是，如果現有任務當中已經存在一個該Activity的例項了，那麼系統就不會再建立一次它的例項，而是會直接呼叫它的onNewIntent()方法。宣告成這種啟動模式的Activity，在同一個任務當中只會存在一個例項。注意這裡我們所說的啟動Activity，都指的是啟動其它應用程式中的Activity，因為”singleTask”模式在預設情況下只有啟動其它程式的Activity才會建立一個新的任務，啟動自己程式中的Activity還是會使用相同的任務，具體原因會在下面 處理affinity 部分進行解釋。

  效果同Intent新增“FLAG_ACTIVITY_NEW_TASK”。

  注：儘管 Activity 在新任務中啟動，但是使用者按“返回”按鈕仍會返回到前一個 Activity。

• “singleInstance”
  這種啟動模式和”singleTask”有點相似，只不過系統不會向宣告成”singleInstance”的Activity所在的任務當中再新增其它Activity。也就是說，這種Activity所在的任務中始終只會有一個Activity，通過這個Activity再開啟的其它Activity均在單獨的任務中開啟。

再舉一個例子，Android系統內建的瀏覽器程式宣告自己瀏覽網頁的Activity始終應該在一個獨立的任務當中開啟，也就是通過在元素中設定”singleTask”啟動模式來實現的。這意味著，當你的程式準備去開啟Android內建瀏覽器的時候，新開啟的Activity並不會放入到你當前的任務中，而是會啟動一個新的任務。而如果瀏覽器程式在後臺已經存在一個任務了，則會把這個任務切換到前臺。

其實不管是Activity在一個新任務當中啟動，還是在當前任務中啟動，返回鍵永遠都會把我們帶回到之前的一個Activity中的。但是有一種情況是比較特殊的，就是如果Activity指定了啟動模式是”singleTask”，並且啟動的是另外一個應用程式中的Activity，這個時候當發現該Activity正好處於一個後臺任務當中的話，就會直接將這整個後臺任務一起切換到前臺。此時按下返回鍵會優先將目前最前臺的任務(剛剛從後臺切換到最前臺)進行回退，下圖比較形象地展示了這種情況：

使用 Intent 標誌

啟動 Activity 時，您可以通過在傳遞給 startActivity() 的 Intent 中加入相應的標誌，修改 Activity 與其任務的預設關聯方式。可用於修改預設行為的標誌包括：

• FLAG_ACTIVITY_NEW_TASK
  在新任務中啟動 Activity。如果已為正在啟動的 Activity 執行任務，則該任務會轉到前臺並恢復其最後狀態，同時 Activity 會在 onNewIntent() 中收到新 Intent。(與”singleTask”有點類似，但不完全一樣)。

  當然這裡討論的仍然還是啟動其它程式中的Activity。這個flag的作用通常是模擬一種Launcher的行為，即列出一推可以啟動的東西，但啟動的每一個Activity都是在執行在自己獨立的任務當中的。

  等同於launchMode設定為 “singleTask”

• FLAG_ACTIVITY_SINGLE_TOP
  如果正在啟動的 Activity 是當前 Activity（位於返回棧的頂部），則 現有例項會接收對 onNewIntent() 的呼叫，而不是建立 Activity 的新例項。

  等同於launchMode設定為 “singleTop”

• FLAG_ACTIVITY_CLEAR_TOP

  如果正在啟動的 Activity 已在當前任務中執行，則會銷燬當前任務頂部的所有 Activity，並通過 onNewIntent() 將此 Intent 傳遞給 Activity 已恢復的例項（現在位於頂部），而不是啟動該 Activity 的新例項。

  單獨使用的情況：ABCD 啟動 B ，會銷燬B和B以上的例項 變成 AB ，B 重新執行onCreate -> onStart
  配合FLAG_ACTIVITY_SINGLE_TOP使用，則 B 不會銷燬只銷毀B以上例項，然後B 執行onNewIntent -> onStart
  配合FLAG_ACTIVITY_NEW_TASK則是singleTask效果

處理affinity

　　affinity可以用於指定一個Activity更加願意依附於哪一個任務，在預設情況下，同一個應用程式中的所有Activity都具有相同的affinity，所以，這些Activity都更加傾向於執行在相同的任務當中。當然了，你也可以去改變每個Activity的affinity值，通過元素的taskAffinity屬性就可以實現了。

　　taskAffinity屬性接收一個字串引數，你可以指定成任意的值(經過測試字串中至少要包含一個.)，但必須不能和應用程式的包名相同，因為系統會使用包名來作為預設的affinity值。

affinity主要有以下兩種應用場景：

• 當呼叫startActivity()方法來啟動一個Activity時，預設是將它放入到當前的任務當中。但是，如果在Intent中加入了一個FLAG_ACTIVITY_NEW_TASK flag的話(或者該Activity在manifest檔案中宣告的啟動模式是”singleTask”)，系統就會嘗試為這個Activity單獨建立一個任務。但是規則並不是只有這麼簡單，系統會去檢測要啟動的這個Activity的affinity和當前任務的affinity是否相同，如果相同的話就會把它放入到現有任務當中，如果不同則會去建立一個新的任務。而同一個程式中所有Activity的affinity預設都是相同的，這也是前面為什麼說，同一個應用程式中即使宣告成”singleTask”，也不會為這個Activity再去建立一個新的任務了。

• 當把Activity的allowTaskReparenting屬性設定成true時，Activity就擁有了一個轉移所在任務的能力。具體點來說，就是一個Activity現在是處於某個任務當中的，但是它與另外一個任務具有相同的affinity值，那麼當另外這個任務切換到前臺的時候，該Activity就可以轉移到現在的這個任務當中。

  那還是舉一個形象點的例子吧，比如有一個天氣預報程式，它有一個Activity是專門用於顯示天氣資訊的，這個Activity和該天氣預報程式的所有其它Activity具體相同的affinity值，並且還將allowTaskReparenting屬性設定成true了。這個時候，你自己的應用程式通過Intent去啟動了這個用於顯示天氣資訊的Activity，那麼此時這個Activity應該是和你的應用程式是在同一個任務當中的。但是當把天氣預報程式切換到前臺的時候，這個Activity又會被轉移到天氣預報程式的任務當中，並顯示出來，因為它們擁有相同的affinity值，並且將allowTaskReparenting屬性設定成了true。

在掘金上找到一篇很好的Activity四種啟動模式的例項講解，建議看一下：徹底弄懂Activity四大啟動模式

清空返回棧

如果使用者將任務切換到後臺之後過了很長一段時間，系統會將這個任務中除了最底層的那個Activity之外的其它所有Activity全部清除掉。當用戶重新回到這個任務的時候，最底層的那個Activity將得到恢復。這個是系統預設的行為，因為既然過了這麼長的一段時間，使用者很有可能早就忘記了當時正在做什麼，那麼重新回到這個任務的時候，基本上應該是要去做點新的事情了。

當然，既然說是預設的行為，那就說明我們肯定是有辦法來改變的，在元素中設定以下幾種屬性就可以改變系統這一預設行為：

• alwaysRetainTaskState
  如果將最底層的那個Activity的這個屬性設定為true，那麼上面所描述的預設行為就將不會發生，任務中所有的Activity即使過了很長一段時間之後仍然會被繼續保留。

• clearTaskOnLaunch
  如果將最底層的那個Activity的這個屬性設定為true，那麼只要使用者離開了當前任務，再次返回的時候就會將最底層Activity之上的所有其它Activity全部清除掉。簡單來講，就是一種和alwaysRetainTaskState完全相反的工作模式，它保證每次返回任務的時候都會是一種初始化狀態，即使使用者僅僅離開了很短的一段時間。

• finishOnTaskLaunch
  這個屬性和clearTaskOnLaunch是比較類似的，不過它不是作用於整個任務上的，而是作用於單個Activity上。如果某個Activity將這個屬性設定成true，那麼使用者一旦離開了當前任務，再次返回時這個Activity就會被清除掉。

部分內容轉發自：http://blog.csdn.net/guolin_blog/article/details/41087993

--------------------- 本文來自 Shen_JC 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/siobhan/article/details/51480368?utm_source=copy