动脑学院 Ricky老师 2017年11月27日录制
什么是内存泄露?
内存不在GC的掌控之内了。
- 了解几个问题
- 垃圾回收机制 GC
- 某对象不再有任何的引用才会进行回收。
- GC回收机制的原理
- GC Root,可以作为GC Root引用点的是
- JavaStack中的引用对象
- 方法区中静态引用指向的对象
- 方法区中常量引用指向的对象
- Native方法中JNI引用的对象
- Thread–活着的线程
- GC Root,可以作为GC Root引用点的是
- 怎么判断一个对象是垃圾对象?
- 这是一个主观的判断
- 内存泄露多了容易导致OOM–内存溢出,app会崩溃
- 垃圾回收机制 GC
确定我们的项目当中或者某几个类中是否存在内存泄露
同屏工具:Total Control
初略判断:
Android Monitor–>System Information–>MemoryUsage查看Objects里面是否有没有释放的Views或者Activities
命令行:adb shell dumpsys meminfo 包名 -d
确定内存泄露的大致范围
- Android Studio:查看Memory Monitor工具
- 检查一个一个动作(比如Activity的跳转)反复多次执行某一个操作,不断地通过这个工具查看内存的大概变化情况。前后两个内存变化增加了不少。
更仔细地查找泄露的位置
* 在As中使用 Heap SnapShot工具(堆栈快照)
问题出现在:
解决:
instance = new CommUtils(mContext.getApplicationContext());//可以传这个
不使用Activity是下文,而是使用Application的上下文,因为Application的生命周期长,进程退出的时候才会销毁,和Static的CommUtils的生命周期一样长。
使用更高级的分析工具来更具体地找到这个泄露的家伙。
LeakCanary 有些使用会不靠谱 ==
MAT工具。需要下载 MemoryAnalyzer
两个步骤的快照对比。
右键 list objects -out(引用了谁|incoming(被谁引用
incoming-右键-Merge Shortest Paths to GC Roots–exclude all phatom/weak/soft etc….
对比之后就出现了
第二个Activty的引用:
第一个Activty的引用:系统的输入法的引用
小结工具:
- Allocation Tracker
- Heap Snapshot
- Heap View
- LeakCanary
- MAT
- TraceView