1. 為什么Diagram Design值得認(rèn)真做“diagram-design”這名字聽著挺直白就是圖表設(shè)計但真正上手之后你會發(fā)現(xiàn)它背后藏著的是一整套關(guān)于“怎么把數(shù)據(jù)變成看得懂的圖”的方法論。我在做這個項目之前一直以為畫圖這事不就是拖幾個框、連幾條線做個漂亮的界面嘛真到自己動手的時候才意識到難點根本不在“畫”這個動作上而在“如何讓圖自己長成對的樣子”。這個項目要解決的核心問題其實很典型業(yè)務(wù)系統(tǒng)里有一堆結(jié)構(gòu)化數(shù)據(jù)可能是服務(wù)依賴關(guān)系、任務(wù)流轉(zhuǎn)狀態(tài)、組織架構(gòu)層級也可能是復(fù)雜的知識圖譜信息本身是有邏輯的但看數(shù)據(jù)的人沒法直接看出來。市面上現(xiàn)成的繪圖工具能用但大多數(shù)定位是“白板”所有布局都要人工拖數(shù)據(jù)一多就亂了根本沒法應(yīng)對動態(tài)變化的內(nèi)容。diagram-design想做的是把“數(shù)據(jù)”和“圖”打通輸入一份JSON自動生成一份結(jié)構(gòu)清晰、層級合理、可以直接編輯和導(dǎo)出的圖表讓用戶既不用手工排版又能保有人工調(diào)整的靈活性。先說清楚這個項目適合誰。如果你正在做低代碼平臺里的流程圖模塊如果你的系統(tǒng)需要展示服務(wù)調(diào)用關(guān)系、任務(wù)依賴關(guān)系如果你在做知識可視化產(chǎn)品需要自動布局能力那么這個項目里的思路和方案對你會有直接參考價值。我自己在開發(fā)和后續(xù)迭代里把整個實現(xiàn)過程拆成了數(shù)據(jù)建模、布局引擎、交互編輯、導(dǎo)出集成四個部分下面逐個說透。2. 整體架構(gòu)與關(guān)鍵技術(shù)選型2.1 數(shù)據(jù)模型設(shè)計先定數(shù)據(jù)結(jié)構(gòu)再談界面做圖編輯類項目最容易犯的錯就是打開編輯器就開始寫界面代碼做到一半才發(fā)現(xiàn)數(shù)據(jù)結(jié)構(gòu)支撐不了復(fù)雜需求回頭重構(gòu)。diagram-design的第一步先把數(shù)據(jù)模型固定下來這個模型決定了后續(xù)所有功能的上限。模型核心分三塊節(jié)點(Node)、邊(Edge)、畫布(Canvas)。節(jié)點包含id、位置坐標(biāo)(x/y)、尺寸(width/height)、端口(ports)、樣式信息和附加業(yè)務(wù)數(shù)據(jù)邊包含id、起點終點引用、路由點(points)、樣式畫布包含畫布尺寸、縮放比、所有節(jié)點和邊的集合、視圖變換參數(shù)。端口是很容易被忽略但實際很重要的設(shè)計。端口就是節(jié)點上的連接點一條邊的起點和終點最終要落到端口上而不是直接浮在節(jié)點邊緣。這樣做的原因是當(dāng)節(jié)點在布局中被拖動或自動重排時邊的連接位置不會跑飛而且后續(xù)做邊路由比如正交連線時端口坐標(biāo)是所有計算的基準(zhǔn)。我用的端口模型是{ id, type: input|output, nodeId, dx, dy }dx/dy是端口相對于節(jié)點左上角的偏移量這樣節(jié)點移動時端口坐標(biāo)可以立即算出來。畫布模型里還有一個關(guān)鍵設(shè)計邏輯坐標(biāo)和渲染坐標(biāo)分離。業(yè)務(wù)數(shù)據(jù)里的坐標(biāo)永遠(yuǎn)是世界坐標(biāo)系里的值用戶看到的是經(jīng)過縮放和平移之后的結(jié)果。這個分離一開始看起來多余但實際在做縮放適配、導(dǎo)出圖片、多人協(xié)作時能省掉大量坐標(biāo)換算的混亂。后面講交互實現(xiàn)時還會重點展開這一點。2.2 渲染層選擇SVG、Canvas還是WebGL圖表編輯器的渲染方案基本就三條路SVG、Canvas 2D、WebGL。diagram-design最終選了SVG但不是因為其他方案不行而是這個項目的場景特性決定的。SVG最大的優(yōu)勢是DOM天然支持事件綁定、樣式隔離和局部更新。圖上某個節(jié)點要變色直接改這個元素的屬性就行不用重繪整個畫面節(jié)點拖拽時事件處理邏輯也直觀pointerdown、pointermove、pointerup三個事件就能搞定交互閉環(huán)。對于節(jié)點數(shù)量在幾百到一兩千規(guī)模的場景SVG的性能完全夠用開發(fā)效率卻比Canvas高出很多。Canvas適合什么情況呢節(jié)點規(guī)模上萬或者有大量動態(tài)粒子、連線動態(tài)流動這類效果時Canvas的批量渲染性能優(yōu)勢才會充分體現(xiàn)但代價是交互命中檢測要自己實現(xiàn)比如根據(jù)坐標(biāo)判斷點中了哪個節(jié)點事件系統(tǒng)也要自己維護。WebGL在diagram-design里更沒必要圖的節(jié)點數(shù)量遠(yuǎn)沒到需要GPU加速的程度引入它意味著整個渲染管線復(fù)雜度直接翻好幾倍。作為參考對比可以看下面這個表格方案交互實現(xiàn)大規(guī)模性能開發(fā)效率適用場景SVG原生事件直觀中等2000節(jié)點為分水嶺高圖表編輯器、流程圖Canvas 2D需自實現(xiàn)命中檢測高萬級節(jié)點中實時監(jiān)控大屏、大規(guī)模拓?fù)鋀ebGL需自實現(xiàn)渲染與檢測極高十萬級低大規(guī)模3D/粒子可視化選SVG還有一個現(xiàn)實考量代碼生成和文檔集成非常方便。diagram-design后續(xù)需要支持導(dǎo)出HTML頁面內(nèi)嵌圖或生成SVG格式的交付物SVG直接輸出即可不需要額外做光柵化處理。所以最終的選型結(jié)論是規(guī)模和開發(fā)效率之間選擇了開發(fā)效率和可維護性優(yōu)先。2.3 編輯器核心能力拆解把圖編輯器拆到最底層核心能力就是六件套畫布管理、節(jié)點編輯、邊編輯、布局引擎、選擇與框選、導(dǎo)入導(dǎo)出。這六件事看起來簡單每一件都能單獨寫成一篇長文。畫布管理負(fù)責(zé)縮放、平移、自適應(yīng)視圖節(jié)點編輯涉及拖拽移動、尺寸調(diào)整、樣式切換邊編輯是最有技術(shù)含量的部分包括連線的交互反饋拖拽連線時的實時預(yù)覽、已有的邊怎么拐彎正交路由、邊的交叉怎么優(yōu)化布局引擎就是自動排版這一步是diagram-design和其他白板工具拉開差距的核心后面單獨用一章講選擇與框選需要處理矩形區(qū)域和節(jié)點集合的相交判斷導(dǎo)入導(dǎo)出則要考慮JSON數(shù)據(jù)的完整序列化、反向恢復(fù)以及圖片導(dǎo)出時的清晰度和裁剪邊界。這里有一個很重要的架構(gòu)設(shè)計原則所有核心能力都做成“模塊”而不是“頁面里的函數(shù)”。diagram-design把每個能力封裝成獨立的Service比如LayoutService、ViewportService、SelectionService它們通過一個中央事件總線通信。這樣做的直接好處是后續(xù)如果要支持多人實時協(xié)作或者把同一個畫布組件嵌入不同的宿主應(yīng)用這些Service可以被復(fù)用UI層只是對Service的薄封裝。3. 自動布局引擎從亂到有序的關(guān)鍵3.1 層次布局讓依賴關(guān)系一眼清晰自動布局是diagram-design的核心價值也是我花時間最多的地方。開始設(shè)計的時候我把布局分成了兩類有向無環(huán)圖比如任務(wù)依賴、服務(wù)調(diào)用鏈用一種方式無向關(guān)系網(wǎng)比如知識圖譜、社交關(guān)系用另一種方式。有向圖我采用的是標(biāo)準(zhǔn)的層次布局算法通常叫Sugiyama算法整體分四步去環(huán)、分層、排序、定位。去環(huán)是為DAG準(zhǔn)備的——如果數(shù)據(jù)里有循環(huán)依賴A依賴BB又依賴A直接分層會死循環(huán)所以先用反轉(zhuǎn)邊的方式消除環(huán)分層是按依賴方向確定每個節(jié)點在第幾層我用了最長路徑分層法保證每個節(jié)點都滿足“邊的起點層號小于終點層號”排序是優(yōu)化同一層內(nèi)節(jié)點的順序目的是減少邊的交叉數(shù)量定位則賦予每個節(jié)點具體的坐標(biāo)。有一步容易忽略但效果很好虛擬節(jié)點。當(dāng)一條邊跨越了多個層比如A連到了第三層但中間隔了個第二層為了讓這根線走成平滑的豎直通道算法會插入虛擬節(jié)點占位。虛擬節(jié)點只參與排序和定位計算最終渲染時不展示。沒有這一步跨層長線會歪七扭八圖看起來像一團亂麻。我第一次實現(xiàn)時偷懶跳過了虛擬節(jié)點結(jié)果出來的圖連自己都看不下去補上之后圖的觀感立刻上了檔次。層次的間距和同層的節(jié)點間距我默認(rèn)分別設(shè)為120px和80px實際項目里也暴露成了可配置參數(shù)。這個間距不是拍腦袋定的節(jié)點寬度普遍在120~160px之間間距太小的話邊和節(jié)點會擠在一起太大又浪費畫布空間。合理的間距標(biāo)準(zhǔn)是任意一條邊在豎直方向上的拐角都不會碰到同層其他節(jié)點的邊緣120px在大多數(shù)場景下夠用。3.2 力導(dǎo)向布局無層級關(guān)系時的最佳選擇輸入數(shù)據(jù)不是DAG而是無向關(guān)系網(wǎng)時層次布局就沒法用了這時候需要力導(dǎo)向布局算法。力導(dǎo)向的物理模型很好理解節(jié)點之間存在相互引力和斥力也有叫彈簧模型每個節(jié)點受合力影響不斷移動經(jīng)過多次迭代后整個網(wǎng)絡(luò)趨于穩(wěn)定狀態(tài)。具體到實現(xiàn)上diagram-design用了三個基礎(chǔ)力斥力所有節(jié)點兩兩之間距離越近斥力越大、引力有連線的節(jié)點之間沿邊方向互相吸引彈簧長度和目標(biāo)邊長相關(guān)、向心力所有節(jié)點向畫布中心靠近的力防止整個圖在多次迭代后漂移出可視區(qū)域。迭代計算時每輪更新每個節(jié)點的速度和位置最后設(shè)置一個“溫度”參數(shù)控制位移步長溫度隨迭代輪次逐漸降低最終收斂。這里最大的坑是參數(shù)調(diào)優(yōu)。斥力常數(shù)、彈簧長度、迭代次數(shù)、時間步長任何一個參數(shù)設(shè)置不好結(jié)果要么節(jié)點全部重疊成一團要么散得像一盤沙。我的調(diào)試經(jīng)驗是用一組固定的測試數(shù)據(jù)例如20個節(jié)點、30條邊反復(fù)跑觀察節(jié)點平均位移量隨迭代次數(shù)變化的曲線當(dāng)某輪迭代的平均位移小于0.5像素時基本可以認(rèn)為收斂了。diagram-design最終默認(rèn)迭代了300輪在大部分中小規(guī)模數(shù)據(jù)上都能在100ms內(nèi)完成布局體感上就是“秒排”。3.3 邊路由與碰撞檢測細(xì)節(jié)決定觀感布局排完節(jié)點接下來的問題是邊怎么走。直線的實現(xiàn)最簡單但節(jié)點一多長的連線會橫穿其他節(jié)點圖就很難看了。diagram-design默認(rèn)使用正交邊路由就是連線只走水平和垂直方向不該穿越節(jié)點的時候繞過去走。這個問題的通用解法是A尋路算法。把節(jié)點占用的矩形區(qū)域標(biāo)記為障礙把畫布劃分成網(wǎng)格找一條從起點端口到終點端口的合法路徑然后再通過“拐點合并”把網(wǎng)格細(xì)化造成的鋸齒路徑平滑成折線。A在這里的效果不錯但網(wǎng)格粒度需要平衡網(wǎng)太細(xì)計算時間長路徑拐彎多網(wǎng)太粗通道可能被障礙物擋住找不到路。實踐下來用10px的網(wǎng)格粒度在大多數(shù)流程圖中都能得到良好結(jié)果性能也可以接受。碰撞檢測不只是用于路由布局完成后的校正階段也需要。層次布局定位完畢理論上節(jié)點不會重疊但不同子樹的節(jié)點可能靠得太近觀感不好。我的做法是布局結(jié)束后做一次后處理檢測節(jié)點間的重疊區(qū)域如果重疊面積超過閾值就把其中一個子樹的整體位置往下或往右推開。這一步雖然簡單但對于提升整體整齊度非常管用。4. 核心模塊實操實現(xiàn)要點4.1 畫布交互縮放、平移與坐標(biāo)轉(zhuǎn)換畫布交互是圖編輯器給用戶的第一印象所以這塊必須做扎實?？s放我用的是以鼠標(biāo)位置為錨點的“光標(biāo)縮放”交互體驗公認(rèn)最自然鼠標(biāo)滾輪向上放大、向下縮小縮放中心始終保持在鼠標(biāo)指向的位置。很多初學(xué)者會做成“以畫布中心為縮放中心”結(jié)果用戶想放大看畫布某個區(qū)域時目標(biāo)越滾越偏這交互基本就廢了。光標(biāo)縮放的數(shù)學(xué)原理不復(fù)雜核心就三步記錄鼠標(biāo)當(dāng)前的邏輯坐標(biāo)(wx, wy)更新縮放比例scale然后調(diào)整畫布的平移量(tx, ty)使得鼠標(biāo)下的邏輯坐標(biāo)點在整個變換前后保持不動。公式可以概括為tx_new wx - (wx - tx_old) * (scale_new / scale_old)平移量的y方向同理。坐標(biāo)轉(zhuǎn)換是整個交互模塊的基礎(chǔ)能力diagram-design里封裝了兩個函數(shù)screenToWorld(sx, sy)把屏幕坐標(biāo)轉(zhuǎn)為邏輯坐標(biāo)worldToScreen(wx, wy)做反方向轉(zhuǎn)換。每次鼠標(biāo)點擊、拖拽、框選都要先經(jīng)過這個轉(zhuǎn)換否則縮放之后所有交互都會漂移。我見過很多實現(xiàn)就是因為忘記了坐標(biāo)轉(zhuǎn)換這步導(dǎo)致縮放后點不到節(jié)點。4.2 編輯操作框選、連線與撤銷重做框選看起來簡單實現(xiàn)起來有幾個細(xì)節(jié)要處理。一是畫布大了之后框選區(qū)域和屏幕可見區(qū)域可能只有部分重疊所以選擇服務(wù)要先做集合求交框選矩形和節(jié)點矩形是否相交相交就選中不相交就跳過。二是框選時要區(qū)分“從空白處開始拖”和“從節(jié)點上開始拖”前者是框選后者是移動節(jié)點。我用的判斷標(biāo)準(zhǔn)是按下鼠標(biāo)時是否命中了節(jié)點命中則進入移動模式否則進入框選模式。連線交互是用戶體驗最敏感的部分之一。diagram-design的實現(xiàn)方式是這樣的從某個節(jié)點的輸出端口按下并拖拽出現(xiàn)一條跟隨鼠標(biāo)的橡皮筋線鼠標(biāo)經(jīng)過其他節(jié)點的輸入端口附近時端口高亮松開鼠標(biāo)若鼠標(biāo)在某個高亮端口上則創(chuàng)建一條正式的邊否則取消。撤銷重做用的是命令模式。每個操作移動節(jié)點、創(chuàng)建連線、刪除元素、批量移動都封裝成一個命令對象包含excute和undo兩個方法并且會記錄操作前后數(shù)據(jù)的差異信息。這里我踩過一個嚴(yán)重的坑一開始保存快照是直接把整個畫布對象深拷貝操作一多內(nèi)存瞬間膨脹畫布一復(fù)雜就卡得不行。后來改成只記錄diff比如移動操作記錄“哪些節(jié)點從哪到哪”撤銷時反向應(yīng)用diff內(nèi)存和性能問題都解決了。4.3 導(dǎo)出與集成從畫布到交付物圖表做得再漂亮不能導(dǎo)出就等于白做。diagram-design支持兩種導(dǎo)出模式JSON數(shù)據(jù)和圖片/快照。JSON導(dǎo)出相對簡單把數(shù)據(jù)模型序列化時需要注意保證無循環(huán)引用、所有自定義業(yè)務(wù)字段完整保留。圖片導(dǎo)出則有兩個方案在瀏覽器端直接把SVG序列化為圖片或者借助Canvas二次渲染。我最終的選型是用SVG的XMLSerializer序列化再放到Blob里通過URL.createObjectURL生成下載鏈接如果用戶需要PNG就再走一遍Canvas的drawImage把SVG畫上去再導(dǎo)出。這個方案的好處是矢量內(nèi)容導(dǎo)向PDF或打印時依然清晰不需要額外服務(wù)端處理。集成方面diagram-design留了一個非常干凈的APImount(container, data)和getData()。前者傳入DOM容器和JSON數(shù)據(jù)即可完成渲染后者把當(dāng)前畫布數(shù)據(jù)序列化返回。這意味著它可以被嵌入到任何管理系統(tǒng)里項目交付時只需要一個容器節(jié)點不需要依賴任何框架。5. 常見問題與排查技巧實錄5.1 性能問題節(jié)點一多就卡頓SVG方案的性能瓶頸主要出現(xiàn)在兩處節(jié)點數(shù)量過多導(dǎo)致DOM樹過大以及頻繁的屬性更新觸發(fā)大量重繪。diagram-design實際測試中節(jié)點超過1500個時拖動畫布會明顯感到卡頓幀率從滿幀掉到30幀以下。排查和優(yōu)化的過程有三個維度。第一是減少DOM數(shù)量——同一個類型的節(jié)點盡量復(fù)用模板而不是每個節(jié)點都生成一套新的子元素第二是降低屬性變化頻率——拖拽過程中對節(jié)點位置的更新做節(jié)流16ms內(nèi)只更新一次第三是局部更新代替全局更新——移動節(jié)點時只改這個節(jié)點的transform屬性而不是重渲染整棵畫布樹。做完這三層優(yōu)化后哪怕節(jié)點到了3000個也能穩(wěn)定在40幀以上日常使用完全夠了。5.2 布局結(jié)果不理想連線交叉怎么優(yōu)化布局完成后連線條交叉導(dǎo)致可讀性差這個問題的根源多數(shù)是同一層內(nèi)節(jié)點的排序不合理。Sugiyama算法的第三階段就是專門解決這個問題的通過交換同層相鄰節(jié)點的位置計算邊交叉數(shù)量找到交叉最少的排列。我遇到過的最典型的情況是層次布局的圖整體結(jié)構(gòu)是對的但某些局部區(qū)域出現(xiàn)大量長線條交叉。排查后發(fā)現(xiàn)是因為某些同層內(nèi)節(jié)點數(shù)量多且邊的關(guān)系復(fù)雜僅靠相鄰交換這一個啟發(fā)式策略沒法找到全局最優(yōu)。這個問題的實用解法是引入層內(nèi)節(jié)點重排的多輪迭代每輪隨機打亂初始順序再執(zhí)行交換保留交叉數(shù)最少的結(jié)果。平均跑5~10輪效果就已經(jīng)很好了性能損耗也完全可以接受。5.3 撤銷重做的數(shù)據(jù)爆炸問題撤銷重做導(dǎo)致的瀏覽器內(nèi)存溢出是我在這個項目里踩過最深的坑。最初實現(xiàn)時每次操作結(jié)束就把整個畫布數(shù)據(jù)序列化后推入棧底連續(xù)操作幾十次后內(nèi)存飆升到幾百MB頁面直接白屏。排查后發(fā)現(xiàn)問題的根源在于快照里保存了大量“未變化”的數(shù)據(jù)。比如一次移動操作只需要記錄“哪些節(jié)點、從什么坐標(biāo)、到什么坐標(biāo)”而整個快照包含了所有節(jié)點、邊、樣式的完整數(shù)據(jù)。優(yōu)化后的方案是用命令對象加diff記錄來替代全量快照。diff的粒度很小一次批量移動記錄了所有節(jié)點的舊位置和新位置一次刪除邊記錄了被刪除邊的完整信息以便撤銷時恢復(fù)。這樣做了之后連續(xù)操作上百次內(nèi)存占用也就幾MB。5.4 坐標(biāo)漂移縮放平移后點不準(zhǔn)老實說“縮放平移之后點不準(zhǔn)”這種問題圖編輯器項目太常見了。表現(xiàn)形式是窗口放大后鼠標(biāo)點擊某個節(jié)點選中到的卻不是這個節(jié)點甚至完全選不中。排查思路是沿著事件流檢查每一步鼠標(biāo)事件拿到的坐標(biāo)是屏幕坐標(biāo)如果沒有先轉(zhuǎn)換成邏輯坐標(biāo)就直接拿去做命中檢測放大之后誤差會越來越大因為此時屏幕坐標(biāo)和邏輯坐標(biāo)的比例已經(jīng)被縮放因子拉大了。修復(fù)方案就是保證所有命中檢測前都先調(diào)用screenToWorld做一次坐標(biāo)變換并且保證坐標(biāo)轉(zhuǎn)換函數(shù)里面用的是最新的縮放值和平移值而不是事件綁定那一刻的緩存值。我在這個坑上補了自動化測試模擬縮放2倍、平移500px后點擊一個已知節(jié)點斷言是否選中正確。從此再也沒有出現(xiàn)過坐標(biāo)漂移的回歸問題。結(jié)語個人經(jīng)驗diagram-design做完之后再回看我最深刻的體會是圖編輯類項目難的不是某個單一的算法而是各個模塊之間的數(shù)據(jù)銜接和狀態(tài)一致。布局引擎再強交互沒跟上用戶感受就是“亂”交互做得再順數(shù)據(jù)導(dǎo)出不完整項目落地就會出問題。整個開發(fā)過程里我反復(fù)在調(diào)整的就是這種事改布局參數(shù)時要保證畫布上的元素同步更新改數(shù)據(jù)模型時要同步升級歷史記錄的序列化邏輯。最后分享一個小技巧如果你也在做類似的項目從一開始就要維護一套標(biāo)準(zhǔn)化的測試數(shù)據(jù)覆蓋樹形結(jié)構(gòu)、環(huán)結(jié)構(gòu)、孤立節(jié)點、超大圖、空數(shù)據(jù)等邊界情況。每一次改動布局算法或交互邏輯跑一遍這套數(shù)據(jù)基本能攔住大部分回歸問題。這個習(xí)慣讓diagram-design在后續(xù)幾次大改中少踩了很多坑也讓我能放心地對布局引擎做各種激進實驗。寫代碼做編輯器這事最好的狀態(tài)就是測試數(shù)據(jù)在手里心里就不慌。