大家好，我是前端西瓜哥。

我一直對圖形編輯器如何做多人協同編輯很感興趣，最近讀了 Figma 前 CTO Evan Wallace 的文章《How Figma’s multiplayer technology works》，很有收獲，于是寫了這篇筆記。

我建議讀者直接閱讀原文，里面還有動圖。

https://madebyevan.com/figma/how-figmas-multiplayer-technology-works/

參考 CRDT

協同編輯，需要用到數據一致性算法，目前成熟的算法有 OT 和 CRDT。

Figma 沒用 OT，太復雜，尤其是當離線數據本地緩存了很久才提交時，會進行復雜的 OT 算法計算，產生組合爆炸問題。

CRDT，也有一定復雜度，而且是去中心的，Figma 還是需要一個中心服務實現鑒權功能。

OT 和 CRDT 更多是針對富文本編輯的，而 Figma 是設計工具，作者認為沒有必要引入這些復雜的東西，這樣會讓項目難以維護。

Figma 最終選擇借鑒 CRDT 的思想，自己實現一套協同系統。

這里我比較贊同，我永遠認為 “不要過早擴展”，能簡單就不要復雜。

因為一些后期不一定會用到的功能，強行做了更復雜的抽象和擴展，導致功能開發的心智負擔過重，當發現這些后期功能不需要，并且要擴展另一個方向的一套功能時，原本抽象的設計變得毫無意義，且一切都積重難返，最后的結果只能是屎上雕花了。

沖突處理

Figma 的設計文件的數據是一棵圖形樹，圖形之間可能會有父子關系，比如一個 group 下有一個 rectangle，形成多層的樹結構。協同編輯操作的對象就是這么一棵樹。

Figma 協同操作的最小原子是 對象的屬性。

修改同一個對象的不同屬性沒有沖突問題。

多個用戶同時修改同一個對象的相同屬性時，最晚提交到服務端的值會覆蓋其他用戶的值，包括文本內容。

假設一個屬性的值是 B，一個用戶修改為 AB，另一個用戶修改為 BC，最終同步后，他們不會得到 ABC，只會是 AB ，或者 BC，看誰最晚提交。

這個其實在大多協同表格應用也是類似的，單元格的內容也是最后提交者優勝，只有富文本文檔才要求得到 ABC。

處理閃爍現象

首先要明確 Figma 協同編輯的基本要求：

• 可以本地立即修改，而不是提交后再更新，這是為了有絲滑的用戶體驗，同時也能支持離線編輯能力；
• 使用中心服務，而不是去中性化（說你呢 CRDT），Figma 的服務端會維護圖形樹，作為最終的權威，并負責修正用戶提交的數據。

當多個用戶同時修改同一個對象屬性時，服務端返回的有沖突的屬性值如果立即給對象應用上，可能會有 “閃爍” 現象。

是這么一個場景，在同一時間，用戶 A 將圖形改成紅色（本地改成紅色然后提交到服務器），用戶 B 改成黃色，用戶 B 比用戶 A 更早提交到服務器。

對于用戶 A，他會先看到顏色從紅色變成黃色，黃色再變成紅色，這種不期望的 “閃爍” 現象。

解決方式是，用戶 A 提交將顏色改成紅色的操作，要等待服務端確認。在等待服務端確認期間，如果收到其他用戶修改同一個屬性的操作（用戶 B 改成黃色），會把這個改動 丟棄。

之后用戶 A 收到服務端的確認消息后，如果此時有個用戶 C 修改圖形為紫色的操作同步過來，就會走正常的流程，將圖形改成紫色。

創建與刪除

創建類似前面的做法，也是最后寫入者優勝。（沒理解）

對于刪除操作，Figma 服務器不會保存被刪除的數據，這么做是為了防止文檔大小持續增長。

被刪除的數據由進行刪除操作的客戶端負責，該客戶端可通過 undo（撤銷）恢復。

系統需要保證 id 的一致性。

做法是給每個客戶端分配一個唯一 id，將其作為新創建對象 id 的一部分。這樣兩個客戶端就不會生成相同的對象 id 了。（這有點像雪花算法）

更改對象的父元素

修改對象的位置是 Figma 系統中最復雜的部分。

其復雜度來自移動一個對象到另一個父節點操作。需要做到：

• 該移動操作不和該對象的其他無關屬性沖突；
• 并發的兩個操作不會導致一個對象同時在多個父元素下。

很多做法是 “刪除+重新創建” 表示對象的移動，但這會導致 id 的改變，對 Figma 并不合適。

Figma 最后選擇給對象加一個屬性，指向它的父節點。這樣 id 得以保持不變，多個用戶同時進行操作只是在改這個屬性，也有效避免了副本的出現。

副本指的是，兩個用戶同時分別把一個圖形放到不同的父節點上，如果用的是修改 children 數組的方式，就會導致兩個父節點都掛著同一個圖形的引用。

然后還有一個 “環” 的問題，假設 B 和 C 是兄弟節點，一個用戶將 B 放到 C 下，另一個用戶把 C 放到 B 下，就會產生一個環。

解決方法是，最先改變父子關系，會作為最終狀態。假設用戶 1 將 C 放到 B 下的操作先到服務器，服務器會應用它。此時服務器收到用戶 2 把  B 放到 C 下的同步信息，服務器會將其駁回，帶上真正的父節點 id。

在駁回前，用戶 2 其實收到了用戶 1 的操作，客戶端此時會將 A 和 B 臨時形成環，然后移出圖形樹，接著駁回的信息回來，客戶端就能確定父節點，然后恢復到圖形樹中。

該方法并不是非常好，因為圖形消失了一段時間，但方案比較簡單，且這種場景非常罕見，Figma 不打算用更復雜的方案。

順序一致性

如果多個用戶同時修改一個節點下的兄弟節點的位置，如何保證它們的最終順序是一致的？

Figma 使用了 “Fractional Indexing”（小數索引） 技術。

兄弟節點會分配一個大于等于 0，小于 1 的小數索引值。

插入新的節點，會取于它相鄰的兩個節點的索引值的中間位置，比如要在索引為 0.3 和 0.4 的中間插入新節點，這個節點的索引值會標記為 0.35。

如果出現索引值相同的情況，服務端會進行糾正，把更晚提交的新節點的索引往后移動一點。

實現撤銷（undo）

單機的 undo，是將狀態會恢復到上一個時間點，如果不加以改變，換成多人協同，就會導致當前用戶的操作在其他用戶撤銷時被覆蓋。

Figma 團隊總結了一個重要的準則：撤銷后復制了一些東西，然后重做到當前位置，文檔不應該被改變。

Figma 的做法是 改歷史記錄。

Figma 會在用戶撤銷的時候修改重做歷史，以及在重做的時候修改撤銷歷史。

用戶 A 和用戶 B 都打開一張圖紙，其中一個圖形原來是紅色。用戶 A 將其更換為藍色，同步，此時雙方都看到圖形是藍色。

此時用戶 B 又將圖形改成黃色，同步，此時雙方都是黃色的。。

用戶 A 進行撤銷操作，撤銷為紅色（因為撤銷棧記錄的是紅變藍），此時重做棧的命令對象跑到重做棧，本來應該是藍變紅，但是 最新的文檔狀態是黃色，所以這里強行把替換為黃變紅。

這樣歷史記憶就被篡改了，可以保證重做后能回到最新狀態。

對于用戶 B，則不需要修改，因為他的歷史記錄是就是紅變黃（黃是最終狀態）。

要點

最后是作者的一些心得：

• CRDT 的文獻很有參考價值，即使你不打算做非中心化協同；
• 可視化編輯器的協同編輯并沒有想象中難做；
• 在開做之前先調研并實現原型是非常有價值的。

結尾

文章看下來，大概有一些圖形編輯器如何做協同編輯的概念了，以后有機會實踐一下。

其中一點我是非常贊同的，就是方案能簡單就不要復雜，我不是很喜歡一些高度抽象的東西，代碼是寫給人看的，只是順便讓機器執行而已。