我們的小程序是基于「WePY」框架開(kāi)發(fā)的，而「wxParse」是基于原生的小程序編寫(xiě)的。要想讓兩者兼容，必須修改「wxParse」的源代碼。

「wxParse」只是簡(jiǎn)單地通過(guò)image組件對(duì)原img元素的圖片進(jìn)行顯示和預(yù)覽。而在實(shí)際使用中，可能會(huì)用到云存儲(chǔ)的接口對(duì)圖片進(jìn)行縮小，達(dá)到「 用小圖顯示，用原圖預(yù)覽 」的目的。

「wxParse」直接使用小程序的video組件展示視頻，但是video組件的 層級(jí)問(wèn)題 經(jīng)常導(dǎo)致UI異常(例如把某個(gè)固定定位的元素給擋了)。

此外，圍觀一下「wxParse」的代碼倉(cāng)庫(kù)可以發(fā)現(xiàn)，它已經(jīng)兩年沒(méi)有迭代了。所以就萌生了基于「WePY」的組件模式重新寫(xiě)一個(gè)富文本組件的想法，其成果就是「WePY HTML」項(xiàng)目。實(shí)現(xiàn)過(guò)程解析HTML

首先仍然是要把HTML字符串解析為樹(shù)結(jié)構(gòu)的數(shù)據(jù)，我采用的是「特殊字符分隔法」。HTML中的特殊字符是「」，前者為開(kāi)始符，后者為結(jié)束符。

?如果待解析內(nèi)容以開(kāi)始符開(kāi)頭，則截取 開(kāi)始符到結(jié)束符之間 的內(nèi)容作為節(jié)點(diǎn)進(jìn)行解析。

?如果待解析內(nèi)容不以開(kāi)始符開(kāi)頭，則截取 開(kāi)頭到開(kāi)始符之前 (如果開(kāi)始符不存在，則為末尾)的內(nèi)容作為純文本解析。

?剩余內(nèi)容進(jìn)入下一輪解析，直到無(wú)剩余內(nèi)容為止。

正如下圖所示：

為了形成樹(shù)結(jié)構(gòu)，解析過(guò)程中要維護(hù)一個(gè)上下文節(jié)點(diǎn)(默認(rèn)為根節(jié)點(diǎn))：

?如果截取出來(lái)的內(nèi)容是開(kāi)始標(biāo)簽，則根據(jù)匹配出的標(biāo)簽名和屬性，在當(dāng)前上下文節(jié)點(diǎn)下創(chuàng)建一個(gè)子節(jié)點(diǎn)。如果該標(biāo)簽不是自結(jié)束標(biāo)簽(br、img等)，就把上下文節(jié)點(diǎn)設(shè)為新節(jié)點(diǎn)。

?如果截取出來(lái)的內(nèi)容是結(jié)束標(biāo)簽，則根據(jù)標(biāo)簽名關(guān)閉當(dāng)前上下文節(jié)點(diǎn)(把上下文節(jié)點(diǎn)設(shè)為其父節(jié)點(diǎn))。

?如果是純文本，則在當(dāng)前上下文節(jié)點(diǎn)下創(chuàng)建一個(gè)文本節(jié)點(diǎn)，上下文節(jié)點(diǎn)不變。

過(guò)程正如下面的表格所示：

經(jīng)過(guò)上述流程，HTML字符串就被解析為節(jié)點(diǎn)樹(shù)了。

對(duì)比

把上述算法與其他類似的解析算法進(jìn)行對(duì)比(性能以「解析10000長(zhǎng)度的HTML代碼」進(jìn)行測(cè)定)：

可見(jiàn)，在不考慮容錯(cuò)性(產(chǎn)生錯(cuò)誤的結(jié)果，而非拋出異常)的情況下，本組件的算法與其余兩者相比有壓倒性的優(yōu)勢(shì)，符合小程序「 小而快 」的需要。而一般情況下，富文本編輯器所生成的代碼也不會(huì)出現(xiàn)語(yǔ)法錯(cuò)誤。因此，即使容錯(cuò)性較差，問(wèn)題也不大(但這是需要改進(jìn)的)。模板渲染

樹(shù)結(jié)構(gòu)的渲染，必然會(huì)涉及到子節(jié)點(diǎn)的 遞歸 處理。然而，小程序的模板并不支持遞歸，這下仿佛掉入了一個(gè)大坑。

css,html5,html

總結(jié)

以上是生活随笔為你收集整理的微信小游戏游戏显示html控件,微信小程序中如何渲染html内容（代码示例）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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