作者：閑魚技術-新宿
背景
在閑魚消息體系中，富文本在 UI 側占了非常大的比重。最近消息部分在整體 Flutter 化，如何解決 Flutter 側富文本問題，成為了項目早期的風險點。
在 Native 中，消息使用了 HTML 協定來承載富文本的解析與展示，由于消息的曆史資料有落庫的特性，我們必須在 Flutter 側相容這種協定。對于 Flutter，我們是否可以在相容的基礎上，進行能力的擴充與完善？
目前閑魚也在更新 Flutter 1.12，是以我們不光要在目前版本支援圖文混排，也需要快速遷移到高版本的系統方案。是以我們需要找到一個相容性高、易遷移的富文本方案。
行業現狀
行業内，對于舊版的 RichText （Flutter 1.7.3 之前）已有了解決方案，詳見玄川：《如何低成本實作Flutter 富文本，看這一篇就夠了！》。但這裡并沒有對富文本的整個鍊路的解決思路，且 Flutter 自身的 RichText 也在随着版本疊代進行演進，我們需要一套完整的演進方案。
事實上，Flutter 1.7.3 開始的 RichText 解決了我們的很多麻煩，它是怎麼實作的呢？和舊版的實作有什麼差別呢？帶着問題，我們先來分析它的實作原理。
RichText 圖文混排原理
Flutter 1.7.3 開始，RichText 不再繼承自 LeafRenderObjectWidget，而是繼承自 MultiChildRenderObjectWidget，從這就很容易看出，RichText 将是一個布局控件，内部可以有多個子控件。
建立過程：
如上圖，我們傳給 RichText 的 text 參數為 InlineSpan，TextSpan、WidgetSpan都是其子類。
- RichText 初始化過程中會将 text 中的所有 WidgetSpan 遞歸篩選出來，傳遞給父類 MultiChildRenderObjectWidget。
- 建立 MultiChildRenderObjectElement，接着 RichText 會通過 createRenderObject，生成 RenderParagraph。
- RenderParagraph 初始化過程中會建立 TextPainter，這個是繪制的核心，這裡将會進行 layout、paint 和事件分發操作；然後遞歸篩選 PlaceholderSpan (其實還是 WidgetSpan)。
渲染過程：
上圖為 RenderParagraph 内的 performLayout 函數。
- 如上圖 RenderParagraph 執行 performLayout 。首先 _layoutChildren：為子控件布局，目的為擷取子控件大小，如果沒有子控件則直接 return。這裡所說的子控件就是 WidgetSpan。
- 第二步 _layoutTextWithConstraints，就是執行 _textPainter 的 layout 方法，這裡會讓 text（InlineSpan）進行 build，此時會按照它的樹形結構周遊執行。
- TextWidget build 時會将自身的 text（這是真實的字元串）addText 給 builder。
- WidgetSpan build 時會将自身控件的 PlaceholderDimensions 資訊，addPlaceholder 給 builder。這裡其實就是添加占位符，占位符将與控件同大小。
- 緊接着 _paragraph 會進行一次布局，然後擷取各個占位符位置存儲下來。
- Paint 過程會先将帶着占位符的文本繪制完成，然後周遊子控件按照 2-3 步驟中獲得的占位符位置，設定偏移。
概括來說，新版本對比舊版本，底層多了個 _addPlaceholder 能力，用來占位混排的 Widget，并擷取位置資訊。
設計思路
我們以 HTML 協定為抓手，不光可以解決普通 HTML 字元串的解析與渲染，也可以對使用者發送的帶閑魚自定義 emoji 的字元串進行能力的擴充。下圖為大緻的設計思路：
目前消息展示分為兩種場景，一種為帶有閑魚自定義 emoji 表情的字元串：
你好[微笑]，你的寶貝不錯哦[呲牙]，包郵嗎？[壞笑][壞笑] 另一種為簡單的 HTML 字元串：
"<font color="#888888">交易全程在閑魚，</font><strong><font color="#F54444">你敢買，我敢賠！</font></strong><font color="#888888">若遇欺詐造成</font><strong><font color="#F54444">錢貨兩失，可獲賠</font></strong><strong><font color="#F54444">最高5000元</font></strong>" 當然，還有最普通的純文字。
對于這三種字元串，服務端并沒有用類型來給我們區分，用戶端拿到的都為字元串。端側該如何處理且高效展示呢？
過程設計成這樣：
- 首先對于确定為純文字的控件，直接使用單 TextSpan 的 RichText，免去 Text 的封裝。
- 使用
RegExp(r'\[[^\]\[]+\]')
[微笑]
<img src=003_微笑.png width=22.400000 height=22.400000/>
- 取最後的 HTMLString ，使用 html | Dart Package ，進行 HTML 解析，生成 HTML Node Tree
- 遞歸 HTML Node Tree
- 文本标簽映射為 TextSpan
- 圖檔标簽映射為 FDImageSpan；Flutter 更新後将其替換為 WidgetSpan，其 child 設定為 Image Widget
- 連結标簽映射為 TextSpan，定義 GestureRecognizer 相應手勢
流程上，先将閑魚自定義 emoji 占位符轉為 HTML 元素，接着統一處理 HTML 字元串。然後将 HTML 字元串統一轉為富文本。設計上，分為兩層：資料解析層、渲染層。
如上圖，有了前面原生 Flutter 圖文混排支撐，我們在低版本可以仿照實作，低版本 RichText 繼承自 LeafRenderObjectWidget，我們把 RichText 與其他 Widget 組成新的 MultiChildRenderObjectWidget，通過占位符正常渲染文本，之後擷取占位符位置，設定對應 Widget 的位置。
Flutter SDK 更新過程中如何保持業務方無感覺？先看下圖：
對比發現，在 TextSpan 樹中，我們繼承自 TextSpan 的自定義 FDImageSpan，實際上可以直接對應到原生的 WidgetSpan，這裡我們可以在 HTML Node Tree 映射到 TextSpan Tree 的過程中直接修改。而 FDRichText build 裡，我們可以直接傳回系統 RichText。這樣的改動，對于使用方可以做到無感覺。
效果
上圖中是一種最為簡單和常見的系統消息，為了突出安全警示，使用了較多的紅色字型。子產品中定義的三個富文本，均可定制樣式。
上圖為涉及互動的富文本，買家可以點選藍色文字「那兒發貨」，然後買家會自動發送「那兒發貨」給賣家，賣家會根據預設的問題自動回複買家。點選會觸發 HTML 字元串中的 href 自定義協定連結，用戶端會觸發 openURL 的操作，以此來實作互動。
這是普通使用者可以編輯發送的富文本，豐富的閑魚自定義 emoji，穿插在文字中，不僅增加了聊天樂趣，也增強了使用者的表達。
未來
目前的展示部分僅僅是圖文混排，新版本中的富文本支援任意 Widget，可玩性更高，是以我們對 HTML 标簽描述可以進行擴充，這部分未來還需要持續探索。
由于篇幅有限，上文并沒有講述富文本編輯器。消息中使用者輸入框也需支援閑魚自定義 emoji，目前版本的方案為直接使用占位符（比如“[微笑]”），并不展示實際的圖檔。我們回頭再看一下 HTML 協定，對于新版的 TextField，我們可以支援嗎？這就不僅僅局限在自定義 emoji 裡了。
我們把目光轉向釋出和寶貝詳情：
我們後續可能會支援上圖中，釋出和寶貝詳情的富文本編輯和展示。對比兩個詳情頁，很明顯能看出，使用富文本的方式，在表達上更加富有沖擊力，買家閱讀起來能很容易抓住賣家想表達的關鍵資訊。
可見，未來在富文本的編輯、展示基礎能力統一之後，可以讓更多業務收益。