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功能，在这里会给你提供一些明显的细节，让你知道内存泄漏是哪里导致的。然后我们对症下药来进行代码优化。
文笔有限，本人的技术也有限，有疑问的朋友可以在下方留言，我们一起学习进步！