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