LeakCanary
LeakCanary是Square公司开源的检测内存泄露的工具, 如果怀疑自己或者队友写的代码存在内存泄露, 交给LeakCanary, 它能帮你查个水落石出. 它只在Debug版本中使用, 在release版本中都是空的实现, 可以放心集成到自己的项目中.
LeakCanary使用
LeakCanary使用极其简单, 只要在gradle中加入依赖, 在Application的onCreate()中加入一句简单的代码
LeakCanary.install(this);
就可以在Activity内存泄露的第一时间发现它, 而不是到系统频繁OOM再去抽丝剥茧地找到它.
如果想要LeakCanary能检测到Fragment发生的泄露, 还要在BaseFragment(别说没有)的onDestoroy()中加入
App.getRefWatcher().watch(this);
其中的App.getRefWatcher()就是在Application中得到的RefWatcher对象
LeakCanary分析
十分好奇它是如何做到这么神奇的功能的, 下面从我们写的代码入手分析它的工作原理.
- 简述
LeakCanary是通过检测一个对象的生命周期结束时的可达性来判断有没有存在内存的泄露的, 所以我们在在Activity或者Fragment或者其它什么对象的生命周期最后对它进行检测. - 安装
我们在项目的Application中使用了LeakCanary.install(this);, 我们顺藤摸瓜看看它是install的时候做了什么
public static RefWatcher install(Application application) {
//DisplayLeakService.class, 将来显示内存泄露的通知
//AndroidExcludedRefs.createAppDefaults().build()将已知的泄露列表传入, 将来在弹出泄露通知原时候会有一个exclude的标志
return install(application, DisplayLeakService.class, AndroidExcludedRefs.createAppDefaults().build());
}
//4.0之后的程序要把下面的拿出来写在Application中
public static RefWatcher install(Application application,
Class<? extends AbstractAnalysisResultService> listenerServiceClass,
ExcludedRefs excludedRefs) {
//判断是不是处理的进程, 是的话不处理, RefWatcher.DISABLED就是一个对象, 在检测的过程中直接检测通过
if (isInAnalyzerProcess(application)) {
return RefWatcher.DISABLED;
}
//确保可以使用DisplayLeakActivity,
enableDisplayLeakActivity(application);
//dump出文件后的监听, 这个是分析泄露的主力, 记住是ServiceHeapDumpListener, 会将它传给refWatcher作为成员引用b
HeapDump.Listener heapDumpListener = new ServiceHeapDumpListener(application, listenerServiceClass);
//!!!!!这里构造了最重要的对象, refWatcher!!, 构造过程我们后面再看
RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs);
//真去写监听
ActivityRefWatcher.installOnIcsPlus(application, refWatcher);
return refWatcher;
}
在ActivityRefWatcher中, 判断了版本, 对版本使用了application.registerActivityLifecycleCallbacks(lifecycleCallbacks);将RefWatchaer设置到Activity的生命周期方法中.
public static void installOnIcsPlus(Application application, RefWatcher refWatcher) {
if (SDK_INT < ICE_CREAM_SANDWICH) {
// If you need to support Android < ICS, override onDestroy() in your base activity.
return;
}
ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);
activityRefWatcher.watchActivities();
}
public void watchActivities() {
// Make sure you don't get installed twice.
stopWatchingActivities();
application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
}
public void stopWatchingActivities() {
application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks);
}
在lifecycleCallbacks就是Application.ActivityLifecycleCallbacks, 其中重写了
@Override
public void onActivityDestroyed(Activity activity) {
ActivityRefWatcher.this.onActivityDestroyed(activity);
}
最后在Activity结束时调用到ActivityRefWatcher中的onActivityDestroyed()方法,
void onActivityDestroyed(Activity activity) {
refWatcher.watch(activity);
}
以在Activity的onDestory()方法对Activity进行检测.
如果是Fragment也是同理, 在Fragment的onDestory()方法中对其进行检测.
- 检测过程
检测的过程就是在对象生命周期最后使用RefWatcher进行watch, 那我们进去看看它到底做了什么
//watch方法会直接使用下面这个方法
public void watch(Object watchedReference, String referenceName) {
checkNotNull(watchedReference, "watchedReference");
checkNotNull(referenceName, "referenceName");
//正在Debug的程序直接通过检测, 上面提到的RefWatcher.DISABLED就是使用的这个来跳过的
if (debuggerControl.isDebuggerAttached()) {
return;
}
final long watchStartNanoTime = System.nanoTime();
String key = UUID.randomUUID().toString();
retainedKeys.add(key);
//对象对应的UUID, 使用弱引用包起来
final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, queue);
watchExecutor.execute(new Runnable() {
@Override
public void run() {
//检测内存泄露的核心代码
ensureGone(reference, watchStartNanoTime);
}
});
}
此时看到核心代码使用一个线程池管理运行, 我们可以找到就是在上面提到的, 创建RefWatcher的时候对线程池进行初始化的.
public static RefWatcher androidWatcher(Context context, HeapDump.Listener heapDumpListener, ExcludedRefs excludedRefs) {
//管理dump出来的文件存放目录, 判断是否重复等
LeakDirectoryProvider leakDirectoryProvider = new DefaultLeakDirectoryProvider(context);
DebuggerControl debuggerControl = new AndroidDebuggerControl();
AndroidHeapDumper heapDumper = new AndroidHeapDumper(context, leakDirectoryProvider);
heapDumper.cleanup();
Resources resources = context.getResources();
//这个地方就是5秒钟
int watchDelayMillis = resources.getInteger(R.integer.leak_canary_watch_delay_millis);
AndroidWatchExecutor executor = new AndroidWatchExecutor(watchDelayMillis);
//executor是等5秒钟之后才真正运行交给它的Runnable. 也就是说我们在关掉Activity或者Fragment之后5秒内完成内存资源的释放, LeakCanary都认为不是内存泄露.
return new RefWatcher(executor, debuggerControl, GcTrigger.DEFAULT, heapDumper, heapDumpListener, excludedRefs);
}
我们再回来看LeakCanary是怎么检测内存泄露的
void ensureGone(KeyedWeakReference reference, long watchStartNanoTime) {
long gcStartNanoTime = System.nanoTime();
long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
//删除已经只有弱引用的对象, 就是去掉肯定不会泄露的对象
removeWeaklyReachableReferences();
//如果已经确定不泄露, 直接返回
if (gone(reference) || debuggerControl.isDebuggerAttached()) {
return;
}
//触发GC, 这里是触发, 而不是直接调用GC, 并不能保证立刻发生GC
gcTrigger.runGc();
removeWeaklyReachableReferences();
//如果还是有强引用, 可能存在泄露
if (!gone(reference)) {
long startDumpHeap = System.nanoTime();
long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
//创建堆内存镜像
File heapDumpFile = heapDumper.dumpHeap();
//创建失败
if (heapDumpFile == HeapDumper.NO_DUMP) {
// Could not dump the heap, abort.
return;
}
long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
//最后交给dump的监听进行分析泄露
heapdumpListener.analyze(
new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs, gcDurationMs, heapDumpDurationMs));
}
}
分析泄露的任务都交给了heapdumpListener,它实际上是一个ServiceHeapDumpListener的对象, 而heapdumpListener也是在构造refWatcher时创建出来的, 上面已有androidWatcher的代码, 在heapdumpListener的analyze中, 直接使用了HeapAnalyzerService的静态方法进行分析, 这个静态方法直接启动自己的服务进行处理, HeapAnalyzerService又是个IntentService, 这种方式挺好看的.
public static void runAnalysis(Context context, HeapDump heapDump, Class<? extends AbstractAnalysisResultService> listenerServiceClass) {
Intent intent = new Intent(context, HeapAnalyzerService.class);
intent.putExtra(LISTENER_CLASS_EXTRA, listenerServiceClass.getName());
intent.putExtra(HEAPDUMP_EXTRA, heapDump);
context.startService(intent);}
下面再看看HeapAnalyzerService处理分析的onHandleIntent方法:
@Override
protected void onHandleIntent(Intent intent) {
if (intent == null) {
CanaryLog.d("HeapAnalyzerService received a null intent, ignoring.");
return;
}
String listenerClassName = intent.getStringExtra(LISTENER_CLASS_EXTRA);
HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAPDUMP_EXTRA);
HeapAnalyzer heapAnalyzer = new HeapAnalyzer(heapDump.excludedRefs);
//这里使用了HaHa对Dump出来的堆进行分析, 拿到处理结果
AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey);
//这里不能传Class, 只好把classname传过去了, 此时的class就是最开始intall时传进来的处理显示结果的Service: DisplayLeakService.class, 此时结果的数据已经存在于result中了
AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);
}
分析堆文件先不去管, 拿到结果后就到DisplayLeakService中弹通知展示, 基本上就是分析展示的流程了.
pendingIntent = DisplayLeakActivity.createPendingIntent(this, heapDump.referenceKey);
//.......
showNotification(this, contentTitle, contentText, pendingIntent);
afterDefaultHandling(heapDump, result, leakInfo);
最后再回来看看怎么分析堆文件的, 就是HeapAnayzer类, 好吧, 看不懂,,,有机会再看吧
