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