最近接手的一個老專案，功能比較繁雜，是執行在安卓pos機上面的收銀系統，基本需要應用整天在前臺使用，對系統穩定性要求較高，不同於一般app。

今天做了記憶體方面的檢測

首先我們用電腦連線裝置，用cmd執行adb的記憶體檢測的命令

adb shell dumpsys meminfo best.DianJiaPos

後面的best.DianJiaPos是包名，要改成自己的

執行後會顯示如下資訊：

這裡面需要關心的有：HeapSize（堆總大小）HeapAlloc（已用大小）HeapFree（剩餘可用）

分為Native Heap和Dalvik Heap，這裡我們只關心Dalvik Heap

另外還有一些應用相關資訊：Views，Activitys等，可以統計到已經存在的view和activity個數

那麼，怎麼判斷一個activity是否發生洩漏？

這裡有個簡單的辦法，先使用以上命令，獲取activity個數，然後在應用內執行一些可用關閉activity的操作，比如切換使用者，退出登入，或者一些介面的返回鍵finish等

activity執行finish或onDestroy之後，再次執行以上命令，獲取記憶體資訊，看activity個數，如果個數沒有減少，這個activity就很可能發生洩漏了

下面是我的MainActivity介面

應用邏輯是，從LoginActivity中登入，登入成功進入MainActivity，然後在MainActivity中有切換使用者功能，點選之後會銷燬MainActivity進入LoginActivity

此時的activity數量應該是1，如果多了就很可以，可能是有其他的功能邏輯，繼續持有MainActivity的引用，導致MainActivity資源無法釋放

在我進行多次上述操作之後，獲取記憶體資訊，發現activity數量已經達到十幾個，顯然存在activity洩漏

接下來我們使用Android studio 的Analyzer Task進行分析

首先，進行可能產生記憶體洩漏的操作

之後，進入androidstudio開發介面，下方切換到monitors，點選下面的儲存的圖示

稍等片刻，androidstudio儲存好hprof檔案後會自動開啟

開啟後介面如上，右側有一個Analyzer Task

點開它，點選藍色箭頭，會自動幫我們分析記憶體洩漏

如圖，檢測到了MainActivity

選中之後，下方會顯示相關資訊，這裡提醒大家除錯時候一定要關掉混淆，否則，這裡檢測出來的程式碼變數，都是混淆後的，很難找到目標

如上圖，Analyzer Task自動幫我們檢測出可能的洩漏處，並用藍色字型顯示

點開之後如圖所示，這裡解釋一下引用關係

上圖的結構，表示MainActivity被PrnDspA1088這個類的s變數引用

而s變數又被CashierFragment的dsp變數引用

那麼接下來看看CashierFragment的程式碼

private static PrnDspA1088 dsp = null;

dsp = new PrnDspA1088(getActivity());

常見的記憶體洩漏原因除了static引用之外，還有資源未釋放/服務未解綁/EventBus未登出/TimeTask未停止等

大家使用這些的時候一定不要忘記釋放資源。