内存泄漏原因
根据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可打开此文件查看。
任重而道远