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