许多时候，我们的界面上会呈现大量的数据，如包含数千条记录的表格或包含数百张照片的相册。由于呈现UI是一件开销比较大的动作，一次性呈现数百张照片就目前的电脑性能来说是需要占用大量内存和时间的。因此需要对其进行优化。以前采用的方案大多数是翻页，翻页在某种程度上造成用户浏览的中断，因此现在往往采用一种新的方案——UI虚拟化。
UI虚拟化的原理是：但是由于显示器和人眼的限制，用户往往只会同时看到其中的数十条数据，因此只要在界面上渲染用户所看到的那些数据即可，对于用户呈现的界面仍然是一样的。微软的MSDN文档UI虚拟化说明的比较详细，这里就不累述了。
关于UI虚拟化的实现，其核心则是VirtualPanel，在WPF中内置的VirtualPanel貌似只有VirtualizingStackPanel一个，不过这个也是最实用的，一般常用于表格之类的数据呈现。如果需要其它布局方式的Panel，则需要自己实现，MSDN Blog上有一系列文章介绍得比较详细：
- Implementing a VirtualizingPanel part I
- Implementing a VirtualizingPanel part II
- Implementing a VirtualizingPanel part III
- Implementing a VirtualizingPanel part IV
文章最后也附带了一个VirtualizingTilePanel，实现了一个类似WrapPanel的效果（它要求里面的元素大小是相等的）。用于照片浏览之类的持续还是比较方便的，不知道为什么M$官方没有带这个。原文的.Net版本比较老，是直接编译不过去的，需要自行修改一下。
实现自定义VirtualizingPanel并非很复杂，首先介绍介绍几个前置条件：
1. VirtualizingPanel是用于UI虚拟化的，它是用来做ItemsControl的ItemTemplate的，而不是像普通Panel那样直接控制Children。因此，它必须同ItemsControl及其子类（如DataGrid、ListBox）搭配使用，并继承自VirtualizingPanel。
2. VirtualizingPanel是需要和ScrollViewer一起使用的，没有ScrolViewer的话，所有控件都是可见的，谈不上虚拟化。需要注意的是，ItemsControl的默认Template没有ScrollViewer，在ItemsControl中使用VirtualizingPanel时，需要修改一下Template，加上ScrollViewer，并设置CanContentScroll="True"。
3. UI虚拟化是需要在不呈现所有的UI控件前提下知道当前视图下元素呈现效果的，如果所有的数据都转换了为控件的话，也就谈不上虚拟化了。也就是说，不能靠Measure和Arrange所有子元素来确定布局。
具体实现的时候一般有如下几个功能点：
- Panel需要实现IScrollInfo接口，这样才能手动控制滚动时候的界面虚拟化。关于IScrollInfo接口，我前面的文章中有一些介绍，可以参考一下。
- Panel需要能只根据数据感知整体的布局。常见的有三种方案：1. 在Panel中直接指定每个子元素所占据的空间大小，2. 拿第一个子元素所占据的大小来衡量其它子元素所占据的大小，3.数据中直接声明它所需要的大小
- Panel根据当前窗口的大小呈现元素（加载可见元素，删除不可见元素）。
例子就可以直接参考前面的那个，这里就不单独举例了。
数据虚拟化：
UI虚拟化可以解决渲染UI控件所需要较多的时间和内存的问题，但是还是有可以优化的空间，那就是所有的数据仍然都加载到了内存中了。我们仍然可以采用和UI虚拟化一样的优化方案：不加载所有数据到集合，只加载用户可见部分。数据虚拟化本身并不受WPF所支持，不过当我们的Panel实现IScrollInfo接口了之后，就可以精确感知滚动条了，实现数据虚拟化也不是难事。
一般来说，我们很少使用数据虚拟化，主要的原因是它大多数的时候只能减少很少一点内存占用，反而带来了较大的代码复杂度， 一般是认为得不偿失的。
不过，有的时候，我们的数据是来自于外部RPC访问，这个时候数据虚拟化就有意义了，考虑如下两个场景：
- 新闻客户端，数据来源是来自于远程的Rest服务，但是它的接口是分页获取的，只能每次获取50条，总共却可能有100页。
- 图片浏览器，图片不是来自于本地，而是来自于图片服务网站。
第一个例子就是比较典型的数据虚拟化的应用场景了，如果一开始就加载所有100页新闻就需要花费大量时间了。第二个例子则是部分数据虚拟化，图片信息无需虚拟化，但图片呈现需要虚拟化，只是在需要呈现的时候才从网络下载。