@pdog18
第一个，是没有问题的，Runnable 是 OnClickListener 的内部类，所以引用关系是 $Runnable -> $OnClickListener-> Activity，检查一下生成的类可以看到引用的是 TActivity$1 即 匿名的 OnClickListener 类。

确实如你所说，分析内存泄漏时，一般优先分析最短路径，textView 的内部通过 mContext 已经引用了 Activity。
此非最短路径，分析和解决问题时均需要考虑到，为了释放 activity 引用，这两个引用链均需要在合适的时机置空。（其实是在所有的情况下都不应该把 View 放置在全局引用）

1. 如#2 所说 『生命周期长的对象引用生命周期短的对象就会造成生命周期短的对象内存泄漏。』
如果 Thread 不需要 Activity，但因为 Runnalbe 是一个非静态内部类，会默认持有外部类的引用；非主观期望，就是泄露。
如果 Thread 需要 Activity，我就是启动一个空的 Activity，来执行，也不占用大量的资源，主观期望，就不是泄露了。

2. 循环依赖（持有环：TActivity->textView->$OnClickListener->TActivity ），GC 是能发现和处理循环依赖，依然可以进行回收；
如果你把 textView 对象传递给外部的对象，比如一个单例对象持有，就会导致整个环均无法被回收。

3. 没有点击的情况下，Thread 对象和 匿名的 Runnable 对象均未创建，当然没有泄露。
在此场景下，假设点击行为发生，持有链为 $Runnable -> $OnClickListener-> Activity。

需要注意：
类与对象的关系，针对第三种场景，就是类有依赖，但对象未创建。
我们讨论内存泄露时，考虑的是对象间的引用关系，对象间的引用关系是由类来表达的。


关于 #3
不是栈，是引用链，方法栈会导致引用关系，但不是一一对应。

方法完成后，Runnble 对象已经没有其他对象引用了，可以被回收，进而它所引用的 activity 等资源也可以被回收。

已经泄露的对象，可以通过切断持有关系来让 GC 回收。以 OnClickListener 为例，如果我在 onCreate 中把 textView 放到一个单例的对象中持有，那么这个 TActivity 就会有一条引用关系 Root-> Singleton->textView->$OnClickListener->activity，导致 TActivity 泄露。

如果是：
public final class Singleton {
private Singleton() {

}

public static final Singleton INSTANCE = new Singleton();

public View holder;
}

那么，下一次再次进入 TActivity 时，新的 textView 对象被赋予 holder 时，原持有的 textView 和 原 TActivity 可以被回收。

@linvaux 不是拉出去弹死？

关机闹钟而已，人类真会加戏

关键在于两个卡不可以同时走流量。

不试试 3.5 新出的 dark purple ？

@lnkn 不需要重复下载，我是重启一下，拉取到 null 对应的信息，直接就可以更新了，没有二次下载。

本来也是提示又下载一次。

@dxfree +1 还是摸鱼的日子好。期待