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