FbLitho的RecyclerCollectionComponent加载新Section时为何重复旧视图

问题定位步骤 #

• 检查Section key唯一性：Litho的Section树依赖key区分不同实例，若新旧GroupSection使用相同key，Diff逻辑会判定为同一实例，不会触发旧视图卸载。可开启SectionsDebugReporter打印当前Section树的key结构，确认是否存在重复。
• 检查Diff逻辑正确性：若自定义了Section的isSameItem/isSameContent回调，或数据模型的equals方法实现错误，会导致Diff计算判定内容无变化，不触发视图更新。可在回调中添加日志验证Diff结果是否符合预期。
• 检查旧Section生命周期状态：若旧Section的子组件存在异步渲染、延迟加载逻辑，Section切换后未完成的任务仍提交视图会导致残留。可在onDetached回调中添加日志，确认旧Section是否正常触发detach，异步任务是否被正确取消。
• 检查Recycler缓存配置：若开启了Recycler视图缓存、设置了过大的itemViewCacheSize，切换Section时未清理回收池，也可能出现旧视图复用错误。

解决方案 #

• 强制Section key唯一：创建新GroupSection时显式指定唯一key，示例：

  GroupSection.create(c)
    .key("home_section_${currentTabType}") // 按业务场景拼接唯一标识
    // 其余配置
    .build()
  

  确保新旧Section的key完全不同，强制Litho重构Section树。
• 修正Diff逻辑：自定义Diff时确保isSameItem比对数据唯一标识，isSameContent比对所有UI相关字段；使用默认Diff时确保数据模型正确重写equals和hashCode方法，覆盖所有触发更新的字段。
• 切换Section时清理Recycler缓存：加载新Section的同时清理回收池，示例：

  Recycler recycler = recyclerCollectionComponent.getRecycler();
  if (recycler != null) {
    recycler.clear();
    recycler.getRecycledViewPool().clear();
  }
  

• 完善生命周期管理：在自定义Section的onDetached回调中主动取消所有未完成的异步请求、延迟任务，避免旧任务更新已卸载的Section。
• 兜底方案：若以上方案无法快速定位问题，可给RecyclerCollectionComponent设置动态唯一key，强制销毁旧Recycler实例：

  RecyclerCollectionComponent.create(c)
    .key("recycler_${System.currentTimeMillis()}")
    // 其余配置
    .build()
  

  该方案会完全重建Recycler，彻底避免旧内容残留，仅会带来极小幅的性能损耗。

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