[Android] Activity的Launch mode詳解

Activity有四種加載模式：standard(默認)， singleTop， singleTask和 singleInstance。如下逐一舉例說明他們的區別：

standard：Activity的默認加載方法，即便某個Activity在Task棧中已經存在，另外一個activity經過Intent跳 轉到該activity，一樣會新建立一個實例壓入棧中。例如：如今棧的狀況爲：A B C D，在D這個Activity中經過Intent跳轉到D，那麼如今的棧狀況爲： A B C D D 。此時若是棧頂的D經過Intent跳轉到B，則棧狀況爲：A B C D D B。此時若是依次按返回鍵，D  D C B A將會依次彈出棧而顯示在界面上。

singleTop：若是某個Activity的Launch mode設置成singleTop，那麼當該Activity位於棧頂的時候，再經過Intent跳轉到自己這個Activity，則將不會建立一個新的 實例壓入棧中。例如：如今棧的狀況爲：A B C D。D的Launch mode設置成了singleTop，那麼在D中啓動Intent跳轉到D，那麼將不會新建立一個D的實例壓入棧中，此時棧的狀況依然爲：A B C D。可是若是此時B的模式也是singleTop，D跳轉到B，那麼則會新建一個B的實例壓入棧中，由於此時B不是位於棧頂，此時棧的狀況就變成了：A B C D B。

singleTask：若是某個Activity是singleTask模式，那麼Task棧中將會只有一個該Activity的實例。例如：如今 棧的狀況爲：A B C D。B的Launch mode爲singleTask，此時D經過Intent跳轉到B，則棧的狀況變成了：A B。而C和D被彈出銷燬了，也就是說位於B之上的實例都被銷燬了。

關於singleTask這個網上很有爭議，包括google api上的說明也讓我看的是一頭霧水，本身用實例親測，終於算是搞清楚了

正解：1.singleTask 並不必定處於棧底

　　　2.singleTask 並必定會是棧底的根元素　

　　  3.singleTask 並不必定會啓動新的task　　

    　狀況一：若是在本程序中啓動singleTask的activity：假設ActivityA是程序的入口，是默認的模式（standard）,ActivityB是singleTask 模式，由ActivityA啓動，剛ActivityB不會位於棧底，不是根元素，不會啓動新的task，此種狀況ActivityB會和ActivityA在一個棧中，位於ActivityA上面

　　狀況二：若是ActivityB由另一個程序啓動：假設apkA是狀況一中的應用，apkB是測試程序，在apkB中啓動apkA中的ActivityB，剛ActivityB會位於棧底，是根元素，會啓動新的task

注意：singleTask模式的Activity不論是位於棧頂仍是棧底，再次運行這個Activity時，都會destory掉它上面的Activity來保證整個棧中只有一個本身，切記切記

singleInstance：將Activity壓入一個新建的任務棧中。例如：Task棧1的狀況爲：A B C。C經過Intent跳轉到D，而D的Launch mode爲singleInstance，則將會新建一個Task棧2。此時Task棧1的狀況仍是爲：A B C。Task棧2的狀況爲：D。此時屏幕界面顯示D的內容，若是這時D又經過Intent跳轉到D，則Task棧2中也不會新建一個D的實例，因此兩個棧 的狀況也不會變化。而若是D跳轉到C，則棧1的狀況變成了：A B C C，由於C的Launch mode爲standard，此時若是再按返回鍵，則棧1變成：A B C。也就是說如今界面還顯示C的內容，不是D。

好了，如今有一個問題就是這時這種狀況下若是用戶點擊了Home鍵，則再也回不到D的即時界面了。若是想解決這個問題，能夠爲D在Manifest.xml文件中的聲明加上：

<intent-filter>

       <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />

 </intent-filter>

加上這段以後，也就是說該程序中有兩個這種聲明，另外一個就是那個正常的根activity，在打成apk包安裝以後，在程序列表中能看到兩個圖標， 可是若是都運行的話，在任務管理器中其實也只有一個。上面的狀況點擊D的那個圖標就能回到它的即時界面（好比一個EditText，之前輸入的內容，如今 回到以後依然存在）。

PS：intent-filter中 <action android:name="android.intent.action.MAIN" />和 <category android:name="android.intent.category.LAUNCHER" />兩個過濾條件缺一不可纔會在程序列表中添加一個圖標，圖標下的顯示文字是android:label設定的字符串。

    Android管理task和back stack的默認行爲：activity 在同一個任務中建立並置於先進後出的棧中。若是這種默認的行爲不能知足咱們的app設計，如：爲一個activity建立一個新任務（而不是在相同的任務 中），或者啓動activity時直接打開已存在的實例（而不是直接在棧頂建立新實例），又或者在用戶離開這個task的時候清空除了棧頂之外的所有 activity。Android提供了一些屬性和flag讓coder來指定管理的方式。

在manifest <activity>標籤中的相關屬性：

launchMode

allowTaskReparenting

clearTaskOnLaunch

alwaysRetainTaskState

finishOnTaskLaunch

Intent 也有相關的flag：

FLAG_ACTIVITY_NEW_TASK

FLAG_ACTIVITY_CLEAR_TOP

FLAG_ACTIVITY_SINGLE_TOP

        android建議通常的app都不要干涉系統按照默認的方式管理activity和task。若是coder必須指定非默認的管理的方式，最好肯定這種效果能符合用戶的預期。

 

定義Launch Mode

對<activity> 的launchMode能夠指定如下值：

Use Cases	Launch Mode	Multiple Instances?	Comments
Normal launches for most activities	"standard"	Yes	默認行爲。每次啓動一個activity，系統都會在目標task新建一個實例。
Normal launches for most activities	"singleTop"	Conditionally	若是目標activity的實例已經存在於目標task的棧頂，系統會直接使用該實例，並調用該activity的onNewIntent()（不會從新create）
Specialized launches (not recommended for general use)	"singleTask"	No	在一個新任務的棧頂建立activity的實例。若是實例已經存在，系統會直接使用該實例，並調用該activity的onNewIntent()（不會從新create）
Specialized launches (not recommended for general use)	"singleInstance"	No	和"singleTask"相似，但在目標activity的task中不會再運行其餘的activity，在那個task中永遠只有一個activity。

 

SingleTask的例子：瀏覽器的browser activity設置了SingleTask只運行在它本身的task中，若是Browser的task如今正在後臺當中（task B），而咱們的app（task A）的正要打開這個activity，這個task就會被直接移到前臺接收咱們的intent。

返回鍵只會將界面返回到當前task的下一個activity，因此Task B回到前臺後，返回鍵會先做用在Task B中，直到最後一個activity被彈出，纔會回到咱們的Task A棧頂的activity。

注意：launchMode能被Intent 的flag覆蓋。

 

使用Intent 標誌

FLAG_ACTIVITY_NEW_TASK: 等同於 singleTask

FLAG_ACTIVITY_SINGLE_TOP: 等同singleTop

FLAG_ACTIVITY_CLEAR_TOP: 若是該activity已經運行在當前task中，intent指定啓動這個activity時，task中在它上面的activity都會被destroy，直到指定的activity位於棧頂，而後它的onNewIntent()被調用。

 

Affinity

affinity用於指定activity所屬的task。默認狀態下，一個app中的全部activity都有相同的affinity，因此它們會運行 在同一個task。而經過<activity>的taskAffinity屬性能夠指定affinity。

taskAffinity要用<manifest>中定義的惟一包名來取值，系統經過包名定位到app的默認task。

taskAffinity在如下2種狀況中發生做用：

• 使用FLAG_ACTIVITY_NEW_TASK啓動一個activity。若是該activity指定了taskAffinity，系統會將 activity實例置於指定的task中。 注意的是，此狀況下若是用戶點擊HOME鍵，必需要肯定有辦法能回到那個task中！（例如task所屬的app在launcher有本身icon）

• activity 設置了 allowTaskReparenting = 「true」。 當activity所在的task被移到前臺時，該activity會被移動到affinity指定的task中。

清理back stack

若是用戶離開一個task很長時間，系統會清理棧頂如下的activity，這樣task被重新打開時，棧頂activity就被還原了。coder一樣能夠經過<activity>屬性改變這種行爲：

alwaysRetatinTaskState: 若是當前棧頂的activity設置此屬性爲true，task中的全部activity都會被保留狀態。

clearTaskOnLaunch：若是當前棧頂的activity設置此屬性爲true，行爲則與alwaysRetatinTaskState相反，每次離開並從新該task，棧頂下的全部activity都會被清除，用戶返回task時永遠都是activity初始化的狀態。

finishOnTaskLaunch: 與clearTaskOnLaunch 類似，不過只做用於單個activity，不影響整個task。即便是棧頂的activity，也會生效。