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万的数量级再不加判断，程序会因为内存不足而卡死。

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