记一次小程序排查 setData 函数耗时很长思路
小程序 大约 800 字场景介绍
小程序使用wxParse
渲染富文本,原理是将HTML标签解析成为原生view
+wxParse-
样式。
问题复现
功能上了生产环境后发现,数据从网络上请求下来后,setData
函数更新数据时,耗时达到了3秒之多,加载进度条消失了页面还未展示出来,体验较差。
排查思路
查看官方文档,setData
每次设置的数据大小不能超过1MB
,应避免一次设置过多数据。
但发现文章数据也没有达到1MB
大小,故排除了大小限制问题。
后来在查看页面布局时发现,生成了很多view
,对比较短的文章发现,节点越少,setData
耗时越短。
想到view
的多少由wxParse
解析HTML
节点生成,没有办法控制(小编功力不够,还没能力修改),只能想到使用原生rich-text
试一下耗时多久。
不试不知道,果然是因为wxParse渲染后节点过多导致setData
函数非常耗时。
解决方案
焦头烂额
查看rich-text
的官方文档描述后,感觉要破罐子破摔了。
tip
:nodes
不推荐使用String
类型,性能会有所下降。tip
:rich-text
组件内屏蔽所有节点的事件。
使用String
性能下降,事件又被全部屏蔽。
OMG! 还能不能快乐地玩耍了。
柳暗花明
作为CV
工程师百度了一把(不对谷歌了一把),发现有一个Parser
开源的解决方案,替换后果然耗时短了很多,平均只要200-300
毫秒。
备注说明
小编的小程序基于Parser
添加了一下功能:
- 代码区域长按复制功能
- 多语言代码高亮
code
标签在普通段落时的样式
相关地址
rich-text: https://developers.weixin.qq.com/miniprogram/dev/component/rich-text.html
————        END        ————
Give me a Star, Thanks:)
https://github.com/fendoudebb扫描下方二维码关注公众号和小程序↓↓↓

-
PostgreSQL 错误: 编码 "UTF8" 的字符 0x0xc9 0x99 在编码 "GBK" 没有相对应值阅读 5043
-
Vue 重置 data 数据阅读 48
-
Kubernetes Namespace 命名规则阅读 203
-
start.spring.io 无法访问解决办法阅读 5012
-
软考-系统架构设计师:三级模式-两级映射阅读 1675
-
Windows 添加用户到指定用户组阅读 769
-
Linux tcpdump: no suitable device found阅读 2044
-
minikube start Unable to determine current user's administrator privileges阅读 190
-
lanyus激活时IDEA提示your activation code could not be validated error 1653219阅读 273056
-
软考-系统架构设计师:DHCP 协议阅读 1584