轉自https://wetest.qq.com/lab/view/359.html
WeTest 導讀
歷時五天的內存優化已經結束，這裏總結一下這幾天都做了什麼，有哪些收穫。優化了，或可以優化的地方都有哪些。（因爲很多事還沒做，有些結論需要一定樣本量才能斷定，所以叫一期）一期優化減少JavaHeap內存佔用約26.5M。
在任何性能優化之前，要做的第一件事就是找到性能瓶頸！而找到性能瓶頸通常需要強大的debug工具輔助。內存方面Android有 AndroidStudio 的 Android Profiler、Allocation Tracker，以及Eclipse的MAT用於分析java的內存佔用，相當強大。而偏向native層面的內存佔用則找不到太好的工具，因此這裏在做優化前，先造了幾個工具。
一
造輪子
1. 線程創建分析工具
該工具使用native hook的方式，直接hook了pthread_create調用，並記錄每一個線程創建時的堆棧，並打印日誌。同時維護一個running thread的集合，必要時 dump下來所有running thread的創建堆棧，用於分析野蠻線程創建的場景。以及對應的日誌分析工具。
2. Linux /proc/<pid>/smaps 文件分析腳本
主要用於跟蹤進程的 Code 部分內存（見下文）佔用，分析出佔用內存較多的dex，so文件。排查第三方SDK佔用過多內存場景。網上只能找到一個perl腳本，功能不是很強大，鑑於筆者不熟悉perl的語法規範，改起來會比較困難，因此直接用python重寫了一個。
代碼在這裏：https://gist.github.com/LanderlYoung/aedd0e1fe09214545a7f20c40c01776c
3. 快速Dump Android java heap腳本
因爲分析內存需要很多dump操作，所以乾脆寫了個Bash腳本。
Bash腳本鏈接：https://gist.github.com/LanderlYoung/9cd0f49e49e42746622cc8e7b4bbcc8a
（順便提一下，android提供的 hprof-conv 工具有個參數 -z 用於排除zygote的內存，十分便利。）
二
Android 進程 內存分類
通常我們在系統的內存管理頁面看到的內存佔用是進程的PSS，也就是整個進程的內存佔用，因此我們做優化的要考慮到所有的內存，不僅僅是Java Heap。
使用Android Studio（3.0 beta）的 Android Profiler工具。
我們可以很清晰的看到
1）進程總內存佔用： 180M
2）JavaHeap： 48M
3）NativeHeap：native層的 so 中調用malloc或new創建的內存 —— 28M
4）Graphics：OpenGL和SurfaceFlinger相關內存 ——58M
5）Stack：線程棧——1.89M
6）Code：dex+so相關代碼佔用內存——37.75M
7）Other：蜜汁存在
上述6中內存佔用除了兩種不需要考慮，其他5中通通需要優化。不需要考慮的是：
1）Other：暫時無從分析
2）Graphics：若應用沒有直接調用OpenGL，則可以確定這部分內存是由Android Framework操控的，可以忽略。（當然對於遊戲類應用，這裏肯定是優化重點。）
下面按照內存分類分開逐一介紹分析方法，和結論：
JavaHeap
這裏必然是內存優化的重點，無需多言。但是企鵝FM的業務，UI，代碼已經比較龐大，分析起來會顯得力不從心。因此這裏主要從兩個方面入手，希望能總結出一套分析方法。
1. 分析應用 靜息態 內存佔用。
所謂靜息態，是筆者自行定義的概念：
應用在退後臺之後，不保留活動的場景下的內存佔用。
爲什麼要考察這個維度？因爲這個是一個應用內存佔用最低點的時候，後續打開任何Activity內存只會更多，不會更少！
2. 分析方法
1）開發者選項開啓“不保留活動”
2）進入MainActivity，滑動頁面，操作一下
3）退後臺，Android Studio中強制執行GC
4）dump java heap （注意上面提到的 hprof-conf 加上 -z 參數排除zygote的干擾）
5）MAT 分析 dump 下來的JavaHeap
重點介紹一下MAT：
這裏可以直接打開domanitor_tree看佔用內存最多的實例。
從這裏按照RetainedHeap倒序排列，一點一點的排查內存佔用。很容易發現不正常的內存情況。
在企鵝FM中發現：
1）圖片的內存級緩存退後臺沒清空（此處屬於onTrimMemory回調的處理有誤），佔用10M內存
2）ImageMisc — 280k
①
② 是一個buffer，可以在不用的時候釋放內存
③ 優化目標，徹底幹掉
3）播放頁應用動畫的關係，UI是單例。其中相關View佔用數百K內存，而button的icon直接引用住了5-6M的bitmap資源。
4）播放列表存儲了103個ShowInfo，每個ShowInfo 22k，總計內存約2.24M，ShowInfo冗餘信息很多，可以考慮優化數據結構
5） DanmuManager — 510k
● mDanmuItemManager 內含衆多彈幕
● 每條彈幕6k
● UI相關數據，離開播放頁後應該清理彈幕（因爲無需展示了）
● 優化目標，徹底幹掉。
6） FileCacheService — 362k
①
② 其中緩存了每一個cache entry，其中圖片緩存較多
③ 每一個entry記錄完整文件路徑其比較長，因此路徑的字符串佔用了很多內存
④ 優化方案：
● 文件Parent可以共用同一個File對象。
● entry = new File(parent, “entry_name”)
⑤ 優化目標 到100k
7）LiveRoomShowListManager -- 287k
①
② 優化目標：UI相關數據，離開界面應該徹底幹掉
8) DB InsertHelper， Sql Statement clearBinding
① 700K到2M
② InsetHelper中會引用住最後一次執行DB insert調用的 數據（佔位符）
③ InsertHelper的佔位數據可以在insert完成之後清掉
針對上面提到的ShowInfo的數據結構優化
擬定優化方案：
1）ShowList存儲的ShowInfo數量過多，30個足矣。
2）ShowInfo中Album字段佔用10k內存，其實同一個ShowList中大多數album是完全一致的（比如專輯類型的ShowList，主播類型的，自選集類型的，本地專輯的，etc...）。
預計內存佔用 2M -> 30*12K = 360K
3）靜息態內存優化總結：
上述幾點加起來預期可以減少內存佔用：
10M + 280K + 5M + 2M + 510K + 260k + 287k + 1M = 約20M
3. MainActivity 操作一段時間之後內存增量
上面分析的是靜息態內存，下面看一下MainActivity操作一點時間之後，內存有怎樣的變化。
這裏採用的方式是：
1）dump靜息態內存
2）進入MainActivity，立即dump內存
3）操作一段時間之後再dump內存
一共有三次dump，可以利用MAT對比heap的功能對比內存增量。
打開MAT的historgram視圖
工具欄最右邊有個雙箭頭的icon，點擊可對比dump：如下圖
增量最多的還是Bitmap（底層用byte[]存儲），藉助MAT的 Finer 工具可以直接看到Bitmap的圖片。
這裏發現的幾個問題是（時間關係，應該多次測試的，會發現更多問題）：
① Banner的大圖沒有 Clip 導致 分辨率 很高
② 分類頁的 配置區域 沒有Clip
③ onRecycle沒有清除掉已經引用的Bitmap，導致引用住不能gc
主要說一下第3點，是Banner每一個Item有一個大圖做背景，當item的view被回收的時候，相應的ImageView仍然持有着大圖，導致其不能回收。這裏發現了4張1M+的大圖，其實理論上應該只有1張。
這個問題可以推廣到所有的ListView場景，建議方式是：
替換爲RecyclerView，在view回收的時候，ScarpView釋放圖片引用。
此外，MainActivity有5個tab，各個tab之間其實會用到相同的View（listview 的item），如果使用RecyclerView可以做到5個tab的RecyclerView共同複用同一個RecyclerPool，在節省內存的同時還能顯著提高性能。
這裏不方便直接測試內存佔用，預估可以節省內存5-10M。
4. 正常操作應用，觀察內存佔用圖表是否有突起
這裏主要用來測試異常內存分配的場景。
這裏仍然需要很大人力，過很多頁面。
目前發現問題有：
1）service進程，發送wns請求的時候，內存異常增長2-3M。
這時可以使用AllocationTracker工具（點擊下圖工具欄的紅點），記錄峯值那一段內存的分配，如圖：
這裏可以直接看到分配的棧，定位過去看，發現是這樣的代碼，因爲head是一個65536長的數組（在 com.tencent.wns.session.Session 的構造函數寫死的長度），這裏創建string就浪費了超大量的內存。建議可以改成下圖彈窗裏的樣子
2）另外一個問題是播放進程，在切換節目的時候內存會突然增長2-3M，簡單跟進去看是exo創建buffer。似乎有問題，需要再多分析一下~
Native Heap
目前能看到的NativeHeap大小是
應用啓動：26M 此時已經初始化了 X5內核和IM SDK
UGC錄音：26M->34M 退出之後時32M，還有部分沒釋放，疑似內存泄漏
發起直播：32M->72M 退出之後42M，同樣沒有完全釋放
具體內部佔用情況還沒測。。。（都說了是一期）。
官方文檔：
https://source.android.com/devices/tech/debug/native-memory
Code
這一段明顯看到佔用了很多內存。各個場景下的使用情況是：
1）剛進入應用：38M
2）再使用UGC錄音：38.28M
3）再使用視頻直播（發起直播）：46M
4）打開應用內WebView（X5內核）：56M
以上是主進程的內存，佔用相當多。需要注意的是code內存佔用一般是通過read-only方式mmap映射到內存中的的dex、odex、so等文件，因此在內存緊張的情況下，系統會回收這些內存，只是在oom-killer中仍然會計算在內。
另外播放進程2.27M，service進程1.1M還屬於比較正常的水平。
顯然主進程的Code內存佔用太多了，需要分析。這裏通過解析Linux標準的 /proc/<pid>/smaps文件，這個文件記錄了進程內每一段虛擬內存的文件映射情況，這個文件只有進程自己有讀權限，所以要麼用root的機器，要麼就自己寫段代碼copy出來。結合上面提到的工具。分析結果如下：
● 應用so佔用 app so map Rss = 3984 kB （其中IM SDK 2576k）
● 應用的dex佔用 app dex map Rss = 15101 kB
● X5內核的so+dex內存佔用 tbs mem map Rss = 29048 kB
● 直播so相關 avlive mem map Rss = 3092 kB
● 其中X5內核的代碼沒有打進apk，因此可以比較獨立的統計出來，佔用有29M之多，讓人驚訝！
● 其次直播的java代碼打進了apk不方便單獨統計內存用量，但是so是獨立加載的，內存佔用3M也是不少的。
● 最後是應用自身的dex佔用有15M之多，因爲自身代碼量很大，似乎可以理解，但是仍然很多啊！
這裏需要考慮的是 X5 內核能否延時加載？因爲沒打開WebView的時候就已經佔用了數M了。另外WebView關閉之後是否可以銷燬。
直播相關SO，可以考慮直播退出之後從內存中卸載掉。（java規範是加載so的classloader被GC，相關so即可卸載）。
應用自身dex佔用。android 8.0 對art優化一個叫做DexLayout 的能力，應爲mmap映射的文件不會被立即加載進內存，在用到的時候是按照頁大小（4k）加載的，當用到的類在dex中分佈很分散的時候，就會導致盲目加載很多頁，DexLayout就是把熱點類集中放到一起。這裏FaceBook推出了ReDex工具，可以參考一下。
PS：關於DexLayout
三
線程創建
在AndroidStudio的Memory Profiler中沒有線程數這個維度。但是運行中，主進程的線程數量通常會在100個左右，這是個驚人的數字，要知道Mac版的AndroidStudio也不過77個線程。。。。請自行體會一下。
關於線程的創建和內存佔用，請參考筆者的另一篇文章：《Android 創建線程源碼與OOM分析》 。
這裏分析用的自制工具，dump下載所有running的線程，和他們創建時的堆棧。
結果是：
● X5：25個線程（簡直。。。）
● IMSDK：17個線程
● StackBlur：8個線程
● WNS：7個線程
● ImageLoader：6個線程
● magnifiersdk：5個線程
需要注意，這裏的棧和線程名，是創建線程的時候的調用棧，以及對應的線程名（而不是子線程名）
事實上，用同樣的方法，還可以分析一下進程歷史中所有創建過的線程，統計哪裏創建線程最多。
通常來說，所有線程應該有應用統一的線程池來管理，sdk內部需要線程池，應該有外部注入一個線程池來提供給sdk使用。
如果有其他情況，如：不是在線程池創建的線程，在sdk自己的線程池裏創建的線程，這種都可能導致線程數量的野蠻增長，需要聯繫sdk的開發人員杜絕這種情況。
四
總結
以上就是這5天的工作結果：
java內存佔用基本合理，靜息態 內存佔用可以優化20M，MainActivity運行時的內存佔用可以優化5-10M。
code內存佔用太多，其中X5內核佔用29M實在太多，需要考慮優化。
應用內的線程數量主要有X5內核，IMSDK和WNS貢獻，外網線程創建的OOM crash 系WNS的bug，需要聯繫相關sdk開發人員。
最後是Native內存佔用還沒有詳細分析，暫時看不到使用情況。但是可以知道目前的結論是：Native內存佔用很多，且應該存在內存泄漏。
PS: 實際效果反饋
按照上述分析結果，進行了相關的代碼調整。
執行的點包括：
1、IntelliShowList pageSize 50->20
2、IntelliShowList 公用Album結構
3、Afc-db clearBinding after insert， 數據庫
4、Afc-FileCacheService cache Entry with fileName not full path， 文件緩存
5、 fix onTrimMemory bug,退後臺清空圖片內存緩存
6、播放頁相關控件,退後臺之後清掉icon,釋放bitma引用
未執行的點包括：
1、播放頁的bottomPannel部分icon因爲邏輯較爲複雜，暫時未進行處理。預計內存佔用1M
2、PlayLogic的historyList邏輯複雜暫時未處理，預計內存佔用500K
3、24h直播間LiveRoomShowListManager -- 287k
4、DanmuManager — 510k
5、經過ice提醒，下載節目的record也會全部加載進內存。每個ShowInfo 22k，內存佔用取決於用戶下載的節目數。
效果對比：
before：39.32M
after：12.88M
優化內存佔用 26.44M！
UPA—— 一款針對Unity遊戲/產品的深度性能分析工具，由騰訊WeTest和unity官方共同研發打造，可以幫助遊戲開發者快速定位性能問題。旨在爲遊戲開發者提供更完善的手遊性能解決方案，同時與開發環節形成閉環，保障遊戲品質。