吹爆系列享學(xué)新課教育提示：Android 內(nèi)存還可以這樣優(yōu)化！
內(nèi)存問題是一個普遍問題，但是卻普遍缺少關(guān)注度，具體有以下幾個原因：
內(nèi)存問題相對比較隱蔽，表現(xiàn)并不明顯。
同時android使用Jvm語言開發(fā)，垃圾回收是自動的，所以一般沒有特別關(guān)注。
內(nèi)存問題難以定位，出現(xiàn)問題的地方往往只是表現(xiàn)的地方，真正的原因難以收集。
內(nèi)存優(yōu)化的內(nèi)容其實(shí)非常多而復(fù)雜，我們可以嘗試從以下思路去了解：
要了解內(nèi)存問題，我們首先要了解為什么要做內(nèi)存優(yōu)化？
同時需要了解一些內(nèi)存優(yōu)化的背景知識，如垃圾回收機(jī)制。
我們需要了解一些內(nèi)存優(yōu)化的常用工具與手段。
圖片是內(nèi)存優(yōu)化的重點(diǎn)，我們需要重點(diǎn)了解下圖片優(yōu)化的知識點(diǎn)。
內(nèi)存問題的一個直接體現(xiàn)是OOM,我們還需要了解下OOM治理的一些手段。
所以我們可以輕松得出本文的主要內(nèi)容：
為什么要做內(nèi)存優(yōu)化?
android內(nèi)存優(yōu)化的一些背景知識。
android內(nèi)存優(yōu)化的常用工具與手段。
怎么做圖片內(nèi)存優(yōu)化？
怎么做OOM線上監(jiān)控?
本文主要內(nèi)容思維導(dǎo)圖如下：
1、為什么要做內(nèi)存優(yōu)化?
要回答這個問題，我們首先應(yīng)該明確需求，當(dāng)我們?nèi)プ鰞?nèi)存優(yōu)化時是為了什么。
做內(nèi)存優(yōu)化的目的是降低OOM率、減少卡頓、增加應(yīng)用存活時間。
1.1 降低OOM率
做內(nèi)存優(yōu)化的一個常見原因是為了降低OOM率。
申請內(nèi)存過多而沒有及時釋放，常常就會導(dǎo)致OOM。
引起OOM的原因有多種，在后面我們再細(xì)談。
1.2 減少卡頓
Android中造成界面卡頓的原因有很多種，其中一種就是由內(nèi)存問題引起的。
內(nèi)存問題之所以會影響到界面流暢度，是因?yàn)槔厥铡?/p>
在GC時，所有線程都要停止，包括主線程.當(dāng)GC和繪制界面的操作同時觸發(fā)時，繪制的執(zhí)行就會被擱置，導(dǎo)致掉幀，也就是界面卡頓。
1.3 增加應(yīng)用存活時間
Android會按照特定的機(jī)制清理進(jìn)程，清理進(jìn)程時優(yōu)先會考慮清理后臺進(jìn)程，如果某個應(yīng)用在后臺運(yùn)行并且占用的內(nèi)存更多，就會被優(yōu)先清理掉。
我們通常希望App能盡量存活的久一點(diǎn)，所以內(nèi)存不再使用時應(yīng)該盡快釋放。
2、android內(nèi)存優(yōu)化的一些背景知識
2.1 Java垃圾回收機(jī)制
Java內(nèi)存回收主要包括以下內(nèi)容：
判斷對象是否回收的可達(dá)性分析算法。
強(qiáng)軟弱虛4種引用類型。
用于GC回收的垃圾回收算法。
這些都是很常見的知識點(diǎn)了，這里也就不綴述了，如果想要了解更多細(xì)節(jié)的同學(xué)可參考：Java 垃圾回收機(jī)制。
https://juejin.cn/post/6844903897958449166
2.2 什么是內(nèi)存泄漏?
內(nèi)存泄漏指的是一塊內(nèi)存沒有被使用且無法被GC回收，從而造成了內(nèi)存的浪費(fèi)，比如Handler匿名內(nèi)部類持有Activity的引用，Activity 需要銷毀時，GC 就無法回收它。
內(nèi)存泄漏的表現(xiàn)就是可用內(nèi)存逐漸減少，無法被回收的內(nèi)存逐漸累積，直到應(yīng)用無更多可用內(nèi)存可申請時，就會導(dǎo)致內(nèi)存溢出。
內(nèi)存泄漏的直接原因是長生命周期的對象引用了短生命周期的對象，導(dǎo)致短生命周期對象無法回收。
常見的引起內(nèi)存泄漏的原因有：
非靜態(tài)內(nèi)部類持有了外部引用。
靜態(tài)變量持有了context的引用。
資源沒有及時釋放。
我們一般使用LeakCanary或者Profile檢測內(nèi)存泄漏。
2.3 什么是內(nèi)存抖動?
當(dāng)我們在短時間內(nèi)頻繁創(chuàng)建大量臨時對象時，就會引起內(nèi)存抖動，比如在一個for循環(huán)中創(chuàng)建臨時對象實(shí)例，下面這張圖就是內(nèi)存抖動時的一個內(nèi)存圖表現(xiàn)，它的形狀是鋸齒形的，而中間的垃圾桶代表著一次GC。
內(nèi)存抖動意味著頻繁的創(chuàng)建對象與回收，容易觸發(fā)GC，而當(dāng)GC時所有線程都會停止，因此可能導(dǎo)致卡頓。
為了避免內(nèi)存抖動，我們應(yīng)該避免以下操作：
盡量避免在循環(huán)體中創(chuàng)建對象。
盡量不要在自定義View的
onDraw()方法中創(chuàng)建對象，因?yàn)檫@個方法會被頻繁調(diào)用。對于能夠復(fù)用的對象，可以考慮使用對象池把它們緩存起來。
2.4 什么是內(nèi)存溢出?
內(nèi)存溢出即申請的內(nèi)存超出可用的內(nèi)存，即OOM，這會導(dǎo)致我們的程序異常退出,這也是我們重點(diǎn)關(guān)注的指標(biāo)。
引起OOM的原因可能有多種，主要可以分為以下幾類：
關(guān)于OOM治理及線上監(jiān)控等，后面會詳細(xì)介紹。
3、android內(nèi)存優(yōu)化的常用工具與手段
3.1 Memory Profiler
Memory Profiler是Profiler 中的其中一個版塊，Profiler 是 Android Studio 為我們提供的性能分析工具，使用 Profiler 能分析應(yīng)用的 CPU、內(nèi)存、網(wǎng)絡(luò)以及電量的使用情況。
使用Memory可以檢測以下功能：
查看內(nèi)存曲線及內(nèi)存占用情況。
可以定位是否存在內(nèi)存抖動問題。
堆轉(zhuǎn)儲（Dump Java Heap）可檢測出內(nèi)存泄漏的對象。
關(guān)于Memory Profiler的具體使用就不在此綴述了，想要了解的可參考：什么是 Memory Profiler？
https://juejin.cn/post/6844903897958449166
3.2 Memory Analyzer Tool
MAT工具可以幫助開發(fā)者定位導(dǎo)致內(nèi)存泄漏的對象，以及發(fā)現(xiàn)大的內(nèi)存對象，然后解決內(nèi)存泄漏并通過優(yōu)化內(nèi)存對象，以達(dá)到減少內(nèi)存消耗的目的。
比起Memory Profiler，MAT使用起來更加麻煩，同時現(xiàn)在Memory Profiler功能也越來越強(qiáng)大了，所以我現(xiàn)在已經(jīng)很少使用MAT了。
如果想要更多地了解MAT，也可以參考:什么是Memory Analyzer Tool。
https://juejin.cn/post/6844903897958449166#heading-52
3.3 LeakCanary檢測內(nèi)存泄漏
相比Memory Profiler與MAT,LeakCanary在使用上更加簡便。
只需要在項(xiàng)目中添加依賴，即可自動地檢測內(nèi)存泄漏并報警，使用起來非常方便。
當(dāng)發(fā)生泄漏時，引用鏈如下：
LeakCanary有以下幾個特點(diǎn)：
不需要手動初始化。
可自動檢測內(nèi)存泄漏并通過通知報警。
不能用于線上。
LeakCanary檢測流程如下：
關(guān)于LeakCanary的原理，我之前曾經(jīng)總結(jié)過一篇文章，有興趣的同學(xué)也可以參考:【帶著問題學(xué)】關(guān)于LeakCanary2.0你應(yīng)該知道的知識點(diǎn)。
https://juejin.cn/post/6968084138125590541
3.4 內(nèi)存優(yōu)化的一些常規(guī)手段
內(nèi)存優(yōu)化的一些細(xì)節(jié)問題可以在開發(fā)時避免，下面介紹一些常規(guī)的內(nèi)存優(yōu)化手段。
1）、使用LargeHeap屬性增加最大可用內(nèi)存。
2）、在系統(tǒng)觸發(fā)資源緊張回調(diào)時，主動刪除緩存。
3）、使用優(yōu)化過后的集合：如SparseArray類等。
4）、謹(jǐn)慎使用 SharedPreference,SP會在應(yīng)用初始化時將所有內(nèi)容加載到內(nèi)存中，所以不應(yīng)該存放比較大的內(nèi)容。
5）、謹(jǐn)慎使用外部庫，引入時需要明確不會對應(yīng)用性能造成大的影響。
6）、業(yè)務(wù)架構(gòu)設(shè)計要合理,抽象可以優(yōu)化代碼的靈活性和可維護(hù)性，但是抽象也會帶來其他成本,應(yīng)權(quán)衡使用。
這些細(xì)節(jié)問題其實(shí)都很普通，如果平時注意到了，相信對應(yīng)用的內(nèi)存一定有所幫助。
4、怎么做圖片內(nèi)存優(yōu)化？
內(nèi)存優(yōu)化應(yīng)該優(yōu)先去做見效快的地方，圖片內(nèi)存優(yōu)化是內(nèi)存優(yōu)化的重點(diǎn)，可能一張圖片沒有回收就會造成幾M內(nèi)存的浪費(fèi)。
4.1 常規(guī)的圖片內(nèi)存優(yōu)化方法
我們都知道，圖片所占內(nèi)存=寬高一像素占用內(nèi)存。
所以優(yōu)化圖片內(nèi)存主要有以下幾個思路：
縮放減小寬高。
減少每個像素所占用的內(nèi)存。
內(nèi)存復(fù)用，避免重復(fù)分配內(nèi)存。
對于大圖，可以采取局部加載的策略。
4.1.1 減少圖片寬高
有時圖片寬高為200*200, 而View寬高為100*100, 這種時候如果展示200*200的圖片沒有意義，應(yīng)該對圖片進(jìn)行縮放。
這種情況一般通過inSampleSize實(shí)現(xiàn)。
BitampFactory.Options?options?=?new?BitmapFactory.Options();
//?設(shè)置為4就是寬和高都變?yōu)樵瓉?/4大小的圖片
options.inSampleSize?=?4;
BitmapFactory.decodeSream(is,?null,?options);
4.1.2 減少每個像素所占用的內(nèi)存
在API29中，將Bitmap分為ALPHA_8, RGB_565, ARGB_4444, ARGB_8888, RGBA_F16, HARDWARE六個等級。
ALPHA_8：不存儲顏色信息，每個像素占1個字節(jié)；
RGB_565：僅存儲RGB通道，每個像素占2個字節(jié)，對Bitmap色彩沒有高要求，可以使用該模式；
ARGB_4444：已棄用，用ARGB_8888代替；
ARGB_8888：每個像素占用4個字節(jié)，保持高質(zhì)量的色彩保真度，默認(rèn)使用該模式；
RGBA_F16：每個像素占用8個字節(jié)，適合寬色域和HDR；
HARDWARE：一種特殊的配置，減少了內(nèi)存占用同時也加快了Bitmap的繪制。
每個等級每個像素所占用的字節(jié)也都不一樣，所存儲的色彩信息也不同。同一張100像素的圖片，ARGB_8888就占了400字節(jié)，RGB_565才占200字節(jié)。
所以在某些場景中，修改圖片格式可以達(dá)到減少一半內(nèi)存的效果。
4.1.3 內(nèi)存復(fù)用，避免重復(fù)分配內(nèi)存
Bitmap所占內(nèi)存比較大，如果我們頻繁創(chuàng)建與回收Bitmap，那么很容易造成內(nèi)存抖動,所以我們應(yīng)該盡量復(fù)用Bitmap內(nèi)存。
在 Android 3.0（API 級別 11）開始，系統(tǒng)引入了BitmapFactory.Options.inBitmap字段。如果設(shè)置了此選項(xiàng)，那么采用 Options 對象的解碼方法會在生成目標(biāo) Bitmap 時嘗試復(fù)用 inBitmap，這意味著 inBitmap 的內(nèi)存得到了重復(fù)使用，從而提高了性能，同時移除了內(nèi)存分配和取消分配。
不過 inBitmap 的使用方式存在某些限制，在 Android 4.4（API 級別 19）之前系統(tǒng)僅支持復(fù)用大小相同的位圖，4.4 之后只要 inBitmap 的大小比目標(biāo) Bitmap 大即可。
4.1.4 大圖局部加載策略
對于圖片加載還有種情況，就是單個圖片非常巨大，并且還不允許壓縮。比如顯示：世界地圖、清明上河圖、微博長圖等。
首先不壓縮，按照原圖尺寸加載，那么屏幕肯定是不夠大的，并且考慮到內(nèi)存的情況，不可能一次性整圖加載到內(nèi)存中。
所以這種情況的優(yōu)化思路一般是局部加載，通過BitmapRegionDecoder來實(shí)現(xiàn)。
//設(shè)置顯示圖片的中心區(qū)域
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 小結(jié)
上面所說的這些關(guān)于Bitmap的內(nèi)存優(yōu)化策略其實(shí)都比較簡單，而且我們在開發(fā)中可能很少用到
因?yàn)槲覀兂Ｓ玫膱D片框架比如Glide已經(jīng)將這些都封裝在里面了，所以一般情況下我們加載圖片時不需要做這些特殊操作。
關(guān)于Glide對于加載圖片都做了哪些優(yōu)化，有興趣的同學(xué)可以參考:【帶著問題學(xué)】Glide做了哪些優(yōu)化?
https://juejin.cn/post/6970683481127043085
4.2 圖片兜底策略
針對因activity、fragment泄漏導(dǎo)致的圖片泄漏，我們可以在onDetachedFromWindow時機(jī)進(jìn)行了監(jiān)控和兜底，具體流程如下：
通過這種方式可以方便地解決因Activity導(dǎo)致的圖片泄漏問題。
4.3 線上大圖監(jiān)控方案
當(dāng)運(yùn)營在線上配置了不合理大小的圖片時，如果我們及時發(fā)現(xiàn)，也會帶來內(nèi)存問題。
如果圖片本身大小就不合理，我們在這個基礎(chǔ)上談圖片優(yōu)化也沒有什么意義，因此大圖監(jiān)控這也是個比較常見的需求。
下面介紹幾種大圖監(jiān)控的方案：
4.3.1 ArtHook 方案
該方案采用weishu大佬寫的epic庫實(shí)現(xiàn)，通過對ART虛擬機(jī)的hook，hook ImageView的 setImageBitmap 等方法。
解析對比方法參數(shù)中的 bitmap 寬高和 ImageView 實(shí)例的寬高，也可以獲得bitmap的實(shí)際大小。
如果圖片寬高比ImageView寬高大，或者圖片大小超出了閾值，就可以把相關(guān)信息上報。
這種方案的優(yōu)點(diǎn)在于：
侵入性極低，一次初始化配置即可hook全局的目標(biāo)View控件。
可以獲取代碼調(diào)用堆棧，方便開發(fā)者快速定位。
而缺點(diǎn)則在于:
兼容性存在問題，使用了hook系統(tǒng)API ,不能用于線上。
4.3.2 BaseActivity 方案
大部分應(yīng)用工程在業(yè)務(wù)發(fā)展的過程中都會沉淀封裝自己的BaseActivity ，通過在BaseActivity onDestroy中動態(tài)地檢測各個View控件，從而獲知圖片加載情況。
class?BaseActivity?:?Activity(){
????fun?onDestory(){
????????if(isOpenCheckBitmap){
????????????checkBitmapFromView()
????????}
????}
????fun?checkBitmapFromView(){
????????//1、遍歷activity中的各個View控件
????????//2、獲取View控件加載的Bitmap
????????//3、對比Bitmap寬高與View寬高
????}
}
這種方案的優(yōu)點(diǎn)在于：
兼容性強(qiáng)，無任何反射。
加入簡單，沒有什么復(fù)雜邏輯。
缺點(diǎn)在于：
侵入性太強(qiáng)，需要修改BaseActivity。
BaseActivity.onDestory本身可能被重寫,并不安全。
4.3.3 ASM方案
該方案在編譯流程進(jìn)行插樁，通過匹配setImageBitmap、?setBackground等關(guān)鍵方法，插入Bitmap大小檢測邏輯。
這種方案優(yōu)點(diǎn)在于：
編譯時期插樁，對開發(fā)過程無侵入性。
缺點(diǎn)在于：
通過插樁的方式打點(diǎn)，可能會增加編譯期耗時。
ASM代碼維護(hù)成本較高，使用起來不是那么方便。
4.3.4 registerActivityLifecycleCallback方案
通過registerActivityLifecycleCallback監(jiān)聽Activity生命周期,在onStop時進(jìn)行Bitmap大小檢測的邏輯。
private?fun?registerActivityLifecycleCallback(application:?Application)?{
????application.registerActivityLifecycleCallbacks(object?:
????????Application.ActivityLifecycleCallbacks?{
????????override?fun?onActivityStopped(activity:?Activity)?{
????????????checkBitmapIsTooBig(childViews)
????????}
????})
}
這種方案對原始代碼無侵入性，同時使用起來比較簡單，也沒有兼容性問題，應(yīng)該屬于比較良好的方案.
詳細(xì)實(shí)現(xiàn)可見：BitmapCanary 誕生。
https://juejin.cn/post/6956138531789996040#heading-14
5、怎么做OOM線上監(jiān)控?
上文我們介紹了，可以使用LeakCanary在線下監(jiān)測內(nèi)存泄漏，但是LeakCanary只能在線下使用,有以下問題：
線下場景能跑到的場景有限，很難把所有用戶場景窮盡.碰到線上問題難以定位。
檢測過程需要主動觸發(fā)GC,Dump內(nèi)存鏡像造成app凍結(jié)，造成測試過程中體驗(yàn)不好。
適用范圍有限，只能定位Activity&Fragment泄漏，無法定位大對象、頻繁分配等問題。
hprof文件過大，如果整體上傳的話需要耗費(fèi)很多資源。
下面我們就介紹一下快手開源的線上OOM監(jiān)控框架KOOM。
5.1 線上OOM監(jiān)控框架KOOM介紹
上面我們介紹了LeakCanary不能用于線上監(jiān)控的原因，所以要實(shí)現(xiàn)線上監(jiān)控功能，就需要解決以下問題：
1、監(jiān)控
主動觸發(fā)GC，會造成卡頓
2、采集
Dump hprof，會造成app凍結(jié)
Hprof文件過大
3、解析
解析耗時過長
解析本身有OOM風(fēng)險
其核心流程為三部分：
監(jiān)控OOM，發(fā)生問題時觸發(fā)內(nèi)存鏡像的采集，以便進(jìn)一步分析問題。
采集內(nèi)存鏡像，學(xué)名堆轉(zhuǎn)儲，將內(nèi)存數(shù)據(jù)拷貝到文件中，以下簡稱dump hprof。
解析鏡像文件，對泄漏、超大對象等我們關(guān)注的對象進(jìn)行可達(dá)性分析，解析出其到GC root的引用鏈以解決問題。
5.2 KOOM解決GC卡頓
LeakCanary通過多次GC的方式來判斷對象是否被回收，所以會造成性能損耗。
koom通過無性能損耗的內(nèi)存閾值監(jiān)控來觸發(fā)鏡像采集，具體策略如下：
1、Java堆內(nèi)存/線程數(shù)/文件描述符數(shù)突破閾值觸發(fā)采集。
2、Java堆上漲速度突破閾值觸發(fā)采集。
3、發(fā)生OOM時如果策略1、2未命中 觸發(fā)采集。
4、泄漏判定延遲至解析時。
我們并不需要在運(yùn)行時判定對象是否泄漏，以Activity為例，我們并不需要在運(yùn)行時判定其是否泄漏，Activity有一個成員變量mDestroyed，在onDestory時會被置為true，只要解析時發(fā)現(xiàn)有可達(dá)且mDestroyed為true的Activity，即可判定為泄漏。
通過將泄漏判斷延遲至解析時，即可解決GC卡頓的問題。
5.3 KOOM解決Dump hprof凍結(jié)app
Dump hprof即采集內(nèi)存鏡像需要暫停虛擬機(jī)，以確保在內(nèi)存數(shù)據(jù)拷貝到磁盤的過程中，引用關(guān)系不會發(fā)生變化，暫停時間通常長達(dá)10秒以上，對用戶來講是難以接受的，這也是LeakCanary官方不推薦線上使用的重要原因之一。
利用Copy-on-write機(jī)制，fork子進(jìn)程dump內(nèi)存鏡像，可以完美解決這一問題，fork成功以后，父進(jìn)程立刻恢復(fù)虛擬機(jī)運(yùn)行，子進(jìn)程dump內(nèi)存鏡像期間不會受到父進(jìn)程數(shù)據(jù)變動的影響。
流程如下圖所示：
KOOM隨機(jī)采集線上真實(shí)用戶的內(nèi)存鏡像，普通dump和fork子進(jìn)程dump阻塞用戶使用的耗時如下：
可以看出，基本可以做到無感知的采集內(nèi)存鏡像。
5.4 KOOM解決hprof文件過大
Hprof文件通常比較大，分析OOM時遇到500M以上的hprof文件并不稀奇，文件的大小，與dump成功率、dump速度、上傳成功率負(fù)相關(guān)，且大文件額外浪費(fèi)用戶大量的磁盤空間和流量。
因此需要對hprof進(jìn)行裁剪，只保留分析OOM必須的數(shù)據(jù)，另外，裁剪還有數(shù)據(jù)脫敏的好處，只上傳內(nèi)存中類與對象的組織結(jié)構(gòu)，并不上傳真實(shí)的業(yè)務(wù)數(shù)據(jù)（諸如字符串、byte數(shù)組等含有具體數(shù)據(jù)的內(nèi)容），保護(hù)用戶隱私。
裁剪hprof文件涉及到對hprof文件格式的了解，這里就不綴述了。
下面看一下裁剪過程的流程圖：
5.5 KOOM解決hprof解析的耗時與OOM
解析hprof文件，對關(guān)鍵對象進(jìn)行可達(dá)性分析，得到引用鏈，是解決OOM最核心的一步，之前的監(jiān)控和dump都是為解析做鋪墊。
解析分兩種，一種是上傳hprof文件由server解析，另一種是在客戶端解析后上傳報告(通常只有幾KB)。
KOOM選擇了端上解析，這樣做有兩個好處：
節(jié)省用戶流量。
利用用戶閑時算力，降低server壓力，這樣也符合分布式計算理念。
這樣就可以把解析過程拆解成以下兩個問題：
1、哪些對象需要分析，全部分析性能開銷太大，很難在端上完成，并且問題沒有重點(diǎn)也不利于解決。
2、性能優(yōu)化，作為一個debug組件，要在不影響用戶體驗(yàn)的情況下完成解析，對性能有非常高的要求。
5.5.1 關(guān)鍵對象判定
KOOM只解析關(guān)鍵的對象，關(guān)鍵對象分為兩類，一類是根據(jù)規(guī)則可以判斷出對象已經(jīng)泄露，且持有大量資源的，另外一類是對象shallow / retained size 超過閾值。
Activity/fragment泄露判定即為第一種:
對于強(qiáng)可達(dá)的activity對象，其mDestroyed值為true時(onDestroy時賦值)，判定已經(jīng)泄露。
類似的，對于fragment，當(dāng)mCalled值為true且mFragmentManager為null時，判定已經(jīng)泄露。
Bitmap/window/array/sufacetexture判定為第二種。
檢查bitmap/texture的數(shù)量、寬高、window數(shù)量、array長度等等是否超過閾值，再結(jié)合hprof中的相關(guān)業(yè)務(wù)信息，比如屏幕大小，view大小等進(jìn)行判定。
5.5.2 性能優(yōu)化
KOOM在LeakCanary解析引擎shark的基礎(chǔ)上做了一些優(yōu)化，將解析時間在shark的基礎(chǔ)上優(yōu)化了2倍以上，內(nèi)存峰值控制在100M以內(nèi)。用一張圖總結(jié)解析的流程：
詳細(xì)流程就不在這里綴述了，詳情可見：KOOM解析性能優(yōu)化。
https://juejin.cn/post/6860014199973871624#heading-13
5.6 KOOM使用
KOOM目前已經(jīng)開源，開源地址：
https://github.com/KwaiAppTeam/KOOM
直接參照接入指南接入即可，當(dāng)發(fā)現(xiàn)內(nèi)存超過閾值或者發(fā)生OOM時，就會觸發(fā)采集內(nèi)存快照，對hprof文件進(jìn)行裁剪并分析后得到報告。
KOOM的報告是json格式，并且大小在KB級別，樣式如下所示：
大概包括以下信息：
一些可能泄漏的類信息。
泄漏原因,gcRoot,泄漏實(shí)例數(shù)量等。
泄漏對象的引用鏈，方便定位問題。
可見KOOM上傳的數(shù)據(jù)量并不太大，但相對準(zhǔn)確，非常便于我們分析線上數(shù)據(jù)。
5.7 小結(jié)
本章主要介紹了線上監(jiān)控OOM的開源框架KOOM。
其實(shí)線上監(jiān)控OOM的框架各大廠都有開發(fā)，比如美團(tuán)的Probe,字節(jié)的Liko。
https://tech.meituan.com/2019/11/14/crash-oom-probe-practice.html
https://juejin.cn/post/6908517174667804680#heading-7
不過大部分都沒有正式開源，只是一些文章介紹原理，有興趣的同學(xué)也可以都了解下。
總結(jié)
對于優(yōu)化的大方向，我們應(yīng)該優(yōu)先去做見效快的地方，主要有以下幾個部分：
內(nèi)存泄漏。
內(nèi)存抖動。
Bitmap大圖監(jiān)控。
OOM線上監(jiān)控。
我們還介紹了內(nèi)存優(yōu)化的多種實(shí)用工具：
可以使用Profile,MAT在開發(fā)時定位內(nèi)存抖動內(nèi)存泄漏問題。
線下開發(fā)、回歸、Monkey、壓測等環(huán)節(jié)可以自動集成LeakCanary檢測內(nèi)存泄漏；
圖片加載是內(nèi)存優(yōu)化的重點(diǎn)，我們可以結(jié)合圖片兜底策略與線上大圖監(jiān)控，優(yōu)化圖片內(nèi)存問題。
線上OOM時通過KOOM監(jiān)測，內(nèi)存超出閾值時主動dump內(nèi)存快照，通過上傳分析結(jié)果精準(zhǔn)。分析OOM問題。
內(nèi)存優(yōu)化是個復(fù)雜的過程，我們在做內(nèi)存優(yōu)化的過程中，需要結(jié)合多種工具，線上線下結(jié)合，系統(tǒng)化地配合來定位與解決問題。
