簡(jiǎn)介這是一份面向C# WinForm開(kāi)發(fā)者的側(cè)邊欄導(dǎo)航控件資源適合需要在Windows窗體項(xiàng)目中快速集成左側(cè)導(dǎo)航菜單的開(kāi)發(fā)者?？丶⒖季W(wǎng)站導(dǎo)航界面風(fēng)格采用扁平化設(shè)計(jì)圖標(biāo)、位置、大小、文字顏色與樣式均可靈活調(diào)整并附帶Visual Studio 2017可直接運(yùn)行的示例程序同時(shí)兼容.NET Framework 2.0便于在舊項(xiàng)目中復(fù)用。壓縮包共37個(gè)文件主要包含C#源碼、資源文件、圖片圖標(biāo)、解決方案工程以及可執(zhí)行演示程序整體僅1.06MB內(nèi)容精煉且便于閱讀。目前已有7746人學(xué)習(xí)參考。由于實(shí)現(xiàn)并非樹(shù)形結(jié)構(gòu)作者也說(shuō)明了注意事項(xiàng)但控件仍適合作為自定義導(dǎo)航欄的實(shí)用范例。開(kāi)發(fā)者可從中學(xué)習(xí)導(dǎo)航條的自繪實(shí)現(xiàn)、鼠標(biāo)懸停與選中狀態(tài)處理、菜單項(xiàng)分組管理、顏色與字體動(dòng)態(tài)調(diào)整等關(guān)鍵細(xì)節(jié)并且通過(guò)公開(kāi)屬性可以控制菜單項(xiàng)高度、圖標(biāo)大小、展開(kāi)方向、背景漸變、邊框圓角等為二次開(kāi)發(fā)提供良好基礎(chǔ)。 需求方一句“左邊加個(gè)菜單欄、右邊放內(nèi)容”聽(tīng)起來(lái)就是個(gè)現(xiàn)成控件的事真上手才發(fā)現(xiàn)WinForm自帶的控件里根本沒(méi)有一個(gè)像樣的側(cè)邊導(dǎo)航。MenuStrip是頂部菜單TreeView能湊合但樣式老氣展開(kāi)箭頭在導(dǎo)航場(chǎng)景里總覺(jué)得不對(duì)勁。我在最近一個(gè)設(shè)備管理上位機(jī)項(xiàng)目里專(zhuān)門(mén)重寫(xiě)了左側(cè)導(dǎo)航欄把方案選型、核心實(shí)現(xiàn)到踩坑記錄都過(guò)一遍希望能給正在找C# WinForm側(cè)邊欄方案的朋友省點(diǎn)時(shí)間。這個(gè)方案適合需要在C# WinForm中實(shí)現(xiàn)左側(cè)導(dǎo)航欄、導(dǎo)航控件又不想引入DevExpress這類(lèi)重型第三方框架的開(kāi)發(fā)者。如果你只是做內(nèi)部工具或者項(xiàng)目對(duì)UI要求不算高但希望結(jié)構(gòu)清晰、能靈活擴(kuò)展下面的做法可以直接抄走。全文沒(méi)有花哨概念就是最樸實(shí)的控件組合加自繪代碼量也不大。1. 為什么WinForm應(yīng)用繞不開(kāi)側(cè)邊欄導(dǎo)航1.1 管理系統(tǒng)與上位機(jī)的天然信息架構(gòu)WinForm最常見(jiàn)的應(yīng)用場(chǎng)景就是兩類(lèi)一類(lèi)是企業(yè)管理類(lèi)的信息錄入查詢(xún)系統(tǒng)一類(lèi)是工控上位機(jī)、設(shè)備調(diào)試工具。這兩類(lèi)軟件有個(gè)共同特點(diǎn)功能模塊多且模塊之間往往是平級(jí)或淺層級(jí)的并列關(guān)系。頂部菜單欄一旦超過(guò)一屏就會(huì)折疊成“更多”用戶根本不知道里面還有功能TreeView放在左側(cè)又總讓人誤以為是文件目錄。側(cè)邊欄正好卡在中間縱向空間可以容納足夠多的一級(jí)菜單二級(jí)用展開(kāi)或下拉呈現(xiàn)用戶掃一眼就能看清整個(gè)系統(tǒng)能干什么。我在設(shè)備管理項(xiàng)目里最直觀的感受是把導(dǎo)航從頂部換到左側(cè)之后用戶找功能的操作路徑從“點(diǎn)開(kāi)更多看一眼再返回”變成“一路掃下去直接點(diǎn)”效率提升很明顯。而且對(duì)于信息密集型頁(yè)面左側(cè)導(dǎo)航欄固定不動(dòng)、右側(cè)內(nèi)容區(qū)滾動(dòng)切換的布局用戶的視覺(jué)錨點(diǎn)更強(qiáng)不容易迷路。這一點(diǎn)在客戶驗(yàn)收演示的時(shí)候特別加分——對(duì)方一眼就能看懂軟件結(jié)構(gòu)。1.2 看似簡(jiǎn)單的需求實(shí)際由六七個(gè)子問(wèn)題組成“加個(gè)左側(cè)導(dǎo)航”這句話背后隱藏著一堆細(xì)節(jié)菜單項(xiàng)如何組織數(shù)據(jù)、點(diǎn)擊后選中態(tài)怎么更新、右側(cè)內(nèi)容區(qū)怎么切換頁(yè)面、切頁(yè)時(shí)舊頁(yè)面要不要銷(xiāo)毀、折疊后圖標(biāo)能不能自解釋、筆記本低分辨率下會(huì)不會(huì)擠爆布局、菜單項(xiàng)過(guò)多時(shí)怎么滾動(dòng)。任何一個(gè)環(huán)節(jié)處理不好側(cè)邊欄都會(huì)變成“能看但不好用”的半成品。這也是為什么我不建議直接拖十幾個(gè)Button對(duì)齊排布——那樣做出來(lái)的東西改一個(gè)菜單項(xiàng)可能就要?jiǎng)诱麄€(gè)窗體的布局代碼。把導(dǎo)航獨(dú)立成一個(gè)控件把數(shù)據(jù)和繪制封裝起來(lái)后面所有改動(dòng)都只在控件內(nèi)部發(fā)生這才是值得寫(xiě)進(jìn)項(xiàng)目里的方案。我見(jiàn)過(guò)太多項(xiàng)目一開(kāi)始圖省事直接擺按鈕功能模塊一多就開(kāi)始改布局拉到崩潰最后推倒重來(lái)。2. 三條實(shí)現(xiàn)路線第三方庫(kù)、TreeView改造與自繪面板2.1 第三方UI庫(kù)能用但先掂量授權(quán)和體積C# WinForm側(cè)邊欄最常見(jiàn)的偷懶方案是上DevExpress或Telerik還有國(guó)內(nèi)開(kāi)發(fā)者常用的SunnyUI、HZHControls之類(lèi)的開(kāi)源庫(kù)。平心而論這些庫(kù)的側(cè)邊導(dǎo)航控件做得確實(shí)完整折疊、動(dòng)畫(huà)、皮膚、鼠標(biāo)懸停效果全都現(xiàn)成拖進(jìn)去就能用。但引入之前得先算幾筆賬。第一是授權(quán)費(fèi)用DevExpress的授權(quán)對(duì)個(gè)人開(kāi)發(fā)者并不便宜公司項(xiàng)目還得走采購(gòu)流程時(shí)間成本不小。第二是安裝包體積一個(gè)UI庫(kù)DLL動(dòng)輒幾十兆加上各種依賴(lài)做一個(gè)內(nèi)部小工具完全沒(méi)必要背這么重的行囊。第三是定制自由度庫(kù)提供的樣式一旦不滿足客戶審美改起來(lái)比自繪還費(fèi)勁因?yàn)槟阋パ芯克钠つw機(jī)制而不是直接畫(huà)兩筆。如果是個(gè)人練習(xí)或者開(kāi)源小項(xiàng)目用SunnyUI這類(lèi)開(kāi)源庫(kù)沒(méi)問(wèn)題但公司項(xiàng)目我真建議再想想。2.2 TreeView改造最快但上限太低還有人會(huì)想到用TreeView放左側(cè)當(dāng)導(dǎo)航畢竟它原生支持節(jié)點(diǎn)層級(jí)、展開(kāi)收起、選中事件代碼量最小。但用過(guò)幾次我就放棄了原因很實(shí)在TreeView的視覺(jué)風(fēng)格太“文件資源管理器”展示的縮進(jìn)線和展開(kāi)箭頭天生就給人一種“我在操作目錄”的暗示用在導(dǎo)航場(chǎng)景里總有點(diǎn)違和。高DPI下它的字體渲染也一般想給它加圖標(biāo)、調(diào)選中背景、做無(wú)邊框的扁平風(fēng)每一件事都需要走自定義繪制寫(xiě)起來(lái)并不比從零畫(huà)一個(gè)Panel省事。所以我的結(jié)論是TreeView適合做真正的樹(shù)形數(shù)據(jù)展示比如組織架構(gòu)、權(quán)限分配做主導(dǎo)航欄還是另起爐灶更干凈。如果只是為了快速出原型TreeView當(dāng)然沒(méi)問(wèn)題但想交付一個(gè)觀感正常的軟件你遲早會(huì)走到自繪這一步。2.3 自繪面板推薦方案最終我選了繼承Panel自繪理由就一條導(dǎo)航欄的UI復(fù)雜度其實(shí)很低無(wú)非是“一排矩形圖標(biāo)文字”底下的邏輯卻是事件驅(qū)動(dòng)和數(shù)據(jù)驅(qū)動(dòng)這兩部分分開(kāi)處理反而是最舒服的。自繪的好處是樣式完全可控畫(huà)成什么樣就是什么樣不用擔(dān)心組件庫(kù)的默認(rèn)樣式干擾沒(méi)有額外依賴(lài)編譯出來(lái)就是一個(gè)普通的UserControl渲染性能對(duì)于幾十個(gè)菜單項(xiàng)的規(guī)模來(lái)說(shuō)完全足夠。缺點(diǎn)是要自己處理鼠標(biāo)命中、懸停狀態(tài)、滾動(dòng)等基礎(chǔ)行為但這些在WinForm里都有成熟的套路代碼量并不大。下面的實(shí)現(xiàn)就是按這個(gè)思路來(lái)的整體代碼不到三百行維護(hù)起來(lái)比研究第三方庫(kù)的皮膚機(jī)制輕松得多。實(shí)現(xiàn)路線開(kāi)發(fā)速度視覺(jué)效果定制難度依賴(lài)與授權(quán)適用場(chǎng)景第三方UI庫(kù)快好高重需授權(quán)商業(yè)產(chǎn)品、UI要求高TreeView改造很快一般中無(wú)樹(shù)形結(jié)構(gòu)顯示、快速原型自繪Panel/UserControl中可控低無(wú)管理軟件、上位機(jī)、內(nèi)部工具3. 手寫(xiě)扁平化側(cè)邊欄控件的核心實(shí)現(xiàn)3.1 數(shù)據(jù)模型與控件框架先定義導(dǎo)航項(xiàng)的數(shù)據(jù)結(jié)構(gòu)。建議不要讓控件直接依賴(lài)你業(yè)務(wù)里的某個(gè)類(lèi)而是抽象出最小模型這樣控件才能在不同項(xiàng)目里復(fù)用public class NavMenuItem { public string Key { get; set; } // 唯一標(biāo)識(shí)用于頁(yè)面映射 public string Text { get; set; } // 顯示文字 public Image Icon { get; set; } // 圖標(biāo)可為空 public int Height { get; set; } 44; public bool Selected { get; set; } public object Tag { get; set; } // 掛載業(yè)務(wù)數(shù)據(jù) }控件本身繼承Panel設(shè)置Dock DockStyle.Left固定寬度默認(rèn)220BackColor按你的整體主題選深色或淺色。關(guān)鍵點(diǎn)是在構(gòu)造函數(shù)里把DoubleBuffered打開(kāi)后面閃爍問(wèn)題會(huì)少很多。如果你用UserControl作為基類(lèi)就通過(guò)SetStyle開(kāi)啟雙緩沖效果一樣。public NavSideBar() { DoubleBuffered true; Width 220; BackColor Color.FromArgb(45, 45, 48); ForeColor Color.FromArgb(220, 220, 220); Font new Font(微軟雅黑, 9F); }3.2 繪制與命中OnPaint解決一切視覺(jué)在OnPaint里依次畫(huà)背景、畫(huà)每個(gè)菜單項(xiàng)矩形、選中高亮、圖標(biāo)、文字。核心邏輯是遍歷Items集合每個(gè)項(xiàng)按順序畫(huà)一個(gè)矩形區(qū)域y坐標(biāo)累加這樣后續(xù)增刪菜單項(xiàng)都不用改繪制代碼。選中項(xiàng)我習(xí)慣畫(huà)一個(gè)和背景色對(duì)比明顯的色塊外加左側(cè)一條3像素的白色豎條作為強(qiáng)調(diào)比單純變色更有“焦點(diǎn)”感。protected override void OnPaint(PaintEventArgs e) { base.OnPaint(e); var g e.Graphics; g.SmoothingMode SmoothingMode.AntiAlias; int y _paddingTop; foreach (var item in _items) { var rect new Rectangle(0, y, Width, item.Height); if (item.Selected) { using (var brush new SolidBrush(Color.FromArgb(0, 120, 215))) { g.FillRectangle(brush, rect); } using (var accent new SolidBrush(Color.White)) { g.FillRectangle(accent, 0, y, 3, item.Height); } } else if (_hoverIndex _items.IndexOf(item)) { using (var brush new SolidBrush(Color.FromArgb(20, 255, 255, 255))) { g.FillRectangle(brush, rect); } } if (item.Icon ! null) { g.DrawImage(item.Icon, 12, y (item.Height - 20) / 2, 20, 20); } TextRenderer.DrawText(g, item.Text, Font, new Point(item.Icon null ? 16 : 42, y (item.Height - Font.Height) / 2), item.Selected ? Color.White : ForeColor); y item.Height; } }這里有個(gè)細(xì)節(jié)TextRenderer.DrawText比Graphics.DrawString的字體渲染更接近原生控件文字邊緣更清晰高DPI下也不容易發(fā)虛推薦一律用TextRenderer。懸停狀態(tài)我維護(hù)了一個(gè)_hoverIndex在OnMouseMove里更新并局部刷新。鼠標(biāo)點(diǎn)擊的命中邏輯不復(fù)雜在OnMouseClick里根據(jù)e.Y除以itemHeight算出索引更新選中項(xiàng)后觸發(fā)事件即可。注意命中前要做邊界判斷否則點(diǎn)擊控件底部空白區(qū)域會(huì)誤選中最后一個(gè)菜單項(xiàng)這是我實(shí)測(cè)踩過(guò)的坑protected override void OnMouseClick(MouseEventArgs e) { base.OnMouseClick(e); if (_items.Count 0) return; int index (e.Y - _paddingTop) / _items[0].Height; if (index 0 index _items.Count) { if (_selectedIndex ! index) { if (_selectedIndex 0) _items[_selectedIndex].Selected false; _selectedIndex index; _items[index].Selected true; Invalidate(); SelectionChanged?.Invoke(this, new NavSelectionChangedEventArgs(_items[index])); } } }3.3 對(duì)外接口屬性、事件、數(shù)據(jù)源為了讓控件能塞進(jìn)不同項(xiàng)目對(duì)外暴露三個(gè)東西就夠ItemsNavMenuItem的集合增刪后調(diào)用Invalidate刷新SelectedKey可讀可寫(xiě)的屬性外部也能通過(guò)它改變選中項(xiàng)SelectionChanged事件參數(shù)里帶上選中項(xiàng)的Key和Text。public ListNavMenuItem Items { get; set; } public string SelectedKey { get; set; } public event EventHandlerNavSelectionChangedEventArgs SelectionChanged; public void AddItem(NavMenuItem item) { _items.Add(item); Invalidate(); }這樣的接口設(shè)計(jì)讓導(dǎo)航控件和業(yè)務(wù)解耦主窗體只需要訂閱事件然后根據(jù)Key切換到對(duì)應(yīng)頁(yè)面完全不需要知道控件內(nèi)部怎么畫(huà)的。我習(xí)慣再提供一個(gè)SelectByKey(string key)方法方便程序初始化時(shí)默認(rèn)選中某個(gè)菜單比如啟動(dòng)后直接進(jìn)入“總覽”頁(yè)。4. 菜單與內(nèi)容區(qū)聯(lián)動(dòng)頁(yè)面切換不留臟數(shù)據(jù)4.1 內(nèi)容容器就用一個(gè)Panel做宿主主窗體布局上左側(cè)NavSideBar設(shè)置Dock DockStyle.Left右側(cè)用一個(gè)專(zhuān)門(mén)的Panel設(shè)置Dock DockStyle.Fill當(dāng)宿主容器。頁(yè)面切換本質(zhì)上就是往這個(gè)宿主容器里放UserControlprivate Panel _contentHost; private void ShowPage(UserControl page) { _contentHost.SuspendLayout(); _contentHost.Controls.Clear(); page.Dock DockStyle.Fill; _contentHost.Controls.Add(page); _contentHost.ResumeLayout(); }SuspendLayout/ResumeLayout成對(duì)出現(xiàn)很有必要多控件切換時(shí)能避免布局引擎反復(fù)計(jì)算界面不會(huì)閃。一開(kāi)始我圖省事直接Controls.Clear()和Controls.Add()欄目一多就明顯感覺(jué)切換時(shí)整個(gè)窗體在跳加上這兩行之后問(wèn)題消失。4.2 按需緩存頁(yè)面實(shí)例狀態(tài)保留的關(guān)鍵新手最容易犯的錯(cuò)是切頁(yè)時(shí)直接new一個(gè)新頁(yè)面懟進(jìn)去切走再切回來(lái)發(fā)現(xiàn)用戶剛填的表單數(shù)據(jù)全沒(méi)了。我的做法是準(zhǔn)備一個(gè)字典按菜單Key緩存頁(yè)面實(shí)例private readonly Dictionarystring, UserControl _pageCache new Dictionarystring, UserControl(); private UserControl GetOrCreatePage(string key) { if (_pageCache.TryGetValue(key, out var page)) return page; page CreatePage(key); _pageCache[key] page; return page; } private void OnSideBarSelectionChanged(object sender, NavSelectionChangedEventArgs e) { var page GetOrCreatePage(e.Key); ShowPage(page); }如果某個(gè)頁(yè)面不需要保留狀態(tài)比如純實(shí)時(shí)刷新的監(jiān)控視圖也可以不緩存每次重建具體按業(yè)務(wù)來(lái)。實(shí)際項(xiàng)目里我的經(jīng)驗(yàn)是80%的頁(yè)面都值得緩存重建的成本往往比多占一點(diǎn)內(nèi)存更高尤其是頁(yè)面構(gòu)造函數(shù)里有數(shù)據(jù)庫(kù)連接、配置加載這類(lèi)耗時(shí)操作時(shí)緩存能讓切換體驗(yàn)從“卡一下”變成“秒開(kāi)”。4.3 頁(yè)面切換時(shí)的生命周期處理當(dāng)頁(yè)面包含定時(shí)器、SerialPort、后臺(tái)線程時(shí)切頁(yè)后要注意釋放。最簡(jiǎn)單有效的做法是在ShowPage新頁(yè)面之前先讓舊頁(yè)面執(zhí)行一個(gè)停用邏輯。我習(xí)慣讓頁(yè)面基類(lèi)提供兩個(gè)虛方法public abstract class BasePage : UserControl { public virtual void OnPageActivated() { } public virtual void OnPageDeactivated() { } }切換時(shí)先調(diào)舊頁(yè)面的OnPageDeactivated再調(diào)新頁(yè)面的OnPageActivated。定時(shí)器、串口這類(lèi)資源在Deactivated里暫停在Activated里恢復(fù)既能保住現(xiàn)場(chǎng)又不至于讓后臺(tái)任務(wù)一直在跑。這個(gè)設(shè)計(jì)在上位機(jī)場(chǎng)景里救了不少次——設(shè)備數(shù)據(jù)采集頁(yè)面切走之后定時(shí)器繼續(xù)跑導(dǎo)致COM口一直被占著客戶那邊拔線都拔不掉加了生命周期管理之后才根治。5. 折疊、動(dòng)畫(huà)與高DPI側(cè)邊欄易用性的三個(gè)細(xì)節(jié)5.1 折疊成窄條只有圖標(biāo)也能自解釋管理軟件左側(cè)導(dǎo)航欄占用200多像素在1366x768的筆記本上再扣掉內(nèi)容區(qū)右側(cè)的滾動(dòng)條內(nèi)容區(qū)實(shí)際寬度非常緊張。所以折疊功能基本成了標(biāo)配。折疊模式我推薦兩種狀態(tài)展開(kāi)220px折疊64px只顯示圖標(biāo)。折疊態(tài)下文字不畫(huà)鼠標(biāo)懸停到圖標(biāo)上彈出ToolTip顯示菜單名。實(shí)現(xiàn)上折疊時(shí)改變控件的Width同時(shí)把繪制文字的邏輯跳過(guò)public bool Collapsed { get _collapsed; set { _collapsed value; _targetWidth _collapsed ? 64 : 220; Invalidate(); } }注意折疊后Width變化會(huì)導(dǎo)致右側(cè)內(nèi)容區(qū)一起重排這是正常的只要內(nèi)容區(qū)的控件都設(shè)置了Dock布局會(huì)自動(dòng)跟著調(diào)整。折疊態(tài)下的ToolTip我用了一個(gè)窗體級(jí)的ToolTip組件在OnMouseMove里根據(jù)當(dāng)前hover的item設(shè)置ToolTip文字沒(méi)多少代碼但體驗(yàn)提升很明顯。5.2 用Timer做過(guò)渡動(dòng)畫(huà)別一幀一幀new動(dòng)畫(huà)我用的是WinForm自帶的Timer間隔15ms每次改變Width朝目標(biāo)值靠近。這里有個(gè)性能細(xì)節(jié)不要每次Tick都重新創(chuàng)建Pen和Brush應(yīng)該在控件里緩存常用的畫(huà)刷也不要直接改Width然后Invalidate整個(gè)窗體只需Invalidate側(cè)邊欄自身。private void _animTimer_Tick(object sender, EventArgs e) { int current Width; int delta _targetWidth - current; if (Math.Abs(delta) 2) { Width _targetWidth; _animTimer.Stop(); return; } Width current delta / 2; }delta / 2這種簡(jiǎn)單緩動(dòng)看起來(lái)已經(jīng)足夠順滑沒(méi)必要引動(dòng)畫(huà)庫(kù)。WinForm的布局系統(tǒng)是同步的Width一改全局馬上重排所以動(dòng)畫(huà)期間性能開(kāi)銷(xiāo)主要在重繪菜單項(xiàng)少的話完全無(wú)感。動(dòng)畫(huà)過(guò)程中如果用戶連續(xù)點(diǎn)擊折疊按鈕要先把Timer停掉再重新啟動(dòng)不然會(huì)出現(xiàn)寬度來(lái)回跳的鬼畜情況。5.3 高DPI與字體筆記本低分辨率下最容易翻車(chē)很多人做完控件在自己的4K屏上很美觀放到客戶1366x768的筆記本上一看要么字?jǐn)D成一團(tuán)要么整體被截?cái)?。原因多半是沒(méi)處理DPI縮放。WinForm項(xiàng)目建議在Program.cs入口處加上Application.SetHighDpiMode(HighDpiMode.SystemAware);控件內(nèi)繪制字體用TextRenderer在OnPaint里不要硬編碼坐標(biāo)所有尺寸都用基于Font.Height的倍數(shù)去算。圖標(biāo)資源我一般準(zhǔn)備32x32和64x64兩套按當(dāng)前DPI選擇繪制尺寸不然高分屏上圖標(biāo)會(huì)糊。折疊狀態(tài)64px寬度在高DPI下會(huì)放不下圖標(biāo)可以把折疊寬度跟DPI關(guān)聯(lián)比如64 * DeviceDpi / 96這樣在任何分辨率的機(jī)器上表現(xiàn)都一致。6. 真實(shí)項(xiàng)目里踩過(guò)的坑6.1 自繪控件閃爍與卡頓WinForm自繪控件常見(jiàn)的閃爍來(lái)自?xún)蓚€(gè)原因一是沒(méi)有開(kāi)啟雙緩沖二是背景擦除邏輯反復(fù)執(zhí)行。Panel默認(rèn)的DoubleBuffered屬性是protected外部不能直接設(shè)置但繼承子類(lèi)里可以直接訪問(wèn)所以我的NavSideBar構(gòu)造函數(shù)里直接DoubleBuffered true;。如果你用的是UserControl寫(xiě)SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.OptimizedDoubleBuffer, true)效果一樣。高亮狀態(tài)變化時(shí)不要對(duì)整個(gè)控件Invalidate只對(duì)變化的兩個(gè)矩形區(qū)域Invalidate能省不少CPU。具體做法是在更新選中項(xiàng)時(shí)記錄舊的selectedIndex和新的selectedIndex然后Invalidate(GetItemRect(oldIndex))和Invalidate(GetItemRect(newIndex))。實(shí)測(cè)在快速連續(xù)點(diǎn)擊菜單時(shí)這個(gè)優(yōu)化能讓CPU占用從10%降到1%左右。6.2 菜單項(xiàng)多了之后的滾動(dòng)處理當(dāng)菜單超過(guò)控件高度時(shí)直接給Panel開(kāi)AutoScroll true會(huì)有一個(gè)問(wèn)題你自己在OnPaint里畫(huà)的菜單項(xiàng)不會(huì)被Panel的滾動(dòng)邏輯搬走。自繪控件做滾動(dòng)要么把所有繪制起點(diǎn)都加上AutoScrollPosition偏移要么干脆不用AutoScroll自己維護(hù)一個(gè)垂直偏移量在MouseWheel事件里累加并Invalidate。我的建議是后一種因?yàn)锳utoScrollPosition的偏移還有坐標(biāo)轉(zhuǎn)換容易繞暈自己維護(hù)偏移量反而直觀protected override void OnMouseWheel(MouseEventArgs e) { base.OnMouseWheel(e); int contentHeight _items.Count * _items[0].Height _paddingTop; if (contentHeight Height) return; _scrollOffset Math.Max(0, Math.Min(_scrollOffset - e.Delta * 2, contentHeight - Height)); Invalidate(); }繪制時(shí)所有矩形y坐標(biāo)減去_scrollOffset即可。折疊態(tài)下菜單項(xiàng)高度還是用展開(kāi)態(tài)的44px這樣切換模式時(shí)不會(huì)出現(xiàn)滾動(dòng)位置錯(cuò)亂。另外滾動(dòng)條外觀如果是默認(rèn)的灰色方塊在深色側(cè)邊欄上會(huì)特別突兀建議把系統(tǒng)滾動(dòng)條隱藏掉只靠鼠標(biāo)滾輪反正導(dǎo)航場(chǎng)景下用戶不會(huì)太依賴(lài)滾動(dòng)條拖拽。6.3 把導(dǎo)航配置抽成JSON改菜單不用改代碼最后分享一個(gè)讓我省了很多事的小改進(jìn)。側(cè)邊欄菜單結(jié)構(gòu)經(jīng)常會(huì)變比如客戶說(shuō)“加一個(gè)日志查詢(xún)頁(yè)面”傳統(tǒng)做法是改代碼重新編譯發(fā)布。我把導(dǎo)航配置抽成了一個(gè)JSON文件[ { key: dashboard, text: 總覽, icon: dashboard.png }, { key: device, text: 設(shè)備管理, icon: device.png } ]程序啟動(dòng)時(shí)讀文件按配置生成NavMenuItem集合單擊事件再按key從頁(yè)面工廠創(chuàng)建UserControl。之后加菜單只需要往JSON里加一行再寫(xiě)一個(gè)對(duì)應(yīng)的頁(yè)面類(lèi)注冊(cè)到工廠即可發(fā)布時(shí)連代碼都不用重新編譯前提是頁(yè)面類(lèi)提前存在。配置文件放在exe同級(jí)目錄客戶現(xiàn)場(chǎng)也能自己調(diào)整菜單順序和名稱(chēng)雖然這需求聽(tīng)起來(lái)有點(diǎn)怪但真遇到過(guò)幾次后你會(huì)發(fā)現(xiàn)這招很實(shí)用。這套側(cè)邊欄從最初用Button堆疊到現(xiàn)在獨(dú)立的自繪控件中間重構(gòu)了三次。每次重構(gòu)都是因?yàn)榘l(fā)現(xiàn)導(dǎo)航不只是“一排按鈕”而是整個(gè)系統(tǒng)信息架構(gòu)的門(mén)面。后續(xù)你要是想在這個(gè)基礎(chǔ)上擴(kuò)展深色主題、二級(jí)菜單或者右側(cè)滑出抽屜核心思路都是一樣的把狀態(tài)和數(shù)據(jù)管好剩下的交給OnPaint。本文還有配套的精品資源點(diǎn)擊獲取