作者：陳帥團隊：騰訊移動品質中心TMQ
APP占用記憶體的測試，要比CPU的更為簡單。App memory資料來源是dumpsys meminfo。當然，首先需要了解清楚dumpsys裡面這些數值的含義是什麼，這裡不詳述。
Android程式記憶體主要是兩部分：native和dalvik。dalvik就是我們平常說的java堆，我們建立的對象是在這裡面配置設定的，而bitmap是直接在native上配置設定的，對于記憶體的限制是native+dalvik 不能超過最大限制，否則OOM。
圖一dumpsys meminfo資訊
與CPU耗電jiffs資料的采集一緻，直接繼承Performace基類，然後使用threading.Timer定時器來每隔3秒運作一次__fun_get_mem，調用dumpsys meminfo來擷取相關記憶體資訊。如下圖中，隻收集了TOTAL的資料，如果要具體分析native和dalvik的記憶體資訊，也可以将其資料單獨過濾出來儲存。start()在主路徑的set_up()中調用，保證在執行test() UI自動化場景用例時，定時器一直在收集資料，直到tear_down()調用stop()将定時器取消。
圖二記憶體資訊收集邏輯
評估一個使用場景是否存在記憶體洩漏，如從APP首頁進入一個二級頁面，我們隻需要将這個操作封裝成UI自動化，重複執行N遍，即可獲得如下資料曲線。隻要資料曲線不是如下圖中的灰色平緩曲線，則可以證明該場景是有記憶體洩漏的。
圖三記憶體洩漏示意圖
同樣，如果隻提供上述的曲線給開發，定位問題也會比較麻煩，測試在記憶體洩漏的測試中，也可以多做一些。如果是Dalvik記憶體洩漏，也可以使用Android Device Monitor dump出一份hprof檔案（别忘了先手工Cause GC）。
圖四DDMSdump記憶體
拿到hprof檔案後，可以導入Android Studio中檢視，一般檢視Retained Size占用最大的類，分析是否有記憶體洩漏，一個對象的ShallowHeap，指的是該對象自身占用記憶體的大小。一個對象的 Retained Heap, 指的是當該對象被GC回收時，所釋放掉的記憶體大小。由于該對象先前可能直接或間接持有對其他多個對象的引用，那麼當它自己被回收時，被它所引用的其他對象有些也可能會被回收，是以這種情況下，該對象的Retained Heap既包括他自身占用記憶體的大小，也包括所有被它直接或間接引用的某些對象占用記憶體的大小。
圖五使用Android Studio檢視記憶體洩漏
Android Studio的分析不夠強大，也可以借助MAT來分析記憶體洩漏：更多内容參考http://blog.csdn.net/cleverGump/article/details/52013873。
在連結内容中，可以關注下GIMP相關的内容，因為在APP中因為記憶體洩漏引起OOM一般會跟圖檔有關，其他對象往往沒有bitmap對象大，是以解決圖檔相關的記憶體洩漏是優先級非常高的。
篇幅有限，還有很多深入的内容無法一一鋪陳，後續将繼續深入學習記憶體洩漏測試的相關内容。
搜尋微信公衆号：騰訊移動品質中心TMQ，擷取更多測試幹貨！