maoruibin/awesomearticles

:card_file_box: 收集看到的内容特别棒的技术文章并会配有一段个人短评

awesomearticles's Issues

Android 开发者必知必会的权限管理知识指向错了

《Android 开发者必知必会的权限管理知识》指向了《Android ListView 与 RecyclerView 对比浅析--缓存机制》

垃圾回收

• JAVA垃圾回收不会回收应用的物理资源，只回收堆内存对象所占用的内存

轻松搞定面试中的链表题目 链接已经失效

rt

主流 JAVA 虚拟机

主流 JAVA 虚拟机

• HotSpot VM
• J9 VM
• Zing VM

HotSpot

HotSpot VM是绝对的主流。Oracle JDK、 Sun JDK、OpenJDK的各种变种（例如IcedTea、Zulu），用的都是相同核心的HotSpot VM。

这里如果你对 JDK 和 VM 区分不是很清楚的话，移步到 JDK 与 JVM 以及 JRE 的关系 #2 。

J9

J9是IBM开发的一个高度模块化的JVM。
在许多平台上，IBM J9 VM都只能跟IBM产品一起使用。这不是技术限制，而是许可证限制。

Zing

Zing VM是一个从Sun HotSpot VM fork出来的一个高性能JVM，可以运行在Linux/x86-64平台上。Azul为它重新写了一套GC，也修改了VM内的许多实现细节，所以从我们自己的角度看，与其说它是HotSpot VM的一个变种，还不如把它看作“一个全新的JVM、只是凑巧与HotSpot VM很像”更合适。

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 工作的大致原理。

JDK 与 JVM 以及 JRE 的关系

JDK 与 JVM 以及 JRE 的关系

在说 JDK 与 JVM 的关系前，先说说 JDK 与 JRE 之间的关系。
JDK 是 Java 开发工具包，如果你要开发 Java 程序，总得使用 Java 提供的 API 进行开发吧，JDK 就是我们开发 Java 程序的工具。

JDK 包含 JRE。JRE 是 Java 程序的运行时环境，也就是说，他是运行 Java 程序的一个环境。

我们都知道，Java 字节码的运行需要在 JVM 中完成，所以 JRE 必定包含一个 JVM(Java 虚拟机)。