淺談 JSBox 介面編輯器的實現

摘要： # JSBox 介面編輯器 JSBox 是我的一個個人專案，如果你還不知道是什麼：https:// sspai.com/post/42361 從第一個版本開始，JSBox 就支援通過 JavaScript 來寫介面，類似這樣： $ui.render({ views: ...

# JSBox 介面編輯器

JSBox 是我的一個個人專案，如果你還不知道是什麼： https:// sspai.com/post/42361

從第一個版本開始，JSBox 就支援通過 JavaScript 來寫介面，類似這樣：

$ui.render({
views: [
{
type: "button",
props: {
title: "Hey!"
},
layout: (make, view) => {
make.center.equalTo(view.super);
make.size.equalTo($size(100, 36));
},
events: {
tapped: () => {
console.log("Hey!");
}
}
}
]
});

這幾行程式碼會在螢幕中間建立一個按鈕，點選之後控制檯會輸出 Hey! ，很簡單。

最近幾個月，我花了一點時間來給 JSBox 的介面系統造了個視覺化的編輯器，不是什麼新鮮玩意，簡單說就是可以通過拖拽來構造介面：

你也可以理解成一個移動端簡化版本的 Interface Builder，這邊文章就是來介紹這個編輯器背後的一些基本原理。

# 資料儲存

這樣一個編輯器的本質是什麼？是一個 JSON 編輯器罷了（當然，很多的編輯器用 XML 做的資料儲存），我們要做的事情只不過是提供一個所見即所得的 JSON 編輯器，這個編輯器可以編輯一些檢視的屬性，比如說：

• 長寬和位置
• 繫結的事件
• 顏色、字型
• 特有的一些屬性，比如 button 會有 title

這個編輯器能解析包含上述內容的一個 JSON 檔案，用視覺化的方式進行編輯，編輯完之後能夠將上述內容序列化後存起來。

現在有一個問題，JSON 只支援下面幾種資料：

• string.
• Numeric types.
• object.
• array.
• boolean.
• null.

假設我們要把一個 UIColor 存在裡面，要做什麼？序列化唄，通過 JSON 支援的方式表達出來。序列化的思路有兩種：

• 易於人讀，例如 "RGBA(255, 255, 255, 1)"
• 易於機器讀，例如：

{
"$type": "$color",
"$props": {
"red": 238,
"green": 241,
"blue": 241,
"alpha": 1
}
}

當然，這樣一個檔案我是不希望使用者去讀寫的，他應該用於依賴於介面編輯器去操作他（回想下，除了解決衝突你應該不會去手動改一個 storyboard 檔案），甚至不需要了解這背後的儲存是什麼樣的，於是易於機器讀是我考慮的。在我的實踐裡面，就是把所有的物件都封裝成了包含 $type 和 $props 的一個 JSON，通過簡單的 JSON 解析和寫入，完成了所有型別的讀寫。

# 檢視樹

這是整個編輯器中最基本的概念，因為本質上一個 View 就是一棵樹：

{
views: [
{
views: [

]
}
]
}

他可以巢狀多層下去，所以在這麼一個編輯器中會出現很多樹的節點訪問操作，需要熟練掌握遞迴和非遞迴實現。有時候需要訪問比較深的一個節點，有時候需要獲取一個節點所有的子孩子。

# 編輯器 UI 部分

這樣一個編輯器框架其實是整個專案中最簡單的部分。最核心的部分，你需要實現一個拖動手勢用於：

• 移動一個 View 的位置
• 調整一個 View 的大小

如果不考慮 Auto Layout 的話，非常簡單（但 JSBox 支援 Auto Layout，我在後面會解釋這個問題），唯一比較麻煩的是實現輔助線效果：

這個效果的實現思路是這樣的：

• 拖動開始之後收集一下目前螢幕上所有的矩形
• 拖動過程中，檢測拖動的方向
• 根據方向列舉收集到的矩形，如果發現靠近某一條邊，就主動靠過去

這是一個最基本的模型，在實際工程中有很多優化的點，比如說根據距離來計算權值，進而決定靠近哪個檢視比較好。另外一個問題是，在支援 Auto Layout 的場景下，還需要提醒使用者當前的 Frame 和 Auto Layout 出來的結果是否一致，否則要提供警告。

# 屬性編輯器

這個編輯器可以這樣編輯每個 View 的屬性：

其實實現這些東西並沒有多少技術難度，但是卻極為繁瑣，基本可以認為是體力活，但我們有必要通過簡單的協議來實現所有的檢視型別，比如說現在 JSBox 支援的 20 幾種檢視：

假設你已經實現了這些子編輯器：

• 顏色選擇器
• 字型選擇器
• 日期選擇器
• ...

這些都是體力活，能夠編輯單一的屬性。現在我們要歸類所有的檢視支援的屬性，有哪些型別，比如：

• 整數
• 浮點數
• 字串
• 顏色
• 字型
• 日期
• 各種列舉值
• ...

把這些收集起來是為了造一個對映表，比如說對於 button 他可能有這樣一個表：

• title: string
• titleColor: color
• font: font
• image: image
• ...

然後我們在編輯某一個具體的檢視時，就可以通過對映表動態的生成屬性編輯器支援的屬性。在具體的工程實踐中，會有很多麻煩的問題，比如說有些屬性是複合結構：

• UISegmentedControl 支援一個字串陣列
• UITableView 的 cell 本身是個 View

當然這些困難都存在於實踐的層面，並沒有引入多少新的概念，所以不是什麼大問題，花點時間都可以克服。

# 事件繫結

在上面的圖中，點按鈕會彈出一個視窗，那是因為這個按鈕綁定了一個事件。這個事情有一點點複雜，首先的一件事情是，每個介面檔案都實際上包括兩個檔案：

• views.json 用於定義介面
• actions.js 用於定義行為

有點像 iOS 裡面的 storyboard 和 swift 檔案的關係，雖然現在 JSBox 不支援動態的繫結這兩個檔案，但原理大致是一樣的。假設使用者把 button 的 tapped 繫結到了 tapped 函式，那麼在 views.json 裡面會生成這樣一個節點：

{
"tapped": {
"$type": "$event",
"$props": {
"selector": "tapped"
}
}
}

解析器遇到這樣一個節點，會把他解析成一個事件，然後在 actions.js 裡面找到他完成呼叫，這裡還涉及到一些更復雜的話題，我就只簡單提一下。在 JavaScriptCore 裡面，如果你把所有的函式都寫在 Global 下面，例如：

function tapped() {

}

如果這些函式都在 Global，你可以很方便的呼叫，但是 JSBox 是支援模組化引入 js 檔案的，很多函式在別的 scope，這件事就變得稍微麻煩一點了。我在實際實踐中，會把函式繫結在 exports 上面，然後通過 module loader 把他載入進來，最後通過 JavaScriptCore 把事件轉發過去完成呼叫：

exports.tapped = () => {

}

實際呼叫類似於引入了一個模組：

const actions = require("actions.js");
actions.tapped();

當然，JavaScriptCore 是沒有 module loader 的，你需要自己寫一個。另外有一個提升使用者體驗的點，就是列出 actions.js 裡面已經有的函式，使用者可以直接把他繫結起來。

實現這樣一個邏輯，你需要一個 Parser 用來把 actions.js 解析成一個 AST，比如 Acorn 或 Esprima，在這裡可以玩一下： https:// astexplorer.net/

acorn 會把 actions.js 生成這樣的一個 AST:

{
"type": "Program",
"start": 0,
"end": 24,
"body": [
{
"type": "FunctionDeclaration",
"start": 0,
"end": 24,
"id": {
"type": "Identifier",
"start": 9,
"end": 15,
"name": "tapped"
},
"expression": false,
"generator": false,
"params": [],
"body": {
"type": "BlockStatement",
"start": 18,
"end": 24,
"body": []
}
}
],
"sourceType": "module"
}

最後，你需要從這個 AST 中找出最外層的所有函式，他們就是使用者可以繫結的函式。如何把這樣的 parser 跑在 JavaScriptCore 上面？這又是另一個比較大的話題，之後有空再介紹。

# Auto Layout

如果只是支援 Frame 佈局的話，實現這樣一個編輯器其實是比較簡單的，但 JSBox 還做了對 Auto Layout 的支援：

首先，Auto Layout 的本質是多個一次的方程或者不等式：

• view1.attr1 = view2.attr2 * multiplier1 + constant1
• view1.attr2 >= view2.attr3 * multiplier2 + constant2
• ...

iOS 通過某一時刻的一些已知量來求解儘可能滿足所有式子的一組解，當不能滿足所有方程時通過 break 掉一些優先順序低的式子。如果出現多個解，或者沒有解，我們稱之為有歧義的佈局。

上面說的這些式子，就是約束，或者更具體點，在 iOS 上面就是很多的 NSLayoutConstraint。Auto Layout 有很多的實現方式，我們需要的，其實恰恰是最臭名昭著的這個 API:

+(instancetype)constraintWithItem:(id)view1 attribute:(NSLayoutAttribute)attr1 relatedBy:(NSLayoutRelation)relation toItem:(nullable id)view2 attribute:(NSLayoutAttribute)attr2 multiplier:(CGFloat)multiplier constant:(CGFloat)c;

為什麼？因為其他的 API 其實都是一些封裝，但是這個 API 它本身就是我們上面說的那個方程，它符合 a = b * m + c 的定義，非常適合我們的編輯器去解析和描述他。所以我們只要歸納一下約束的型別以及約束關係，就能製作出這樣一個編輯介面：

當然有些麻煩的事情要解決，比如上面說的介面編輯器，上面的檢視其實是通過 frame 完成佈局的，否則將會碰到更多的麻煩。這就涉及到一個如何將 Auto Layout 對映到一個具體的 Frame 佈局的問題。

另外，但使用者拖動了一個有約束的檢視時，會造成錯位的問題，可以通過類似的方式找出錯位並提供解決方案：

最後一個問題，是發現有歧義的佈局，什麼樣的佈局有歧義？

• 當前的約束無法唯一的描述一個佈局，例如缺少的對寬度的約束
• 當前的約束存在對同一個屬性產生不同的結果的狀況，例如三個約束無法同時滿足

知道什麼樣的約束是有歧義的，就可以求解出一組約束是不是有歧義，同時 UIView 有這麼幾個功能也可以幫助你：

• hasAmbiguousLayout
• exerciseAmbiguityInLayout
• constraintsAffectingLayoutForAxis

# 總結

以上就是 JSBox 介面編輯器的一些原理，功能很早就上線了，歡迎在 App Store 上面下載體驗。當然，這樣一個巨大的工程是不可能一下子就做得很好的，目前也只是剛剛能跑的階段，還需要很多優化工作。

這篇講到這裡，謝謝。