Android内存泄漏问题分析

关于内存泄漏有很多中问题引起，比如：

1. Context引用（常见的就是单例模式的套用），通过context来获取系统服务；
2. 图片bitmap的处理；
3. Handler的Runnable回调；
4. 强引用；
5. 在一个Activity内启动了一个线程但在该Activity退出时却没有即时关闭该线程等；

内存泄漏最终会导致我们常说的OOM；

一般解决办法如下：

1. 对于Context一般会使用applicationContext代替，同时我们编码过程尽量做到与context解耦；
2. 图片属于大内存的处理的问题，需要手动进行释放，使用完毕后注意对其recycle。
3. 一般我们需要在当前时间下间隔一段时间去操作某个事情时，我们可以直接用Handler定时，比定时器会简单点，但在完成操作要即使移除绑定的Runnable；
4. 对于强引用，要注意对其的释放，可以改成SoftwareReference或WeakReference下建议改成这两种方式；
5. 对于这种情况我们可以使用异步任务或者IntentService代替，我们编码尽量少出现这种new Thread{}.start;的代码，因为启动一个线程是要花费系统较多的资源的，建议采用线程池代替（注意线程池的容量问题）；

       分析完以上这几种情况，那么问题来了，我们要如何来找一个app是否有内存泄漏的问题呢？总不能老是要等到app崩溃后再来分析吧，可以用Android Studio的Montior观察，启动一个Activiy然后退出该Activity，观察这个过程内存的变化过程感性判断，也可以用使用AS内存检测工具获得内存报告，前后比对，eclipse的DDMS中的heap工具这里就不赘述了；

      在感性判断后，怎样排查问题这个才是关键点，对于这种情况网上有好多工具如MAT定位内存泄漏位置，这里建议使用leakcanry，它会在app发生内存泄漏时将泄漏的栈显示出来，这样有利于我们大致定位然后深入排查。

工具的工具下载地址：https://download.csdn.net/download/u012724841/10500112

需要的资源下载地址：https://download.csdn.net/download/u012724841/10500139

使用详见第一个链接的readme.txt；

该工具在检查内存发现有泄漏问题时会有一个toast提示，同时可打开桌面的Leaks查看发生泄漏的栈。