WPF性能改善---之化整为零(蜂窝的衍生应用)

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

在有的项目中，有这样的需求，由于显示器的显示区域是有限的，而软件却要展示一个远大于显示区域的一些元素，此时就要引入放大、缩小、拖动等UI控制技术，而在使用这些技术的同时，在后台有效的控制渲染元素的个数显得尤其重要。

假设这样的案例屏幕1366*768，软件全屏显示为1366×738，软件中显示地图用的区域为600×600，此时我们可以把这个600×600的区域定义为关注区域，后台程序在获取屏幕界面变更事件(如最大化、最小化、侧栏收缩\展开)后，重新计算这个600×600的四个顶点坐标值。当需渲染元素在这个区域内时再进行渲染，否则不处理。如下图所示，黑色区域为关注区域。

以下是后台判断的代码

private void Button_Click_1(object sender, RoutedEventArgs e) { Random RD = new Random(); Console.WriteLine(DateTime.Now.ToString("mm:ss.fff")); ; i < ; i++) { TextBlock tb = new TextBlock(); tb.Text = i.ToString(); Brush myBrush = new SolidColorBrush(Colors.White); tb.Foreground = myBrush; , ); , ); Canvas.SetLeft(tb, x); Canvas.SetTop(tb, y); && x < && y > && y < ) { CanvInVStack.Children.Add(tb); } } Console.WriteLine(DateTime.Now.ToString("mm:ss.fff")); }

经过测试，10万级别的元素显示，如果不加 if (x > 0 && x < 600 && y > 0 && y < 600)这句判断，所耗时间约为22秒，如果加了判断耗时为2秒。时间计算的方法是，按钮一点击之后会产生一个时间，当看到元素显示到界面后，点击按钮2产生一个时间，因为没有找到合适的渲染成功事件，只能采用手工计时，虽不是很精确但是足以证明两种方案的效率相差10倍左右。上面的程序是生产100万个元素，如果是10万个不加判断程序还可以勉强运行，如果提高到100万的数量级再不加判断，程序会因为内存不足而卡死。

在设计类似的软件时，一定要采用分而治之的方案，才能得到良好的性能。