使用流程:
1.找出有泄漏嫌疑的对象 原理
2.确诊 使用haha 可达性分析
使用方法:
添加leakcanary的支持库即可
debugImplementation "com.squareup.leakcanary:leakcanary-android:2.3"
不需要添加代码,执行后发生泄漏可以直接查看引用持有,也可以导出去AMT查看分析。
LeakCanary初始化
contentprovider的oncreate比application的oncreate创建的更早。详见AMS启动流程
leakcanary的Manifeast清单中有provider,apk打包流程中 mergeAndroidManifest.xml会把app和依赖库所有的清单文件合并到一起。
LeakCanary检测Activity退出原理
Activity有生命回调函数
public interface ActivityLifecycleCallbacks{}
而leakCanary注册了一个ActivityLifecycleCallbacksAdapter重写了onActivityDestroyed方法,遍历Activity使用refWatcher.watch()方法监测每个Activity实例。
主要是使用了Activity的生命周期回调
RefWatcher核心原理
Java四种引用
一,强引用
Java中默认声明的就是强引用,比如:
Object obj = new Object(); //只要obj还指向Object对象,Object对象就不会被回收
obj = null; //手动置null
只要强引用存在,垃圾回收器将永远不会回收被引用的对象,哪怕内存不足时,JVM也会直接抛出OutOfMemoryError,不会去回收。如果想中断强引用与对象之间的联系,可以显示的将强引用赋值为null,这样一来,JVM就可以适时的回收对象了
二,软引用
软引用是用来描述一些非必需但仍有用的对象。在内存足够的时候,软引用对象不会被回收,只有在内存不足时,系统则会回收软引用对象,如果回收了软引用对象之后仍然没有足够的内存,才会抛出内存溢出异常。这种特性常常被用来实现缓存技术,比如网页缓存,图片缓存等。
在 JDK1.2 之后,用java.lang.ref.SoftReference类来表示软引用。
如果一个对象惟一剩下的引用是软引用,那么该对象是软可及的(softly reachable)。垃圾收集器并不像其收集弱可及的对象一样尽量地收集软可及的对象,相反,它只在真正 “需要” 内存时才收集软可及的对象。
三,弱引用
弱引用的引用强度比软引用要更弱一些,无论内存是否足够,只要 JVM 开始进行垃圾回收,那些被弱引用关联的对象都会被回收。在 JDK1.2 之后,用 java.lang.ref.WeakReference 来表示弱引用。
四,虚引用
虚引用是最弱的一种引用关系,如果一个对象仅持有虚引用,那么它就和没有任何引用一样,它随时可能会被回收,在 JDK1.2 之后,用 PhantomReference 类来表示,通过查看这个类的源码,发现它只有一个构造函数和一个 get() 方法,而且它的 get() 方法仅仅是返回一个null,也就是说将永远无法通过虚引用来获取对象,虚引用必须要和 ReferenceQueue 引用队列一起使用。
ReferenceQueue
含义以及作用:
通常叫为引用队列,换言之就是存放引用的队列,保存的是Reference对象。其作用在于Reference对象所引用的对象被GC回收时,该Reference对象将会加入引用队列中的队列末尾
常用方法:
poll():从队列中取出一个元素,队列为空返回null
remove():从队列中出队一个元素,若没有则阻塞至有可出队元素
remove(long timeout):从队列中出队一个元素,若没有则阻塞至有可出队元素或阻塞至超过timeout毫秒
如对于Reference和ReferenceQueue:
Reference对象可以看作一个容器,可存放4种引用对象,假如存放的对象被gc回收后,就会把Reference置入ReferenceQueue种,通过判断Reference容器是否为空就可以看出来是否已释放
测试实例
public class WeakReferenceTest {
/**
* WeakReference和ReferenceQueue联合使用案例
* 也是用来监控某个对象是否被gc回收的手段
* @param args
*/
public static void main(String[] args) {
System.out.println("hello world");
ReferenceQueue referenceQueue = new ReferenceQueue();
Object obj = new Object();
//把obj放入weakReference,并和一个referenceQueue关联
//当obj被gc回收后,盛放它的weakReference会被添加与之关联的referenceQueue
WeakReference weakReference = new WeakReference(obj,referenceQueue);
System.out.println("盛放obj的weakReference = " + weakReference);
//把obj置空,让它没有强引用
obj = null;
Runtime.getRuntime().gc();//gc,让可以回收的对象回收
try{
Thread.sleep(1000);
}catch (Exception e){}
Reference findRef = null;
do{
findRef = referenceQueue.poll();
//如果能找到上面的weakReference => 说明它盛放的obj被gc回收了
System.out.println("findRef = " +findRef + "是否等于上面的weakReference = " + (findRef == weakReference));
}while(findRef !=null);//把所有放到referenceQueue的引用容器找出来
}
}
leakcanary执行流程
watch()5s 观测 队列的引用列表 给每一个obj生成唯一uuid 列表为 watchReferences[key,obj],过了5秒后
如过在队列种找到gc中回收的对象,则 watchReferences会remove该对象,若没有找到,则会加入到retainedReferences,当retainedReferences.size>5后则会使用haha进行可达性分析,观测是否发生泄漏