百度腦圖解析：如何進行web複雜應用的漸進式開發

內容來源：2017 年 4 月 8 日，張博在“HTML5夢工場 & 微軟開發者沙龍第05期—持續整合”進行《Web複雜應用的 「漸進式」開發》演講分享。IT 大咖說（微信id：itdakashuo）作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

百度腦圖是一款線上思維導圖編輯工具，常被用在工作規劃、頭腦風暴、會議記錄、讀書筆記、考試大綱等方面。

百度腦圖的底層是基於SVG向量圖形庫，在此基礎上是一個思維導圖的封裝——Kityminder-core，還有一個完善導圖功能的hotbox，它是一個上下文字快捷選單。最後的完全體就是一個編輯器——Kityminder-editor。

以上是功能性的結構，除此之外還有業務上的應用，比如檔案管理、使用者認證、分享、歷史版本管理等等。可以看出整個構造從裡往外通用性不斷降低、定製程度也隨之增加。這就是一個漸進的過程，不同的目標人群能夠找到所需的功能。

Kity是一款向量圖形庫，它的最底層特性是物件導向支援。眾所周知JavaScript是弱型別語言，要想用它完成工程化的產出，就需要物件導向的支援。因此我們基於ES5構建了一套面嚮物件語言的實現，包括定義類、擴充套件類、繼承以及混合。下圖就是Kity類的繼承關係。

Kity的一個核心內容就是座標系的概念，它的座標系分為自身座標系和參考座標系。自身座標系只存在一個，用於定義圖形。參考座標系由觀察者選取，針對不同的參考有不同的座標系，它的目的是用來觀察圖形。

上圖中的二維線性變換矩陣能夠很清楚的將二維空間中的圖形變換呈現出來。

相對於指定座標系的線性變換：Shape.getTransform(refer):matrix

相對於圖形自身座標系的區域：Shape.getBoundaryBox():box

相對於指定座標系的區域：Shape.getRenderBox(refer):box

事件發生時相對指定座標系的位置：ShapeEvent.getPosition(refer):Point

1.執行命令：execCommand(command,args)

2.查詢命令狀態：queryCommandState(command),可執行返回0，不可執行返回-1，已執行返回1

3.查詢命令結果：queryCommandValue(Command)

這三個函式中Command參數列示需要傳入的命令，args補充引數。例如minder.execCommand(‘expand’)就表示展開當前節點。

AppendChildNode：新增子節點到選中的節點中

Arrange：調整選中節點的位置

Camera：設定當前視野中心點的當前樣式

Image:為選中的節點新增圖片

Progress：設定節點的進度資訊

Parent：父節點

Children：子節點陣列

Root：根節點

Data：節點資料，如：文字、備註 、優先順序

Rc：renderContainer，節點渲染出的容器

Attached：是否獨立節點

Type：root，main，sub

Kityminder-core中渲染就是決定節點外觀，並在渲染後提供contentBox，目前共提供了10個渲染器。

渲染的實現基於渲染器基類core/render提供的執行時支援，能夠相對自身座標系分別對center、top、bottom、left、right、outline、outside位置進行渲染。

佈局就是決定一個節點相對父節點的位置，並提供一個layoutBox，它預設是相對於父節點的座標系，每個節點data均有layout屬性。Kityminder-core提供了5種主要佈局和10中子佈局。

模板是佈局和連線的集合，目前腦圖提供了上圖中的6種模板。

Kityminder-editor基於Angular1.x，依賴於execCommand函式，並新增了hotbox和UI。

Hotbox又叫做熱盒UI，是一種高效的上下文互動方式。可以說是一種快捷選單，選中節點後敲擊空格就會展現，接著就可以使用方向鍵選中需要的功能。這樣就能擺脫頻繁使用滑鼠點選工具欄的情況。

有限狀態機是計算理論的入門概念，是表示有限個狀態以及在這些狀態之間轉移的數學模型。腦圖中的初始狀態為normal，當使用者輸入的時候就會切換到input狀態，選擇狀態下敲擊空格切換到hotbox狀態。由此通過這種機制就能在不同狀態下完成不同的互動。

由於是實時協同，所以不能加鎖。此外多個客戶端與同一個伺服器的通訊，其實傳送的是資料的增量，基於JSON-diff就能得到不同時刻的json增量。除此之外它的底層基於 websocket，我們用到了 js 庫SocketIO。

必須滿足：

所有客戶端和伺服器操作的順序一致

所有客戶端和伺服器操作的集合一致

為了解決多人實時編輯的問題，我們實現了一個基於版本號的實時協作演算法。上圖是服務端的操作流程，可以看到它有一個server三個客戶端，a客戶端首先向伺服器傳送請求，伺服器接收到後將head部分通過patch操作更新到最新，並且版本號自更新，最後給a客戶端回覆確認，同時將版本號以及diff廣播到其他客戶端。

客戶端方面為了能更方便的編輯，我們將節點分成三個狀態，分別是head——已確認的快照、pending——等待確認的快照、work——正在工作的快照。客戶端的版本號是嚴格遞增的，按照版本號遞增順序合併。