近日，快手宣布開源KOOM，成為行業(yè)首個(gè)開源線上內(nèi)存溢出(Out of Memory，以下簡稱OOM)問題解決方案的互聯(lián)網(wǎng)企業(yè)。據(jù)介紹，KOOM是在客戶端完成內(nèi)存監(jiān)控后，將解析報(bào)告上傳到云端，傳輸文件大小僅為KB級，運(yùn)行時(shí)用戶無感知，對流量基本無影響，適合大規(guī)模普及應(yīng)用，目前該方案已在快手全量業(yè)務(wù)中應(yīng)用，OOM率降低了80%以上，效果顯著。

OOM是當(dāng)前Android開發(fā)中的常見疑難問題，尤其是線上發(fā)生的OOM問題極難定位。業(yè)界當(dāng)前最知名的方案LeakCanary，通過監(jiān)控Activity/Fragment泄漏優(yōu)化Java OOM問題，多年來一直為廣大app保駕護(hù)航，解決了OOM治理從0到1的問題。但面對行業(yè)不斷復(fù)雜的業(yè)務(wù)環(huán)境和龐大用戶流量，LeakCanary仍有優(yōu)化空間：受限于性能，無法在線上大規(guī)模部署，僅支持線下使用；只能定位Activity&Fragment泄漏，無法定位大對象、頻繁分配等問題；需要人工一一分析，無法對問題聚類量化……為了徹底解決OOM問題，行業(yè)嘗試了多種解決方案，通常是基于LeakCanary做優(yōu)化，但至今沒有能完全解決監(jiān)控過程中的性能問題，普遍解決方法是通過采樣的辦法犧牲一小部分用戶的體驗(yàn)來定位問題。

快手OOM  Killer沿用行業(yè)的研究思路，針對LeakCanary無法解決的難題進(jìn)行自研改造，充分發(fā)揮LeakCanary原有優(yōu)勢的同時(shí)補(bǔ)足短板，打造了一套可以線上部署、兼顧線下、配置靈活、適用范圍廣泛、高度自動化，埋點(diǎn)、監(jiān)控、解析、上報(bào)、分發(fā)、跟進(jìn)、報(bào)警一站式服務(wù)的閉環(huán)監(jiān)控系統(tǒng)，將絕大多數(shù)OOM問題攔截在灰度階段，徹底解決了OOM問題。

KOOM框架

快手KOOM核心流程包括：配置下發(fā)決策、監(jiān)控內(nèi)存狀態(tài)、采集內(nèi)存鏡像、解析鏡像文件(以下簡稱hprof)生成報(bào)告并上傳、問題聚合報(bào)警與分配跟進(jìn)。

無主動觸發(fā)GC不卡頓

之前行業(yè)的普遍做法是通過在Activity.onDestroy()后連續(xù)觸發(fā)兩次GC，并檢查引用隊(duì)列，判定Activity是否發(fā)生了泄漏，但頻繁GC會造成用戶可感知的卡頓，快手為實(shí)現(xiàn)無感觸發(fā)設(shè)計(jì)了全新的監(jiān)控模塊，通過無性能損耗的內(nèi)存閾值監(jiān)控來觸發(fā)鏡像采集。將對象是否泄漏的判斷延遲到了解析時(shí)，閾值監(jiān)控只要在子線程定期獲取關(guān)注的幾個(gè)內(nèi)存指標(biāo)即可，性能損耗忽略不計(jì)。

內(nèi)存監(jiān)控流程圖

高性能鏡像DUMP

采集內(nèi)存鏡像傳統(tǒng)方案會造成應(yīng)用完全凍結(jié)長達(dá)幾秒，期間用戶完全不能操作，嚴(yán)重?fù)p害用戶體驗(yàn)?？焓掷孟到y(tǒng)內(nèi)核COW(Copy-on-write，寫時(shí)復(fù)制)機(jī)制，每次dump內(nèi)存鏡像前先暫停虛擬機(jī)，然后fork子進(jìn)程來執(zhí)行dump操作，父進(jìn)程在fork成功后立刻恢復(fù)虛擬機(jī)運(yùn)行，整個(gè)過程對于父進(jìn)程來講總耗時(shí)只有幾毫秒，對用戶完全沒有影響。

暫停虛擬機(jī)需要調(diào)用虛擬機(jī)的art::Dbg::SuspendVM函數(shù)，谷歌從Android 7.0開始對調(diào)用系統(tǒng)庫做了限制，快手自研了kwai-linker組件，通過caller address替換和dl_iterate_phdr解析繞過了這一限制。

Fork dump hprof流程圖

“不偷”用戶流量的解決方案

傳統(tǒng)方案得到的hprof文件通常比較大，占用用戶大量磁盤空間，上傳大文件浪費(fèi)用戶流量，且不利于問題聚類分析?？焓植捎昧诵碌乃悸罚翰捎眠吘売?jì)算的思路，將內(nèi)存鏡像于閑時(shí)進(jìn)行獨(dú)立進(jìn)程單線程本地分析，不過多占用系統(tǒng)運(yùn)行時(shí)資源；分析完即刪除，不占用磁盤空間；分析報(bào)告大小只有KB級別，不浪費(fèi)用戶流量。

分析報(bào)告生成流程總體分為三個(gè)環(huán)節(jié)，第一個(gè)環(huán)節(jié)掃描鏡像構(gòu)建索引，建立泄露查找分析的基礎(chǔ)；第二個(gè)環(huán)節(jié)查找出泄露的對象，根據(jù)既有的framework知識以及人為設(shè)定的策略，執(zhí)行對象泄露判定；第三個(gè)環(huán)節(jié)生成最終報(bào)告文件，將對象泄露路徑、泄露數(shù)量、類統(tǒng)計(jì)、運(yùn)行時(shí)信息添加至報(bào)告文件，輔助后續(xù)根據(jù)報(bào)告分析解決OOM問題。

解析鏡像生成報(bào)告流程圖

針對鏡像回?fù)菩枨?，對hprof進(jìn)行運(yùn)行時(shí)hook裁剪，只保留分析OOM必須的數(shù)據(jù)。裁剪還有數(shù)據(jù)脫敏的好處，只保留對分析問題有用的內(nèi)存中類與對象的組織結(jié)構(gòu)，并不上傳真實(shí)的業(yè)務(wù)數(shù)據(jù)，充分保護(hù)用戶隱私。

總結(jié)展望

快手KOOM計(jì)劃做完整的客戶端內(nèi)存解決方案，開發(fā)者可以通過接入KOOM，解決自己項(xiàng)目中的OOM問題。此次一期開源暫時(shí)只包括Android Java OOM解決方案，后續(xù)還將開源Android線程/文件描述符監(jiān)控、Android Native OOM監(jiān)控、iOS OOM監(jiān)控等，最終實(shí)現(xiàn)幫助開發(fā)者解決各種場景下OOM的愿景。

快手KOOM GitHub地址：https://github.com/KwaiAppTeam/KOOM