優(yōu)化要掌握分析方法

在具體講卡頓工具前，你需要了解一些基礎(chǔ)知識，它們主要都和CPU相關(guān)。造成卡頓的原因可能有千百種，不過最終都會反映到CPU時間上。我們可以把CPU時間分為兩種：用行內(nèi)核態(tài)系統(tǒng)調(diào)用所消耗的時間，包括I/O、鎖、中斷以及其他系統(tǒng)調(diào)用的時間。CPU我們先來簡單講講CPU的性能，考慮到功耗、體積這些因素，移動設(shè)備和PC的CPU會有不少的差異。但近年來，CPU的性能也在向PC快速靠攏，Mate20的“麒麟980”和 XS的“A12”已經(jīng)率先使用領(lǐng)先PC的7納米工藝。評價一個CPU的性能，需要看主頻、數(shù)、緩存等參數(shù)，具體表現(xiàn)出來的是計算能力和980”采用三級能效架構(gòu)，22.6GHzA76大核+2個1.92GHz主頻的A76大核+4個1.8GHz主頻的A55小核。相比之下，“A12”使用2個性能+4個能效的架構(gòu)，這樣設(shè)計主要是為了在日常低負(fù)荷工作時，使用低頻更加節(jié)省電量。在開發(fā)過程中，我們可以通過下面的方法獲得設(shè)備的CPU信息。//獲取CPUcat3//獲取某個CPUcat隨著機(jī)器學(xué)習(xí)的興起，現(xiàn)代不僅帶有強(qiáng)大的GPU，還配備了專門為神經(jīng)網(wǎng)絡(luò)計算打造的PU（eraletworkProcessingUit）?！癆12”就使用了八的PU，每秒可執(zhí)行五萬億次運算。從CPU到GPU再到AI，隨著CPU整體性能的飛躍，醫(yī)療診斷、圖像超清化等一些AI應(yīng)用場景也可以在移動端更好地落地。最近邊緣計算也越來越多的被提及，我們希望可以更大程度地利用移動端的計算能力來降低高昂的服務(wù)器成本。也因此在開發(fā)過程中，我們需要根據(jù)設(shè)備CPU性能來“看菜下飯”，例如線程池使用線程數(shù)根據(jù)CPU的數(shù)，一些高級的AI功能只在主頻比較高或者帶有NPU的設(shè)備開啟。拓展了那么多再回到前面我講的CPU時間，也就是用戶時間和系統(tǒng)時間。當(dāng)出現(xiàn)卡頓問題的時候，應(yīng)該怎么去區(qū)分究竟是我們代碼的問題，還是系統(tǒng)的問題？用戶時間和系統(tǒng)時間可以給我們哪些線索？這里還要集合兩個非常重要的指標(biāo)，可以幫助我們做判斷。出現(xiàn)卡頓問題后，首先我們應(yīng)該查看CPU的使用率過/proc/statCPU/proc/[pid]/stat可以得到某個進(jìn)程的CPU使用情況。statCPULinux 如果CPU使用率長期大于60%，表示系統(tǒng)處于繁忙狀態(tài)，就需要進(jìn)一步分析用戶時間和系統(tǒng)時間的比例。對于普通應(yīng)用程序，系統(tǒng)時間不會長期高于30%，如果超過這個值，我們就應(yīng)該進(jìn)一步檢查是I/O過多，還是其他的系統(tǒng)調(diào)用問題。Android是站在Linux巨人的肩膀上，雖然做了不少修改也砍掉了一些工具，但還是保留了很多有用的工具可以協(xié)助我們更容易地排查問題，這里我給你介紹幾個常用令。例如，top命令可以幫助我們查看哪個進(jìn)程是CPU的消耗大戶；vmstat命令可以實時動態(tài)監(jiān)視操作系統(tǒng)的虛擬內(nèi)存和CPU活動；strace命令可以某個進(jìn)程中所有的系統(tǒng)調(diào)用。CPUCPUCPU行的線程，把大量的時間浪費在上下文切換，我們知道每一次CPU上下文切換都需要刷新我們可以通過使用vmstat命令或者/proc/[pid]/schedstat文件來查看CPU上下文切主動上下文切換次數(shù)，因為線程無法獲取所需資源導(dǎo)致上下文切換，最普遍的是IO 上下文切換次數(shù)，線程被系統(tǒng)強(qiáng)制調(diào)度導(dǎo)致上下文切換，例如大量線程在搶占CPUse.statistics.iowait_count：IO IOuptimeCPU1515比如一個4核的CPU，如果當(dāng)前平均負(fù)載是8，這意味著每個CPU上有一個線程在運行，還有一個線程在等待。一般平均負(fù)載建議控制在“0.7×核數(shù)”以內(nèi)。100:02:39up7days,46min,02loadaverage:13.91,14.70,另外一個會影響CPU飽和度的是線程優(yōu)先級，線程優(yōu)先級會影響Android系統(tǒng)的調(diào)度策略，它主要由nice和cgroup類型共同決定。nice值越低，搶占CPU時間片的能力越CPUCPU關(guān)于線程優(yōu)先級，你需要注意是否存在高優(yōu)先級的線程空等低優(yōu)先級線程，例如主線程等待某個線程的鎖。從應(yīng)用程序的角度來看，無論是用戶時間、系統(tǒng)時間，還是等待CPU的調(diào)度，都是程序運行花費的時間?？赡苣銜X得按照上面各種Linux命令組合來排查問題太麻煩了，有沒有更簡單的、圖形化的操作界面呢？Traceview和systrace都是我們比較熟悉的排查卡頓的工具，從實現(xiàn)上第一個流派是instrument。獲取一段時間內(nèi)所有函數(shù)的調(diào)用過程，可以通過分析這段時間第二個流派是sample。有選擇性或者采用抽樣的方式觀察某些函數(shù)調(diào)用過程，可以通過這TraceviewAndroidRuntime函數(shù)調(diào)用的event，將函數(shù)運行的耗時和調(diào)用關(guān)系寫入trace文件中。由此可見，Traceview屬于instrument類型，它可以用來查看整個過程有哪些函數(shù)調(diào)用，1秒，開啟Traceview后可能會變成5秒，而且這些函數(shù)的耗時變化并不是成比例放大。在Android5.0之后，新增了startMethodTracingSampling方法，可以使用基于樣本的方式進(jìn)行分析，以減少分析對運行時的性能影響。新增了sample類型后，就需要我們無論是哪種的Traceview對release包支持的都不太好，例如無法反。其實trace文件的格式十分簡單，之前曾經(jīng)寫個一個小工具，支持通過map文件反trace。那在答案是有的，Uber開源的Nanoscope就能達(dá)到這個效果。它的實現(xiàn)原理是直接修改Android虛擬機(jī)源碼，在ArtMethod執(zhí)行和執(zhí)行結(jié)束位置增加埋點代碼，將所有的信息先寫到內(nèi)存，等到trace結(jié)束后才統(tǒng)一生成結(jié)果文件。在使用過程可以明顯感覺到應(yīng)用不會因為開啟Nanoscope而感到卡頓，但是trace結(jié)束生成結(jié)果文件這一步需要的時間比較長。另一方面它可以支持分析任意一個應(yīng)用，可用于做競需要自己刷ROM，并且當(dāng)前只支持Nexus6P，或者采用其提供的x86的內(nèi)存數(shù)組只能支持大約20秒左右的時間段。Uber寫了一系列自動化協(xié)助整個流程，使用起來還算簡單。Nanoscope作為基本沒有性能損耗的instrument工具，它非常適合做啟動耗時的自動化分析。Nanoscope生成的是符合Chrometracing規(guī)范的HTML文件。我們可以通過來實第一個是反。通過map自動反結(jié)果文件diff，自動分析差異實現(xiàn)定制化功能或者拿到更加豐富的信息，這個時候不得不使用定制ROM的方式。而Nanoscope恰恰是一個很好的工具，可以讓我們更方便地實現(xiàn)定制ROM，在后面啟動和I/O優(yōu)化里我還會提到類似的案例。systrace是Android4.1新增的性能分析工具。我通常使用systrace系統(tǒng)的I/O操作、CPU負(fù)載、Surface渲染、GC等。針，也就是在代碼里加了一些性能的埋點。Android在ftrace的基礎(chǔ)上封裝了atrace，并增加了特有的探針，例如Graphics、ActivityManager、DalvikVM、SystemServersystrace工具只能特定系統(tǒng)調(diào)用的耗時情況，所以它是屬于sample類型，而且性能由于系統(tǒng)預(yù)留了Trace.beginSection接口來應(yīng)用程序的調(diào)用耗時，那我們有沒有辦法在systrace上面自動增加應(yīng)用程序的耗時分析呢？劃重點了，我們可以通過編譯時給每個函數(shù)插樁的方式來實現(xiàn)，也就是在重要函數(shù)的和出口分別增加TracebeginSction和rac.endSetion。當(dāng)然出于性能的考慮，我們會過濾大部分指令數(shù)比較少的函數(shù)，這樣就實現(xiàn)了在sysrae基礎(chǔ)上增加應(yīng)用程序耗時的。通過這樣方式的好處有：耗時、線程鎖，GC耗時等。I/O，所以整個運行耗時systraceHTMLNanoscope那如果我們想分析NativeAndroid5.0新增了Simpleperf性能分析工具，它利用CPU的性能單元（PMU）提供的硬件perf。使用Simpleperf可以看到所有的Native代碼的耗時，有時候一些Android系統(tǒng)庫的調(diào)用對分析問題有比較大的幫助，例如加載dex、verifyclass的耗時Simpleperf同時封裝了systrace的功能，通過Android幾個版本的優(yōu)化，現(xiàn)AndroidMSimpleperfJava第二個階段：在AndroidO和以前，需要手動指定編譯OAT文件。AndroidPSimpleperfJava從這個過程可以看到還是比較看重這個功能，在AndroidStudio3.2也ProfilerSimpleperfSimpleperfsample目前除了Nanoscope之外的三個工具都只支持debugable的應(yīng)用程序，如果想測試release包，需要將測試機(jī)器root。對于這個限制，我們在實踐中會專門打出debugable的測試包，然后自己實現(xiàn)針對map的反功能。其中Simpleperf的反比較難實現(xiàn)，因為在函數(shù)聚合后會拋棄參數(shù)，無法直接對生成的HTML文件做處理。當(dāng)然我們也可以根據(jù)各個工具的實現(xiàn)思路，自己重新打造一套支持非debugable的自動化測試工具。選擇哪種工具，需要看具體的場景。我來匯總一下，如果需要分析Native代碼的耗時，可以選擇Simpleperf；如果想分析系統(tǒng)調(diào)用，可以選擇systrace；如果想分析整個程序執(zhí)行流程的耗時，可以選擇Traceview或者插樁版本的systrace。隨著Android版本的演進(jìn)，不僅提供了的性能分析工具，而且也在慢慢優(yōu)化現(xiàn)有工具的體驗，使功能更強(qiáng)大、使用門檻更低。而AndroidStudio則肩負(fù)另外一個重在AndroidStudio3.2的ProfilerSampleJavaMethods的功能類似于Traceview的sample類型。TraceJavaMethodsTraceviewinstrumentTraceSystemCalls的功能類似于systrace。SampleNative(APILevel26Simpleperf坦白來說，Profiler行，不過Profiler的確大大降低了開發(fā)者的使用門檻。CallCallChartTraceviewsystrace序來展示，適合用于分析整個流程的調(diào)用。舉一個最簡單的例子，A函數(shù)調(diào)用B函數(shù)，B函數(shù)調(diào)用C函數(shù)，循環(huán)三次，就得到了下面的CallChart。CallChart工作，比如是否存程間的鎖、主線程是否存在長時間的I/O操作、是否存在空閑等。FlameFlameChart也就是大名鼎鼎的火焰圖。它跟CallChart不同的是，F(xiàn)lameChart以一個全局的視野來看待一段時間的調(diào)用分布，它就像給應(yīng)用程序拍X光片，可以很自然地把時當(dāng)我們不想知道應(yīng)用程序的整個調(diào)用流程，只想直出哪些代碼路徑花費的CPU時間較焰圖發(fā)現(xiàn)耗時最多的是大量Java字符串的創(chuàng)建和拷貝，通過將實現(xiàn)轉(zhuǎn)為Native，最火焰圖還可以使用在各種各樣的維度，例如內(nèi)存、I/O的分析。有些內(nèi)存可能非常緩慢地泄漏，通過一個內(nèi)存的火焰圖，我們就知道哪些路徑申請的內(nèi)存最多，有了火焰圖我們根本不需要分析源代碼，也不需要分析整個流程。在寫今天的文章，也就是分析卡頓的基礎(chǔ)知識和四種Android卡頓排查工具時，我越發(fā)覺得底層基礎(chǔ)知識的重要性。Android底層基于Linux內(nèi)核，像systrace、Simpleperf也是利用Linux提供的機(jī)制實現(xiàn)，因此學(xué) 些Linux的基礎(chǔ)知識，對于理解這些工具的工作原理另一方面，雖然很多大廠有專門的性能優(yōu)化團(tuán)隊，但我覺得鼓勵和培養(yǎng)團(tuán)隊里的每一個人都去關(guān)注性能問題更加重要。我們在使用性能工具的同時，要學(xué)會思考，應(yīng)該知道它們的原理和局限性。更進(jìn)一步來說，你還可以嘗試去為這些工具做一些優(yōu)化，從而實現(xiàn)更加完善的方案。當(dāng)發(fā)生ANR的時候，Android系統(tǒng)會打印CPU相關(guān)的信息到日志中，使用的是ProcessCpuTracker.javaCPUCPU個線程的CPU使用率，繼而統(tǒng)計出該進(jìn)程各個線程的時間占比。 //進(jìn)程CPU/proc/[pid]/task/[tid]/stat//進(jìn)程下面各個線程的CPU //進(jìn)程CPU //系統(tǒng)平均負(fù)載，uptimeCPU5SampleCPU1usage:CPUusage5000ms(from23:23:33.000toSystemTOTAL:2.1%user+16%kernel+9.2%iowait+0.2%irq+0.1%softirq+72%CPUCore:LoadAverage:8.74/7.74/5 .sample.app(S):11%user+38%kernel843%23493/singleThread(R):6.5%user+36%kernel3.2%23485/RenderThread(S):2.1%user+1%kernel0.3%23468/.sample.app(S):0.3%user+