接手過一個老項目測試提了一個非常經典的bug從通知欄點進“訂單詳情”連續(xù)點十次返回鍵要按十次才能回到桌面有時候從訂單詳情按返回居然跳到了首頁漏掉了中間一系列頁面。當時第一反應是哪里把launchMode寫錯了結果翻代碼發(fā)現訂單詳情頁在Manifest里根本沒寫launchMode默認standard通知欄每次點擊都在堆實例。這個bug讓我把Activity啟動模式從頭到尾梳理了一遍發(fā)現大多數人——包括當時的我——對啟動模式的理解都停留在“四種模式分別叫什么”的層面一旦涉及Intent Flag、taskAffinity、外部拉起、onNewIntent整個行為就開始失控。這篇文章把我整理的完整思路寫出來適合那些對啟動模式有基礎認知但想徹底搞懂“什么場景該用什么模式、為什么”的Android開發(fā)。不管你是剛入職的新人、還在準備面試還是維護老項目的同學啟動模式相關的Bug早晚都會來找你。我會先從任務棧講起把基礎補上然后逐個模式拆解再穿插Flag和taskAffinity這些運行時變量最后給你一套用adb驗證和線上選型的實操方法。1. 先看懂返回棧才知道四種launchMode在調什么Activity的啟動模式本質上就是在定義“一個Activity實例放進任務棧時是新建、復用還是清理”。所以不理解任務棧四種模式的名字背得再熟也只是名詞堆砌。1.1 任務棧Task是什么Android系統把一組按順序打開的Activity放進一個后進先出的棧里這個棧就叫Task。每次startActivity新頁面就被壓到棧頂每按一次返回鍵棧頂Activity出棧并銷毀。這樣講比較抽象你可以把Task想象成一摞盤子startActivity是把一個新盤子放到最上面finish是按返回鍵拿走最上面的盤子。這里有兩個特別容易被誤解的點必須先說清楚。第一Task和進程不是一回事。同一個Task里可以放不同App的Activity同一個App的Activity也可以分布在多個Task里。比如你用系統的URL Scheme打開另一個應用的某個頁面那個頁面完全可能被放進你自己的Task棧里棧里同時存在兩個應用的不同頁面這在dumpsys里非常常見。第二按Home鍵不會清空Task。Task只是被打到后臺里面的Activity都還在從桌面圖標重新點進App系統會盡量恢復原來的Task而不是每次新建一個。很多“返回棧錯亂”的問題根源就在這里——開發(fā)者以為按Home鍵等于銷毀了頁面于是沒有處理再次進入時的去重邏輯。1.2 用一個三頁跳轉實測觀察返回棧變化為了直觀感受Task我建了一個測試demo三個頁面A、B、C每頁一個按鈕跳下一頁分別在onCreate、onNewIntent、onDestroy里打日志。A - B - C之后執(zhí)行adb shell dumpsys activity activities輸出里找到當前Task部分會看到taskId下面有A、B、C三個ActivityRecord按順序排列。這時候按返回鍵C先destroy然后B再A完全符合“棧頂先出”的規(guī)則。這個實測很有價值因為很多開發(fā)者沒親眼看過多Task長什么樣。你再試一下從A跳B然后按Home鍵回桌面再從桌面圖標點進來再次執(zhí)行dumpsys會發(fā)現原來的Task還在里面躺著的還是A和B并沒有重新創(chuàng)建一份A。如果這個過程中你從最近任務列表里把App劃掉整個Task才會被銷毀。下次從圖標進入時系統才重新創(chuàng)建Task和根Activity。理解了“用戶按Home鍵只是切后臺”這個事實后面講singleTask和singleInstance時你才能理解為什么“任務棧復用”對某些頁面那么重要。2. 四種模式逐個拆解它們各自解決什么問題、又埋了什么坑2.1 standard默認行為也是最容易“棧爆炸”的模式如果不給Activity配置launchMode默認就是standard。特征是每次startActivity都創(chuàng)建一個全新的實例不管棧里是否已經存在相同的頁面然后把這個新實例壓入當前Task棧頂。standard適合什么場景適合那些“內容天然不同”的頁面比如文章詳情、商品詳情、訂單詳情。用戶可能同時打開了好幾篇不同的文章每一篇都應該是一個獨立實例按返回鍵時能一篇一篇地回退。這種情況下standard天然就是最合理的選擇。但standard最容易被坑的地方在入口頁面。舉個例子MainActivity用的是默認standard用戶進入App后按Home鍵掛在后臺再從桌面圖標點進來由于Launcher啟動應用時通常會給Intent加上FLAG_ACTIVITY_NEW_TASK而系統又找不到可以復用的Task就可能直接新建一個Task并重新創(chuàng)建MainActivity實例。最終最近任務列表里出現同一個App的多個任務每個任務里各有一個MainActivity用戶切來切去會發(fā)現返回棧完全是亂的。我用一個小項目實測過App里只有一個MainActivity不配launchMode進入后按Home再從桌面圖標反復進出三次dumpsys里能看到兩個甚至三個taskId每個taskId下都有MainActivityRecord。手機廠商的ROM可能還會把MainActivity的affinity和包名綁定導致行為更加隱蔽。我的經驗是涉及“App主入口”“首頁”“同頁面唯一”的頁面最好不要用standard裸奔。standard作為一個兜底模式當然沒問題但你要清楚它兜底的結果是“每次都是新頁面”這往往不是入口頁面想要的效果。2.2 singleTop適合通知欄和掃碼入口但不是所有“防止重復”場景都該用它singleTop的特性是如果目標Activity已經處于當前Task棧頂則不創(chuàng)建新實例而是直接復用棧頂實例并回調onNewIntent如果目標Activity不在棧頂行為跟standard一樣照樣創(chuàng)建新實例。這個“只在棧頂復用”的限定條件經常被忽略。我看到很多人給頁面配了singleTop以為就能全局防抖結果發(fā)現在“列表頁 - 詳情頁 - 再次打開另一個詳情頁”的場景下詳情頁依舊被創(chuàng)建了多個實例因為詳情頁根本不在棧頂它上面壓著列表頁。singleTop真正適合的是這類場景通知欄不斷推送同一條消息用戶點進推送落地頁或者掃碼應用連續(xù)掃出同一個結果頁。落地頁剛好在棧頂時點擊通知欄只是把新Intent交給當前頁面刷新而不會在棧頂再疊一層。注意singleTop頁面復用時會走onNewIntent而不是onCreate。如果你在singleTop頁面里依賴onCreate重新拉取數據會發(fā)現第二次從通知欄進入時頁面數據沒有刷新因為onCreate根本沒被再次調用。這個坑我在后面“onNewIntent的正確姿勢”里專門展開。2.3 singleTask最常用的復用模式但它的清棧行為經常把開發(fā)者嚇一跳singleTask的邏輯比singleTop復雜它分三步走系統按目標Activity的taskAffinity尋找對應的Task如果沒有找到就新建一個Task并把這個Activity作為根Activity壓入。如果找到了Task并且Task里已經有該Activity的實例就把這個實例之上的所有Activity全部出棧銷毀默認行為。復用該實例回調onNewIntent。這個“把上面的Activity全部出?！本褪乔鍡Ｐ袨橐彩亲钊菀壮鰡栴}的地方。舉個例子頁面棧是“首頁 - 列表 - 詳情 - 支付 - 支付成功頁”支付成功頁配置singleTask。如果用戶從詳情頁再次發(fā)起支付并成功此時詳情頁把支付成功頁又啟動了一次系統發(fā)現支付成功頁已經在棧里就會把它上面的所有Activity全部清掉。最終返回棧變成“首頁 - 支付成功頁”列表和詳情沒了。用戶按返回鍵直接回首頁甚至退出App感覺就像“跳過了一大段歷史”。這不能怪系統是singleTask的工作機制就是這樣。所以singleTask的使用場景必須很克制。它適合那些“希望始終作為Task的根節(jié)點”的頁面比如App主頁或者那些“進入后就不希望用戶返回到來路”的頁面比如收銀臺支付完成后不希望返回去修改商品。你要清楚設置singleTask等于跟系統說把這個頁面變成整個棧的錨點它上面的歷史都可以不要。另外還有一個小坑singleTask并不保證“系統里只有一個實例”。如果一個Activity設置了singleTask但taskAffinity跟當前Task不匹配系統會在另一個Task里創(chuàng)建一個新實例。這也是很多人被面試題坑的地方。所以講singleTask必須同時講taskAffinity這塊放到第3節(jié)。2.4 singleInstance全局唯一且獨立成棧用不對會讓整個App體驗割裂singleInstance比singleTask更極端擁有該Activity的Task里只允許存在這一個Activity不能有別的Activity壓進來。系統一旦創(chuàng)建了這個Activity就會單獨開一個Task給它后續(xù)再用到它時直接復用這個獨立Task里的實例。這種模式典型用于系統級來電頁面、鬧鐘響鈴頁面、語音通話界面這類“全局唯一、不希望被其他頁面干擾”的場景。在普通業(yè)務App里我?guī)缀醪煌扑]使用singleInstance。原因很實際它會讓最近任務列表里多出一個獨立任務項用戶從這個頁面按返回鍵返回的是“上一個Task”而不是這個頁面之前所在的某個子頁面。很多用戶會感覺“怎么按返回鍵跳到別的App了”體驗很割裂。另外singleInstance頁面的啟動和切換往往伴隨切換Task的動畫視覺上就像在跳App產品經理大概率會問你“為什么這個頁面跟整個App不在一個上下文里”。四種模式放到一起對比一張表就能看清模式新實例創(chuàng)建時機已存在實例時的行為是否回調onNewIntent適合場景standard每次啟動都新建無復用邏輯否文章詳情、商品詳情等獨立頁singleTop目標不在棧頂時新建目標在棧頂則復用是通知欄落地頁、掃碼結果頁singleTask棧中不存在實例時新建按affinity找Task清掉其上Activity并復用是App主框架頁、根任務頁singleInstance全局不存在實例時新建獨立Task復用并切換整個Task是系統來電頁、鬧鐘頁等3. taskAffinity和Intent Flag能在運行時改寫啟動模式的隱藏開關很多人在Manifest里配好launchMode后就以為“這個頁面的行為一定是我配的那樣”。錯了。實際線上絕大部分啟動路徑Intent上都帶了各種Flag而這些Flag在系統判斷里的優(yōu)先級比Manifest里的launchMode更高。3.1 Intent Flag優(yōu)先級高于Manifest配置先記住這條鐵律系統在決定Activity如何啟動時會先讀Intent攜帶的Flag再參考Manifest里的launchMode。兩者沖突時Flag往往能覆蓋掉launchMode的默認行為。只需要把4個Flag記住就足夠應對絕大多數場景Flag與launchMode的對應行為說明FLAG_ACTIVITY_NEW_TASK類似singleTask找Task的能力目標Task不存在則新建Task存在且affinity匹配則復用已有TaskFLAG_ACTIVITY_SINGLE_TOP等價singleTop棧頂存在目標Activity時復用否則新建FLAG_ACTIVITY_CLEAR_TOP清棧清掉目標Activity之上的所有Activity若目標Activity本身不在棧底也會被處理FLAG_ACTIVITY_CLEAR_TASK徹底清空啟動前先把整個Task所有Activity銷毀再創(chuàng)建目標ActivityFLAG_ACTIVITY_CLEAR_TOP是最容易踩坑的一個。比如標準?！癆 - B - C”你想回到A并清空B和C最穩(wěn)妥的寫法是Intent intent new Intent(context, A.class); intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP); startActivity(intent);如果只設置FLAG_ACTIVITY_CLEAR_TOP而不加SINGLE_TOP系統會把A之上的B、C銷毀同時把A本身也銷毀重建。結果是用戶明明想“回到已有頁面”頁面卻閃爍一下重新走了onCreate狀態(tài)全丟。這個反直覺行為我在線上真真切切碰到過最后排查時目瞪口呆。還有一個規(guī)則要記牢如果使用ApplicationContext、ServiceContext去startActivity必須給Intent加FLAG_ACTIVITY_NEW_TASK否則會直接拋“Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag”。很多推送SDK回調里跳頁面崩潰就是這個原因。3.2 taskAffinity決定單例模式去哪里找棧taskAffinity可以理解成Activity的“棧歸屬傾向”。默認情況下一個App所有Activity的taskAffinity都是包名。singleTask和FLAG_ACTIVITY_NEW_TASK在尋找“已有Task”時依據的就是目標Activity的taskAffinity跟哪個Task的affinity匹配。打個比方Task就像一棟大樓每個Task有自己的門牌號affinity。singleTask要找的不是“哪個Task里有我”而是“哪個Task掛的牌子跟我一致或者里面已經有一個我的實例”。如果匹配不上它不會復用而是去新開一棟樓?？鏏pp互跳時這個坑特別明顯。比如你用瀏覽器打開一個自定義scheme鏈接瀏覽器在發(fā)出Intent時經常會帶上FLAG_ACTIVITY_NEW_TASK如果目標Activity的taskAffinity跟瀏覽器Task不一致系統就會新建一個Task來放這個Activity。結果就是你從瀏覽器跳進App的某個頁面按返回鍵直接回到瀏覽器而不是回到App原本的頁面棧。普通業(yè)務App盡量不要改taskAffinity。你需要知道這個屬性的存在但大概率不會用到它。真到了需要跨模塊共享Task、或者希望多個App模塊合并到同一個Task時再考慮調整affinity并且一定要在dumpsys里反復驗證返回關系。3.3 外部拉起場景里的“意外棧”外部拉起是啟動模式問題的高發(fā)地帶主要是三個方向第一通知欄。很多開發(fā)者寫PendingIntent時要么忘了加Flag要么盲目復制網上的代碼。用戶多次點擊通知時如果目標頁面是standard會在當前Task或新Task里各創(chuàng)建一份實例返回棧越堆越長。正確的做法是給目標頁面設計好singleTop或singleTaskIntent的extra用FLAG_UPDATE_CURRENT保證最新數據能傳進去。第二URL Scheme。瀏覽器、微信、掃碼App拉起你的頁面時和你自己App內startActivity完全不一樣。外部進程發(fā)來的Intent往往帶有各種不確定的Flag有時候還帶著跨進程的ComponentName。這個時候你最不能做的就是讓“每個業(yè)務頁”直接暴露給外部。最好用一個專門的路由中轉Activity集中接收外部Intent解析后再分發(fā)到真正的業(yè)務頁。第三掃碼。如果你的落地頁是掃碼結果頁結果頁在棧頂連續(xù)被掃碼喚起時singleTop很合適但如果你希望掃碼喚起后清掉之前的中間頁面那就需要CLEAR_TOP或singleTask兩者效果完全不同要先想清楚交互預期。4. 用adb“透視”任務棧排查啟動行為混亂的實操路徑前面講了那么多理論你可能已經頭暈了。真正有用的排查手法是把抽象概念落到adb命令上用實測結果倒推啟動行為。4.1 dumpsys activity activities怎么讀命令很簡單adb shell dumpsys activity activities不同Android版本輸出格式略有差異但核心去看三個信息就夠了當前Resumed的Activity是哪個。一般會有一個topResumedActivity或mResumedActivity字樣后面跟著ComponentName。當前有幾個Task每個Task的taskId是多少。輸出里會有Task{xxx #id typestandard A包名}這個A后面的值就是該Task的affinity。每個Task下面的ActivityRecord列表。通常Activities[...]里按從底到頂的順序列出了這個Task中的所有Activity。排查啟動模式問題時不要上來就盯著一大坨日志。記住一個原則在操作前先dump一次操作后再dump一次對比差異。差異不外乎三種情況多了一個新taskId說明這次啟動被放進了新Task。原有taskId下多了一個ActivityRecord說明在既有Task里新增了頁面實例。原有taskId下的ActivityRecord數量沒變但某個Activity的狀態(tài)從Hist變成了Resumed說明復用了已有實例。這三個差異足以判斷大多數啟動行為。4.2 用am start強制指定Flag復現“Manifest被覆蓋”的場景光看不開不行還要能模擬。adb支持用命令行直接啟動特定Activity并傳Flagadb shell am start -n com.example.app/.DetailActivity --activity-single-top --activity-clear-top --activity-new-task這條命令等價于代碼里給Intent設置FLAG_ACTIVITY_SINGLE_TOP、FLAG_ACTIVITY_CLEAR_TOP、FLAG_ACTIVITY_NEW_TASK。通過替換參數你可以快速驗證“如果外部這樣拉起頁面的返回棧會變成什么樣”。還可以加-W參數查看啟動耗時adb shell am start -W -n com.example.app/.MainActivity有個小提醒你在網上搜“chrome如何調試模式啟動”時搜出來的是Chrome瀏覽器的啟動參數調試方法跟Android am start不是一回事。要復現瀏覽器通過scheme拉起App的場景用的是adb shell am start -a android.intent.action.VIEW -d yourApp://page/detail?id100 --activity-new-task4.3 用adb定位一個單例模式Bug的完整鏈路我拿一個實際Bug復盤整個排查過程?，F象用戶從桌面圖標進入App后再跳到B頁面按Home再從圖標進入發(fā)現回到了B頁面但按返回鍵卻要按很多次。第一步B頁面在Manifest里配置的是singleTask。我先執(zhí)行adb shell dumpsys activity activities發(fā)現有兩個taskId其中一個taskId里是MainActivity另一個taskId里是B頁面。問題定位到一半B頁面沒有和MainActivity待在同一個Task里。第二步檢查B頁面的taskAffinity發(fā)現有人把它改成了com.example.other和App默認包名不一致。singleTask找Task時按affinity匹配因此它找到了一個新的空任務或別的任務自然就和MainActivity分家了。第三步把taskAffinity改回默認包名重新dump驗證兩個頁面的taskId終于變成了同一個。整個鏈路就是這樣現象 - dump看Task - 發(fā)現affinity不匹配 - 修復 - 重新dump確認。這類問題如果靠肉眼看代碼很難發(fā)現但dumpsys能直接給你答案。5. 啟動模式之外的隱藏變量Activity重建與onNewIntent的配合問題有時候用戶反饋“頁面閃一下表單數據沒了”不一定跟launchMode有關系很可能是Activity被系統重建了。這一節(jié)把Activity重建的原因和onNewIntent的正確處理方式放一起講是因為它們經常在同一個Bug里同時出現。5.1 哪些配置會導致Activity重建Activity重建最常見的原因是系統配置Configuration變化。默認情況下以下變化都會讓當前Activity先destroy再重新create屏幕旋轉系統語言或地區(qū)切換深色模式切換字體大小、顯示大小調整分屏或屏幕尺寸變化每次重建都會走onSaveInstanceState - onStop - onDestroy - onCreate - onRestoreInstanceState。如果你在頁面里持有比較重的運行時狀態(tài)比如表單輸入、視頻播放進度、拍照預覽重建就很容易造成狀態(tài)丟失。一個常見的應對方式是在Manifest里配置configChanges告訴系統部分變化不需要銷毀重建activity android:name.PlayerActivity android:configChangesorientation|screenSize|uiMode|fontScale|density /這樣配置后產生這些變化時Activity不會重建而是回調onConfigurationChanged。但注意這不等于“永久解決問題”多窗口、分屏場景下有些尺寸變化不會被完整覆蓋。所以我更建議重要狀態(tài)用onSaveInstanceState保存穩(wěn)定數據用ViewModel持有而configChanges只在特定場景比如視頻播放、拍照里作為兜底。另外進程被系統回收后用戶重新回到頁面也會觸發(fā)Activity重建。這時候重建走的是“狀態(tài)恢復”路徑如果你沒有處理好onSaveInstanceState頁面就真的“什么都沒了”。5.2 onNewIntent的正確姿勢當singleTop棧頂復用、singleTask和singleInstance復用已有實例時系統不會調用onCreate而是調用onNewIntent。這時候最容易犯的錯是只處理onCreate里的Intent沒處理onNewIntent里的Intent導致第二次帶參數進入時頁面不刷新。正確做法有兩個核心點。第一一定要setIntent。override fun onNewIntent(intent: Intent?) { super.onNewIntent(intent) setIntent(intent) handleIntent(intent, isNew false) }不調setIntent的話后續(xù)調用getIntent()取到的還是舊的Intent頁面只能拿到第一次的extra排查時很難發(fā)現。第二onCreate和onNewIntent要共用同一個處理入口。override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) handleIntent(intent, isNew true) }這樣無論頁面是被創(chuàng)建還是被復用Intent里的參數都能被處理到不會出現“第一次進有數據第二次進數據還是老的”的詭異現象。還有一個很容易被忽略的細節(jié)如果用戶用某個singleTask頁面系統發(fā)現實例存在但進程已經被殺掉這次進入會先重建整個Activity走onCreate而不是onNewIntent。所以不能在onNewIntent里假設“onCreate一定已經執(zhí)行過某些成員變量一定還在”。謹慎的做法是在handleIntent里對關鍵資源做空判斷或者把關鍵數據放到ViewModel里。5.3 被CLEAR_TOP“坑到重建”的經典場景前面講過FLAG_ACTIVITY_CLEAR_TOP不搭配FLAG_ACTIVITY_SINGLE_TOP時即使目標Activity已在棧中也會被銷毀重建。這導致的直接結果是用戶點“回到上一頁”看到的卻是頁面重新加載表單數據全丟。如果你確實希望“回退到已有頁面并保留狀態(tài)”一定要把SINGLE_TOP加上如果你希望“到達目標頁時強制刷新數據”那反而可以利用這種重建行為。關鍵在于想清楚交互預期再選方案不要模棱兩可。6. 項目實戰(zhàn)選型把啟動模式落實到功能頁面而不是停留在學理6.1 常見功能頁面的啟動模式選擇參考表每接到一個頁面先給頁面定性它是根節(jié)點、跳轉中間頁、還是落地頁。然后按這個表來選頁面類型推薦模式理由App首頁/MainActivitysingleTask或standard手動去重配合桌面圖標NewTask行為避免多Task多實例登錄頁standard登錄頁通常需要保留來源頁singleTask清棧會把來路斷掉文章/商品/訂單詳情standard每次打開的內容不同需要獨立實例支付/收銀臺standard支付頁需要保留完整返回鏈不希望在支付中途被清棧WebView容器standard每個WebView頁獨立返回棧要保留來源推送/掃碼落地頁singleTask或singleTop需要復用并處理新Intent根據頁面是否常見于棧中決定系統級提醒/通話浮層singleInstance全局唯一且獨立棧業(yè)務App不要輕易用這里有個高頻問題“要不要給所有頁面都加singleTop來防重復”不要。詳情類頁面天然允許開多個實例加了singleTop之后棧里會出現“同一個類但不是同一個實例”的多個頁面反而更難處理。singleTop只解決“棧頂重復”的問題不解決“全局唯一”的問題。6.2 落地方案通知欄、掃碼和URL Scheme通知欄落地頁推薦用singleTask。每次點通知欄都復用同一個Activity實例配合PendingIntent的FLAG_UPDATE_CURRENT能保證extra里的數據是最新的。注意targetSdk 31以上PendingIntent需要顯式指定FLAG_IMMUTABLE或FLAG_MUTABLE否則運行時直接崩潰。掃碼結果頁推薦用singleTop前提是結果頁大概率位于棧頂。用戶連續(xù)掃兩個碼后一個掃碼會觸發(fā)前一個結果頁的onNewIntent頁面刷新成新的內容。如果業(yè)務上要求“掃碼后回到結果頁時清掉中間頁面”那就得用singleTask或者顯式加CLEAR_TOP。URL Scheme入口我強烈建議收斂到一個RouterActivity。不要每個業(yè)務頁都對外配scheme而是讓RouterActivity統一接收外部Intent解析后再跳真正的業(yè)務頁。RouterActivity設成singleTask處理完立刻finish這樣外部無論帶什么奇怪的Flag內部棧始終只有一條清晰路徑。6.3 我踩過的一個真實坑收銀臺的singleTask事故有個項目里頁面棧原本是“首頁 - 詳情 - WebView - 收銀臺”。收銀臺這個頁面產品經理要求“同一時間只能出現一個”于是同事把收銀臺配成了singleTask。上線后用戶反饋從收銀臺按返回鍵直接回到首頁中間的WebView和詳情全被清掉了用戶想回WebView再看一眼商品說明都不行。排查后發(fā)現收銀臺作為singleTask進入時它上方的WebView和詳情確實會被系統清棧這是設計如此不是bug。后來我們改成standard在業(yè)務代碼里控制收銀臺的finish時機來解決“同時只能存在一個”的問題。這個坑給我的啟發(fā)是singleTask的真正適用面是“根節(jié)點”不是“唯一節(jié)點”。想控制頁面唯一用單例路由或在頁面內自行去重都可以不一定要靠模式硬解。我更愿意把啟動模式理解為“棧上頁面的調度策略”而不是四行配置項。遇到任何返回棧異常不要先急著改launchMode先用dumpsys看一眼Task再確認是誰發(fā)起的啟動、帶了哪些Flag最后再決定是改Manifest、改Intent還是改路由。曾經有段時間我把每個需要去重的頁面都收進了統一的路由層在入口集中處理去重和Intent效果反而比硬調launchMode靠譜得多。如果項目里還沒有統一路由層建議至少把外部入口通知欄、URL Scheme、推送收斂到一個中轉Activity再談launchMode怎么配。