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

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

實現富文本編輯器有兩個基本思路：

基于native實現：比如coretext或者textkit

基于uiwebview實現

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

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

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

如何保持光標在可見區域。

插入表情的時候uiwebview會失焦問題。

原生命令會有bug,需要自己處理。

樣式的兼容性。

at以及話題的鏈接處理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

document.execCommand("formatBlock", false, "
")

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

if (inQuoteBlock.is) {
        document.execCommand("formatBlock", false, "
")
    } else {
        document.execCommand("formatBlock", false, "
")
        }

同樣的還有標題設置等等都有這樣的問題。

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

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

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

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

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

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

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