前言

內存問題是一個普遍問題，但是卻普遍缺少關注度，具體有以下幾個原因：

內存問題相對比較隱蔽，表現并不明顯。

同時android使用Jvm語言開發，垃圾回收是自動的，所以一般沒有特別關注。

內存問題難以定位，出現問題的地方往往只是表現的地方，真正的原因難以收集。

內存優化的內容其實非常多而復雜，我們可以嘗試從以下思路去了解：

要了解內存問題，我們首先要了解為什么要做內存優化？

同時需要了解一些內存優化的背景知識，如垃圾回收機制。

我們需要了解一些內存優化的常用工具與手段。

圖片是內存優化的重點，我們需要重點了解下圖片優化的知識點。

內存問題的一個直接體現是OOM，我們還需要了解下OOM治理的一些手段。

所以我們可以輕松得出本文的主要內容：

為什么要做內存優化？

android內存優化的一些背景知識。

android內存優化的常用工具與手段。

怎么做圖片內存優化？

怎么做OOM線上監控？

本文主要內容思維導圖如下：

1、為什么要做內存優化？

要回答這個問題，我們首先應該明確需求，當我們去做內存優化時是為了什么。

做內存優化的目的是降低OOM率、減少卡頓、增加應用存活時間。

1.1 降低OOM率

做內存優化的一個常見原因是為了降低OOM率。

申請內存過多而沒有及時釋放，常常就會導致OOM。

引起OOM的原因有多種，在后面我們再細談。

1.2 減少卡頓

Android中造成界面卡頓的原因有很多種，其中一種就是由內存問題引起的。

內存問題之所以會影響到界面流暢度，是因為垃圾回收。

在GC時，所有線程都要停止，包括主線程。當GC和繪制界面的操作同時觸發時，繪制的執行就會被擱置，導致掉幀，也就是界面卡頓。

1.3 增加應用存活時間

Android會按照特定的機制清理進程，清理進程時優先會考慮清理后臺進程，如果某個應用在后臺運行并且占用的內存更多，就會被優先清理掉。

我們通常希望App能盡量存活的久一點，所以內存不再使用時應該盡快釋放。

2、android內存優化的一些背景知識

2.1 Java垃圾回收機制

Java內存回收主要包括以下內容：

判斷對象是否回收的可達性分析算法。

強軟弱虛4種引用類型。

用于GC回收的垃圾回收算法。

這些都是很常見的知識點了，這里也就不綴述了，如果想要了解更多細節的同學可參考：Java 垃圾回收機制。

https://juejin.cn/post/6844903897958449166

2.2 什么是內存泄漏？

內存泄漏指的是一塊內存沒有被使用且無法被GC回收，從而造成了內存的浪費，比如Handler匿名內部類持有Activity的引用，Activity 需要銷毀時，GC 就無法回收它。

內存泄漏的表現就是可用內存逐漸減少，無法被回收的內存逐漸累積，直到應用無更多可用內存可申請時，就會導致內存溢出。

內存泄漏的直接原因是長生命周期的對象引用了短生命周期的對象，導致短生命周期對象無法回收。

常見的引起內存泄漏的原因有：

非靜態內部類持有了外部引用。

靜態變量持有了context的引用。

資源沒有及時釋放。

我們一般使用LeakCanary或者Profile檢測內存泄漏。

2.3 什么是內存抖動？

當我們在短時間內頻繁創建大量臨時對象時，就會引起內存抖動，比如在一個for循環中創建臨時對象實例，下面這張圖就是內存抖動時的一個內存圖表現，它的形狀是鋸齒形的，而中間的垃圾桶代表著一次GC。

內存抖動意味著頻繁的創建對象與回收，容易觸發GC，而當GC時所有線程都會停止，因此可能導致卡頓。

為了避免內存抖動，我們應該避免以下操作：

盡量避免在循環體中創建對象。

盡量不要在自定義View的onDraw（）方法中創建對象，因為這個方法會被頻繁調用。

對于能夠復用的對象，可以考慮使用對象池把它們緩存起來。

2.4 什么是內存溢出？

內存溢出即申請的內存超出可用的內存，即OOM，這會導致我們的程序異常退出，這也是我們重點關注的指標。

引起OOM的原因可能有多種，主要可以分為以下幾類：

關于OOM治理及線上監控等，后面會詳細介紹。

3、android內存優化的常用工具與手段

3.1 Memory Profiler

Memory Profiler是Profiler 中的其中一個版塊，Profiler 是 Android Studio 為我們提供的性能分析工具，使用 Profiler 能分析應用的 CPU、內存、網絡以及電量的使用情況。

使用Memory可以檢測以下功能：

查看內存曲線及內存占用情況。

可以定位是否存在內存抖動問題。

堆轉儲（Dump Java Heap）可檢測出內存泄漏的對象。

關于Memory Profiler的具體使用就不在此綴述了，想要了解的可參考：什么是 Memory Profiler？

https://juejin.cn/post/6844903897958449166

3.2 Memory Analyzer Tool

MAT工具可以幫助開發者定位導致內存泄漏的對象，以及發現大的內存對象，然后解決內存泄漏并通過優化內存對象，以達到減少內存消耗的目的。

比起Memory Profiler，MAT使用起來更加麻煩，同時現在Memory Profiler功能也越來越強大了，所以我現在已經很少使用MAT了。

如果想要更多地了解MAT，也可以參考：什么是Memory Analyzer Tool。

https://juejin.cn/post/6844903897958449166#heading-52

3.3 LeakCanary檢測內存泄漏

相比Memory Profiler與MAT，LeakCanary在使用上更加簡便。

只需要在項目中添加依賴，即可自動地檢測內存泄漏并報警，使用起來非常方便。

LeakCanary有以下幾個特點：

不需要手動初始化。

可自動檢測內存泄漏并通過通知報警。

不能用于線上。

LeakCanary檢測流程如下

關于LeakCanary的原理，我之前曾經總結過一篇文章，有興趣的同學也可以參考：【帶著問題學】關于LeakCanary2.0你應該知道的知識點。

https://juejin.cn/post/6968084138125590541

3.4 內存優化的一些常規手段

內存優化的一些細節問題可以在開發時避免，下面介紹一些常規的內存優化手段。

1）、使用LargeHeap屬性增加最大可用內存。

2）、在系統觸發資源緊張回調時，主動刪除緩存。

3）、使用優化過后的集合：如SparseArray類等。

4）、謹慎使用 SharedPreference，SP會在應用初始化時將所有內容加載到內存中，所以不應該存放比較大的內容。

5）、謹慎使用外部庫，引入時需要明確不會對應用性能造成大的影響。

6）、業務架構設計要合理，抽象可以優化代碼的靈活性和可維護性，但是抽象也會帶來其他成本，應權衡使用。

這些細節問題其實都很普通，如果平時注意到了，相信對應用的內存一定有所幫助。

4、怎么做圖片內存優化？

內存優化應該優先去做見效快的地方，圖片內存優化是內存優化的重點，可能一張圖片沒有回收就會造成幾M內存的浪費。

4.1 常規的圖片內存優化方法

我們都知道，圖片所占內存=寬高一像素占用內存。

所以優化圖片內存主要有以下幾個思路：

縮放減小寬高。

減少每個像素所占用的內存。

內存復用，避免重復分配內存。

對于大圖，可以采取局部加載的策略。

4.1.1 減少圖片寬高

有時圖片寬高為200*200， 而View寬高為100*100， 這種時候如果展示200*200的圖片沒有意義，應該對圖片進行縮放。

這種情況一般通過inSampleSize實現。

BitampFactory.Options options = new BitmapFactory.Options（）;

// 設置為4就是寬和高都變為原來1/4大小的圖片

options.inSampleSize = 4;

BitmapFactory.decodeSream（is， null， options）;

4.1.2 減少每個像素所占用的內存

在API29中，將Bitmap分為ALPHA_8， RGB_565， ARGB_4444， ARGB_8888， RGBA_F16， HARDWARE六個等級。

ALPHA_8：不存儲顏色信息，每個像素占1個字節；

RGB_565：僅存儲RGB通道，每個像素占2個字節，對Bitmap色彩沒有高要求，可以使用該模式；

ARGB_4444：已棄用，用ARGB_8888代替；

ARGB_8888：每個像素占用4個字節，保持高質量的色彩保真度，默認使用該模式；

RGBA_F16：每個像素占用8個字節，適合寬色域和HDR；

HARDWARE：一種特殊的配置，減少了內存占用同時也加快了Bitmap的繪制。

每個等級每個像素所占用的字節也都不一樣，所存儲的色彩信息也不同。同一張100像素的圖片，ARGB_8888就占了400字節，RGB_565才占200字節。

所以在某些場景中，修改圖片格式可以達到減少一半內存的效果。

4.1.3 內存復用，避免重復分配內存

Bitmap所占內存比較大，如果我們頻繁創建與回收Bitmap，那么很容易造成內存抖動，所以我們應該盡量復用Bitmap內存。

在 Android 3.0（API 級別 11）開始，系統引入了BitmapFactory.Options.inBitmap字段。如果設置了此選項，那么采用 Options 對象的解碼方法會在生成目標 Bitmap 時嘗試復用 inBitmap，這意味著 inBitmap 的內存得到了重復使用，從而提高了性能，同時移除了內存分配和取消分配。

不過 inBitmap 的使用方式存在某些限制，在 Android 4.4（API 級別 19）之前系統僅支持復用大小相同的位圖，4.4 之后只要 inBitmap 的大小比目標 Bitmap 大即可。

4.1.4 大圖局部加載策略

對于圖片加載還有種情況，就是單個圖片非常巨大，并且還不允許壓縮。比如顯示：世界地圖、清明上河圖、微博長圖等。

首先不壓縮，按照原圖尺寸加載，那么屏幕肯定是不夠大的，并且考慮到內存的情況，不可能一次性整圖加載到內存中。

所以這種情況的優化思路一般是局部加載，通過BitmapRegionDecoder來實現。

//設置顯示圖片的中心區域

BitmapRegionDecoder bitmapRegionDecoder = BitmapRegionDecoder.newInstance（inputStream， false）;

BitmapFactory.Options options = new BitmapFactory.Options（）;

options.inPreferredConfig = Bitmap.Config.RGB_565;

Bitmap bitmap = bitmapRegionDecoder.decodeRegion（new Rect（width / 2 - 100， height / 2 - 100， width / 2 + 100， height / 2 + 100）， options）;

mImageView.setImageBitmap（bitmap）;

4.1.5 小結

上面所說的這些關于Bitmap的內存優化策略其實都比較簡單，而且我們在開發中可能很少用到

因為我們常用的圖片框架比如Glide已經將這些都封裝在里面了，所以一般情況下我們加載圖片時不需要做這些特殊操作。

關于Glide對于加載圖片都做了哪些優化，有興趣的同學可以參考：【帶著問題學】Glide做了哪些優化？

https://juejin.cn/post/6970683481127043085

4.2 圖片兜底策略

針對因activity、fragment泄漏導致的圖片泄漏，我們可以在onDetachedFromWindow時機進行了監控和兜底，具體流程如下：

通過這種方式可以方便地解決因Activity導致的圖片泄漏問題。

4.3 線上大圖監控方案

當運營在線上配置了不合理大小的圖片時，如果我們及時發現，也會帶來內存問題。

如果圖片本身大小就不合理，我們在這個基礎上談圖片優化也沒有什么意義，因此大圖監控這也是個比較常見的需求。

下面介紹幾種大圖監控的方案：

4.3.1 ArtHook 方案

該方案采用weishu大佬寫的epic庫實現，通過對ART虛擬機的hook，hook ImageView的 setImageBitmap 等方法。

解析對比方法參數中的 bitmap 寬高和 ImageView 實例的寬高，也可以獲得bitmap的實際大小。

如果圖片寬高比ImageView寬高大，或者圖片大小超出了閾值，就可以把相關信息上報。

這種方案的優點在于：

侵入性極低，一次初始化配置即可hook全局的目標View控件。

可以獲取代碼調用堆棧，方便開發者快速定位。

而缺點則在于：

兼容性存在問題，使用了hook系統API ，不能用于線上。

4.3.2 BaseActivity 方案

大部分應用工程在業務發展的過程中都會沉淀封裝自己的BaseActivity ，通過在BaseActivity onDestroy中動態地檢測各個View控件，從而獲知圖片加載情況。

class BaseActivity ： Activity（）{

fun onDestory（）{

if（isOpenCheckBitmap）{

checkBitmapFromView（）

}

}

fun checkBitmapFromView（）{

//1、遍歷activity中的各個View控件

//2、獲取View控件加載的Bitmap

//3、對比Bitmap寬高與View寬高

}

}

這種方案的優點在于：

兼容性強，無任何反射。

加入簡單，沒有什么復雜邏輯。

缺點在于：

侵入性太強，需要修改BaseActivity。

BaseActivity.onDestory本身可能被重寫，并不安全。

4.3.3 ASM方案

該方案在編譯流程進行插樁，通過匹配setImageBitmap、 setBackground等關鍵方法，插入Bitmap大小檢測邏輯。

這種方案優點在于：

編譯時期插樁，對開發過程無侵入性。

缺點在于：

通過插樁的方式打點，可能會增加編譯期耗時。

ASM代碼維護成本較高，使用起來不是那么方便。

4.3.4 registerActivityLifecycleCallback方案

通過registerActivityLifecycleCallback監聽Activity生命周期，在onStop時進行Bitmap大小檢測的邏輯。

private fun registerActivityLifecycleCallback（application： Application） {

application.registerActivityLifecycleCallbacks（object ：

Application.ActivityLifecycleCallbacks {

override fun onActivityStopped（activity： Activity） {

checkBitmapIsTooBig（childViews）

}

}）

}

這種方案對原始代碼無侵入性，同時使用起來比較簡單，也沒有兼容性問題，應該屬于比較良好的方案。

詳細實現可見：BitmapCanary 誕生。

https://juejin.cn/post/6956138531789996040#heading-14

5、怎么做OOM線上監控？

上文我們介紹了，可以使用LeakCanary在線下監測內存泄漏，但是LeakCanary只能在線下使用，有以下問題：

線下場景能跑到的場景有限，很難把所有用戶場景窮盡。碰到線上問題難以定位。

檢測過程需要主動觸發GC，Dump內存鏡像造成app凍結，造成測試過程中體驗不好。

適用范圍有限，只能定位Activity&Fragment泄漏，無法定位大對象、頻繁分配等問題。

hprof文件過大，如果整體上傳的話需要耗費很多資源。

下面我們就介紹一下快手開源的線上OOM監控框架KOOM。

5.1 線上OOM監控框架KOOM介紹

上面我們介紹了LeakCanary不能用于線上監控的原因，所以要實現線上監控功能，就需要解決以下問題：

1、監控

主動觸發GC，會造成卡頓

2、采集

Dump hprof，會造成app凍結

Hprof文件過大

3、解析

解析耗時過長

解析本身有OOM風險

其核心流程為三部分：

監控OOM，發生問題時觸發內存鏡像的采集，以便進一步分析問題。

采集內存鏡像，學名堆轉儲，將內存數據拷貝到文件中，以下簡稱dump hprof。

解析鏡像文件，對泄漏、超大對象等我們關注的對象進行可達性分析，解析出其到GC root的引用鏈以解決問題。

5.2 KOOM解決GC卡頓

LeakCanary通過多次GC的方式來判斷對象是否被回收，所以會造成性能損耗。

koom通過無性能損耗的內存閾值監控來觸發鏡像采集，具體策略如下：

1、Java堆內存/線程數/文件描述符數突破閾值觸發采集。

2、Java堆上漲速度突破閾值觸發采集。

3、發生OOM時如果策略1、2未命中 觸發采集。

4、泄漏判定延遲至解析時。

我們并不需要在運行時判定對象是否泄漏，以Activity為例，我們并不需要在運行時判定其是否泄漏，Activity有一個成員變量mDestroyed，在onDestory時會被置為true，只要解析時發現有可達且mDestroyed為true的Activity，即可判定為泄漏。

通過將泄漏判斷延遲至解析時，即可解決GC卡頓的問題。

5.3 KOOM解決Dump hprof凍結app

Dump hprof即采集內存鏡像需要暫停虛擬機，以確保在內存數據拷貝到磁盤的過程中，引用關系不會發生變化，暫停時間通常長達10秒以上，對用戶來講是難以接受的，這也是LeakCanary官方不推薦線上使用的重要原因之一。

利用Copy-on-write機制，fork子進程dump內存鏡像，可以完美解決這一問題，fork成功以后，父進程立刻恢復虛擬機運行，子進程dump內存鏡像期間不會受到父進程數據變動的影響。

流程如下圖所示：

KOOM隨機采集線上真實用戶的內存鏡像，普通dump和fork子進程dump阻塞用戶使用的耗時如下：

可以看出，基本可以做到無感知的采集內存鏡像。

5.4 KOOM解決hprof文件過大

Hprof文件通常比較大，分析OOM時遇到500M以上的hprof文件并不稀奇，文件的大小，與dump成功率、dump速度、上傳成功率負相關，且大文件額外浪費用戶大量的磁盤空間和流量。

因此需要對hprof進行裁剪，只保留分析OOM必須的數據，另外，裁剪還有數據脫敏的好處，只上傳內存中類與對象的組織結構，并不上傳真實的業務數據（諸如字符串、byte數組等含有具體數據的內容），保護用戶隱私。

裁剪hprof文件涉及到對hprof文件格式的了解，這里就不綴述了。

5.5 KOOM解決hprof解析的耗時與OOM

解析hprof文件，對關鍵對象進行可達性分析，得到引用鏈，是解決OOM最核心的一步，之前的監控和dump都是為解析做鋪墊。

解析分兩種，一種是上傳hprof文件由server解析，另一種是在客戶端解析后上傳報告（通常只有幾KB）。

KOOM選擇了端上解析，這樣做有兩個好處：

節省用戶流量。

利用用戶閑時算力，降低server壓力，這樣也符合分布式計算理念。

這樣就可以把解析過程拆解成以下兩個問題：

1、哪些對象需要分析，全部分析性能開銷太大，很難在端上完成，并且問題沒有重點也不利于解決。

2、性能優化，作為一個debug組件，要在不影響用戶體驗的情況下完成解析，對性能有非常高的要求。

5.5.1 關鍵對象判定

KOOM只解析關鍵的對象，關鍵對象分為兩類，一類是根據規則可以判斷出對象已經泄露，且持有大量資源的，另外一類是對象shallow / retained size 超過閾值。

Activity/fragment泄露判定即為第一種：

對于強可達的activity對象，其mDestroyed值為true時（onDestroy時賦值），判定已經泄露。

類似的，對于fragment，當mCalled值為true且mFragmentManager為null時，判定已經泄露。

Bitmap/window/array/sufacetexture判定為第二種。

檢查bitmap/texture的數量、寬高、window數量、array長度等等是否超過閾值，再結合hprof中的相關業務信息，比如屏幕大小，view大小等進行判定。

5.5.2 性能優化

KOOM在LeakCanary解析引擎shark的基礎上做了一些優化，將解析時間在shark的基礎上優化了2倍以上，內存峰值控制在100M以內。用一張圖總結解析的流程：

詳細流程就不在這里綴述了，詳情可見：KOOM解析性能優化。

https://juejin.cn/post/6860014199973871624#heading-13

5.6 KOOM使用

KOOM目前已經開源，開源地址：

https://github.com/KwaiAppTeam/KOOM

直接參照接入指南接入即可，當發現內存超過閾值或者發生OOM時，就會觸發采集內存快照，對hprof文件進行裁剪并分析后得到報告。

KOOM的報告是json格式，并且大小在KB級別，樣式如下所示：

大概包括以下信息：

一些可能泄漏的類信息。

泄漏原因，gcRoot，泄漏實例數量等。

泄漏對象的引用鏈，方便定位問題。

可見KOOM上傳的數據量并不太大，但相對準確，非常便于我們分析線上數據。

5.7 小結

本章主要介紹了線上監控OOM的開源框架KOOM。

其實線上監控OOM的框架各大廠都有開發，比如美團的Probe，字節的Liko。

https://tech.meituan.com/2019/11/14/crash-oom-probe-practice.html

https://juejin.cn/post/6908517174667804680#heading-7

不過大部分都沒有正式開源，只是一些文章介紹原理，有興趣的同學也可以都了解下。

總結

對于優化的大方向，我們應該優先去做見效快的地方，主要有以下幾個部分：

內存泄漏。

內存抖動。

Bitmap大圖監控。

OOM線上監控。

我們還介紹了內存優化的多種實用工具：

可以使用Profile，MAT在開發時定位內存抖動內存泄漏問題。

線下開發、回歸、Monkey、壓測等環節可以自動集成LeakCanary檢測內存泄漏；

圖片加載是內存優化的重點，我們可以結合圖片兜底策略與線上大圖監控，優化圖片內存問題。

線上OOM時通過KOOM監測，內存超出閾值時主動dump內存快照，通過上傳分析結果精準。分析OOM問題。

內存優化是個復雜的過程，我們在做內存優化的過程中，需要結合多種工具，線上線下結合，系統化地配合來定位與解決問題。

作者：RicardoMJiang

https://juejin.cn/post/6975876569990447134

責任編輯：haq