打造Flutter高效能富文字編輯器——協議篇

語言: CN / TW / HK
時間 2022-05-19 09:15:09
主題:

作者：閒魚技術——光酒

閒魚作為一個二手閒置交易平臺，賣家釋出商品產出優質的供給尤為重要；商品釋出器希望擁有富文字編輯能力，讓使用者簡單便捷的方式產出更加優質的內容；Flutter本身沒有富文字編輯器的能力的，只有最基礎的文字編輯器TextField；對於更加複雜的場景，比如支援自定義表情、主題、有序段落等能力，目前flutter元件是無法滿足我們的業務訴求，另外在互動體驗上與Native仍然存在一定的差距；為了解決業務中面臨的以上問題，我們決定設計並實現一個Flutter場景下高效能、可擴充套件的富文字編輯器。

富文字編輯器整體架構設計

首先我們來看一看整體的架構設計分層：

p0

自下而上主要分四層：

  1. 1. 協議層：主要負責Model的定義、Selection描述、Commond事件邏輯處理，以及協議Normalizing校驗；
  2. 2. 能力擴充套件層：能力擴充套件層提供豐富的plugin能力，既有內建的plugin，如：純文字轉換，undo/redo等能力，同時也非常方便的支援業務層自定義的擴充套件，例如支援站外H5頁面展示的model to HTML的序列化plugin；
  3. 3. 渲染層：渲染層主要實現將富文字Model轉換成Flutter Widget渲染，以及游標、選區、ToolBar等計算和渲染，以及使用者手勢互動事件等；
  4. 4. 業務擴充套件層：在Mural的設計之初，可擴充套件就是設計過程中非常重要的一部分，我們為業務方提供了非常靈活、功能強大的擴充套件能力，通過自定義Node、Plugin、Normalizing，實現如自定義表情、主題、段落、語法高亮等能力；

協議層設計

富文字編輯器對大家來說並不陌生，發展至今，已經湧現出非常多有優秀的開源富文字編輯器；當我們想要做Flutter富文字協議的時候，第一個想法就是先了解優秀的開源富文字編輯器方案，避免閉門造車；

目前比較優秀的開源富文字編輯器，如CKEditor、Quill、Prosemirror、Draft、Slate等等；在瞭解和對比過後，我們決定使用Slate作為我們的富文字編輯器的協議；

why Slatejs

我們為什麼選擇Slate？

p4

外掛是一等公民，能夠很好的滿足我們對於擴充套件性的要求； Slatjs在設計上支援巢狀結構，可以滿足複雜的業務場景；

與Dom相同的Data model，對於後面flutter渲染層的實現，也變得更加方便；

直觀的指令設計，能夠非常好的支援plugin的自定義擴充套件；

Slate在設計上，協議層與渲染層是有明確的核心劃分，這讓我們可以複用Slate協議層的設計，渲染層交給flutter來處理；

除了上面的原因，我們選擇Slate另外一個很重要的原因，就是它的單元測試覆蓋率和完整度，讓我們對它的穩定性更有信心；

Slate協議層設計

協議層的整體架構設計如下圖：

arch

下面我們就以Slate為例，來看一看富文字編輯器的協議層設計，需要定義的核心概念和模組：

  1. 1. 巢狀Model定義；
  2. 2. 原子能力Operation設計；
  3. 3. 秩序維護者Normalizing的設計；

協議層設計——巢狀Model設計

Slate定義了三種類型的Node節點：

  • • Editor：包含整個文件內容的根節點;
  • • Element：在自定義域中擁有語義的容器節點；
  • • Text：包含文件文字的葉子節點;

dom_tree

Editor

Editor抽象介面定義如下：

abstract class BaseEditor {
  BaseEditor();
  Selection selection;
  List<Operation> operations;
  Map<dynamic, dynamic> marks;

  bool isInline(Element element);
  bool isVoid(Element element);
  void normalizeNode(Tuple2<Node, Path> entry);
  void onChange();
  void addMark(String key, dynamic any);
  void apply(Operation operation);
  void deleteBackward(String unit);
  void deleteForward(String unit);
  void deleteFragment(String direction);
  List<Descendant> getFragment();
  void insertBreak();
  void insertFragment(List<Node> fragment);
  void insertNode(Node node, {Location at});
  void insertText(String text);
  void removeMark(String text);
}

Element

Element節點比較特殊，既是Ancentor節點，作為容器節點包含子節點；同時又是Descendant節點，可以作為其他容器節點的子節點存在。

  • • 塊(Blocks)：Element預設為Block型別的節點，也就是獨立的一個段落；在Slate協議設計中，一個段落是不允許存在換行符的，當輸入換行符的時候，就會生成一個新的Block型別的Element；
  • • 行內(Inlines)：同時Element也可以是Inline型別的節點，作為另外一個Element的巢狀子節點存在，作為行內元素渲染在一行；
  • • 空元素(Void)：Element也可以是Void型別，這裡Void與HTML中Void的是同一個概念：如果某個Node為Void，則表示這個Node節點是不可編輯狀態，游標無法定位到節點內部，會被整體輸入和刪除；比如：@某個人、主題、富文字中的圖片或者影片等等；

Text

Text節點是樹中的最低階葉子節點，描述了文字內容以及其他自定義的渲染元素；所有的自定義屬性都包含在properties屬性中：

class Text implements Descendant {
  String text;

  Map<String, dynamic> properties;

  Text({@required String text, Map<String, dynamic> properties})
      : this.text = text ?? '',
        this.properties = properties ?? <String, dynamic>{};

  @override
  String string() {
    return text;
  }

  @override
  Text clone() {
    return Text(text: text, properties: Map.from(properties));
  }

  @override
  String nativeString() {
    return text;
  }
}

我們以下面這這段富文字為例：

p1

最終這樣一段富文字對應的Mode定義如下：

6

可以看到，Model的樹形結構還是比較簡單的，所有的屬性都存放在properties欄位中，這也非常方便實現自定義擴充套件；Flutter渲染層根據Node節點的Type以及properties屬性，將富文字內容渲染到螢幕上；

協議層設計——原子能力Operation

接下來需要富文字Commond協議的設計，使用者的每一次的文字輸入、刪除、文字加粗、換行等操作都是一次Command指令；Slate抽象定義了九個最基本的Operations，協議層所有的Commond指令，最終在協議層，都會轉換成一個或者多個operation操作：

  • • insert_node：插入Node節點；
  • • insert_text：插入文字；
  • • merge_node：合併相同屬性的Node節點；
  • • move_node：移動Node；
  • • remove_node：刪除Node；
  • • remove_text：刪除文字；
  • • set_node：設定Node屬性；
  • • set_selection：設定Selection；
  • • split_node：拆分Node；

下面我們通過對選中文字加粗操作為例，來了解Slate協議層Commond的處理過程：

10

對選中文字加粗這樣一個Commond，協議層會將這個Commond拆解成三個Opeartion：

  • • split_node：將一個Text Node拆分成三個Text Node;
  • • set_selection：更新游標選擇區域Selection；
  • • set_node：設定需要加粗Text Node節點properties的加粗屬性；

當一個Commond被協議層拆分成一個或者多個Opeartion執行之後，會執行一個非常重要的操作——Normalizing；

秩序維護者——Normalizing

每一次Command操作，絕大部分情況會對Model進行相應修改；我們需要一個秩序維護者——Normalizing，時刻保證對協議Model修改過之後，保持資料結構的正確性；

Slate定義了幾個基本的內建Normalizing規則：

p10

每一次Commond之後，Editor都會呼叫normalizeNode方法，在Normalizing的過程中，發現存在協議結構錯誤，需要進行錯誤修復；

Normalizing的另一個強大之處在於，我們可以通過自定義Normalizing，新增自定義的校驗規則，實現自定義的需求；在後面的業務擴充套件章節會，我們會具體講解如何通過自定義Normalizing快速實現一個自定義主題的能力；

總結

目前Mural已經在閒魚商品釋出、商品詳情、訊息等場景落地，支援了自定義表情、主題等業務能力，使用者體驗方面也有了非常大的提升。

本次主要介紹了富文字編輯器Mural整體的架構設計以及協議層的設計；後續我們會系列文章的方式介紹Mural在渲染層的設計、自定義擴充套件設計，以及互動體驗、效能方面的優化實踐，敬請期待！

參考連結： [1] Slate：http://github.com/ianstormtaylor/slate

「」