Android性能优化（Memory）

性能相关：UI卡顿 / ANR / 内存泄漏——>OOM

内存泄漏的本质：较长生命周期对象持有较短生命周期的引用导致，较短引用没法释放内存。

GcRoots：Garbage Collector 的对象, 收集非GC Roots的引用对象，通常的GC Root有哪些？

www.jianshu.com/p/dcfe84c50…

通过System Class Loader或者Boot Class Loader加载的class对象，通过自定义类加载器加载的class不一定是GC Root
处于激活状态的线程
栈中的对象
JNI栈中的对象
JNI中的全局对象
正在被用于同步的各种锁对象
JVM自身持有的对象，比如系统类加载器等。
复制代码

通常这里涉及的 静态的对象，其它运行线程持有当前的引用。

LeakCanary原理watch一个即将要销毁的对象：

1. 栈（stack）
2. 堆（heap）
3. 方法区（method）

常见的内存泄漏：

1. 单例持有context, 写成 ApplicationContext
2. 非静态内部类创建静态实例造成的内存泄漏（改成静态的内部类）
3. Handler（TLS，handler生命周期跟Activity的生命周期不一样） handler.postDelay延迟发送。原因message 持有handler，handler持有Activity，将Handler设置为静态的（以弱引用的方式持有Activity）
4. 线程的内存泄漏。AsyncTask，Thread+Runnable，以及Handler(将他们定义为static, 调用AsyncTask的Cancel方法)
5. Webview，hybird。webview加载网页申请native内存加载页面，（1.将webview放在单独的Webview的进程里； 2. 在Webview所在的Activity在onDestory的时候killProcess）

LeakCanary源码：

内存泄漏会造成OOM的罪魁祸首 探究源码，检测Activity泄漏的机制，LeakCanary的原理

Activity泄漏检测原理

1. 将Activity Destory之后将它放在一个WeakReference
2. 将这个WeakReference放到引用队列ReferenceQueue

####ReferenceQueue 软引用/弱引用

对象被GC回收，Java虚拟机会把它加入到ReferenceQueue中

关于ReferenceQueue: www.cnblogs.com/dreamroute/…

四种引用类型：

StrongReference

softReference（内存空间不够时才回收）

WeakReference（）

virtualReference(虚引用)

RefWatcher

监控Activity的内存泄漏

LeakCanary.enableDisplayLeakActivity(控制弹框)

1. 创建一个refwatcher，启动一个ActivityRefWatcher监听Activity的生命周期的情况（新版本没有排除系统Reference的引用）

   //Refwatcher类结构
   public final class RefWatcher {
   
     public static final RefWatcher DISABLED = new RefWatcherBuilder<>().build();
   
     private final WatchExecutor watchExecutor;//执行内存泄漏检测用的
     private final DebuggerControl debuggerControl;//查询是否在代码调试中，调试的时候就不检测
     private final GcTrigger gcTrigger;//处理GC的，用于判断泄漏之前给最后一次机会是否会GC，否者会显示出来
     private final HeapDumper heapDumper;//Dump出内存泄漏的堆文件
     private final HeapDump.Listener heapdumpListener;//分析产生Heap文件的回调
     private final HeapDump.Builder heapDumpBuilder;
     private final Set retainedKeys;//待检测的产生泄漏的Key
     private final ReferenceQueue