做WPF開發(fā)的朋友應(yīng)該都有過這種經(jīng)歷一個(gè)簡單的Button點(diǎn)擊為什么在窗口根部也能收到通知在某個(gè)控件上掛的事件處理器為什么子元素觸發(fā)時(shí)也會(huì)跟著響應(yīng)DataGrid里那一堆按鈕、復(fù)選框的事件怎么一不小心就在上層炸開了鍋這些問題的答案全都指向同一個(gè)底層機(jī)制——路由事件?？梢哉f沒搞懂路由事件你對WPF事件體系的理解就始終隔著一層窗戶紙。這篇博文專門把WPF路由事件的傳播機(jī)制掰開揉碎講清楚。我會(huì)從最基礎(chǔ)的“它和普通.NET事件有什么區(qū)別”開始一路拆解三種路由策略冒泡、隧道、直達(dá)的完整路徑覆蓋事件參數(shù)里sender、Source、OriginalSource、Handled這幾個(gè)關(guān)鍵屬性的真實(shí)行為再結(jié)合MVVM開發(fā)中最常遇到的DataGrid選中刪除、按鈕命令查找、自定義控件事件設(shè)計(jì)這些實(shí)戰(zhàn)場景最后附上我自己調(diào)試路由事件時(shí)的排查經(jīng)驗(yàn)。這篇文章適合剛接觸WPF想系統(tǒng)理解事件系統(tǒng)的初學(xué)者也適合已經(jīng)寫過不少界面但總在處理事件時(shí)“憑感覺”的進(jìn)階開發(fā)者——看完你會(huì)明白事件處理不該靠猜路徑都是可視的、可推導(dǎo)的。1. 路由事件究竟在解決什么問題從一次數(shù)據(jù)刪改說起很多從WinForm轉(zhuǎn)過來的開發(fā)者初期對WPF路由事件最直觀的感受就是“亂”明明是點(diǎn)了一個(gè)小按鈕怎么整個(gè)窗口都能感覺到這件事發(fā)生。這種“亂”背后的設(shè)計(jì)意圖其實(shí)是用一套更靈活的事件分發(fā)機(jī)制解決傳統(tǒng)事件模型在復(fù)雜界面邏輯下的三大痛點(diǎn)。1.1 傳統(tǒng).NET事件模型的三個(gè)硬傷傳統(tǒng)的.NET事件模型很簡單事件源比如一個(gè)Button內(nèi)部持有一個(gè)委托列表觸發(fā)時(shí)逐個(gè)調(diào)用訂閱者的處理方法。這套模型在簡單的窗體應(yīng)用里完全夠用但在WPF這種面向樣式重寫、控件自由組合的UI框架里立刻暴露出三個(gè)問題。第一事件只能由聲明它的類處理。你的用戶控件里嵌了一個(gè)標(biāo)準(zhǔn)Button你想在用戶控件層面統(tǒng)一處理所有子按鈕的點(diǎn)擊——在傳統(tǒng)模型里做不到除非你手動(dòng)給每個(gè)Button逐一掛Click事件然后再轉(zhuǎn)發(fā)出去。第二事件處理無法“讓路”。你掛了一個(gè)事件它就會(huì)執(zhí)行沒有一種機(jī)制能讓某個(gè)處理器“吞掉”這次觸發(fā)、阻止后續(xù)處理器繼續(xù)響應(yīng)。第三事件的封裝方式不夠靈活。WPF里很多元素是通過樣式模板組合出來的比如一個(gè)Button的內(nèi)部可能由一個(gè)Border、一個(gè)ContentPresenter和一個(gè)TextBlock拼成如果你只能監(jiān)聽Button本體的Click那模板內(nèi)部結(jié)構(gòu)變化就可能讓你的事件代碼失效。路由事件就是為了解決這三件事而設(shè)計(jì)的它允許一個(gè)事件沿著界面元素樹傳播沿途任何一個(gè)元素都可以處理它也可以標(biāo)記“已處理”來中斷繼續(xù)傳播而且路由事件是附加在元素上的跟控件的具體類型沒有強(qiáng)綁定關(guān)系。1.2 路由事件到底“路由”到哪里去路由事件的核心是把“事件觸發(fā)”和“事件處理”解耦由一個(gè)中立的機(jī)制決定事件從哪個(gè)元素開始、沿什么路徑、經(jīng)過哪些元素。在WPF中這個(gè)路徑就是可視樹Visual Tree——也就是界面上真正參與渲染的元素層級(jí)。舉個(gè)例子你有一個(gè)窗口里面放了一個(gè)StackPanelStackPanel里放了一個(gè)ButtonButton內(nèi)部是文本“點(diǎn)擊我”。當(dāng)用戶按下這個(gè)按鈕時(shí)如果這個(gè)Click事件是冒泡路由事件那它實(shí)際發(fā)生的順序是這樣的Button事件源 → ContentPresenterButton模板內(nèi) → Button的整體邊界 → StackPanel → Grid假設(shè)外層有Grid → Window一路向上直到到達(dá)根元素或者某個(gè)元素把事件標(biāo)記為“已處理”。沿途每一個(gè)元素都有機(jī)會(huì)響應(yīng)這個(gè)事件而你只需要在這個(gè)鏈條上找任意一層掛上Click事件處理器就能收到通知。這就是路由兩個(gè)字的核心含義——事件沿著既定的路徑傳播而不是靜止地停留在觸發(fā)它的那個(gè)控件上。理解了這層基礎(chǔ)接下來的三種路由策略就是在這個(gè)大框架下的三種具體走向。2. 三種路由策略的完整路徑拆解WPF的路由事件按照傳播方向分為冒泡Bubbling、隧道Tunneling和直達(dá)Direct三種策略。看起來很簡單但很多bug恰恰是因?yàn)闆]有正確區(qū)分這三者的執(zhí)行順序和相互影響而出現(xiàn)的。2.1 冒泡路由從事件源向上走層級(jí)越深越先響應(yīng)冒泡路由是最常用、也最符合直覺的一種策略。事件的傳播方向是從觸發(fā)事件的元素開始逐級(jí)向上走到可視樹的根部。也就是說離事件源最近的元素最先收到通知然后是父級(jí)、祖父級(jí)以此類推。這種機(jī)制最大的價(jià)值是允許你在上層用“一個(gè)處理器”管理“多個(gè)來源相同的事件”。我早期做一個(gè)生產(chǎn)管理界面時(shí)一個(gè)窗口里有十幾個(gè)編輯控件需要統(tǒng)一做輸入合法性檢查。如果按照傳統(tǒng)事件模型我得給每個(gè)TextBox都掛一個(gè)TextChanged事件然后手動(dòng)匯總有了冒泡路由我只需要在窗口層掛一個(gè)TextChanged處理器事件從任何一個(gè)TextBox冒上來時(shí)都能統(tǒng)一處理處理完再?zèng)Q定是否放行。但這里有個(gè)容易被忽略的細(xì)節(jié)冒泡路徑經(jīng)過的每一個(gè)元素都會(huì)按照層級(jí)順序收到事件即使某些中間元素沒有掛處理器事件也不會(huì)停下腳步它會(huì)一路走到根。而且中途被標(biāo)記為Handled之后默認(rèn)情況下事件就不再繼續(xù)傳播了這點(diǎn)對后面的實(shí)戰(zhàn)影響非常大稍后我會(huì)專門展開。2.2 隧道路由從根向下走先攔截后處理隧道路由和冒泡正好相反事件從根元素開始逐級(jí)向下穿透到真正觸發(fā)事件的元素。WPF里幾乎所有隧道事件都以“Preview”前綴開頭比如PreviewMouseDown、PreviewKeyDown、PreviewTextInput。從命名就能看出來它的定位是“在事件正式處理之前先做一次偵察和攔截”。依然用剛才按鈕點(diǎn)擊的例子。當(dāng)你按下鼠標(biāo)時(shí)WPF實(shí)際上會(huì)先后觸發(fā)兩個(gè)配套的事件先走一遍隧道路徑的PreviewMouseDown從窗口一路向下到按鈕再走一遍冒泡路徑的MouseDown從按鈕一路向上到窗口。這兩個(gè)階段合起來就構(gòu)成了一次完整的輸入事件生命周期。隧道階段的意義在于“先手機(jī)會(huì)”。你可以在事件從窗口滲入到深層控件之前提前介入、判斷甚至取消這次操作。我的實(shí)際項(xiàng)目中有一個(gè)表格控件需要禁止某些行被選中。我就在窗口層掛一個(gè)PreviewMouseDown判斷點(diǎn)擊位置是否落在禁用行區(qū)域是就設(shè)置e.Handledtrue這樣事件還沒到達(dá)DataGrid的處理邏輯就被截停了。如果用冒泡事件DataGrid內(nèi)部的選中邏輯可能早就執(zhí)行完了再去補(bǔ)救就晚了。2.3 直達(dá)路由最接近傳統(tǒng)事件的一類直達(dá)路由最簡單事件只會(huì)在觸發(fā)它的元素上觸發(fā)一次不會(huì)向上或向下傳播。WPF里有一部分事件是直接路由的比如一些自定義控件內(nèi)部的事件、若干依賴屬性變更通知等。但這里要澄清一個(gè)常見誤解很多開發(fā)者以為“所有帶RoutedEvent標(biāo)識(shí)的都是多級(jí)路由事件”其實(shí)不然。直達(dá)路由事件雖然在注冊時(shí)會(huì)綁定一個(gè)RoutedEvent對象但它本質(zhì)上只是沿用了路由事件的基礎(chǔ)架構(gòu)傳播行為卻退化成了普通事件。它存在的意義更多在于統(tǒng)一事件注冊和封裝的API方便開發(fā)者用同一種方式掛載和移除處理器并不是為了傳播。了解這一點(diǎn)你在設(shè)計(jì)自定義控件的時(shí)候就會(huì)明白如果只是控件內(nèi)部自用的事件用直達(dá)路由即可只有需要外部感知、需要上拋下傳的事件才值得定義成冒泡或隧道事件。2.4 三種策略的執(zhí)行順序隧道先走冒泡后行直達(dá)夾中間現(xiàn)在把三種策略放到同一個(gè)場景里看。當(dāng)用戶在一個(gè)TextBox里按下鍵盤的“A”鍵時(shí)WPF內(nèi)部實(shí)際發(fā)生的事件序列是這樣的隧道階段PreviewKeyDown從Window一級(jí)級(jí)向下走到TextBox事件到達(dá)TextBox后按鍵事件正式開始冒泡階段KeyDown從TextBox一級(jí)級(jí)向上走到Window這個(gè)順序?qū)φ{(diào)試非常重要。我見過不少開發(fā)者在一個(gè)控件上同時(shí)掛了PreviewKeyDown和KeyDown卻不知道為什么Preview的處理器總是先執(zhí)行、而且設(shè)置了Handled之后KeyDown就再也不觸發(fā)了。這是因?yàn)樗淼朗录茸咄耆倘绻谀硞€(gè)環(huán)節(jié)把Handled標(biāo)記為true后續(xù)的冒泡配對事件就不會(huì)再觸發(fā)。說白了這是一套“先攔截、后處理”的協(xié)作機(jī)制。需要注意隧道事件和冒泡事件并非自帶信息同步如果隧道階段的PreviewKeyDown只是想“觀察”而沒實(shí)際處理千萬不要隨手把Handled置為true否則會(huì)莫名其妙攔截掉下游的所有響應(yīng)邏輯。3. 事件參數(shù)里那些容易混淆的核心屬性3.1 sender和e.Source一個(gè)代表掛載者一個(gè)代表觸發(fā)源路由事件的事件處理器簽名是統(tǒng)一的void handler(object sender, RoutedEventArgs e)。這里面的sender指的是“當(dāng)前掛載這個(gè)處理器并正在被回調(diào)的元素”而e.Source指的是“事件最初發(fā)生的那個(gè)元素”。兩者在事件傳播的中間節(jié)點(diǎn)上常常是不同的。舉個(gè)例子說明private void Button_Click(object sender, RoutedEventArgs e) { var senderElement sender as FrameworkElement; var sourceElement e.Source as FrameworkElement; }假設(shè)事件鏈條是Window → Grid → StackPanel → Button事件從Button冒泡上來。當(dāng)處理器被Window這個(gè)層級(jí)的控件接收時(shí)sender是Windowe.Source還是那個(gè)被點(diǎn)擊的Button而當(dāng)處理器掛在Button自身上時(shí)sender和e.Source才相等。我實(shí)際開發(fā)時(shí)的做法是所有只需要判斷“是誰觸發(fā)”的邏輯一律優(yōu)先讀e.Source不讀sender。因?yàn)閟ender的值會(huì)隨掛載位置變化容易造成邏輯誤判。比如一個(gè)窗口里多個(gè)按鈕共用一個(gè)Click事件處理邏輯處理函數(shù)里需要根據(jù)“到底點(diǎn)了哪個(gè)按鈕”來分支那必須用e.Source來識(shí)別而不是sender。不過這里也要注意e.Source的類型可能是按鈕模板內(nèi)部的具體元素比如被點(diǎn)擊的TextBlock而不是Button本身所以往往需要向上查找。3.2 OriginalSource連模板內(nèi)部都能看見的原始觸發(fā)元素e.OriginalSource是另一個(gè)經(jīng)常被忽視但很實(shí)用的屬性。它表示事件實(shí)際上是從哪個(gè)可視元素開始觸發(fā)的——注意是“可視元素”不是邏輯元素。對于帶有控件模板的元素OriginalSource會(huì)直接指向模板內(nèi)部那個(gè)被點(diǎn)擊的組件。舉個(gè)例子你點(diǎn)擊了一個(gè)Buttone.Source返回的是Button邏輯上的事件源但e.OriginalSource返回的是Button模板內(nèi)具體那個(gè)TextBlock或Border視覺上的原始觸點(diǎn)。這在做樣式定制、控件模板重寫的時(shí)候非常有用。比如我有一個(gè)自定義的列表項(xiàng)控件需要實(shí)現(xiàn)“點(diǎn)空白區(qū)域和點(diǎn)文字區(qū)域做出不同響應(yīng)”。只靠e.Source沒法區(qū)分因?yàn)槲叶贾傅氖峭粋€(gè)業(yè)務(wù)元素但讀取e.OriginalSource之后判斷它的類型是TextBlock還是Border就能做到精確分支。這是那種“不寫不知道一寫就真香”的細(xì)節(jié)。3.3 Handled的真正含義不是“事件結(jié)束”而是“不要繼續(xù)傳”Handled是RoutedEventArgs里對程序行為影響最大的一個(gè)布爾屬性也是最容易被誤用的一個(gè)。很多新手以為把Handled設(shè)為true就表示“事件處理完成”可以理直氣壯地結(jié)束流程。但它的真實(shí)語義是告訴路由機(jī)制這個(gè)事件已經(jīng)被處理過了后面的元素不需要再收到它。注意這個(gè)“告訴”默認(rèn)情況下是生效的但并不是絕對生效。在WPF中即使某個(gè)元素把事件標(biāo)記為Handled你依然可以通過AddHandler方法傳入handledEventsToo: true來強(qiáng)行監(jiān)聽已經(jīng)標(biāo)記為已處理的事件。這個(gè)機(jī)制在后期的調(diào)試和復(fù)雜業(yè)務(wù)場景里簡直就是救命稻草。我舉一個(gè)真實(shí)的坑我有一個(gè)窗口里面放了若干個(gè)自定義卡片每個(gè)卡片內(nèi)部有一個(gè)刪除按鈕。我原本在卡片外層監(jiān)聽了Button.Click想在點(diǎn)擊刪除按鈕的時(shí)候彈確認(rèn)框。但奇怪的是不管怎么點(diǎn)外層都沒反應(yīng)。我查了半天才發(fā)現(xiàn)卡片內(nèi)部的某個(gè)自定義控件在處理點(diǎn)擊時(shí)已經(jīng)把Handled設(shè)成了true事件根本沒有冒泡到外層。后來我改用AddHandler(Button.ClickEvent, handler, true)強(qiáng)行接收已經(jīng)被標(biāo)記的事件問題立刻解決。所以當(dāng)你發(fā)現(xiàn)某個(gè)事件“不傳播”的時(shí)候除了檢查層級(jí)結(jié)構(gòu)還要往控件內(nèi)部是否早早設(shè)置了Handled的方向排查。3.4 RoutedEvent屬性每個(gè)事件都有獨(dú)立身份的識(shí)別證每一個(gè)路由事件都會(huì)有一個(gè)類型為RoutedEvent的靜態(tài)屬性來標(biāo)識(shí)自己比如Button.ClickEvent、TextBox.TextChangedEvent。在AddHandler的時(shí)候第一個(gè)參數(shù)就是指定要監(jiān)聽哪一個(gè)路由事件。這個(gè)機(jī)制看似只是給事件起了一個(gè)靜態(tài)名字但它的深層用途是實(shí)現(xiàn)事件路由表和事件查找——WPF可以通過這棵事件注冊表很快地判斷某個(gè)路由事件在指定元素上是否有注冊的處理器。我見過有些代碼習(xí)慣直接在XAML里掛事件比如Button ClickButton_Click/。這在大多數(shù)情況下沒有問題但當(dāng)你需要?jiǎng)討B(tài)監(jiān)聽、動(dòng)態(tài)移除監(jiān)聽時(shí)繞不開RoutedEvent這個(gè)標(biāo)識(shí)對象。理解RoutedEvent的獨(dú)立身份之后你會(huì)更明白為什么同一個(gè)事件名在不同控件上可以重復(fù)使用以及為什么AddHandler能跨層級(jí)監(jiān)聽深層元素的事件。4. 實(shí)戰(zhàn)拆解DataGrid內(nèi)按鈕與復(fù)選框的路由事件情景理論講再多不落到具體界面都是空的。這一節(jié)我用開發(fā)中非常常見的“DataGrid里勾選復(fù)選框然后點(diǎn)擊外部按鈕做刪除”作為場景把路由事件在真實(shí)業(yè)務(wù)中的傳播行為完整走一遍。4.1 事件從單元格到DataGrid再到Window的完整路徑假設(shè)這樣一個(gè)典型界面Window x:ClassDemo.MainWindow Grid StackPanel DataGrid x:Namegrid AutoGenerateColumnsFalse DataGrid.Columns DataGridCheckBoxColumn Binding{Binding IsSelected} / DataGridTemplateColumn DataGridTemplateColumn.CellTemplate DataTemplate Button Content刪除 ClickDeleteButton_Click / /DataTemplate /DataGridTemplateColumn.CellTemplate /DataGridTemplateColumn /DataGrid.Columns /DataGrid Button Content批量刪除選中項(xiàng) ClickBatchDelete_Click / /StackPanel /Grid /Window當(dāng)用戶點(diǎn)擊數(shù)據(jù)行里的“刪除”按鈕時(shí)這個(gè)Button.Click會(huì)沿著可視樹一路冒泡。實(shí)際經(jīng)過的層級(jí)大致是Button → ContentPresenter模板容器 → DataGridCell → DataGridRow → DataGrid → StackPanel → Grid → Window。你在其中任何一層掛上Click事件都能收到通知。但這里有一個(gè)關(guān)鍵的陷阱DataGridRow、DataGridCell等自帶輸入處理的控件可能在冒泡過程中提前把事件標(biāo)記為Handled。比如DataGrid本身對單元格的點(diǎn)擊有一套內(nèi)部邏輯某些版本或某些樣式下它可能在處理完點(diǎn)擊后順手就把事件標(biāo)記為已處理導(dǎo)致你的外部按鈕點(diǎn)擊事件“消失”。遇到這種情況不要急著懷疑路由機(jī)制本身先檢查是不是中間控件吞掉了事件——用我前面提到的AddHandler重載就能解決。4.2 如何準(zhǔn)確區(qū)分“哪一行”的哪個(gè)按鈕被點(diǎn)擊在實(shí)際業(yè)務(wù)里你往往需要在點(diǎn)擊按鈕后知道它對應(yīng)的是哪一行數(shù)據(jù)。這里的關(guān)鍵技巧是從e.Source或sender向上查找DataGridRow然后通過DataGridRow的DataContext獲取業(yè)務(wù)對象。private void DeleteButton_Click(object sender, RoutedEventArgs e) { var btn sender as Button; if (btn null) return; var row FindParentDataGridRow(btn); if (row null) return; var data row.DataContext as YourModel; if (data ! null) { // 執(zhí)行刪除邏輯 } } private static T FindParentT(DependencyObject child) where T : DependencyObject { var parent VisualTreeHelper.GetParent(child); while (parent ! null) { if (parent is T typedParent) return typedParent; parent VisualTreeHelper.GetParent(parent); } return null; }這個(gè)“向上查找”的技巧在路由事件上下文里特別實(shí)用。因?yàn)槁酚墒录烊痪褪恰皬南峦献摺钡哪阍谏蠈咏邮帐录r(shí)完全可以沿著可視樹往回追溯真正的業(yè)務(wù)元素。很多新手不知道VisualTreeHelper還能這么用遇到“不知道怎么定位行”的問題就硬編碼行號(hào)結(jié)果界面一調(diào)整邏輯就崩。4.3 批量刪除里預(yù)覽隧道的攔截用法批量刪除按鈕不在DataGrid內(nèi)部而是在外層這時(shí)候事件路徑就更直接Button → StackPanel → Grid → Window。不過批量刪除真正需要注意的是“確定哪些行被選中”而不是依賴路由事件本身的傳播。那路由事件在這里還有用嗎有而且非常好用。一種常見的需求是在批量刪除之前用戶必須至少勾選一行。你可以用一個(gè)Preview類事件在操作發(fā)生前做攔截。比如在窗口根節(jié)點(diǎn)掛一個(gè)PreviewMouseDown在點(diǎn)擊批量刪除按鈕時(shí)先檢查選中數(shù)量數(shù)量為0就直接標(biāo)記Handled按鈕的Click事件根本不會(huì)觸發(fā)。這種做法的好處是把你自己的業(yè)務(wù)校驗(yàn)邏輯和按鈕的Click處理徹底分離校驗(yàn)不通過時(shí)下游連執(zhí)行的機(jī)會(huì)都沒有從源頭避免了“彈一堆提示還繼續(xù)執(zhí)行”的問題。4.4 與MVVM相結(jié)合時(shí)的坑代碼后置事件和命令如何共存在MVVM模式下很多人恨不得把所有邏輯都移到ViewModel里避開代碼后置事件。但路由事件和命令并不沖突反而可以通過Command機(jī)制自然融合。WPF的ButtonBase.Click會(huì)在命令系統(tǒng)中觸發(fā)查找從觸發(fā)元素開始向上查找CommandBinding找到后執(zhí)行綁定命令。這意味著你可以在Window的資源或外層控件中定義一個(gè)CommandBinding將某條路由事件映射到某個(gè)ICommand。這樣即使是深層控件觸發(fā)的路由事件也能被統(tǒng)一映射到ViewModel的命令上代碼后置只保留極少量的交互粘合邏輯。我在實(shí)際項(xiàng)目中的習(xí)慣是需要與業(yè)務(wù)數(shù)據(jù)交互的操作一律走ICommand僅僅屬于界面行為的操作比如折疊某個(gè)面板、選中某個(gè)Tab就保留在代碼后置里用路由事件處理。強(qiáng)行把一切塞進(jìn)ViewModel只會(huì)讓你為“控件拿到手了怎么傳給VM”這種問題反復(fù)糾結(jié)反而拖慢開發(fā)速度。5. 自定義路由事件的注冊與控制5.1 什么場景值得自定義路由事件項(xiàng)目做到一定規(guī)模你就需要封裝自己的控件。封裝控件時(shí)如果只用普通的事件封裝外部使用方想要在控件外層統(tǒng)一接收內(nèi)部通知就會(huì)很別扭。自定義路由事件的意義在于讓控件的內(nèi)部事件可以冒泡或隧道到外層供外層容器統(tǒng)一處理。舉個(gè)例子我做過一個(gè)自定義的分頁控件內(nèi)部包含“上一頁”“下一頁”“頁碼按鈕”等多個(gè)按鈕。如果使用傳統(tǒng)事件外部每個(gè)按鈕都要單獨(dú)訂閱但用自定義路由事件我只需要定義一個(gè)PageChanged路由事件內(nèi)部按鈕點(diǎn)擊時(shí)統(tǒng)一觸發(fā)這個(gè)事件事件冒泡到使用控件的頁面上任何一層都能監(jiān)聽處理。這樣控件的使用者體驗(yàn)和標(biāo)準(zhǔn)WPF控件的用法完全一致。5.2 五個(gè)步驟定義一個(gè)冒泡路由事件定義一個(gè)自定義冒泡路由事件的基本模板如下public class MyPager : Control { // 1. 注冊路由事件 public static readonly RoutedEvent PageChangedEvent EventManager.RegisterRoutedEvent( PageChanged, RoutingStrategy.Bubble, typeof(RoutedEventHandler), typeof(MyPager)); // 2. 封裝為CLR事件 public event RoutedEventHandler PageChanged { add { AddHandler(PageChangedEvent, value); } remove { RemoveHandler(PageChangedEvent, value); } } // 3. 觸發(fā)方法 protected void OnPageChanged(int page) { var args new RoutedEventArgs(PageChangedEvent); RaiseEvent(args); } }注意幾個(gè)細(xì)節(jié)。第一注冊時(shí)RoutingStrategy.Bubble指定了傳播策略如果想做成隧道事件就傳RoutingStrategy.Tunnel。第二事件必須是public static readonly這是路由事件命名的約定WPF內(nèi)部也依賴這種靜態(tài)字段來查找事件。第三RaiseEvent是路由事件真正的觸發(fā)入口通過this.RaiseEvent(args)來啟動(dòng)整條傳播鏈。第四如果事件需要攜帶業(yè)務(wù)數(shù)據(jù)可以自定義RoutedEventArgs子類在構(gòu)造函數(shù)里傳入數(shù)據(jù)然后在處理器里讀取。5.3 自定義事件里的Handled如何處理注意一致性自定義事件有一個(gè)容易被忽視的問題事件的觸發(fā)者和使用者在Handled語義上要有默契。如果你的自定義事件本身就有明確的“只有最深層需要響應(yīng)、上層不得介入”的需求讓觸發(fā)方在RaiseEvent之前就把某些參數(shù)前置處理好而不是期望上層自覺不去設(shè)置Handled。因?yàn)橐坏┥蠈釉O(shè)置Handledtrue同一傳播鏈上更深層的事件處理器在默認(rèn)情況下不會(huì)再收到事件這會(huì)直接改變事件的行為契約。我自己的習(xí)慣是自定義路由事件一律遵循“誰觸發(fā)、誰負(fù)責(zé)上層擁有最終裁決權(quán)”的契約。底層控件觸發(fā)事件時(shí)不做任何攔截上層想要攔截就通過設(shè)置Handled來實(shí)現(xiàn)。上下之間的交互邏輯清晰后續(xù)維護(hù)才不會(huì)混亂。6. 附加事件讓非繼承體系的元素也能用上路由事件6.1 附加事件是兩個(gè)類之間的“協(xié)作”機(jī)制附加事件Attached Event是路由事件的一種特殊形態(tài)它由某一個(gè)靜態(tài)類注冊但可以掛載到任何DependencyObject上。最經(jīng)典的例子就是Button.Click本身——Click事件雖然是Button類注冊的但你可以在任何外層容器上直接監(jiān)聽子級(jí)按鈕的Click。這在XAML中的寫法就是StackPanel Button.ClickStackPanel_Click Button ContentA / Button ContentB / /StackPanel這里Button.Click就是一個(gè)附加事件的典型應(yīng)用Click由Button注冊但StackPanel也可以監(jiān)聽它。WPF在解析這個(gè)XAML時(shí)實(shí)際上是把事件處理器掛在StackPanel上當(dāng)子元素Button觸發(fā)Click時(shí)事件冒泡到StackPanelStackPanel上的處理器被調(diào)用。6.2 實(shí)現(xiàn)一個(gè)自定義附加事件實(shí)現(xiàn)附加事件的核心步驟和自定義路由事件很相似但注冊的類并不需要繼承UI元素。簡單示例如下public static class ListBehavior { public static readonly RoutedEvent ItemSelectedEvent EventManager.RegisterRoutedEvent( ItemSelected, RoutingStrategy.Bubble, typeof(RoutedEventHandler), typeof(ListBehavior)); public static void AddItemSelectedHandler(DependencyObject d, RoutedEventHandler handler) { ((UIElement)d).AddHandler(ItemSelectedEvent, handler); } public static void RemoveItemSelectedHandler(DependencyObject d, RoutedEventHandler handler) { ((UIElement)d).RemoveHandler(ItemSelectedEvent, handler); } }在XAML里就可以這樣使用StackPanel local:ListBehavior.ItemSelectedOnItemSelected /這種模式在做“全局交互”或“跨層級(jí)事件”時(shí)非常有用。比如我做過一個(gè)全局快捷鍵監(jiān)聽不是在每個(gè)窗口中硬編碼而是定義一個(gè)KeyBehavior附加事件在根元素上掛一次就能監(jiān)聽所有子控件的按鍵操作。這個(gè)思路在復(fù)雜項(xiàng)目里能減少大量重復(fù)代碼。6.3 附加事件在全局樣式和模板中的應(yīng)用附加事件還有一個(gè)很妙的用法在樣式中使用。你可以通過Style的EventSetter來給某類控件統(tǒng)一掛載事件而不需要逐個(gè)控件寫事件。比如Style TargetTypeButton EventSetter EventClick HandlerGlobalButton_Click / /Style這樣一來所有應(yīng)用了這個(gè)樣式的按鈕它們的Click事件都會(huì)自動(dòng)被GlobalButton_Click監(jiān)聽到。它和直接在XAML里寫Click的區(qū)別在于EventSetter讓事件掛載成為一種樣式行為可以被模板化、被條件化地應(yīng)用。這一點(diǎn)在做全局埋點(diǎn)、全局權(quán)限攔截、統(tǒng)一日志時(shí)特別方便。我在一個(gè)內(nèi)部工具項(xiàng)目里用EventSetter給所有按鈕統(tǒng)一掛了個(gè)點(diǎn)擊日志事件后續(xù)排查用戶操作路徑時(shí)非常省力而且不需要?jiǎng)尤魏螛I(yè)務(wù)按鈕的原有代碼。7. 路由事件與命令WPF的“意圖”傳播機(jī)制7.1 命令把“操作意圖”和“具體實(shí)現(xiàn)”拆開路由事件解決的是“事件能傳到哪”而WPF的命令系統(tǒng)解決的是“這個(gè)操作想干什么”。兩者經(jīng)常被放在一起討論因?yàn)樗鼈児蚕硗环N路由思想從觸發(fā)點(diǎn)沿著可視樹傳播沿途查找合適的目標(biāo)來處理請求。典型的命令流程是一個(gè)Button被點(diǎn)擊它先觸發(fā)Click路由事件然后命令系統(tǒng)介入從Button開始向上查找CommandBinding找到之后執(zhí)行綁定的ICommand同時(shí)通過CanExecute方法查詢當(dāng)前是否有權(quán)限執(zhí)行。這本質(zhì)上是把意圖刪除、保存、刷新從實(shí)現(xiàn)細(xì)節(jié)具體刪除哪一行、如何保存中解耦出來。7.2 CommandBinding如何利用路由查找到執(zhí)行者Window.CommandBindings CommandBinding Commandlocal:MyCommands.DeleteItem ExecutedDeleteItem_Executed / /Window.CommandBindings當(dāng)深層控件觸發(fā)刪除命令時(shí)命令系統(tǒng)沿著可視樹向上尋找CommandBinding找到后就調(diào)用Executed處理器。這個(gè)機(jī)制使得你在任何層級(jí)都可以觸發(fā)同一個(gè)命令而不需要關(guān)心命令由誰來處理。我實(shí)際項(xiàng)目中經(jīng)常用這種做法工具欄的刪除按鈕、右鍵菜單的刪除項(xiàng)、鍵盤快捷鍵Delete三處都綁定同一條DeleteItem命令所有處理邏輯集中在窗口層一個(gè)Executed方法里代碼維護(hù)成本瞬間降下來了。7.3 路由事件和命令的適配取舍命令雖然強(qiáng)大但并不是所有場景都適合用它。命令更適合“有明確業(yè)務(wù)意圖、需要支持禁用/啟用切換、可能需要被多個(gè)入口觸發(fā)”的操作。而純粹面向交互細(xì)節(jié)如“鼠標(biāo)進(jìn)入某個(gè)區(qū)域時(shí)改變顏色”的事件更適合用路由事件直接處理。把二者混用的判斷標(biāo)準(zhǔn)很簡單如果這個(gè)操作需要從ViewModel獲取數(shù)據(jù)、需要做權(quán)限判斷就做成命令如果只是界面自身的視覺或交互反饋就用路由事件。這樣劃分代碼不會(huì)過度設(shè)計(jì)也不容易繞彎子。8. 常見問題與排查技巧實(shí)錄寫路由事件相關(guān)代碼時(shí)踩過的坑總結(jié)起來無非幾類。我把它們集中列成速查表格方便你以后遇到問題時(shí)快速對照。現(xiàn)象根因解決方案事件在外層容器收不到中間某層控件把Handled設(shè)為了true用AddHandler(evt, handler, true)強(qiáng)行監(jiān)聽或檢查自定義控件的冒泡邏輯Preview事件設(shè)置Handled后普通事件也沒反應(yīng)隧道階段攔截后配對冒泡事件被取消確認(rèn)是否真的需要攔截?cái)r截范圍盡量精確不要一刀切e.Source的類型和預(yù)期不符e.Source指向的是事件源所在的模板內(nèi)部元素用VisualTreeHelper向上查找目標(biāo)控件類型或比較OriginalSource在Window上監(jiān)聽子控件的路由事件無效事件沒有從子控件冒泡到Window可能是直達(dá)路由事件確認(rèn)事件策略是Bubble查閱文檔或反射判斷RoutingStrategyDataGrid里的按鈕事件時(shí)有時(shí)無DataGrid內(nèi)部對鼠標(biāo)事件有預(yù)處理優(yōu)先對DataGridCell或DataGridRow本身的事件做處理需要監(jiān)聽Click時(shí)用AddHandler重載自定義控件觸發(fā)了事件但外層收不到事件沒有在正確的可視樹上觸發(fā)檢查事件源對象是否在可視樹內(nèi)部使用RaiseEvent而不是直接執(zhí)行處理器除了表格里的常見問題我在實(shí)際操作中還會(huì)用兩個(gè)技巧來加快排查速度。第一個(gè)技巧是寫一個(gè)事件日志輔助方法在調(diào)試時(shí)把它掛到某個(gè)元素上把事件的名稱、sender、Source、OriginalSource、Handled全部打印出來。這樣一眼就能看清事件是否在傳播、在哪一層被攔截。private void LogRoutedEvent(object sender, RoutedEventArgs e) { Debug.WriteLine( $Event{e.RoutedEvent.Name}, Sender{sender.GetType().Name}, $Source{e.Source?.GetType().Name}, OriginalSource{e.OriginalSource?.GetType().Name}, $Handled{e.Handled}); }第二個(gè)技巧是善用Snoop或Visual Studio的實(shí)時(shí)可視化樹工具。Snoop可以實(shí)時(shí)查看任意元素的RoutedEvent觸發(fā)列表以及每個(gè)事件是否被標(biāo)記為Handled。定位一些復(fù)雜的冒泡丟失問題時(shí)這個(gè)工具比逐行斷點(diǎn)高效得多。9. 聊一點(diǎn)實(shí)踐經(jīng)驗(yàn)路由事件設(shè)計(jì)的一些思路走到這里路由事件的技術(shù)骨架已經(jīng)完整了。最后分享幾個(gè)我多年用下來的設(shè)計(jì)原則幫你避開低質(zhì)量的代碼組織方式。不要因?yàn)橥祽卸岩粋€(gè)業(yè)務(wù)邏輯塞進(jìn)某個(gè)控件的路由事件處理器里。路由事件是UI層的通信機(jī)制不是業(yè)務(wù)層的總線。業(yè)務(wù)判斷和數(shù)據(jù)封裝應(yīng)該往ViewModel層放事件處理器只做“界面響應(yīng)”和“命令轉(zhuǎn)發(fā)”兩件事。否則當(dāng)你需要在一個(gè)單元測試?yán)矧?yàn)證業(yè)務(wù)邏輯時(shí)會(huì)因?yàn)槁酚墒录蕾嘦I環(huán)境而處處受阻。在處理深度嵌套的可視樹時(shí)要時(shí)刻記住你寫的處理器可能在很多元素的調(diào)用上下文中執(zhí)行。所以事件處理器里的邏輯越短越好越直白越好。一個(gè)比較通用的做法是在事件處理器里只做“識(shí)別目標(biāo)元素—取出數(shù)據(jù)上下文—觸發(fā)命令”這三步核心邏輯挪到想測試的ViewModel方法里。還有一點(diǎn)很實(shí)際的經(jīng)驗(yàn)當(dāng)你在XAML里定義一個(gè)事件處理器的名字時(shí)右鍵“轉(zhuǎn)到定義”的時(shí)候要能一秒定位到方法。這件事聽起來很基礎(chǔ)但在一個(gè)幾千行的MainWindow里事件處理器的命名如果亂七八糟排查問題的時(shí)候真的會(huì)頭大。我個(gè)人的規(guī)范是事件源控件名_事件名如DeleteButton_Click如果是批量邏輯統(tǒng)一處理則用業(yè)務(wù)意圖命名如OnItemDeleted并且在事件處理器頂部寫清楚這個(gè)處理器的掛載層級(jí)和觸發(fā)來源。路由事件的傳播機(jī)制不算難但它背后的“沿著可視樹傳播”“Handled是協(xié)作協(xié)議而非終止命令”“e.Source和sender要分清楚”這幾個(gè)核心觀念確實(shí)需要在實(shí)際工程里多踩幾腳才能真正內(nèi)化?？吹竭@里你已經(jīng)掌握了大部分關(guān)鍵點(diǎn)剩下的就是在自己項(xiàng)目里把每個(gè)事件“走一遍過程”感受一下它的路徑踩過幾次坑之后你一定會(huì)對WPF的這套事件機(jī)制建立起直覺。