控件UI性能調優 -- SizeChanged不是萬能的

時間 2019-11-26

原文原文鏈接

簡介

咱們在以前的「UWP控件開發——用NuGet包裝本身的控件「一文中曾提到XAML的佈局系統和平時使用上的一些問題（重寫Measure/Arrange仍是使用SizeChanged？），這篇博文就來爲你們簡單地描述一下XAML佈局系統的行爲，而且概括幾個規則。固然真正的XAML佈局系統十分複雜，本文無心把狀況弄得太複雜，就從一個最簡單最直觀的例子入手，來爲你們提供一點理解XAML佈局的新思路。html

問題描述

假設咱們有一個Templated Control，其XAML描述以下：windows

<Style TargetType="local:CustomControl1">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="local:CustomControl1">
                <Border x:Name="OuterBorder"
                    BorderBrush="Yellow"
                    BorderThickness="20">
                    <Border x:Name="InnerBorder"
                                BorderThickness="20"
                                BorderBrush="Red" />
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

兩個Border嵌套，邊寬20。咱們的目的就是經過代碼來改變InnerBorder的大小。好比長寬都變成OuterBorder的一半大。app

首次嘗試

咱們很容易就寫出了這樣的代碼：ide

public sealed class CustomControl1 : Control
{
    public CustomControl1() {...}

    private Border _border;
    private Border _inner;
    protected override void OnApplyTemplate()
    {
        base.OnApplyTemplate();

        _border = GetTemplateChild("OuterBorder") as Border;
        _inner = GetTemplateChild("InnerBorder") as Border;
        if (_border != null && _inner != null)
        {
            _border.SizeChanged += (s, e) => {
                _inner.Width = _border.ActualWidth / 2;
                _inner.Height = _border.ActualHeight / 2;
            };
        }
    }
}

works perfectly。這一實現很好地達到了咱們的需求。（並且對於這樣的簡單的狀況設計器仍是可以正常處理的）工具

對SizeChanged的概述

可是這卻隱藏着問題。首先，SizeChanged事件是由一輪Measure/Arrange完成後觸發的。佈局

XAML的核心佈局流程，是從根元素即頁面開始，遞歸向下。第一次挨個調用Measure，提供能用的大小，並肯定每一個子項所但願的空間大小；再來一次挨個調用Arrange，提供能用大小，按實際狀況給子項分配空間（不必定能知足它們的須要）和肯定位置。本例的過程當中就涉及到OuterBorder和InnerBorder，它們以此能根據Border類佈局規則肯定本身的大小，即刨去BorderThickness。性能

這以後，OuterBorder和InnerBorder的實際大小就肯定了。若是和上次佈局的結果不同，OuterBorder就會觸發SizeChanged事件（是Chang*ed*哦），改變InnerBorder的設定大小。由於設定大小變化了，會引起新一輪遞歸Measure和Arrange。這一次以後，OuterBorder的大小不變，InnerBorder的大小變成OuterBorder的一半。以後沒有事件和佈局再被觸發，你們相安無事。優化

但實際上，佈局進行了兩輪。若是Visual Tree很大的話，後果可想而知。ui

修改後的過程

那麼，根據咱們剛纔介紹的過程，從Measure出發，實現以下（去掉SizeChanged的事件綁定並override MeasureOvrride方法）：spa

public sealed class CustomControl1 : Control
{
    public CustomControl1() {...}

    private Border _border;
    private Border _inner;
    protected override void OnApplyTemplate()
    {
        base.OnApplyTemplate();

        _border = GetTemplateChild("Border") as Border;
        _inner = GetTemplateChild("InnerBorder") as Border;
    }

    protected override Size MeasureOverride(Size availableSize)
    {
        // availableSize就是OuterBorder的大小
        if (_inner != null)
        {
            _inner.Width = availableSize.Width / 2;
            _inner.Height = availableSize.Height / 2;
        }

        return base.MeasureOverride(availableSize);
    }
}

設定大小後再進入真正的measure環節，一次性搞定佈局。緣由就在於咱們在佈局開始以前就搞定了Size信息，而不是在佈局結束後再把它辛辛苦苦計算出來的Size踩在地上並讓它重來一遍。在咱們設定的需求看來，甚至無需插手Arrange流程。

固然，這免不了地要本身計算Size，可能須要手動減去BorderThickness的大小，甚至還可能要自行調用一次Measure。複雜的具體狀況須要具體分析。

性能對比

經過調試工具，咱們來對比一下兩種方法的實際性能：

SizeChanged	MeasureOverride

在兩種實現下，分別大力地快速拖動窗口大小。。。

其中柱形圖是一段時間內UI線程的響應狀況，佔最大比重的橙色是佈局行爲。下面的扇形圖是選中差很少的時間段內，佈局消耗的佔比狀況。

可見經過提供Measure策略的方式，即便是這樣簡單的設定，性能提高也還看得出來。

若是咱們發揚奧卡姆剃刀的精神，不要本身寫這陌生的MeasureOverride，用Grid來作如何？

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="*"/>
        <ColumnDefinition Width="2*"/>
        <ColumnDefinition Width="*"/>
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
        <RowDefinition Height="*"/>
        <RowDefinition Height="2*"/>
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>
    <Border x:Name="Border"
            BorderBrush="Yellow"
            BorderThickness="20"
            Grid.RowSpan="3" Grid.ColumnSpan="3"/>
    <Border x:Name="InnerBorder"
            BorderThickness="20"
            BorderBrush="Red" 
            Grid.Column="1" Grid.Row="1"/>
</Grid>