静态内部类不会持有外部类引用，因其字节码中无隐式的this$0字段，不依赖外部类实例；而非静态内部类会自动添加该字段，导致外部类无法被gc回收。
静态内部类为什么不会持有外部类引用
因为 static 修饰的内部类在字节码层面不隐式持有一个指向外部类实例的 this$0 字段，它和普通顶层类一样，只依赖显式传入的引用。而非静态内部类编译后会自动添加这个字段，导致只要它被长期持有（比如作为单例、回调、线程任务），外部 Activity 或 Fragment 就无法被 GC 回收。
哪些场景必须用静态内部类防泄漏
常见于需要脱离 Activity 生命周期独立运行的逻辑：
- Handler 的子类（尤其配合
Looper.getMainLooper()使用时） - AsyncTask 的子类（尽管已废弃，但存量代码仍多）
- Runnable 实现类被 post 到 Handler 或提交到线程池
- 作为单例的持有者（如网络请求回调容器、事件总线监听器）
例如：new Handler(Looper.getMainLooper()) { ... } 是非静态匿名内部类，会隐式引用当前 Activity；而写成 static class SafeHandler extends Handler { ... } 就安全得多——前提是它不通过参数或成员变量间接持有 Activity。
静态内部类里怎么安全访问外部类成员
不能直接访问外部类的非静态字段或方法。若真需交互，必须显式传入且控制生命周期：
- 用
WeakReference<activity></activity>包裹 Activity 引用，每次使用前调用get()并判空 - 避免在静态内部类中缓存 Context，除非是
getApplicationContext() - 不要把 View、Dialog、Adapter 等强绑定 UI 生命周期的对象传进去
- 如果只是读取配置或常量，优先提取为
public static final字段供静态类直接访问
典型错误写法：private static class LoaderTask implements Runnable { void doWork() { textView.setText("done"); } } —— textView 是外部 Activity 的成员，静态类无法直接访问，编译就报错；但若把它作为构造参数传入并保存为弱引用，才可控。
混淆和反射对静态内部类的影响
ProGuard/R8 默认不会剥离静态内部类，但要注意两点：
- 如果用反射获取
OuterClass$StaticInner.class，确保 keep 规则包含$符号，例如：-keep class com.example.OuterClass$StaticInner - 反射调用静态内部类的私有成员时，仍需
setAccessible(true)，和普通类无异；但别为了“方便”在静态类里加一堆 public static 方法暴露外部类状态——这等于绕过设计约束，反而制造隐式强引用
真正难处理的不是语法，而是人：当团队多人协作时，很容易在静态内部类里悄悄 new 一个 Activity 实例、或传入一个未包装的 Context。这种泄漏不会立刻 crash，但会在低内存设备上快速堆积，最终触发 GC_FOR_MALLOC 频繁发生甚至 OOM。
