Android内存泄漏

内存泄漏原因

根据gc回收机制，已销毁的组件或对象还被引用，导致无法被回收，导致内存泄漏，内存占用将越来越多，而虚拟机为每个App分配内存是有限的，最终内存溢出。

1，Application引用Activity，Application的生命周期是整个App的周期，如果引用某一个Activity实例，将导致Activity组件销毁时，对象无法回收。
2，匿名内部类，非静态内部类，他们会持有外部类对象的引用。在Activity中定义的，导致无法回收。如Handler消息队列有未处理消息但是Activity已经销毁，导致泄漏，静态或弱引用解决。还有Thread，以及AsyncTask。
3，static修饰的变量引用Activity，同理，static的生命周期是整个app的周期。
4，单例模式，生命周期与app相同，导致泄漏。
5，资源未关闭，造成的内存泄漏，如file，curse，stream，在finally中close关闭资源对象，。
6，Activity内部创建一个静态对象，构造方法包含Context，使用this传入创建。
7，WebView内存泄漏。未unregister，callback。先移除view，在destory。解决方案可以开启一个独立进程，aidl和主进程通信。
8，容器对象未清理，将引用从集合中清除掉。
9，注册对象未注销。如BraodcastReceiver注册。

Handler导致内存泄漏

Handler绑定主线程消息队列和Looper，同时，内部匿名Handelr定义会持有外部Activity的实例，在这种情况下，如果我们通过Handler发送了一个延迟几分钟的消息到主线程消息队列，销毁Activity。
因为消息已经放在主线程消息队列，消息队列由主线程一直在处理，肯定不会被回收，而刚才的消息被插入到队列中，还有一定时间才会处理，也不会被回收，同时，消息中拿着该Handler的引用，即target，这个是关键，Handler也不会被回收，导致Activity无法被回收。

解决方案：只要不持有Activity的强引用即可。
1，静态内部类+弱引用。
2，外部类定义Handler。
3，结束Activity时，将消息移除队列，切断了和消息队列的关系，这样msg即可以被gc，那么handler也会。

内存分析工具

1，直接在As查看内存分配情况，操作应用时，内存一直往上涨说明存在内存泄露。
2，内存泄露分析工具MAT(Memory Analyzer tool)。
3，LeakCanary快速定位内存泄露。

Android Profiler

监控应用内存，cpu和网络的图形化工具，可以显示可用/已用内存。
内存监控Memory Profiler整合了Heap Viewer，Allocation Tracker和Memory Monitor的特性，可以观察对象分配实时数量，观察一段时间内的垃圾收集事件，Force GC，Dump Java heap。

Heap Viewer

5.0及以上的系统，查看所有内存情况，手动GC。
Heap Size，堆栈分配App的内存大小，Allocated，使用大小，Free，空闲大小，Used，使用率，Object，对象数量。
展现所有数据类型的内存情况。

Allocation Tracker

分配跟踪记录App的内存分配，列出调用堆栈，查看所有对象内存分配周期。
启动Allocation Tracking，操作App，结束追踪。生成alloc文件，记录此次追踪到的所有内存数据。Android Stuido可打开此文件查看。

任重而道远