AwesomeArticles

对 ContentProvider 的作用以及在 Android 中的地位描述很恰当，另外在使用说明也比较详细。个人平时使用 ContentProvider 还是做跨进程数据同步多一点，因为 SharePreference 在跨进程情景下不可靠，所以包装 ContentProvider 后会特别合适，具体的实现可以参看 tray。

深入理解Android之View的绘制流程

作者：absfree 时间：2016-11-07 来源：简书

Window PhoneWindow 概念描述的很清楚。

Android内存优化杂谈

作者：shwenzhang 时间：2016-12-15 来源：公众号

尽管是15年的文章了，但是涵盖的内容还是非常全面的，尤其是微信对待问题的态度，还有处理内存问题的方式都很值得学习。从文章中可以学到他们他们对问题追踪的一些实践经验。

Android 进程保活招式大全

作者：张兴华时间：2016-08-11 来源：公众号

如文章名字一样，一点都不标题档，文章很有条理。从进程优先级说起，然后讲了各种保活方式，更难能可贵的是对不同保活方式在不同 Android 版本上的表现也做了说明。

我打赌你一定没搞明白的Activity启动模式

作者：尹star 时间：2016-05-31 来源：简书

讲的很透彻，读完后你会对 Activity 的启动模式，任务栈有更深的了解。

一文读懂Android View事件分发机制

作者：Flyzend 时间：2017-05-22 来源：简书

文风诙谐，分析有理，喜欢这样的文章。

Android事件分发机制详解：史上最全面、最易懂

作者：Carson_Ho 时间：2016-01-06 来源：简书

图文并茂，非常有条理，了解事件分发，只此一篇文章即可，不用多找。另外作者的一些其他文章貌似也不错。

Handler异步通信机制全面解析

作者：Carson_Ho 时间：2016-04-30 来源：简书

Handler 的方方面面都说到了，描述很精准，深度好文。

Fragment完全解析三步曲

作者：YoKey 时间：2016-02-27 来源：简书

对 Fragment 中的各种 bug 做了解释,并提供了解决方案，良心作者。

网络

HTTP 协议入门

作者：阮一峰时间：2016-08-19 来源：个人博客

Http 协议很庞大，但是作者从历史发展谈起，从简单到复杂，循序渐进，作为对 Http 协议的入门了解，这篇文章非常不错。

前端

Flex 布局教程：语法篇

作者：阮一峰时间：2015-07-10 来源：个人博客

自己接触前端页面挺早，但是对前端的布局不感冒，跟客户端布局相比，总觉得前端布局比较麻烦，各种 CSS 属性，直到遇到了 Flex 布局，之前就看过阮老师的这篇文章，通俗易懂，非常不错。

后端

我所认为的RESTful API最佳实践

作者：ScienJus 时间：2016-04-03 来源：个人博客

作者应该是个后端工程师，文章列举了自己开发过程中总结出的 Restful API 最佳实践，很实用。

About

咕咚

你可以通过下面的方式联系到我，欢迎关注。

公众号 - 大侠咕咚

Android 内存泄漏检测工具 LeakCanary 原理分析

LeakCanary 在 Application 中安装完成后，它会注册对应用内所有 Activity 生命周期的监听，具体监听的原理在于 Application 的 registerActivityLifecycleCallbacks 方法，该方法可以对应用内所有 Activity 的生命周期做监听。追踪 LeakCanary 的 install 方法就可以找到具体的设置地方，最终发现对应的监听设置代码在 ActivityRefWatcher 类的 watchActivities 方法中，如下所示:

  public void watchActivities() {
    // Make sure you don't get installed twice.
    stopWatchingActivities();
    //注册 Activity 生命周期监听
    application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
  }

这里的 lifecycleCallbacks 是一个监听的简单实现，但是这个实现只对 Activity 的销毁回调做了监听处理，如下所示

  private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
      new Application.ActivityLifecycleCallbacks() {
        @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
        }

        @Override public void onActivityStarted(Activity activity) {
        }

        @Override public void onActivityResumed(Activity activity) {
        }

        @Override public void onActivityPaused(Activity activity) {
        }

        @Override public void onActivityStopped(Activity activity) {
        }

        @Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
        }

        @Override public void onActivityDestroyed(Activity activity) {
          ActivityRefWatcher.this.onActivityDestroyed(activity);
        }
      };

从上已经可以知道，LeakCanary 是如何无侵入的监听每一个 Acitivity 的死亡回调的，接着继续看 onActivityDestroyed 方法：

void onActivityDestroyed(Activity activity) {
    refWatcher.watch(activity);
}
public void watch(Object watchedReference) {
    watch(watchedReference, "");
}
public void watch(Object watchedReference, String referenceName) {
    if (this == DISABLED) {
      return;
    }
    checkNotNull(watchedReference, "watchedReference");
    checkNotNull(referenceName, "referenceName");
    final long watchStartNanoTime = System.nanoTime();
    String key = UUID.randomUUID().toString();
    retainedKeys.add(key);
    final KeyedWeakReference reference =
        new KeyedWeakReference(watchedReference, key, referenceName, queue);

    ensureGoneAsync(watchStartNanoTime, reference);
}

这时 ActivityRefWatcher 会把对应的 activity 实例关联包装为一个自定义的弱引用（KeyedWeakReference），但是这里在指定弱引用时，LeakCanary 同时还为这个弱引用指定了一个 ReferenceQuery 队列，具体精简代码如下所示

// 队列
ReferenceQueue queue = new ReferenceQueue<>();
// KeyedWeakReference 为 LeakCanary 自定义的软引用( 就是简单继承了 WeakReference )
// watchedReference 就是 Activity 
KeyedWeakReference reference = new KeyedWeakReference(watchedReference, queue);

这个队列很重要，它是 WeakReference 的第二个构造参数，可能平时我们都没有关心它，它用于存放一些将来要做可达性分析的对象。下面是 ReferenceQuery 的文档介绍

Reference queues, to which registered reference objects are appended by the garbage collector after the appropriate reachability changes are detected.

分析到这里，LeakCanary 的原理就很简单了，会在检测到 Activity 的 onDestory 时主动GC，触发WeakReference 被GC，同时检测 GC 前后，ReferenceQueue 是否包含被监听对象；如果不包含，则说明该对象没有被GC，一定存在到 GC Roots 的强引用链，也就是发生了泄漏。

接着 LeakCanary 会使用 Square 开源库 haha 来分析Android heap dump文件，并把最终结果通过通知的方式显示在通知栏。

这就是 LeakCanary 工作的大致原理。

maoruibin / awesomearticles Goto Github PK

awesomearticles's Introduction

AwesomeArticles

Dart

系列文章

Java

Android

网络

前端

后端

About

awesomearticles's People

Contributors

Stargazers

Watchers

Forkers

awesomearticles's Issues

JDK 与 JVM 以及 JRE 的关系

主流 JAVA 虚拟机

HotSpot

J9

Zing

Recommend Projects

Recommend Topics

Recommend Org