SwiftUI列表变更时保留滚动位置的实现问题

问题描述 #

我正在开发一个SwiftUI视图，需求如下：

• 展示包含若干Items的Sections列表；
• 顶部筛选栏可按不同条件过滤Items，部分筛选需触发API请求；
• 支持双向无限滚动/分页；
• 视图首次加载时自动滚动到指定Section；
• 列表顶部添加数据或筛选导致列表变更时，保留用户当前滚动位置。

当前小量数据变更时视图表现正常，但大量数据隐藏/显示或顶部添加数据时，滚动位置会大幅偏移。想请教：

1. LazyVStack或List是否提供相关控制能力？
2. 不熟悉UIKit，但了解到UIKit的Table/List可能有更多控制选项，是否需要转用？
3. 是否需要手动实现？比如用GeometryReader跟踪可见Section，再调用scrollTo配合DispatchQueue延迟执行？但这种方案在网络请求耗时较长时可能失效。

解决方案 #

一、SwiftUI原生组件的控制能力 #

1. List的原生优化

SwiftUI的List内置了基础的滚动位置维护逻辑，但大量数据变更时容易失效，核心优化点在于：

• 绑定稳定的唯一ID：给每个Section和Item绑定后端返回的唯一标识（而非数组索引），让SwiftUI的Diffing算法能精准识别元素的身份，减少滚动位置错乱。
• 结合ScrollViewReader主动控制：用ScrollViewReader包裹List，在数据变更完成后主动滚动到预存的位置。可以通过自定义PreferenceKey跟踪当前可见的Section/Item，在数据更新后触发scrollTo。注意不要在数据变更的同步代码里直接调用，需等待视图完成重绘（比如用DispatchQueue.main.async或withAnimation包裹）。

2. LazyVStack的使用注意

LazyVStack本身是懒加载容器，没有List的内置滚动维护能力，必须配合ScrollView和ScrollViewReader使用。同样需要绑定稳定ID，且完全依赖手动跟踪和控制滚动位置，适合对性能要求极高但滚动逻辑简单的场景。

二、UIKit桥接方案 #

如果SwiftUI原生方案无法满足稳定性要求，可以通过UIViewRepresentable桥接UIKit的UITableView，它的滚动控制更成熟：

• 可以直接读取和设置contentOffset，在数据变更前记录当前偏移量，更新后直接恢复；
• 顶部插入数据时，可计算新增内容的总高度，主动调整contentOffset.y（加上新增高度），保证用户视角不变；
• 虽然需要编写桥接代码，但对于大量数据变更、复杂滚动逻辑的场景，稳定性远高于SwiftUI原生组件。

三、手动实现的优化思路 #

如果坚持使用SwiftUI，手动跟踪方案可以做以下优化：

1. 用PreferenceKey跟踪可见元素：自定义PreferenceKey，在每个Section头部添加GeometryReader，将Section的ID和位置信息传递给父视图，实时记录当前最顶部的可见Section；
2. 预存滚动位置：在触发筛选或顶部添加数据前，先保存当前的可见Section ID；
3. 延迟滚动时机：不要依赖固定时长的DispatchQueue延迟，而是在数据更新完成后，用DispatchQueue.main.asyncAfter(deadline: .now() + 0.1)或RunLoop.main.perform等待视图重绘完成，再调用scrollTo；
4. 适配网络请求场景：在API请求发起前记录滚动位置，请求完成、数据更新后再触发滚动，不管请求耗时多久，都能在数据就绪后恢复位置。

关键注意事项 #

• 稳定ID是基础：所有Section和Item必须绑定唯一且不变的ID，否则SwiftUI会把元素判定为新创建，直接导致滚动位置错乱；
• 避免频繁调用scrollTo：多次触发会导致滚动抖动，只在数据完全更新后执行一次；
• 顶部添加数据时，SwiftUI默认会将滚动位置向下推，此时必须主动调用scrollTo恢复到之前的元素位置。

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