一、背景
假使我们的应用程序是一个基于搜索类的应用，那么该应用程序必然会加载大量数据，实现的基本方法不用说大家也知道，使用ListBox或者ItemsControl绑定数据是最为简单易行的，当然加载数据的情况也主要分为两种，分页式呈现和无限延展式呈现，对于用户体验来说，就好像Windows Phone 7的Market Place里面寻找某个类型的程序一样，每次移动到数据底部便增加一部分的数据，这种用户体验是很友好的，而本篇文章也主要讨论无限延展式呈现加载数据的时候，系统的内存对于不同的控件不同设置的消耗程度，并提供几个简单例子进行说明，供大家相互探讨。
个人背景：
最近在公司为某搜索类应用增加功能时，发现了瓶颈问题，问题如下：搜索结果显示页面使用ItemsControl作为绑定数据的控件，外层套个ScrollViewer用于滚动使用，并且把滚动条的位置用于判断是否位于数据最底部进而自动加载新数据，但加载了十几页的数据后，程序自动退出，其实作为我这样初出茅庐的程序员而言，对于程序内部运作机制不是很了解，只能判断为可能内存达到了瓶颈，随后增加了两个TextBox，每隔一秒自动刷新查看内存的值，方法很简单：
1 privatevoid Updated(object sender, EventArgs e)
2 {
3 tbDebugCurrent.Text = Microsoft.Phone.Info.DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage").ToString();
4 tbDebugPeek.Text = Microsoft.Phone.Info.DeviceExtendedProperties.GetValue("ApplicationPeakMemoryUsage").ToString();
5 }
每增加数据一次，便发现内存逐渐上升，真机在7390的版本下，100M不到就可能直接退出，在7392的版本下，300M左右可能直接退出，仿真器的话也是300M左右，这里这些数据只是说明一个事实，随着数据的增加，内存不断上涨，乍看下，这是一个显而易见的问题，但是事实又是如何呢？
二、调查过程
我在程序中特地加入断点把UI和数据处理区分开来，以决定到底是UI部分的内存还是数据部分的内存，得到的结果当然是UI部分的内存是罪魁祸首。所以就产生出了一个问题。
第一个问题：生成的UI控件是否没有内部优化机制？
我找到的答案关键字是这样的：UI Virtualization，也就是UI虚拟化
简单的描述的话（引用查到的博客的原文，以ListBox为例）：“假设我有一个带滚动条的ListBox,绑定到ListBox上的数据有10000条，而ListBox的高度只能够显示100条数据,由于在silverlight3中ListBox支持(UI Virtualization)虚拟化，所以实际上ListBox只会创建100条ListItem,而不是实际绑定的10000条 ,如果将ListBox的UI虚拟化功能禁用掉，那么ListBox将会创建10000条ListItem，或者有100000条或更多，性能会怎样呢？因此，某种程度上讲,UI虚拟化是可以解决大数据集合性能的”。
这样又出现第二个问题：ListBox支持UI Virtualization，难道ItemsControl不支持UI Virtualization？
由此问题我做了一个小小的实验。
三、实验过程
新建一个项目，将屏幕分为左右两部分，左边用于查看ItemsControl，右边用于查看ListBox，最上方显示内存情况，最下方有三个按钮，分别为增加ItemsControl的Items的数量和ListBox的Items的数量以及一个清除按钮（用于清除UI占用内存）。文章最后提供实验源代码下载（源代码中已设定ItemsControl（resultList），未设定ListBox（resultList2）的高度）。
每个按钮按下后，每次增加100个如图的Button，观察内存情况。
四、实验结果
ItemsControl：
初始内存4M：当ItemsControl不设定高度的时候，内存随着每次点击增加25M左右，加载时间缓慢，因为外层嵌套ScrollViewer，可拖动。点击Clear按钮，内存大幅下降。
初始内存4M：当ItemsControl设定高度的时候，内存每次点击增加4M左右，第一次之后加载明显加快，因为高度被限制，貌似直接把显示内容的高度也限制了，导致数据无法拖动。点击Clear按钮，内存变化不大。
ListBox：
初始内存4M：当ListBox不设定高度的时候，内存随着每次点击增加34M左右，可拖动。点击Clear按钮，内存大幅下降。
初始内存4M：当ListBox设定高度的时候，内存每次点击增加1M左右，第一次之后加载明显加快，虽然高度限制，因为ListBox本身机制，依旧可以拖动，点击Clear按钮，内存变化不大。
五、实验结论
高度一定的情况下，内存每次增加的都是数据内存，而UI内存变化不大。高度不定的情况下，内存每次既增加数据内存又增加UI内存。（PS：感觉回到了中学学物理的样子。。。）
不过这个结论是有一定问题的，因为ListBox我没用所谓的模板数据来显示，而是直接用了ListBox的Items来增加控件数量，如果用DataTemplate的话，不设置高度也是可以虚拟化的。而ItemsConrol因为没在ControlTemplate里使用ScrollViewer，也导致了虚拟化需要设置高度。
个人观点：UI Virtualization的实现在Windows Phone 7中的控件表现来看，基于的是Height是否为固定值，即便你把控件放在Grid中，Grid本身限制高度，但是如果控件不限制的话，同样是不采用UI Virtualization的。但是如果大家刚才认真看了我提供的博客的原文，从Silverlight的版本调查来看，似乎又有一些不同，关于那个设置控件的VirtualizingStackPanel.VirtualizationMode值来选择是否启用UI Virtualization，我尝试下来依旧不给力。
六、总结
因为不同程序可以采用不同方法，但是目的都是一个，用户体验和程序稳定性，如果在UI数据加载上碰到诸如此类的问题的话，不妨换个控件，或者设置下高度，让UI Virtualization节省程序的内存以及加快加载速度吧。
七、疑问
使用指定高度的ItemsControl来滚动显示所有数据我还是不知道怎么实现，感觉好像高度定死了，数据内容也定死了，希望大家能给我一个建议，否则我只能使用ListBox来实现功能了。
还有部分就是性能问题，UI Virtualization是否会导致暴力拖拉显示加载过慢的情况。
