[[172100]]

背景

最近我們微信讀書將寫想法換成了基于webview的富文本編輯器，遇到了不少問題，這里我將簡單的介紹一下我們在開發(fā)過程中踩到的坑。

實現(xiàn)富文本編輯器有兩個基本思路：

• 基于native實現(xiàn)：比如coretext或者textkit
• 基于uiwebview實現(xiàn)

第一種方案，你需要自己去實現(xiàn)很多在webview已經(jīng)很成熟的效果，比如鏈接，字體加粗，標(biāo)題，引用樣式，列表樣式等等，這些的工作量都比較可觀，而且還有ios/android兩個端的對齊問題。還有一個問題，這個可能是我們項目相關(guān)的問題，我們在原來還沒有很多富文本要求的情況下，在textview上做了一些我們對鏈接的處理工作，僅僅這一個方面，當(dāng)時就覺得不是很方便。

第二種方案，你可以借助webview省掉很多在第一種方案里面提到的工作，同時webview相對而言，開源的可供參考的項目也更多一點，不過webview也會存在光標(biāo)的控制，css的沖突處理以及兼容性的問題，不過在最終選擇方案的時候，我們幾經(jīng)權(quán)衡，最終選擇了webview的方案

基于webview的富文本編輯器的光標(biāo)及樣式問題

uiwebview實現(xiàn)富文本編輯器，一個大麻煩在于光標(biāo)的處理，另一個大麻煩就是css樣式的兼容，具體體現(xiàn)為如下幾個方面：

1. 如何保持光標(biāo)在可見區(qū)域。
2. 插入表情的時候uiwebview會失焦問題。
3. 原生命令會有bug,需要自己處理。
4. 樣式的兼容性。
5. at以及話題的鏈接處理。

如何保持光標(biāo)在可見區(qū)域

這里有很多情況，如我們在當(dāng)前可見區(qū)域的最后一行的時候，再進(jìn)行換行時，光標(biāo)會跑到可見區(qū)域的下面，webview不會把光標(biāo)所在位置自動滾動到可見區(qū)域，需要手動觸發(fā)webview的滾動機制.

解決這個問題有兩個思路，一種思路就是hack native的滾動邏輯，對滾動進(jìn)行修正處理，這樣做，能使得webview滾動表現(xiàn)的像native一樣，但是需要hack的地方會比較多，實現(xiàn)起來可能會踩吭。另外一種思路就是直接在js里面操作scrollview，這樣相對比較簡單。我們使用的是后者的做法，通過監(jiān)聽光標(biāo)位置的變化，來進(jìn)行修正，代碼如下：

   document.addEventListener("selectionchange", function(e) { 
       RE.calculateEditorHeightWithCaretPosition();//矯正位置 
});  

這里矯正的具體邏輯是，每次光標(biāo)位置發(fā)生變化時首先計算當(dāng)前光標(biāo)的位置，然后判斷當(dāng)前光標(biāo)是否在可見區(qū)域范圍內(nèi)，如果不在，那么執(zhí)行window.scrollTo滾動到響應(yīng)區(qū)域。這里有個小點需要注意，就是在判斷光標(biāo)位置的時候，頂部以及底部的判斷有稍微的區(qū)別，如果判斷光標(biāo)是在可見區(qū)域上面，需要判斷光標(biāo)的頂部是否在可見區(qū)域范圍內(nèi)，如果斷光標(biāo)是在可見區(qū)域下面，需要判斷光標(biāo)的底部是否在可見區(qū)域范圍內(nèi)。

這里還有一個問題，在最后一行，換行到新的一行進(jìn)行輸入的時候，如果是漢字輸入，會產(chǎn)生聯(lián)想輸入條，在還沒有確定輸入內(nèi)容的時候，uiwebview是不知道你需要的高度的，這個時候，由于觸發(fā)了selectionchange，會導(dǎo)致輸入時候，整個界面不斷的抖動，因此在這里使用了一個奇技淫巧的方案。我們監(jiān)聽input的輸入，并在在webview的最后面，強制插入一個空白的div，使得輸入始終是在已有的區(qū)域范圍內(nèi)的。

另外切記不要在js,以及native兩端都由scroll的操作，這樣會導(dǎo)致滾動的邏輯很混亂。

插入表情，光標(biāo)的變化

在我們的場景中，插入表情會彈出一個表情面板(這應(yīng)該也是主流的做法)，這個表情面板會覆蓋鍵盤，這樣會導(dǎo)致uiwebview失焦。這就意味著，我們在插入表情的時候，不能直接使用Inserthtml命令插入，因為在失焦?fàn)顟B(tài)下這個命令會失效，因此在這里需要手動找到正在操作的node，手動執(zhí)行Insertnode的操作，并且要記錄光標(biāo)的變化位置，以便退出面板退出后，重新foucus找到正確的光標(biāo)位置。簡單的偽代碼如下代碼

// 這時候光標(biāo)直接parent是editor，需要判斷光標(biāo)所在的node的nodeIndex，然后將imgNode 插入到parent[nodeIndex]之前 
           if(currentOffset == currentNode.childNodes.length){ 
               // 光標(biāo)在editor最后或者editor內(nèi)容為空，直接append 
               currentNode.appendChild(imgNode); 
           }else{ 
               currentNode.insertBefore(imgNode, currentNode.childNodes[currentOffset]); 
           }  

然后更新一下當(dāng)前selection，同時在表情面板刪除表情的時候，也需要做類似的操作。

表情還有一個問題，就是在webview里面插入表情之后，傳給后臺的時候，因為ios/android兩個平臺的表情本地文件名，樣式有所區(qū)別，因此要轉(zhuǎn)化成[發(fā)呆]這個格式。

原生api的坑

前面在提到webview的優(yōu)點的時候說過，webview很吸引人的一個地方在于其提供了很多原生的接口來實現(xiàn)一樣樣式，但是，真正操作起來才發(fā)現(xiàn)，套路遠(yuǎn)比我們想象的要深。

舉一個簡單的例子你要實現(xiàn)加粗以及取消加粗，那么一個命令就能搞定。 

document.execCommand('bold', false, null); 

同樣的，按照文檔的介紹，如果如果你想要操作quote格式，改成一下命令就好了

document.execCommand('formatBlock', false, "<blockquote>") 

然而上面這個命令只能讓你添加引用格式，如果要取消引用格式，你會發(fā)現(xiàn)然而并沒有卵用，就需要自己另外想辦法了。這里有一個哥們對于quote的悲催經(jīng)歷 ，不過我們最后的處理方案和他略有不同，我們是通過判斷當(dāng)前光標(biāo)所在的Node是不是有blockquote標(biāo)簽或者是不是含有blockquote標(biāo)簽的Node的子node來決定是添加引用還是取消引用，偽代碼如下：

if (inQuoteBlock.is) { 
        document.execCommand('formatBlock', false, "<div>") 
    } else { 
        document.execCommand('formatBlock', false, "<blockquote>") 
        }  

同樣的還有標(biāo)題設(shè)置等等都有這樣的問題。

樣式的兼容性

這個問題發(fā)生在多個樣式并存的情況，比如引用、標(biāo)題、序列格式、高亮鏈接混在一起用會發(fā)現(xiàn)各種奇奇怪怪的問題。

以我們碰到的一個引用和高亮鏈接混用的例子來說明。我們先使用引用格式 blockquote,然后在引用文字里面插入一個a標(biāo)簽，接下來再次輸入其他文字的時候，會發(fā)現(xiàn)系統(tǒng)幫我們偷偷的加了一個span標(biāo)簽，這個標(biāo)簽有它自己的style,導(dǎo)致后面樣式跟前面的不一致了。

再舉一個例子，我們開發(fā)的時候測試發(fā)現(xiàn)一個bug，就是當(dāng)引用、標(biāo)題、序列格式同時運用到一段文字的時候，會發(fā)現(xiàn)系統(tǒng)默默的幫你插入了一個div標(biāo)簽，這個也會導(dǎo)致一些莫名奇妙的格式問題。

當(dāng)然還有一些其他奇奇怪怪的問題，這些其實是css樣式的問題，對于這些問題的處理，要么自己維護(hù)一套css格式庫，然后不要使用系統(tǒng)的document.execCommand命令，自己去封裝，這個當(dāng)然是最徹底的，但是也是最費工作量的，另外一個方法就是去限定某些組合的可能性，或者對某些場景的場景進(jìn)行特殊處理，當(dāng)然這個只是不補救的方案啦，具體怎么做，取決于使用場景，畢竟我們不是做一個word，所以未必需要考慮的那么全面。

at以及話題的鏈接處理

其實這里就是對webview的鏈接處理問題了。以@為例，我們的需求要求點擊@之后，生成一個搜索框，能夠搜索想要@的用戶，如果使用textview，我們完全能夠在textView的delegate里面，根據(jù)當(dāng)前的位置以及輸入的內(nèi)容進(jìn)行搜索，但是webview你是很難去獲取用戶一段時間輸入的內(nèi)容的，因此，我們直接使用鏈接代替，當(dāng)輸入一個@之后就生成一個鏈接，然后搜索操作就在鏈接中進(jìn)行(這里有個小技巧，如果只是輸入一個@字符然后將其變成一個Link，那么光標(biāo)默認(rèn)的會處在link的外面，因此接下來的輸入，不會成為鏈接的一部分，因此在這里我們生成的是一個 "@ "加一個空格的鏈接，并把光標(biāo)手動移動到@之后)。不過這里還有一個光標(biāo)的坑，因為我們選擇一個用戶之后需要替換掉已經(jīng)輸入的部分，也就是將link內(nèi)容替換掉，會發(fā)現(xiàn)光標(biāo)會移動到link的最前面去,光標(biāo)又亂跳了!所以其實這里還需要自己去移動光標(biāo)!

另外這里在進(jìn)行搜索的時候還有個問題，就是在使用系統(tǒng)輸入法輸入中文的時候，會出現(xiàn)聯(lián)想輸入條(quicktype)，如果這個時候，用戶沒有選擇輸入條的內(nèi)容，而是直接選擇了用戶名進(jìn)行替換，那么我們會自動將當(dāng)前的link替換成選擇后的內(nèi)容，并將光標(biāo)移動到Link的后面，但是這個時候，其實系統(tǒng)輸入法的聯(lián)想輸入還沒結(jié)束，因此當(dāng)用戶再次點擊輸入的時候，系統(tǒng)會默認(rèn)找原來開始聯(lián)想輸入時候的Node位置，但是由于這個已經(jīng)被我們替換掉了，會找不到，從而使得光標(biāo)跑到webview的外面去，因此我們還需要在這里通過監(jiān)聽compositionupdate，進(jìn)行修正光標(biāo)的位置

總結(jié)

總得來說，基于webview的富文本，雖然系統(tǒng)幫我們做了很多事情，但是真正實踐起來還是會發(fā)現(xiàn)問題遠(yuǎn)比我們想象的多，所以永遠(yuǎn)不要懷疑word開發(fā)那么多年的工作!另外要基于webview做富文本編輯器，那么一定要對Js有一定的了解，要不然會發(fā)現(xiàn)很鬼頭痛!不過對于大多數(shù)app而言，其實我們的要求是沒那么高的，所以找一個適合自己的webview的開源方案還是能很大的減少自己的工作量。