在微信小程式中渲染HTML內容3種解決方案及分析與問題解決
大部分Web應用的富文字內容都是以HTML字串的形式儲存的,通過HTML文件去展示HTML內容自然沒有問題。但是,在微信小程式(下文簡稱為「小程式」)中,應當如何渲染這部分內容呢?
在微信小程式中渲染HTML內容的3種解決方案
wxParse
小程式剛上線那會兒,是無法直接渲染HTML內容的,於是就誕生了一個叫做「wxParse」的庫。它的原理就是把HTML程式碼解析成樹結構的資料,再通過小程式的模板把該資料渲染出來。
rich-text
後來,小程式增加了「rich-text」元件用於展示富文字內容。然而,這個元件存在一個極大的限制:元件內遮蔽了所有節點的事件。也就是說,在該元件內,連「預覽圖片」這樣一個簡單的功能都無法實現。
web-view
再後來,小程式允許通過「web-view」元件巢狀網頁,通過網頁展示HTML內容是相容性最好的解決方案了。然而,因為要多載入一個頁面,效能是較差的。
當「WePY」遇上「wxParse」
基於使用者體驗和功能互動上的考慮,我們拋棄了「rich-text」和「web-view」這兩個原生元件,選擇了「wxParse」。然而,用著用著卻發現,「wxParse」也不能很好地滿足需要:
我們的小程式是基於「WePY」框架開發的,而「wxParse」是基於原生的小程式編寫的。要想讓兩者相容,必須修改「wxParse」的原始碼。
「wxParse」只是簡單地通過image元件對原img元素的圖片進行顯示和預覽。而在實際使用中,可能會用到雲端儲存的介面對圖片進行縮小,達到「用小圖顯示,用原圖預覽」的目的。
「wxParse」直接使用小程式的video元件展示視訊,但是video元件的層級問題經常導致UI異常(例如把某個固定定位的元素給擋了)。
此外,圍觀一下「wxParse」的程式碼倉庫可以發現,它已經兩年沒有迭代了。所以就萌生了基於「WePY」的元件模式重新寫一個富文字元件的想法,其成果就是「WePY HTML」專案。
實現過程
解析HTML
首先仍然是要把HTML字串解析為樹結構的資料,我採用的是「特殊字元分隔法」。HTML中的特殊字元是「<」和「>」,前者為開始符,後者為結束符。
如果待解析內容以開始符開頭,則擷取開始符到結束符之間的內容作為節點進行解析。
如果待解析內容不以開始符開頭,則擷取開頭到開始符之前(如果開始符不存在,則為末尾)的內容作為純文字解析。
剩餘內容進入下一輪解析,直到無剩餘內容為止。
為了形成樹結構,解析過程中要維護一個上下文節點(預設為根節點):
如果截取出來的內容是開始標籤,則根據匹配出的標籤名和屬性,在當前上下文節點下建立一個子節點。如果該標籤不是自結束標籤(br、img等),就把上下文節點設為新節點。
如果截取出來的內容是結束標籤,則根據標籤名關閉當前上下文節點(把上下文節點設為其父節點)。
如果是純文字,則在當前上下文節點下建立一個文字節點,上下文節點不變。
上下文(解析前) | 解析內容 | 上下文(解析後) |
---|---|---|
根節點 | <div class="content"> | div |
div | <p style="text-indent: 2em;"> | p |
p | Hello world | p |
p | </p> | div |
div | </div> | 根節點 |
經過上述流程,HTML字串就被解析為節點樹了。
對比
本元件演算法 | wxParse | parse5 | |
---|---|---|---|
效能 | 3~6ms | 20ms左右 | 20ms左右 |
容錯性 | 差 | 一般 | 強 |
檔案大小(未壓縮) | 6kb | 22kb | 接近400kb |
可見,在不考慮容錯性(產生錯誤的結果,而非丟擲異常)的情況下,本元件的演算法與其餘兩者相比有壓倒性的優勢,符合小程式「小而快」的需要。而一般情況下,富文字編輯器所生成的程式碼也不會出現語法錯誤。因此,即使容錯性較差,問題也不大(但這是需要改進的)。
模板渲染
樹結構的渲染,必然會涉及到子節點的遞迴處理。然而,小程式的模板並不支援遞迴,這下彷彿掉入了一個大坑。
看了一下「wxParse」模板的實現,它採用簡單粗暴的方式解決這個問題:通過13個長得幾乎一模一樣的模板進行巢狀呼叫(1呼叫2,2呼叫3,……,12呼叫13),也就是說最多可以支援12次巢狀。一般來說,這個深度也足夠了。
由於「WePY」框架本身是有構建機制的,所以不必手寫十來個幾乎一模一樣的模板,通過一個構建的外掛去生成即可。
<!-- wepyhtml-repeat start --> <template name="wepyhtml-0"> <block wx:if="{{ content }}" wx:for="{{ content }}"> <block wx:if="{{ item.type === 'node' }}"> <view class="wepyhtml-tag-{{ item.name }}"> <!-- next template --> </view> </block> <block wx:else>{{ item.text }}</block> </block> </template> <!-- wepyhtml-repeat end -->
以下是對應的構建程式碼(需要安裝「wepy-plugin-replace」):
// wepy.config.js { plugins: { replace: { filter: /\.wxml$/,config: { find: /<\!-- wepyhtml-repeat start -->([\W\w]+?)<\!-- wepyhtml-repeat end -->/,replace(match,tpl) { let result = ''; // 反正不要錢,直接寫個20層巢狀 for (let i = 0; i <= 20; i++) { result += '\n' + tpl .replace('wepyhtml-0','wepyhtml-' + i) .replace(/<\!-- next template -->/g,() => { return i === 20 ? '' : `<template is="wepyhtml-${ i + 1 }" wx:if="{{ item.children }}" data="{{ content: item.children"></template>`; }); } return result; } } } } }
然而,執行起來後發現,第二層及更深層級的節點都沒有渲染出來,說明巢狀失敗了。再看一下dist目錄下生成的wxml檔案可以發現,變數名與元件原始碼的並不相同:
<block wx:if="{{ $htmlContent$wepyHtml$content }}" wx:for="{{ $htmlContent$wepyHtml$content }}">
「WePY」在生成元件程式碼時,為了避免元件資料與頁面資料的變數名衝突,會根據一定的規則給元件的變數名增加字首(如上面程式碼中的「$htmlContent$wepyHtml$」)。
所以在生成巢狀模板時,也必須使用帶字首的變數名。 先在元件程式碼中增加一個變數「thisIsMe」用於識別字首:
<!-- wepyhtml-repeat start --> <template name="wepyhtml-0"> {{ thisIsMe }} <block wx:if="{{ content }}" wx:for="{{ content }}"> <block wx:if="{{ item.type === 'node' }}"> <view class="wepyhtml-tag-{{ item.name }}"> <!-- next template --> </view> </block> <block wx:else>{{ item.text }}</block> </block> </template> <!-- wepyhtml-repeat end -->
然後修改構建程式碼:
replace(match,tpl) { let result = ''; let prefix = ''; // 匹配 thisIsMe 的字首 tpl = tpl.replace(/\{\{\s*(\$.*?\$)thisIsMe\s*\}\}/,(match,p) => { prefix = p; return ''; }); for (let i = 0; i <= 20; i++) { result += '\n' + tpl .replace('wepyhtml-0','wepyhtml-' + i) .replace(/<\!-- next template -->/g,() => { return i === 20 ? '' : `<template is="wepyhtml-${ i + 1 }" wx:if="{{ item.children }}" data="{{ ${ prefix }content: item.children }}"></template>`; }); } return result; }
至此,渲染問題就解決了。
微信小程式中HTML包含圖片
為了節省流量和提高載入速度,展示富文字內容時,一般都會按照所需尺寸對裡面的圖片進行縮小,點選小圖進行預覽時才展示原圖。
這主要涉及節點屬性的修改: 把圖片原路徑(src屬性值)存到自定義屬性(例如「data-src」)中,並將其新增到預覽圖陣列。
把圖片的src屬性值修改為縮小後的圖片URL(一般雲服務商都有提供此類URL規則)。
點選圖片時,使用自定義屬性的值進行預覽。 為了實現這個需求,本元件在解析節點時提供了一個鉤子(onNodeCreate):
onNodeCreate(name,attrs) { if (name === 'img') { attrs['data-src'] = attrs.src; // 預覽圖陣列 this.previewImgs.push(attrs.src); // 縮圖 attrs.src = resizeImg(attrs.src,640); } }
對應的模板和事件處理邏輯如下:
<template name="wepyhtml-img"> <image class="wepyhtml-tag-img" mode="widthFix" src="{{ elem.attrs.src }}" data-src="{{ elem.attrs['data-src'] || elem.attrs.src }}" @tap="imgTap"></image> </template>
// 點選小圖看大圖 imgTap(e) { wepy.previewImage({ current: e.currentTarget.dataset.src,urls: this.previewImgs }); }
微信小程式中HTML包含視訊
在小程式中,video元件的層級是較高的(且無法降低)。
如果頁面設計上存在著可能擋住視訊的元素,處理起來就需要一些技巧了: 隱藏video元件,用image元件(視訊封面)佔位; 點選圖片時,讓視訊全屏播放; 如果退出了全屏,則暫停播放。
相關程式碼如下:
<template name="wepyhtml-video"> <view class="wepyhtml-tag-video" @tap="videoTap" data-nodeid="{{ elem.nodeId }}"> <!-- 視訊封面 --> <image class="wepyhtml-tag-img wepyhtml-tag-video__poster" mode="widthFix" src="{{ elem.attrs.poster }}"></image> <!-- 播放圖示 --> <image class="wepyhtml-tag-img wepyhtml-tag-video__play" src="./imgs/icon-play.png"></image> <!-- 視訊元件 --> <video style="display: none;" src="{{ elem.attrs.src }}" id="wepyhtml-video-{{ elem.nodeId }}" @fullscreenchange="videoFullscreenChange" @play="videoPlay"></video> </view> </template>
{ // 點選封面圖,播放視訊 videoTap(e) { const nodeId = e.currentTarget.dataset.nodeid; const context = wepy.createVideoContext('wepyhtml-video-' + nodeId); context.play(); // 在安卓微信下,如果視訊不可見,則呼叫play()也無法播放 // 需要再呼叫全屏方法 if (wepy.getSystemInfoSync().platform === 'android') { context.requestFullScreen(); } },// 視訊層級較高,為防止遮擋其他特殊定位元素,造成介面異常, // 強制全屏播放 videoPlay(e) { wepy.createVideoContext(e.currentTarget.id).requestFullScreen(); },// 退出全屏則暫停 videoFullscreenChange(e) { if (!e.detail.fullScreen) { wepy.createVideoContext(e.currentTarget.id).pause(); } } }
開源
最後貼一下「WePY HTML」的專案倉庫: https://github.com/beiliao-web-frontend/wepy-html ,具體使用方法見專案內的 README 。
如果你在使用過程中遇到了問題,或者是有好的建議和意見,都可以在 Issues 中提出。
隨著微信小程式的不斷完善相信用不了多長時間就會有一種更加完美的解決方案,那時我們就不會再改來改去了。更多關於微信小程式開發的文章請點選下面的相關文章