Figma 是如何做協(xié)同編輯的？

作者：前端西瓜哥 2024-01-15 07:42:37

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

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

我一直對圖形編輯器如何做多人協(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 協(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ù)雜的方案。