RecyclerView.Adapter的StateRestorationPolicy工作原理及列表位置复位问题解决

核心问题成因 #

列表回滚到起始位置的现象，本质是Adapter状态恢复流程与异步数据填充的时序不匹配，和对StateRestorationPolicy的生效规则理解偏差直接相关。

你当前的实现流程是：

1. Activity重建时，在onCreate中初始化Adapter，此时传入Adapter的列表为空
2. 给Adapter设置StateRestorationPolicy.PREVENT_WHEN_EMPTY策略
3. 调用connectToDatabase异步拉取数据，填充列表
4. 等异步数据返回时，系统已经完成了RecyclerView的状态恢复流程

常见踩坑点 #

• 对StateRestorationPolicy.PREVENT_WHEN_EMPTY的行为存在认知偏差：

StateRestorationPolicy.PREVENT_WHEN_EMPTY的实际运行逻辑：在RecyclerView尝试从保存的实例状态中恢复信息时，如果检测到当前Adapter的itemCount为0，会暂时存储待恢复的状态对象，不会直接丢弃；等Adapter后续第一次完成非空数据的提交、并触发对应数据变更回调时，再自动应用之前暂存的状态，把列表恢复到之前的滚动位置。
但这个自动触发的前提是，Adapter必须通过官方的数据更新接口发送“数据已就绪”的信号。如果直接修改Adapter内部持有的可变列表引用，没有触发对应的更新回调，哪怕列表已经填充了数据，系统也感知不到状态变化，自然不会执行状态恢复流程，最终就会出现列表回到顶部的问题。

• 代码存在拼写错误：代码里写的override fun onDistroy()是拼写失误，正确的系统生命周期回调方法是onDestroy，这个错误会导致写的数据库解绑逻辑根本不会被系统执行，不仅可能引发内存泄漏，还可能因为旧的数据库连接在Activity重建后重复触发数据更新，打乱状态恢复的时序。
• 没有使用正确的数据提交方式：直接将外部可变列表的引用传入Adapter构造方法，后续异步修改列表内容时，没有主动通过Adapter的公开接口通知数据变更，Adapter内部的状态感知完全失效。

正确实现步骤 #

• 第一时间修正拼写错误，将onDistroy改为onDestroy，保证数据库连接能在Activity销毁时正常解绑。
• 调整Adapter的实现逻辑：如果是使用普通的RecyclerView.Adapter，在异步填充完列表数据后，必须主动调用notifyDataSetChanged()告知Adapter数据已经更新；更推荐改用ListAdapter+DiffUtil的实现方式，通过submitList()方法提交不可变的列表快照，保证数据更新的信号能被系统正确捕获。
• 不需要手动干预滚动位置的恢复流程：只要Adapter在设置完PREVENT_WHEN_EMPTY策略后，第一次提交非空数据时能正确触发数据变更回调，系统就会自动把之前暂存的滚动位置、列表选中状态等信息恢复回去，不需要手动从savedInstanceState里读取位置再设置。
• 优化加载逻辑（可选但推荐）：结合ViewModel持有数据加载任务和已加载的列表数据，配置变更导致Activity重建时，直接从ViewModel中拿到已经加载完成的列表数据提交给Adapter，从根源上消除“Activity重建后需要等异步加载才出数据”的时序空窗。

内容的提问来源于stack exchange，提问作者Sourav Kannantha B