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