在移動(dòng)互聯(lián)網(wǎng)時(shí)代，由于設(shè)備資源受限、網(wǎng)絡(luò)不穩(wěn)定等因素，Web 端和移動(dòng)端的性能優(yōu)化顯得尤為重要，如果性能不好，用戶就容易流失，ToC 的產(chǎn)品尤為明顯，體驗(yàn)差的產(chǎn)品必然會(huì)被市場(chǎng)淘汰。如何做好性能優(yōu)化是每個(gè)企業(yè)都會(huì)關(guān)注的。
在將于 11 月 24-25 日舉辦的 GMTC 全球大前端技術(shù)大會(huì)上，快手性能優(yōu)化負(fù)責(zé)人楊凱將會(huì)分享《快手 APM 平臺(tái)建設(shè)與性能優(yōu)化》。他表示，“隨著快手 App 功能越來(lái)越多，App 的性能也面臨著嚴(yán)峻的挑戰(zhàn)，諸如 App 越來(lái)越卡、內(nèi)存占用越來(lái)越大、包大小不斷增加等各類問(wèn)題都嚴(yán)重影響著用戶體驗(yàn)”。InfoQ 在會(huì)前采訪了楊老師，我們一起來(lái)看看快手是如何應(yīng)對(duì)性能挑戰(zhàn)的。
InfoQ：快手 APM 指標(biāo)監(jiān)控平臺(tái)的建設(shè)背景是什么？目前發(fā)展現(xiàn)狀如何？
楊凱：APM 是我們針對(duì)快手的性能檢測(cè)做的一個(gè)監(jiān)控平臺(tái)，其建立背景主要有兩方面 ， 一方面有很多用戶反饋在使用我們的 App 時(shí)，遇到過(guò)卡、閃退和發(fā)熱等問(wèn)題；另一方面，我們從現(xiàn)有數(shù)據(jù)分析得出結(jié)論：性能對(duì)于用戶活躍度有著重要影響。
目前，我們已經(jīng)基本完成了崩潰、內(nèi)存溢出（OOM）、應(yīng)用無(wú)響應(yīng)（ANR）、卡頓、啟動(dòng)、幀率（FPS）、包大小的線上、線下監(jiān)控，電量、流量等監(jiān)控正在開發(fā)中。線上的話，我們有天級(jí)、小時(shí)級(jí)的監(jiān)控，并且重點(diǎn)指標(biāo)有完善的報(bào)警機(jī)制。對(duì)于包大小、啟動(dòng)等，我們建立了一套實(shí)驗(yàn)室環(huán)境，可以監(jiān)控到每個(gè) mr（Merge request ） 導(dǎo)致的變化，以及日常迭代劣化。
APM 主要解決我們面臨的各種穩(wěn)定性和性能問(wèn)題。效果非常明顯：
優(yōu)化了 40% 的啟動(dòng)速度，提升了我們的 0 播、留存等關(guān)鍵產(chǎn)品數(shù)據(jù)。優(yōu)化了 23M 包大小，大大降低了我們新用戶獲取成本。兩個(gè)優(yōu)化，都獲得了快手技術(shù)線的績(jī)效提升獎(jiǎng)。
InfoQ：你們?cè)诖罱ㄖ笜?biāo)監(jiān)控過(guò)程中遇到哪些難點(diǎn)？是怎么解決的呢？
楊凱：APM 可以做的事情很多，容易鋪得很廣，但每一點(diǎn)都做不透。另一方面，雖然大家都覺得性能重要，但如果沒有數(shù)據(jù)的支撐，也容易陷入到處救火而看不到成績(jī)得窘境。所以我們一方面參考業(yè)內(nèi)經(jīng)驗(yàn)、根據(jù)數(shù)據(jù)分析得出重要程度，評(píng)估每個(gè)方向的優(yōu)先級(jí)，各個(gè)擊破，抓住重點(diǎn)，力求每一點(diǎn)都做到極致，并且能從用戶數(shù)據(jù)上得到充分的體現(xiàn)。
我們是一個(gè)音視頻軟件，所以對(duì)內(nèi)存的使用，尤其是 C++ 申請(qǐng)的內(nèi)存會(huì)比較多。內(nèi)存泄露，OOM、地址空間不足等問(wèn)題非常突出。業(yè)內(nèi)現(xiàn)有方案對(duì)我們來(lái)說(shuō)并不完全適用，需要我們根據(jù)自己的實(shí)際情況，開發(fā)監(jiān)控、解決問(wèn)題。業(yè)內(nèi)有比較成熟的 malloc hook 方案監(jiān)控 C++ 內(nèi)存的申請(qǐng)、釋放，但我們還需要知道哪些內(nèi)存不可達(dá)，哪些大塊內(nèi)存被長(zhǎng)時(shí)間持有，才能更好地解決我們的問(wèn)題。
另外，我們?cè)诰€上發(fā)現(xiàn)的性能問(wèn)題，通常不是我們性能組能獨(dú)立解決的，需要推動(dòng)各業(yè)務(wù)方配合解決。這些工作會(huì)給大家日常的開發(fā)工作帶來(lái)額外的負(fù)擔(dān)，但它又對(duì)我們產(chǎn)品體驗(yàn)有很重要的影響。所以我們一方面盡量完善工具，上報(bào)更多更全的數(shù)據(jù)，另一方面我們要將大家作為一個(gè)整體團(tuán)隊(duì)，享受項(xiàng)目的成果。
InfoQ：內(nèi)存優(yōu)化過(guò)程中遇到的問(wèn)題是如何解決的？
楊凱： 我們有一套自己的方法論，即定義問(wèn)題、分析問(wèn)題、解決問(wèn)題、驗(yàn)收以及防劣化。
定義問(wèn)題： 在最開始階段，先將問(wèn)題量化，例如用戶卡，就需要定義什么叫卡，怎么監(jiān)控用戶卡？
分析問(wèn)題： 我們會(huì)在收集到足夠的用戶數(shù)據(jù)后，分析用戶實(shí)際的問(wèn)題場(chǎng)景、原因。解決問(wèn)題： 很多問(wèn)題，并不是性能組可以解決的，但是我們可以提供工具定位、發(fā)現(xiàn)問(wèn)題，推動(dòng)相關(guān)開發(fā)人員解決。驗(yàn)收： 對(duì)于一些重要的優(yōu)化，我們會(huì)通過(guò) AB 上線驗(yàn)收效果，回收技術(shù)數(shù)據(jù)和產(chǎn)品數(shù)據(jù)（例如優(yōu)化 FPS，我們會(huì)看相關(guān)頁(yè)面 CTR 的變化）。防劣化： 我們會(huì)制定一些機(jī)制、方案，防止已經(jīng)優(yōu)化的數(shù)據(jù)在日常的迭代中劣化，包括每個(gè)版本灰度期間的監(jiān)控、線下實(shí)驗(yàn)室環(huán)境測(cè)試、開發(fā)階段提醒等。
InfoQ：怎么進(jìn)行內(nèi)存優(yōu)化？
楊凱： 內(nèi)存主要是 JAVA 和 C 兩部分，對(duì)于 Java，我們研發(fā)了一套線上裁剪、分析、上傳用戶本地鏡像的方案，可以做到用戶內(nèi)存不足時(shí)，快速而準(zhǔn)確地上報(bào)當(dāng)時(shí)的 Java 內(nèi)存狀態(tài)，初步可以判斷出來(lái)泄露和內(nèi)存大戶是誰(shuí)。上報(bào)后我們會(huì)對(duì)所有用戶的信息做匯總、展示。Java 部分的內(nèi)存監(jiān)控主要做了以下幾點(diǎn)：
內(nèi)存鏡像轉(zhuǎn)儲(chǔ)，我們研發(fā)了一種高效 dump 方案，解決了傳統(tǒng)方法虛擬機(jī)內(nèi)存轉(zhuǎn)儲(chǔ)需要暫停虛擬機(jī)的問(wèn)題。內(nèi)存鏡像分析，研發(fā)了基于 shark 的低內(nèi)存開銷、低 CPU 開銷的獨(dú)立進(jìn)程解析方案，采用了更為節(jié)省內(nèi)存的高性能數(shù)據(jù)結(jié)構(gòu)以及更為高效的內(nèi)存索引，增加了同類型對(duì)象閾值用于 GC Root 最短路徑搜索剪枝，可以在手機(jī)側(cè) 10 分鐘內(nèi)完成 400M 鏡像、200 萬(wàn) 對(duì)象的極端 case 解析。內(nèi)存鏡像裁剪，我們研發(fā)了一種 hook 虛擬機(jī)內(nèi)存鏡像轉(zhuǎn)儲(chǔ)時(shí) IO 的高效裁剪方案，解決了傳統(tǒng)裁剪效率低、成功率低的問(wèn)題，輔以 zstd 壓縮，90% 內(nèi)存鏡像可以壓縮至 80M 內(nèi)。
C 的內(nèi)存 我們主要利用編譯器插樁及 malloc hook 記錄所有活著的內(nèi)存塊，利用 mark-and-sweep 算法在單獨(dú)的進(jìn)程中分析測(cè)試應(yīng)用進(jìn)程 Native Heap 中不可達(dá)的內(nèi)存塊。將發(fā)現(xiàn)的不可達(dá)內(nèi)存上報(bào)后臺(tái)。具體操作如下：
利用編譯器插樁及 malloc hook 記錄所有活著的內(nèi)存塊（包含內(nèi)存塊地址、backtrace 信息），對(duì)性能影響較小。利用 mark-and-sweep 算法在單獨(dú)的進(jìn)程中分析測(cè)試應(yīng)用進(jìn)程 Native Heap 中不可達(dá)的內(nèi)存塊（包含內(nèi)存塊地址）。對(duì)于步驟 2 中收集到的不可達(dá)內(nèi)存塊，從 1 中獲取其對(duì)應(yīng)的 backtrace 信息，將泄漏信息上報(bào)至 APM 監(jiān)控平臺(tái)。APM 監(jiān)控平臺(tái)解析泄漏信息（backtrace 信息符號(hào)化等），做友好的展示，業(yè)務(wù)方根據(jù) APM 展示信息可快速定位泄漏問(wèn)題。
InfoQ：如何優(yōu)化卡頓？
楊凱： 我們定義的卡頓是：一個(gè)消息 / 任務(wù)在主線程執(zhí)行超過(guò) 1s。
優(yōu)化主要看卡頓的堆棧特征、當(dāng)前 CPU 占用、其它線程正在執(zhí)行的任務(wù)。通常有以下幾種情況：CPU 占用過(guò)高（一般是主線程或者子線程任務(wù)重），主線程等鎖（需要看其它線程當(dāng)時(shí)的任務(wù)），系統(tǒng)服務(wù)忙（binder 調(diào)用耗時(shí)長(zhǎng)）。解決方案一般需要結(jié)合場(chǎng)景、頁(yè)面，增加 log 等，豐富更多上報(bào)信息，定位主要問(wèn)題，或者緩解 CPU 占用。
InfoQ：在啟動(dòng)優(yōu)化這部分做了哪些動(dòng)作，優(yōu)化前后對(duì)比效果如何？
楊凱： 啟動(dòng)優(yōu)化我們主要是建立啟動(dòng)框架，將啟動(dòng)所有的任務(wù)，全部收斂到框架內(nèi)，統(tǒng)計(jì)每個(gè)任務(wù)的耗時(shí)、相互依賴關(guān)系。
啟動(dòng)優(yōu)化定位問(wèn)題：
將啟動(dòng)時(shí)運(yùn)行的代碼，按照功能，做成 task；線上收集每個(gè) task 的耗時(shí)；在線下，在 Android 端利用 systrace、在 IOS 端利用自研的火焰圖工具，來(lái)分析耗時(shí)。
優(yōu)化手段：
優(yōu)化整體流程；分場(chǎng)景、分用戶特性，推遲甚至取消一些 task （根據(jù)用戶登錄狀態(tài)，用戶使用習(xí)慣，后面我們會(huì)用機(jī)器學(xué)習(xí)預(yù)測(cè) task 是否需要初始化）；特別關(guān)注一些鎖的等待、主線程 CPU 分配不足等問(wèn)題；一些系統(tǒng) API，背后會(huì)引發(fā)一系列的初始化（setcookie，會(huì)引起 WebView 內(nèi)核初始化）；主動(dòng) dex2oat；二進(jìn)制重排、dex 重排。
另外，針對(duì)線上收集到的信息，重點(diǎn)優(yōu)化耗時(shí)較多的任務(wù)。線下通過(guò) systrace 等工具，定位、驗(yàn)證修復(fù)。然后依據(jù)用戶的不同特征，初始化不同任務(wù)。例如，未登錄用戶不需要初始化拍攝相關(guān)任務(wù)。我們一期優(yōu)化效果達(dá)到了 40%，后續(xù)幾期優(yōu)化，也收到了不錯(cuò)的效果。用戶側(cè)收益明顯，用戶（尤其是新用戶）0 展示 、0 滑、 0 播放，以及留存等數(shù)據(jù)都有非常大的提升。
