記憶體作為計算機程式運行最重要的資源之一，需要運行程序中做到合理的資源分配與回收，不合理的記憶體占用輕則使得用戶應用程式運行卡頓、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. 圖片位元組碼監控方案

加入我們

我們是負責抖音客戶端基礎技術能力研發和前沿技術探索的客戶端團隊，我們專注于性能、架構、穩定性、研發工具、編譯構建等方向的深耕，保障超大規模團隊的研發效率和工程質量，將 6 億人使用的抖音打造成極致用戶體驗的產品，

如果你對技術充滿熱情，歡迎加入抖音基礎技術團隊，讓我們共建億級全球化 App，目前我們在上海、北京、杭州、深圳均有招聘需求，內推可以聯系郵箱： tech@bytedance.com ；郵件標題： 姓名 - 作業年限 - 抖音 - 基礎技術 - Android / iOS ，

抖音 Android 性能優化系列：Java 記憶體優化篇

抖音 Java OOM 背景

Java OOM Top 堆疊歸因

堆記憶體治理思路

工具建設

工具思路

線下

線上

Liko 介紹

Liko 整體架構

Liko 流程圖

Hprof 收集

Hprof 分析時機

分析策略

端上分析

分析引擎

記憶體泄漏

大物件

小物件

圖片

回傳分析

裁剪程序

優化實踐

記憶體泄漏

系統異步 UI 泄漏

記憶體泄漏兜底

大物件

小物件

通用類優化

業務優化

快取優化

圖片

圖片庫

圖片自身優化

圖片兜底

圖片監控

更多思考

Kenzo 原理

生產端

消費端

作業流

可視化展示

啟動階段記憶體歸因

加入我們

更多分享