1. 為什么XAML屬性不是單純的賦值依賴屬性體系的底層邏輯很多剛接觸WPF的朋友會把XAML當(dāng)作一種配置文件覺得Button Width100不過就是設(shè)置一個對象的屬性。但實際上WPF的屬性系統(tǒng)是圍繞DependencyProperty依賴屬性建立起來的它和傳統(tǒng)的CLR屬性有本質(zhì)的區(qū)別。如果你不理解這一層后面會遇到很多莫名其妙的問題——比如為什么設(shè)置了寬度卻不生效為什么在樣式里定義的屬性被本地值覆蓋為什么綁定能自動刷新這些事兒靠普通屬性根本做不到。1.1 從CLR屬性到依賴屬性先看一個最常見的屬性寫法。我們在后臺代碼里定義一個普通屬性是這樣private int _width; public int Width { get { return _width; } set { _width value; } }這就是CLR屬性本質(zhì)是字段加get/set方法存值、取值都很直接。但WPF里的Button、TextBox這些控件你會發(fā)現(xiàn)它們的屬性并不走這條路。比如Button.Width它是一個CLR屬性包裝器真正存值的是這樣一行注冊代碼public static readonly DependencyProperty WidthProperty DependencyProperty.Register(Width, typeof(double), typeof(FrameworkElement), new FrameworkPropertyMetadata(Double.NaN, FrameworkPropertyMetadataOptions.AffectsMeasure));這行注冊代碼說明了幾個關(guān)鍵點Width的真實值存在DependencyProperty內(nèi)部的值表中而不是某個字段里。調(diào)用button.Width 100時實際上執(zhí)行的是SetValue(WidthProperty, 100)。每個依賴屬性都有一個全局唯一的標(biāo)識就是WidthProperty這個靜態(tài)字段在注冊時會帶上屬性名、類型、所屬類以及元數(shù)據(jù)。CLR打包器只是個語法糖方便你用C#的點語法寫代碼。如果你在代碼里用反射去查看Width的值得繞一圈還是要回到GetValue。為什么WPF要搞這么一套復(fù)雜的設(shè)計核心原因有四個屬性繼承、數(shù)據(jù)綁定、樣式和動畫。普通屬性改了就是改了沒有變化通知依賴屬性則內(nèi)建了一套變更通知機(jī)制綁定和動畫都能訂閱它的變化。而且依賴屬性支持從多個來源取值再通過優(yōu)先級決定最終值普通屬性做不到。1.2 屬性優(yōu)先級一個值為什么能從上到下層層覆蓋這是屬性解析中非常容易被忽略、卻又極其關(guān)鍵的一塊。XAML里的屬性賦值看似只是一行最終渲染出來的值實際上是經(jīng)過一個復(fù)雜的優(yōu)先級排序得到的。WPF官方文檔給出的優(yōu)先級從高到低大致是這樣優(yōu)先級值來源示例1屬性強(qiáng)制回調(diào)Coerce通過CoerceValueCallback強(qiáng)制修正的值2Activity值動畫正在運(yùn)行的動畫值3本地值XAML里直接寫的Width100或者代碼SetValue4模板綁定ControlTemplate里的TemplateBinding5隱式樣式?jīng)]有x:Key的樣式6主題樣式系統(tǒng)主題里的默認(rèn)樣式7繼承值從父元素繼承的屬性如DataContext、FontSize8默認(rèn)值注冊屬性時給的元數(shù)據(jù)默認(rèn)值我見過不少人被這個優(yōu)先級坑過。舉個例子你在Style里給Button設(shè)置了Width80但界面顯示還是別的寬度。很可能就是在某個地方給按鈕直接設(shè)置了本地值而本地值的優(yōu)先級高于樣式樣式根本覆蓋不了本地值。反過來如果你想用動畫改寬度本地值也會被動畫壓住因為動畫的優(yōu)先級高于本地值。理解了這套優(yōu)先級排查屬性設(shè)置了卻不生效的問題會快很多。1.3 元數(shù)據(jù)屬性解析時的說明書依賴屬性注冊時那個FrameworkPropertyMetadata參數(shù)是屬性解析的重要依據(jù)它告訴WPF這個屬性在布局、綁定、繼承等各個環(huán)節(jié)該怎么處理。常見的幾個選項AffectsMeasure/AffectsArrange屬性變化時要重新測量和排列。比如寫Width時AffectsMeasure就很有必要否則你改了寬度界面不刷新。BindsTwoWayByDefault默認(rèn)雙向綁定。Text屬性默認(rèn)雙向是TextBox.Text注冊時設(shè)置了這項。Inherits允許從父元素繼承DataContext、FontSize、Foreground都有這個特性。DefaultValue屬性默認(rèn)值。注意這里的默認(rèn)值是依賴屬性的兜底值優(yōu)先級最低。這些元數(shù)據(jù)直接參與了XAML屬性解析的決策。比如你在XAML里寫了Button FontSize20 /解析器需要知道FontSize會不會影響布局、是不是繼承屬性這些信息都從元數(shù)據(jù)來。實話說大多數(shù)業(yè)務(wù)開發(fā)不需要自己注冊太多依賴屬性但如果做自定義控件、帶交互的自定義UserControl比如熱搜詞里提到的帶時分秒的日期選擇器依賴屬性的注冊和元數(shù)據(jù)設(shè)置是基本功不然你的控件在Style、Binding、Trigger里根本無法被正常使用。2. 從XAML到BAML屬性解析在編譯期與運(yùn)行期的完整路徑很多WPF開發(fā)者對XAML的理解停留在字符串是給XamlReader解析的這一層但實際的項目中XAML在編譯階段就已經(jīng)被轉(zhuǎn)化成了二進(jìn)制BAML格式。這個轉(zhuǎn)化過程對屬性解析影響巨大尤其是在分析性能問題或者手動加載動態(tài)XAML的時候。2.1 編譯期Markup Compiler做了什么當(dāng)你編譯一個WPF項目XAML文件會被MarkupCompiler編譯產(chǎn)出一份BAMLBinary Application Markup Language嵌入到程序集的資源中同時生成一個InitializeComponent方法。這個過程做了幾件事詞法分析Tokenize把XAML文本拆成元素、屬性、字符串等token。類型綁定Bind to Types查找每一個元素對應(yīng)的CLR類型比如Button要找到System.Windows.Controls.Button。屬性解析對每個屬性判斷是普通屬性、依賴屬性還是附加屬性并生成對應(yīng)的指令碼。序列化把對象樹存成BAML二進(jìn)制流。這里有個容易踩的坑XAML里使用的類型必須能被編譯期找到。如果你引用了第三方控件庫比如ReoGrid做表格沒有在xmlns里正確映射命名空間編譯期就會報錯Name cannot be found或者直接生成不了BAML。這個報錯其實比運(yùn)行期好解決因為編譯器通常會指認(rèn)哪個屬性找不到對應(yīng)的類型。2.2 運(yùn)行期BAML Reader如何還原對象樹窗口打開時InitializeComponent會調(diào)用Application.LoadComponent把BAML交給Baml2006Reader配合XamlObjectWriter逐步還原對象樹。這個還原過程和直接解析XAML文本很像但數(shù)據(jù)不是從字符串讀取而是從字節(jié)流中解碼。每一步會讀取元素指令創(chuàng)建對象實例。讀取屬性指令對屬性賦值。遇到嵌套元素進(jìn)入子對象處理。有意思的是在屬性賦值這一步BAML里存的信息比XAML字符串還豐富——它已經(jīng)把類型信息、屬性標(biāo)識這些都提前映射好了運(yùn)行期不需要再做一次字符串到類型的查找。這也是為什么InitializeComponent給人的感覺比XamlReader.Parse更快。2.3 運(yùn)行時動態(tài)解析XAMLXamlReader.Parse的場景與代價如果你的WPF應(yīng)用需要動態(tài)加載界面比如插件系統(tǒng)、從數(shù)據(jù)庫讀取模板就得在運(yùn)行期解析XAML字符串。XamlReader.Parse是最常用的入口它的內(nèi)部流程是字符串 →XamlXmlReader→XamlObjectWriter→ 最終對象樹。運(yùn)行時解析和BAML解析有一個重大區(qū)別編譯期有靜態(tài)類型信息兜底運(yùn)行期只能靠反射去查類型和屬性。這就會帶來幾個實際問題你寫的類型必須帶程序集限定名或者已經(jīng)注冊到Application的startup里。純XamlReader.Parse()默認(rèn)只能解析WPF自帶的類型。自定義控件如果沒有正確的xmlns映射運(yùn)行期直接拋ParserException。屬性值里如果用了{(lán)Binding}解析到Binding時它不會馬上去取數(shù)據(jù)源而是進(jìn)入延遲綁定階段這里如果DataContext沒準(zhǔn)備好界面不會立刻顯示值排查起來容易困惑。我一般建議能編譯期寫好的XAML就編譯期寫動態(tài)XAML除了插件、模板場景真的能不用就不用。性能是一方面調(diào)試復(fù)雜度是另一方面——它在運(yùn)行期報的錯堆棧往往不如編譯期直觀InnerException一堆嵌套要一層層剝開。3. 特性、屬性元素與內(nèi)容元素三種寫法的解析規(guī)則差異XAML里設(shè)置屬性有三種語法特性Attribute、屬性元素Property Element和內(nèi)容元素Content Element。它們是XAML語法樹的三種不同節(jié)點解析器對它們的處理路徑完全不同。搞懂這三者的區(qū)別在IDE里寫XAML時才能建立直覺否則經(jīng)常會寫上去沒反應(yīng)。3.1 Attribute語法這是最常見的寫法Button Width100 Content保存 ClickOnClick /。在解析時Width的值100只是一個字符串需要經(jīng)過特殊的轉(zhuǎn)換才能賦給屬性。轉(zhuǎn)換規(guī)則是解析器檢查屬性類型。Width是doubleContent是objectClick是事件委托。如果沒有標(biāo)記擴(kuò)展如{Binding}解析器會找一個TypeConverter來做字符串到目標(biāo)類型的轉(zhuǎn)換。double有DoubleConverterBrush有BrushConverter等等。對于事件比如ClickOnClick解析器會把字符串當(dāng)作方法名去查找代碼后臺類里對應(yīng)名字的方法然后創(chuàng)建RoutedEventHandler委托并掛接。所以Width100這句話其實要經(jīng)過字符串→TypeConverter→double這么一條路。如果你給屬性設(shè)置一個轉(zhuǎn)換器不認(rèn)識的字符串寫法比如Width100px運(yùn)行期就會報TypeConverter無法轉(zhuǎn)換的錯誤。TypeConverter的作用區(qū)域是設(shè)計時和運(yùn)行時都存在的它不光給XAML解析用PropertyGrid里顯示屬性時也會通過它做字符串和值的互轉(zhuǎn)。我調(diào)試XAML問題的時候第一刀往往就是開InnerException看有沒有包含Converter cannot convert from System.String這類關(guān)鍵詞。有這句話基本就是屬性類型轉(zhuǎn)換沒走通接下來去檢查字符串格式是不是符合預(yù)期。3.2 Property Element語法并不是所有屬性值都能用簡單的字符串轉(zhuǎn)換出來。比如Button的背景色漸變Button Button.Background LinearGradientBrush StartPoint0,0 EndPoint1,1 GradientStop ColorRed Offset0 / GradientStop ColorBlue Offset1 / /LinearGradientBrush /Button.Background /Button這種寫法的名字叫屬性元素語法它把屬性當(dāng)成元素來書寫嵌套在所屬對象的XML結(jié)構(gòu)里。解析器看到Button.Background這個節(jié)點處理方式是先把內(nèi)部的LinearGradientBrush對象完整創(chuàng)建出來再把這個對象賦給按鈕的Background屬性。這里有個細(xì)節(jié)屬性元素的解析順序和Attribute并不完全一致。XAML解析器按XML文檔順序逐一處理節(jié)點屬性元素本身是節(jié)點的子元素它內(nèi)部的對象構(gòu)建會優(yōu)先于屬性賦值完成。也就是說你不會在設(shè)置Background時發(fā)現(xiàn)畫筆對象還沒有創(chuàng)建好。這個順序關(guān)系在寫復(fù)雜模板的時候很重要尤其是依賴其他屬性值的場景。Grid.Row、Canvas.Left這類附加屬性也是通過屬性元素寫法的思路來解析的只不過它們賦值的目標(biāo)是父容器網(wǎng)格的Grid而不是元素自身。所以Grid.Row1實際上是調(diào)用了Grid.SetRow(child, 1)在解析器內(nèi)部是有專門指令的。了解了這一點你就會知道Grid.Row為什么在類型上屬于Grid類而不是按鈕類——它是掛到宿主容器類型上的。3.3 Content Property為什么內(nèi)容可以直接寫再來看這個Button保存/Button按鈕的內(nèi)容沒有寫Content屬性卻能直接作為子內(nèi)容寫在標(biāo)簽里。這是ContentPropertyAttribute在起作用某個類可以標(biāo)注一個屬性為內(nèi)容屬性XAML解析器遇到子元素或文本時就會把它賦給這個內(nèi)容屬性而不需要顯式聲明。Button的內(nèi)容屬性是Content。TextBlock的內(nèi)容屬性是Text所以TextBlock你好/TextBlock會被解析成你好賦給Text。ComboBoxItem這類項目容器也有類似機(jī)制。這里有一個容易踩的坑一個類只能聲明一個內(nèi)容屬性。如果你做自定義控件想支持里面隨便寫內(nèi)容的直覺寫法就得自行標(biāo)注[ContentProperty(MyChild)]并且這個屬性得是object類型或者是能容納多個子元素的內(nèi)容集合類型。如果標(biāo)注成字符串類型那子元素就只能是一些簡單文本想放控件就報錯。這就解釋了為什么ContentControl的Content屬性是object類型而Panel的子元素集合屬性要單獨(dú)起名Children。4. 綁定與資源引用屬性值如何在運(yùn)行時被延遲填充XAML屬性解析里有一類特殊的延遲值它們的賦值不是在解析時完成而是要到運(yùn)行期甚至運(yùn)行后的某一個時刻才真正算出結(jié)果。這類延遲值的核心載體是標(biāo)記擴(kuò)展Markup Extension和資源引用機(jī)制。4.1 Binding標(biāo)記擴(kuò)展如何劫持屬性看這一行TextBox Text{Binding UserName} /{Binding UserName}就是標(biāo)記擴(kuò)展。解析器遇到以花括號開頭的屬性值時不會走TypeConverter轉(zhuǎn)換而是先構(gòu)造一個Binding對象調(diào)用它的ProvideValue方法返回一個表達(dá)式對象通常是BindingExpression把它交給屬性系統(tǒng)。這時候?qū)傩灾挡]有真正獲取到UserName而是建立了一個綁定監(jiān)聽。當(dāng)DataContext發(fā)生變化、UserName屬性值變化時依賴屬性系統(tǒng)會自動更新Text的值。這個機(jī)制也解釋了為什么綁定只能用于依賴屬性。TextBox.Text本身是依賴屬性有屬性變更通知機(jī)制綁定表達(dá)式才能把源和目標(biāo)串起來。普通CLR屬性沒有通知通道綁定結(jié)果沒法主動推送給它。我在一些代碼里看到有人試圖給一個普通類的普通屬性寫{Binding}那是不行的——除非那個屬性所在的對象本身做了INotifyPropertyChanged且屬性是支持綁定的目標(biāo)。順帶說一句熱搜詞里如何在RichTextBox.Document上使用Binding是很典型的困惑因為Document的FlowDocument并不是一個普通字符串直接綁就容易出問題。正確的做法是綁定Document屬性本身讓后臺把值轉(zhuǎn)成正確的FlowDocument對象或者通過TextRange之類的輔助類做一層轉(zhuǎn)換。這個問題表面上像綁定問題實質(zhì)還是類型轉(zhuǎn)換與屬性解析的問題FlowDocument沒有一個現(xiàn)成的字符串轉(zhuǎn)換器所以你要自己補(bǔ)齊這一步。4.2 StaticResource與DynamicResource兩種解析時機(jī)資源引用也屬于屬性解析的一部分但StaticResource和DynamicResource的解析時機(jī)完全不同。StaticResource編譯/加載期一次性解析。XAML解析器在構(gòu)建對象樹時會立即去資源字典里查找這個資源并把值賦給屬性。資源找不到當(dāng)場拋異常。DynamicResource解析器不會立刻取值而是先建立一個資源引用表達(dá)式把它掛進(jìn)屬性系統(tǒng)。之后不管資源字典內(nèi)容怎么變它都會跟著更新。所以DynamicResource能響應(yīng)運(yùn)行期資源替換代價是性能略低但靈活性更好。解析資源時的查找順序大概是當(dāng)前元素自己的資源字典 → 向上遍歷父元素資源字典 →Application.Resources→ 系統(tǒng)主題資源。這個順序很重要它決定了你定義了一個同名資源會不會被覆蓋。排查為什么樣式?jīng)]生效時十有八九是資源查找順序問題元素自己在更深的層級定義了一個同名資源把上層全局的資源給頂?shù)袅恕?.3 前后端協(xié)作MVVM中的Command屬性解析MVVM模式下Command屬性的解析是綁定機(jī)制的延伸。Button Command{Binding SaveCommand} /這里的SaveCommand通常是DelegateCommandPrism的常用實現(xiàn)或者RelayCommand。綁定解析到SaveCommand在后臺拿到的其實是一個實現(xiàn)了ICommand接口的對象。XAML解析本身并不管接口不接口它只關(guān)心綁定的源路徑能不能找到這個屬性。真正觸發(fā)執(zhí)行的是按鈕在Click時由ButtonBase調(diào)用了Command屬性的Execute方法。這里很多新人會問為什么CommandParameter綁定時Command的CanExecute不觸發(fā)刷新答案是綁定解析時源屬性只有在實現(xiàn)INotifyPropertyChanged并且主動通知Command所在屬性變化時才刷新。DelegateCommand本身會觸發(fā)CanExecuteChanged事件但如果你在界面上根本拿不到Command的綁定源、或者DataContext沒設(shè)對整個Command解析鏈路就是從空開始。 MVVM的調(diào)試如果先確認(rèn)DataContext能砍掉一大半問題。另外一個小細(xì)節(jié)設(shè)計器里可能看不到綁定值。Visual Studio的XAML設(shè)計器和Blend一樣它在設(shè)計期找不到運(yùn)行時上下文所以顯示的是一個空值。這不代表解析有問題運(yùn)行時能看到值就說明綁定路徑是對的。還有人在XAML里用d:DataContext來給設(shè)計器指定設(shè)計期數(shù)據(jù)上下文那個解析器是設(shè)計器專用的它運(yùn)行在你的設(shè)計時環(huán)境跟運(yùn)行時解析是兩套邏輯。5. 屬性解析高頻踩坑現(xiàn)場與排查工具箱XAML屬性解析的報錯幾乎每個WPF開發(fā)者都見過。我把自己踩過和幫別人看過的坑梳理一下。5.1 最常見的XamlParseException先看幾個典型報錯Width property not found in type Button屬性名稱拼錯或者屬性確實不屬于這個類。這個看著簡單但有時候會因為自定義控件的派生層級搞錯某個屬性在基類里你在子類寫屬性名卻少了繼承關(guān)系。Cannot set content on a Button because it doesnt have a content property你給一個類型設(shè)置了子內(nèi)容但它沒有被標(biāo)注內(nèi)容屬性。MarkupExtension cannot provide a value for property標(biāo)記擴(kuò)展返回了不支持的類型或者Binding返回空。最常見的是綁定了null的DataContext解析本身成功取不到源值時表達(dá)式留在那里不出效果。TypeConverter cannot convert from stringAttribute語法中字符串無法轉(zhuǎn)成屬性類型。比如Widthheight這種錯誤。這些報錯其實是很好的入口。XamlParseException的InnerException通常藏了真正的原因它有可能是一個FileLoadException引用的程序集找不到、ArgumentException某個參數(shù)格式不對、甚至TargetInvocationException對象初始化時內(nèi)部拋了異常。排查第一步永遠(yuǎn)是剝洋蔥——把InnerException層層打開比直接搜報錯關(guān)鍵詞有效率得多。5.2 手動加載XAML時的注意事項如果你的場景確實需要走XamlReader.Parse動態(tài)加載資源有幾點經(jīng)驗始終用帶命名空間的完整XAML最好手動加xmlnshttp://schemas.microsoft.com/winfx/2006/xaml/presentation。自定義類型要帶程序集限定名或者先Application.LoadComponent注冊相關(guān)程序集。加載后如果涉及綁定記得設(shè)置DataContext否則一堆綁定看起來都沒值。注意x:Class在XamlReader.Parse里不要用——動態(tài)解析沒有代碼后臺配合寫了反而報錯。還需要留意I/O文本讀取和XML讀取的編碼問題。XAML文件通常用UTF-8如果你從數(shù)據(jù)庫或接口拿一段字符串注意編碼不一致會引入解析失敗。這種問題很小但卡起人來可以卡半天。5.3 幾個順手好用的調(diào)試工具排查XAML屬性解析問題除了肉眼盯代碼我常用這幾類工具PresentationTraceSources.TraceLevelHigh直接在XAML里標(biāo)在綁定的相關(guān)屬性上把綁定過程輸出到VS輸出窗口。適合查綁定路徑問題。Snoop / WPF Inspector運(yùn)行時查看可視化樹的屬性值——Width到底被哪個優(yōu)先級的值覆蓋了綁定的最終值是多少有沒有解析異常。這類工具對依賴屬性優(yōu)先級排查幾乎是必備的。Visual Studio的實時可視化樹與屬性面板運(yùn)行模式下找一個元素實時看它的所有依賴屬性值和Snoop功能重疊但用法更順手調(diào)試UWP和WPF都支持。WinDbg SOS極端場景遇到Layout周期循環(huán)、屬性強(qiáng)制循環(huán)之類的問題其實靠的是調(diào)試器看托管堆棧。不過這種場景不常碰普通開發(fā)有Snoop就夠用了。做一個快速對照現(xiàn)象可能原因首選排查工具屬性設(shè)置了但不生效依賴屬性優(yōu)先級被其他值覆蓋Snoop查看最終值來源綁定顯示空白DataContext未設(shè)置或路徑錯誤PresentationTraceSources樣式不生效資源查找順序問題或樣式被本地值覆蓋可視化樹 / 資源字典檢查動態(tài)加載XAML報錯類型映射缺失、命名空間不全I(xiàn)nnerException逐層排查最后說一個我自己的經(jīng)驗也是接待了無數(shù)同事問題后總結(jié)出來的遇到XAML屬性相關(guān)的問題別急著往代碼里加?xùn)|西先判斷它的報錯發(fā)生在哪一步——編譯期、運(yùn)行期解析、還是綁定執(zhí)行階段。把階段判斷對了再去查對應(yīng)的那部分文檔或工具基本都能快速定位。屬性解析這套東西說到底就是類型、轉(zhuǎn)換、優(yōu)先級、引用時機(jī)四個關(guān)鍵詞的排列組合懂了規(guī)則報錯就不是迷。