背景
在閒魚消息體系中，富文本在 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 表情的字符串：
<code>你好[微笑]，你的寶貝不錯哦[呲牙]，包郵嗎？[壞笑][壞笑]/<code>
另一種為簡單的 HTML 字符串：
<code>"交易全程在閒魚，你敢買，我敢賠！若遇欺詐造成錢貨兩失，可獲賠最高5000元"/<code>
當然，還有最普通的純文本。
對於這三種字符串，服務端並沒有用類型來給我們區分，客戶端拿到的都為字符串。端側該如何處理且高效展示呢？
過程設計成這樣：
- 首先對於確定為純文字的控件，直接使用單 TextSpan 的 RichText，免去 Text 的封裝。
- 使用 RegExp(r'\[[^\]\[]+\]') 匹配 [微笑] 等 emoji 佔位符，替換為
- 取最後的 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 裡了。
我們把目光轉向發佈和寶貝詳情：
我們後續可能會支持上圖中，發佈和寶貝詳情的富文本編輯和展示。對比兩個詳情頁，很明顯能看出，使用富文本的方式，在表達上更加富有衝擊力，買家閱讀起來能很容易抓住賣家想表達的關鍵信息。
可見，未來在富文本的編輯、展示基礎能力統一之後，可以讓更多業務收益。
