快手自研OOM解決方案KOOM今日宣佈開源

近日，快手宣佈開源KOOM，成為行業首個開源線上內存溢出(Out of Memory，以下簡稱OOM)問題解決方案的互聯網企業。據介紹，KOOM是在客户端完成內存監控後，將解析報告上傳到雲端，傳輸文件大小僅為KB級，運行時用户無感知，對流量基本無影響，適合大規模普及應用，目前該方案已在快手全量業務中應用，OOM率降低了80%以上，效果顯著。

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

快手OOM Killer沿用行業的研究思路，針對LeakCanary無法解決的難題進行自研改造，充分發揮LeakCanary原有優勢的同時補足短板，打造了一套可以線上部署、兼顧線下、配置靈活、適用範圍廣泛、高度自動化，埋點、監控、解析、上報、分發、跟進、報警一站式服務的閉環監控系統，將絕大多數OOM問題攔截在灰度階段，徹底解決了OOM問題。

KOOM框架

快手KOOM核心流程包括：配置下發決策、監控內存狀態、採集內存鏡像、解析鏡像文件(以下簡稱hprof)生成報告並上傳、問題聚合報警與分配跟進。

無主動觸發GC不卡頓

之前行業的普遍做法是通過在Activity.onDestroy()後連續觸發兩次GC，並檢查引用隊列，判定Activity是否發生了泄漏，但頻繁GC會造成用户可感知的卡頓，快手為實現無感觸發設計了全新的監控模塊，通過無性能損耗的內存閾值監控來觸發鏡像採集。將對象是否泄漏的判斷延遲到了解析時，閾值監控只要在子線程定期獲取關注的幾個內存指標即可，性能損耗忽略不計。

內存監控流程圖

高性能鏡像DUMP

採集內存鏡像傳統方案會造成應用完全凍結長達幾秒，期間用户完全不能操作，嚴重損害用户體驗。快手利用系統內核COW(Copy-on-write，寫時複製)機制，每次dump內存鏡像前先暫停虛擬機，然後fork子進程來執行dump操作，父進程在fork成功後立刻恢復虛擬機運行，整個過程對於父進程來講總耗時只有幾毫秒，對用户完全沒有影響。

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

Fork dump hprof流程圖

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

傳統方案得到的hprof文件通常比較大，佔用用户大量磁盤空間，上傳大文件浪費用户流量，且不利於問題聚類分析。快手採用了新的思路：採用邊緣計算的思路，將內存鏡像於閒時進行獨立進程單線程本地分析，不過多佔用系統運行時資源;分析完即刪除，不佔用磁盤空間;分析報告大小隻有KB級別，不浪費用户流量。

分析報告生成流程總體分為三個環節，第一個環節掃描鏡像構建索引，建立泄露查找分析的基礎;第二個環節查找出泄露的對象，根據既有的framework知識以及人為設定的策略，執行對象泄露判定;第三個環節生成最終報告文件，將對象泄露路徑、泄露數量、類統計、運行時信息添加至報告文件，輔助後續根據報告分析解決OOM問題。

解析鏡像生成報告流程圖

針對鏡像回撈需求，對hprof進行運行時hook裁剪，只保留分析OOM必須的數據。裁剪還有數據脱敏的好處，只保留對分析問題有用的內存中類與對象的組織結構，並不上傳真實的業務數據，充分保護用户隱私。

總結展望

快手KOOM計劃做完整的客户端內存解決方案，開發者可以通過接入KOOM，解決自己項目中的OOM問題。此次一期開源暫時只包括Android Java OOM解決方案，後續還將開源Android線程/文件描述符監控、Android Native OOM監控、iOS OOM監控等，最終實現幫助開發者解決各種場景下OOM的願景。