我自己這些年做App性能治理最頭疼的往往不是優(yōu)化本身而是找不準(zhǔn)數(shù)據(jù)來源。CPU飆到多少算異常內(nèi)存里的PSS到底該怎么看線上用戶反饋“用著用著就卡頓”我這邊連個(gè)像樣的曲線都拿不出來——這種狀態(tài)相信不少轉(zhuǎn)做專項(xiàng)性能的開發(fā)者都經(jīng)歷過。這篇文章把我在Android和iOS兩條線上實(shí)際跑過的監(jiān)測(cè)工具做了一次完整盤點(diǎn)覆蓋IDE自帶工具、命令行、開源庫、系統(tǒng)框架和自動(dòng)化腳本。準(zhǔn)備分六個(gè)部分講先是監(jiān)測(cè)指標(biāo)本身的認(rèn)知然后Android、iOS分別盤工具再講幾個(gè)關(guān)鍵數(shù)據(jù)的讀法最后落到專項(xiàng)測(cè)試和常見坑位上。適合剛接手性能監(jiān)控的開發(fā)、測(cè)試也適合想搭一套低成本監(jiān)測(cè)體系的技術(shù)負(fù)責(zé)人讀完可以直接按清單落地。1. 盤點(diǎn)前的關(guān)鍵認(rèn)知CPU與內(nèi)存監(jiān)測(cè)到底在監(jiān)控什么1.1 用戶視角的“卡”和工程師視角的數(shù)據(jù)經(jīng)常不同步用戶說“這個(gè)App很卡”他感知到的是掉幀、點(diǎn)擊無響應(yīng)、App被系統(tǒng)殺掉重開。但落到CPU和內(nèi)存監(jiān)測(cè)上我們看到的往往是另外一套東西某段時(shí)間CPU使用率超過80%或者PSS內(nèi)存持續(xù)增長、遲遲不回落。這兩者不是天然對(duì)應(yīng)的。CPU高不一定肉眼可見的卡比如后臺(tái)批量壓縮圖片頁面主線程可能根本不受影響內(nèi)存大也不一定馬上崩Android系統(tǒng)對(duì)“內(nèi)存壓力”有很長的容忍期等它真正開始?xì)⑦M(jìn)程時(shí)你才感受到后果。所以盤點(diǎn)工具之前先要把目標(biāo)定清楚你是為了找卡頓根因還是為了控內(nèi)存上限還是為了發(fā)現(xiàn)泄漏工具選型完全不一樣。我的習(xí)慣是先把目標(biāo)拆成三類。第一類是定位問題需要可以回溯的函數(shù)調(diào)用棧和內(nèi)存分配棧典型工具是Android Profiler和Instruments第二類是持續(xù)觀測(cè)需要低開銷、長時(shí)間采樣的指標(biāo)典型工具是Perfetto和MetricKit第三類是自動(dòng)化回歸需要能在CI里跑出對(duì)比數(shù)據(jù)的腳本方案。一篇文章很難同時(shí)覆蓋三類細(xì)節(jié)但這篇的每個(gè)工具會(huì)標(biāo)清楚用途邊界方便你按場(chǎng)景取用。1.2 CPU監(jiān)測(cè)不只看占用率還要看線程調(diào)度和調(diào)用棧不少剛?cè)腴T性能的同學(xué)有個(gè)習(xí)慣開個(gè)系統(tǒng)監(jiān)視器看到CPU 40%就覺得“正?！笨吹?5%就覺得“高了”。這種判斷在移動(dòng)端會(huì)誤導(dǎo)人——現(xiàn)在的CPU是多核架構(gòu)一顆大核跑到頂和八顆核全部滿載體現(xiàn)出來的占用率完全不同前端體感也完全不同。用生活類比來講CPU占用率像一棟辦公樓里亮燈的工位比例。你只知道亮燈多還是少但不知道哪些人真正在干活、哪些人是空轉(zhuǎn)更不知道哪條主干道在堵車。移動(dòng)端實(shí)際出問題的往往是單線程或單核的調(diào)度延遲主線程被一個(gè)耗時(shí)任務(wù)占住其它事情都排它后面。這時(shí)整體CPU占用率可能只有30%界面已經(jīng)卡到不行。所以CPU監(jiān)測(cè)有三個(gè)層次最淺的是進(jìn)程占用率只能做趨勢(shì)觀察稍深的是線程級(jí)占用率能看出哪個(gè)線程在忙再深一層是采樣調(diào)用棧能看到忙的時(shí)候CPU到底在跑哪段代碼。工具盤點(diǎn)里凡是能采樣調(diào)用棧的我標(biāo)了“定位專用”只能給占用率的我標(biāo)了“趨勢(shì)觀測(cè)”。定位問題和排查問題用的工具級(jí)別完全不同這也是很多團(tuán)隊(duì)工具買了不少、問題還是查不出來的原因。1.3 內(nèi)存監(jiān)測(cè)的維度比想象中多別只盯著“已用內(nèi)存”那個(gè)數(shù)內(nèi)存監(jiān)測(cè)比CPU更容易被誤讀。手機(jī)自己的存儲(chǔ)空間很大而App的進(jìn)程通常被分配了專用內(nèi)存空間但其中很多是“共享”和“可回收”的。單純看系統(tǒng)剩余內(nèi)存來判斷App有沒有問題就像數(shù)倉庫里還剩多少紙箱卻不看這批貨里有多少是自家租的、多少是別人暫時(shí)寄放的。專業(yè)一點(diǎn)的監(jiān)控一般分三個(gè)維度。維度一是進(jìn)程的RSS它表示進(jìn)程實(shí)際占用的物理內(nèi)存頁數(shù)包含共享庫被多進(jìn)程共用后重復(fù)計(jì)算的部分這個(gè)數(shù)字通常會(huì)偏“虛胖”維度二是PSS它把共享內(nèi)存按進(jìn)程數(shù)量平分后再分配到每個(gè)進(jìn)程頭上是Android系統(tǒng)評(píng)判進(jìn)程大小最常用的口徑維度三是VSS它基本只是進(jìn)程地址空間大小除了一些極端場(chǎng)景沒人認(rèn)真看它。再往細(xì)了分Android側(cè)還分Java堆、Native堆、代碼段、棧、圖形緩沖等iOS側(cè)有物理內(nèi)存足跡、虛擬內(nèi)存、壓縮內(nèi)存等概念。工具給出來的每一個(gè)數(shù)字都有統(tǒng)計(jì)口徑如果你拿不同工具的數(shù)字去對(duì)接同一份報(bào)告很容易牛頭不對(duì)馬嘴。我后面專門用一節(jié)來講這些字段怎么讀這比單純背命令更有用。2. Android平臺(tái)從IDE到命令行的完整監(jiān)測(cè)梯隊(duì)2.1 Android Studio Profiler開發(fā)期最直觀的CPU與內(nèi)存在線觀測(cè)Android Studio自帶Profiler依然是開發(fā)期最省事的入口。它不需要額外配置Android Studio打開Profiler窗口選擇已經(jīng)運(yùn)行的App進(jìn)程就能看到CPU、內(nèi)存、網(wǎng)絡(luò)、能耗四條實(shí)時(shí)曲線。CPU模板適合看“當(dāng)前忙不忙”內(nèi)存模板則會(huì)把Java堆、Native堆、Graphics、Stack、Code等分塊展示初始定位問題很快。但要注意它和線上用戶跑的環(huán)境并不完全一樣模擬器和真機(jī)調(diào)度策略不同Profiler本身還會(huì)占用額外CPU和數(shù)據(jù)上報(bào)所以它更適合開發(fā)期說服自己“這里確實(shí)有問題”不建議拿它出周報(bào)。我在實(shí)際項(xiàng)目里的用法是定位到一個(gè)具體操作時(shí)比如“點(diǎn)開商品詳情頁再返回”點(diǎn)擊CPU錄制錄個(gè)幾秒生成火焰圖看哪些函數(shù)吃掉了大量CPU時(shí)間。如果火焰圖里出現(xiàn)明顯的長時(shí)間函數(shù)調(diào)用比如圖片主線程解碼就去優(yōu)化它。這種“操作路徑火焰圖”的排查法比看整體占用率精準(zhǔn)得多。有一點(diǎn)申請(qǐng)后需留意Android 10以上支持對(duì)release包開啟profileable模式這樣可以模擬線上混淆和release優(yōu)化后的性能。構(gòu)建時(shí)在AndroidManifest里加android:profileabletrue或者在debug包和release包之間對(duì)比能避免“debug下正常、release下崩”的尷尬。2.2 adb命令三件套top、dumpsys meminfo、Perfetto命令行工具適合不上IDE、人在遠(yuǎn)程或自動(dòng)化跑批量的場(chǎng)景。Android平臺(tái)上我最常用的三條命令是top、dumpsys meminfo和Perfetto。第一條是top用于快速看進(jìn)程級(jí)CPU和內(nèi)存實(shí)時(shí)狀況adb shell top -m 20 -n 1 -o PID,PCPU,RSS,NAME-m 20表示只顯示前20個(gè)進(jìn)程-n 1表示只掃一次-o指定輸出列。它給出的RSS是前面說過的“虛胖”口徑不能直接和PSS混用但勝在一句話能拿到全機(jī)狀態(tài)。第二條是dumpsys meminfo專門看單個(gè)進(jìn)程內(nèi)存明細(xì)adb shell dumpsys meminfo com.demo.package輸出里最有價(jià)值的部分是“App Summary”里面列出Java Heap、Native Heap、Code、Stack、Graphics等分部占用以及TOTAL PSS。這個(gè)數(shù)字直接決定Android系統(tǒng)Memory Trim時(shí)的殺進(jìn)程優(yōu)先級(jí)也是做線上內(nèi)存水位線監(jiān)控最常用的字段。第三條是Perfetto它是Systrace的接棒者也是現(xiàn)在Android性能追蹤的標(biāo)配。命令行采集簡單adb shell perfetto --time 15s -o /data/misc/perfetto-traces/trace adb pull /data/misc/perfetto-traces/trace然后把這個(gè)trace文件拖到ui.perfetto.dev里打開就能看到CPU調(diào)度片段、線程狀態(tài)、內(nèi)存生命周期、binder調(diào)用等非常詳細(xì)的信息。Perfetto的學(xué)習(xí)曲線比前兩條命令陡但排查“線程間互相等待”“CPU調(diào)頻跟不上”這類疑難問題它是真正能給出證據(jù)的工具。我通常只在top和dumpsys定位到大概問題后再用Perfetto抓更深的trace。2.3 內(nèi)存泄漏與對(duì)象引用檢測(cè)LeakCanary與Memory Profiler分工Android側(cè)的“找泄漏”有兩套工具互補(bǔ)。LeakCanary適合做持續(xù)性的動(dòng)態(tài)監(jiān)測(cè)它在Debug包中集成后一旦發(fā)現(xiàn)Activity或Fragment銷毀后仍被強(qiáng)引用持有就會(huì)落下通知并把引用鏈展示出來。這套東西不需要你主動(dòng)操作適合團(tuán)隊(duì)回歸。它在分析時(shí)依賴Shark庫直接讀取堆快照在Native層注入判斷非常省事。Android Studio的Memory Profiler則適合主動(dòng)調(diào)查。你可以手動(dòng)觸發(fā)一堆操作后點(diǎn)擊Memory視圖里的垃圾回收按鈕再對(duì)比堆占用是否回落到基線。如果回不去很可能有泄漏再點(diǎn)“Dump Java heap”生成堆轉(zhuǎn)儲(chǔ)用“Analyzer Tasks”里的“Detect Leaked Activity”跑一遍通常直接能提示“某個(gè)Activity實(shí)例還活著”。這兩者的分工我總結(jié)為一句話LeakCanary管“團(tuán)隊(duì)日常防線”Memory Profiler管“專項(xiàng)攻堅(jiān)抽樣”。實(shí)際項(xiàng)目里我見過有人依賴LeakCanary就再也不管內(nèi)存直到線上內(nèi)存水位一路上漲——其實(shí)LeakCanary默認(rèn)只在Debug下生效線上發(fā)布包并沒有它。所以線上還需要另外一套監(jiān)控這個(gè)話題放到第五節(jié)再展開。3. iOS平臺(tái)Instruments與MetricKit的組合玩法3.1 Instruments的四個(gè)標(biāo)配模板Activity Monitor、Allocations、Leaks、Time ProfileriOS上做性能分析的入口是Xcode里的Instruments。它自帶的模板很多但日常做CPU與內(nèi)存監(jiān)測(cè)我長期只固定用四個(gè)其余大多是這四個(gè)的變體。Activity Monitor模板用來整體看進(jìn)程的CPU占用和內(nèi)存占用適合先抓“哪個(gè)進(jìn)程在頂”也可以配置成直接動(dòng)態(tài)選擇目標(biāo)App。Allocations模板用來記錄內(nèi)存分配可以看到對(duì)象分配的類型、數(shù)量和調(diào)用棧是排查增長問題的關(guān)鍵比如內(nèi)存中圖片緩存不斷累積。Leaks模板專抓循環(huán)引用和泄露對(duì)象配合一個(gè)“旋轉(zhuǎn)一定角度再返回”的操作路徑反復(fù)測(cè)試往往能抓出不少ViewController沒被釋放的經(jīng)典問題。Time Profiler模板則按時(shí)段采樣CPU調(diào)用棧類似Android Profiler的火焰圖按耗時(shí)從大到小排序找熱點(diǎn)函數(shù)。這四件套的操作節(jié)奏通常是先用Activity Monitor確認(rèn)整體趨勢(shì)再用Time Profiler定位CPU熱點(diǎn)用Allocations定位內(nèi)存增長最后用Leaks確認(rèn)是否有真正的泄漏。一個(gè)實(shí)操建議錄制時(shí)別急著全程跑改成“開始錄制-人工執(zhí)行操作-場(chǎng)景結(jié)束-點(diǎn)stop”。時(shí)間線越長越難定位把操作路徑切得短一點(diǎn)后面分析的工作量會(huì)驟減。3.2 Xcode Memory Graph不打開Instruments也能看的對(duì)象關(guān)系圖Xcode從大概iOS 12開始提供的Memory Graph調(diào)試器是個(gè)被很多人忽略的好工具。它的入口在Debug工具欄里點(diǎn)擊那個(gè)看起來像三個(gè)圓圈疊在一起的按鈕就能在調(diào)試中看到當(dāng)前進(jìn)程的對(duì)象圖布局類似“一個(gè)矩形一個(gè)對(duì)象對(duì)象間的實(shí)線引用關(guān)系”。日常用法是把一個(gè)ViewController push進(jìn)導(dǎo)航棧再pop然后點(diǎn)擊內(nèi)存圖左下角搜索這個(gè)類名。如果類實(shí)例仍然存在它能直接顯示是誰還在引用它比如一條保存在單例里的回調(diào)閉包或是一個(gè)沒有置空的定時(shí)器屬性。這個(gè)能力比Instruments里的定制Leak檢測(cè)更直觀適合在開發(fā)階段先快速過濾明顯問題。要注意的是Memory Graph并不能代替Instruments做統(tǒng)計(jì)數(shù)據(jù)它偏向?qū)ο箨P(guān)系圖重點(diǎn)解釋“為什么會(huì)活著”但不解釋“內(nèi)存整體漲了多少”。所以在我的工作流里Memory Graph是“定位異常引用”的放大鏡Instruments是“做量化對(duì)比”的標(biāo)尺兩者的使用時(shí)機(jī)并不相同。3.3 MetricKit把性能監(jiān)控搬到線上而不是只在連接電腦時(shí)才看Xcode和Instruments發(fā)作的前提是你有一臺(tái)連著電腦的測(cè)試機(jī)但線上真實(shí)用戶跑起來是什么樣它們完全無感知。蘋果提供的MetricKit就是為這種情況準(zhǔn)備的它讓App在用戶設(shè)備上采集性能指標(biāo)然后定期以報(bào)告形式送回開發(fā)端。接入方法不復(fù)雜在App啟動(dòng)時(shí)注冊(cè)一個(gè)MXMetricManager.MetricManager.shared.addSubscriber(...)的訂閱方然后實(shí)現(xiàn)回調(diào)就能收到包括CPU、內(nèi)存、磁盤I/O、啟動(dòng)時(shí)長、掉幀等多類數(shù)據(jù)。這些是蘋果統(tǒng)一采集并標(biāo)準(zhǔn)化后匯總的不需要我們?cè)贏pp內(nèi)自己架哨兵隱私和電量影響也較小。它的局限是數(shù)據(jù)粒度偏“匯總型”適合做線上大盤和版本對(duì)比不太適合單獨(dú)定位某個(gè)用戶的某次具體問題。所以我的建議是MetricKit作為線上自動(dòng)化監(jiān)控的底板一旦它發(fā)現(xiàn)某版本CPU中位數(shù)明顯偏高再回到Xcode Instruments復(fù)現(xiàn)問題、采集更詳細(xì)的現(xiàn)場(chǎng)。線上報(bào)警和線下定位按理應(yīng)該是一套聯(lián)動(dòng)流程。4. 數(shù)據(jù)含義拆解為什么同一款A(yù)pp在兩個(gè)平臺(tái)看到的數(shù)字不一樣4.1 Android的Java堆、Native堆和“圖形內(nèi)存”到底代表什么打開dumpsys meminfo的輸出很多人會(huì)被那一排字段嚇到。其實(shí)歸類后一套邏輯就清楚了Java堆是經(jīng)過虛擬機(jī)和垃圾回收器管理的對(duì)象內(nèi)存平常new出來的普通對(duì)象基本都在這里Native堆是直接通過C/C分配的內(nèi)存比如Bitmap像素?cái)?shù)據(jù)、三方引擎內(nèi)部緩沖、部分網(wǎng)絡(luò)庫的緩沖區(qū)Code是App代碼和資源映射占的內(nèi)存Stack是線程棧Graphics是圖形緩沖和GPU相關(guān)內(nèi)存這塊數(shù)字經(jīng)常被忽略但它常常是吃內(nèi)存大戶。一個(gè)常見誤判是只盯著Java Heap看認(rèn)為Java Heap沒漲就沒問題。但實(shí)際項(xiàng)目里Bitmap在較新版本上大部分計(jì)算在Graphics和Native層如果這里持續(xù)上漲Java Heap反而很穩(wěn)。所以我們看內(nèi)存報(bào)告時(shí)我習(xí)慣先把“App Summary”里的TOTAL PSS拉出來當(dāng)?shù)谝粰谠侔袹ava Heap/Gaphics/Native這幾類單列做趨勢(shì)單列之間互相驗(yàn)證才能防漏。平臺(tái)區(qū)分也在這Android允許同一個(gè)Library被不同進(jìn)程通過共享內(nèi)存映射所以“Private Dirty”和“Shared Dirty”等術(shù)語頻繁出現(xiàn)。PSS會(huì)把共享部分按進(jìn)程數(shù)均攤所以我們說“某App占了多少內(nèi)存”最嚴(yán)謹(jǐn)?shù)牧炕趶绞荘SS不是RSS更不是系統(tǒng)剩余內(nèi)存減出來的差值。4.2 iOS的phys_footprint、vsz與“壓縮內(nèi)存”不同在哪iOS側(cè)的內(nèi)存術(shù)語和Android完全不同但在社區(qū)討論里經(jīng)常被混著用。物理內(nèi)存足跡phys_footprint是iOS判斷進(jìn)程內(nèi)存壓力的核心指標(biāo)它把App的內(nèi)存壓縮、IOAccelerator、TASK_VM_INFO等匯總成一個(gè)可以被系統(tǒng)評(píng)估的值。Apple官方和MetricKit里的內(nèi)存報(bào)告基本都圍繞這個(gè)字段展開?！疤摂M內(nèi)存大小”則更像一個(gè)邏輯地址空間的大小iOS上不同的線程、庫、二進(jìn)制映射都會(huì)增大它但它不代表真實(shí)的物理占用。部分開發(fā)者看到模擬器監(jiān)控里vsz很大就被嚇到其實(shí)這是正?，F(xiàn)象虛擬內(nèi)存和物理占用不是一回事。另一個(gè)概念是壓縮內(nèi)存系統(tǒng)在內(nèi)存吃緊時(shí)會(huì)對(duì)符合條件的頁進(jìn)行壓縮壓縮后的數(shù)據(jù)在footprint里有一部分計(jì)入但壓縮本身也是CPU開銷。這就是為什么你常?？吹侥承〢pp內(nèi)存曲線明顯下降性能卻變差了——它是在靠CPU換內(nèi)存。從工具上看Instruments的Activity Monitor會(huì)把Memory顯示為某個(gè)數(shù)值底部還能看到Compressed Memory選項(xiàng)。Memory Graph里選中某個(gè)對(duì)象也能看到它在某個(gè)區(qū)域里。你要盯的始終是footprint而不是籠統(tǒng)的“App占用內(nèi)存”。4.3 CPU采樣的“采樣”和“插樁”決定了優(yōu)化精度CPU數(shù)據(jù)的生成方式也影響準(zhǔn)確度。Instruments的Time Profiler是定時(shí)采樣每隔一小段時(shí)間記錄當(dāng)前CPU正在執(zhí)行的調(diào)用棧然后通過統(tǒng)計(jì)頻率推算出熱點(diǎn)。這種方式的優(yōu)點(diǎn)是開銷低缺點(diǎn)是短耗時(shí)的一閃而過函數(shù)可能完全被漏采所以它適合找“大頭”不適合找秒級(jí)以內(nèi)的毛刺問題。Android Profiler的CPU錄制更接近Trace事件的插樁方式它會(huì)更精確地記錄每次函數(shù)調(diào)用的開始結(jié)束時(shí)間代價(jià)是錄制時(shí)對(duì)性能的影響更大。Perfetto的調(diào)度事件屬于系統(tǒng)內(nèi)核打點(diǎn)可以看到線程狀態(tài)切換但對(duì)用戶態(tài)的代碼調(diào)用關(guān)系提供的信息相對(duì)有限。一句話總結(jié)要回答“哪段函數(shù)最耗時(shí)”用采樣型工具就夠要回答“突然卡頓的那幾毫秒發(fā)生了什么”盡量用插樁或Trace事件并把Perfetto的調(diào)度信息一起帶上。組會(huì)里最尷尬的事就是采樣頻率不夠復(fù)現(xiàn)時(shí)又沒抓到你想抓的那一幀。工具選型里務(wù)必將這個(gè)差異納入考慮。5. 專項(xiàng)測(cè)試與自動(dòng)化讓監(jiān)控跑成流水線5.1 一條adb循環(huán)腳本實(shí)現(xiàn)穩(wěn)定性曲線的低成本采集性能測(cè)試最枯燥的部分是長時(shí)間觀察。線上問題往往不會(huì)在手工點(diǎn)兩下后立刻出現(xiàn)需要跑10分鐘、半小時(shí)甚至更久。手工盯屏幕完全不現(xiàn)實(shí)所以我的第一建議是哪怕不用任何工具也要先寫一條adb循環(huán)腳本把數(shù)據(jù)錄下來。以下腳本可以按實(shí)際項(xiàng)目改包名和時(shí)長#!/bin/bash PACKAGEcom.demo.package DURATION300 START$(date %s) while [ $(($(date %s) - $START)) -lt $DURATION ]; do adb shell top -n 1 -o PID,PCPU,RSS,NAME | grep $PACKAGE cpu.log adb shell dumpsys meminfo $PACKAGE | grep -E TOTAL PSS|Java Heap|Native Heap mem.log sleep 2 done跑完后你會(huì)得到兩份文本日志接下來可以導(dǎo)入Excel或?qū)憘€(gè)小Python腳本畫曲線。這樣不用Perfetto也能看出內(nèi)存趨勢(shì)是“穩(wěn)步上漲”“鋸齒波”還是“突然跳變”。鋸齒波通常是正常的對(duì)象反復(fù)創(chuàng)建穩(wěn)步上漲極有可能是泄漏或緩存不清突然跳變可能是某次資源加載任務(wù)。這個(gè)腳本雖然原始卻是我做性能回歸時(shí)利用率最高的工具。要注意的是top里的RSS和dumpsys里的PSS不能在同一張圖里直接比較我在腳本里把它們拆開了分析時(shí)分開看。另外長時(shí)間腳本最好帶上adb shell dumpsys batterystats一起記錄這樣后續(xù)分析還能順便解釋CPU升高和電量消耗的關(guān)系。5.2 iOS回歸xctrace與CI里可接受的采樣方式iOS側(cè)的自動(dòng)化相比Android要麻煩一些主要原因是命令行的權(quán)限和采樣的隱蔽性不如adb豐富。但有一條路徑可以走通用xctrace record在命令行采集Instruments模板數(shù)據(jù)。一個(gè)參考格式是xcrun xctrace record --template Time Profiler --device 你的設(shè)備名 --output /tmp/app_trace.trace --launch -- com.demo.package這樣可以在不打開Xcode圖形界面的情況下啟動(dòng)App并采集一段時(shí)間內(nèi)的CPU調(diào)用棧。采集完再解析trace文件就能把數(shù)據(jù)傳給報(bào)告或分析腳本。這個(gè)方案適合在固定測(cè)試機(jī)上跑回歸不適合大規(guī)模線上收集線上仍交給MetricKit。在本地CI里我更關(guān)心的是趨勢(shì)包對(duì)比同時(shí)跑兩遍同一個(gè)操作路徑一遍打基線版本一遍打新版本然后比較兩次trace里主要方法的采樣時(shí)長。手工做過一兩次后會(huì)發(fā)現(xiàn)這比“看代碼猜性能”效率高得多。哪怕是粗略對(duì)比也能在提交前就發(fā)現(xiàn)某次改動(dòng)把列表滑動(dòng)幀時(shí)間拉長了一大截。5.3 線上監(jiān)控APM SDK與自采樣的取舍線上用戶設(shè)備千差萬別只有在線上才能看到真實(shí)的首屏分布、CPU高負(fù)載比例和系統(tǒng)殺進(jìn)程情況。常見的APM SDK包括Sentry、Firebase Performance等主流的移動(dòng)開發(fā)平臺(tái)也都有各自的性能監(jiān)控產(chǎn)品。它們可以在App內(nèi)定期采當(dāng)前進(jìn)程的CPU和內(nèi)存狀態(tài)上報(bào)到后臺(tái)做水位線和版本對(duì)比。不過用現(xiàn)成SDK之前先想清楚一個(gè)核心問題上報(bào)頻率和用戶隱私的平衡。CPU采樣太密SDK自己就是耗電和耗CPU的元兇采樣太疏曲線失去參考價(jià)值。比較合理的做法是按場(chǎng)景采樣比如只在關(guān)鍵頁面切換后采集或只在某條網(wǎng)絡(luò)請(qǐng)求完成之后采一條CPU快照。上報(bào)頻率按版本灰度逐步放量先灰度10%用戶確認(rèn)功耗沒有明顯上升再放大比例。此外如果你的App里有大量Native代碼第三方SDK默認(rèn)采到的只是整個(gè)進(jìn)程的占用率很難區(qū)分是Native庫還是Java層引入的。這時(shí)可以在自建采樣里額外記錄線程名稱把“渲染線程”“IO線程”“網(wǎng)絡(luò)線程”區(qū)分出來。線上報(bào)告能區(qū)分線程才算有一點(diǎn)點(diǎn)可用性。6. 實(shí)測(cè)手冊(cè)常見誤判、隱藏坑位與排查速查表6.1 常見誤判Profiler開著測(cè)、模擬器數(shù)字倒掛、Debug與Release不一致先說我見到的頭號(hào)誤判開著Android Studio Profiler或Instruments錄制去測(cè)性能數(shù)據(jù)然后把結(jié)果直接作為“App真實(shí)性能”寫入報(bào)告。這兩個(gè)工具本身會(huì)占用一定的CPU和內(nèi)存錄制得越密干擾越大。如果是插樁型錄制JIT編譯行為也可能被改變。所以它們最適合定位問題方向不適合出精確的基準(zhǔn)數(shù)字。第二個(gè)高頻誤判是模擬器和真機(jī)對(duì)比。模擬器共享宿主機(jī)CPU調(diào)度模型和真機(jī)大核小核的結(jié)構(gòu)完全不同跑出來的CPU占用率和內(nèi)存壓縮行為往往會(huì)和真機(jī)倒掛模擬器表現(xiàn)正常的場(chǎng)景真機(jī)上可能一直卡頓。我的經(jīng)驗(yàn)是做趨勢(shì)分析可以用模擬器但任何系統(tǒng)性結(jié)論必須到真機(jī)上復(fù)核。第三個(gè)誤判是把Debug版的性能當(dāng)Release版。Debug模式下代碼未混淆、未優(yōu)化系統(tǒng)中還有大量日志輸出和調(diào)試信息CPU和內(nèi)存占用都會(huì)明顯偏高。線上問題的復(fù)現(xiàn)如果只在Debug上成立先不要急著改代碼打開profileable的Release配置再跑一遍很多時(shí)候會(huì)發(fā)現(xiàn)根本不是同一個(gè)問題。6.2 容易被忽略的坑GC延遲、系統(tǒng)內(nèi)存壓縮、日志采樣上限另一個(gè)在實(shí)戰(zhàn)中耗費(fèi)過時(shí)間的坑是系統(tǒng)垃圾回收帶來的延遲。Java堆頻繁增長到水位線后系統(tǒng)會(huì)自動(dòng)觸發(fā)GC此時(shí)主線程經(jīng)常會(huì)被暫停表現(xiàn)為瞬時(shí)卡頓。這種卡頓用CPU占用率看往往不高甚至還會(huì)出現(xiàn)內(nèi)存曲線掉頭向下的“假平穩(wěn)”。排查時(shí)一定要搭配看GC日志或Perfetto的GC片段否則你會(huì)盯著CPU火焰圖卻找不到真正兇手。iOS側(cè)最容易被忽略的是內(nèi)存壓縮進(jìn)程內(nèi)存上限逼近時(shí)系統(tǒng)會(huì)壓縮舊頁面來騰出可用空間表面上看內(nèi)存曲線不高但CPU會(huì)多出大量解壓、壓縮的工作。在Instruments里同時(shí)對(duì)比“Compressed Memory”和CPU占用率這類問題會(huì)更容易看清。還有一個(gè)偏工具層面的坑Perfetto和Instruments的長trace輸出會(huì)非常大動(dòng)不動(dòng)幾百M(fèi)B甚至上GB。帶采樣頻率的文件很容易在傳輸時(shí)被截?cái)嗷蛘叽蜷_后卡死。我建議長實(shí)操場(chǎng)景分段錄制每段控制在10到20秒之間明確標(biāo)記路徑然后再另跑一條全局趨勢(shì)的采樣顆粒度粗一點(diǎn)也沒事。兩段數(shù)據(jù)情景不同信息互補(bǔ)就不會(huì)因?yàn)橐粋€(gè)文件過大而丟掉全部線索。6.3 面對(duì)實(shí)際現(xiàn)場(chǎng)的工具速查表等于是自救清單最后把這套工具整理成一張表按“我想知道什么 - 用什么工具 - 注意什么”的路徑對(duì)照著參考監(jiān)測(cè)需求Android側(cè)推薦iOS側(cè)推薦主要注意點(diǎn)整體趨勢(shì)觀測(cè)adb top、PerfettoInstruments Activity Monitor只能看趨勢(shì)不能直接定位調(diào)用棧定位CPU熱點(diǎn)函數(shù)Android Profiler CPU錄制Instruments Time Profiler采樣型工具可能漏短耗時(shí)熱點(diǎn)定位內(nèi)存分配增長Android Profiler Dump Java heapInstruments Allocations需要對(duì)比前后兩輪堆轉(zhuǎn)儲(chǔ)檢測(cè)泄漏與引用鏈LeakCanary、Memory GraphInstruments Leaks、Xcode Memory Graph線上默認(rèn)不生效需單獨(dú)處理系統(tǒng)級(jí)trace回溯PerfettoInstruments配合系統(tǒng)Trace長trace文件要注意分段采集線上周期上報(bào)自建采樣或APM SDKMetricKit注意頻率和隱私邊界灰度放量我在實(shí)操項(xiàng)目里養(yǎng)成的習(xí)慣是拿這張表反過來倒推現(xiàn)象先歸類再選工具不要打開一個(gè)工具就什么信息都想抓。性能監(jiān)控生態(tài)發(fā)展到2026年已經(jīng)比較成熟但真正拉開差距的并不是工具本身而是你對(duì)工具輸出數(shù)據(jù)的理解方式。CPU和內(nèi)存不是兩個(gè)孤立的指標(biāo)它們經(jīng)?；ハ酄恳獌?nèi)存壓縮帶來CPU上升GC卡頓引發(fā)掉幀CPU過載導(dǎo)致線程調(diào)度延遲。多數(shù)據(jù)源交叉驗(yàn)證比在單一工具里死磕更有價(jià)值。把這些基礎(chǔ)工具用扎實(shí)后續(xù)再上更重的自動(dòng)化或AI輔助分析時(shí)你的判斷力也能跟得上。