技術文章 » 明修"棧"道——越過Android啟動棧陷阱

明修"棧"道——越過Android啟動棧陷阱

2023-04-18 12:01:21

作者：vivo 網際網路大前端團隊- Zhao Kaiping

本文從一例業務中遇到的問題出發，以FLAG_ACTIVITY_NEW_TASK這一flag作為切入點，帶大家探究Activity啟動前的一項重要的工作——棧校驗。

文中列舉一系列業務中可能遇到的異常狀況，詳細描述了使用FLAG_ACTIVITY_NEW_TASK時可能遇到的「坑」，並從原始碼中探究其根源。只有合理使用flag、launchMode，才能避免因為棧機制的特殊性，導致一系列與預期不符的啟動問題。

一、問題及背景

應用間相互聯動、相互跳轉，是實現系統整體性、體驗一致性的重要手段，也是最簡單的一種方法。

當我們用最常用的方法去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 原始碼偵錯注意事項

原始碼的偵錯方法，許多文章已經有了詳細的教學，本文不再贅述。此處只簡單總結其中需要注意的事項：

  1. 下載模擬器時，不要使用Google Play版本，該版本類似user版本，無法選擇system_process程序進行斷點。

  2. 即使是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在mMovedToFront=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】強相關的邏輯。再次簡述一下：

  1. 【場景0】同一個Task內，從頂部B-3跳轉B-2——停留在B-3

  2. 【場景1】從另一個Task內的C-4，跳轉B-2——跳轉到B-3

  3. 【場景2】把場景1中，C-4跳轉B-2的方式改為setClassName()——建立新B-2範例

  4. 【場景3】把場景1中，C-4跳轉B-2改為跳轉B-3——建立新B-3範例

  5. 【場景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()的問題得到解答。

五、結語

通過一系列場景假設，我們發現了許多出乎意料的現象：

  1. 檔案提到FLAG_ACTIVITY_NEW_TASK等價於singleTask，與事實並不完全如此，只有與其他flag搭配才能達到相似的效果。這一flag的註釋非常片面，甚至會引發誤解，單一因素無法決定整體表現。

  2. 官方檔案提到

  3. START_DELIVERED_TO_TOP會將新的Intent傳遞給頂層Activity，但事實上，並不是每一種START_DELIVERED_TO_TOP都會把新的Intent重新分發。

  4. 同一個棧底Activity，前後兩次都通過action或都通過setClassName跳轉到時，第二次跳轉竟然會失敗，而兩次用不同方式跳轉時，則會成功。

  5. 單純使用FLAG_ACTIVITY_NEW_TASK時，跳棧底Activity和跳同棧內其他Activity的效果大相徑庭。

業務中遇到的問題，歸根結底就是對Android棧機制不夠了解造成的。

在面對棧相關的編碼時，開發者務必要想清楚，承擔新開應用棧的Activty在應用全域性承擔怎樣的使命，要對Task歷史、flag屬性、launchMode屬性、Intent內容等全面評估，謹慎參考官方檔案，才能避免棧陷阱，達成理想可靠的效果。