一、問題及背景
應用間相互聯動、相互跳轉，是實現系統整體性、體驗一致性的重要手段，也是最簡單的一種方法。
當我們用最常用的方法去startActivity時，竟也會遇到失敗的情況。在真實業務中，就遇到了這樣一例異常：用戶點擊某個按鈕時，想要“簡簡單單”跳轉另一個應用，卻沒有任何反應。
經驗豐富的你，腦海中是否涌現出了各種猜想：是不是目標Activity甚至目標App不存在？是不是目標Activty沒有對外開放？是不是有權限的限制或者跳轉的action/uri錯了……
真實的原因被flag、launchMode、Intent等特性層層藏匿，可能超出你此時的思考。
本文將從源碼出發，探究前因后果，展開講講在startActivity()真正準備啟動一個Activity前，需要經過哪些“磨難”，怎樣有據可依地解決由棧問題導致的啟動異常。
1.1 業務中遇到的問題
業務中的場景是這樣的，存在A、B、C三個應用。
（1）從應用A-Activity1跳轉至應用B-Activity2；
（2）應用B-Activity2繼續跳轉到應用C-Activity3；
（3）C內某個按鈕，會再次跳轉B-Activity2，但點擊后沒有任何反應。如果不經過前面A到B的跳轉，C直接跳到B是可以的。
1.2 問題代碼
3個Activity的Androidmanifest配置如下，均可通過各自的action拉起，launchMode均為標準模式。
<!--應用A-->
<activity
android:name=".Activity1"
android:exported="true">
<intent-filter>
<action android:name="com.zkp.task.ACTION_TO_A_PAGE1" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
<!--應用B-->
<activity
android:name=".Activity2"
android:exported="true">
<intent-filter>
<action android:name="com.zkp.task.ACTION_TO_B_PAGE2" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
<!--應用C-->
<activity
android:name=".Activity3"
android:exported="true">
<intent-filter>
<action android:name="com.zkp.task.ACTION_TO_C_PAGE3" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
A-1到B-2的代碼，指定flag為
FLAG_ACTIVITY_NEW_TASK
private void jumpTo_B_Activity2_ByAction_NewTask() {
Intent intent = new Intent();
intent.setAction("com.zkp.task.ACTION_TO_B_PAGE2");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
}
B-2到C-3的代碼，未指定flag
private void jumpTo_C_Activity3_ByAction_NoTask() {
Intent intent = new Intent();
intent.setAction("com.zkp.task.ACTION_TO_C_PAGE3");
startActivity(intent);
}
C-3到B-2的代碼，與A-1到B-2的完全一致，指定flag為 FLAG_ACTIVITY_NEW_TASK
private void jumpTo_B_Activity2_ByAction_NewTask() {
Intent intent = new Intent();
intent.setAction("com.zkp.task.ACTION_TO_B_PAGE2");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
}
1.3 代碼初步分析
仔細查看問題代碼，在實現上非常簡單，有兩個特征：
（1）如果直接通過C-3跳B-2，沒有任何問題，但A-1已經跳過B-2后，C-3就失敗了。
（2）在A-1和C-3跳到B-2時，都設置了flag為FLAG_ACTIVITY_NEW_TASK。
依據經驗，我們推測與棧有關，嘗試將跳轉前棧的狀態打印出來，如下圖。
由于A-1跳到B-2時設置了FLAG_ACTIVITY_NEW_TASK，B-2跳到C-3時未設置，所以1在獨立棧中，2、3在另一個棧中。示意如下圖。
C-3跳轉B-2一般有3種可能的預期，如下圖：預想1，新建一個Task，在新Task中啟動一個B-2；預想2，復用已經存在的B-2；預想3，在已有Task中新建一個實例B-2。
但實際上3種預期都沒有實現，所有Activity的任何聲明周期都沒有變化，界面始終停留在C-3。
看一下FLAG_ACTIVITY_NEW_TASK的官方注釋和代碼注釋，如下圖：
重點關注這一段：
When using this flag, if a task is already running for the activity you are now starting, then a new activity will not be started; instead, the current task will simply be brought to the front of the screen with the state it was last in.
使用此flag時，如果你正在啟動的Activity已經在一個Task中運行，那么一個新Activity不會被啟動；相反，當前Task將簡單地顯示在界面的前面，并顯示其最后的狀態。
——顯然，官方文檔與代碼注釋的表述與我們的異常現象是一致的，目標Activity2已經在Task中存在，則不會被啟動；Task直接顯示在前面，并展示最后的狀態。由于目標Activty3就是來源Activity3，所以頁面沒有任何變化。
看起來官方還是很靠譜的，但實際效果真的能一直與官方描述一致嗎？我們通過幾個場景來看一下。
二、場景拓展與驗證
2.1 場景拓展
在筆者依據官方描述進行調整、復現的過程中，發現了幾個比較有意思的場景。
PS：上面業務的案例中，B-2和C-3在不同應用內，又在相同的Task內，但實際上是否是同一個應用，對結果的影響并不大。為了避免不同應用和不同Task造成閱讀混亂，同一個棧的跳轉，我們都在本應用內進行，故業務中的場景等價于下面的【場景0】
【場景0】把業務中B-2到C-3的應用間跳轉改為B-2到B-3的應用內跳轉
// B-2跳轉B-3
public static void jumpTo_B_3_ByAction_Null(Context context) {
Intent intent = new Intent();
intent.setAction("com.zkp.task.ACTION_TO_B_PAGE3");
context.startActivity(intent);
}
如下圖，A-1設置NEW_TASK跳轉B-2，再跳轉B-3，最終設置NEW_TASK想跳轉B-2。雖然跳C-3改為了跳B-3，但與之前問題的表現一致，沒有反應，停留在B-3。
有的讀者會指出這樣的問題：如果同一個應用內使用NEW_TASK跳轉，而不指定目標的taskAffinity屬性，實際是無法在新Task中啟動的。請大家忽略該問題，可以認為筆者的操作是已經加了taskAffinity的，這對最終結果并沒有影響。
【場景1】如果目標Task和來源Task不是同一個，情況是否會如官方文檔所說復用已有的Task并展示最近狀態？我們改為B-3啟動一個新Task的新Activity C-4，再通過C-4跳回B-2
// B-3跳轉C-4
public static void jumpTo_C_4_ByAction_New(Context context) {
Intent intent = new Intent("com.zkp.task.ACTION_TO_C_PAGE4");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
}
// C-4跳轉B-2
public static void jumpTo_B_2_ByAction_New(Context context) {
Intent intent = new Intent();
intent.setAction("com.zkp.task.ACTION_TO_B_PAGE2");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
}
如下圖，A-1設置NEW_TASK跳轉B-2，再跳轉B-3，再設置NEW_TASK跳轉C-4，最終設置NEW_TASK想跳轉B-2。
預想的結果是：不會跳到B-2，而是跳到它所在Task的頂層B-3。
實際的結果是：與預期一致，確實是跳到了B-3。
【場景2】把場景1稍做修改：C-4到B-2時，我們不通過action來跳，改為通過setClassName跳轉。
// C-4跳轉B-2
public static void jumpTo_B_2_ByPath_New(Context context) {
Intent intent = new Intent();
intent.setClassName("com.zkp.b", "com.zkp.b.Activity2"); // 直接設置classname,不通過action
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
}
如下圖，A-1設置NEW_TASK跳轉B-2，再跳轉B-3，再設置NEW_TASK跳轉C-4，最終設置NEW_TASK想跳轉B-2。
預想的結果是：與場景0一致，會跳到B-2所在Task的已有頂層B-3。
實際的結果是：在已有的Task2中，產生了一個新的B-2實例。
僅僅是改變了一下重新跳轉B-2的方式，效果就完全不一樣了！這與官方文檔中提到該flag與"singleTask" launchMode值產生的行為并不一致！
【場景3】把場景1再做修改：這次C-4不跳棧底的B-2，改為跳轉B-3，且還是通過action方式。
// C-4跳轉B-3
public static void jumpTo_B_3_ByAction_New(Context context) {
Intent intent = new Intent();
intent.setAction("com.zkp.task.ACTION_TO_B_PAGE3");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
}
如下圖，A-1設置NEW_TASK跳轉B-2，再跳轉B-3，再設置NEW_TASK跳轉C-4，最終設置NEW_TASK想跳轉B-3。
預想的結果是：與場景0一致，會跳到B-2所在Task的頂層B-3。
實際的結果是：在已有的Task2中，產生了一個新的B-3實例。
不是說好的，Activity已經存在時，展示其所在Task的最新狀態嗎？明明Task2中已經有了B-3，并沒有直接展示它，而是生成了新的B-3實例。
【場景4】既然Activity沒有被復用，那Task一定會被復用嗎？把場景3稍做修改，直接給B-3指定一個單獨的affinity。
<activity
android:name=".Activity3"
android:exported="true"
android:taskAffinity="b3.task"><!--指定了親和性標識-->
<intent-filter>
<action android:name="com.zkp.task.ACTION_TO_B_PAGE3" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
如下圖，A-1設置NEW_TASK跳轉B-2，再跳轉B-3，再設置NEW_TASK跳轉C-4，最終設置NEW_TASK想跳轉B-3。
——這次，連Task也不會再被復用了……Activity3在一個新的棧中被實例化了。
再回看官方的注釋，就會顯得非常不準確，甚至會讓開發者對該部分的認知產生嚴重錯誤！稍微改變過程中的某個毫無關聯的屬性（如跳轉目標、跳轉方式……），就會產生很大差異。
在看flag相關注釋時，我們要樹立一個意識：Task和Activity跳轉的實際效果，是launchMode、taskAffinity、跳轉方式、Activity在Task中的層級等屬性綜合作用的結果，不要相信“一面之詞”。
回到問題本身，究竟是哪些原因造就了上面的不同效果呢？只有源碼最值得信賴了。
三、場景分析與源碼探索
本文以Android 12.0源碼為基礎，進行探究。上述場景在不同Android版本上的表現是一致的。
3.1 源碼調試注意事項
源碼的調試方法，許多文章已經有了詳細的教學，本文不再贅述。此處只簡單總結其中需要注意的事項：
- 下載模擬器時，不要使用google Play版本，該版本類似user版本，無法選擇system_process進程進行斷點。
- 即使是Google官方模擬器和源碼，在斷點時，也會有行數嚴重不對應的情況（比如：模擬器實際會運行到方法A，但在源碼中打斷點時，實際不能定位到方法A的對應行數），該問題并沒有很好的處理方法，只能盡量規避，如使模擬器版本與源碼版本保持一致、多打一些斷點增加關鍵行數被定位到的幾率。
3.2 初步斷點，明確啟動結果
以【場景0】為例，我們初步確認一下，為什么B-3跳轉B-2會無反應，系統是否告知了原因。
3.2.1 明確啟動結果及其來源
在Android源碼的斷點調試中，常見的有兩類進程：應用進程和system_process進程。
在應用進程中，我們能獲取到應用啟動結果的狀態碼result，這個result用來告訴我們啟動是否成功。涉及堆棧如下圖（標記1）所示：
Activity類::startActivity()
→ startActivityForResult()
→ Instrumentation類::execStartActivity()，
返回值result則是ATMS
（ActivityTaskManagerService）執行的結果。
如上圖（標記2）標注，ATMS類::startActivity()方法，返回了result=3。
在system_process進程中，我們看一下這個result=3是怎樣被賦值的。略去詳細斷點步驟，實際堆棧如下圖（標注1）所示：
ATMS類::startActivity() → startActivityAsUser()
→ ActivityStarter類::execute()
→ executeRequest()
→ startActivityUnchecked()
→ startActivityInner()
→ recycleTask()，在recycleTask()中返回了結果。
如上圖（標注2）所示，result在mMovedToFrnotallow=false時被賦值，即result=START_DELIVERED_TO_TOP=3，而START_SUCCESS=0才代表創建成功。
看一下源碼中對START_DELIVERED_TO_TOP的說明，如下圖：
Result for IActivityManaqer.startActivity: activity wasn't really started, but the given Intent was given to the existing top activity.
（IActivityManaqer.startActivityActivity的結果：Activity并未真正啟動，但給定的Intent已提供給現有的頂層Activity。）
“Activity并未真正啟動”——是的，因為可以復用
“給定的Intent已提供給現有的頂層Activity”——實際沒有，頂層Activity3并沒有收到任何回調，onNewIntent()未執行，甚至嘗試通過Intent::putExtra()傳入新的參數，Activity3也沒有收到。官方文檔又帶給了我們一個疑問點？我們把這個問題記錄下來，在后面分析。
滿足什么條件，才會造成
START_DELIVERED_TO_TOP的結果呢？筆者的思路是，通過與正常啟動流程對比，找出差異點。
3.3 過程斷點，探索啟動流程
一般來說，在定位問題時，我們習慣通過結果反推原因，但反推的過程只能關注到與問題強關聯的代碼分支，并不能能使我們很好地了解全貌。
所以，本節內容我們通過順序閱讀的方法，正向介紹startActivity過程中與上述【場景01234】強相關的邏輯。再次簡述一下：
- 【場景0】同一個Task內，從頂部B-3跳轉B-2——停留在B-3
- 【場景1】從另一個Task內的C-4，跳轉B-2——跳轉到B-3
- 【場景2】把場景1中，C-4跳轉B-2的方式改為setClassName()——創建新B-2實例
- 【場景3】把場景1中，C-4跳轉B-2改為跳轉B-3——創建新B-3實例
- 【場景4】給場景3中的B-3，指定taskAffinity——創建新Task和新B-3實例
3.3.1 流程源碼概覽
源碼中，整個啟動流程很長，涉及的方法和邏輯也很多，為了便于大家理清方法調用順序，方便后續內容的閱讀，筆者將本文涉及到的關鍵類及方法調用關系整理如下。
后續閱讀中如果不清楚調用關系，可以返回這里查看：
// ActivityStarter.JAVA
ActivityStarter::execute() {
executeRequest(intent) {
startActivityUnchecked() {
startActivityInner();
}
}
ActivityStarter::startActivityInner() {
setInitialState();
computeLaunchingTaskFlags();
Task targetTask = getReusableTask(){
findTask();
}
ActivityRecord targetTaskTop = targetTask.getTopNonFinishingActivity();
if (targetTaskTop != null) {
startResult = recycleTask() {
setTargetRootTaskIfNeeded();
complyActivityFlags();
if (mAddingToTask) {
return START_SUCCESS; //【場景2】【場景3】從recycleTask()返回
}
resumeFocusedTasksTopActivities()
return mMovedToFront ? START_TASK_TO_FRONT : START_DELIVERED_TO_TOP;//【場景1】【場景0】從recycleTask()返回
}
} else {
mAddingToTask = true;
}
if (startResult != START_SUCCESS) {
return startResult;//【場景1】【場景0】從startActivityInner()返回
}
deliverToCurrentTopIfNeeded();
resumeFocusedTasksTopActivities();
return startResult;
}
3.3.2 關鍵流程分析
（1）初始化
startActivityInner()是最主要的方法，如下列幾張圖所示，該方法會率先調用setInitialState()，初始化各類全局變量，并調用reset()，重置ActivityStarter中各種狀態。
在此過程中，我們記下兩個關鍵變量mMovedToFront和mAddingToTask，它們均在此被重置為false。
其中，mMovedToFront代表當Task可復用時，是否需要將目標Task移動到前臺；mAddingToTask代表是否要將Activity加入到Task中。
（2）計算確認啟動時的flag
該步驟會通過computeLaunchingTaskFlags()方法，根據launchMode、來源Activity的屬性等進行初步計算，確認LaunchFlags。
此處重點處理來源Activity為空的各類場景，與我們上文中的幾種場景無關，故不再展開講解。
（3）獲取可以復用的Task
該步驟通過調用getReusableTask()實現，用來查找有沒有可以復用的Task。
先說結論：場景0123中，都能獲取到可以復用的Task，而場景4中，未獲取到可復用的Task。
為什么場景4不可以復用？我們看一下getReusableTask()的關鍵實現。
上圖（標注1）中，putIntoExistingTask代表是否能放入已經存在的Task。當flag含有NEW_TASK且不含MULTIPLE_TASK時，或指定了singleInstance或singleTask的launchMode等條件，且沒有指定Task或要求返回結果 時，場景01234均滿足了條件。
然后，上圖（標注2）通過findTask()查找可以復用的Task，并將過程中找到的棧頂Activity賦值給intentActivity。最終，上圖（標注3）將intentActivity對應的Task作為結果。
findTask()是怎樣查找哪個Task可以復用呢？
主要是確認兩種結果mIdealRecord——“理想的ActivityRecord” 和 mCandidateRecord——"候選的ActivityRecord"，作為intentActivity，并取intentActivity對應的Task作為復用Task。
什么ActivityRecord才是理想或候選的ActivityRecord呢？
在mTmpFindTaskResult.process()中確認。
程序會將當前系統中所有的Task進行遍歷，在每個Task中，進行如上圖所示的工作——將Task的底部Activity realActivity與目標Activity cls進行對比。
場景012中，我們想跳轉Activity2，即cls是Activity2，與Task底部的realActivity2相同，則將該Task頂部的Activity3 r作為“理想的Activity”；
場景3中，我們想跳轉Activity3，即cls是Activity3，與Task底部的realActivity2不同，則進一步判斷task底部Activity2與目標Activity3的棧親和行，具有相同親和性，則將Task的頂部Activity3作為“候選Activity”；
場景4中，所有條件都不滿足，最終沒能找到可復用的Task。在執行完getReusableTask()后將mAddingToTask賦值為true
由此，我們就能解釋【場景4】中，新建了Task的現象。
（4）確定是否需要將目標Task移動到前臺
如果存在可復用的Task，場景0123會執行recycleTask()，該方法中會相繼進行幾個操作：setTargetRootTaskIfNeeded()、
complyActivityFlags()。
首先，程序會執行
setTargetRootTaskIfNeeded()，用來確定是否需要將目標Task移動到前臺，使用mMovedToFront作為標識。
在【場景123】中，來源Task和目標Task是不同的，differentTopTask為true，再經過一系列Task屬性對比，能夠得出mMovedToFront為true；
而場景0中，來源Task和目標Task相同，differentTopTask為false，mMovedToFront保持初始的false。
由此，我們就能解釋【場景0】中，Task不會發生切換的現象。
（5）通過對比flag、Intent、Component等確認是否要將Activity加入到Task中
還是在【場景0123】中，recycleTask()會繼續執行complyActivityFlags()，用來確認是否要將Activity加入到Task中，使用mAddingToTask作為標識。
該方法會對FLAG_ACTIVITY_NEW_TASK、
FLAG_ACTIVITY_CLEAR_TASK、
FLAG_ACTIVITY_CLEAR_TOP等諸多flag、Intent信息進行一系列判斷。
上圖（標注1）中，會先判斷后續是否需要重置Task，resetTask，判斷條件則是FLAG_ACTIVITY_RESET_TASK_IF_NEEDED，顯然，場景0123的resetTask都為false。繼續執行。
接著，會有多種條件判斷按順序執行。
在【場景3】中，目標Component（mactivityComponent）是B-3，目標Task的realActivity則是B-2，兩者不相同，進入了resetTask相關的判斷（標注2）。
之前resetTask已經是false，故【場景3】的mAddingToTask脫離原始值，被置為true。
在【場景012】中，相對比的兩個Activity都是B-2（標注3），可以進入下一級判斷——isSameIntentFilter()。
這一步判斷的內容就很明顯了，目標Activity2的已有Intent 與 新的Intent做對比。很顯然，場景2中由于改為了setClassName跳轉，Intent自然不一樣了。
故【場景2】的mAddingToTask脫離原始值，被置為true。
總結看一下：
【場景123】的mMovedToFront最先被置為true，而【場景0】經歷重重考驗，保持初始值為false。
——這意味著當有可復用Task時，【場景0】不需要把Task切換到前列；【場景123】需要切換到目標Task。
【場景234】的mAddingToTask分別在不同階段被置為true，而【場景01】，始終保持初始值false。
——這意味著，【場景234】需要將Activity加入到Task中，而【場景01】不再需要。
（6）實際啟動Activity或直接返回結果
被啟動的各個Activity會通過resumeFocusedTasksTopActivities()等一系列操作，開始真正的啟動與生命周期的調用。
我們關于上述各個場景的探索已經得到答案，后續流程便不再關注。
四、問題修復及遺留問題解答
4.1 問題修復
既然前面總結了這么多必要條件，我們只需要破壞其中的某些條件，就可以修復業務中遇到的問題了，簡單列舉幾個的方案。
- 方案一：修改flag。B-3跳轉B-2時，增加FLAG_ACTIVITY_CLEAR_TASK或FLAG_ACTIVITY_CLEAR_TOP，或者直接不設置flag。經驗證可行。
- 方案二：修改intent屬性，即【場景2】。A-1通過action方式隱式跳轉B-2，則B-3可以通過setClassName方式，或修改action內屬性的方式跳轉B-2。經驗證可行。
- 方案三：提前移除B-2。B-2跳轉B-3時，finish掉B-2。需要注意的是，finish()要在startActivity()之前執行，以避免遺留的ActivityRecord和Intent信息對后續跳轉的影響。尤其是當你把B-2作為自己應用的deeplink分發Activity時，更值得警惕。
4.2 遺留問題
還記得我們在文章開端的某個疑惑嗎，為什么沒有回調onNewIntent()？
onNewIntent() 會通過deliverNewIntent()觸發，而deliverNewIntent()僅通過以下兩個方法調用。
complyActivityFlags()就是上文3.3.1.5中我們著重探討的方法，可以發現complyActivityFlags()中所有可能調用deliverNewIntent()的條件均被完美避開了。
而deliverToCurrentTopIfNeeded()方法則如下圖所示。
mLaunchFlags和mLaunchMode，無法滿足條件，導致dontStart為false，無緣
deliverNewIntent()。
至此，onNewIntent()的問題得到解答。
五、結語
通過一系列場景假設，我們發現了許多出乎意料的現象：
- 文檔提到FLAG_ACTIVITY_NEW_TASK等價于singleTask，與事實并不完全如此，只有與其他flag搭配才能達到相似的效果。這一flag的注釋非常片面，甚至會引發誤解，單一因素無法決定整體表現。
- 官方文檔提到
START_DELIVERED_TO_TOP會將新的Intent傳遞給頂層Activity，但事實上，并不是每一種START_DELIVERED_TO_TOP都會把新的Intent重新分發。 - 同一個棧底Activity，前后兩次都通過action或都通過setClassName跳轉到時，第二次跳轉竟然會失敗，而兩次用不同方式跳轉時，則會成功。
- 單純使用FLAG_ACTIVITY_NEW_TASK時，跳棧底Activity和跳同棧內其他Activity的效果大相徑庭。
業務中遇到的問題，歸根結底就是對Android棧機制不夠了解造成的。
在面對棧相關的編碼時，開發者務必要想清楚，承擔新開應用棧的Activty在應用全局承擔怎樣的使命，要對Task歷史、flag屬性、launchMode屬性、Intent內容等全面評估，謹慎參考官方文檔，才能避免棧陷阱，達成理想可靠的效果。
