Android 內(nèi)存暴減的秘密(轉(zhuǎn))

在?我這樣減少了26.5M Java內(nèi)存捌治！?一文中內(nèi)存優(yōu)化一期已經(jīng)告一段落塑径，主要做的事情是，造了幾個分析內(nèi)存問題的輪子薇宠，定位進程各種類型內(nèi)存占用情況偷办，分析了線程創(chuàng)建OOM的原因。當(dāng)然最重要的是昼接，優(yōu)化了一波進程靜息態(tài)的內(nèi)存占用（減少26M+）爽篷。而二期則是在一期的基礎(chǔ)之上，推進已發(fā)現(xiàn)問題的SDK解決問題慢睡，最終要的是要優(yōu)化進程的動態(tài)Java內(nèi)存占用逐工！

通常來說不管是做什么性能優(yōu)化，逃不出性能優(yōu)化3步曲：

1. 找到性能瓶頸

2. 分析優(yōu)化方案

3. 執(zhí)行優(yōu)化

上述三步看似第三步最能決定優(yōu)化結(jié)果漂辐，而事實上泪喊，從筆者的幾次性能優(yōu)化經(jīng)歷來看，找到瓶頸確占據(jù)了絕對的影響力髓涯！

● ?能否找到瓶頸意味著優(yōu)化做不做的下去袒啼。

● ?找到的瓶頸性能越差意味著優(yōu)化效果越明顯。

● ?找到的瓶頸越多同樣意味著優(yōu)化效果越好纬纪。

一

如何找瓶頸所在

在分析方法上蚓再，主要：

● ?分析代碼邏輯，檢查有問題的邏輯包各，對其進行相關(guān)優(yōu)化摘仅。

● ?模擬用戶操作 在內(nèi)存占用較高的時候dump內(nèi)存，使用MAT分析

● ?然后是分析HeapDump的方法

1. 看 DominatorTree问畅，確定占用內(nèi)存最多的實例

2. 通過 GC root輔助分析內(nèi)存占用的來源

3. 通過 RetainHeapSize 量化的分析內(nèi)存占用

動態(tài)內(nèi)存優(yōu)化比靜態(tài)要更難娃属，其難點在于動態(tài)二字之上。動態(tài)不僅是的查找瓶頸變得困難护姆，也使得對比優(yōu)化成果不顯而易見矾端。而不同的環(huán)境、操作路徑卵皂、設(shè)備秩铆、使用習(xí)慣等各個因素都有可能導(dǎo)致內(nèi)存占用的不同〉票洌可能的情況是：找到的性能瓶頸和用戶實際操作的方式不同豺旬，導(dǎo)致不能解決外網(wǎng)的OOM。因此直接獲取手機用戶的真實數(shù)據(jù)則是最行之有效的一種方式柒凉。

因此輔助采取了另一種方式, 收集真實的用戶數(shù)據(jù)族阅。

● ?在手機發(fā)生OOM的時候dump內(nèi)存，上傳到后臺膝捞，以便后續(xù)分析

措施1：可以優(yōu)化現(xiàn)有代碼邏輯坦刀，針對內(nèi)存占用過多/不合理的場景進行優(yōu)化。這是主場景蔬咬。

措施2：主要分析外網(wǎng)用戶的使用習(xí)慣下鲤遥，發(fā)生OOM的場景。比較容易發(fā)現(xiàn)bug類問題導(dǎo)致瞬間內(nèi)存占用過多的場景林艘。

二

找到哪些瓶頸

找到的瓶頸問題很多盖奈，稍微按照分類梳理一下：

1. 加載進內(nèi)存，實際上沒用到（還沒用到）的數(shù)據(jù)

1）PullToRefreshListView 的 Loading 和 Empty View ? ? ? lazyLoad狐援，這是下拉刷新的組件钢坦，其下拉刷新有一個幀動畫究孕，圖片較多，占用較多內(nèi)存爹凹。

2）Minibar PlayListView厨诸。每個頁面都會有一個Minibar，但是不一定Minibar都會打開播放列表禾酱。

3）AsyncImageView 的 默認圖和失敗圖以Drawble的形式直接加載進內(nèi)存的微酬。

2. UI 相關(guān)數(shù)據(jù)，未及時釋放

1）24 小時直播間數(shù)據(jù)颤陶，只在節(jié)目切換的時候才有用

2）彈幕颗管，只在播放頁展示彈幕的時候才有用

3）播放頁 TransitionBackgroundManager 大圖內(nèi)存占用問題 。這個一個大圖滓走，為了做漸變動畫垦江。

3. 數(shù)據(jù)結(jié)構(gòu)不合理，占用內(nèi)存過多

1）播放歷史最多記錄600個節(jié)目信息闲坎，每一個ShowInfo占用內(nèi)存多達22K（通過MAT查看RetainHeap）

2）下載管理會在內(nèi)存中存儲用戶下載的 節(jié)目信息疫粥，歌詞，專輯信息腰懂，分別占用內(nèi)存 12K, 0-10K, ? ? ? 12K梗逮。并且這里沒有數(shù)量限制。

4. 圖片占用內(nèi)存過多

1）在應(yīng)用主頁操作一下绣溜，發(fā)現(xiàn)圖片（Bitmap）占用的內(nèi)存很多

2）高斯模糊圖片慷彤。

5. bug類導(dǎo)致內(nèi)存占用過多

播放歷史應(yīng)為代碼邏輯bug，導(dǎo)致沒有控制記錄數(shù)量上限怖喻。于是用戶聽的節(jié)目越多內(nèi)存占用就越大底哗。這里的問題主要通過OOM上報發(fā)現(xiàn)，占用內(nèi)存最多的一次上報锚沸，僅播放歷史記錄就占內(nèi)存50M之多跋选。

上述 1-4 點通過措施1主動檢查內(nèi)存發(fā)現(xiàn)。而第5點則是在分析了OOM上報“意外”發(fā)現(xiàn)的哗蜈，如果是通過措施1的方式前标，幾乎不可能知道這么多OOM竟然是因為這個問題引起的。

三

怎么優(yōu)化瓶頸

找到問題之后距潘，剩下的就是比較好做的了炼列，只需順藤摸瓜，各個擊破音比！

1俭尖、懶加載 （LazyLoad）

針對上面的1.1， 1.2， 都可以做LazyLoad稽犁，真正需要下拉刷新/展示播放列表的時候再創(chuàng)建相關(guān)實例焰望。

1.4 則可以在動畫結(jié)束之后清理掉相關(guān)Bitmap

1.3 會復(fù)雜一點。圖片加載組件可以提供default圖缭付，在圖片加載過程中臨時展示柿估；以及faild圖循未，在圖片加載失敗之后展示陷猫。這兩個圖在AsyncImageView中都是直接引用住圖片 （Drawable）的。事實上絕大多數(shù)場景都會顯示成功的圖片的妖。因此這里的修改方式是：

AsyncImageView的 default/fail 圖片不再引用 drawable绣檬，而是引用資源ID，在需要的時候再由ImageLoader加載進內(nèi)存嫂粟，同時這些圖片將有ImageCache統(tǒng)一管理娇未，并占用內(nèi)存LRU空間（之前是由Resource管理）。

這里去掉了幾個大圖的內(nèi)存占用星虹。內(nèi)存占用在幾M級別零抬。

2. 及時釋放

上面 2.1 中的24小時直播間的數(shù)據(jù)會一直在內(nèi)存中，即使用戶當(dāng)前沒有在聽24小時直播間宽涌。這個顯然是不合理的平夜。

修改的做法是業(yè)務(wù)數(shù)據(jù)緩存的DB中，在需要用到的時候從DB中查詢出來

2.2 的彈幕則是純粹的UI相關(guān)數(shù)據(jù)，在播放頁退出之后即可釋放了。

2.3 是為了動畫準備的一張大圖室埋，為了做一個炫酷的動畫效果弧圆。事實上，在動畫結(jié)束之后痕貌，就可以釋放了。這個圖片占用的內(nèi)存和手機分辨徐率相關(guān)，分辨率（嚴格來說是density）越高的手機鸯檬，圖片尺寸越大。在主流手機上1080p約1M螺垢。

這里分別減少了 287K + 512K + 1M

3. 優(yōu)化數(shù)據(jù)結(jié)構(gòu)

3.1 和 3.2 都會存儲節(jié)目信息喧务，而節(jié)目信息相關(guān)的jce結(jié)構(gòu)都比較大，通過MAT甩苛，可以看到 Show:12K, Album:10K, 一個ShowInfo同時包含了上面兩種數(shù)據(jù)結(jié)構(gòu)蹂楣。

最合理的方式應(yīng)該是：

1. 數(shù)據(jù)存儲在DB

2. 在需要數(shù)據(jù)的時候通過一次db查詢，拿到具體的數(shù)據(jù)讯蒲。

但是因為現(xiàn)有代碼都是從內(nèi)存中查詢痊土，接口是同步的方式，全部改異步的成本會比較大墨林，這里我們的時間成本和測試自由都有限赁酝。

綜合上面MAT分析的結(jié)果犯祠，有個思路：

內(nèi)存中存儲 節(jié)目信息 （ShowMeta）最少的內(nèi)存，例如: 節(jié)目名酌呆，節(jié)目id衡载，專輯id 之類的信息。而真正的Show和Album結(jié)構(gòu)存在DB中隙袁。

這樣內(nèi)存中的數(shù)據(jù)可以盡量的少痰娱，同時大部分已有接口還可以保持同步調(diào)用的方式。

此外菩收，從用戶的角度出發(fā)梨睁，假設(shè)一個重度用戶下載了1000個節(jié)目，那么每一個ShowMeta占用的內(nèi)存都會被放大1000倍娜饵，因此載極限的優(yōu)化ShowMeta都不為過坡贺。

這里做了兩件事：

1. ?刪字段，把ShowMeta中的非必要字段刪掉箱舞。

比如其中的url字段遍坟，實際只用來通過hash生成文件名，我們完全可以用showId代替晴股。而一個url長度可達500Byte愿伴，1000個ShowMeta的話，這里就能節(jié)省500K內(nèi)存了队魏！

再比如：dowanloadTaskId字段公般，是存儲下載任務(wù)的id的，在節(jié)目下載完成后胡桨，該字段即失去意義官帘，因此可以刪除之。

2. intern 這里是參考了?String.intern?的思路昧谊。不同的ShowMeta可能會有相同的字段刽虹，或者說字段中有相同的部分。

比如同一個專輯中的ShowMeta其albumId字段都會是相同的呢诬，我們只需要保留一份albumId涌哲，其他ShowMeta都可以用同一個實例。（內(nèi)存優(yōu)化一期對ShowList做了同樣的改造）

再比如：ShowMeta中會存儲下載文件的全路徑尚镰，而事實上所有節(jié)目都會存儲在同一個文件目錄中阀圾，因此這里把文件路徑拆成 目錄+文件名來存儲，而路徑采用?intern?的方式狗唉，保證了內(nèi)存中只會有一份初烘。

優(yōu)化前

優(yōu)化后

最直觀的看變化是內(nèi)存占用從 14272B 到 120B。仔細看會發(fā)現(xiàn) ShowRecordMeta 的retainHeap 不等于各字段內(nèi)存占用之和，這是因為上面提到的 String intern 的作用肾筐，相同字段被復(fù)用了哆料，因此這里的retainheap不準確，通過RecordDataManager/countof(records) 計算吗铐，平均每一個record 14800/60 = 247B东亦，減少98%。

這里的修改結(jié)果：

播放歷史 ShowHistoryBiz -> ShowHistoryMeta 內(nèi)存占用從 19k 到 約216B

下載記錄 ShowRecordBiz -> ShowRecordMeta 內(nèi)存占用 從 14k 到 約100B

粗略估計唬渗，這里修改的播放歷史（每次播放都會增加一個記錄典阵，上限600個），(19256-216)* 600 = 10.9M

和下載記錄（假設(shè)一個輕度使用用戶用戶下載100個節(jié)目）谣妻，內(nèi)存總共可以減少：

(14727-100)* 100 = 1.4M

如果是重度用戶萄喳，下載1000個節(jié)目卒稳，則有14M之多蹋半！

不得不說這是個很大的數(shù)字！

四

圖片內(nèi)存

在Android 2.3 之后充坑，Bitmap改了實現(xiàn)减江，圖片內(nèi)存從native heap轉(zhuǎn)移到了Java heap。這就導(dǎo)致了JavaHeap占用暴增捻爷。（然而8.0又改成NativeHeap了辈灼，具體原因官方文檔并沒有提及，有待考察）也榄。

通常我們分析 heap dump 的時候會發(fā)現(xiàn)Bitmap占用的內(nèi)存是絕對的大頭巡莹。這次我們做內(nèi)存優(yōu)化也不例外。

這里的思路是分析內(nèi)存占用是否合理：

1. 是否所有圖片都用于界面展示

2. 是否圖片尺寸過大甜紫。

首先降宅，分析內(nèi)存占用是否合理。經(jīng)過一期的優(yōu)化囚霸，在不打開MainActivity的時候腰根，內(nèi)存中幾乎沒有圖片。但是打開MainActivity之后拓型，內(nèi)存中會出現(xiàn)幾十兆的圖片內(nèi)存额嘿。

圖片內(nèi)存主要是用于展示的，也即：被AsyncImageView持有的部分劣挫。

另外是內(nèi)存的圖片緩存册养，會持有 最大JavaHeap 1/8 的內(nèi)存充當(dāng) Bitmap 緩存，使用LRU算法淘汰老數(shù)據(jù)压固。

當(dāng)然另外一些圖片過大屬于使用不當(dāng)球拦，實際上可以裁剪才View實際的大小。

而一些全屏（和屏幕等寬的圖，主要是Banner）圖其實可以裁剪的更小一點（如3/4大辛跤ā）減少近46%的內(nèi)存占用阎毅，而觀感不會有特別明顯的區(qū)別。（寫這個文檔的時候突然想到的点弯，TODO一下）扇调。

問題1：針對AsyncImageView的問題，思考是否所有圖片都在用戶展示抢肛？

答案顯然是否定的狼钮，一部分圖片被ListView回收的view所持有，這些內(nèi)存占用顯然是不合理的捡絮。

問題2：另外就是ViewPager這種多頁面視圖熬芜，給用戶展示的實際上只有一個，其他幾個視圖并沒有在展示福稳，因此這里是否可以改造ViewPager呢涎拉？

針對第一個問題，被ListView回收的view仍然在內(nèi)存中的問題的圆，通過改造AsyncImageView鼓拧，在View從windowdetach的時候，主動釋放Bitmap越妈，attach到Window的時候再次嘗試加載圖片季俩。另外是多圖滾動視圖，這里的圖片很大梅掠，因此占用內(nèi)存也很多酌住。因為歷史原因之前使用的是Gallery，其有bug導(dǎo)致會額外引用住兩個大圖（已經(jīng)不可見）阎抒，因此這里使用RecyclerView修改了其實現(xiàn)酪我，解決上述問題。

針對第二個問題挠蛉，目前還沒有采取有效措施祭示，主要依賴Android系統(tǒng)，主動回收Activity的內(nèi)存谴古。（這里存疑质涛，需要深挖系統(tǒng)代碼，理清理邏輯之后再下結(jié)論掰担。短期的結(jié)論是：系統(tǒng)的清理行為不可靠）汇陆。如果要改的話，可以簡單的修改一下ViewPager的內(nèi)存带饱，保證在其他page不可見的時候毡代，回收其相關(guān)的Fragment阅羹。留個TODO。

LRU + TTL

針對圖片緩存教寂，這里本身只是緩存圖片并且有LRU算法保證不會超過最大內(nèi)存捏鱼，理論上內(nèi)存占用合理。但是LRU算法有一個問題酪耕，就是一旦緩存滿了导梆，后續(xù)只能通過添加新Bitmap才能淘汰掉老的Bitmap，而此時緩存占用的內(nèi)存仍然是最大值迂烁。因此這里的思考是LRU+TTL算法：即在LRU的基礎(chǔ)上看尼，指定每一個Bitmap在緩存中存在是有效時長。超過時長之后主動將其從緩存中清理掉盟步。這樣我們就可以解決LRUcache占用的內(nèi)存不可減少的問題藏斩。

再次感謝afc組件作者raezlu和筆者討論問題，欣然接受建議却盘，并身體力行的實現(xiàn)了TTL方案狰域！

高斯模糊

這里補充一個，關(guān)于高斯模糊圖片占用內(nèi)存過高的問題谷炸，在之前版本已經(jīng)優(yōu)化過了北专。

因為高斯模糊的圖片本身會讓圖片變得模糊（廢話。旬陡。），因此圖片的信息實質(zhì)上是丟失了很大一部分的语婴。在此思路的基礎(chǔ)上描孟，我們可以把需要高斯模糊的圖片先縮小（比如 100x100）砰左，然后再做高斯模糊匿醒。這樣不僅減少了內(nèi)存占用，同時高斯模糊處理的速度也可以大大增加缠导！

比如廉羔，之前遇到播放頁封面cover圖 720*720的大小，占內(nèi)存?720 * 720 * 4 = 2M僻造，降低到 100x100 占用內(nèi)存大小?100 * 100 * 4= 40K憋他，內(nèi)存優(yōu)化效果明顯，而視覺上幾乎沒有差距髓削。

五

其他優(yōu)化

這里主要針對外網(wǎng)的TOP1 crash竹挡，WNS內(nèi)部線程創(chuàng)建導(dǎo)致的OOM。

筆者的解決方案是先根據(jù)crash上報信息立膛，深挖系統(tǒng)源碼《Android 創(chuàng)建線程源碼與OOM分析》揪罕，徹底理清楚線程創(chuàng)建邏輯梯码，并最終確定crash原因是線程的無節(jié)制創(chuàng)建。然后針對crash好啰，整理出詳細的原因分析轩娶，再給WNS的小伙伴提了bug，待修復(fù)之后替換sdk框往。

六

成果對比

內(nèi)存優(yōu)化的效果總體還不錯罢坝，這里一共做了兩期，優(yōu)化了幾十個項目搅窿。首先要比較感謝項目組給了可觀的排期嘁酿，這樣才有時間做一些比較深入的改動。

靜息態(tài)內(nèi)存

一期優(yōu)化效果是在Nexus6P@7.1上測試到的靜息態(tài)內(nèi)存優(yōu)化 26.5M男应。

二期又進一步做了優(yōu)化（上文3.2 3.3節(jié)）闹司，現(xiàn)在靜息態(tài)內(nèi)存再次dump會發(fā)現(xiàn)只有3M內(nèi)存了，而這3M有一部分是播放列表沐飘，一部分是播放頁持有的小圖片游桩。

通過計算，可以得出靜息態(tài)內(nèi)存進一步減少了：

24小時直播間單例： 287K

彈幕manager 單例： 512K

播放頁動畫大圖：1M

播放歷史 600個（上限）：(19256-216) * 600 = 10.9M

下載記錄 下載100個節(jié)目：(14727-100)* 100 = 1.4M

總共減少： 28M+

動態(tài)內(nèi)存

動態(tài)內(nèi)存比較不好對比耐朴，這里決定采用黑盒測試的方式：

打開應(yīng)用借卧，MainActivity各個tab操作一遍，打開播放頁筛峭，然后對比內(nèi)存占用量铐刘。鑒于筆者只有一臺Nexus6P開發(fā)機，為了控制變量影晓，這里創(chuàng)建了兩臺模擬器镰吵，并排擺放，分別打開企鵝FM4.0和3.9版本挂签，確保使用相同的操作路徑疤祭。

這里測試了兩種場景：

1. 應(yīng)用新安裝

2. 老用戶，聽了很多節(jié)目（播放歷史600個）饵婆，下載近200個節(jié)目

experiment?

?操作對照圖

通過AndroidStudio查看內(nèi)存占用情況勺馆。

compare clean install?

在場景一種：4.0版本占用 38.74M，而3.9版本占用 59.78M侨核。減少了21.04M內(nèi)存草穆。

?compare heavy use?

在場景二中：4.0版本占用 45.5M，而3.9版本占用 87.4M芹关。減少了41.9M內(nèi)存续挟。

事實上，因為有圖片緩存在LRU算法的基礎(chǔ)上增加了TTL邏輯侥衬，在靜止1分鐘之后（只要不再加載新圖片）诗祸，4.0版本跑芳，內(nèi)存還會下降。（圖片緩存超時主動清理）直颅。

?4.0 ImageCache TTL

可以看到Java內(nèi)存下降到 34.92M博个，而此時3.9版本仍然沒有變化，此時內(nèi)存減少 52.48M功偿。

PS：需要注意的是3.9版本的“廣播”tab在4.0版本替換成了“書城”tab盆佣，而書城tab的頁面要遠復(fù)雜的多，圖片也更多械荷。

最后共耍，在4.0版本發(fā)布外網(wǎng)之后，筆者對比了一下3.9版本的Crash上報吨瞎，結(jié)果如下：

總的crash率從?0.41%下降到%0.16痹兜，減少了0.21%。而OOM類型的crash率從?0.19%下降到?0.04%颤诀，減少了0.15%字旭！而剩下的0.04%則主要是線程創(chuàng)建導(dǎo)致的。目前在通過線程監(jiān)控組件查找根本原因崖叫，后續(xù)推動相關(guān)SDK進行優(yōu)化遗淳！

七

結(jié)論

另外需要注意的一點是，動態(tài)內(nèi)存和靜態(tài)內(nèi)存雖然分別減少了 52M 和 28M心傀，但是兩者是有一部分交集的屈暗。

兩者的測量標(biāo)準稍有不同，對應(yīng)用的影響也不同剧包。

動態(tài)內(nèi)存主要優(yōu)化app在低內(nèi)存設(shè)備上的性能恐锦，并減少OutOfMemory發(fā)生的幾率。

而靜態(tài)內(nèi)存疆液，主要優(yōu)化app退后臺后的內(nèi)存占用，一方面可以減少應(yīng)用進程被Android系統(tǒng)的LowMemoryKiller殺死陕贮，另一方面可以讓用戶的設(shè)備有更多剩余內(nèi)存堕油，用戶體驗更好。

http://wetest.qq.com/lab/view/362.html?from=content_toutiao&hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io