1. 為什么我會開始認(rèn)真思考 diagram-design 這件事先坦白一個背景我做的很多項目都需要畫圖——架構(gòu)圖、流程圖、時序圖、拓?fù)鋱D、ER 圖不一而足。早年沒太把這件事當(dāng)回事腦子里有個大概就開始堆代碼今天用某個在線工具拖一拖明天用另外一款軟件補一補后天發(fā)現(xiàn)某個模塊邏輯盤不清干脆 PPT 畫個示意就丟給下游。結(jié)果就是圖與圖之間風(fēng)格混亂、坐標(biāo)系不統(tǒng)一、數(shù)據(jù)模型對不上一個圖換一個人維護就徹底沒法看了。后來做了一個以“圖”為核心的跨平臺系統(tǒng)才真正把 diagram design 當(dāng)作一個嚴(yán)肅工程問題來看待。diagram-design 這個標(biāo)題表面看是“圖表設(shè)計”但做過的朋友應(yīng)該都能感受得到真正難的從來不是“畫圖”這個動作而是怎么把業(yè)務(wù)結(jié)構(gòu)拆解成節(jié)點、邊、分組、布局和交互這套模型再在這套模型之上做出可擴展、可維護、性能還過得去的渲染方案。畫一個靜態(tài)圖誰都會畫一套可以編輯、自動布局、實時聯(lián)動、支持大數(shù)據(jù)量的圖形系統(tǒng)那就是另一回事了。這篇內(nèi)容適合誰如果你正在做可視化編輯器、流程圖引擎、拓?fù)鋱D平臺、數(shù)據(jù)血緣圖或者只是被“項目里上百個圖形節(jié)點怎么管理”這件事折磨這篇文章應(yīng)該能提供一個從我有思路到落到工程實現(xiàn)的完整剖面。我會聊技術(shù)選型、數(shù)據(jù)建模、布局算法、交互與渲染的取舍也會把我在實際項目里踩過的一些坑直接攤開來講。不會有太多玄學(xué)盡量每一個結(jié)論都能對應(yīng)到實際代碼和真實場景。2. 先用一張“圖”拆解 diagram-design 的問題域很多人拿到“做一個圖表設(shè)計系統(tǒng)”的需求第一反應(yīng)是去找渲染庫這是順序錯了。渲染是整個鏈路里最末端的東西前面還有數(shù)據(jù)模型、布局邏輯和交互協(xié)議。如果這三層不先想明白哪怕選了再強的渲染引擎后面也會被各種臨時需求扯得七零八落。2.1 圖的本質(zhì)節(jié)點、邊、端口、分組與畫布把任意一張圖拆到底核心元素就這兩類節(jié)點和邊。但真實業(yè)務(wù)里光有這兩類遠遠不夠。以流程圖為例節(jié)點可能是“開始”“結(jié)束”“處理步驟”“判斷分支”邊是帶方向的箭頭但判斷分支的邊上得帶標(biāo)簽比如“是”和“否”。以網(wǎng)絡(luò)拓?fù)鋱D為例節(jié)點是服務(wù)器和交換機邊是鏈路但鏈路上可能有多條虛擬連接連線的語義遠比箭頭復(fù)雜。以 ER 圖為例節(jié)點是實體表邊是關(guān)系但關(guān)系有一對多、多對多之分邊上還需要標(biāo)注主外鍵字段。所以在設(shè)計數(shù)據(jù)模型的時候我建議一開始就把這幾類基礎(chǔ)設(shè)施建好節(jié)點Node坐標(biāo)、尺寸、類型、樣式、業(yè)務(wù)數(shù)據(jù)掛載點。端口Port節(jié)點上用于連線的錨點決定連線從哪個位置引出。邊Edge源端口與目標(biāo)端口、路徑點、箭頭樣式、線型、標(biāo)簽。分組Group用于表達容器關(guān)系比如泳道、子圖、分組框。畫布Canvas全局變換信息、縮放比例、可視區(qū)域、網(wǎng)格設(shè)置。如果項目里一開始就接受“邊只連接節(jié)點、不連接端口”這種簡化模型后面做節(jié)點拖動、邊跟隨、錨點吸附時會付出大量返工成本。我的經(jīng)驗是寧可第一版把端口模型做上去哪怕界面層暫時隱藏端口也比后續(xù)硬塞進一個不支持的模型要省力得多。2.2 從“畫一張圖”到“圖系統(tǒng)”跨度在哪里“畫一張圖”是單次行為畫完就結(jié)束信息不流動。而圖系統(tǒng)要考慮的是持續(xù)的編輯、序列化、數(shù)據(jù)驅(qū)動更新、多人協(xié)作甚至版本管理。這里有一個容易被低估的復(fù)雜度來源圖的序列化格式。如果只是想畫個靜態(tài)效果把節(jié)點坐標(biāo)和邊路徑直接寫進 JSON 就夠了。可一旦引入自動布局坐標(biāo)就成了派生數(shù)據(jù)而不是源數(shù)據(jù)——你存的是圖的拓?fù)浣Y(jié)構(gòu)坐標(biāo)是布局引擎算出來的。這時候若還把坐標(biāo)當(dāng)成第一公民寫死自動布局和手動調(diào)整之間就會天天打架。我后來采用的方案是源數(shù)據(jù)只保存節(jié)點、邊、端口的連接關(guān)系和業(yè)務(wù)字段坐標(biāo)則作為一個可選的“用戶覆蓋層”保存。布局引擎產(chǎn)出的坐標(biāo)寫入覆蓋層手動微調(diào)也寫入覆蓋層而拓?fù)浔旧硎冀K是干凈的結(jié)構(gòu)化數(shù)據(jù)。這套設(shè)計的直接收益是后續(xù)加新布局算法、做子圖復(fù)用、做圖形模板都不需要動根基。3. 技術(shù)選型的底層邏輯老牌庫就一定省心嗎圖表領(lǐng)域可選的技術(shù)棧其實不多但每個方案都各有各的脾氣。我把主流路線梳理了一遍重點不是“誰最強”而是“誰更適合作為自研圖系統(tǒng)的基礎(chǔ)”。3.1 三條主流路線的對比市面上做 diagram 相關(guān)工具底層渲染路線大抵分三類一是基于 SVG 的方案。代表庫包括老牌的 Raphael 和后來的一些封裝庫。SVG 的優(yōu)點在于 DOM 集成度高事件處理天然樣式可以用 CSS 控制做小型和中型圖非常順手。缺點是節(jié)點數(shù)量一旦上千DOM 節(jié)點數(shù)量會成為明顯的性能瓶頸拖拽縮放時也會感覺跟手度不夠。二是基于 Canvas 的方案。一次繪制、整體渲染性能上限比 SVG 高很多適合節(jié)點數(shù)多、交互相對簡單的場景比如純展示類拓?fù)?。缺點是事件命中檢測要自己做文字換行、樣式定制都得模擬一套 UI 體系開發(fā)成本明顯上去了。三是基于 WebGL 的方案。這是真正的重型武器性能天花板最高能做海量節(jié)點和復(fù)雜動效但開發(fā)門檻也最高普通圖系統(tǒng)上屬于殺雞用牛刀。如果項目里沒有“幾萬個節(jié)點還要流暢漫游”這類極端需求建議不要一上來就碰。3.2 我最終確定的自研組合開頭提到的那個跨平臺系統(tǒng)節(jié)點規(guī)模常規(guī)在幾百到幾千這個區(qū)間同時要求支持用戶交互編輯、拖拽、縮放、框選還要能導(dǎo)入導(dǎo)出多種格式。我最后選的技術(shù)組合是基于 SVG 自研核心渲染引擎配合虛擬化渲染思路來做性能兜底。一句話總結(jié)就是先選對工具車再考慮給車上裝什么樣的引擎。為什么不是 Canvas因為在編輯型圖系統(tǒng)里“精細到每個節(jié)點、每條邊的交互”是核心訴求。SVG 天然就有獨立 DOM 節(jié)點來做事件綁定框選、拖拽、命中檢測這些都順手很多。Canvas 要自己實現(xiàn)的交互層工作量幾乎是 SVG 方案的兩三倍。為什么不是直接套某個大而全的現(xiàn)成庫因為這個項目需要深度定制自定義節(jié)點形狀、自定義端口規(guī)則、自定義自動布局算法、特定的數(shù)據(jù)格式對接。成熟商業(yè)庫的封裝層再厚到了這一步也會成為障礙。與其花大力氣繞開別人的封裝不如在底層之上只保留少量惰性封裝。補充一個表方便你看對比方案交互開發(fā)成本性能上限定制自由度適合場景純 SVG 自研低中配合優(yōu)化手段可提升高中量級編輯型圖系統(tǒng)Canvas 自研高高高展示型、超大量節(jié)點現(xiàn)成 Vue/React 圖庫低中低快速交付、標(biāo)準(zhǔn)圖型WebGL 自研很高極高很高極端大規(guī)模場景這套選型落地的過程中我也有一些心得不要追求“一步到位的全能力框架”先做一個只支持有限節(jié)點類型、有限交互的版本跑通鏈路再逐步開放能力。圖表系統(tǒng)的復(fù)雜度是螺旋上升的最怕一開始就引入大量抽象概念結(jié)果自己先被抽象困住了。4. 數(shù)據(jù)模型先行如何把業(yè)務(wù)“翻譯”成圖結(jié)構(gòu)選定技術(shù)棧之后我做的第一件事不是畫界面而是定數(shù)據(jù)模型。這個階段多花一周后面少花一個月。4.1 核心實體的最小字段集我把最初的 TypeScript 類型定義精簡成下面這個層次這是整個系統(tǒng)最關(guān)鍵的代碼片段沒有之一interface DiagramNode { id: string; type: string; // 節(jié)點類型如 process, start, end x: number; y: number; width: number; height: number; ports: Port[]; // 端口列表 data: Recordstring, any; // 業(yè)務(wù)數(shù)據(jù)掛載點 groupId?: string; // 所屬分組 } interface Port { id: string; nodeId: string; side: top | right | bottom | left; // 所在方位 index?: number; // 同一側(cè)多個端口時的順序 } interface Edge { id: string; source: PortRef; // { nodeId, portId } target: PortRef; points?: Point[]; // 經(jīng)過的關(guān)鍵路徑點 label?: string; style?: EdgeStyle; }這里有兩個容易被忽視的設(shè)計點第一個是Port獨立成實體。連線不是“從這個節(jié)點中心到那個節(jié)點中心”而是“從某節(jié)點的一個端口到另一節(jié)點的一個端口”。在這個模型下節(jié)點拖走時邊的端點能自動跟隨到正確位置多端口節(jié)點也能區(qū)分“這根線究竟連哪個插孔”。第二個是節(jié)點的data字段它專門用來掛載業(yè)務(wù)數(shù)據(jù)。圖系統(tǒng)本身不關(guān)心業(yè)務(wù)字段是啥但交互層、校驗層、后端同步層都需要一個統(tǒng)一入口來讀寫。把業(yè)務(wù)數(shù)據(jù)和圖形數(shù)據(jù)混在一個平級字段里短期省事長期必亂。4.2 序列化格式的版本兼容設(shè)計圖數(shù)據(jù)一定會經(jīng)歷版本迭代。今天你的圖里有節(jié)點、邊、端口明天可能就要加“子圖”或者“泳道”后天可能又要加“聚合節(jié)點”。如果在序列化結(jié)構(gòu)里不做版本字段和兼容策略老數(shù)據(jù)怎么遷移將成為一個大麻煩。我用的做法是給所有持久化數(shù)據(jù)加一個schemaVersion字段同時維護一個遷移函數(shù)鏈。每次數(shù)據(jù)結(jié)構(gòu)變化就新增一個遷移函數(shù)而不是直接改舊數(shù)據(jù)的讀取邏輯。加載時如果發(fā)現(xiàn)版本號低于當(dāng)前版本就依次執(zhí)行遷移函數(shù)把舊數(shù)據(jù)升級到最新格式。這套思路其實就是軟件工程里的數(shù)據(jù)庫遷移思路搬到前端圖數(shù)據(jù)上一樣適用。具體遷移函數(shù)示例const migrations: Recordnumber, (oldData: any) any { 1: (data) { // 版本1升級到版本2為每個節(jié)點補充空數(shù)組 ports return { ...data, nodes: data.nodes.map((n: any) ({ ...n, ports: [], groupId: undefined })) }; }, 2: (data) { // 版本2升級到版本3edge 從 node 引用改為 port 引用 return { ...data, edges: data.edges.map((e: any) ({ ...e, source: { nodeId: e.source, portId: e.sourcePort }, target: { nodeId: e.target, portId: e.targetPort } })) }; } }; function upgrade(data: any): any { let current data; while (current.schemaVersion LATEST_VERSION) { const next current.schemaVersion 1; current migrations[next](current); current.schemaVersion next; } return current; }如果沒有這套機制第一版上線后一改數(shù)據(jù)格式用戶手里的圖就打不開了那是災(zāi)難級事故。我現(xiàn)在對這個事情敏感度很高凡是能持久化的結(jié)構(gòu)必須有版本標(biāo)識、必須有遷移路徑、必須有新舊兼容的至少一個迭代容錯周期。4.3 業(yè)務(wù)語義與視覺表達的邊界圖系統(tǒng)里最容易出問題的地方是把視覺表達直接當(dāng)成業(yè)務(wù)語義存儲。比如說某個節(jié)點在業(yè)務(wù)上屬于“已下線”狀態(tài)你可能會想給它渲染成灰色然后在數(shù)據(jù)模型里也記一個color: gray。短期看著沒問題可一旦業(yè)務(wù)規(guī)則變成“已下線”要顯示成紅色你就得去改全量數(shù)據(jù)而不是只改一套配置。我的做法是數(shù)據(jù)模型里存穩(wěn)定的業(yè)務(wù)狀態(tài)字段比如status: online | offline視覺層統(tǒng)一維護一份“狀態(tài)到樣式的映射表”。當(dāng)多個節(jié)點共用同一種視覺規(guī)則時把樣式注冊成可復(fù)用的主題規(guī)則而不是散布在各節(jié)點數(shù)據(jù)里。用一句話概括就是數(shù)據(jù)存事實樣式存映射規(guī)則集中在主題層。這個原則同樣適用于邊的類型。業(yè)務(wù)里的“依賴關(guān)系”和“調(diào)用關(guān)系”在圖上可能只是顏色和線型不同但在數(shù)據(jù)模型里必須是兩個不同的edgeType。如果只依賴顏色區(qū)分后續(xù)做數(shù)據(jù)導(dǎo)出、權(quán)限控制、語義分析的時候就會缺失關(guān)鍵信息。5. 自動布局決定圖表可讀性的隱藏引擎如果說數(shù)據(jù)模型是圖系統(tǒng)的骨架那自動布局就是它的神經(jīng)系統(tǒng)。理想的布局算法能把一團亂麻的拓?fù)渥詣诱沓扇祟愰喿x時覺得“順眼”的結(jié)構(gòu)。順眼是個主觀感受但底層規(guī)律其實非常穩(wěn)定減少交叉邊、保持層級方向一致、同類節(jié)點對齊、連線盡量短。5.1 分層布局、力導(dǎo)向布局和正交布局的應(yīng)用邊界目前開源的布局算法核心就那幾類選錯了應(yīng)用場景體驗會斷崖式下跌。分層布局的核心思路是先對圖做拓?fù)渑判虬压?jié)點按層級排開再在每一層內(nèi)部調(diào)整順序以降低邊交叉。流程圖、狀態(tài)機、依賴關(guān)系圖都適合分層布局因為它天然有“從上往下、從左往右”的閱讀方向感。實際項目里大多數(shù)業(yè)務(wù)圖的默認(rèn)布局我都會優(yōu)先考慮分層布局。力導(dǎo)向布局模擬的是物理模型節(jié)點之間互相排斥、邊就像彈簧互相拉引迭代若干次后達到穩(wěn)定狀態(tài)。這種布局適合沒有明確方向感的圖比如社交網(wǎng)絡(luò)關(guān)系、系統(tǒng)模塊親密度圖。優(yōu)點是不需要對圖做任何結(jié)構(gòu)假設(shè)缺點是結(jié)果帶有隨機性同一個圖布局兩遍節(jié)點位置可能完全不一樣。對經(jīng)常需要“復(fù)現(xiàn)同樣視覺效果”的場景這是個大忌。正交布局則更貼近電路圖和建筑平面圖的風(fēng)格所有線段都走水平或垂直方向折彎處用直角。ER 圖、微服務(wù)調(diào)用鏈這種強調(diào)連線清晰度的場景正交布局非常有用不過代價是路徑計算的復(fù)雜度明顯更高。實際項目中我一般這樣分配有天然層級關(guān)系的用分層布局不分層但強調(diào)聚類關(guān)系的用力導(dǎo)向需要嚴(yán)謹(jǐn)連線的圖允許用戶在自動布局之后手動微調(diào)路徑點而不是強行全自動。5.2 我基于 dagre 的二次封裝與定制業(yè)界做分層布局dagre 是個繞不開的庫。它實現(xiàn)的是經(jīng)典的 Sugiyama 分層算法框架輸入一個圖結(jié)構(gòu)輸出帶坐標(biāo)的布局結(jié)果。但直接用 dagre 做業(yè)務(wù)系統(tǒng)還是有幾個很別扭的地方。第一個問題dagre 不知道你的節(jié)點尺寸它默認(rèn)把節(jié)點當(dāng)成等寬高的矩形。真實場景中節(jié)點寬度差異很大有的節(jié)點要放圖標(biāo)有的節(jié)點是一大段文本。所以我在封裝時做了一步“先按默認(rèn)尺寸布局再按實際尺寸調(diào)整層級內(nèi)對齊”大致思路如下function layeredLayout(graph: GraphModel, options: LayoutOptions) { // 第一遍預(yù)估尺寸跑 dagre 拿到相對層級與順序 const preliminary dagre.graphlib.Graph(); preliminary.setGraph({ rankdir: options.rankdir }); graph.nodes.forEach(node { preliminary.setNode(node.id, { width: node.width || DEFAULT_WIDTH, height: node.height || DEFAULT_HEIGHT }); }); graph.edges.forEach(edge { preliminary.setEdge(edge.source.nodeId, edge.target.nodeId); }); dagre.layout(preliminary); // 第二遍按實際尺寸做層內(nèi)對齊兼顧同一層節(jié)點的中心線對齊 const layers groupByRank(preliminary, graph); const result: Recordstring, { x: number; y: number } {}; layers.forEach((layer, layerIndex) { const maxHeight Math.max(...layer.map(n graph.node(n).height)); layer.forEach((nodeId, index) { const node graph.node(nodeId); result[nodeId] { x: layerOffset(nodeId, index, layers), y: layerIndex * (maxHeight options.levelGap) }; }); }); return result; }第二個問題dagre 輸出的布局沒有考慮端口方位。它默認(rèn)邊從節(jié)點中心連到節(jié)點中心可真實圖上連線應(yīng)該有明確的出口和入口方向。我的做法是在布局階段先以節(jié)點中心坐標(biāo)做整體排布排完后再根據(jù)邊的相對方位自動推導(dǎo)端口方向這樣既保留了 dagre 的整體結(jié)構(gòu)穩(wěn)定性又讓局部的連線看起來更自然。第三個讓我折騰了一陣的問題節(jié)點寬度差異導(dǎo)致同層節(jié)點參差不齊。比如同一層的三個節(jié)點一個 300px 寬兩個 120px 寬如果只是簡單地把它們擠在一行大節(jié)點會頂著左右兩邊小節(jié)點周圍留出大片空白。最終我采用“層內(nèi)網(wǎng)格居中”策略把每層寬度統(tǒng)一拉伸到該層最大節(jié)點的寬度小節(jié)點在該列內(nèi)水平居中。視覺效果會整齊很多。5.3 布局重計算的觸發(fā)策略布局算法有個常見的性能陷阱用戶只是拖動了某一個節(jié)點整個圖都重新布局了一遍。這會讓用戶感覺到“圖不聽話”因為非被拖動的節(jié)點也亂跳了。我調(diào)參后的觸發(fā)策略是節(jié)點拖動過程中只更新被拖動節(jié)點及其直接相連邊的路徑不做全局重排。節(jié)點拖動結(jié)束標(biāo)記該節(jié)點坐標(biāo)為用戶覆蓋后續(xù)自動布局跳過它。手動觸發(fā)自動布局比如點擊“重新布局”按鈕執(zhí)行全圖重排此時清除所有手動覆蓋信息。圖結(jié)構(gòu)變化新增/刪除節(jié)點、邊以增量方式打補丁優(yōu)先保持已有節(jié)點位置不變讓新節(jié)點在旁邊“長出來”只有在結(jié)構(gòu)變化比例過大時才主動做全量重排。這套策略的核心思想是自動布局要尊重用戶的每一次手動調(diào)整只有在用戶明確要求時才能大動干戈。否則光是一個“拖完節(jié)點又彈回去”的問題就能把用戶逼瘋。6. 交互與渲染的細節(jié)工程拖拽、縮放與路徑重算圖和普通 UI 組件最大的不同在于它面對的是一塊無邊際的虛擬畫布。所有交互計算都要在圖坐標(biāo)和屏幕坐標(biāo)之間做轉(zhuǎn)換這就是整個交互層的數(shù)學(xué)地基。6.1 坐標(biāo)變換與縮放系數(shù)管理假設(shè)畫布有一個全局變換縮放系數(shù)scale平移偏移量tx、ty。那么屏幕坐標(biāo)和邏輯坐標(biāo)之間的換算關(guān)系就是screenX logicX * scale tx screenY logicY * scale ty反推邏輯坐標(biāo)logicX (screenX - tx) / scale logicY (screenY - ty) / scale這套公式本身不復(fù)雜但工程上有幾個細節(jié)容易出問題。第一個是鼠標(biāo)滾輪縮放的中心點。如果鼠標(biāo)停在畫布某處滾輪縮放之后鼠標(biāo)下的那個邏輯坐標(biāo)點應(yīng)該在屏幕位置保持不變。很多初版實現(xiàn)都沒做這個校正結(jié)果就是縮放時圖總是往左上角縮或者上下左右亂飄。校正公式是把光標(biāo)處的邏輯坐標(biāo)作為錨點先換算縮放前后的偏移量差再補償?shù)絫x、ty上。第二個是編輯狀態(tài)下的坐標(biāo)精度。當(dāng)縮放系數(shù)特別大比如放大到 200%同一個邏輯坐標(biāo)在不同幀之間小數(shù)位抖動會導(dǎo)致節(jié)點邊緣不停閃爍。我的做法是渲染層統(tǒng)一用整數(shù)化的邏輯坐標(biāo)避免累積誤差。6.2 連線路徑的自動規(guī)避與折線計算邊是圖系統(tǒng)中最“難畫”的元素因為它的路徑點需要繞過節(jié)點還需要在方向變化處畫成直角折線。直角折線計算的標(biāo)準(zhǔn)思路是如果源端口和目標(biāo)端口在同一水平線就走一段水平線如果不在就要先出端口方向一段“引出線”再走正交線段連接。我用的是簡化版 A* 尋路算法作用范圍限制在包圍盒所在的局部區(qū)域。具體來說網(wǎng)格化源節(jié)點到目標(biāo)節(jié)點之間的矩形區(qū)域把其他節(jié)點當(dāng)成障礙物搜索一條從源端口到目標(biāo)端口的最短正交路徑。這個算法對少數(shù)連線場景表現(xiàn)很好但連線一旦密集比如上百條每根線都做獨立尋路會產(chǎn)生大量重疊和交叉這也是正交布局在復(fù)雜場景下比較難解決的問題。我采取的妥協(xié)方案是自動計算完路徑后再做一次基于熵的路徑平滑把共線的線路合并交叉情況用曲線過渡簡化視覺噪聲。效果上自動連線的“粗糙感”會明顯減輕雖然沒法做到完全零交叉但在千級節(jié)點規(guī)模的系統(tǒng)里已經(jīng)夠用。6.3 選中的反饋與編輯器的撤銷/重做圖編輯器里用戶對“選中”的反饋非常敏感。節(jié)點選中時會出現(xiàn)選中框邊選中時會出現(xiàn)路徑錨點同一時間可以框選多個對象。這個交互層其實藏著一個大坑撤銷/重做棧。圖編輯的撤銷和文本編輯的撤銷復(fù)雜度完全不在一個量級。光是把一個節(jié)點從 A 點拖到 B 點中間會經(jīng)過幾十次鼠標(biāo)移動事件如果不做合并撤銷棧會被幾十條“位置微調(diào)”記錄撐爆用戶按一次撤銷只能回退 1 像素體驗極其糟糕。我后來實現(xiàn)的是“命令模式 操作批次合并”連續(xù)同類型的變更比如連續(xù)拖拽、連續(xù)縮放、連續(xù)框選移動合并成一個撤銷記錄每次交互結(jié)束后才 push 進撤銷棧。像這樣class CommandStack { private stack: Command[] []; private batch: Command[] | null null; beginBatch() { this.batch []; } push(command: Command) { if (this.batch) { this.batch.push(command); } else { this.stack.push(command); } } endBatch() { if (this.batch this.batch.length 0) { this.stack.push(this.batch); } this.batch null; } undo() { const cmd this.stack.pop(); if (Array.isArray(cmd)) { cmd.reverse().forEach(c c.undo()); } else if (cmd) { cmd.undo(); } } }每次鼠標(biāo)按下時beginBatch()鼠標(biāo)松開時endBatch()整個拖拽過程只留下一個可撤銷步驟用戶按 CtrlZ 時能夠一次回到拖拽前狀態(tài)。這個設(shè)計雖然代碼行數(shù)不多但對編輯類工具的使用體驗提升是立竿見影的。7. 性能優(yōu)化的實戰(zhàn)路徑當(dāng)棱角開始穿透 SVG 的天花板SVG 的上限在幾千個節(jié)點時就會開始顯形這個數(shù)字聽起來好像很夠用可真到了流程圖編輯場景一個主節(jié)點掛幾十個子節(jié)點再疊加編輯緩存和歷史記錄內(nèi)存占用很快會飆升。我經(jīng)歷過的性能拐點很明確節(jié)點數(shù)上到 2000 左右拖拽開始卡5000 左右直接沒法互動。所以性能優(yōu)化不是可選項是必選項。7.1 可視區(qū)裁剪是第一優(yōu)先級的優(yōu)化圖表畫布是個無邊際的世界但用戶眼睛能看到的區(qū)域其實很小。不做可視區(qū)裁剪等于把整個城市的地圖一次性畫出來而用戶只盯著一個街區(qū)。實現(xiàn)思路是維護一個可視矩形viewBounds遍歷節(jié)點時只渲染與viewBounds有交集的節(jié)點對完全在可視區(qū)外的節(jié)點直接跳過 DOM 創(chuàng)建。邊的渲染判斷稍微復(fù)雜一些因為一條邊的兩個端點可能都在可視區(qū)外但路徑中途穿過可視區(qū)。所以邊不能用“兩端是否在可視區(qū)”來判斷需要判斷折線線段與viewBounds是否相交。7.2 分層渲染靜態(tài)層與交互層分離很多圖表卡頓的根源在于靜態(tài)展示的圖形和用戶正在拖拽的節(jié)點混在同一個渲染層級每次交互都導(dǎo)致全量重繪。我采用的方案是分層底層靜態(tài)背景網(wǎng)格線、大節(jié)點、固定樣式元素只在畫布變換結(jié)束或數(shù)據(jù)變更時重繪。中間層動態(tài)內(nèi)容節(jié)點和邊的渲染主體在拖拽、縮放時按需更新。頂層交互反饋層選中框、拖拽中的預(yù)覽路徑、臨時高亮每幀刷新但元素數(shù)量極少。TS 項目里對應(yīng)實現(xiàn)就是疊加多個g組操作時精準(zhǔn)定位到對應(yīng)層級的g而不是每次都重建整個畫布。7.3 批量更新原則與渲染節(jié)流節(jié)點數(shù)據(jù)變化是高頻事件如果每次變化都立即操作對應(yīng) DOM往往會造成無謂的性能開銷。我多做了一個隊列化更新機制把一批變化統(tǒng)一收集放到 requestAnimationFrame 的回調(diào)里一次處理。這樣在同一次交互內(nèi)的幾十次節(jié)點移動最終只觸發(fā)一次批量更新。類似的節(jié)流還用在了縮放事件上。滾輪事件在瀏覽器里頻率非常高如果每幀都去重算所有邊的路徑必然卡頓。我的做法是縮放過程中只更新畫布的 transform 和網(wǎng)格線等縮放停止約 150ms 無新事件后才重算邊上路徑點的寬度。視覺上無感性能上會有質(zhì)的提升。8. 一路摸爬滾打總結(jié)的 diagram-design 實用準(zhǔn)則最后把這段經(jīng)歷里最有復(fù)用價值的東西濃縮成幾條原則這些是我每次做圖系統(tǒng)時都會默念的清單。先定數(shù)據(jù)模型再選渲染庫。數(shù)據(jù)模型一旦定錯后續(xù)所有代碼都在給錯誤模型打補丁。節(jié)點、端口、邊、分組、畫布這五個實體齊全了再去接渲染層、布局算法和交互邏輯。自動布局和用戶手動調(diào)整的關(guān)系要趁早想清楚。我用“用戶覆蓋優(yōu)先、自動布局尊重覆蓋、用戶主動觸發(fā)才全量重排”這套策略極大避免了布局和手動的沖突。如果沒有這條策略圖系統(tǒng)會處于一種“永遠在跟用戶搶奪控制權(quán)”的狀態(tài)非常難受。序列化數(shù)據(jù)結(jié)構(gòu)必須帶版本號和遷移機制。好結(jié)構(gòu)是慢慢“長”出來的沒有誰第一版就能設(shè)計完美。允許數(shù)據(jù)模型演進但演進一定要有章法不能直接把舊數(shù)據(jù)處理邏輯撕了。圖系統(tǒng)的性能優(yōu)化以可視區(qū)裁剪為基底再疊加批量更新和分層渲染。這三板的收益在中小圖系統(tǒng)上已經(jīng)足夠真正需要 WebGL 的場景非常少不要過早引入重型技術(shù)。還有一個容易忽略的體驗細節(jié)圖系統(tǒng)的空狀態(tài)。用戶打開編輯器時畫布上什么都沒有此時至少要展示一張“引導(dǎo)浮層”告訴用戶從哪里開始創(chuàng)建節(jié)點、怎么連線、怎么切換布局。這個浮層成本極低但對新用戶的上手體驗幫助極大。很多圖系統(tǒng)做出來功能很強大但新用戶一打開就懵了很大原因是空狀態(tài)沒有設(shè)計過。我現(xiàn)在的習(xí)慣是每做一個 diagram 類項目都會先從數(shù)據(jù)和布局入手搭一個最小原型只支持一個正方形節(jié)點、一條邊、一次拖拽、一次縮放跑通全鏈路后再逐步加功能。這個最小原型的價值不在于功能而在于把坐標(biāo)系、批量更新、撤銷棧、序列化這些地基打牢。地基穩(wěn)了后面長出來的每一層功能才不至于傾覆。