对项目中的 DataGird 进行测试时,发现只要数据稍微多一点,不管是进行 Sort 还是 Filter 操作都会变得很卡,在网上各种 Research 如何提高 Performance,什么将 VirtualizingStackPanel.IsVirtualizing="True" 呀,将 VirtualizingStackPanel.VirtualizationMode="Recycling" 呀等等都尝试过,但是还是没有一点效果,实在没办法了,只能从源头找了——将项目中使用的 Template 代码读一遍。没想到刚打开 Template 就找到问题了:在该 DataGrid 使用的 Template 中,将 ScrollViewer.CanContentScroll 设置为 False,设置为 False 意味着禁用 Vitalize 的效果,怪不得怎么设置的都不起作用的 。
在 WPF 中,利用 ScrollViewer 包裹 Content 后,当 Content 实际的高度/宽度大于设置的高度/宽度时,将会自动出现 ScrollBar,方便用户利用滚动条来查看更多的内容。所以 ItemsControl 簇(继承自 ItemsControl 的一系列控件,如 ListBox,ListView,DataGrid 等)都包含 ScrollViewer。WPF 为 ScrollViewer 提供两种滚动的方式:按物理单元滚动以及按逻辑单元滚动,非此即彼。而两种方式各有千秋:
按物理单元滚动 (ScrollViewer.CanContentScroll = false)
优点:所谓的物理单元,通俗点说就是像素。由于是按照像素进行滚动,所以在此模式下滚动会显的非常平滑。
缺点:也正是由于按照像素进行滚动,所以 ScrollViewer 需要确切地知道它包裹的 Content 的高度、宽度等具体数值。对 ItemesControl 簇来说,也就是要知道每一个 Item 的高度、宽度等数值,即每一个 Item 都会经历 Measure 和 Arrange 阶段,而这两个阶段都是在 UI 线程上进行的,所以当在 ScrollViewer 中的 Item 比较多时,就会导致 UI 变得很卡。
适用:Item 数量比较少的情况。
按逻辑单元滚动 (ScrollViewer.CanContentScroll = true)
优点:
1. 性能比较高,因为它只需要 Measure 和 Arrange 可见的 Item 而非所有的 Item。
2. 滚动的行为比较简单,只需要从一个 Item 滚动到另一个 Item,简单点说就是 index + 1 就可以了,该行为和每个 Item 实际高度没有关系。
缺点:
1. 只能从一个 Item 滚动到另一个 Item,而不会停留在一个 Item 的中间。
(如图所示,左边是按逻辑单元滚动的效果,右边是按物理单元滚动的效果。)
2. ScrollViewer 的 ExtentHeight、ScrollableHeight、ViewportHeight 和 VerticalOffset 属性的值代表的 Item 的数量而不是设备无关像素。也就是说如果每次处于可见状态的 Item 数量不一样(如果每个 Item 的 Height 不同,就有可能导致这个问题),滚动起来会看到明显的抖动。
适用:Item 的数量比较多的情况。