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

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

我建議讀者直接閱讀原文，里面還有動(dòng)圖。

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

參考 CRDT

協(xié)同編輯，需要用到數(shù)據(jù)一致性算法，目前成熟的算法有 OT 和 CRDT。

Figma 沒用 OT，太復(fù)雜，尤其是當(dāng)離線數(shù)據(jù)本地緩存了很久才提交時(shí)，會(huì)進(jìn)行復(fù)雜的 OT 算法計(jì)算，產(chǎn)生組合爆炸問題。

CRDT，也有一定復(fù)雜度，而且是去中心的，F(xiàn)igma 還是需要一個(gè)中心服務(wù)實(shí)現(xiàn)鑒權(quán)功能。

OT 和 CRDT 更多是針對富文本編輯的，而 Figma 是設(shè)計(jì)工具，作者認(rèn)為沒有必要引入這些復(fù)雜的東西，這樣會(huì)讓項(xiàng)目難以維護(hù)。

Figma 最終選擇借鑒 CRDT 的思想，自己實(shí)現(xiàn)一套協(xié)同系統(tǒng)。

這里我比較贊同，我永遠(yuǎn)認(rèn)為 “不要過早擴(kuò)展”，能簡單就不要復(fù)雜。

因?yàn)橐恍┖笃诓灰欢〞?huì)用到的功能，強(qiáng)行做了更復(fù)雜的抽象和擴(kuò)展，導(dǎo)致功能開發(fā)的心智負(fù)擔(dān)過重，當(dāng)發(fā)現(xiàn)這些后期功能不需要，并且要擴(kuò)展另一個(gè)方向的一套功能時(shí)，原本抽象的設(shè)計(jì)變得毫無意義，且一切都積重難返，最后的結(jié)果只能是屎上雕花了。

沖突處理

Figma 的設(shè)計(jì)文件的數(shù)據(jù)是一棵圖形樹，圖形之間可能會(huì)有父子關(guān)系，比如一個(gè) group 下有一個(gè) rectangle，形成多層的樹結(jié)構(gòu)。協(xié)同編輯操作的對象就是這么一棵樹。

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

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

多個(gè)用戶同時(shí)修改同一個(gè)對象的相同屬性時(shí)，最晚提交到服務(wù)端的值會(huì)覆蓋其他用戶的值，包括文本內(nèi)容。

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

這個(gè)其實(shí)在大多協(xié)同表格應(yīng)用也是類似的，單元格的內(nèi)容也是最后提交者優(yōu)勝，只有富文本文檔才要求得到 ABC。

處理閃爍現(xiàn)象

首先要明確 Figma 協(xié)同編輯的基本要求：

• 可以本地立即修改，而不是提交后再更新，這是為了有絲滑的用戶體驗(yàn)，同時(shí)也能支持離線編輯能力；
• 使用中心服務(wù)，而不是去中性化（說你呢 CRDT），F(xiàn)igma 的服務(wù)端會(huì)維護(hù)圖形樹，作為最終的權(quán)威，并負(fù)責(zé)修正用戶提交的數(shù)據(jù)。

當(dāng)多個(gè)用戶同時(shí)修改同一個(gè)對象屬性時(shí)，服務(wù)端返回的有沖突的屬性值如果立即給對象應(yīng)用上，可能會(huì)有 “閃爍” 現(xiàn)象。

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

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

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

之后用戶 A 收到服務(wù)端的確認(rèn)消息后，如果此時(shí)有個(gè)用戶 C 修改圖形為紫色的操作同步過來，就會(huì)走正常的流程，將圖形改成紫色。

創(chuàng)建與刪除

創(chuàng)建類似前面的做法，也是最后寫入者優(yōu)勝。（沒理解）

對于刪除操作，F(xiàn)igma 服務(wù)器不會(huì)保存被刪除的數(shù)據(jù)，這么做是為了防止文檔大小持續(xù)增長。

被刪除的數(shù)據(jù)由進(jìn)行刪除操作的客戶端負(fù)責(zé)，該客戶端可通過 undo（撤銷）恢復(fù)。

系統(tǒng)需要保證 id 的一致性。

做法是給每個(gè)客戶端分配一個(gè)唯一 id，將其作為新創(chuàng)建對象 id 的一部分。這樣兩個(gè)客戶端就不會(huì)生成相同的對象 id 了。（這有點(diǎn)像雪花算法）

更改對象的父元素

修改對象的位置是 Figma 系統(tǒng)中最復(fù)雜的部分。

其復(fù)雜度來自移動(dòng)一個(gè)對象到另一個(gè)父節(jié)點(diǎn)操作。需要做到：

• 該移動(dòng)操作不和該對象的其他無關(guān)屬性沖突；
• 并發(fā)的兩個(gè)操作不會(huì)導(dǎo)致一個(gè)對象同時(shí)在多個(gè)父元素下。

很多做法是 “刪除+重新創(chuàng)建” 表示對象的移動(dòng)，但這會(huì)導(dǎo)致 id 的改變，對 Figma 并不合適。

Figma 最后選擇給對象加一個(gè)屬性，指向它的父節(jié)點(diǎn)。這樣 id 得以保持不變，多個(gè)用戶同時(shí)進(jìn)行操作只是在改這個(gè)屬性，也有效避免了副本的出現(xiàn)。

副本指的是，兩個(gè)用戶同時(shí)分別把一個(gè)圖形放到不同的父節(jié)點(diǎn)上，如果用的是修改 children 數(shù)組的方式，就會(huì)導(dǎo)致兩個(gè)父節(jié)點(diǎn)都掛著同一個(gè)圖形的引用。

然后還有一個(gè) “環(huán)” 的問題，假設(shè) B 和 C 是兄弟節(jié)點(diǎn)，一個(gè)用戶將 B 放到 C 下，另一個(gè)用戶把 C 放到 B 下，就會(huì)產(chǎn)生一個(gè)環(huán)。

解決方法是，最先改變父子關(guān)系，會(huì)作為最終狀態(tài)。假設(shè)用戶 1 將 C 放到 B 下的操作先到服務(wù)器，服務(wù)器會(huì)應(yīng)用它。此時(shí)服務(wù)器收到用戶 2 把  B 放到 C 下的同步信息，服務(wù)器會(huì)將其駁回，帶上真正的父節(jié)點(diǎn) id。

在駁回前，用戶 2 其實(shí)收到了用戶 1 的操作，客戶端此時(shí)會(huì)將 A 和 B 臨時(shí)形成環(huán)，然后移出圖形樹，接著駁回的信息回來，客戶端就能確定父節(jié)點(diǎn)，然后恢復(fù)到圖形樹中。

該方法并不是非常好，因?yàn)閳D形消失了一段時(shí)間，但方案比較簡單，且這種場景非常罕見，F(xiàn)igma 不打算用更復(fù)雜的方案。

順序一致性

如果多個(gè)用戶同時(shí)修改一個(gè)節(jié)點(diǎn)下的兄弟節(jié)點(diǎn)的位置，如何保證它們的最終順序是一致的？

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

兄弟節(jié)點(diǎn)會(huì)分配一個(gè)大于等于 0，小于 1 的小數(shù)索引值。

插入新的節(jié)點(diǎn)，會(huì)取于它相鄰的兩個(gè)節(jié)點(diǎn)的索引值的中間位置，比如要在索引為 0.3 和 0.4 的中間插入新節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)的索引值會(huì)標(biāo)記為 0.35。

如果出現(xiàn)索引值相同的情況，服務(wù)端會(huì)進(jìn)行糾正，把更晚提交的新節(jié)點(diǎn)的索引往后移動(dòng)一點(diǎn)。

實(shí)現(xiàn)撤銷（undo）

單機(jī)的 undo，是將狀態(tài)會(huì)恢復(fù)到上一個(gè)時(shí)間點(diǎn)，如果不加以改變，換成多人協(xié)同，就會(huì)導(dǎo)致當(dāng)前用戶的操作在其他用戶撤銷時(shí)被覆蓋。

Figma 團(tuán)隊(duì)總結(jié)了一個(gè)重要的準(zhǔn)則：撤銷后復(fù)制了一些東西，然后重做到當(dāng)前位置，文檔不應(yīng)該被改變。

Figma 的做法是 改歷史記錄。

Figma 會(huì)在用戶撤銷的時(shí)候修改重做歷史，以及在重做的時(shí)候修改撤銷歷史。

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

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

用戶 A 進(jìn)行撤銷操作，撤銷為紅色（因?yàn)槌蜂N棧記錄的是紅變藍(lán)），此時(shí)重做棧的命令對象跑到重做棧，本來應(yīng)該是藍(lán)變紅，但是 最新的文檔狀態(tài)是黃色，所以這里強(qiáng)行把替換為黃變紅。

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

對于用戶 B，則不需要修改，因?yàn)樗臍v史記錄是就是紅變黃（黃是最終狀態(tài)）。

要點(diǎn)

最后是作者的一些心得：

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

結(jié)尾

文章看下來，大概有一些圖形編輯器如何做協(xié)同編輯的概念了，以后有機(jī)會(huì)實(shí)踐一下。

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