核實(shí)現(xiàn)0.2秒啟動)
寫這篇文章的起因是我這段時(shí)間把一個基于 Electron 的桌面工具徹底推翻重寫用一套自研的 C# UI 引擎 XchyUI 換掉了原來的 Web 套殼方案。內(nèi)核壓縮到 200KB 級別啟動耗時(shí)從 3 秒壓到 0.2 秒以內(nèi)內(nèi)存占用從 300MB 掉到 50MB 上下。整個過程踩了不少坑也積累了一些能直接復(fù)用的經(jīng)驗(yàn)今天就是想把這套東西的來龍去脈、設(shè)計(jì)取舍、核心實(shí)現(xiàn)和實(shí)測數(shù)據(jù)攤開聊一聊。想在桌面端擺脫 Electron 體積和性能包袱、對 UI 渲染底層原理感興趣的 C# 開發(fā)者應(yīng)該能從里面找到自己需要的東西。1. 先把賬算明白200KB 和 Electron 的差距到底在哪1.1 Electron 體積與內(nèi)存的真實(shí)賬單Electron 的本質(zhì)是一個把 Chromium 瀏覽器內(nèi)核、Node.js 運(yùn)行時(shí)和你的應(yīng)用代碼打包在一起的發(fā)行方式。Chromium 本身就是個上億行的龐然大物它的多進(jìn)程架構(gòu)決定了每開一個窗口至少要拉起一個 GPU 進(jìn)程、一個渲染進(jìn)程再加若干輔助進(jìn)程。我原來的應(yīng)用僅僅是一個內(nèi)部數(shù)據(jù)看板加報(bào)表工具功能談不上復(fù)雜打包出來 exe 安裝包接近 180MB安裝完成之后磁盤占用輕松突破 600MB運(yùn)行時(shí)內(nèi)存基本穩(wěn)定在 250MB 以上切換到復(fù)雜頁面時(shí)峰值可以沖到 400MB。這在開發(fā)機(jī)上還不覺得什么放到客戶配置一般的辦公電腦上風(fēng)扇狂轉(zhuǎn)、點(diǎn)擊卡頓是常有的事。自研 XchyUI 之后整個應(yīng)用的 UI 層程序集大小只有 180KB 左右加上輔助類庫也穩(wěn)定在 200KB 級別。這里的 200KB 指的是自研 UI 引擎本體的文件體積不包含 .NET 運(yùn)行時(shí)。用 .NET 的 single-file publish 把應(yīng)用連同框架一起發(fā)布出去完整產(chǎn)物也才 35MB 左右磁盤占用 100MB 出頭運(yùn)行時(shí)內(nèi)存 40~60MB。這組數(shù)字不是拿不同配置的機(jī)器硬對比出來的而是在同一臺機(jī)器上反復(fù)測量的結(jié)果。1.2 Web 套殼方案被忽略的隱性成本很多人選擇 Electron 或者類似的 Web 套殼方案理由是寫起來快、樣式好調(diào)、前端生態(tài)豐富。這幾句話在原型階段沒問題但放到真實(shí)產(chǎn)品里隱性成本會一點(diǎn)點(diǎn)顯現(xiàn)出來。首先是啟動鏈路過長。Electron 要依次完成加載 Chromium 內(nèi)核、初始化 V8、啟動 Node.js、加載應(yīng)用腳本、構(gòu)建渲染進(jìn)程的 DOM 樹、執(zhí)行前端框架的掛載邏輯。這條鏈路做任何一步優(yōu)化都要和瀏覽器內(nèi)核打交道你幾乎沒有掌控力。你以為自己寫的是一款桌面應(yīng)用其實(shí)你只是把瀏覽器和 Node.js 縫在了一起。其次是內(nèi)存模型。前端頁面的所有 DOM 節(jié)點(diǎn)、JavaScript 對象、CSS 樣式和圖片解碼數(shù)據(jù)都堆在渲染進(jìn)程的堆里而 Node.js 和 Chromium 各自維護(hù)獨(dú)立的運(yùn)行時(shí)狀態(tài)兩邊通過 IPC 反復(fù)拷貝數(shù)據(jù)。哪怕頁面本身很簡單瀏覽器內(nèi)核的基礎(chǔ)開銷也省不掉。我遇到過僅僅打開一個主窗口、沒有任何復(fù)雜邏輯內(nèi)存就穩(wěn)定在 120MB 以上的情況——其中真正屬于業(yè)務(wù)數(shù)據(jù)的部分連 5MB 都不到。第三是事件鏈路的時(shí)延。Web 套殼中一次鼠標(biāo)點(diǎn)擊要走完渲染進(jìn)程捕獲事件 → 序列化 → IPC 發(fā)給主進(jìn)程 → 主進(jìn)程執(zhí)行邏輯 → 序列化 → IPC 回渲染進(jìn)程 → 更新 DOM → 瀏覽器重排重繪。這條鏈路從原理上就決定了它的延遲不可能太低尤其是頻繁交互的場景掉幀、卡頓幾乎是必然的。1.3 自研引擎的收益邊界與選型判斷做任何技術(shù)決策之前先想清楚收益邊界。自研 UI 引擎確實(shí)能解決 Electron 的體積、內(nèi)存、啟動速度問題但它也要求你具備對渲染底層機(jī)制的基本理解同時(shí)意味著你不再擁有前端生態(tài)里那些開箱即用的圖表庫、富文本編輯器、UI 組件庫。我的判斷標(biāo)準(zhǔn)是如果應(yīng)用界面復(fù)雜度一般交互密度高對資源占用有硬性要求且團(tuán)隊(duì)本身有 C# 功底那么就非常適合走自研路線。反過來如果你的應(yīng)用重度依賴網(wǎng)頁生態(tài)里那些復(fù)雜組件界面每天都要換皮膚、調(diào)樣式又或者迭代速度要求極高那還是繼續(xù)用 Electron 或者考慮 Avalonia 這類成熟框架更穩(wěn)妥。XchyUI 的定位就是夠用且可控。它不做你根本用不上的各種瀏覽器特性不做通用 DOM 解析不做復(fù)雜的 CSS 盒模型而是聚焦桌面應(yīng)用真正高頻需要的按鈕、輸入框、列表、樹、表格、簡單的自定義繪圖面板。這個邊界決定了它能夠做到很小也決定了它能夠快。2. 200KB 內(nèi)核是怎么做到的XchyUI 的核心架構(gòu)2.1 剝離 Chromium 后一個 UI 引擎剩下什么很多人聽到自研 UI 引擎會下意識覺得這是個大工程動輒要寫幾萬行代碼。實(shí)際上如果暫時(shí)放下瀏覽器那套巨獸體量一個面向桌面應(yīng)用的 UI 引擎只需要解決六個子問題窗口創(chuàng)建和消息循環(huán)——調(diào)用操作系統(tǒng)提供的原生窗口機(jī)制繪制圖元——在窗口客戶區(qū)輸出文字、矩形、線條、圖片輸入事件——把鼠標(biāo)、鍵盤、觸摸事件分發(fā)到具體控件布局計(jì)算——按規(guī)則算出每個控件的位置與尺寸控件樹與生命周期——組織界面結(jié)構(gòu)并管理重繪樣式與主題——讓控件長得不那么原生且保持一致性Electron 為了兼容所有網(wǎng)頁技術(shù)把每個子問題都做成了通用抽象代價(jià)就是體量爆炸。XchyUI 的做法恰恰相反按照桌面應(yīng)用的實(shí)際情況做最強(qiáng)約束?？丶涫瞧胀ǖ?C# 對象樹布局只支持垂直流式、水平流式、絕對定位和表格定位樣式只有純色背景、邊框、字體、間距這些有限屬性。約束越多實(shí)現(xiàn)越簡單越容易做到極致體量。2.2 渲染層的選擇為什么不直接上 SkiaSharp做 C# UI 引擎第一個選型難題就是渲染后端。備選項(xiàng)無非幾個GDI、SkiaSharp、SharpDX/Direct2D、OpenGL。SkiaSharp 功能強(qiáng)大跨平臺文字渲染質(zhì)量高但它本身是一個相當(dāng)龐大的圖形庫原生部分加載進(jìn)進(jìn)程就占不少內(nèi)存包裝層也不小。再疊加微軟的字體管理系統(tǒng)和圖像解碼庫內(nèi)核體積很難保持在 200KB 量級。SharpDX/Direct2D 性能更好但它是原生 COM 接口的薄封裝使用難度大對象生命周期管理要非常小心哪怕一個 COM 引用釋放遺漏都可能引發(fā)直接的地址訪問錯誤比如 C# 調(diào)用 C 層時(shí)常見的 access violation c0000005。對于一個小內(nèi)核的項(xiàng)目引入這么厚的底層依賴性價(jià)比不高。XchyUI 最終選擇了 GDI 作為第一代渲染后端。理由很直接它吃內(nèi)存少調(diào)用鏈短C# 里用 System.Drawing 就能穩(wěn)定輸出文字和圖形。雖然 GDI 的渲染性能上限不如 Direct2D但是對于一個界面層操作遠(yuǎn)多于高頻動畫的桌面應(yīng)用來說60fps 的需求是一定滿足得了的——我后面會給出實(shí)測數(shù)據(jù)。提示這里有個常見誤區(qū)。很多人覺得 GDI 慢是因?yàn)槟盟ヤ秩菊敛粩嘧兓母邘视螒虍嬅?。對于普通表單和業(yè)務(wù)界面GDI 的真正瓶頸并不在繪制速度而在無腦整窗重繪。做好局部失效重繪之后性能完全夠用。2.3 消息循環(huán)與事件分發(fā)的最小實(shí)現(xiàn)Windows 應(yīng)用程序的窗口系統(tǒng)是一個消息驅(qū)動模型。鼠標(biāo)點(diǎn)擊、鍵盤輸入、窗口移動、尺寸變化Windows 都會把行為封裝成消息投遞到目標(biāo)窗口的消息隊(duì)列里。你的 UI 框架只要持續(xù)循環(huán)接收這些消息再轉(zhuǎn)成自己的事件就完成了事件分發(fā)。XchyUI 的消息循環(huán)是所有控件的心臟。它的基本結(jié)構(gòu)是一個 while 循環(huán)調(diào)用 Win32 的 GetMessage 取出消息TranslateMessage 做鍵盤按鍵翻譯再 DispatchMessage 把消息交還給窗口過程函數(shù)。窗口過程里XchyUI 收到 WM_PAINT 就觸發(fā)整體重繪收到鼠標(biāo)移動消息就把坐標(biāo)換算后交給命中測試邏輯從而找到這個點(diǎn)落在哪個控件上再把對應(yīng)的鼠標(biāo)事件派發(fā)給它。這里要強(qiáng)調(diào)的是消息循環(huán)和渲染循環(huán)的關(guān)系。XchyUI 并不是拿一個獨(dú)立的死循環(huán)去不斷刷幀。沒有界面變化時(shí)消息循環(huán)會阻塞在 GetMessage 上CPU 占用率幾乎降到零。只有當(dāng)消息到達(dá)、或者某段代碼顯式觸發(fā)重繪時(shí)才走一遍繪制流程。這種做法保證了百分百的省電和安靜也是桌面應(yīng)用該有的基本素養(yǎng)。2.4 布局引擎從坐標(biāo)計(jì)算到 Flex/Stack 布局Electron 里的布局是由 CSS 盒模型計(jì)算的瀏覽器為了一小段樣式要跑完整的計(jì)算鏈。XchyUI 不需要這套東西。我把它設(shè)計(jì)成了一套極簡的測量-安排兩階段布局流程。測量階段每個控件根據(jù)自己的內(nèi)容、字體和尺寸策略計(jì)算出理想大小。安排階段容器控件按照自己的布局規(guī)則把子控件逐個擺放到具體位置。最核心的容器是 StackLayout參數(shù)只有方向垂直或水平和間距Spacing沒有百分比、沒有媒體查詢。另一個是 GridLayout把可用區(qū)域按行和列切分對表格類界面特別實(shí)用。這兩下子看起來樸素的過分但實(shí)際用下來會發(fā)現(xiàn)桌面應(yīng)用 90% 的界面布局就是一行一行往下排加一個二維表格。自研引擎的最大好處就是你可以按照實(shí)際需求去砍功能而不必被通用方案拖累。3. 手把手構(gòu)建 XchyUI 跑道渲染循環(huán)、事件系統(tǒng)與組件封裝3.1 第一個可用的渲染循環(huán)先看一段最核心的代碼。這是 XchyUI 消息循環(huán)和渲染觸發(fā)的骨架去掉了一些邊界處理保留了主干邏輯。public sealed class XchyApplication { private readonly IntPtr _hwnd; private readonly ListControl _rootControls new(); private bool _dirty true; public void Run(Window mainWindow) { _hwnd mainWindow.Handle; mainWindow.Show(); while (true) { if (GetMessage(out var msg, IntPtr.Zero, 0, 0)) { TranslateMessage(ref msg); DispatchMessage(ref msg); } else { break; // 收到 WM_QUIT退出應(yīng)用 } if (_dirty) { RenderFrame(); _dirty false; } } } private void RenderFrame() { var buffer new Bitmap(WindowWidth, WindowHeight); using var g Graphics.FromImage(buffer); g.Clear(_backgroundBrush); // 先布局再繪制 LayoutEngine.Instance.Arrange( _rootControls, new Rect(0, 0, WindowWidth, WindowHeight)); foreach (var control in _rootControls) control.Draw(g); using var screen Graphics.FromHwnd(_hwnd); screen.DrawImageUnscaled(buffer, 0, 0); } }這里用了一個 內(nèi)存位圖 一次性拷貝 的雙緩沖思路。先在內(nèi)存里畫好整幀再一次性拷貝到窗口顯示區(qū)避免用戶看到撕裂的繪制過程。邏輯上整個渲染循環(huán)不就兩件事消息來了處理界面臟了重畫。消息循環(huán)負(fù)責(zé)響應(yīng)動作渲染循環(huán)負(fù)責(zé)呈現(xiàn)結(jié)果二者通過 _dirty 標(biāo)志位解耦不會出現(xiàn)事件處理時(shí)強(qiáng)插一個繪制的混亂局面。3.2 控件樹與命中測試的完整實(shí)現(xiàn)控件樹是 XchyUI 結(jié)構(gòu)上最重要的數(shù)據(jù)結(jié)構(gòu)。每個控件要么是葉子節(jié)點(diǎn)要么是內(nèi)部節(jié)點(diǎn)內(nèi)部節(jié)點(diǎn)負(fù)責(zé)持有子控件集合。結(jié)構(gòu)就是這么簡單。public abstract class Control { public string Name { get; set; } string.Empty; public Rect Bounds { get; set; } public bool Visible { get; set; } true; public bool Enabled { get; set; } true; public Control? Parent { get; internal set; } public ListControl Children { get; } new(); public void Add(Control child) { child.Parent this; Children.Add(child); } public virtual Size Measure() { // 子類根據(jù)內(nèi)容計(jì)算理想尺寸 return new Size(0, 0); } public virtual void Draw(Graphics g) { if (!Visible) return; foreach (var child in Children) child.Draw(g); } public virtual bool HitTest(Point p) { return Visible Enabled Bounds.Contains(p); } public virtual void OnMouseDown(Point location, MouseButton button) { } public virtual void OnMouseUp(Point location, MouseButton button) { } public virtual void OnMouseMove(Point location) { } internal virtual void RaiseMouseDown(Point location, MouseButton button) { // 深度優(yōu)先優(yōu)先把事件交給最后繪制、看起來在上層的子控件 for (var i Children.Count - 1; i 0; i--) { var child Children[i]; if (child.HitTest(location)) { child.RaiseMouseDown(location, button); return; } } OnMouseDown(location, button); } }命中測試的規(guī)則也很直接收到鼠標(biāo)點(diǎn)擊坐標(biāo)后從控件樹的最末端節(jié)點(diǎn)往根節(jié)點(diǎn)走誰的面積覆蓋了這個點(diǎn)就把事件給誰。因?yàn)樽詈罄L制的控件視覺上在最前面所以按子控件列表的倒序去檢查第一個命中的就是用戶真正想點(diǎn)的那個控件。這套機(jī)制雖然樸素但已經(jīng)足夠在按鈕、列表項(xiàng)、樹節(jié)點(diǎn)之間做出正確的事件路由。3.3 組件庫封裝Button、TextBox、List 的設(shè)計(jì)思路有了控件樹和事件路由接下來就是封裝具體控件。以一個最簡單的 Button 為例它需要處理三種視覺狀態(tài)普通、懸停、按下每種狀態(tài)對應(yīng)不同的背景色。繪制時(shí)根據(jù)狀態(tài)填充圓角矩形再居中繪制文字。XchyUI 中按鈕的實(shí)現(xiàn)大概只有 100 行但它完整覆蓋了外觀表現(xiàn)和交互反饋。TextBox 復(fù)雜一些。它要管理插入符位置、支持響應(yīng)鍵盤輸入、處理光標(biāo)閃爍、支持選中區(qū)域的反白顯示。早期版本我直接在控件內(nèi)部用一個普通的 TextBox 成員變量去承接輸入后來發(fā)現(xiàn)這會造成 WinForms 控件的全權(quán)耦合最后改用純 GDI 繪制文本和插入符自己實(shí)現(xiàn)鍵盤字符替換邏輯。這樣既減少了外部依賴也讓控件體積和渲染可控性更好。List 是另一個高頻組件。我最初實(shí)現(xiàn)的是全部可見項(xiàng)逐一繪制的樸素版本。支持 10 個、20 個條目沒問題但條目一旦達(dá)到幾千個逐一繪制就會拖慢每幀速度。最終采用了虛擬化方案只繪制出現(xiàn)在可視區(qū)域內(nèi)的那幾十個條目。這個優(yōu)化屬于 UI 引擎常見的基礎(chǔ)設(shè)計(jì)但對性能的提升是立竿見影的。3.4 局部失效區(qū)域優(yōu)化不做無腦全窗重繪自研引擎最容易被忽視的一個細(xì)節(jié)是哪些區(qū)域需要重繪。一開始我也是最簡單的辦法控件 Event 觸發(fā)任何變化就設(shè) _dirtytrue然后整窗口重畫。這在控件少時(shí)無所謂窗口大了或者控件多了無謂的整窗繪制會直接影響幀率。XchyUI 最終實(shí)現(xiàn)了區(qū)域失效機(jī)制。每個控件維護(hù)一個 IsDirty 標(biāo)記父容器負(fù)責(zé)把子控件的臟區(qū)域合并成一個或多個矩形區(qū)域記錄到 _invalidRegions 集合。RenderFrame 時(shí)只對這些矩形區(qū)域做裁剪繪制最后用 DrawImageUnscaled 配合 Graphics 的 SetClip 把對應(yīng)部分拷貝到窗口上。這樣高頻改動的小控件不會再拖累整個窗口的重繪。提示實(shí)現(xiàn)局部失效的復(fù)雜度會明顯上升因?yàn)椴眉魠^(qū)域、控件交疊、縮放變換都要處理。如果項(xiàng)目第一版趕進(jìn)度建議還是先整窗重繪把功能跑通之后再用特性分支去升級局部失效。性能優(yōu)化永遠(yuǎn)不要發(fā)生在需求還沒穩(wěn)定的階段。4. 性能驗(yàn)證與真實(shí)數(shù)據(jù)怎樣才算秒殺4.1 1000 控件壓力測試的實(shí)測數(shù)據(jù)我拿一個真實(shí)場景做了壓力測試窗體里有 1000 個自定義卡片控件每個卡片包含一個標(biāo)題、一行描述、一個圖標(biāo)區(qū)域。分別測量了靜態(tài)界面無交互時(shí)的幀率、滾動列表時(shí)的事件處理吞吐量、以及內(nèi)存占用。用 XchyUI 跑這套界面靜態(tài)幀率穩(wěn)定在 60fps觸發(fā)滾動和點(diǎn)擊時(shí)幀耗時(shí)幾乎恒定在 14ms 左右CPU 占用率在無交互時(shí)是 0.4% 以下持續(xù)滾動的峰值也只有 15%。同樣的界面我用 Electron 做了一版對照靜態(tài)內(nèi)存大約 260MB高速滾動時(shí)幀率會出現(xiàn)明顯下降到 40fps 以下CPU 峰值可達(dá) 45%。差距的主要來源是 Electron 每一次滾動都要經(jīng)過 DOM 樹更新、樣式重算和瀏覽器合成而 XchyUI 只是在畫布上把卡片新位置繪制一遍。4.2 內(nèi)存與啟動時(shí)間的可復(fù)現(xiàn)測試方法性能對比不能只憑體感要有一套可復(fù)現(xiàn)的測量方法。在 XchyUI 里我做了這樣三個測試步驟任何人都可以直接抄走啟動耗時(shí)從進(jìn)程啟動開始計(jì)時(shí)到主窗口完成第一幀繪制結(jié)束。用 Stopwatch 包裹 Main 函數(shù)入口之后到 Run 函數(shù)進(jìn)入首輪 RenderFrame 完成的位置多次取中位數(shù)。內(nèi)存占用用 GC.GetTotalMemory(false) 做增量測量判斷托管堆增長情況再用 Process.WorkingSet64 觀察進(jìn)程整體的工作集。后者受 .NET 運(yùn)行時(shí)預(yù)熱影響較大最好在運(yùn)行 30 秒、各項(xiàng)功能點(diǎn)過一遍之后再讀數(shù)。滾動流暢度維護(hù)一個固定長度的幀耗時(shí)隊(duì)列在滾動循環(huán)里每次 SwapBuffer 后記錄耗時(shí)統(tǒng)計(jì) P9595 分位值。如果 P95 低于 16ms基本可以認(rèn)定在普通 60Hz 屏幕上是流暢的。按照這套方法實(shí)測下來的結(jié)果前面已經(jīng)列了這里再補(bǔ)一個最有說服力的對比同一個業(yè)務(wù)流程從點(diǎn)擊按鈕到界面完成刷新XchyUI 的平均時(shí)間是 9msElectron 大約是 87ms。這個差異在業(yè)務(wù)界面上直接體感就是秒開和輕微遲滯的區(qū)別。4.3 XchyUI、Electron、WPF 的橫向?qū)φ罩笜?biāo)XchyUIElectronWPFUI 層程序集體積約 200KB瀏覽器內(nèi)核約 150MB框架約 3MB完整安裝包體積約 35MB含 .NET 運(yùn)行時(shí)普遍 150MB~250MB約 50MB 起啟動到首幀時(shí)間0.1~0.2s1.5~3s0.2~0.4s靜態(tài)內(nèi)存占用簡單窗口40~60MB150~300MB80~120MB渲染原理GDI可選后端升級Chromium 合成器DirectX 合成器跨平臺計(jì)劃中三平臺全覆蓋僅 Windows前端生態(tài)可用性無完整極弱這張表格不是為了貶低 Electron 和 WPF而是想說明不同技術(shù)棧的本質(zhì)差異Electron 用一個完整的瀏覽器內(nèi)核來解決通用問題WPF 用一個龐大的框架體系來解決富媒體表現(xiàn)問題而 XchyUI 是定義問題邊界之后做減法的產(chǎn)物。三種方案適合三種不同訴求關(guān)鍵是看清楚你的訴求是什么。4.4 高 DPI、字體渲染、線程調(diào)度等細(xì)節(jié)坑在測試和真實(shí)使用中有幾個細(xì)節(jié)會讓結(jié)果出現(xiàn)劇烈波動必須單獨(dú)說。高 DPI 是第一大坑。如果進(jìn)程沒有正確聲明 DPI 感知Windows 會把你的窗口自動縮放導(dǎo)致所有坐標(biāo)比例錯亂畫面模糊點(diǎn)擊區(qū)域?qū)Σ簧?。我最終把清單里的 dpiAwareness 設(shè)成了 PerMonitorV2再用 QueryDpiAwareness 做運(yùn)行時(shí)檢測。這套處理做完在 125%、150% 縮放環(huán)境下窗口和對齊才是正確的。字體是第二大坑。GDI 的文本渲染在默認(rèn)字體下會有明顯的鋸齒中文尤其容易發(fā)虛。我的經(jīng)驗(yàn)是優(yōu)先使用微軟雅黑并開啟 TextRenderingHint.ClearTypeGridFit同時(shí)對字體做一次 Fallback 鏈——微軟雅黑 → 宋體 → 系統(tǒng)默認(rèn)字體。這樣即便目標(biāo)機(jī)器沒有安裝微軟雅黑中文也不會變成方塊。線程調(diào)度是第三大坑。所有 UI 相關(guān)的繪制和控件屬性更新必須發(fā)生在創(chuàng)建窗口的同一個線程上。如果在后臺線程直接改控件坐標(biāo)或者觸發(fā)重繪輕則閃爍重則直接崩潰典型的 access violation c0000005 就是這么來的C# 層訪問了已被釋放的 GDI 對象。XchyUI 內(nèi)部做了一個簡單的 Dispatcher 封裝所有外部更新請求統(tǒng)一通過 PostMessage 投遞到 UI 線程執(zhí)行。5. 實(shí)戰(zhàn)記錄從 Web 套殼遷移到 XchyUI 的完整過程5.1 遷移前的架構(gòu)評估與組件盤點(diǎn)如果你現(xiàn)在也想做類似的遷移第一個建議是不要急著寫代碼先盤需求。我把原有應(yīng)用里的界面元素逐個列成清單按鈕、輸入框、下拉框、表格、樹、彈窗、消息條、自定義繪圖面板、右鍵菜單。然后逐個評估XchyUI 現(xiàn)成有沒有、需要新寫、需要改設(shè)計(jì)。最終結(jié)論是 60% 的控件可以直接復(fù)用25% 需要少量定制15% 需要重寫思路。這個評估過程還有個額外收益它會逼著你去砍那些看起來挺炫但沒人用的界面裝飾。脫離 Web 生態(tài)后很多花里胡哨的動效自然就不做了產(chǎn)品反而更聚焦。另一個重要決策是數(shù)據(jù)綁定。Web 套殼的前端框架都有響應(yīng)式綁定XchyUI 一開始沒有設(shè)計(jì)這套東西。我的過渡方案是控件數(shù)據(jù)源 刷新接口每個復(fù)雜控件持有一個數(shù)據(jù)源列表數(shù)據(jù)變化時(shí)調(diào)用控件的 Refresh()控件在內(nèi)部重新讀取數(shù)據(jù)并標(biāo)記臟區(qū)域。這個模式寫起來比響應(yīng)式綁定繁瑣但邏輯鏈路很短排查問題很容易。數(shù)據(jù)頻率不高的場景下這種寫法完全夠了。數(shù)據(jù)綁定決策還影響了一個核心數(shù)據(jù)結(jié)構(gòu)。從 Web 套殼遷移到一個內(nèi)聚框架最大的區(qū)別就是所有狀態(tài)有且僅有一個權(quán)威來源。Web 時(shí)代可能 Model 一套、DOM 一套、狀態(tài)管理再存一份XchyUI 只認(rèn) C# 對象里的字段。別小看這個約束它直接解決了大量數(shù)據(jù)不同步的舊 Bug。5.2 自定義主題系統(tǒng)與樣式處理Web 套殼里改樣式是頻率很高的操作。自研引擎如果讓每個控件把顏色、字體寫死團(tuán)隊(duì)迭代起來會非常痛苦。我做了一個極簡主題系統(tǒng)主題是一個 Theme 對象里面有背景色、前景色、邊框色、按鈕不同狀態(tài)的顏色、字體名稱和尺寸、間距常量等若干字段。所有控件在繪制時(shí)只從當(dāng)前主題讀取顏色不硬編碼。切換主題只需要換一個 Theme 實(shí)例然后全窗標(biāo)記重繪。因?yàn)?GDI 里繪制矩形和文字的成本極低哪怕是整窗重繪也能在幾毫秒內(nèi)完成主題切換這個平時(shí)最容易卡出掉幀的操作反而成了 XchyUI 最具表現(xiàn)力的功能之一。5.3 常見問題排查速查表現(xiàn)象可能原因排查思路與解決動作窗口渲染為空白重繪時(shí)機(jī)被漏掉WM_PAINT 沒有觸發(fā)布爾標(biāo)記檢查 Invalidate 是否真的調(diào)用了確認(rèn)渲染代碼是否在 UI 線程執(zhí)行點(diǎn)擊控件沒有反應(yīng)消息循環(huán)被阻塞或者命中測試順序錯誤檢查事件處理里是否有 Sleep/耗時(shí)操作打印鼠標(biāo)坐標(biāo)和控件 Bounds 對比文字發(fā)虛、有鋸齒GDI 默認(rèn)渲染模式不對設(shè)置 Graphics.TextRenderingHint ClearTypeGridFit中文顯示方塊字體 Fallback 缺失配置字體鏈優(yōu)先用系統(tǒng)自帶的微軟雅黑高 DPI 下坐標(biāo)全亂進(jìn)程沒聲明 DPI 感知修改 manifest 設(shè)置 PerMonitorV2并動態(tài)查詢 DPI內(nèi)存緩慢上漲每次繪制創(chuàng)建了 Bitmap 未釋放或者事件沒有解綁用 Dispose 模式管理 Bitmap檢查控件樹移除時(shí)是否清理事件引用后臺線程 Crash跨線程操作 UI 控件統(tǒng)一走 Dispatcher不要直接訪問控件屬性5.4 打包發(fā)布與裁剪策略XchyUI 項(xiàng)目的目標(biāo)是小打包環(huán)節(jié)也要堅(jiān)持這個思路。首先確保所有用不到的程序集不進(jìn)發(fā)布目錄。然后使用 .NET 的 single-file publish 把所有托管程序集打成一個文件這是最直觀的體積削減。之后經(jīng)過 ILLink 裁剪把沒有被引用的框架代碼從最后的產(chǎn)物里移除。這里有個值得注意的細(xì)節(jié)ILLink 裁剪雖然能縮小體積但它對反射破壞非常敏感。如果代碼里用了 Type.GetType 或者反射調(diào)用必須給對應(yīng)的程序集標(biāo)記 DynamicDependency否則運(yùn)行時(shí)會直接 TypeNotFound。我在 XchyUI 的早期版本就踩過這個坑上線測試時(shí)控件創(chuàng)建報(bào)了一大堆反射錯誤最后是把加載邏輯改成顯式注冊表才繞開反射機(jī)制的不確定性。發(fā)布時(shí)還要保留 PDB 文件。自研引擎沒有成熟的崩潰上報(bào)體系如果你連符號文件都沒有用戶那邊報(bào)一個 access violation 你根本沒法定位。PDB 加上 Windows 事件日志里捕獲到的異常堆棧是排查崩潰類問題最重要的兩張底牌。6. 下一步值得探索的方向6.1 跨平臺與國產(chǎn)化適配XchyUI 目前以 Windows 為主但架構(gòu)上沒有把非 Windows 的路堵死。核心的控件樹、布局引擎、事件路由邏輯全部用純 C# 實(shí)現(xiàn)不依賴任何 Windows 程序集。只有最底層的創(chuàng)建窗口 消息循環(huán) 圖形上下文這一層與平臺相關(guān)我把它隔離成了 IPlatformBackend 接口。如果后續(xù)要支持 Linux可以在 XLib/Wayland 上實(shí)現(xiàn)這個接口macOS 則走 Cocoa國產(chǎn)化環(huán)境的難點(diǎn)主要在 CPU 架構(gòu)而非操作系統(tǒng)——大部分國產(chǎn)系統(tǒng)本身就是 Linux 內(nèi)核但指令集可能是 ARM 或者龍芯的 LoongArch。.NET 官方已經(jīng)支持多種架構(gòu)的 Linux 發(fā)布理論上只要 IPlatformBackend 的接口實(shí)現(xiàn)能正常編譯整套 UI 引擎就能在這些平臺上跑起來。這條路我還沒有完整走通現(xiàn)階段只能算一個方向但它讓 XchyUI 擁有一個比 Electron 輕量得多的跨平臺想象空間。6.2 渲染后端升級路線SkiaSharp、SharpDX 都只是備選GDI 作為第一代渲染后端確實(shí)簡單穩(wěn)定但它的抗鋸齒質(zhì)量、圖形變換能力、復(fù)雜路徑填充效果都存在上限。后續(xù)如果要支持更細(xì)膩的圓角陰影、漸變、變換動畫就需要考慮更強(qiáng)大的渲染后端。我的規(guī)劃不是立刻替換而是先把渲染層抽象成 ICanvas 接口GDI 只是其中一個實(shí)現(xiàn)。然后可以逐步添加 SkiaSharpCanvas、SharpDXCanvas 這些實(shí)現(xiàn)并且針對不同后端去做性能對比。這里的關(guān)鍵是渲染后端可以換但控件樹結(jié)構(gòu)、布局引擎、事件系統(tǒng)絕不能因?yàn)閾Q后端而重寫。接口隔離的意義就在于讓變化局限在最小范圍內(nèi)。注意追加渲染后端要考慮的不僅是代碼工作量還有體量變化。SkiaSharp 的原生庫會拉高內(nèi)核體積SharpDX 的 COM 對象生命周期也要投入不少精力。收益與代價(jià)需要反復(fù)權(quán)衡別為了營造技術(shù)很牛的感覺去堆疊依賴。6.3 開源計(jì)劃與社區(qū)共建XchyUI 現(xiàn)在處于自用順手、開源需整理的狀態(tài)。如果要開源許可證我會選 MIT 或者 Apache-2.0并且會整理出三類倉庫內(nèi)容核心引擎、組件庫、示例模板。社區(qū)共建的價(jià)值在于可以讓更多從業(yè)者幫忙補(bǔ)齊真實(shí)場景里的邊界情況——不同輸入法、不同顯卡驅(qū)動、不同企業(yè)安全軟件的兼容性這些問題永遠(yuǎn)只能靠足夠多的真實(shí)場景暴露出來。我還沒有確定開源的具體時(shí)間表但可以確定的是即使不開源我也會持續(xù)把 XchyUI 用于自己的實(shí)際項(xiàng)目讓它保持小而鋒利的特點(diǎn)而不是膨脹成一個誰都不需要的通用框架。最后分享一點(diǎn)個人體會。整個遷移過程中我最深的感受不是Electron 不好而是技術(shù)選型要對齊真實(shí)約束。如果你的產(chǎn)品身處資源受限環(huán)境或者用戶對啟動速度和內(nèi)存占用極其敏感那 Electron 這套技術(shù)棧的底層代價(jià)就會壓得你很難受。自研引擎的價(jià)值不在于標(biāo)榜我不用 Electron而在于它逼著你去理解 UI 是怎么工作的——一個按鈕從點(diǎn)擊到屏幕反饋經(jīng)歷哪些環(huán)節(jié)、一次滾動如何保證不卡、一個窗體如何做到秒開。這些理解在任何技術(shù)棧里都不會浪費(fèi)。不要被性能焦慮綁架更不要被工具路徑綁架——輕量自有輕量的價(jià)值。 從Electron到自研C# UI引擎：200KB內(nèi)核實(shí)現(xiàn)0.2秒啟動
寫這篇文章的起因是我這段時(shí)間把一個基于 Electron 的桌面工具徹底推翻重寫用一套自研的 C# UI 引擎 XchyUI 換掉了原來的 Web 套殼方案。內(nèi)核壓縮到 200KB 級別啟動耗時(shí)從 3 秒壓到 0.2 秒以內(nèi)內(nèi)存占用從 300MB 掉到 50MB 上下。整個過程踩了不少坑也積累了一些能直接復(fù)用的經(jīng)驗(yàn)今天就是想把這套東西的來龍去脈、設(shè)計(jì)取舍、核心實(shí)現(xiàn)和實(shí)測數(shù)據(jù)攤開聊一聊。想在桌面端擺脫 Electron 體積和性能包袱、對 UI 渲染底層原理感興趣的 C# 開發(fā)者應(yīng)該能從里面找到自己需要的東西。1. 先把賬算明白200KB 和 Electron 的差距到底在哪1.1 Electron 體積與內(nèi)存的真實(shí)賬單Electron 的本質(zhì)是一個把 Chromium 瀏覽器內(nèi)核、Node.js 運(yùn)行時(shí)和你的應(yīng)用代碼打包在一起的發(fā)行方式。Chromium 本身就是個上億行的龐然大物它的多進(jìn)程架構(gòu)決定了每開一個窗口至少要拉起一個 GPU 進(jìn)程、一個渲染進(jìn)程再加若干輔助進(jìn)程。我原來的應(yīng)用僅僅是一個內(nèi)部數(shù)據(jù)看板加報(bào)表工具功能談不上復(fù)雜打包出來 exe 安裝包接近 180MB安裝完成之后磁盤占用輕松突破 600MB運(yùn)行時(shí)內(nèi)存基本穩(wěn)定在 250MB 以上切換到復(fù)雜頁面時(shí)峰值可以沖到 400MB。這在開發(fā)機(jī)上還不覺得什么放到客戶配置一般的辦公電腦上風(fēng)扇狂轉(zhuǎn)、點(diǎn)擊卡頓是常有的事。自研 XchyUI 之后整個應(yīng)用的 UI 層程序集大小只有 180KB 左右加上輔助類庫也穩(wěn)定在 200KB 級別。這里的 200KB 指的是自研 UI 引擎本體的文件體積不包含 .NET 運(yùn)行時(shí)。用 .NET 的 single-file publish 把應(yīng)用連同框架一起發(fā)布出去完整產(chǎn)物也才 35MB 左右磁盤占用 100MB 出頭運(yùn)行時(shí)內(nèi)存 40~60MB。這組數(shù)字不是拿不同配置的機(jī)器硬對比出來的而是在同一臺機(jī)器上反復(fù)測量的結(jié)果。1.2 Web 套殼方案被忽略的隱性成本很多人選擇 Electron 或者類似的 Web 套殼方案理由是寫起來快、樣式好調(diào)、前端生態(tài)豐富。這幾句話在原型階段沒問題但放到真實(shí)產(chǎn)品里隱性成本會一點(diǎn)點(diǎn)顯現(xiàn)出來。首先是啟動鏈路過長。Electron 要依次完成加載 Chromium 內(nèi)核、初始化 V8、啟動 Node.js、加載應(yīng)用腳本、構(gòu)建渲染進(jìn)程的 DOM 樹、執(zhí)行前端框架的掛載邏輯。這條鏈路做任何一步優(yōu)化都要和瀏覽器內(nèi)核打交道你幾乎沒有掌控力。你以為自己寫的是一款桌面應(yīng)用其實(shí)你只是把瀏覽器和 Node.js 縫在了一起。其次是內(nèi)存模型。前端頁面的所有 DOM 節(jié)點(diǎn)、JavaScript 對象、CSS 樣式和圖片解碼數(shù)據(jù)都堆在渲染進(jìn)程的堆里而 Node.js 和 Chromium 各自維護(hù)獨(dú)立的運(yùn)行時(shí)狀態(tài)兩邊通過 IPC 反復(fù)拷貝數(shù)據(jù)。哪怕頁面本身很簡單瀏覽器內(nèi)核的基礎(chǔ)開銷也省不掉。我遇到過僅僅打開一個主窗口、沒有任何復(fù)雜邏輯內(nèi)存就穩(wěn)定在 120MB 以上的情況——其中真正屬于業(yè)務(wù)數(shù)據(jù)的部分連 5MB 都不到。第三是事件鏈路的時(shí)延。Web 套殼中一次鼠標(biāo)點(diǎn)擊要走完渲染進(jìn)程捕獲事件 → 序列化 → IPC 發(fā)給主進(jìn)程 → 主進(jìn)程執(zhí)行邏輯 → 序列化 → IPC 回渲染進(jìn)程 → 更新 DOM → 瀏覽器重排重繪。這條鏈路從原理上就決定了它的延遲不可能太低尤其是頻繁交互的場景掉幀、卡頓幾乎是必然的。1.3 自研引擎的收益邊界與選型判斷做任何技術(shù)決策之前先想清楚收益邊界。自研 UI 引擎確實(shí)能解決 Electron 的體積、內(nèi)存、啟動速度問題但它也要求你具備對渲染底層機(jī)制的基本理解同時(shí)意味著你不再擁有前端生態(tài)里那些開箱即用的圖表庫、富文本編輯器、UI 組件庫。我的判斷標(biāo)準(zhǔn)是如果應(yīng)用界面復(fù)雜度一般交互密度高對資源占用有硬性要求且團(tuán)隊(duì)本身有 C# 功底那么就非常適合走自研路線。反過來如果你的應(yīng)用重度依賴網(wǎng)頁生態(tài)里那些復(fù)雜組件界面每天都要換皮膚、調(diào)樣式又或者迭代速度要求極高那還是繼續(xù)用 Electron 或者考慮 Avalonia 這類成熟框架更穩(wěn)妥。XchyUI 的定位就是夠用且可控。它不做你根本用不上的各種瀏覽器特性不做通用 DOM 解析不做復(fù)雜的 CSS 盒模型而是聚焦桌面應(yīng)用真正高頻需要的按鈕、輸入框、列表、樹、表格、簡單的自定義繪圖面板。這個邊界決定了它能夠做到很小也決定了它能夠快。2. 200KB 內(nèi)核是怎么做到的XchyUI 的核心架構(gòu)2.1 剝離 Chromium 后一個 UI 引擎剩下什么很多人聽到自研 UI 引擎會下意識覺得這是個大工程動輒要寫幾萬行代碼。實(shí)際上如果暫時(shí)放下瀏覽器那套巨獸體量一個面向桌面應(yīng)用的 UI 引擎只需要解決六個子問題窗口創(chuàng)建和消息循環(huán)——調(diào)用操作系統(tǒng)提供的原生窗口機(jī)制繪制圖元——在窗口客戶區(qū)輸出文字、矩形、線條、圖片輸入事件——把鼠標(biāo)、鍵盤、觸摸事件分發(fā)到具體控件布局計(jì)算——按規(guī)則算出每個控件的位置與尺寸控件樹與生命周期——組織界面結(jié)構(gòu)并管理重繪樣式與主題——讓控件長得不那么原生且保持一致性Electron 為了兼容所有網(wǎng)頁技術(shù)把每個子問題都做成了通用抽象代價(jià)就是體量爆炸。XchyUI 的做法恰恰相反按照桌面應(yīng)用的實(shí)際情況做最強(qiáng)約束?？丶涫瞧胀ǖ?C# 對象樹布局只支持垂直流式、水平流式、絕對定位和表格定位樣式只有純色背景、邊框、字體、間距這些有限屬性。約束越多實(shí)現(xiàn)越簡單越容易做到極致體量。2.2 渲染層的選擇為什么不直接上 SkiaSharp做 C# UI 引擎第一個選型難題就是渲染后端。備選項(xiàng)無非幾個GDI、SkiaSharp、SharpDX/Direct2D、OpenGL。SkiaSharp 功能強(qiáng)大跨平臺文字渲染質(zhì)量高但它本身是一個相當(dāng)龐大的圖形庫原生部分加載進(jìn)進(jìn)程就占不少內(nèi)存包裝層也不小。再疊加微軟的字體管理系統(tǒng)和圖像解碼庫內(nèi)核體積很難保持在 200KB 量級。SharpDX/Direct2D 性能更好但它是原生 COM 接口的薄封裝使用難度大對象生命周期管理要非常小心哪怕一個 COM 引用釋放遺漏都可能引發(fā)直接的地址訪問錯誤比如 C# 調(diào)用 C 層時(shí)常見的 access violation c0000005。對于一個小內(nèi)核的項(xiàng)目引入這么厚的底層依賴性價(jià)比不高。XchyUI 最終選擇了 GDI 作為第一代渲染后端。理由很直接它吃內(nèi)存少調(diào)用鏈短C# 里用 System.Drawing 就能穩(wěn)定輸出文字和圖形。雖然 GDI 的渲染性能上限不如 Direct2D但是對于一個界面層操作遠(yuǎn)多于高頻動畫的桌面應(yīng)用來說60fps 的需求是一定滿足得了的——我后面會給出實(shí)測數(shù)據(jù)。提示這里有個常見誤區(qū)。很多人覺得 GDI 慢是因?yàn)槟盟ヤ秩菊敛粩嘧兓母邘视螒虍嬅?。對于普通表單和業(yè)務(wù)界面GDI 的真正瓶頸并不在繪制速度而在無腦整窗重繪。做好局部失效重繪之后性能完全夠用。2.3 消息循環(huán)與事件分發(fā)的最小實(shí)現(xiàn)Windows 應(yīng)用程序的窗口系統(tǒng)是一個消息驅(qū)動模型。鼠標(biāo)點(diǎn)擊、鍵盤輸入、窗口移動、尺寸變化Windows 都會把行為封裝成消息投遞到目標(biāo)窗口的消息隊(duì)列里。你的 UI 框架只要持續(xù)循環(huán)接收這些消息再轉(zhuǎn)成自己的事件就完成了事件分發(fā)。XchyUI 的消息循環(huán)是所有控件的心臟。它的基本結(jié)構(gòu)是一個 while 循環(huán)調(diào)用 Win32 的 GetMessage 取出消息TranslateMessage 做鍵盤按鍵翻譯再 DispatchMessage 把消息交還給窗口過程函數(shù)。窗口過程里XchyUI 收到 WM_PAINT 就觸發(fā)整體重繪收到鼠標(biāo)移動消息就把坐標(biāo)換算后交給命中測試邏輯從而找到這個點(diǎn)落在哪個控件上再把對應(yīng)的鼠標(biāo)事件派發(fā)給它。這里要強(qiáng)調(diào)的是消息循環(huán)和渲染循環(huán)的關(guān)系。XchyUI 并不是拿一個獨(dú)立的死循環(huán)去不斷刷幀。沒有界面變化時(shí)消息循環(huán)會阻塞在 GetMessage 上CPU 占用率幾乎降到零。只有當(dāng)消息到達(dá)、或者某段代碼顯式觸發(fā)重繪時(shí)才走一遍繪制流程。這種做法保證了百分百的省電和安靜也是桌面應(yīng)用該有的基本素養(yǎng)。2.4 布局引擎從坐標(biāo)計(jì)算到 Flex/Stack 布局Electron 里的布局是由 CSS 盒模型計(jì)算的瀏覽器為了一小段樣式要跑完整的計(jì)算鏈。XchyUI 不需要這套東西。我把它設(shè)計(jì)成了一套極簡的測量-安排兩階段布局流程。測量階段每個控件根據(jù)自己的內(nèi)容、字體和尺寸策略計(jì)算出理想大小。安排階段容器控件按照自己的布局規(guī)則把子控件逐個擺放到具體位置。最核心的容器是 StackLayout參數(shù)只有方向垂直或水平和間距Spacing沒有百分比、沒有媒體查詢。另一個是 GridLayout把可用區(qū)域按行和列切分對表格類界面特別實(shí)用。這兩下子看起來樸素的過分但實(shí)際用下來會發(fā)現(xiàn)桌面應(yīng)用 90% 的界面布局就是一行一行往下排加一個二維表格。自研引擎的最大好處就是你可以按照實(shí)際需求去砍功能而不必被通用方案拖累。3. 手把手構(gòu)建 XchyUI 跑道渲染循環(huán)、事件系統(tǒng)與組件封裝3.1 第一個可用的渲染循環(huán)先看一段最核心的代碼。這是 XchyUI 消息循環(huán)和渲染觸發(fā)的骨架去掉了一些邊界處理保留了主干邏輯。public sealed class XchyApplication { private readonly IntPtr _hwnd; private readonly ListControl _rootControls new(); private bool _dirty true; public void Run(Window mainWindow) { _hwnd mainWindow.Handle; mainWindow.Show(); while (true) { if (GetMessage(out var msg, IntPtr.Zero, 0, 0)) { TranslateMessage(ref msg); DispatchMessage(ref msg); } else { break; // 收到 WM_QUIT退出應(yīng)用 } if (_dirty) { RenderFrame(); _dirty false; } } } private void RenderFrame() { var buffer new Bitmap(WindowWidth, WindowHeight); using var g Graphics.FromImage(buffer); g.Clear(_backgroundBrush); // 先布局再繪制 LayoutEngine.Instance.Arrange( _rootControls, new Rect(0, 0, WindowWidth, WindowHeight)); foreach (var control in _rootControls) control.Draw(g); using var screen Graphics.FromHwnd(_hwnd); screen.DrawImageUnscaled(buffer, 0, 0); } }這里用了一個 內(nèi)存位圖 一次性拷貝 的雙緩沖思路。先在內(nèi)存里畫好整幀再一次性拷貝到窗口顯示區(qū)避免用戶看到撕裂的繪制過程。邏輯上整個渲染循環(huán)不就兩件事消息來了處理界面臟了重畫。消息循環(huán)負(fù)責(zé)響應(yīng)動作渲染循環(huán)負(fù)責(zé)呈現(xiàn)結(jié)果二者通過 _dirty 標(biāo)志位解耦不會出現(xiàn)事件處理時(shí)強(qiáng)插一個繪制的混亂局面。3.2 控件樹與命中測試的完整實(shí)現(xiàn)控件樹是 XchyUI 結(jié)構(gòu)上最重要的數(shù)據(jù)結(jié)構(gòu)。每個控件要么是葉子節(jié)點(diǎn)要么是內(nèi)部節(jié)點(diǎn)內(nèi)部節(jié)點(diǎn)負(fù)責(zé)持有子控件集合。結(jié)構(gòu)就是這么簡單。public abstract class Control { public string Name { get; set; } string.Empty; public Rect Bounds { get; set; } public bool Visible { get; set; } true; public bool Enabled { get; set; } true; public Control? Parent { get; internal set; } public ListControl Children { get; } new(); public void Add(Control child) { child.Parent this; Children.Add(child); } public virtual Size Measure() { // 子類根據(jù)內(nèi)容計(jì)算理想尺寸 return new Size(0, 0); } public virtual void Draw(Graphics g) { if (!Visible) return; foreach (var child in Children) child.Draw(g); } public virtual bool HitTest(Point p) { return Visible Enabled Bounds.Contains(p); } public virtual void OnMouseDown(Point location, MouseButton button) { } public virtual void OnMouseUp(Point location, MouseButton button) { } public virtual void OnMouseMove(Point location) { } internal virtual void RaiseMouseDown(Point location, MouseButton button) { // 深度優(yōu)先優(yōu)先把事件交給最后繪制、看起來在上層的子控件 for (var i Children.Count - 1; i 0; i--) { var child Children[i]; if (child.HitTest(location)) { child.RaiseMouseDown(location, button); return; } } OnMouseDown(location, button); } }命中測試的規(guī)則也很直接收到鼠標(biāo)點(diǎn)擊坐標(biāo)后從控件樹的最末端節(jié)點(diǎn)往根節(jié)點(diǎn)走誰的面積覆蓋了這個點(diǎn)就把事件給誰。因?yàn)樽詈罄L制的控件視覺上在最前面所以按子控件列表的倒序去檢查第一個命中的就是用戶真正想點(diǎn)的那個控件。這套機(jī)制雖然樸素但已經(jīng)足夠在按鈕、列表項(xiàng)、樹節(jié)點(diǎn)之間做出正確的事件路由。3.3 組件庫封裝Button、TextBox、List 的設(shè)計(jì)思路有了控件樹和事件路由接下來就是封裝具體控件。以一個最簡單的 Button 為例它需要處理三種視覺狀態(tài)普通、懸停、按下每種狀態(tài)對應(yīng)不同的背景色。繪制時(shí)根據(jù)狀態(tài)填充圓角矩形再居中繪制文字。XchyUI 中按鈕的實(shí)現(xiàn)大概只有 100 行但它完整覆蓋了外觀表現(xiàn)和交互反饋。TextBox 復(fù)雜一些。它要管理插入符位置、支持響應(yīng)鍵盤輸入、處理光標(biāo)閃爍、支持選中區(qū)域的反白顯示。早期版本我直接在控件內(nèi)部用一個普通的 TextBox 成員變量去承接輸入后來發(fā)現(xiàn)這會造成 WinForms 控件的全權(quán)耦合最后改用純 GDI 繪制文本和插入符自己實(shí)現(xiàn)鍵盤字符替換邏輯。這樣既減少了外部依賴也讓控件體積和渲染可控性更好。List 是另一個高頻組件。我最初實(shí)現(xiàn)的是全部可見項(xiàng)逐一繪制的樸素版本。支持 10 個、20 個條目沒問題但條目一旦達(dá)到幾千個逐一繪制就會拖慢每幀速度。最終采用了虛擬化方案只繪制出現(xiàn)在可視區(qū)域內(nèi)的那幾十個條目。這個優(yōu)化屬于 UI 引擎常見的基礎(chǔ)設(shè)計(jì)但對性能的提升是立竿見影的。3.4 局部失效區(qū)域優(yōu)化不做無腦全窗重繪自研引擎最容易被忽視的一個細(xì)節(jié)是哪些區(qū)域需要重繪。一開始我也是最簡單的辦法控件 Event 觸發(fā)任何變化就設(shè) _dirtytrue然后整窗口重畫。這在控件少時(shí)無所謂窗口大了或者控件多了無謂的整窗繪制會直接影響幀率。XchyUI 最終實(shí)現(xiàn)了區(qū)域失效機(jī)制。每個控件維護(hù)一個 IsDirty 標(biāo)記父容器負(fù)責(zé)把子控件的臟區(qū)域合并成一個或多個矩形區(qū)域記錄到 _invalidRegions 集合。RenderFrame 時(shí)只對這些矩形區(qū)域做裁剪繪制最后用 DrawImageUnscaled 配合 Graphics 的 SetClip 把對應(yīng)部分拷貝到窗口上。這樣高頻改動的小控件不會再拖累整個窗口的重繪。提示實(shí)現(xiàn)局部失效的復(fù)雜度會明顯上升因?yàn)椴眉魠^(qū)域、控件交疊、縮放變換都要處理。如果項(xiàng)目第一版趕進(jìn)度建議還是先整窗重繪把功能跑通之后再用特性分支去升級局部失效。性能優(yōu)化永遠(yuǎn)不要發(fā)生在需求還沒穩(wěn)定的階段。4. 性能驗(yàn)證與真實(shí)數(shù)據(jù)怎樣才算秒殺4.1 1000 控件壓力測試的實(shí)測數(shù)據(jù)我拿一個真實(shí)場景做了壓力測試窗體里有 1000 個自定義卡片控件每個卡片包含一個標(biāo)題、一行描述、一個圖標(biāo)區(qū)域。分別測量了靜態(tài)界面無交互時(shí)的幀率、滾動列表時(shí)的事件處理吞吐量、以及內(nèi)存占用。用 XchyUI 跑這套界面靜態(tài)幀率穩(wěn)定在 60fps觸發(fā)滾動和點(diǎn)擊時(shí)幀耗時(shí)幾乎恒定在 14ms 左右CPU 占用率在無交互時(shí)是 0.4% 以下持續(xù)滾動的峰值也只有 15%。同樣的界面我用 Electron 做了一版對照靜態(tài)內(nèi)存大約 260MB高速滾動時(shí)幀率會出現(xiàn)明顯下降到 40fps 以下CPU 峰值可達(dá) 45%。差距的主要來源是 Electron 每一次滾動都要經(jīng)過 DOM 樹更新、樣式重算和瀏覽器合成而 XchyUI 只是在畫布上把卡片新位置繪制一遍。4.2 內(nèi)存與啟動時(shí)間的可復(fù)現(xiàn)測試方法性能對比不能只憑體感要有一套可復(fù)現(xiàn)的測量方法。在 XchyUI 里我做了這樣三個測試步驟任何人都可以直接抄走啟動耗時(shí)從進(jìn)程啟動開始計(jì)時(shí)到主窗口完成第一幀繪制結(jié)束。用 Stopwatch 包裹 Main 函數(shù)入口之后到 Run 函數(shù)進(jìn)入首輪 RenderFrame 完成的位置多次取中位數(shù)。內(nèi)存占用用 GC.GetTotalMemory(false) 做增量測量判斷托管堆增長情況再用 Process.WorkingSet64 觀察進(jìn)程整體的工作集。后者受 .NET 運(yùn)行時(shí)預(yù)熱影響較大最好在運(yùn)行 30 秒、各項(xiàng)功能點(diǎn)過一遍之后再讀數(shù)。滾動流暢度維護(hù)一個固定長度的幀耗時(shí)隊(duì)列在滾動循環(huán)里每次 SwapBuffer 后記錄耗時(shí)統(tǒng)計(jì) P9595 分位值。如果 P95 低于 16ms基本可以認(rèn)定在普通 60Hz 屏幕上是流暢的。按照這套方法實(shí)測下來的結(jié)果前面已經(jīng)列了這里再補(bǔ)一個最有說服力的對比同一個業(yè)務(wù)流程從點(diǎn)擊按鈕到界面完成刷新XchyUI 的平均時(shí)間是 9msElectron 大約是 87ms。這個差異在業(yè)務(wù)界面上直接體感就是秒開和輕微遲滯的區(qū)別。4.3 XchyUI、Electron、WPF 的橫向?qū)φ罩笜?biāo)XchyUIElectronWPFUI 層程序集體積約 200KB瀏覽器內(nèi)核約 150MB框架約 3MB完整安裝包體積約 35MB含 .NET 運(yùn)行時(shí)普遍 150MB~250MB約 50MB 起啟動到首幀時(shí)間0.1~0.2s1.5~3s0.2~0.4s靜態(tài)內(nèi)存占用簡單窗口40~60MB150~300MB80~120MB渲染原理GDI可選后端升級Chromium 合成器DirectX 合成器跨平臺計(jì)劃中三平臺全覆蓋僅 Windows前端生態(tài)可用性無完整極弱這張表格不是為了貶低 Electron 和 WPF而是想說明不同技術(shù)棧的本質(zhì)差異Electron 用一個完整的瀏覽器內(nèi)核來解決通用問題WPF 用一個龐大的框架體系來解決富媒體表現(xiàn)問題而 XchyUI 是定義問題邊界之后做減法的產(chǎn)物。三種方案適合三種不同訴求關(guān)鍵是看清楚你的訴求是什么。4.4 高 DPI、字體渲染、線程調(diào)度等細(xì)節(jié)坑在測試和真實(shí)使用中有幾個細(xì)節(jié)會讓結(jié)果出現(xiàn)劇烈波動必須單獨(dú)說。高 DPI 是第一大坑。如果進(jìn)程沒有正確聲明 DPI 感知Windows 會把你的窗口自動縮放導(dǎo)致所有坐標(biāo)比例錯亂畫面模糊點(diǎn)擊區(qū)域?qū)Σ簧?。我最終把清單里的 dpiAwareness 設(shè)成了 PerMonitorV2再用 QueryDpiAwareness 做運(yùn)行時(shí)檢測。這套處理做完在 125%、150% 縮放環(huán)境下窗口和對齊才是正確的。字體是第二大坑。GDI 的文本渲染在默認(rèn)字體下會有明顯的鋸齒中文尤其容易發(fā)虛。我的經(jīng)驗(yàn)是優(yōu)先使用微軟雅黑并開啟 TextRenderingHint.ClearTypeGridFit同時(shí)對字體做一次 Fallback 鏈——微軟雅黑 → 宋體 → 系統(tǒng)默認(rèn)字體。這樣即便目標(biāo)機(jī)器沒有安裝微軟雅黑中文也不會變成方塊。線程調(diào)度是第三大坑。所有 UI 相關(guān)的繪制和控件屬性更新必須發(fā)生在創(chuàng)建窗口的同一個線程上。如果在后臺線程直接改控件坐標(biāo)或者觸發(fā)重繪輕則閃爍重則直接崩潰典型的 access violation c0000005 就是這么來的C# 層訪問了已被釋放的 GDI 對象。XchyUI 內(nèi)部做了一個簡單的 Dispatcher 封裝所有外部更新請求統(tǒng)一通過 PostMessage 投遞到 UI 線程執(zhí)行。5. 實(shí)戰(zhàn)記錄從 Web 套殼遷移到 XchyUI 的完整過程5.1 遷移前的架構(gòu)評估與組件盤點(diǎn)如果你現(xiàn)在也想做類似的遷移第一個建議是不要急著寫代碼先盤需求。我把原有應(yīng)用里的界面元素逐個列成清單按鈕、輸入框、下拉框、表格、樹、彈窗、消息條、自定義繪圖面板、右鍵菜單。然后逐個評估XchyUI 現(xiàn)成有沒有、需要新寫、需要改設(shè)計(jì)。最終結(jié)論是 60% 的控件可以直接復(fù)用25% 需要少量定制15% 需要重寫思路。這個評估過程還有個額外收益它會逼著你去砍那些看起來挺炫但沒人用的界面裝飾。脫離 Web 生態(tài)后很多花里胡哨的動效自然就不做了產(chǎn)品反而更聚焦。另一個重要決策是數(shù)據(jù)綁定。Web 套殼的前端框架都有響應(yīng)式綁定XchyUI 一開始沒有設(shè)計(jì)這套東西。我的過渡方案是控件數(shù)據(jù)源 刷新接口每個復(fù)雜控件持有一個數(shù)據(jù)源列表數(shù)據(jù)變化時(shí)調(diào)用控件的 Refresh()控件在內(nèi)部重新讀取數(shù)據(jù)并標(biāo)記臟區(qū)域。這個模式寫起來比響應(yīng)式綁定繁瑣但邏輯鏈路很短排查問題很容易。數(shù)據(jù)頻率不高的場景下這種寫法完全夠了。數(shù)據(jù)綁定決策還影響了一個核心數(shù)據(jù)結(jié)構(gòu)。從 Web 套殼遷移到一個內(nèi)聚框架最大的區(qū)別就是所有狀態(tài)有且僅有一個權(quán)威來源。Web 時(shí)代可能 Model 一套、DOM 一套、狀態(tài)管理再存一份XchyUI 只認(rèn) C# 對象里的字段。別小看這個約束它直接解決了大量數(shù)據(jù)不同步的舊 Bug。5.2 自定義主題系統(tǒng)與樣式處理Web 套殼里改樣式是頻率很高的操作。自研引擎如果讓每個控件把顏色、字體寫死團(tuán)隊(duì)迭代起來會非常痛苦。我做了一個極簡主題系統(tǒng)主題是一個 Theme 對象里面有背景色、前景色、邊框色、按鈕不同狀態(tài)的顏色、字體名稱和尺寸、間距常量等若干字段。所有控件在繪制時(shí)只從當(dāng)前主題讀取顏色不硬編碼。切換主題只需要換一個 Theme 實(shí)例然后全窗標(biāo)記重繪。因?yàn)?GDI 里繪制矩形和文字的成本極低哪怕是整窗重繪也能在幾毫秒內(nèi)完成主題切換這個平時(shí)最容易卡出掉幀的操作反而成了 XchyUI 最具表現(xiàn)力的功能之一。5.3 常見問題排查速查表現(xiàn)象可能原因排查思路與解決動作窗口渲染為空白重繪時(shí)機(jī)被漏掉WM_PAINT 沒有觸發(fā)布爾標(biāo)記檢查 Invalidate 是否真的調(diào)用了確認(rèn)渲染代碼是否在 UI 線程執(zhí)行點(diǎn)擊控件沒有反應(yīng)消息循環(huán)被阻塞或者命中測試順序錯誤檢查事件處理里是否有 Sleep/耗時(shí)操作打印鼠標(biāo)坐標(biāo)和控件 Bounds 對比文字發(fā)虛、有鋸齒GDI 默認(rèn)渲染模式不對設(shè)置 Graphics.TextRenderingHint ClearTypeGridFit中文顯示方塊字體 Fallback 缺失配置字體鏈優(yōu)先用系統(tǒng)自帶的微軟雅黑高 DPI 下坐標(biāo)全亂進(jìn)程沒聲明 DPI 感知修改 manifest 設(shè)置 PerMonitorV2并動態(tài)查詢 DPI內(nèi)存緩慢上漲每次繪制創(chuàng)建了 Bitmap 未釋放或者事件沒有解綁用 Dispose 模式管理 Bitmap檢查控件樹移除時(shí)是否清理事件引用后臺線程 Crash跨線程操作 UI 控件統(tǒng)一走 Dispatcher不要直接訪問控件屬性5.4 打包發(fā)布與裁剪策略XchyUI 項(xiàng)目的目標(biāo)是小打包環(huán)節(jié)也要堅(jiān)持這個思路。首先確保所有用不到的程序集不進(jìn)發(fā)布目錄。然后使用 .NET 的 single-file publish 把所有托管程序集打成一個文件這是最直觀的體積削減。之后經(jīng)過 ILLink 裁剪把沒有被引用的框架代碼從最后的產(chǎn)物里移除。這里有個值得注意的細(xì)節(jié)ILLink 裁剪雖然能縮小體積但它對反射破壞非常敏感。如果代碼里用了 Type.GetType 或者反射調(diào)用必須給對應(yīng)的程序集標(biāo)記 DynamicDependency否則運(yùn)行時(shí)會直接 TypeNotFound。我在 XchyUI 的早期版本就踩過這個坑上線測試時(shí)控件創(chuàng)建報(bào)了一大堆反射錯誤最后是把加載邏輯改成顯式注冊表才繞開反射機(jī)制的不確定性。發(fā)布時(shí)還要保留 PDB 文件。自研引擎沒有成熟的崩潰上報(bào)體系如果你連符號文件都沒有用戶那邊報(bào)一個 access violation 你根本沒法定位。PDB 加上 Windows 事件日志里捕獲到的異常堆棧是排查崩潰類問題最重要的兩張底牌。6. 下一步值得探索的方向6.1 跨平臺與國產(chǎn)化適配XchyUI 目前以 Windows 為主但架構(gòu)上沒有把非 Windows 的路堵死。核心的控件樹、布局引擎、事件路由邏輯全部用純 C# 實(shí)現(xiàn)不依賴任何 Windows 程序集。只有最底層的創(chuàng)建窗口 消息循環(huán) 圖形上下文這一層與平臺相關(guān)我把它隔離成了 IPlatformBackend 接口。如果后續(xù)要支持 Linux可以在 XLib/Wayland 上實(shí)現(xiàn)這個接口macOS 則走 Cocoa國產(chǎn)化環(huán)境的難點(diǎn)主要在 CPU 架構(gòu)而非操作系統(tǒng)——大部分國產(chǎn)系統(tǒng)本身就是 Linux 內(nèi)核但指令集可能是 ARM 或者龍芯的 LoongArch。.NET 官方已經(jīng)支持多種架構(gòu)的 Linux 發(fā)布理論上只要 IPlatformBackend 的接口實(shí)現(xiàn)能正常編譯整套 UI 引擎就能在這些平臺上跑起來。這條路我還沒有完整走通現(xiàn)階段只能算一個方向但它讓 XchyUI 擁有一個比 Electron 輕量得多的跨平臺想象空間。6.2 渲染后端升級路線SkiaSharp、SharpDX 都只是備選GDI 作為第一代渲染后端確實(shí)簡單穩(wěn)定但它的抗鋸齒質(zhì)量、圖形變換能力、復(fù)雜路徑填充效果都存在上限。后續(xù)如果要支持更細(xì)膩的圓角陰影、漸變、變換動畫就需要考慮更強(qiáng)大的渲染后端。我的規(guī)劃不是立刻替換而是先把渲染層抽象成 ICanvas 接口GDI 只是其中一個實(shí)現(xiàn)。然后可以逐步添加 SkiaSharpCanvas、SharpDXCanvas 這些實(shí)現(xiàn)并且針對不同后端去做性能對比。這里的關(guān)鍵是渲染后端可以換但控件樹結(jié)構(gòu)、布局引擎、事件系統(tǒng)絕不能因?yàn)閾Q后端而重寫。接口隔離的意義就在于讓變化局限在最小范圍內(nèi)。注意追加渲染后端要考慮的不僅是代碼工作量還有體量變化。SkiaSharp 的原生庫會拉高內(nèi)核體積SharpDX 的 COM 對象生命周期也要投入不少精力。收益與代價(jià)需要反復(fù)權(quán)衡別為了營造技術(shù)很牛的感覺去堆疊依賴。6.3 開源計(jì)劃與社區(qū)共建XchyUI 現(xiàn)在處于自用順手、開源需整理的狀態(tài)。如果要開源許可證我會選 MIT 或者 Apache-2.0并且會整理出三類倉庫內(nèi)容核心引擎、組件庫、示例模板。社區(qū)共建的價(jià)值在于可以讓更多從業(yè)者幫忙補(bǔ)齊真實(shí)場景里的邊界情況——不同輸入法、不同顯卡驅(qū)動、不同企業(yè)安全軟件的兼容性這些問題永遠(yuǎn)只能靠足夠多的真實(shí)場景暴露出來。我還沒有確定開源的具體時(shí)間表但可以確定的是即使不開源我也會持續(xù)把 XchyUI 用于自己的實(shí)際項(xiàng)目讓它保持小而鋒利的特點(diǎn)而不是膨脹成一個誰都不需要的通用框架。最后分享一點(diǎn)個人體會。整個遷移過程中我最深的感受不是Electron 不好而是技術(shù)選型要對齊真實(shí)約束。如果你的產(chǎn)品身處資源受限環(huán)境或者用戶對啟動速度和內(nèi)存占用極其敏感那 Electron 這套技術(shù)棧的底層代價(jià)就會壓得你很難受。自研引擎的價(jià)值不在于標(biāo)榜我不用 Electron而在于它逼著你去理解 UI 是怎么工作的——一個按鈕從點(diǎn)擊到屏幕反饋經(jīng)歷哪些環(huán)節(jié)、一次滾動如何保證不卡、一個窗體如何做到秒開。這些理解在任何技術(shù)棧里都不會浪費(fèi)。不要被性能焦慮綁架更不要被工具路徑綁架——輕量自有輕量的價(jià)值。