ScrollViewer.CanContentScroll

对项目中的 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 的数量比较多的情况。