WeTest 導(dǎo)讀

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

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

找到性能瓶頸 分析優(yōu)化方案 執(zhí)行優(yōu)化

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

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

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

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

一、如何找瓶頸所在

在分析方法上，主要：

● 分析代碼邏輯，檢查有問題的邏輯，對(duì)其進(jìn)行相關(guān)優(yōu)化。

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

● 然后是分析HeapDump的方法

看 DominatorTree，確定占用內(nèi)存最多的實(shí)例 通過 GC root輔助分析內(nèi)存占用的來源 通過 RetainHeapSize 量化的分析內(nèi)存占用

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

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

● 在手機(jī)發(fā)生OOM的時(shí)候dump內(nèi)存，上傳到后臺(tái)，以便后續(xù)分析

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

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

二、找到哪些瓶頸

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

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

1）PullToRefreshListView 的 Loading 和 Empty View lazyLoad，這是下拉刷新的組件，其下拉刷新有一個(gè)幀動(dòng)畫，圖片較多，占用較多內(nèi)存。

2）Minibar PlayListView。每個(gè)頁面都會(huì)有一個(gè)Minibar，但是不一定Minibar都會(huì)打開播放列表。

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

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

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

2）彈幕，只在播放頁展示彈幕的時(shí)候才有用

3）播放頁 TransitionBackgroundManager 大圖內(nèi)存占用問題 。這個(gè)一個(gè)大圖，為了做漸變動(dòng)畫。

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

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

2）下載管理會(huì)在內(nèi)存中存儲(chǔ)用戶下載的 節(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上報(bào)發(fā)現(xiàn)，占用內(nèi)存最多的一次上報(bào)，僅播放歷史記錄就占內(nèi)存50M之多。

上述 1-4 點(diǎn)通過措施1主動(dòng)檢查內(nèi)存發(fā)現(xiàn)。而第5點(diǎn)則是在分析了OOM上報(bào)“意外”發(fā)現(xiàn)的，如果是通過措施1的方式，幾乎不可能知道這么多OOM竟然是因?yàn)檫@個(gè)問題引起的。

三、怎么優(yōu)化瓶頸

找到問題之后，剩下的就是比較好做的了，只需順藤摸瓜，各個(gè)擊破！

1、懶加載 （LazyLoad）

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

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

1.3 會(huì)復(fù)雜一點(diǎn)。圖片加載組件可以提供default圖，在圖片加載過程中臨時(shí)展示；以及faild圖，在圖片加載失敗之后展示。這兩個(gè)圖在AsyncImageView中都是直接引用住圖片 （Drawable）的。事實(shí)上絕大多數(shù)場(chǎng)景都會(huì)顯示成功的圖片。因此這里的修改方式是：

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

這里去掉了幾個(gè)大圖的內(nèi)存占用。內(nèi)存占用在幾M級(jí)別。

2、及時(shí)釋放

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

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

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

2.3 是為了動(dòng)畫準(zhǔn)備的一張大圖，為了做一個(gè)炫酷的動(dòng)畫效果。事實(shí)上，在動(dòng)畫結(jié)束之后，就可以釋放了。這個(gè)圖片占用的內(nèi)存和手機(jī)分辨徐率相關(guān)，分辨率（嚴(yán)格來說是density）越高的手機(jī)，圖片尺寸越大。在主流手機(jī)上1080p約1M。

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

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

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

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

數(shù)據(jù)存儲(chǔ)在DB 在需要數(shù)據(jù)的時(shí)候通過一次db查詢，拿到具體的數(shù)據(jù)。

但是因?yàn)楝F(xiàn)有代碼都是從內(nèi)存中查詢，接口是同步的方式，全部改異步的成本會(huì)比較大，這里我們的時(shí)間成本和測(cè)試自由都有限。

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

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

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

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

這里做了兩件事：

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

比如其中的url字段，實(shí)際只用來通過hash生成文件名，我們完全可以用showId代替。而一個(gè)url長(zhǎng)度可達(dá)500Byte，1000個(gè)ShowMeta的話，這里就能節(jié)省500K內(nèi)存了！

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

2、 intern 這里是參考了 String.intern 的思路。不同的ShowMeta可能會(huì)有相同的字段，或者說字段中有相同的部分。

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

再比如：ShowMeta中會(huì)存儲(chǔ)下載文件的全路徑，而事實(shí)上所有節(jié)目都會(huì)存儲(chǔ)在同一個(gè)文件目錄中，因此這里把文件路徑拆成 目錄+文件名來存儲(chǔ)，而路徑采用 intern 的方式，保證了內(nèi)存中只會(huì)有一份。

優(yōu)化前

優(yōu)化后

最直觀的看變化是內(nèi)存占用從 14272B 到 120B。仔細(xì)看會(huì)發(fā)現(xiàn) ShowRecordMeta 的retainHeap 不等于各字段內(nèi)存占用之和，這是因?yàn)樯厦嫣岬降?String intern 的作用，相同字段被復(fù)用了，因此這里的retainheap不準(zhǔn)確，通過RecordDataManager/countof(records) 計(jì)算，平均每一個(gè)record 14800/60 = 247B，減少98%。

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

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

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

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

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

(14727-100)* 100 = 1.4M

如果是重度用戶，下載1000個(gè)節(jié)目，則有14M之多！

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

四、圖片內(nèi)存

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

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

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

是否所有圖片都用于界面展示 是否圖片尺寸過大。

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

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

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

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

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

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

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

問題2：另外就是ViewPager這種多頁面視圖，給用戶展示的實(shí)際上只有一個(gè)，其他幾個(gè)視圖并沒有在展示，因此這里是否可以改造ViewPager呢？

針對(duì)第一個(gè)問題，被ListView回收的view仍然在內(nèi)存中的問題，通過改造AsyncImageView，在View從windowdetach的時(shí)候，主動(dòng)釋放Bitmap，attach到Window的時(shí)候再次嘗試加載圖片。另外是多圖滾動(dòng)視圖，這里的圖片很大，因此占用內(nèi)存也很多。因?yàn)闅v史原因之前使用的是Gallery，其有bug導(dǎo)致會(huì)額外引用住兩個(gè)大圖（已經(jīng)不可見），因此這里使用RecyclerView修改了其實(shí)現(xiàn)，解決上述問題。

針對(duì)第二個(gè)問題，目前還沒有采取有效措施，主要依賴Android系統(tǒng)，主動(dòng)回收Activity的內(nèi)存。（這里存疑，需要深挖系統(tǒng)代碼，理清理邏輯之后再下結(jié)論。短期的結(jié)論是：系統(tǒng)的清理行為不可靠）。如果要改的話，可以簡(jiǎn)單的修改一下ViewPager的內(nèi)存，保證在其他page不可見的時(shí)候，回收其相關(guān)的Fragment。留個(gè)TODO。

LRU + TTL

針對(duì)圖片緩存，這里本身只是緩存圖片并且有LRU算法保證不會(huì)超過最大內(nèi)存，理論上內(nèi)存占用合理。但是LRU算法有一個(gè)問題，就是一旦緩存滿了，后續(xù)只能通過添加新Bitmap才能淘汰掉老的Bitmap，而此時(shí)緩存占用的內(nèi)存仍然是最大值。因此這里的思考是LRU+TTL算法：即在LRU的基礎(chǔ)上，指定每一個(gè)Bitmap在緩存中存在是有效時(shí)長(zhǎng)。超過時(shí)長(zhǎng)之后主動(dòng)將其從緩存中清理掉。這樣我們就可以解決LRUcache占用的內(nèi)存不可減少的問題。

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

高斯模糊

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

因?yàn)楦咚鼓：膱D片本身會(huì)讓圖片變得模糊（廢話。。），因此圖片的信息實(shí)質(zhì)上是丟失了很大一部分的。在此思路的基礎(chǔ)上，我們可以把需要高斯模糊的圖片先縮小（比如 100x100），然后再做高斯模糊。這樣不僅減少了內(nèi)存占用，同時(shí)高斯模糊處理的速度也可以大大增加！

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

五、其他優(yōu)化

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

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

六、成果對(duì)比

內(nèi)存優(yōu)化的效果總體還不錯(cuò)，這里一共做了兩期，優(yōu)化了幾十個(gè)項(xiàng)目。首先要比較感謝項(xiàng)目組給了可觀的排期，這樣才有時(shí)間做一些比較深入的改動(dòng)。

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

一期優(yōu)化效果是在[email protected]上測(cè)試到的靜息態(tài)內(nèi)存優(yōu)化 26.5M。

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

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

24小時(shí)直播間單例： 287K

彈幕manager 單例： 512K

播放頁動(dòng)畫大圖：1M

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

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

總共減少： 28M+

動(dòng)態(tài)內(nèi)存

動(dòng)態(tài)內(nèi)存比較不好對(duì)比，這里決定采用黑盒測(cè)試的方式：

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

這里測(cè)試了兩種場(chǎng)景：

應(yīng)用新安裝 老用戶，聽了很多節(jié)目（播放歷史600個(gè)），下載近200個(gè)節(jié)目

experiment

操作對(duì)照?qǐng)D

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

compare clean install

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

compare heavy use

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

事實(shí)上，因?yàn)橛袌D片緩存在LRU算法的基礎(chǔ)上增加了TTL邏輯，在靜止1分鐘之后（只要不再加載新圖片），4.0版本，內(nèi)存還會(huì)下降。（圖片緩存超時(shí)主動(dòng)清理）。

4.0 ImageCache TTL

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

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

最后，在4.0版本發(fā)布外網(wǎng)之后，筆者對(duì)比了一下3.9版本的Crash上報(bào)，結(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ù)推動(dòng)相關(guān)SDK進(jìn)行優(yōu)化！

七、結(jié)論

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

兩者的測(cè)量標(biāo)準(zhǔn)稍有不同，對(duì)應(yīng)用的影響也不同。

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

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

UPA——一款針對(duì)Unity游戲/產(chǎn)品的深度性能分析工具，由騰訊WeTest和unity官方共同研發(fā)打造，可以幫助游戲開發(fā)者快速定位性能問題。旨在為游戲開發(fā)者提供更完善的手游性能解決方案，同時(shí)與開發(fā)環(huán)節(jié)形成閉環(huán)，保障游戲品質(zhì)。

來自：https://segmentfault.com/a/1190000012708312