性能優(yōu)化：畫(huà)清Boot、冷啟動(dòng)、熱啟動(dòng)的時(shí)間漏斗)
做啟動(dòng)性能優(yōu)化做得越多我越覺(jué)得一個(gè)項(xiàng)目里最難的部分往往不是“怎么優(yōu)化”而是“怎么定義優(yōu)化目標(biāo)”。很多團(tuán)隊(duì)一說(shuō)啟動(dòng)優(yōu)化第一反應(yīng)就是壓冷啟動(dòng)耗時(shí)把幾十個(gè)初始化任務(wù)丟到異步線程跑一輪機(jī)器看到數(shù)字降了就算交差。但真到線上用戶還是說(shuō)“打開(kāi)慢”你一頭霧水。等把整個(gè)鏈路拉通之后你才會(huì)發(fā)現(xiàn)真正的問(wèn)題往往藏在 Boot、冷啟動(dòng)、熱啟動(dòng)三種窗口的交界處你優(yōu)化了 A 場(chǎng)景用戶感知的 B 場(chǎng)景卻更差了——因?yàn)槟愀緵](méi)把啟動(dòng)鏈路的時(shí)間漏斗畫(huà)完整。這篇是穩(wěn)定性性能系列的第九篇。我不打算給你列一份“啟動(dòng)優(yōu)化 checklist”而是想從三種啟動(dòng)窗口的邊界講起把冷啟動(dòng)優(yōu)化真正值得動(dòng)手的杠桿、熱啟動(dòng)和 Boot 場(chǎng)景容易被忽略的隱性耗時(shí)、以及“優(yōu)化之后怎么保證穩(wěn)定”這件事講透。內(nèi)容面向做應(yīng)用性能、穩(wěn)定性、框架優(yōu)化的小伙伴也適合剛接手啟動(dòng)性能專(zhuān)項(xiàng)、想建立全局判斷的同學(xué)。1. 先把時(shí)間漏斗畫(huà)清楚Boot、冷啟動(dòng)、熱啟動(dòng)的邊界到底在哪1.1 三個(gè)啟動(dòng)窗口的差異在移動(dòng)端項(xiàng)目里“啟動(dòng)”并不只有我們?cè)跍y(cè)試環(huán)境按一下冷啟動(dòng)那一下。從設(shè)備上電到用戶點(diǎn)開(kāi)應(yīng)用再到用戶第二次、第三次從最近任務(wù)切回整個(gè)過(guò)程至少可以分成三個(gè)完全不同的窗口Boot、冷啟動(dòng)、熱啟動(dòng)。Boot 指的是設(shè)備從開(kāi)機(jī)到系統(tǒng)可用這一整段窗口。這個(gè)階段系統(tǒng)在做包掃描、系統(tǒng)服務(wù)初始化、桌面啟動(dòng)、開(kāi)機(jī)廣播分發(fā)等大量工作CPU、磁盤(pán) IO、內(nèi)存帶寬都屬于“被爭(zhēng)搶”的狀態(tài)。很多應(yīng)用會(huì)注冊(cè)開(kāi)機(jī)廣播在 Boot 窗口內(nèi)做自啟、拉活、數(shù)據(jù)預(yù)取。這個(gè)窗口的特點(diǎn)是你看到的每一項(xiàng)任務(wù)單獨(dú)看都不大但疊加在一起會(huì)明顯拉長(zhǎng)開(kāi)機(jī)完成時(shí)間也會(huì)讓開(kāi)機(jī)后的第一次應(yīng)用冷啟動(dòng)變得異常緩慢。冷啟動(dòng)是應(yīng)用進(jìn)程從頭創(chuàng)建的過(guò)程。系統(tǒng)里原本沒(méi)有這個(gè)應(yīng)用的進(jìn)程用戶點(diǎn)擊圖標(biāo)后系統(tǒng)要?jiǎng)?chuàng)建進(jìn)程、創(chuàng)建 Application、創(chuàng)建 Activity、完成第一幀渲染再到用戶真正可以操作。這是整個(gè)啟動(dòng)鏈路里成本最高、也是大多數(shù)團(tuán)隊(duì)重點(diǎn)優(yōu)化的場(chǎng)景。熱啟動(dòng)則分成兩種常見(jiàn)形態(tài)一種是應(yīng)用進(jìn)程還活著Activity 也還在任務(wù)棧里用戶只是切回前臺(tái)另一種是進(jìn)程還活著但 Activity 已經(jīng)被系統(tǒng)回收用戶切回時(shí)需要重建 Activity 而不是重建進(jìn)程。很多人把熱啟動(dòng)等同于“切后臺(tái)再切回來(lái)”這其實(shí)不夠準(zhǔn)確。重建 Activity 的熱啟動(dòng)恢復(fù)成本很多時(shí)候比你想的要高。1.2 為什么邊界不清會(huì)讓優(yōu)化“白做”我見(jiàn)過(guò)不少團(tuán)隊(duì)在冷啟動(dòng)上花了很大力氣結(jié)果線上首幀數(shù)據(jù)好看用戶卻依然覺(jué)得“打開(kāi)慢”。原因往往出在三個(gè)地方。第一首幀定義被系統(tǒng)啟動(dòng)圖“騙”了。Activity 還沒(méi)有真正創(chuàng)建時(shí)系統(tǒng)已經(jīng)把 windowBackground 作為啟動(dòng)圖顯示出來(lái)了這個(gè)畫(huà)面出現(xiàn)得很快但它不能代表業(yè)務(wù)代碼已經(jīng)就緒。如果你以這一幀作為結(jié)束點(diǎn)所有優(yōu)化都會(huì)顯得“已經(jīng)到底了”。第二熱啟動(dòng)路徑?jīng)]有納入優(yōu)化范圍。用戶冷啟動(dòng)優(yōu)化完之后日常使用中最頻繁的反而是熱啟動(dòng)。如果熱啟動(dòng)恢復(fù)路徑上有大量重復(fù)初始化、狀態(tài)恢復(fù)、圖片重新解碼用戶感知到的“慢”會(huì)被歸因到冷啟動(dòng)頭上但你無(wú)論如何壓冷啟動(dòng)都?jí)翰粍?dòng)。第三Boot 窗口的影響被誤判成機(jī)型性能問(wèn)題。中低端機(jī)開(kāi)機(jī)后的第一次冷啟動(dòng)經(jīng)常比平時(shí)慢出好幾倍。如果不看系統(tǒng)啟動(dòng)狀態(tài)只拿開(kāi)機(jī)后的首啟數(shù)據(jù)做優(yōu)化前后對(duì)比結(jié)論可能是錯(cuò)的。所以在動(dòng)任何優(yōu)化之前先把三種窗口的時(shí)間漏斗畫(huà)出來(lái)Boot 階段的資源競(jìng)爭(zhēng)、冷啟動(dòng)的進(jìn)程創(chuàng)建與初始化、熱啟動(dòng)的 Activity 恢復(fù)與狀態(tài)回填。每個(gè)窗口的優(yōu)化手段和度量口徑都不一樣混在一起做得到的只能是一團(tuán)糊涂賬。2. 度量先行不同啟動(dòng)場(chǎng)景的埋點(diǎn)口徑與樣本采集2.1 系統(tǒng)工具能告訴你什么啟動(dòng)優(yōu)化如果只靠人手一只秒表基本等于瞎優(yōu)化。第一步是先建立起一套可復(fù)現(xiàn)的度量方式。在 Android 側(cè)最基礎(chǔ)的工具是adb shell am start -W。這條命令可以打印從啟動(dòng) Activity 到首幀呈現(xiàn)的系統(tǒng)側(cè)耗時(shí)適合在固定機(jī)型上做橫向?qū)Ρ?。?shí)際使用中我一般會(huì)配合am force-stop先殺掉應(yīng)用進(jìn)程保證測(cè)的是冷啟動(dòng)語(yǔ)義# 先停止應(yīng)用確保進(jìn)程不存在 adb shell am force-stop com.example.debug # 再啟動(dòng)目標(biāo) Activity并打印啟動(dòng)耗時(shí) adb shell am start -W -n com.example.debug/.MainActivityam start -W輸出的參數(shù)可以拿來(lái)評(píng)估同一臺(tái)設(shè)備、同一個(gè)版本的前后變化但不要直接把它當(dāng)成線上用戶可感知的啟動(dòng)時(shí)間。原因在于Activity 首幀出現(xiàn)并不等于頁(yè)面真正可交互而且這條命令覆蓋不到 Application 初始化之后的大量異步邏輯。2.2 埋點(diǎn)里最容易被帶偏的兩個(gè)口徑真正要建立的是應(yīng)用內(nèi)的自定義啟動(dòng)打點(diǎn)。建議把啟動(dòng)過(guò)程切成幾段進(jìn)程創(chuàng)建、Application.attachBaseContext、Application.onCreate、Activity.onCreate、首幀、reportFullyDrawn、用戶可交互。第一段是進(jìn)程創(chuàng)建。如果你在 API 29 及以上可以拿到進(jìn)程真實(shí)的啟動(dòng)時(shí)間低版本則在attachBaseContext里記錄一個(gè)近似起點(diǎn)。注意attachBaseContext在多進(jìn)程場(chǎng)景下會(huì)被調(diào)用多次必須用進(jìn)程名過(guò)濾只統(tǒng)計(jì)主進(jìn)程。第二段是結(jié)束點(diǎn)。首幀和“用戶可交互”不是同一回事。reportFullyDrawn()這個(gè)機(jī)制可以讓你在首幀之后、布局和數(shù)據(jù)都準(zhǔn)備好的時(shí)機(jī)主動(dòng)上報(bào)“完全繪制”。我建議同時(shí)統(tǒng)計(jì)首幀時(shí)間和 fully drawn 時(shí)間兩個(gè)都上報(bào)后續(xù)分析時(shí)才不會(huì)因?yàn)槟硞€(gè)頁(yè)面“首幀很快、內(nèi)容很慢”而被誤導(dǎo)。還有一個(gè)容易翻車(chē)的點(diǎn)冷、熱啟動(dòng)的判定。你可以在進(jìn)程內(nèi)維護(hù)一個(gè)標(biāo)記位進(jìn)程第一次執(zhí)行到啟動(dòng)流程時(shí)必然是冷啟動(dòng)Activity 只是從后臺(tái)回前臺(tái)、沒(méi)有重新執(zhí)行 onCreate 的屬于熱啟動(dòng)Activity 被重建、但是進(jìn)程仍然在的屬于“溫啟動(dòng)”統(tǒng)計(jì)時(shí)建議單獨(dú)歸類(lèi)。很多團(tuán)隊(duì)把冷啟動(dòng)和熱啟動(dòng)混在一個(gè)指標(biāo)里版本對(duì)比自然不穩(wěn)定。2.3 樣本分布決定優(yōu)化方向啟動(dòng)耗時(shí)是典型的右偏分布少數(shù)中低端機(jī)、后臺(tái)任務(wù)繁忙、存儲(chǔ)接近滿的場(chǎng)景會(huì)把平均值拖得很難看。所以線上大盤(pán)不要只盯平均啟動(dòng)耗時(shí)至少要看 P50、P90、P95 三檔。P50 代表大多數(shù)普通用戶能感受到的水平P90 到 P95 代表尾部用戶也就是最容易在應(yīng)用商店打低分的那批人。如果優(yōu)化后 P50 降了但 P95 反而漲了說(shuō)明你在提升平均體驗(yàn)時(shí)傷到了某些機(jī)型這時(shí)候要做的是分層優(yōu)化而不是直接上線。樣本數(shù)量也要注意。新版本剛發(fā)布時(shí)啟動(dòng)打點(diǎn)樣本量可能不夠尤其是低端機(jī)樣本很少這時(shí)候得出的分位值波動(dòng)會(huì)非常大。我一般會(huì)等新版本樣本覆蓋到指定比例之后再對(duì)比避免把版本升級(jí)后用戶分布變化誤判成優(yōu)化收益。3. 冷啟動(dòng)優(yōu)化真正值得動(dòng)手的四個(gè)杠桿3.1 初始化任務(wù)重排從“首幀前必須完成”倒推冷啟動(dòng)優(yōu)化最有效的動(dòng)作往往不是“把代碼寫(xiě)快”而是“把不該放在啟動(dòng)路徑上的代碼移走”。我建議把 Application 啟動(dòng)過(guò)程里所有初始化任務(wù)列成一張表逐項(xiàng)回答三個(gè)問(wèn)題第一幀渲染必須要它嗎業(yè)務(wù)主流程必須要它嗎用戶首次操作前必須準(zhǔn)備好嗎整理完之后任務(wù)通常能分成三類(lèi)。第一幀前必須完成的任務(wù)渲染核心、崩潰采集、啟動(dòng)必用的基礎(chǔ)配置。首幀后但不一定要立刻完成的任務(wù)網(wǎng)絡(luò)庫(kù)、推送、埋點(diǎn)、部分安全組件、賬號(hào)狀態(tài)同步。真正可以懶加載的任務(wù)地圖、瀏覽器內(nèi)核、廣告、低頻業(yè)務(wù)模塊。對(duì)于第二類(lèi)任務(wù)不要簡(jiǎn)單丟到一個(gè)線程池里就算完。任務(wù)之間往往有依賴關(guān)系比如登錄態(tài)要先初始化網(wǎng)絡(luò)庫(kù)才能發(fā)請(qǐng)求配置先讀出來(lái)業(yè)務(wù)模塊才能初始化。這種場(chǎng)景適合用有向無(wú)環(huán)圖的方式做任務(wù)編排把“并行初始化”變成“按依賴關(guān)系并行”而不是靠線程數(shù)硬堆。并行度并不是越高越好線程太多反而會(huì)增加鎖競(jìng)爭(zhēng)和 CPU 調(diào)度開(kāi)銷(xiāo)。3.2 主線程減負(fù)布局、存儲(chǔ)與類(lèi)加載主線程上的每一毫秒浪費(fèi)在冷啟動(dòng)階段都會(huì)被放大幾倍。 這三個(gè)方向是我每次排查啟動(dòng)性能時(shí)必查的。布局方面啟動(dòng)路徑上第一個(gè)業(yè)務(wù)頁(yè)面的 View 樹(shù)復(fù)雜度會(huì)直接影響首幀耗時(shí)。不要只看布局文件里有多少層還要看有沒(méi)有嵌套過(guò)深、權(quán)重測(cè)量、復(fù)雜 RelativeLayout 約束。減少一層無(wú)用容器、把一個(gè)重量級(jí)自定義 View 拆成更輕的實(shí)現(xiàn)效果可能比你想的更可觀。存儲(chǔ)方面啟動(dòng)過(guò)程最怕在主線程做磁盤(pán) IO。SharedPreferences 首次讀取、數(shù)據(jù)庫(kù)連接初始化、大文件掃描這些操作在主線程上很容易造成明顯的啟動(dòng)卡頓。如果首幀前一定要讀配置應(yīng)該把配置讀進(jìn)內(nèi)存后復(fù)用而不是每次啟動(dòng)都重新解析數(shù)據(jù)庫(kù)遷移這類(lèi)重活盡量放到獨(dú)立線程或者升級(jí)后的專(zhuān)門(mén)流程里。類(lèi)加載方面Java 和 Kotlin 類(lèi)第一次被使用時(shí)要經(jīng)歷加載、校驗(yàn)、初始化等過(guò)程啟動(dòng)路徑上類(lèi)的數(shù)量越多耗時(shí)越長(zhǎng)。這句話的另一面是如果你用 R8/ProGuard 做代碼縮減把啟動(dòng)路徑上用不到的類(lèi)剪掉冷啟動(dòng)收益通常很直接。但反射場(chǎng)景要格外小心縮減規(guī)則配錯(cuò)會(huì)直接導(dǎo)致運(yùn)行時(shí)崩潰。反過(guò)來(lái)“提前預(yù)加載”也要克制只有在確實(shí)測(cè)到某個(gè)類(lèi)首次加載阻塞了主線程時(shí)才值得做否則只會(huì)白白增加啟動(dòng)內(nèi)存和 IO。3.3 首幀到可交互的過(guò)渡時(shí)間別忽略冷啟動(dòng)優(yōu)化如果只盯首幀很可能會(huì)漏掉真正影響體驗(yàn)的“半秒空白”。首幀畫(huà)出來(lái)了用戶看到的是一個(gè)殼子業(yè)務(wù)數(shù)據(jù)還沒(méi)回來(lái)按鈕點(diǎn)了沒(méi)反應(yīng)這種狀態(tài)往往比白屏更讓人煩躁。所以首幀之后到 fully drawn 之間的過(guò)渡時(shí)間反而是優(yōu)化空間很大的區(qū)間。操作上可以在首幀之后的第一次主線程空閑時(shí)再去觸發(fā)真正耗時(shí)的初始化比如數(shù)據(jù)預(yù)加載、頁(yè)面渲染、部分上報(bào)。用 IdleHandler 或者類(lèi)似的空閑回調(diào)比硬編碼 sleep 可控得多。不過(guò)要注意不能把所有延遲任務(wù)都塞進(jìn)空閑回調(diào)因?yàn)橛脩艨赡茉诳臻e回調(diào)觸發(fā)前就退出了應(yīng)用導(dǎo)致任務(wù)永遠(yuǎn)執(zhí)行不完。另一個(gè)常見(jiàn)問(wèn)題是首幀之后立刻發(fā)起一大堆線程任務(wù)把主線程和 CPU 全部打滿結(jié)果頁(yè)面滑動(dòng)掉幀、網(wǎng)絡(luò)請(qǐng)求互相排隊(duì)。啟動(dòng)優(yōu)化講究的是“前慢后快”該慢的初始化寧可晚一點(diǎn)也別讓首幀和用戶交互搶資源。3.4 啟動(dòng)圖與閃屏看著快了但不一定是真快很多團(tuán)隊(duì)會(huì)用 windowBackground 做一個(gè)品牌啟動(dòng)圖系統(tǒng)在 Activity 創(chuàng)建前就把這張圖顯示出來(lái)視覺(jué)上“秒開(kāi)”。但這只是把白屏換成了圖片并沒(méi)有減少 Activity 初始化和業(yè)務(wù)加載的時(shí)間。如果啟動(dòng)圖展示的是品牌圖而 Activity 真正的首幀要等 2 秒才出現(xiàn)用戶的真實(shí)感受是“卡在啟動(dòng)圖半天進(jìn)不去”。更合理的方式是用 windowBackground 消除白屏同時(shí)讓真實(shí)的啟動(dòng)頁(yè)或者業(yè)務(wù)頁(yè)盡快接管接管之后立刻做無(wú)縫轉(zhuǎn)場(chǎng)不要故意用“啟動(dòng)圖倒計(jì)時(shí)”拉長(zhǎng)展示時(shí)長(zhǎng)。這里說(shuō)一句可能不太討喜的話啟動(dòng)圖廣告本質(zhì)上是用性能換營(yíng)收它會(huì)把用戶感知的啟動(dòng)時(shí)間拉長(zhǎng)和啟動(dòng)優(yōu)化是直接沖突的。如果你同時(shí)負(fù)責(zé)這兩塊心里要有數(shù)——你壓下去的啟動(dòng)耗時(shí)很可能被商業(yè)策略又加了回來(lái)。4. 熱啟動(dòng)與Boot場(chǎng)景容易漏掉的隱性耗時(shí)4.1 熱啟動(dòng)不是“換個(gè)頁(yè)面”恢復(fù)路徑也要做減法熱啟動(dòng)看起來(lái)快但并不意味著沒(méi)有優(yōu)化空間。特別是“進(jìn)程還在、Activity 被系統(tǒng)回收”這種場(chǎng)景無(wú)需重新創(chuàng)建進(jìn)程和 Application但 Activity 的 onCreate、setContentView、布局 inflate、數(shù)據(jù)恢復(fù)全部要重新執(zhí)行一遍。最容易出問(wèn)題的是狀態(tài)恢復(fù)。如果 onSaveInstanceState 里塞入了大對(duì)象、位圖或者復(fù)雜的序列化結(jié)構(gòu)恢復(fù)路徑上就會(huì)出現(xiàn)反序列化開(kāi)銷(xiāo)如果恢復(fù)數(shù)據(jù)還要重新從磁盤(pán)讀這個(gè)成本會(huì)進(jìn)一步放大。熱啟動(dòng)優(yōu)化的方向不是壓縮系統(tǒng)啟動(dòng)邏輯而是給 Activity 的“重建”做減法能不入棧的數(shù)據(jù)不入棧能緩存在內(nèi)存的重用緩存避免每次回來(lái)都重新計(jì)算。另外還要關(guān)注進(jìn)程被系統(tǒng) Trim Memory 之后的情況。很多頁(yè)面把圖片緩存放在內(nèi)存里內(nèi)存緊張時(shí)候這些緩存被清掉用戶切回頁(yè)面時(shí)只能重新解碼熱啟動(dòng)瞬間會(huì)感覺(jué)特別卡。治本的方法是把熱啟動(dòng)路徑上的資源緩存策略調(diào)整成“內(nèi)存不足時(shí)先釋放可重建的低優(yōu)資源”而不是把頁(yè)面恢復(fù)依賴的資源也一起清掉。一個(gè)參考判斷如果你們熱啟動(dòng)的 P50 比冷啟動(dòng) P50 的一半還高大概率是因?yàn)閱?dòng)流程里有重復(fù)初始化和恢復(fù)開(kāi)銷(xiāo)。這時(shí)候回頭查 Activity 重建路徑收益往往比繼續(xù)壓冷啟動(dòng)更大。4.2 Boot窗口開(kāi)機(jī)廣播與冷啟動(dòng)的“低氣壓區(qū)”Boot 窗口是很多應(yīng)用團(tuán)隊(duì)完全沒(méi)接管、卻直接影響用戶體驗(yàn)的一塊。系統(tǒng)開(kāi)機(jī)后要做包掃描、預(yù)加載系統(tǒng)組件、恢復(fù)上次運(yùn)行狀態(tài)磁盤(pán)和 CPU 都處于繁忙狀態(tài)。如果你的應(yīng)用注冊(cè)了開(kāi)機(jī)廣播并且在廣播回調(diào)里同步做了大量初始化你搶到的不是“自己的啟動(dòng)速度”而是整個(gè)系統(tǒng)開(kāi)機(jī)完成的時(shí)間還會(huì)連累同窗口內(nèi)其他應(yīng)用。對(duì)于絕大多數(shù)應(yīng)用開(kāi)機(jī)廣播里最該做的事情是什么都不做。把真正的任務(wù)交給系統(tǒng)級(jí)延遲調(diào)度等到系統(tǒng)空閑、滿足網(wǎng)絡(luò)條件或充電條件后再執(zhí)行。即使業(yè)務(wù)上確實(shí)需要開(kāi)機(jī)后盡快運(yùn)行也應(yīng)該控制啟動(dòng)的線程數(shù)、IO 量和鎖的持有時(shí)間不要在系統(tǒng)最忙的時(shí)候添亂。Boot 窗口還會(huì)直接影響應(yīng)用冷啟動(dòng)。應(yīng)用更新后首次啟動(dòng)、系統(tǒng)對(duì)代碼做編譯優(yōu)化時(shí)冷啟動(dòng)會(huì)比平時(shí)慢很多。這種慢不是業(yè)務(wù)代碼造成的而是系統(tǒng)在后臺(tái)做包優(yōu)化。如果你在線上發(fā)現(xiàn)某次版本發(fā)布后冷啟動(dòng)數(shù)據(jù)突然變差先確認(rèn)是不是新包觸發(fā)了系統(tǒng)編譯優(yōu)化再?zèng)Q定要不要追業(yè)務(wù)代碼。這類(lèi)問(wèn)題的處理方式不是“優(yōu)化”而是“區(qū)分責(zé)任”把系統(tǒng)側(cè)耗時(shí)從業(yè)務(wù)側(cè)指標(biāo)里剝離出來(lái)。5. 快之外的穩(wěn)定性紅線別把啟動(dòng)優(yōu)化做成事故5.1 異步化不等于安全化啟動(dòng)優(yōu)化最常用的手段是異步化但異步化恰恰是啟動(dòng)階段引入崩潰和 ANR 的高發(fā)區(qū)。一個(gè)典型的例子某個(gè)初始化任務(wù)原來(lái)在主線程上執(zhí)行順序確定的改成異步之后另一個(gè)任務(wù)依賴它的結(jié)果卻不知道它在哪個(gè)線程執(zhí)行完于是一邊等待一邊超時(shí)最后主線程被卡死出現(xiàn) ANR。還有的團(tuán)隊(duì)把崩潰上報(bào) SDK 初始化改成異步結(jié)果應(yīng)用在異步初始化完成之前就崩潰了線上崩潰直接漏報(bào)。我給所有做啟動(dòng)優(yōu)化的團(tuán)隊(duì)一個(gè)很實(shí)用的建議把啟動(dòng)任務(wù)按“同步必要性”和“狀態(tài)一致性”分等級(jí)而不是簡(jiǎn)單地分成“主線程任務(wù)”和“異步任務(wù)”。以下幾類(lèi)任務(wù)要非常謹(jǐn)慎崩潰采集和日志上報(bào)必須最早初始化通常不要異步或者異步后要有“等待完成”的兜底。影響 UI 展示的數(shù)據(jù)可以異步加載但主線程要有一個(gè)明確的超時(shí)和空態(tài)策略。多個(gè)模塊共享的狀態(tài)必須保證初始化順序或者提供統(tǒng)一的“就緒回調(diào)”不能靠猜。與賬號(hào)、支付、安全相關(guān)的能力不要為了啟動(dòng)快而犧牲正確性。5.2 上線前必須鎖定的聯(lián)合指標(biāo)啟動(dòng)優(yōu)化上線之前不只是看啟動(dòng)耗時(shí)降了多少還要同時(shí)鎖定一組穩(wěn)定性指標(biāo)冷啟動(dòng)崩潰率、啟動(dòng) ANR 率、啟動(dòng)后 1 秒和 3 秒的線程數(shù)、內(nèi)存 PSS 峰值、文件描述符數(shù)量、GC 次數(shù)。為什么強(qiáng)調(diào)聯(lián)合指標(biāo)因?yàn)閱?dòng)優(yōu)化的很多手段是“拆東墻補(bǔ)西墻”。比如把數(shù)據(jù)庫(kù)初始化挪到異步線程首幀快了但用戶第一次進(jìn)入數(shù)據(jù)頁(yè)時(shí)主線程因?yàn)榈却龜?shù)據(jù)庫(kù)就緒而卡頓ANR 率反而上升比如把圖片壓縮力度加大啟動(dòng)快了但放大后清晰度下降用戶覺(jué)得頁(yè)面糊。這些都是優(yōu)化生效但整體體驗(yàn)變差的案例只靠一個(gè)指標(biāo)根本發(fā)現(xiàn)不了。我看一個(gè)啟動(dòng)優(yōu)化改動(dòng)是否成立會(huì)要求同時(shí)給出“優(yōu)化前后啟動(dòng)指標(biāo)對(duì)比”和“優(yōu)化前后穩(wěn)定性指標(biāo)對(duì)比”。只要穩(wěn)定性指標(biāo)出現(xiàn)惡化即使啟動(dòng)耗時(shí)降了很多也不會(huì)輕易放它上線。6. 從本機(jī)跑分到線上大盤(pán)一套能落地的回歸閉環(huán)6.1 線下的固定基線讓“跑分”可復(fù)現(xiàn)啟動(dòng)優(yōu)化的基礎(chǔ)功是維護(hù)一批固定的測(cè)試設(shè)備覆蓋高中低端、不同內(nèi)存檔位用固定的腳本在每個(gè)版本上跑啟動(dòng)測(cè)試。測(cè)試腳本至少要做到自動(dòng)清理進(jìn)程、自動(dòng)啟動(dòng)目標(biāo)頁(yè)面、自動(dòng)抓取系統(tǒng)啟動(dòng)耗時(shí)和應(yīng)用內(nèi)埋點(diǎn)。不要靠人工按秒表人的反應(yīng)誤差有時(shí)候比優(yōu)化幅度還大。也不要只跑一次同一臺(tái)機(jī)器上連續(xù)跑多次會(huì)因?yàn)橛邢到y(tǒng)緩存而越來(lái)越快。常規(guī)做法是先殺掉進(jìn)程跑兩三次“預(yù)熱”讓系統(tǒng)完成必要的包編譯和緩存構(gòu)建然后再連續(xù)采樣并取中位數(shù)。腳本本身也可以寫(xiě)成固定命令配合 CI 在每次版本出包后自動(dòng)跑# 清理最近任務(wù)并強(qiáng)停應(yīng)用保證冷啟動(dòng)語(yǔ)義 adb shell am force-stop com.example.debug # 啟動(dòng)并等待首幀 adb shell am start -W -n com.example.debug/.MainActivity # 抓取應(yīng)用內(nèi)啟動(dòng)埋點(diǎn)日志 adb logcat -d -s StartupMetric線下固定基線的意義不是“測(cè)得絕對(duì)精確”而是讓前后版本之間具備可比性。所以線上機(jī)型、系統(tǒng)版本、測(cè)試流程都不要隨意更換每次對(duì)比都用同一臺(tái)基線機(jī)。6.2 線上的分位值監(jiān)控別被平均數(shù)騙了線下測(cè)完不等于優(yōu)化閉環(huán)結(jié)束。真正起作用的是線上大盤(pán)冷啟動(dòng) P50、P90、P95熱啟動(dòng) P50、P95首幀到可交互的分段耗時(shí)啟動(dòng)崩潰率和 ANR 率。線上版本對(duì)比時(shí)要特別小心兩點(diǎn)。第一統(tǒng)計(jì)口徑不能隨便改。啟動(dòng)完成時(shí)間從首幀改成 fully drawn相當(dāng)于換了一條新的基線前后數(shù)據(jù)沒(méi)有可比性。如果必須調(diào)整口徑要把新舊口徑并行統(tǒng)計(jì)一個(gè)版本周期再切換。第二不要只看版本平均值。新版本用戶結(jié)構(gòu)可能發(fā)生變化比如灰度賬號(hào)偏高端機(jī)導(dǎo)致啟動(dòng)數(shù)據(jù)虛好。所以我會(huì)按機(jī)型檔位做分層對(duì)比重點(diǎn)看中低端機(jī)上的 P95一旦優(yōu)化對(duì)低端機(jī)不友好馬上能看出來(lái)。另外建議建一個(gè)啟動(dòng)性能回歸看板每個(gè)版本發(fā)布后自動(dòng)比對(duì)。它的價(jià)值在于當(dāng)你下次再改某項(xiàng)功能時(shí)能第一時(shí)間發(fā)現(xiàn)“這個(gè)版本給啟動(dòng)路徑加了 50 毫秒”而不是等到用戶反饋?zhàn)儾钪蟛抛凡?。我現(xiàn)在的工作習(xí)慣是任何啟動(dòng)優(yōu)化改動(dòng)必須附帶三類(lèi)數(shù)據(jù)——固定基線機(jī)上的前后對(duì)比、啟動(dòng)任務(wù)鏈路各分段時(shí)間、線上灰度后的分位值和穩(wěn)定性指標(biāo)。拿不出這三樣就不要說(shuō)自己優(yōu)化了啟動(dòng)。啟動(dòng)性能是一個(gè)長(zhǎng)期維護(hù)的地基工程不是某一次上線完成就結(jié)束的事情。 啟動(dòng)性能優(yōu)化：畫(huà)清Boot、冷啟動(dòng)、熱啟動(dòng)的時(shí)間漏斗
做啟動(dòng)性能優(yōu)化做得越多我越覺(jué)得一個(gè)項(xiàng)目里最難的部分往往不是“怎么優(yōu)化”而是“怎么定義優(yōu)化目標(biāo)”。很多團(tuán)隊(duì)一說(shuō)啟動(dòng)優(yōu)化第一反應(yīng)就是壓冷啟動(dòng)耗時(shí)把幾十個(gè)初始化任務(wù)丟到異步線程跑一輪機(jī)器看到數(shù)字降了就算交差。但真到線上用戶還是說(shuō)“打開(kāi)慢”你一頭霧水。等把整個(gè)鏈路拉通之后你才會(huì)發(fā)現(xiàn)真正的問(wèn)題往往藏在 Boot、冷啟動(dòng)、熱啟動(dòng)三種窗口的交界處你優(yōu)化了 A 場(chǎng)景用戶感知的 B 場(chǎng)景卻更差了——因?yàn)槟愀緵](méi)把啟動(dòng)鏈路的時(shí)間漏斗畫(huà)完整。這篇是穩(wěn)定性性能系列的第九篇。我不打算給你列一份“啟動(dòng)優(yōu)化 checklist”而是想從三種啟動(dòng)窗口的邊界講起把冷啟動(dòng)優(yōu)化真正值得動(dòng)手的杠桿、熱啟動(dòng)和 Boot 場(chǎng)景容易被忽略的隱性耗時(shí)、以及“優(yōu)化之后怎么保證穩(wěn)定”這件事講透。內(nèi)容面向做應(yīng)用性能、穩(wěn)定性、框架優(yōu)化的小伙伴也適合剛接手啟動(dòng)性能專(zhuān)項(xiàng)、想建立全局判斷的同學(xué)。1. 先把時(shí)間漏斗畫(huà)清楚Boot、冷啟動(dòng)、熱啟動(dòng)的邊界到底在哪1.1 三個(gè)啟動(dòng)窗口的差異在移動(dòng)端項(xiàng)目里“啟動(dòng)”并不只有我們?cè)跍y(cè)試環(huán)境按一下冷啟動(dòng)那一下。從設(shè)備上電到用戶點(diǎn)開(kāi)應(yīng)用再到用戶第二次、第三次從最近任務(wù)切回整個(gè)過(guò)程至少可以分成三個(gè)完全不同的窗口Boot、冷啟動(dòng)、熱啟動(dòng)。Boot 指的是設(shè)備從開(kāi)機(jī)到系統(tǒng)可用這一整段窗口。這個(gè)階段系統(tǒng)在做包掃描、系統(tǒng)服務(wù)初始化、桌面啟動(dòng)、開(kāi)機(jī)廣播分發(fā)等大量工作CPU、磁盤(pán) IO、內(nèi)存帶寬都屬于“被爭(zhēng)搶”的狀態(tài)。很多應(yīng)用會(huì)注冊(cè)開(kāi)機(jī)廣播在 Boot 窗口內(nèi)做自啟、拉活、數(shù)據(jù)預(yù)取。這個(gè)窗口的特點(diǎn)是你看到的每一項(xiàng)任務(wù)單獨(dú)看都不大但疊加在一起會(huì)明顯拉長(zhǎng)開(kāi)機(jī)完成時(shí)間也會(huì)讓開(kāi)機(jī)后的第一次應(yīng)用冷啟動(dòng)變得異常緩慢。冷啟動(dòng)是應(yīng)用進(jìn)程從頭創(chuàng)建的過(guò)程。系統(tǒng)里原本沒(méi)有這個(gè)應(yīng)用的進(jìn)程用戶點(diǎn)擊圖標(biāo)后系統(tǒng)要?jiǎng)?chuàng)建進(jìn)程、創(chuàng)建 Application、創(chuàng)建 Activity、完成第一幀渲染再到用戶真正可以操作。這是整個(gè)啟動(dòng)鏈路里成本最高、也是大多數(shù)團(tuán)隊(duì)重點(diǎn)優(yōu)化的場(chǎng)景。熱啟動(dòng)則分成兩種常見(jiàn)形態(tài)一種是應(yīng)用進(jìn)程還活著Activity 也還在任務(wù)棧里用戶只是切回前臺(tái)另一種是進(jìn)程還活著但 Activity 已經(jīng)被系統(tǒng)回收用戶切回時(shí)需要重建 Activity 而不是重建進(jìn)程。很多人把熱啟動(dòng)等同于“切后臺(tái)再切回來(lái)”這其實(shí)不夠準(zhǔn)確。重建 Activity 的熱啟動(dòng)恢復(fù)成本很多時(shí)候比你想的要高。1.2 為什么邊界不清會(huì)讓優(yōu)化“白做”我見(jiàn)過(guò)不少團(tuán)隊(duì)在冷啟動(dòng)上花了很大力氣結(jié)果線上首幀數(shù)據(jù)好看用戶卻依然覺(jué)得“打開(kāi)慢”。原因往往出在三個(gè)地方。第一首幀定義被系統(tǒng)啟動(dòng)圖“騙”了。Activity 還沒(méi)有真正創(chuàng)建時(shí)系統(tǒng)已經(jīng)把 windowBackground 作為啟動(dòng)圖顯示出來(lái)了這個(gè)畫(huà)面出現(xiàn)得很快但它不能代表業(yè)務(wù)代碼已經(jīng)就緒。如果你以這一幀作為結(jié)束點(diǎn)所有優(yōu)化都會(huì)顯得“已經(jīng)到底了”。第二熱啟動(dòng)路徑?jīng)]有納入優(yōu)化范圍。用戶冷啟動(dòng)優(yōu)化完之后日常使用中最頻繁的反而是熱啟動(dòng)。如果熱啟動(dòng)恢復(fù)路徑上有大量重復(fù)初始化、狀態(tài)恢復(fù)、圖片重新解碼用戶感知到的“慢”會(huì)被歸因到冷啟動(dòng)頭上但你無(wú)論如何壓冷啟動(dòng)都?jí)翰粍?dòng)。第三Boot 窗口的影響被誤判成機(jī)型性能問(wèn)題。中低端機(jī)開(kāi)機(jī)后的第一次冷啟動(dòng)經(jīng)常比平時(shí)慢出好幾倍。如果不看系統(tǒng)啟動(dòng)狀態(tài)只拿開(kāi)機(jī)后的首啟數(shù)據(jù)做優(yōu)化前后對(duì)比結(jié)論可能是錯(cuò)的。所以在動(dòng)任何優(yōu)化之前先把三種窗口的時(shí)間漏斗畫(huà)出來(lái)Boot 階段的資源競(jìng)爭(zhēng)、冷啟動(dòng)的進(jìn)程創(chuàng)建與初始化、熱啟動(dòng)的 Activity 恢復(fù)與狀態(tài)回填。每個(gè)窗口的優(yōu)化手段和度量口徑都不一樣混在一起做得到的只能是一團(tuán)糊涂賬。2. 度量先行不同啟動(dòng)場(chǎng)景的埋點(diǎn)口徑與樣本采集2.1 系統(tǒng)工具能告訴你什么啟動(dòng)優(yōu)化如果只靠人手一只秒表基本等于瞎優(yōu)化。第一步是先建立起一套可復(fù)現(xiàn)的度量方式。在 Android 側(cè)最基礎(chǔ)的工具是adb shell am start -W。這條命令可以打印從啟動(dòng) Activity 到首幀呈現(xiàn)的系統(tǒng)側(cè)耗時(shí)適合在固定機(jī)型上做橫向?qū)Ρ?。?shí)際使用中我一般會(huì)配合am force-stop先殺掉應(yīng)用進(jìn)程保證測(cè)的是冷啟動(dòng)語(yǔ)義# 先停止應(yīng)用確保進(jìn)程不存在 adb shell am force-stop com.example.debug # 再啟動(dòng)目標(biāo) Activity并打印啟動(dòng)耗時(shí) adb shell am start -W -n com.example.debug/.MainActivityam start -W輸出的參數(shù)可以拿來(lái)評(píng)估同一臺(tái)設(shè)備、同一個(gè)版本的前后變化但不要直接把它當(dāng)成線上用戶可感知的啟動(dòng)時(shí)間。原因在于Activity 首幀出現(xiàn)并不等于頁(yè)面真正可交互而且這條命令覆蓋不到 Application 初始化之后的大量異步邏輯。2.2 埋點(diǎn)里最容易被帶偏的兩個(gè)口徑真正要建立的是應(yīng)用內(nèi)的自定義啟動(dòng)打點(diǎn)。建議把啟動(dòng)過(guò)程切成幾段進(jìn)程創(chuàng)建、Application.attachBaseContext、Application.onCreate、Activity.onCreate、首幀、reportFullyDrawn、用戶可交互。第一段是進(jìn)程創(chuàng)建。如果你在 API 29 及以上可以拿到進(jìn)程真實(shí)的啟動(dòng)時(shí)間低版本則在attachBaseContext里記錄一個(gè)近似起點(diǎn)。注意attachBaseContext在多進(jìn)程場(chǎng)景下會(huì)被調(diào)用多次必須用進(jìn)程名過(guò)濾只統(tǒng)計(jì)主進(jìn)程。第二段是結(jié)束點(diǎn)。首幀和“用戶可交互”不是同一回事。reportFullyDrawn()這個(gè)機(jī)制可以讓你在首幀之后、布局和數(shù)據(jù)都準(zhǔn)備好的時(shí)機(jī)主動(dòng)上報(bào)“完全繪制”。我建議同時(shí)統(tǒng)計(jì)首幀時(shí)間和 fully drawn 時(shí)間兩個(gè)都上報(bào)后續(xù)分析時(shí)才不會(huì)因?yàn)槟硞€(gè)頁(yè)面“首幀很快、內(nèi)容很慢”而被誤導(dǎo)。還有一個(gè)容易翻車(chē)的點(diǎn)冷、熱啟動(dòng)的判定。你可以在進(jìn)程內(nèi)維護(hù)一個(gè)標(biāo)記位進(jìn)程第一次執(zhí)行到啟動(dòng)流程時(shí)必然是冷啟動(dòng)Activity 只是從后臺(tái)回前臺(tái)、沒(méi)有重新執(zhí)行 onCreate 的屬于熱啟動(dòng)Activity 被重建、但是進(jìn)程仍然在的屬于“溫啟動(dòng)”統(tǒng)計(jì)時(shí)建議單獨(dú)歸類(lèi)。很多團(tuán)隊(duì)把冷啟動(dòng)和熱啟動(dòng)混在一個(gè)指標(biāo)里版本對(duì)比自然不穩(wěn)定。2.3 樣本分布決定優(yōu)化方向啟動(dòng)耗時(shí)是典型的右偏分布少數(shù)中低端機(jī)、后臺(tái)任務(wù)繁忙、存儲(chǔ)接近滿的場(chǎng)景會(huì)把平均值拖得很難看。所以線上大盤(pán)不要只盯平均啟動(dòng)耗時(shí)至少要看 P50、P90、P95 三檔。P50 代表大多數(shù)普通用戶能感受到的水平P90 到 P95 代表尾部用戶也就是最容易在應(yīng)用商店打低分的那批人。如果優(yōu)化后 P50 降了但 P95 反而漲了說(shuō)明你在提升平均體驗(yàn)時(shí)傷到了某些機(jī)型這時(shí)候要做的是分層優(yōu)化而不是直接上線。樣本數(shù)量也要注意。新版本剛發(fā)布時(shí)啟動(dòng)打點(diǎn)樣本量可能不夠尤其是低端機(jī)樣本很少這時(shí)候得出的分位值波動(dòng)會(huì)非常大。我一般會(huì)等新版本樣本覆蓋到指定比例之后再對(duì)比避免把版本升級(jí)后用戶分布變化誤判成優(yōu)化收益。3. 冷啟動(dòng)優(yōu)化真正值得動(dòng)手的四個(gè)杠桿3.1 初始化任務(wù)重排從“首幀前必須完成”倒推冷啟動(dòng)優(yōu)化最有效的動(dòng)作往往不是“把代碼寫(xiě)快”而是“把不該放在啟動(dòng)路徑上的代碼移走”。我建議把 Application 啟動(dòng)過(guò)程里所有初始化任務(wù)列成一張表逐項(xiàng)回答三個(gè)問(wèn)題第一幀渲染必須要它嗎業(yè)務(wù)主流程必須要它嗎用戶首次操作前必須準(zhǔn)備好嗎整理完之后任務(wù)通常能分成三類(lèi)。第一幀前必須完成的任務(wù)渲染核心、崩潰采集、啟動(dòng)必用的基礎(chǔ)配置。首幀后但不一定要立刻完成的任務(wù)網(wǎng)絡(luò)庫(kù)、推送、埋點(diǎn)、部分安全組件、賬號(hào)狀態(tài)同步。真正可以懶加載的任務(wù)地圖、瀏覽器內(nèi)核、廣告、低頻業(yè)務(wù)模塊。對(duì)于第二類(lèi)任務(wù)不要簡(jiǎn)單丟到一個(gè)線程池里就算完。任務(wù)之間往往有依賴關(guān)系比如登錄態(tài)要先初始化網(wǎng)絡(luò)庫(kù)才能發(fā)請(qǐng)求配置先讀出來(lái)業(yè)務(wù)模塊才能初始化。這種場(chǎng)景適合用有向無(wú)環(huán)圖的方式做任務(wù)編排把“并行初始化”變成“按依賴關(guān)系并行”而不是靠線程數(shù)硬堆。并行度并不是越高越好線程太多反而會(huì)增加鎖競(jìng)爭(zhēng)和 CPU 調(diào)度開(kāi)銷(xiāo)。3.2 主線程減負(fù)布局、存儲(chǔ)與類(lèi)加載主線程上的每一毫秒浪費(fèi)在冷啟動(dòng)階段都會(huì)被放大幾倍。 這三個(gè)方向是我每次排查啟動(dòng)性能時(shí)必查的。布局方面啟動(dòng)路徑上第一個(gè)業(yè)務(wù)頁(yè)面的 View 樹(shù)復(fù)雜度會(huì)直接影響首幀耗時(shí)。不要只看布局文件里有多少層還要看有沒(méi)有嵌套過(guò)深、權(quán)重測(cè)量、復(fù)雜 RelativeLayout 約束。減少一層無(wú)用容器、把一個(gè)重量級(jí)自定義 View 拆成更輕的實(shí)現(xiàn)效果可能比你想的更可觀。存儲(chǔ)方面啟動(dòng)過(guò)程最怕在主線程做磁盤(pán) IO。SharedPreferences 首次讀取、數(shù)據(jù)庫(kù)連接初始化、大文件掃描這些操作在主線程上很容易造成明顯的啟動(dòng)卡頓。如果首幀前一定要讀配置應(yīng)該把配置讀進(jìn)內(nèi)存后復(fù)用而不是每次啟動(dòng)都重新解析數(shù)據(jù)庫(kù)遷移這類(lèi)重活盡量放到獨(dú)立線程或者升級(jí)后的專(zhuān)門(mén)流程里。類(lèi)加載方面Java 和 Kotlin 類(lèi)第一次被使用時(shí)要經(jīng)歷加載、校驗(yàn)、初始化等過(guò)程啟動(dòng)路徑上類(lèi)的數(shù)量越多耗時(shí)越長(zhǎng)。這句話的另一面是如果你用 R8/ProGuard 做代碼縮減把啟動(dòng)路徑上用不到的類(lèi)剪掉冷啟動(dòng)收益通常很直接。但反射場(chǎng)景要格外小心縮減規(guī)則配錯(cuò)會(huì)直接導(dǎo)致運(yùn)行時(shí)崩潰。反過(guò)來(lái)“提前預(yù)加載”也要克制只有在確實(shí)測(cè)到某個(gè)類(lèi)首次加載阻塞了主線程時(shí)才值得做否則只會(huì)白白增加啟動(dòng)內(nèi)存和 IO。3.3 首幀到可交互的過(guò)渡時(shí)間別忽略冷啟動(dòng)優(yōu)化如果只盯首幀很可能會(huì)漏掉真正影響體驗(yàn)的“半秒空白”。首幀畫(huà)出來(lái)了用戶看到的是一個(gè)殼子業(yè)務(wù)數(shù)據(jù)還沒(méi)回來(lái)按鈕點(diǎn)了沒(méi)反應(yīng)這種狀態(tài)往往比白屏更讓人煩躁。所以首幀之后到 fully drawn 之間的過(guò)渡時(shí)間反而是優(yōu)化空間很大的區(qū)間。操作上可以在首幀之后的第一次主線程空閑時(shí)再去觸發(fā)真正耗時(shí)的初始化比如數(shù)據(jù)預(yù)加載、頁(yè)面渲染、部分上報(bào)。用 IdleHandler 或者類(lèi)似的空閑回調(diào)比硬編碼 sleep 可控得多。不過(guò)要注意不能把所有延遲任務(wù)都塞進(jìn)空閑回調(diào)因?yàn)橛脩艨赡茉诳臻e回調(diào)觸發(fā)前就退出了應(yīng)用導(dǎo)致任務(wù)永遠(yuǎn)執(zhí)行不完。另一個(gè)常見(jiàn)問(wèn)題是首幀之后立刻發(fā)起一大堆線程任務(wù)把主線程和 CPU 全部打滿結(jié)果頁(yè)面滑動(dòng)掉幀、網(wǎng)絡(luò)請(qǐng)求互相排隊(duì)。啟動(dòng)優(yōu)化講究的是“前慢后快”該慢的初始化寧可晚一點(diǎn)也別讓首幀和用戶交互搶資源。3.4 啟動(dòng)圖與閃屏看著快了但不一定是真快很多團(tuán)隊(duì)會(huì)用 windowBackground 做一個(gè)品牌啟動(dòng)圖系統(tǒng)在 Activity 創(chuàng)建前就把這張圖顯示出來(lái)視覺(jué)上“秒開(kāi)”。但這只是把白屏換成了圖片并沒(méi)有減少 Activity 初始化和業(yè)務(wù)加載的時(shí)間。如果啟動(dòng)圖展示的是品牌圖而 Activity 真正的首幀要等 2 秒才出現(xiàn)用戶的真實(shí)感受是“卡在啟動(dòng)圖半天進(jìn)不去”。更合理的方式是用 windowBackground 消除白屏同時(shí)讓真實(shí)的啟動(dòng)頁(yè)或者業(yè)務(wù)頁(yè)盡快接管接管之后立刻做無(wú)縫轉(zhuǎn)場(chǎng)不要故意用“啟動(dòng)圖倒計(jì)時(shí)”拉長(zhǎng)展示時(shí)長(zhǎng)。這里說(shuō)一句可能不太討喜的話啟動(dòng)圖廣告本質(zhì)上是用性能換營(yíng)收它會(huì)把用戶感知的啟動(dòng)時(shí)間拉長(zhǎng)和啟動(dòng)優(yōu)化是直接沖突的。如果你同時(shí)負(fù)責(zé)這兩塊心里要有數(shù)——你壓下去的啟動(dòng)耗時(shí)很可能被商業(yè)策略又加了回來(lái)。4. 熱啟動(dòng)與Boot場(chǎng)景容易漏掉的隱性耗時(shí)4.1 熱啟動(dòng)不是“換個(gè)頁(yè)面”恢復(fù)路徑也要做減法熱啟動(dòng)看起來(lái)快但并不意味著沒(méi)有優(yōu)化空間。特別是“進(jìn)程還在、Activity 被系統(tǒng)回收”這種場(chǎng)景無(wú)需重新創(chuàng)建進(jìn)程和 Application但 Activity 的 onCreate、setContentView、布局 inflate、數(shù)據(jù)恢復(fù)全部要重新執(zhí)行一遍。最容易出問(wèn)題的是狀態(tài)恢復(fù)。如果 onSaveInstanceState 里塞入了大對(duì)象、位圖或者復(fù)雜的序列化結(jié)構(gòu)恢復(fù)路徑上就會(huì)出現(xiàn)反序列化開(kāi)銷(xiāo)如果恢復(fù)數(shù)據(jù)還要重新從磁盤(pán)讀這個(gè)成本會(huì)進(jìn)一步放大。熱啟動(dòng)優(yōu)化的方向不是壓縮系統(tǒng)啟動(dòng)邏輯而是給 Activity 的“重建”做減法能不入棧的數(shù)據(jù)不入棧能緩存在內(nèi)存的重用緩存避免每次回來(lái)都重新計(jì)算。另外還要關(guān)注進(jìn)程被系統(tǒng) Trim Memory 之后的情況。很多頁(yè)面把圖片緩存放在內(nèi)存里內(nèi)存緊張時(shí)候這些緩存被清掉用戶切回頁(yè)面時(shí)只能重新解碼熱啟動(dòng)瞬間會(huì)感覺(jué)特別卡。治本的方法是把熱啟動(dòng)路徑上的資源緩存策略調(diào)整成“內(nèi)存不足時(shí)先釋放可重建的低優(yōu)資源”而不是把頁(yè)面恢復(fù)依賴的資源也一起清掉。一個(gè)參考判斷如果你們熱啟動(dòng)的 P50 比冷啟動(dòng) P50 的一半還高大概率是因?yàn)閱?dòng)流程里有重復(fù)初始化和恢復(fù)開(kāi)銷(xiāo)。這時(shí)候回頭查 Activity 重建路徑收益往往比繼續(xù)壓冷啟動(dòng)更大。4.2 Boot窗口開(kāi)機(jī)廣播與冷啟動(dòng)的“低氣壓區(qū)”Boot 窗口是很多應(yīng)用團(tuán)隊(duì)完全沒(méi)接管、卻直接影響用戶體驗(yàn)的一塊。系統(tǒng)開(kāi)機(jī)后要做包掃描、預(yù)加載系統(tǒng)組件、恢復(fù)上次運(yùn)行狀態(tài)磁盤(pán)和 CPU 都處于繁忙狀態(tài)。如果你的應(yīng)用注冊(cè)了開(kāi)機(jī)廣播并且在廣播回調(diào)里同步做了大量初始化你搶到的不是“自己的啟動(dòng)速度”而是整個(gè)系統(tǒng)開(kāi)機(jī)完成的時(shí)間還會(huì)連累同窗口內(nèi)其他應(yīng)用。對(duì)于絕大多數(shù)應(yīng)用開(kāi)機(jī)廣播里最該做的事情是什么都不做。把真正的任務(wù)交給系統(tǒng)級(jí)延遲調(diào)度等到系統(tǒng)空閑、滿足網(wǎng)絡(luò)條件或充電條件后再執(zhí)行。即使業(yè)務(wù)上確實(shí)需要開(kāi)機(jī)后盡快運(yùn)行也應(yīng)該控制啟動(dòng)的線程數(shù)、IO 量和鎖的持有時(shí)間不要在系統(tǒng)最忙的時(shí)候添亂。Boot 窗口還會(huì)直接影響應(yīng)用冷啟動(dòng)。應(yīng)用更新后首次啟動(dòng)、系統(tǒng)對(duì)代碼做編譯優(yōu)化時(shí)冷啟動(dòng)會(huì)比平時(shí)慢很多。這種慢不是業(yè)務(wù)代碼造成的而是系統(tǒng)在后臺(tái)做包優(yōu)化。如果你在線上發(fā)現(xiàn)某次版本發(fā)布后冷啟動(dòng)數(shù)據(jù)突然變差先確認(rèn)是不是新包觸發(fā)了系統(tǒng)編譯優(yōu)化再?zèng)Q定要不要追業(yè)務(wù)代碼。這類(lèi)問(wèn)題的處理方式不是“優(yōu)化”而是“區(qū)分責(zé)任”把系統(tǒng)側(cè)耗時(shí)從業(yè)務(wù)側(cè)指標(biāo)里剝離出來(lái)。5. 快之外的穩(wěn)定性紅線別把啟動(dòng)優(yōu)化做成事故5.1 異步化不等于安全化啟動(dòng)優(yōu)化最常用的手段是異步化但異步化恰恰是啟動(dòng)階段引入崩潰和 ANR 的高發(fā)區(qū)。一個(gè)典型的例子某個(gè)初始化任務(wù)原來(lái)在主線程上執(zhí)行順序確定的改成異步之后另一個(gè)任務(wù)依賴它的結(jié)果卻不知道它在哪個(gè)線程執(zhí)行完于是一邊等待一邊超時(shí)最后主線程被卡死出現(xiàn) ANR。還有的團(tuán)隊(duì)把崩潰上報(bào) SDK 初始化改成異步結(jié)果應(yīng)用在異步初始化完成之前就崩潰了線上崩潰直接漏報(bào)。我給所有做啟動(dòng)優(yōu)化的團(tuán)隊(duì)一個(gè)很實(shí)用的建議把啟動(dòng)任務(wù)按“同步必要性”和“狀態(tài)一致性”分等級(jí)而不是簡(jiǎn)單地分成“主線程任務(wù)”和“異步任務(wù)”。以下幾類(lèi)任務(wù)要非常謹(jǐn)慎崩潰采集和日志上報(bào)必須最早初始化通常不要異步或者異步后要有“等待完成”的兜底。影響 UI 展示的數(shù)據(jù)可以異步加載但主線程要有一個(gè)明確的超時(shí)和空態(tài)策略。多個(gè)模塊共享的狀態(tài)必須保證初始化順序或者提供統(tǒng)一的“就緒回調(diào)”不能靠猜。與賬號(hào)、支付、安全相關(guān)的能力不要為了啟動(dòng)快而犧牲正確性。5.2 上線前必須鎖定的聯(lián)合指標(biāo)啟動(dòng)優(yōu)化上線之前不只是看啟動(dòng)耗時(shí)降了多少還要同時(shí)鎖定一組穩(wěn)定性指標(biāo)冷啟動(dòng)崩潰率、啟動(dòng) ANR 率、啟動(dòng)后 1 秒和 3 秒的線程數(shù)、內(nèi)存 PSS 峰值、文件描述符數(shù)量、GC 次數(shù)。為什么強(qiáng)調(diào)聯(lián)合指標(biāo)因?yàn)閱?dòng)優(yōu)化的很多手段是“拆東墻補(bǔ)西墻”。比如把數(shù)據(jù)庫(kù)初始化挪到異步線程首幀快了但用戶第一次進(jìn)入數(shù)據(jù)頁(yè)時(shí)主線程因?yàn)榈却龜?shù)據(jù)庫(kù)就緒而卡頓ANR 率反而上升比如把圖片壓縮力度加大啟動(dòng)快了但放大后清晰度下降用戶覺(jué)得頁(yè)面糊。這些都是優(yōu)化生效但整體體驗(yàn)變差的案例只靠一個(gè)指標(biāo)根本發(fā)現(xiàn)不了。我看一個(gè)啟動(dòng)優(yōu)化改動(dòng)是否成立會(huì)要求同時(shí)給出“優(yōu)化前后啟動(dòng)指標(biāo)對(duì)比”和“優(yōu)化前后穩(wěn)定性指標(biāo)對(duì)比”。只要穩(wěn)定性指標(biāo)出現(xiàn)惡化即使啟動(dòng)耗時(shí)降了很多也不會(huì)輕易放它上線。6. 從本機(jī)跑分到線上大盤(pán)一套能落地的回歸閉環(huán)6.1 線下的固定基線讓“跑分”可復(fù)現(xiàn)啟動(dòng)優(yōu)化的基礎(chǔ)功是維護(hù)一批固定的測(cè)試設(shè)備覆蓋高中低端、不同內(nèi)存檔位用固定的腳本在每個(gè)版本上跑啟動(dòng)測(cè)試。測(cè)試腳本至少要做到自動(dòng)清理進(jìn)程、自動(dòng)啟動(dòng)目標(biāo)頁(yè)面、自動(dòng)抓取系統(tǒng)啟動(dòng)耗時(shí)和應(yīng)用內(nèi)埋點(diǎn)。不要靠人工按秒表人的反應(yīng)誤差有時(shí)候比優(yōu)化幅度還大。也不要只跑一次同一臺(tái)機(jī)器上連續(xù)跑多次會(huì)因?yàn)橛邢到y(tǒng)緩存而越來(lái)越快。常規(guī)做法是先殺掉進(jìn)程跑兩三次“預(yù)熱”讓系統(tǒng)完成必要的包編譯和緩存構(gòu)建然后再連續(xù)采樣并取中位數(shù)。腳本本身也可以寫(xiě)成固定命令配合 CI 在每次版本出包后自動(dòng)跑# 清理最近任務(wù)并強(qiáng)停應(yīng)用保證冷啟動(dòng)語(yǔ)義 adb shell am force-stop com.example.debug # 啟動(dòng)并等待首幀 adb shell am start -W -n com.example.debug/.MainActivity # 抓取應(yīng)用內(nèi)啟動(dòng)埋點(diǎn)日志 adb logcat -d -s StartupMetric線下固定基線的意義不是“測(cè)得絕對(duì)精確”而是讓前后版本之間具備可比性。所以線上機(jī)型、系統(tǒng)版本、測(cè)試流程都不要隨意更換每次對(duì)比都用同一臺(tái)基線機(jī)。6.2 線上的分位值監(jiān)控別被平均數(shù)騙了線下測(cè)完不等于優(yōu)化閉環(huán)結(jié)束。真正起作用的是線上大盤(pán)冷啟動(dòng) P50、P90、P95熱啟動(dòng) P50、P95首幀到可交互的分段耗時(shí)啟動(dòng)崩潰率和 ANR 率。線上版本對(duì)比時(shí)要特別小心兩點(diǎn)。第一統(tǒng)計(jì)口徑不能隨便改。啟動(dòng)完成時(shí)間從首幀改成 fully drawn相當(dāng)于換了一條新的基線前后數(shù)據(jù)沒(méi)有可比性。如果必須調(diào)整口徑要把新舊口徑并行統(tǒng)計(jì)一個(gè)版本周期再切換。第二不要只看版本平均值。新版本用戶結(jié)構(gòu)可能發(fā)生變化比如灰度賬號(hào)偏高端機(jī)導(dǎo)致啟動(dòng)數(shù)據(jù)虛好。所以我會(huì)按機(jī)型檔位做分層對(duì)比重點(diǎn)看中低端機(jī)上的 P95一旦優(yōu)化對(duì)低端機(jī)不友好馬上能看出來(lái)。另外建議建一個(gè)啟動(dòng)性能回歸看板每個(gè)版本發(fā)布后自動(dòng)比對(duì)。它的價(jià)值在于當(dāng)你下次再改某項(xiàng)功能時(shí)能第一時(shí)間發(fā)現(xiàn)“這個(gè)版本給啟動(dòng)路徑加了 50 毫秒”而不是等到用戶反饋?zhàn)儾钪蟛抛凡?。我現(xiàn)在的工作習(xí)慣是任何啟動(dòng)優(yōu)化改動(dòng)必須附帶三類(lèi)數(shù)據(jù)——固定基線機(jī)上的前后對(duì)比、啟動(dòng)任務(wù)鏈路各分段時(shí)間、線上灰度后的分位值和穩(wěn)定性指標(biāo)。拿不出這三樣就不要說(shuō)自己優(yōu)化了啟動(dòng)。啟動(dòng)性能是一個(gè)長(zhǎng)期維護(hù)的地基工程不是某一次上線完成就結(jié)束的事情。