內(nèi)存作為計算機程序運行最重要的資源之一，需要運行過程中做到合理的資源分配與回收，不合理的內(nèi)存占用輕則使得用戶應(yīng)用程序運行卡頓、ANR、黑屏，重則導(dǎo)致用戶應(yīng)用程序發(fā)生 OOM（out of memory）崩潰。抖音作為一款用戶使用廣泛的產(chǎn)品，需要在各種機器資源上保持優(yōu)秀的流暢性和穩(wěn)定性，內(nèi)存優(yōu)化是必須要重視的環(huán)節(jié)。
本文從抖音 Java OOM 內(nèi)存優(yōu)化的治理實踐出發(fā)，嘗試給大家分享一下抖音團隊關(guān)于 Java 內(nèi)存優(yōu)化中的一些思考，包括工具建設(shè)、優(yōu)化方法論。
抖音 Java OOM 背景
在未對抖音內(nèi)存進行專項治理之前我們梳理了一下整體內(nèi)存指標的絕對值和相對崩潰，發(fā)現(xiàn)占比都很高。另外，內(nèi)存相關(guān)指標在去年春節(jié)活動時又再次激增達到歷史新高，所以整體來看內(nèi)存問題相當嚴峻，必須要對其進行專項治理。抖音這邊通過前期歸因、工具建設(shè)以及投入一個雙月的內(nèi)存專項治理將整體 Java OOM 優(yōu)化了百分之 80。
Java OOM Top 堆棧歸因
在對抖音的 Java 內(nèi)存優(yōu)化治理之前我們先根據(jù)平臺上報的堆棧異常對當前的 OOM 進行歸因，主要分為下面幾類：
圖 1. OOM 分類
其中 pthread_create 問題占到了總比例大約在百分之 50，Java 堆內(nèi)存超限為百分之 40 多，剩下是少量的 fd 數(shù)量超限。其中 pthread_create 和 fd 數(shù)量不足均為 native 內(nèi)存限制導(dǎo)致的 Java 層崩潰，我們對這部分的內(nèi)存問題也做了針對性優(yōu)化，主要包括：
線程收斂、監(jiān)控
線程棧泄漏自動修復(fù)
FD 泄漏監(jiān)控
虛擬內(nèi)存監(jiān)控、優(yōu)化
抖音 64 位專項
治理之后 pthread_create 問題降低到了 0.02‰以下，這方面的治理實踐會在下一篇抖音 Native 內(nèi)存治理實踐中詳細介紹，大家敬請期待。本文重點介紹 Java 堆內(nèi)存治理。
堆內(nèi)存治理思路
從 Java 堆內(nèi)存超限的分類來看，主要有兩類問題：
1. 堆內(nèi)存單次分配過大/多次分配累計過大。
觸發(fā)這類問題的原因有數(shù)據(jù)異常導(dǎo)致單次內(nèi)存分配過大超限，也有一些是 StringBuilder 拼接累計大小過大導(dǎo)致等等。這類問題的解決思路比較簡單，問題就在當前的堆棧。
2. ****堆內(nèi)存累積分配觸頂。
這類問題的問題堆棧會比較分散，在任何內(nèi)存分配的場景上都有可能會被觸發(fā)，那些高頻的內(nèi)存分配節(jié)點發(fā)生的概率會更高，比如 Bitmap 分配內(nèi)存。這類 OOM 的根本原因是內(nèi)存累積占用過多，而當前的堆棧只是壓死駱駝的最后一根稻草，并不是問題的根本所在。所以這類問題我們需要分析整體的內(nèi)存分配情況，從中找到不合理的內(nèi)存使用（比如內(nèi)存泄露、大對象、過多小對象、大圖等）。
工具建設(shè)
工具思路
工欲善其事，必先利其器。從上面的內(nèi)存治理思路看，工具需要主要解決的問題是分析整體的內(nèi)存分配情況，發(fā)現(xiàn)不合理的內(nèi)存使用（比如內(nèi)存泄露、大對象、過多小對象等）。
我們從線下和線上兩個維度來建設(shè)工具：
線下
線下工具是最先考慮的，在研發(fā)和測試的時候能夠提前發(fā)現(xiàn)內(nèi)存泄漏問題。業(yè)界的主流工具也是這個思路，比如 Android Studio Memory Profiler、LeakCanary、Memory Analyzer (MAT)。
我們基于 LeakCanary 核心庫在線下設(shè)計了一套自動分析上報內(nèi)存泄露的工具，主要流程如下：
圖 2.線下自動分析流程
抖音在運行了一段線下的內(nèi)存泄漏工具之后，發(fā)現(xiàn)了線下工具的各種弊端：
- 檢測出來的內(nèi)存泄漏過多，并且也沒有比較好的優(yōu)先級排序，研發(fā)消費不過來，歷史問題就一直堆積。另外也很難和業(yè)務(wù)研發(fā)溝通問題解決的收益，大家針對解決線下的內(nèi)存泄漏問題的 ROI（投入產(chǎn)出比）比較難對齊。
- 線下場景能跑到的場景有限，很難把所有用戶場景窮盡。抖音用戶基數(shù)很大，我們經(jīng)常遇到一些線上的 OOM 激增問題，因為缺少線上數(shù)據(jù)而無從查起。
- Android 端的 HPORF 的獲取依賴原生的
Debug.dumpHporf，dump 過程會掛起主線程導(dǎo)致明顯卡頓，線下使用體驗較差，經(jīng)常會有研發(fā)反饋影響測試。 - LeakCanary 基于 Shark 分析引擎分析，分析速度較慢，通常在 5 分鐘以上才能分析完成，分析過程會影響進程內(nèi)存占用。
- 分析結(jié)果較為單一，僅僅只能分析出 Fragment、Activity 內(nèi)存泄露，像大對象、過多小對象問題導(dǎo)致的內(nèi)存 OOM 無法分析。
線上
正是由于上述一些弊端，抖音最早的線下工具和治理流程并沒有起到什么太大作用，我們不得不重新審視一下，工具建設(shè)的重心從線下轉(zhuǎn)成了線上。線上工具的核心思路是：在發(fā)生 OOM 或者內(nèi)存觸頂?shù)扔|發(fā)條件下，dump 內(nèi)存的 HPROF 文件，對 HPROF 文件進行分析，分析出內(nèi)存泄漏、大對象、小對象、圖片問題并按照泄露鏈路自動歸因，將大數(shù)據(jù)問題按照用戶發(fā)生次數(shù)、泄露大小、總大小等緯度排序，推進業(yè)務(wù)研發(fā)按照優(yōu)先級順序來建立消費流程。為此我們研發(fā)了一套基于 HPORF 分析的線下、線上閉環(huán)的自動化分析工具 Liko（寓意 ko 內(nèi)存 Leak 問題）。
Liko 介紹
Liko 整體架構(gòu)
圖 3. Liko 架構(gòu)圖
整體架構(gòu)由客戶端、Server 端和核心分析引擎三部分構(gòu)成。
- 客戶端
在客戶端完成 HPROF 數(shù)據(jù)采集和分析（針對端上分析模式），這里線上和線下策略不同。
線上：主要在 OOM 和內(nèi)存觸頂時通過用戶無感知 dump 來獲取 HPROF 文件，當 App 退出到后臺且內(nèi)存充足的情況進行分析，為了盡量減少對 App 運行時影響，主要通過裁剪 HPROF 回傳進行分析，為減輕服務(wù)器壓力，對部分比例用戶采用端上分析作為 Backup。
線下：dump 策略配置較為激進，在 OOM、內(nèi)存觸頂、內(nèi)存激增、監(jiān)測 Activity、Fragment 泄漏數(shù)量達到一定閾值多種場景下觸發(fā) dump，并實時在端上分析上傳至后臺并在本地自動生成 html 報表，幫助研發(fā)提前發(fā)現(xiàn)可能存在的內(nèi)存問題。
- Server 端
Server 端根據(jù)線上回傳的大數(shù)據(jù)完成鏈路聚合、還原、分配，并根據(jù)用戶發(fā)生次數(shù)、泄露大小、總大小等緯度促進研發(fā)測消費，對于回傳分析模式則會另外進行 HPORF 分析。
- 分析引擎
基于 MAT 分析引擎完成內(nèi)存泄露、大對象、小對象、圖片等自動歸因，同時支持在線下自動生成 Html 報表。
Liko 流程圖
圖 4. Liko 流程圖
整體流程分為：
Hprof 收集
分析時機
分析策略
Hprof 收集
收集過程我們設(shè)置了多種策略可以自由組合，主要有 OOM、內(nèi)存觸頂、內(nèi)存激增、監(jiān)測 Activity、Fragment 泄漏數(shù)量達到一定閾值時觸發(fā)，線下線上策略配置不同。
為了解決 dump 掛起進程問題，我們采用了子進程 dump+fileObsever 的方式完成 dump 采集和監(jiān)聽。
在 fork 子進程之前先 Suspend 獲取主進程中的線程拷貝，通過 fork 系統(tǒng)調(diào)用創(chuàng)建子進程讓子進程擁有父進程的拷貝，然后 fork 出的子進程中調(diào)用 Hprof 的 DumpHeap 函數(shù)即可完成把耗時的 dump 操作在放在子進程。由于 suspend 和 resume 是系統(tǒng)函數(shù)，我們這里通過自研的 native hook 工具對 libart.so hook 獲取系統(tǒng)調(diào)用。由于寫入是在子進程完成的，我們通過 Android 提供的 fileObsever 文件寫入進行監(jiān)控獲取 dump 完成時機。
圖 5.子進程 dump 流程圖
Hprof 分析時機
為了達到分析過程對于用戶無感，我們在線上、線下配置了不同的分析時機策略，線下在 dump 分析完成后根據(jù)內(nèi)存狀態(tài)主動觸發(fā)分析，線上當用戶下次冷啟退出應(yīng)用后臺且內(nèi)存充足的情況下觸發(fā)分析。
分析策略
分析策略我們提供了兩種，一種在 Android 客戶端分析，一種回傳至 Server 端分析，均通過 MAT 分析引擎進行分析。
端上分析
分析引擎
端上分析引擎的性能很重要，這里我們主要對比了 LeakCanary 的分析引擎 Shark 和 Haha 庫的 MAT。
圖 6. Shark VS MAT
我們在相同客戶端環(huán)境對 160M 的 HPROF 多次分析對比發(fā)現(xiàn) MAT 分析速度明顯優(yōu)于 Shark，另外針對 MAT 分析后仍持有統(tǒng)治者樹占用內(nèi)存我們也做了主動釋放，對比性能收益后采用基于 MAT 庫的分析引擎進行分析，對內(nèi)存泄漏引用鏈路自動歸并、大對象小對象引用鏈自動分析、大圖線下自動還原線上過濾無用鏈路，分析結(jié)果如下：
內(nèi)存泄漏
圖 7. 內(nèi)存泄漏鏈路
對泄漏的 Activity 的引用鏈進行了聚合分析，方便一次性解決該 Activity 的泄漏鏈釋放內(nèi)存。
大對象
圖 8. 大對象鏈路
大對象不止分析了引用鏈路，還遞歸分析了內(nèi)部 top 持有對象（InRefrenrece）的 RetainedSize。
小對象
圖 9. 小對象鏈路
小對象我們對 top 的外部持有對象（OutRefrenrece）進行聚合得到占有小對象最多的鏈路。
圖片
圖 10. 圖片鏈路
圖片我們過濾了圖片庫等無效引用且對 Android 8.0 以下的大圖在線下進行了還原。
回傳分析
為了最大限度的節(jié)省用戶流量且規(guī)避隱私風(fēng)險，我們通過自研 HPROF 裁剪工具 Tailor 在 dump 過程對 HPROF 進行了裁剪。
裁剪過程
圖 11. Tailor 裁剪流程
去除了無用信息
跳過 header
分 tag 裁剪
裁剪無用信息：char[]; byte[]; timestamp; stack trace serial number; class serial number;
壓縮數(shù)據(jù)信息
同時對數(shù)據(jù)進行 zlib 壓縮，在 server 端數(shù)據(jù)還原，整體裁剪效果：180M--->50M---->13M
優(yōu)化實踐
內(nèi)存泄漏
除了通過后臺根據(jù) GCROOT+ 引用鏈自動分配研發(fā)跟進解決我們常見的內(nèi)存泄漏外，我們還對系統(tǒng)導(dǎo)致一些內(nèi)存泄漏進行了分析和修復(fù)。
系統(tǒng)異步 UI 泄漏
根據(jù)上傳聚合的引用鏈我們發(fā)現(xiàn)在 Android 6.0 以下有一個 HandlerThread 作為 GCROOT 持有大量 Activity 導(dǎo)致內(nèi)存泄漏，根據(jù)引用發(fā)現(xiàn)這些泄漏的 Activity 都被一個 Runnable（這里是 Runnable 是一個系統(tǒng)事件 SendViewStateChangedAccessibilityEvent）持有，這些 Runnable 被添加到一個 RunQueuel 中，這個隊列本身被 TheadLocal 持有。
圖 12. HandlerThread 泄露鏈路
我們從 SendViewStateChangedAccessibilityEvent 入手對源碼進行了分析發(fā)現(xiàn)它在 notifyViewAccessibilityStateChangedIfNeeded 中被拋出，系統(tǒng)的大量 view 都會在自身的一些 UI 方法（eg: setChecked）中觸發(fā)該函數(shù)。
SendViewStateChangedAccessibilityEvent 的 runOrPost 方法會走到我們常用的 View 的 postDelay 方法中，這個方法在當 view 還未被 attched 到根 view 的時候會加入到一個 runQueue 中。
這個 runQueue 會在主線程下一次的 performTraversals() 中消費掉。
如果這個 runQueue 不在主線程那就沒有消費的機會。
根據(jù)上面的分析發(fā)現(xiàn)造成這種內(nèi)存泄漏需要滿足一些條件：
view 調(diào)用了
postDelay方法 （這里是notifyViewAccessisbilityStateChangeIfNeeded觸發(fā)）view 處于 detached 狀態(tài)
上述過程是在非主線程里面操作的，ThreadLocal 非 UIThread，持有的 runQueue 不會走
performTraversals消費掉。
抖音這邊大量使用了異步 UI 框架來優(yōu)化渲染性能，框架內(nèi)部由一個 HandlerThread 驅(qū)動，完全符合上述條件。針對該問題，我們通過反射獲取非主線程的 ThreadLocal，在每次異步渲染完主動清理內(nèi)部的 RunQueue。
圖 13. 反射清理流程
另外，Google 在 6.0 上也修復(fù)了 notifyViewAccessisbilityStateChangeIfNeeded 的判斷不嚴謹問題。
內(nèi)存泄漏兜底
大量的內(nèi)存泄漏，如果我們都靠推進研發(fā)解決，經(jīng)常會出現(xiàn)生產(chǎn)大于消費的情況，針對這些未被消費的內(nèi)存泄漏我們在客戶端做了監(jiān)控和止損，將 onDestory 的 Activity 添加到 WeakRerefrence 中，延遲 60s 監(jiān)控是否回收，未回收則主動釋放泄漏的 Activity 持有的 ViewTree 的背景圖和 ImageView 圖片。
大對象
主要對三種類型的大對象進行優(yōu)化
全局緩存：針對全局緩存我們按需釋放和降級了不需要的緩存，盡量使用弱引用代替強引用關(guān)系，比如針對頻繁泄漏的 EventBus 我們將內(nèi)部的訂閱者關(guān)系改為弱引用解決了大量的 EventBus 泄漏。
系統(tǒng)大對象：系統(tǒng)大對象如 PreloadDrawable、JarFile 我們通過源碼分析確定主動釋放并不干擾原有邏輯，在啟動完成或在內(nèi)存觸頂時主動反射釋放。
動畫：用原生動畫代替了內(nèi)存占用較大的幀動畫，并對 Lottie 動畫泄漏做了手動釋放。
圖 14. 大對象優(yōu)化點
小對象
小對象優(yōu)化我們集中在字段優(yōu)化、業(yè)務(wù)優(yōu)化、緩存優(yōu)化三個緯度，不同的緯度有不同的優(yōu)化策略。
圖 15. 小對象優(yōu)化思路
通用類優(yōu)化
在抖音的業(yè)務(wù)中，視頻是最核心且通用的 Model，抖音業(yè)務(wù)層的數(shù)據(jù)存儲分散在各個業(yè)務(wù)維護了各自視頻的 Model，Model 本身由于聚合了各個業(yè)務(wù)需要的屬性很多導(dǎo)致單個實例內(nèi)存占用就不低，隨著用戶使用過程實例增長內(nèi)存占用越來越大。對 Model 本身我們可以從屬性優(yōu)化和拆分這兩種思路來優(yōu)化。
- 字段優(yōu)化：針對一次性的屬性字段，在使用完之后及時清理掉緩存，比如在視頻 Model 內(nèi)部存在一個 Json 對象，在反序列完成之后 Json 對象就沒有使用價值了，可以及時清理。
- 類拆分：針對通用 Model 冗雜過多的業(yè)務(wù)屬性，嘗試對 Model 本身進行治理，將各個業(yè)務(wù)線需要用到的屬性進行梳理，將 Model 拆分成多個業(yè)務(wù) Model 和一個通用 Model，采用組合的方式讓各個業(yè)務(wù)線最小化依賴自己的業(yè)務(wù) Model，減少大雜燴 Model 不必要的內(nèi)存浪費。
業(yè)務(wù)優(yōu)化
按需加載：抖音這邊 IM 會全局保存會話，App 啟動時會一次性 Load 所有會話，當用戶的會話過多時相應(yīng)全局占用的內(nèi)存就會較大，為了解決該問題，會話列表分兩次加載，首次只加載一定數(shù)量到內(nèi)存，需要時再加載全部。
內(nèi)存緩存限制或清理：首頁推薦列表的每一次 Loadmore 操作，都不會清理之前緩存起來的視頻對象，導(dǎo)致用戶長時間停留在推薦 Feed 時，緩存起來的視頻對象過多會導(dǎo)致內(nèi)存方面的壓力。在通過實驗驗證不會對業(yè)務(wù)產(chǎn)生負面影響情況下對首頁的緩存進行了一定數(shù)量的限制來減小內(nèi)存壓力。
緩存優(yōu)化
上面提到的視頻 Model，抖音最早使用 Manager 來管理通用的視頻實例。Manager 使用 HashMap 存儲了所有的視頻對象，最初的方案里面沒有對內(nèi)存大小進行限制且沒有清除邏輯，隨著使用時間的增加而不斷膨脹，最終出現(xiàn) OOM 異常。為了解決視頻 Model 無限膨脹的問題設(shè)計了一套緩存框架主要流程如下：
圖 16. 視頻緩存框架
使用 LRU 緩存機制來緩存視頻對象。在內(nèi)存中緩存最近使用的 100 個視頻對象，當視頻對象從內(nèi)存緩存中移除時，將其緩存至磁盤中。在獲取視頻對象時，首先從內(nèi)存中獲取，若內(nèi)存中沒有緩存該對象，則從磁盤緩存中獲取。在退出 App 時，清除 Manager 的磁盤緩存，避免磁盤空間占用不斷增長。
圖片
關(guān)于圖片優(yōu)化，我們主要從圖片庫的管理和圖片本身優(yōu)化兩個方面思考。同時對不合理的圖片使用也做了兜底和監(jiān)控。
圖片庫
針對應(yīng)用內(nèi)圖片的使用狀況對圖片庫設(shè)置了合理的緩存，同時在應(yīng)用 or 系統(tǒng)內(nèi)存吃緊的情況下主動釋放圖片緩存。
圖片自身優(yōu)化
我們知道圖片內(nèi)存大小公式 = 圖片分辨率 * 每個像素點的大小。
圖片分辨率我們通過設(shè)置合理的采樣來減少不必要的像素浪費。
//開啟采樣ImagePipelineConfig config = ImagePipelineConfig.newBuilder(context) .setDownsampleEnabled(true) .build();Fresco.initialize(context, config);//請求圖片時，傳入resize的大小，一般直接取View的寬高ImageRequest request = ImageRequestBuilder.newBuilderWithSource(uri) .setResizeOptions(new ResizeOptions(50, 50)) .build();mSimpleDraweeView.setController( Fresco.newDraweeControllerBuilder() .setOldController(mSimpleDraweeView.getController()) .setImageRequest(request) .build());
而單個像素大小，我們通過替換系統(tǒng) drawable 默認色彩通道，將部分沒有透明通道的圖片格式由 ARGB_8888 替換為 RGB565，在圖片質(zhì)量上的損失幾乎肉眼不可見，而在內(nèi)存上可以直接節(jié)省一半。
圖片兜底
針對因 activity、fragment 泄漏導(dǎo)致的圖片泄漏，我們在 onDetachedFromWindow 時機進行了監(jiān)控和兜底，具體流程如下：
圖 17. 圖片兜底流程
圖片監(jiān)控
關(guān)于對不合理的大圖 or 圖片使用我們在字節(jié)碼層面進行了攔截和監(jiān)控，在原生 Bitmap or 圖片庫創(chuàng)建時機記錄圖片信息，對不合理的大圖進行上報；另外在 ImageView 的設(shè)置過程中針對 Bitmap 遠超過 view 本身超過大小的場景也進行了記錄和上報。
圖 18. 圖片字節(jié)碼監(jiān)控方案
更多思考
是不是解決了 OOM 內(nèi)存問題就告一段落了呢？作為一只追求極致的團隊，我們除了解決靜態(tài)的內(nèi)存占用外也自研了 Kenzo（Memory Insight）工具嘗試解決動態(tài)內(nèi)存分配造成的 GC 卡頓。
Kenzo 原理
Kenzo 采用 JVMTI 完成對內(nèi)存監(jiān)控工作，JVMTI（JVM Tool Interface）是 Java 虛擬機所提供的 native 編程接口。JVMTI 開發(fā)時，應(yīng)用建立一個 Agent 使用 JVMTI，可以使用 JVMTI 函數(shù)，設(shè)置回調(diào)函數(shù)，并從 Java 虛擬機中得到當前的運行態(tài)信息，并作出自己的業(yè)務(wù)判斷。
圖 19. Agent 時序圖
Jvmti SetEventCallbacks 方法可以設(shè)置目標虛擬機內(nèi)部事件回調(diào)，可以根據(jù) jvmtiCapabilities 支持的能力和我們關(guān)注的事件來定義需要 hook 的事件。
Kenzo 采用 Jvmti 完成如下事件回調(diào)：
類加載準備事件 -> 監(jiān)控類加載
ClassPrepare：某個類的準備階段完成。
GC -> 監(jiān)控 GC 事件與時間
GarbageCollectionStart：GC 啟動時。
GarbageCollectionFinish：GC 結(jié)束后。
對象事件 -> 監(jiān)控內(nèi)存分配
ObjectFree：GC 釋放一個對象時。
VMObjectAlloc：虛擬機分配一個對象的時候。
框架設(shè)計
Kenzo 整體分為兩個部分：
生產(chǎn)端
采集內(nèi)存數(shù)據(jù)
以 sdk 形式集成到宿主 App
消費端
處理生產(chǎn)端的數(shù)據(jù)
輸入 Kenzo 監(jiān)控的內(nèi)存數(shù)據(jù)
輸出可視化報表
圖 20. kenzo 框架
生產(chǎn)端主要以 Java 進行 API 調(diào)用，C++完成底層檢測邏輯，通過 JNI 完成底層邏輯控制。
消費端主要以 Python 完成數(shù)據(jù)的解析、視圖合成，以 HTML 完成頁面內(nèi)容展示。
工作流
圖 21. kenzo 框架
可視化展示
圖 22. kenzo 聚合展示
啟動階段內(nèi)存歸因
基于動態(tài)內(nèi)存監(jiān)控我們對最為核心的啟動場景的內(nèi)存分配進行了歸因分析，優(yōu)化了一些頭部的內(nèi)存節(jié)點分配:
圖 23.啟動階段內(nèi)存節(jié)點歸因
另外我們也發(fā)現(xiàn)啟動階段存在大量的字符串拼接操作，雖然編譯器已經(jīng)優(yōu)化成了 StringBuider append，但是深入 StringBuider 源碼分析仍在存在大量的動態(tài)擴容動作（System.copy），為了優(yōu)化高頻場景觸發(fā)動態(tài)擴容的性能損耗，在 StringBuilder 在 append的時候，不直接往 char[]里塞東西，而是先拿一個 String[]把它們都存起來，到了最后才把所有 String 的 length 加起來，構(gòu)造一個合理長度的 StringBuilder。通過使用編譯時字節(jié)碼替換的方式，替換所有 StringBuilder 的 append 方法使用自定義實現(xiàn)，優(yōu)化后首次安裝首頁 Feed 滑動 1min 的 FPS 提升 1 幀/S，非首次安裝啟動，滑動 1min 的 FPS 提升 0.6 幀/S。
