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