性能优化之内存泄露

动脑学院 Ricky老师 2017年11月27日录制

什么是内存泄露？

内存不在GC的掌控之内了。

• 了解几个问题
  
  • 垃圾回收机制 GC
    
    • 某对象不再有任何的引用才会进行回收。
  • GC回收机制的原理
    
    • GC Root，可以作为GC Root引用点的是
      
      • JavaStack中的引用对象
      • 方法区中静态引用指向的对象
      • 方法区中常量引用指向的对象
      • Native方法中JNI引用的对象
      • Thread–活着的线程
  • 怎么判断一个对象是垃圾对象？
    
    • 这是一个主观的判断
    • 内存泄露多了容易导致OOM–内存溢出，app会崩溃

确定我们的项目当中或者某几个类中是否存在内存泄露

同屏工具：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