Android嵌套RecyclerView切换LayoutManager遇性能与崩溃问题求助

针对你遇到的三个核心问题，逐个给出可行的解决思路：

1. 多个展开状态下垂直滚动性能极差 #

嵌套RecyclerView本身会带来额外的布局测量与绘制开销，加上大量展开的Flexbox布局，性能问题会被放大，可通过以下方式优化：

• 禁用嵌套滚动：给所有水平RecyclerView设置recyclerView.setNestedScrollingEnabled(false)，让垂直RecyclerView全权处理滚动事件，避免嵌套滚动的手势冲突与额外计算。
• 优化ViewHolder复用：确保水平RecyclerView的Adapter使用DiffUtil进行局部数据更新，避免每次筛选变更都全量调用notifyDataSetChanged()；同时简化Chip的布局层级，减少不必要的嵌套ViewGroup。
• 提前计算展开高度：在切换到FlexboxLayoutManager前，预计算当前筛选类别下所有Chip展开后的总高度，给水平RecyclerView设置固定高度（而非wrap_content），避免RecyclerView在滚动时反复测量高度。
• 开启硬件加速：确保页面的硬件加速处于开启状态（默认开启），减少绘制耗时。

2. 共享RecycledViewPool导致ClassCastException崩溃 #

共享RecycledViewPool的核心问题是：折叠/展开状态下的LayoutManager（LinearLayoutManager/FlexboxLayoutManager）对ViewHolder的布局参数要求不同，复用过程中会出现类型转换错误。解决方式：

• 不要共享RecycledViewPool：给每个水平RecyclerView单独创建自己的RecycledViewPool，避免跨LayoutManager的ViewHolder复用冲突。
• 切换LayoutManager时清空池：如果一定要复用池，在切换LayoutManager前调用recyclerView.getRecycledViewPool().clear()，强制回收所有缓存的ViewHolder，再设置新的LayoutManager并刷新数据。

3. FlexboxLayoutManager截断高度过高的RecyclerView项 #

这个问题通常是FlexboxLayoutManager的测量逻辑未正确计算所有项的总高度导致的，可通过以下调整解决：

• 配置FlexboxLayoutManager的测量模式：创建FlexboxLayoutManager实例时，设置setMeasureAllChildren(true)，确保测量时考虑所有可见与不可见的子项高度。
• 确保RecyclerView高度为wrap_content：在水平RecyclerView的布局中，将高度设置为wrap_content，同时避免父布局给它设置固定高度或限制最大高度。
• 更新flexbox库版本：使用最新版的com.google.android.flexbox:flexbox库，旧版本存在测量bug，更新后可修复部分截断问题。
• 自定义Chip的布局参数：避免给Chip设置layout_height="match_parent"或不合理的flexGrow属性，确保Chip的高度是固定值或wrap_content。

整体架构优化建议 #

如果嵌套RecyclerView的性能问题始终无法满足需求，可考虑替换为单RecyclerView+多类型Item的架构：

• 将每个筛选类别拆分为「标题Item」和「Chip子Item」，通过Adapter的多类型支持实现展开/折叠（折叠时隐藏所有Chip子Item）。
• 给Chip子Item使用FlexboxLayoutManager（或自定义LayoutManager）实现换行效果，这样整个页面只有一个RecyclerView，彻底避免嵌套带来的性能开销。

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