小程序里有几个谜一样的存在,微信的WXS、支付宝的SJS、百度的Filter。
很多开发者都不明白为什么要造这种语言脚本的轮子出来,甚至很多开发者根本不知道它们的存在。
其实几大小程序平台创造它们,都是为了解决性能问题,但不得不吐槽下,设计的实在是很难用,文档也语焉不详。
uni-app
支持将WXS
、SJS
、Filter
编译到这3家小程序平台,同时还在App和H5实现了WXS
的解析。为什么做这些事?也是为了性能。
uni-ui
库新版中的swiperaction
组件,就是列表项向左滑动时拉出几个挤压式联动的菜单按钮,这种流畅的跟手动画,正是借助于WXS
机制实现的。
WXS(WeiXin Script)是微信创造的一套脚本语言,它的官方说法是:“WXS 与 JavaScript 是不同的语言,有自己的语法,并不和 JavaScript 一致”。
那微信为何要脱离 JavaScript ,单独创造一套语言呢?这要从微信小程序的底层逻辑(运行环境)讲起。
小程序的运行环境分为逻辑层和视图层,分别由2个线程管理,其中:
小程序在视图层与逻辑层两个线程间提供了数据传输和事件系统。这样的分离设计,带来了显而易见的好处:
但同时也带来了明显的坏处:
什么是需要频繁通讯的场景?最典型的例子就是用户持续交互的情况,比如触摸、滚动等。我们以侧滑菜单为例,假设在页面上滑动A元素,要求B元素跟随移动,一次滑动操作(touchmove)的响应过程如下:
2.逻辑层处理 touchmove 事件,计算需移动的位置,然后再通过 setData 传递到视图层,中间同样会由微信客户端(Native)做中转
一次 touchmove 的响应需要经过 视图层、Native、逻辑层三者之间2个完整来回的通信,通信的耗时开销较大,用户的交互就会出现延时卡顿的情况。
除了滚动、拖动交互外,在for循环里对数据做格式修改,也会造成逻辑层和视图层频繁通讯。
其实这类通信损耗问题,在业内由来已久,react native和weex都有类似问题,weex提供了bindingx来解决。
但对于小程序来讲,这类问题解决起来更容易。其实视图层的webview,是有js环境的,只不过过去不给开发者开放。
如果在视图层的js直接处理滚动或拖动交互、直接处理数据格式,就能避免大量通信损耗。
但对于小程序平台而言,大量开放webview里的js编写,违反了它的初衷,比如开发者会直接操作dom,影响性能体验。所以小程序平台提出一种新规范,限制webview里可运行的js的能力。这就是wxs、sjs、filter的由来。
从本质来讲,wxs、sjs、filter是一种被限制过的、运行在视图层webview里的js。它并不是真的发明了一种新语言。
WXS具备如下特征:
class
和style
故可以得出WXS的适用场景,主要包括:
//首字母大写
var capitalize = function(value) {
if (!value) return ''
value = value.toString()
return value.charAt(0).toUpperCase() + value.slice(1)
}
module.exports = {
capitalize: capitalize
}
{{m1.capitalize(title)}}
uni-app
遵循Vue单文件组件(SFC)规范,组件/样式/脚本是写在一个.vue
文件中的,但微信小程序是多文件分离(wxml/wxss/js/json)的,所以在微信端的主要工作是扩展vue-template-compiler
,解析template/style/script
节点,并正确生成到对应的wxml/wxss/js
文件中,具体编译工作如下图:
Tips-1:关于
标签重构为的说明:
因.vue
文件中的
标签及内嵌WXS代码,在主流前端开发工具(vscode/HBuilderX等)中,均无法实现语法提示、代码高亮及格式化,故uni-app
将
重构为,便捷实现了语法提示、代码高亮等,如下为vscode/HBuilderX中对于
标签重构前后的代码高亮对比,明显重构为后,开发体验更佳:
Tips-2:鉴于Vue的自定义标签规范,我们建议将
()和
template
平级编写
编译器的具体解析扩展工作,这里不详述,仅给出wxs
生成的示例代码,让大家有个直观理解:
createFilterTag (filterTag, {
content,
attrs
}) {
content = content.trim()
if (content) { //标签内直接编写 wxs 代码
return `<${filterTag} module="${attrs.module}">
${content}
${filterTag}>`
} else if (attrs.src) { //外联 .wxs 文件
return `<${filterTag} src="${attrs.src}" module="${attrs.module}">${filterTag}>`
}
}
在保证编译正确的情况下,微信小程序运行时会正确解析并执行WXS
脚本,框架runtime
无需干预。
下面的gif图是借助 WXS 实现的一个swipeaction
示例,列表项向左滑动时拉出几个挤压式联动的菜单按钮,跟手动画、回弹动画都很自然流畅。
该示例的完整源码参考github
uni-app
的App端也是一个小程序引擎,所以想要在App端实现流畅的跟手拖动,也需要实现类似wxs的机制。
其实H5平台倒不存在逻辑层和视图层通讯折损的问题,但为了平台兼容性拉齐,uni-app
在H5端也实现了wxs机制。
这样编写wxs代码,在uni-app
中可同时运行在App端、H5端、微信小程序端。
因百度小程序的Filter过滤器、支付宝小程序的SJS和微信小程序的WXS在语法上差异较大,uni-app
只支持单独编写百度小程序的Filter过滤器和支付宝小程序的SJS,这两种脚本无法跨多端,仅支持自有平台。开发者若需使用,可分别编写wxs/filter/sjs
脚本,然后依次通过script
引用,uni-app
编译器会根据目标平台,分别编译发行,如下为示例代码:
示例代码要有条件编译
用运行在视图层的js解决通讯阻塞,可能很多人都没意识到。希望本文能给大家解惑,解开WXS之谜。
其实小程序的性能体验优化,仍然有大量空间。DCloud团队在这个领域研究了6年,清楚当前的优势,也清楚当前的问题。
本文涉及的uni-ui
的swiperaction
组件,代码开源在https://github.com/dcloudio/uni-ui,uni-app
框架代码开源在 https://github.com/dcloudio/uni-app,