AndroidStudio3.1.2 新版本對APP內存泄漏問題定位及優化；

Hello，大家好，這兩天在處理公司收銀平板內存泄漏的問題上學習到了不少，現在將我學習的知識分享出來，有問題的可以在底下給我留言哦.
問題：目前，我負責維護管理的是公司的收銀業務，涉及到收銀平板及相關設備。在平板上，有一功能是批量刷卡，這個功能主要是用來減少單次刷卡的操作時間。但是呢，最近客戶反饋一個問題，說有一個用戶需要支付兩萬多元，但是每一張儲值卡最多隻有500元，那麼就需要不停的刷卡，預計需要刷卡刷到64次，但在實際刷卡刷了24次的時候，收銀平板就已經卡到不能自理了（用戶的一個操作，需要等5-8秒來反映出來）。
分析：
1.針對這個問題呢，我首先想到的問題就是是否是系統分配給我們應用內存不夠用了。那麼說幹就幹，我就開始驗證了。通過 adb pull /system/build.prop [目標地址]，將安卓系統中的配合文件放置到我們的電腦文件下。

！[如果提示沒有權限，嘗試使用管理員權限打開DOS窗口]
打開build.prop文件，對其進行分析;！
）
我們能夠看到這3項配置
dalvik.vm.heapstartsize =8m
dalvik.vm.heapgrowthlimit =64m
dalvik.vm.heapsize =384m
通過百度，我們不難看出：
heapstartsize是指應用打開時的初始大小；
heapgrowthlimit表示單個應用可用的最大內存；
heapsize表示單個進程可用的最大內存（heapsize表示不受控情況下的極限堆，表示單個虛擬機或單個進程可用的最大內存。而android上的應用是帶有獨立虛擬機的，也就是每開一個應用就會打開一個獨立的虛擬機（這樣設計就會在單個程序崩潰的情況下不會導致整個系統的崩潰））
注意：在設置了heapgrowthlimit的情況下，單個進程可用最大內存爲heapgrowthlimit值。在android開發中，如果要使用大堆，需要在manifest中指定android：largeHeap爲true，這樣dvmheap最大可達heapsize。
參考鏈接：https://www.cnblogs.com/onelikeone/p/7112184.html
這樣，我們就理解了安卓系統對單應用的內存限制，於是乎，我們通過Andorid Profiler中的Memory項對內存的使用情況進行監控。實際操作過程中呢，我發現內存變化幾乎維持在90-110m之間，但是隨着刷卡的次數增添，平板卻變得非常卡，那麼到此，可以排除平板變卡是因爲內存不夠的猜想了。

2.第二個猜想是，不規範的代碼導致了該被回收的實例沒有被系統回收掉，當刷卡的次數變多了，那麼在內存中的實例也就變多了，從而導致平板變的卡頓。說幹就幹，於是就百度:在這裏推薦該帖子：https://www.jb51.net/article/127295.html，該帖子主要講解了新版本AndroidStudio中如何使用Android Profiler來查詢項目中的那些地方存在內存泄漏問題。但是該貼有一個缺陷，就是沒有講解該如何去處理髮現的內存泄漏問題。這裏，我們接着該帖子往下講。
在我們通過包名找到沒有被系統回收的類的時候，通過分析每個類的實例數，來判斷是否被系統回收掉，是否出現了內存泄漏。
正常情況下，內存泄漏的原因有以下幾種：
1.靜態變量沒有及時置空
2.實體類未及時置空，也有可能存活在內存中
3.廣播、Handler的佔用等，一般我們將廣播（Handler）用靜態內部類加上弱引用的方式來寫。這樣在退出Activity的時候不會因爲線程或者廣播的佔用而導致無法回收。JAVA中非靜態內部類會對當前Activity有一個隱式的引用。

並且要善用AndroidProfiler中的references功能，在這裏會給你提供一些明顯的細節，讓你知道內存泄漏是哪裏導致的。然後我們對症下藥來進行代碼優化。
文筆有限，本人的技術也有限，有疑問的朋友可以在下方留言，我們一起學習進步！