WinUI3中ItemsRepeater在ScrollViewer内的尺寸变化问题解析

问题现象

在WinUI3应用开发中，开发者经常会在ScrollViewer内使用ItemsRepeater控件来实现可滚动的内容列表。然而，当ItemsRepeater中的项目数量超过一定阈值，并且项目尺寸发生变化（如通过折叠操作改变项目可见性）时，会出现以下异常行为：

1. ScrollViewer的滚动条会出现抖动现象
2. 滚动到列表末尾变得困难甚至无法完成
3. ItemsRepeater的SizeChanged事件会频繁触发
4. 滚动条尺寸会不断变化

问题根源

这个问题的核心原因在于ItemsRepeater的虚拟化机制与StackLayout布局的组合使用。当使用虚拟化的StackLayout时，系统会根据当前已呈现(realized)的项目尺寸来推断ItemsRepeater的总尺寸。在滚动过程中，已呈现项目的平均尺寸会发生变化，导致ItemsRepeater的预估总尺寸也随之变化，进而引起滚动条位置的跳动。

具体来说，当项目被折叠或展开时，项目的尺寸发生了变化。由于虚拟化机制只维护了部分项目的视图，系统需要不断重新计算整个列表的预估尺寸，这就导致了SizeChanged事件的频繁触发和滚动条的不稳定行为。

解决方案

1. 增加缓存长度

最直接的解决方案是增加ItemsRepeater的HorizontalCacheLength属性值。这种方法通过增加缓存的元素数量，减少了虚拟化带来的尺寸计算不准确问题。当缓存长度足够大时，实际上相当于禁用了虚拟化功能，所有项目都会被呈现，系统可以准确计算总尺寸。

<ItemsRepeater HorizontalCacheLength="10" ... />

优点：实现简单，效果明显
缺点：可能带来性能开销，特别是当项目数量很大时

2. 使用非虚拟化布局

对于项目数量不多的情况，可以考虑使用NonVirtualizingStackLayout替代默认的StackLayout：

<Page.Resources>
    <NonVirtualizingStackLayout x:Name="NonVirtualizingLayout"/>
</Page.Resources>

<ItemsRepeater Layout="{StaticResource NonVirtualizingLayout}" ... />

这种方法完全避免了虚拟化带来的尺寸计算问题，但只适合项目数量有限的场景。

3. 动态修改数据源

更优雅的解决方案是在需要隐藏项目时，直接从数据源中移除该项目，而不是仅仅修改其可见性：

void ItemTapped(object sender, TappedRoutedEventArgs e)
{
    var item = sender as Border;
    var itemData = item.DataContext as string;
    m_Items.Remove(itemData);
}

这种方法保持了虚拟化的优势，同时避免了尺寸计算问题，是最推荐的解决方案。

最佳实践建议

1. 优先考虑修改数据源：当需要隐藏项目时，直接从数据集合中移除项目，而不是修改UI元素的可见性。

2. 合理使用缓存：如果必须使用可见性控制，适当增加缓存长度可以缓解问题，但要权衡性能影响。

3. 避免混合使用虚拟化和动态尺寸：虚拟化最适合项目尺寸固定的场景，如果项目尺寸变化较大，考虑使用非虚拟化布局或重新评估UI设计。

4. 监控SizeChanged事件：在开发过程中监控ItemsRepeater的SizeChanged事件，可以帮助及时发现潜在的尺寸计算问题。

总结

WinUI3中的ItemsRepeater控件在虚拟化场景下的尺寸计算机制是导致这个问题的根本原因。理解虚拟化布局的工作原理对于开发流畅的滚动列表至关重要。通过合理选择数据操作方式、适当配置缓存参数，或者根据场景选择合适的布局策略，可以有效解决ScrollViewer内ItemsRepeater的滚动异常问题，为用户提供更流畅的交互体验。