簡介

我們在之前的“UWP控件開發——用NuGet包裝自己的控件“一文中曾提到XAML的布局系統和平時使用上的一些問題（重寫Measure/Arrange還是使用SizeChanged？），這篇博文就來為大家簡單地描述一下XAML布局系統的行為，並且歸納幾個規則。當然真正的XAML布局系統十分復雜，本文無意把情況弄得太復雜，就從一個最簡單最直觀的例子入手，來為大家提供一點理解XAML布局的新思路。

問題描述

假設我們有一個Templated Control，其XAML描述如下：

<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的一半大。

首次嘗試

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

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很大的話，后果可想而知。

修改后的過程

那么，根據我們剛才介紹的過程，從Measure出發，實現如下（去掉SizeChanged的事件綁定並override MeasureOvrride方法）：

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>