作者：shwenzhang
Android 記憶體優化是我們性能優化工作中比較重要的一環，這裡其實主要包括兩方面的工作：
優化RAM，即降低運作時記憶體。這裡的目的是防止程式發生OOM異常，以及降低程式由于記憶體過大被LMK機制殺死的機率。另一方面，不合理的記憶體使用會使GC大大增多，進而導緻程式變卡。
優化ROM，即降低程式占ROM的體積。這裡主要是為了降低程式占用的空間，防止由于ROM空間不足導緻程式無法安裝。
本文的着重點為第一點，總結概述降低應用運作記憶體的技巧。在這裡我們不再細述PSS、USS等概念與Android應用的記憶體管理，如對這部分内容感興趣，可自行閱讀文末的參考文章。
記憶體洩露：簡單來說對象由于編碼錯誤或系統原因，仍然存在着對其直接或間接的引用，導緻系統無法進行回收。記憶體洩露，容易留下邏輯隐患,同時增加了應用記憶體峰值與發生OOM的機率。它屬于bug issue,是我們一定要修改的。
下面是造成記憶體洩露的一些常見原因，但是如何建立一套發現記憶體洩露、解決記憶體洩露的閉環方案，才是我們工作的重點。
Square的開源庫leakcanry是一個非常不錯的選擇,它通過弱引用方式偵查Activity或對象的生命周期，若發現記憶體洩露自動dump Hprof檔案，通過HAHA庫得到洩露的最短路徑，最後通過notification展示。
記憶體洩露判斷與處理的流程如下圖 ，各自運作的程序空間(主程序通過idlehandler，HAHA分析使用的是單獨的程序)：
微信在leakcanry推出之前已經有了自己的記憶體洩露監控體系，與leakcanry大緻有以下的差別：
在微信中，對于4.0以上的機型也是采用通過注冊ActivityLifecycleCallbacks接口，對于4.0以下的機型我們會嘗試反射ActivityThread中的mInstrumentation對象。當然，現在微信也改成隻支援android-15以上，美美哒。
leakcanry盡管使用了idlehandler與分程序，但是dumphprof依然會造成應用明顯的卡頓(SuspendAll Thread)。而在三星等一些手機，系統會緩存最後一個Activity，是以在微信，我們采取了更嚴格的檢測模式，即洩露三次确認以及經過5個建立的Activity，確定不是由于系統緩存的原因造成。
在微信中，當發現疑似記憶體洩露時會彈出對話框，當我們主動點選時才會去做dumpHprof以及上傳Hprof快照的操作，而是否誤報、洩露鍊等分析工作也是放于伺服器端。
事實上，通過對leakcanry做簡單的定制，我們就可以實作以下一個記憶體洩露監控閉環。
AndroidExcludedRefs列出了一些由于系統原因導緻引用無法釋放的例子，同時對于大多數的例子，都會提供建議如何通過hack的建議去修複。在微信中，對TextLine、InputMethodManager、AudioManger、android.os.Message也采用了類似Hack的方式(詳細可看參考資料)。
Activity洩漏會導緻該Activity引用到的Bitmap、DrawingCache等無法釋放，對記憶體造成大的壓力，兜底回收是指對于已洩漏Activity，嘗試回收其持有的資源，洩漏的僅僅是一個Activity空殼，進而降低對記憶體的壓力。
做法也非常簡單，在Activity onDestory時候從view的rootview開始，遞歸釋放所有子view涉及的圖檔，背景，DrawingCache，監聽器等等資源，讓Activity成為一個不占資源的空殼，洩露了也不會導緻圖檔資源被持有。
總的來說，我們不是隻懂得一些記憶體洩露解決方法就可以，更重要的是通過日常測試與監控，得到記憶體洩露檢測與修改的一整套閉環體系。
當我們能確定應用中不會出現記憶體洩露時，我們需要一些其他的方法來降低運作時的記憶體。更多的時候，我們其實隻希望降低應用發生OOM的機率。
Android OOM：
Android 2.x系統，當dalvik allocated + external allocated + 新配置設定的大小 >= dalvik heap 最大值時候就會發生OOM。其中bitmap是放于external中 。
Android 4.x系統，廢除了external的計數器，類似bitmap的配置設定改到dalvik的java heap中申請，隻要allocated + 新配置設定的記憶體 >= dalvik heap 最大值的時候就會發生OOM（art運作環境的統計規則還是和dalvik保持一緻）
說到記憶體，bitmap必然是這裡的大頭。對于bitmap記憶體占用，想說的有以下幾點:
防止bitmap占用資源多大導緻OOM
Android 2.x 系統 BitmapFactory.Options 裡面隐藏的的inNativeAlloc反射打開後，申請的bitmap就不會算在external中。對于Android 4.x系統，可采用facebook的fresco庫，即可把圖檔資源放于native中。
圖檔按需加載
即圖檔的大小不應該超過view的大小。在把圖檔載入記憶體之前，我們需要先計算出一個合适的inSampleSize縮放比例，避免不必要的大圖載入。對此，我們可以重載drawable與ImageView，例如在Activity ondestroy時，檢測圖檔大小與View的大小，若超過，可以上報或提示。
統一的bitmap加載器
Picasso、Fresco都是比較出名的加載庫，同樣微信也有自己的庫ImageLoader。加載庫的好處在于将版本差異、大小處理對使用者不感覺。有了統一的bitmap加載器，我們可以在加載bitmap時，若發生OOM(try catch方式)，可以通過清除cache，降低bitmap format(ARGB8888/RBG565/ARGB4444/ALPHA8)等方式，重新嘗試。
圖檔存在像素浪費
對于.9圖，美工可能在出圖時在拉伸與非拉伸區域都有大量的像素重複。通過擷取圖檔的像素ARGB值，計算連續相同的像素區域，自定義算法判定這些區域是否可以縮放。關鍵也是需要将這些工作做到系統化，可及時發現問題，解決問題。
一個好的imageLoader，可以将2.X、4.X或5.X對圖檔加載的處理對使用者隐藏，同時也可以将自适應大小、品質等放于架構中。
對于系統函數onLowMemory等函數是針對整個系統而已的，對于本程序來說，其dalvik記憶體距離OOM的內插補點并沒有展現，也沒有回調函數供我們及時釋放記憶體。假若能有那麼一套機制，可以實時監控程序的堆記憶體使用率，達到設定值即關于通知相關子產品進行記憶體釋放，這會大大的降低OOM。
實作原理
這個其實比較簡單，通過Runtime獲得maxMemory,而totalMemory-freeMemory即為目前真正使用的dalvik記憶體。
<code>Runtime.getRuntime().maxMemory(); Runtime.getRuntime().totalMemory() -</code> <code>Runtime.getRuntime().freeMemory()；</code>
操作方式
我們可以定期(前台每隔3分鐘)去得到這個值，當我們這個值達到危險值時(例如80%)，我們應當主要去釋放我們的各種cache資源(bitmap的cache為大頭)，同時顯示的去Trim應用的memory,加速記憶體收集。
對于webview，圖庫等，由于存在記憶體系統洩露或者占用記憶體過多的問題，我們可以采用單獨的程序。微信目前也會把它們放在單獨的tools程序中
當系統發生OOM的crash時，我們應當上傳更加詳細的記憶體相關資訊，友善我們定位當時記憶體的具體情況。
其他例如使用large heap、inBitmap、SparseArray、Protobuf等不再一一細述，對代碼采用優化--埋坑--優化--埋坑的方式并不推薦。我們應該着力于建立一套合理的架構與監控體系，能及時的發現諸如bitmap過大、像素浪費、記憶體占用過大、應用OOM等問題。
Java擁有GC的機制，不同的系統版本GC的實作可能有比較大的差異。但是無論哪種版本，大量的GC操作則會顯著占用幀間隔時間(16ms)。如果在幀間隔時間裡面做了過多的GC操作，那麼自然其他類似計算，渲染等操作的可用時間就變得少了。
GC的類型有以下幾種，其中GC_FOR_ALLOC是同步方式進行，對應用幀率的影響最大。
GC_FOR_ALLOC
當堆記憶體不夠的時候容易被觸發，尤其是new一個對象的時候，很容易被觸發到，是以如果要加速啟動，可以提高dalvik.vm.heapstartsize的值，這樣在啟動過程中可以減少GC_FOR_ALLOC的次數。注意這個觸發是以同步的方式進行的。如果GC後仍然沒有空間，則堆進行擴張
GC_EXPLICIT
這個gc是被可以調用的，比如system.gc, 一般gc線程的優先級比較低，是以這個垃圾回收的過程不一定會馬上觸發， 千萬不要認為調用了system.gc，記憶體的情況就能有所好轉
GC_CONCURRENT
當配置設定的對象大小超過384K時觸發，注意這是以異步的方式進行回收的.如果發現大量反複的Concurrent GC出現，說明系統中可能一直有大于384K的對象被配置設定，而這些往往是一些臨時對象，被反複觸發了。給到我們的暗示是：對象的複用不夠。
GC_EXTERNAL_ALLOC （在3.0系統之後被廢了）
Native層的記憶體配置設定失敗了，這類GC就會被觸發。如果GPU的紋理、bitmap、或者java.nio.ByteBuffers的使用沒有釋放，這種類型的GC往往會被頻繁觸發。
Memory Churn記憶體抖動，記憶體抖動是因為在短時間内大量的對象被建立又馬上被釋放。瞬間産生大量的對象會嚴重占用記憶體區域，當達到閥值，剩餘空間不夠的時候，會觸發GC進而導緻剛産生的對象又很快被回收。即使每次配置設定的對象占用了很少的記憶體，但是他們疊加在一起會增加Heap的壓力，進而觸發更多其他類型的GC。這個操作有可能會影響到幀率，并使得使用者感覺到性能問題。
通過Memory Monitor，我們可以跟蹤整個app的記憶體變化情況。若短時間發生了多次記憶體的漲跌，這意味着很有可能發生了記憶體抖動。
通過Heap Viewer，我們可以檢視目前記憶體快照，便于對比分析哪些對象有可能發生了洩漏。更重要的工具是Allocation Tracker，追蹤記憶體對象的類型、堆棧、大小等。手Q有做一個統計工具，對Allocation Tracker的原始資料，按照（類型&堆棧）的組合（堆棧取棧頂的5層）統計某一種對象配置設定的大小、次數。同時按照次數、大小的排序，從多/大到少/小結合代碼分析，并自頂向下的逐輪進行優化。
這樣，我們就可以快速知道發生記憶體抖動時，是因為哪些變量的建立造成頻繁GC。一般來說我們需要注意以下幾個方面：
1、字元串拼接優化
減少字元串使用加号拼接，改為使用StringBuilder。減少StringBuilder.enlarge，初始化時設定capacity；這裡需要注意的是，若打開Looper中Printer回調,也會存在較多的字元串拼接。
2、讀檔案優化 讀檔案使用ByteArrayPool，初始設定capacity，減少expand
3、資源重用
建立全球緩存池，對頻繁申請、釋放的對象類型重用
4、減少不必要或不合理的對象
例如在ondraw、getview中應減少對象申請，盡量重用。更多是一些邏輯上的東西，例如循環中不斷申請局部變量等
5、選用合理的資料格式 使用SparseArray, SparseBooleanArray, and LongSparseArray來代替Hashmap
我們并不能将記憶體優化中用到的所有技巧都一一說明，而且随着Android版本的更替，可能很多方法都會變的過時。我在想更重要的是我們能持續的發現問題，精細化的監控，而不是一直處于"哪個有坑填哪裡的"的窘況。在這裡給大家的建議有：
率先考慮采用已有的工具；中國人喜歡重複造輪子，我們更推薦花精力去優化已有工具，為廣大碼農做貢獻。生活已不易，碼農何為為難碼農！
不拘泥于點，更重要在于如何建立合理的架構避免發生問題，或者是能及時的發現問題。
目前微信記憶體監控體系中也存在一些不盡人意的地方，在未來的日子裡也同樣需要努力去優化。
[1].Android記憶體管理
[2].leakcanary
[3].AndroidExcludedRefs
[4].fresco
[5].優化安卓應用記憶體的神秘方法以及背後的原理
[6].Android性能優化之記憶體篇
本文來源于：WeMobileDev 微信公衆号