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