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