一、前言

之前在《富文本編輯器之游戲角色升級 ing》一文中，跟大家分享了富文本編輯器的發(fā)展歷程、選型技巧和擴展方案。今天將和大家一起聊一聊“富文本及編輯器跨平臺方案”那些事。

大家應(yīng)該注意到了，標(biāo)題用的是“富文本及編輯器”，而非“富文本編輯器”。也就意味著本文將圍繞富文本跨平臺和編輯器跨平臺兩大部分進(jìn)行介紹。

通過跨平臺方案的分享，希望能給有富文本編輯器跨平臺相關(guān)需求的小伙伴帶來一些幫助。

二、為什么要跨平臺

對于一個產(chǎn)品來說，用戶的需求程度在一定程度上反映了其產(chǎn)品的價值。對于富文本編輯器而言，以?WEB 端（PC 瀏覽器、移動瀏覽器）、移動端（IOS 應(yīng)用、Android 應(yīng)用）、桌面端（windows、macOS）各自為戰(zhàn)的系統(tǒng)生態(tài)，已經(jīng)無法滿足用戶的需求。同時對于研發(fā)人員而言，各端都需要大量的資源投入進(jìn)行重復(fù)能力的開發(fā)，這無疑是一種資源的消耗。因此越來越多的團(tuán)隊開始尋求突破，建立跨平臺的編輯生態(tài)，在不同的平臺、不同的終端上實現(xiàn)數(shù)據(jù)互通，展現(xiàn)體驗一致的編輯能力。

（圖片來源于網(wǎng)絡(luò)）

上面是比較籠統(tǒng)的概念，舉例子說明下：

社交類型的應(yīng)用

以微博中的場景為例：假如你用電腦網(wǎng)頁版微博發(fā)布了一篇長文，然后分享給了你的朋友，期間發(fā)現(xiàn)內(nèi)容可能需要編輯下。這個時候問題來了，你是傾向于放下手機打開電腦編輯，還是直接切到手機微博來編輯。我猜絕大多數(shù)小伙伴應(yīng)該會選擇用手機微博進(jìn)行編輯，那么我們就可以發(fā)現(xiàn)在這個過程中經(jīng)歷了?Web 端發(fā)表–微信小程序查看–APP 端編輯幾個階段，這其中的流轉(zhuǎn)其實就是跨平臺操作。

記錄類型的應(yīng)用

以手機端便簽應(yīng)用為例：越來越多的用戶習(xí)慣用便簽之類的應(yīng)用記錄一些生活事項，那這些記錄是僅存儲在本地設(shè)備中的嗎？NO! 如果僅存儲在本地，那么換臺手機或者清除數(shù)據(jù)后，數(shù)據(jù)就無法找回了，這必然不符合大眾的需求。大部分記錄類應(yīng)用的數(shù)據(jù)是存儲在云端的，使用云端存儲既能滿足跨設(shè)備的數(shù)據(jù)遷移，同時帶來了跨平臺可瀏覽、可編輯、可刪除的附加價值。

以上，簡單介紹了富文本編輯器跨平臺的兩個應(yīng)用場景，可以看出富文本編輯器跨平臺已經(jīng)成為一種必然的需要。既然已經(jīng)清晰了為什么要跨平臺，下一步我們就來探討下如何實現(xiàn)跨平臺。

三、富文本跨平臺

富文本，在這里指代“編輯器所輸出的數(shù)據(jù)”。富文本的跨平臺，實質(zhì)上就是使富文本在不同平臺內(nèi)以其原生的方式展示相同的效果。

注：在本章節(jié)中探討的場景主要是 WEB 端的富文本 HTML 如何可以在 Android、小程序中展示原生的效果。

有朋友也許會問，HTML 在 Android 內(nèi)可以用 HTML.fromHtml 方法解析展示富文本內(nèi)容。微信小程序也可以用 rich-text 富文本組件直接渲染，既然用 HTML 就可以跨平臺展示，為什么還要單獨拆分一個章節(jié)探討呢？對于這個問題，首先給大家分別展示下用 HTML 數(shù)據(jù)渲染在不同平臺中可能出現(xiàn)的問題：

從上圖中可以看出，HTML的優(yōu)點是特性豐富，靈活多變。而正因如此，其很難嚴(yán)格的定義數(shù)據(jù)。因此若是將HTML作為流轉(zhuǎn)的數(shù)據(jù)，很容易在不同平臺內(nèi)出現(xiàn)解析兼容問題。

那么要在不同平臺間實現(xiàn)一致的展示效果，有兩種方案作為參考：

• 方案一：將 HTML 強制轉(zhuǎn)化為各平臺都能正常適配的層級結(jié)構(gòu)。

• 方案二：利用一種通用的可供各端解析的數(shù)據(jù)模型，各端用原生組件解析渲染。

方案一雖然可以通過枚舉不兼容的場景正則替換，將源數(shù)據(jù)轉(zhuǎn)化為各平臺均可以正常解析的 HTML，但是從可擴展性的角度上來說，枚舉替換的方案不太現(xiàn)實。既然如此，那就一起看看如何通過方案二實現(xiàn)。

通用的數(shù)據(jù)模型

考慮到 HTML 轉(zhuǎn)化中存在的問題，那么通用的數(shù)據(jù)模型需要滿足以下條件：

• 描述文檔層級結(jié)構(gòu)

• 嚴(yán)格定義嵌套規(guī)則

• 制定數(shù)據(jù)過濾機制

下圖分別對比了使用 JSON、XML 作為數(shù)據(jù)模型的優(yōu)缺點，可以根據(jù)項目需要酌情選擇：

之前分享的文章中，L2 階段的富文本編輯器的數(shù)據(jù)模型多是 JSON 結(jié)構(gòu)，本節(jié)直接沿用之前的例子展開介紹下 JSON 數(shù)據(jù)模型是如何滿足以上三個條件的：

遵循條件規(guī)范，定義好數(shù)據(jù)模型后，此時數(shù)據(jù)在各平臺間的流轉(zhuǎn)過程就如下圖所示：

整個流程總結(jié)下來就是：以通用數(shù)據(jù)模型作為媒介，打通 WEB 端與 Android、小程序的數(shù)據(jù)互通，在各平臺用原生的組件渲染頁面，最終實現(xiàn)富文本的跨平臺。

本節(jié)解決的問題是：WEB 端產(chǎn)出的富文本內(nèi)容，在各平臺如何得到最本源的展示效果。那么如何保證各個平臺都是輸出相同的數(shù)據(jù)模型呢？這也就引入了下節(jié)的內(nèi)容——編輯器的跨平臺。

四、編輯器跨平臺

編輯器跨平臺，是指由各平臺提供功能模塊，WEB 端提供排版編輯能力，最終運行在平臺特定的瀏覽器環(huán)境中。本節(jié)將以 Android App 的編輯器實現(xiàn)為例進(jìn)行展開，其他平臺的編輯器實現(xiàn)原理相同。

以便簽 APP 為例，富文本內(nèi)容編輯模塊運行在由Native App 提供的 Webview 環(huán)境中，其工具欄菜單、狀態(tài)顯示部分則由 Native App 原生控件組成。

為什么不選擇直接用 Native 編輯器或者 Web 編輯器，而是選擇這樣組合的形式呢？

首先，如果選擇單一的編輯器或多或少存在一些問題，比如說：

• Native 編輯器實現(xiàn)復(fù)雜富文本結(jié)構(gòu)的開發(fā)成本較高，需要定制很多功能模塊；

• Web 編輯器在 Native APP 中操作能力有限，且交互體驗不及 Native 原生控件。

那么兩者“取其精華”，選擇保留 Web 端富文本豐富靈活的排版能力，同時用 Native 原生控件關(guān)聯(lián)用戶操作，最終實現(xiàn) 1+1>2 的效果。具體體現(xiàn)在：

• 靈活展示豐富的富文本內(nèi)容；

• 不同平臺的核心編輯代碼可復(fù)用，降低跨平臺編輯器的開發(fā)成本；

• 具備系統(tǒng)級控制權(quán)限，極大地擴展了編輯器的能力組成(語音、圖片編輯等)；

4.1 如何實現(xiàn)一個跨平臺的編輯器？

跨平臺編輯器重點需要解決的問題有兩點：

Native App 與運行在 webview 中的編輯器如何數(shù)據(jù)通信？

Native 工具欄如何跟隨光標(biāo)位置呈現(xiàn)不同的狀態(tài)？

首先，介紹下跨平臺的編輯器，各模塊之間是如何交互的。

• 編輯器會開放一些接口如 setData、getData、execCommand，供 Native APP 調(diào)用，向編輯器內(nèi)添加內(nèi)容。

• Native APP 也會向編輯器提供一些接口，如 viewLoad、requestMedia、updateBtnStatus。編輯器可以根據(jù)自身的狀態(tài)，通過這些接口向 APP 內(nèi)傳遞一些數(shù)據(jù)或者信號，使得 APP 內(nèi)的各種控件狀態(tài)得到刷新。

• Web 編輯器僅與 Native APP 建立通信，與服務(wù)端的數(shù)據(jù)交互交由 Native APP 完成。

下面，將介紹幾個跨平臺編輯器的核心場景實現(xiàn)，供大家參考。

4.1.1 頁面初始化

跨平臺編輯器的編輯頁由 Native APP 和 Webview 中的 Web Editor 組成，那么意味著頁面的初始化需要兩個模塊協(xié)同實現(xiàn)。

一般情況下 Native APP 中原生控件的渲染速度是要快于 Webview 的渲染，這里可以在 Editor loaded 之后，調(diào)用 Native APP 提供的初始化方法，將 Native APP 從 Loading 狀態(tài)切換至完成態(tài)。

假設(shè)此時保存有草稿，可以在頁面 Load 后，直接調(diào)用 Editor 暴露的 setData 方法，初始化編輯器數(shù)據(jù)。

4.1.2 數(shù)據(jù)通信

在編輯過程中，必然存在 Native APP 與 編輯器的雙向通信，就以簡單的插入表情為例，整個操作流程分為以下幾個步驟：

1、點擊表情按鈕，從鍵盤狀態(tài)切換至表情選擇面板，此時都屬于 Native APP 內(nèi)部操作流程。

2、當(dāng)點擊某個表情后，就需要 Native APP 主動與編輯器建立通信，通知編輯器需要執(zhí)行插入表情的操作。

3、編輯器接收到插入表情的指令后，插入 Native APP 流轉(zhuǎn)過來的表情數(shù)據(jù)，同時觸發(fā)了編輯器內(nèi)部的狀態(tài)刷新，比如說字?jǐn)?shù)計算、歷史記錄的刷新。

4、由于現(xiàn)在的撤銷、重做按鈕已經(jīng)不在編輯器內(nèi)部，當(dāng)歷史記錄刷新時，需要對按鈕的狀態(tài)進(jìn)行重置。這個時候就需要編輯器調(diào)用 Native APP 提供的狀態(tài)刷新方法，通知 Native APP 進(jìn)行按鈕狀態(tài)的更新。

這樣就完成了兩個模塊的雙向數(shù)據(jù)通信。

4.1.3 媒體嵌入

媒體嵌入是富文本編輯器中必不可少的一部分，這里單獨拿出來介紹，主要是因為跨平臺的富文本編輯器在上傳資源到服務(wù)端時，并不是常規(guī)的通過編輯器本身來實現(xiàn)的。那中間的處理邏輯是怎樣的呢？

Native APP 圖片選擇的流程就不過多贅述，直接進(jìn)入到選擇之后上傳的部分。Native APP 選擇圖片之后，直接會調(diào)用服務(wù)端的接口將圖片上傳，與此同時還會攜帶選擇的圖片信息（本地路徑、寬高信息等等）傳遞給編輯器。

由于圖片上傳與圖片插入存在一定時間差，所以編輯器在最初接收到插入圖片的命令后，默認(rèn)處理為 loading 狀態(tài)，等待 Native APP 上傳完成的信號。

當(dāng)服務(wù)端接口返回圖片加載完成的信息后，Native APP 調(diào)用編輯器預(yù)先提供的接口，控制編輯器中某張圖片刷新為完成時態(tài)。這樣就實現(xiàn)了資源的上傳及插入:

4.2 踩坑實踐了解一下！

當(dāng)然，不是所有的事情都是一帆風(fēng)順的。我在開發(fā)過程中，也踩了一些坑，跟大家分享下。

4.2.1 鍵盤的控制

預(yù)告：由于我使用的 Web 編輯器仍然依賴瀏覽器的 contenteditable 特性，所以下面的案例，并不具備普適性，大家僅供參考。

基于 contenteditable 的編輯器，在光標(biāo)插入的時候，會自動喚起手機端的輸入法鍵盤。有些場景下，比如插入圖片后，預(yù)期鍵盤處于關(guān)閉狀態(tài)。但是在實際操作時，鍵盤會默認(rèn)喚起，即系統(tǒng)鍵盤不受編輯器控制。

針對這種情況，我嘗試了一些解決方案，最終選擇采用雙管齊下的方式，增加雙重保險：

• 在 Editor 插入操作執(zhí)行前，增加禁用編輯和啟用編輯的切換，利用切換的時間差，將系統(tǒng)鍵盤的自動喚起機制失效。

editor.setAttribute('contenteditable', 'false') setTimeout(() => {editor.setAttribute('contenteditable', 'true') }, 150)

• Native APP 提供控制鍵盤彈出、收起的方法，在 Editor 需要的時候調(diào)用系統(tǒng)能力實現(xiàn)控制自由。

JsBridge.call('updateKeyBoardState', { keyBoardState: true/false })JsBridge.call('updateKeyBoardState',{ keyBoardState: true/false })

4.2.2 資源的失敗重試

在編輯器中，資源上傳失敗均會配備重新上傳的機制。在跨平臺編輯器中，重新上傳需要在 WEB 編輯器中觸發(fā)，交由Native APP 重新上傳。Native APP上傳圖片的前提是拿到圖片的本地路徑。因此在前期設(shè)計時就需要重點關(guān)注以下幾個點：

• Native APP 在調(diào)用編輯器插入圖片的接口時，就需要告知圖片對應(yīng)的本地路徑，也作為后續(xù)狀態(tài)刷新、失敗重試的參照條件。

• 要增加本地路徑異常失效的處理（本地圖片刪除、移動等）。

讀到這里，各位小伙伴對于如何實現(xiàn)一個跨平臺的富文本編輯器，是否已經(jīng)胸有成竹了呢。本節(jié)只是探討了?Android APP?這一種平臺的場景，對于其他的平臺其實也是如此，比如桌面端平臺（Windows、Mac）的客戶端中，可以選擇用 CEF（Chromium Embedded FrameWork）提供瀏覽器環(huán)境。感興趣的小伙伴可以動手嘗試一下。

五、總結(jié)

本篇文章聚焦富文本跨平臺和編輯器跨平臺兩個角度，分析了為什么要通過跨平臺的方案實現(xiàn)富文本 編輯器、以及如何實現(xiàn)兩類的跨平臺，其中重點介紹了跨平臺編輯器的核心流程和踩坑實踐。

到此，關(guān)于富文本編輯器的分享已經(jīng)接近尾聲。通過這篇內(nèi)容的介紹，希望大家在遇到諸如此類的需求時，可以觸類旁通，順順利利的將方案落地。

參考資料

1、rich-text ｜微信開放文檔(opens new window)

2、有道云筆記跨平臺富文本編輯器的技術(shù)演進(jìn)

作者：vivo互聯(lián)網(wǎng)服務(wù)器團(tuán)隊-Tian Yuhan

總結(jié)

以上是生活随笔為你收集整理的富文本及编辑器的跨平台方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。