技術分享 | 讓實時協同的框架繪圖變得絲滑起來
ShowMeBug 創始人&CEO李亞飛在10月份的「RTE2021 實時互聯網大會」中，圍繞《讓實時協同的框架繪圖變得絲滑起來》的主題做了技術干貨的分享，以下是主題分享精華版全文——
ShowMeBug 創始人&CEO：李亞飛
今天非常榮幸來到這里跟大家做一場非常技術化的分享，
在開始之前我先介紹一下我個人的情況，我是2009年在深圳開始發展，有十多年的全棧工程師經驗，14年的時候開始獨立創業，到現在已經創建了三家公司，這是我第三家公司。2019年6月份開始啟動 ShowMeBug 這個項目，主要幫助工程師解決在線面試、篩選、評估的難題。
今天的話題也是討論關于《如何構建深度架構繪圖的前端體驗》，我將帶著大家一起，把角色換成工程師的身份來感受整個架構選型，以及探討各個細節和挑戰。
ShowMeBug 連續拿了三年的融資，有大幾百家的客戶，我們正好在這個檔口上，再講到 WebRTC 的痛，我們深有體會，不管兼容性問題，還是移動端的各個點，我們非常期待核心技術的演進。
今天分享的內容將細分為以下五點：
第一、什么是實時協同的架構繪圖；
第二、實時協同框架繪圖的核心技術——協同算法；
第三、實時協同框架繪圖的核心技術——鼠標同步；
第四、實時協同框架繪圖的核心技術——組建同步；
第五、實時協同框架繪圖的核心技術——視角同步。
首先看實時協同架構繪圖技術的核心，我作為十多年的技術研發最大的體會是，任何技術最終都需要給商業價值提供非常核心的輸出，我們把云端繪制架構圖，繪制流程圖，繪制所有技術類相關的產品邏輯，都實現了雙人在線上無縫絲滑的體驗，整個過程我們大概花了一年的時間去迭代研發。
最大的核心價值點是在線上完成整個架構、交流、溝通、協作，是非常爽滑的感覺。具體我們可以看一下架構選型的核心方案：
首先，我們選擇找這些點，最核心的是先找到一個起點，比如音視頻的起點核心是找到 WebRTC，我們用的是 MxGraph，最基礎的開源組件，在上面會做非常多的功能板塊，核心特點是全部結構化構建底層數據，有自動的畫布，整個導出可以做到全結構化的文檔，如果 WebRTC 最好的方式是能夠很容易擴展，能夠以我們的業務需求擴展很多點，這一點就需要做的非常充分。
在整個過程中選擇了非常多可能的技術架構、關于繪圖板塊的核心業務點，比如 jsPlumb、JointJS、QuneeJS，這個是商業幫助圖形庫的解決方案，這對整體社區資源，還有文檔方面都比較有挑戰，整體來說選擇一個能夠自我掌控、很好的去拓展的方案是比較有利的，尤其是在這些點上要掌握非常核心的技術優勢。
以上其實只是完成工作的10%，接下來另外一個核心話題就是：我們如何絲滑實現體驗？
這里有兩個核心算法給大家解釋一下，第一個最常用的核心文檔協作算法是 OT 算法，這個算法是90年伴隨著谷歌的科學家開始打造的標準，之后因為這個技術有很大的挑戰，到94年、95年才有一些文檔系統實現出來，目前為止實時協同的數據，可能會存在丟一些點的問題，且 OT 算法有復雜的機制，以及排隊的結構，這就要求前端也需要實現排隊的算法。
核心理念就是把所有的操作轉成三個操作，加、減和移動，把所有的東西都變成三個操作，通過數學公式，在服務端進行雙向的處理，然后服務端再分發給各個端，這就是關于輕量級文檔的技術。
這一塊也是我們非常核心的算法，會應用在協同編程上，打造云端的編程環境。在這個板塊里我們并不是直接選用這個技術，而是采用非常有點取巧，但是又非常酷的點，我們叫做 Diff/patch 算法，針對性的一個一個比對異同，再應用到每一個具體的節點上，調整完發送到另外一個端，AB兩個用戶之間就可以進行很好的同步。
這個是 Diff/patch 核心的算法實現，大家可以簡單的過一下。首先拿到每一個對象，創建一個節點就會創建新的對象，跟對端對比，我們可以看到中間是不是多了？如果多了就會處理，如果有更新的操作，我們開始 Diff 出來然后形成一個 patch。核心的算法是這樣不斷的循環的，因為我們數的結構最大的優點是永遠不會循環死鎖。
這個模式相比 OT 算法來說很容易掌控，它的延時和各個點非常扎實，唯一有一個挑戰，但是我們在技術選型架構上需要考慮其中的點。偶爾會有網絡丟失或者是一個狀態可能會在過程中有非常低的機率，丟失一個小的圖形，下一次更新的時候，或者有人動一下馬上就會進入到最終的狀態，這種點是萬分之一，或者都不到萬分之一來換取一個清晰的架構，這個事情我覺得是非常值的。
這個是代碼的實現，大家簡單過一下，核心接口是 CreatePatch，在每個節點上就會把加操作對對端是減操作，如果移動操作雙方是一樣的，通過這種方式進行配對，這邊是整個算法核心，大家可以看看：
看起來非常簡單，但是真正實現的時候可以想一下這個大前端的工程調試挑戰或者難點就會非常大，這種技術可以應用于未來很多實際，構建一個云端實時互動的交互場景。
這個是最終的 Apply，反向應用的核心代碼，核心代碼是非常少的，就幾個核心操作。
當這個問題解決完之后，那就意味著一個大的問題解決了，大多數市面上比如說有一些類似的產品就做到那個程度，但針對業務場景需求就需要有一個非常強的，能不能有一種絲滑的感覺，我們需要做到一個非常重要的能力就是鼠標的同步，鼠標同步大家可以想一下這種場景下一個巨大的挑戰，什么時間發送一個鼠標狀態到對端，非常多人的時候可以想到中間會遇到一個巨大的渲染的壓力，剛開始實現的那個方案感覺卡卡的，大家可以感覺到移動溝通上面鼠標狀態會有一些延遲。
實現這個技術手段的時候應用到架構選型的優勢，跟我們再追加一些核心的特性，第一我們用的是，一個是先用 SVG 的鼠標繪制，在原來可視化上追加一個新的隱藏圖層最高層的層級，這樣鼠標的核心點就可以實現出來。
現在整個瀏覽器動畫技術里面最核心的函數接口就是這個接口，可以實現動畫效果，這里面會深度使用這些點，大家可以看一下鼠標同步流程，核心是這樣的流程。
第一、我們繪制出來對端鼠標的效果，加上光標，加上信息。
第二、我們監聽本地的鼠標事件，移動之后循環把這些事件插入到具體隊列里面，然后再發往服務端。
svg 的繪制相對是比較容易的，大家可以看一下這幾個核心點，整體上主要代碼采用的是 svg 的整個方案，最好就是一個結構化文檔可以便捷的進行傳輸，這是這個圖層的效果。
再看這個動畫的實現，體現了兩個技巧，第一是什么時間發送一次，快的話壓力很大，慢的話延遲很高，我們調的節點是500毫秒，搞前端的都知道截流可能觸發很多次，每500毫秒做一次數據。我們的繪制間隔是400毫秒，這個是精心調整過，在對端雙方正好非常絲滑的感覺，你能感覺到稍微有一點點的跟隨，這是最好的狀態，所以這就是我們當時最核心的數據。
這個是核心的鼠標同步算法，這里面用兩個核心接口，通過 CS3 整個的效果可以把一個位置不斷地滾動，非常流暢，這種模式下基本上看起來就跟真的光標一模一樣。所以這就是，原來我們覺得會有挑戰的點，但其實可以很好的化繁為簡。
這個方案解決完之后還有一些關鍵挑戰，比如，我們接下來要討論的組件動畫的同步，大家可以重新回想一下剛才的視頻里面播的是，整個組件移動的過程也要同步過去，現在國際上做這種技術方案，大家的感受都是滑過去之后對方直接就蹦過去了。
這個動畫的拖拽效果也有非常詳細的流程，我們的模式是增加一個選擇的監聽，本地把這些監聽發送到云端，對端開始接受，接受之后創建一個專門的隊列，每一端的操作都有一個對應的隊列，這樣整個體系里面會把每個端的高量全部渲染出來。之后再進行計算處理。
這個處理需要有非常多的技巧，又回到剛才說的技術選型的重要性，所以我們的處理辦法是看起來很嚇人，實際上是非常好的，中間會經歷很多次的闡述、添加，但這就是我們核心的流程。
大家可以看一下關鍵數據的情況，非常關鍵細致的點決定了交互體驗。組件軌跡同步，這是相關的核心代碼，有興趣的話可以找我進一步溝通。
還有一個關鍵挑戰，這個挑戰來自于視角同步，大家都知道整個架構繪圖方面可能是很大的繪制白板，可能脫離出視角，這個情況，超出這個視角之后就不知道對方在更新什么。
而我們的處理辦法是，需要計算每一次新進來的行為有沒有在對方的視角內，如果有的話我們有兩種處理方法，第一類是點擊追隨，追隨完之后，別人移動什么視角對方可以直接追隨，我們不需要任何的動作。第二類是其他追隨，告訴他對方已經出了整個繪圖區需要追隨，再去點擊，這也是我們的核心處理。
這里面最重要的是視角同步整個技術處理，第一一樣的會追隨鼠標狀態，然后關注每個圖形的位置，換算對方過來之后有沒有超出區域。最重要的是拿到對方視角的位置，然后再分析有沒有大于我們的區域。
視角同步算法，通過本地的 ScrollLeft 去判定，之后一樣通過動畫的處理函數去進行整體的處理。
大家跟著我一起感受了整個從技術選型到框架架構方案，再到每一個繪制技術，到最后整個方案選型的整個過程，目前，我們的核心策略是打造一個真正云端化在線協同無縫溝通的環境，尤其是在咱們技術深度的溝通協作環節。
我這邊的核心分享就到這里，大家有什么問題可以找我進一步的交流。
謝謝大家！
