摘要：背景最近我們微信讀書將寫想法換成了基于的富文本編輯器，遇到了不少問題，這里我將簡(jiǎn)單的介紹一下我們?cè)陂_發(fā)過程中踩到的坑。

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

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

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

基于uiwebview實(shí)現(xiàn)

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

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

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

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

插入表情的時(shí)候uiwebview會(huì)失焦問題。

原生命令會(huì)有bug,需要自己處理。

樣式的兼容性。

at以及話題的鏈接處理。

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

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

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

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

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

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

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

 // 這時(shí)候光標(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，同時(shí)在表情面板刪除表情的時(shí)候，也需要做類似的操作。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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