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