在RecyclerView中为何嵌套类比内部类更适合实现ViewHolder？

一、内部类比嵌套类占用更多内存的核心原因 #

Kotlin里的嵌套类默认是静态关联的（等价于Java的static嵌套类），它的实例完全独立，不会持有外部类的任何引用，内存中仅存储自身的成员变量。
而内部类需要用inner关键字修饰，它的实例会隐式持有一个外部类实例的强引用——这个额外的引用就是内存占用更高的根源：不仅要存储自身数据，还要多占用一个引用的内存空间，同时GC回收时还要处理这个额外的引用链。

二、RecyclerView ViewHolder用内部类引发内存泄漏的具体机制 #

咱们拿实际场景拆解：

• 首先，RecyclerView的Adapter通常依附于Activity/Fragment，ViewHolder如果是Adapter的inner内部类，会自动持有Adapter的强引用，进而间接持有Activity/Fragment的引用。
• 其次，RecyclerView有一套多级缓存机制（一级缓存、二级缓存、回收站），当Activity/Fragment被销毁（比如屏幕旋转、用户退出页面），系统本应回收它的内存，但如果旧的ViewHolder还在缓存中，它持有的Adapter引用会“拖住”旧的Activity/Fragment实例，导致GC无法回收该实例，造成内存泄漏。
• 举个直观例子：用户打开列表页滑动加载多个ViewHolder后旋转屏幕，旧Activity被销毁重建，但旧ViewHolder仍在RecyclerView的缓存中，它关联的旧Activity会一直占用内存，直到缓存被彻底清空——频繁触发这种场景会持续占用内存，严重时会触发OOM。

三、是否必须用嵌套类替代内部类？ #

不是必须，但强烈推荐用嵌套类或独立类实现ViewHolder。如果确实想用内部类，得手动切断强引用链：比如用WeakReference包裹外部类的引用，或者在Adapter的onDetachedFromRecyclerView方法里清空所有可能的引用，但这种写法繁琐且容易出错，远不如直接用嵌套类省心。

四、内部类存在的意义是什么？ #

内部类的核心价值是可以直接访问外部类的非静态成员，当你需要让某个类和外部类逻辑高度绑定，且频繁调用外部类的属性、方法时，内部类能大幅简化代码：

• 比如自定义View里的内部触摸监听器，需要直接操作View的状态，用内部类就不用写繁琐的引用传递；
• 再比如一个购物车类的内部结算逻辑类，需要直接读取购物车的商品列表、价格数据，用内部类会更简洁。
  它的存在是为了处理那些“逻辑上属于外部类一部分，且依赖外部类实例”的场景，只是在RecyclerView这种有缓存机制的场景下，它的强引用特性会引发问题。

内容的提问来源于stack exchange，提问作者kite