从微信小程序开发者工具源码看实现原理(二)- - 小程序技术实现

1,785
原文链接: www.cnblogs.com

wxml与wxss的转换

打开小程序开发者工具,在调试控制台输入openVendor就会打开小程序的WeappVendor目录,该目录包括以下几个主要内容:

  • wcc可执行程序,用于将wxml内容转换为js内容,执行方式:wcc xxx.wxml
  • wcsc可执行程序,用于将wxss内容转换为视图可使用css内容,执行方式 wcsc xxx.wxss
  • 不同版本小程序基础库x.x.x.wxvpkg, 里面包含小程序基础库WAService和WAWebview

1、wxml使用wcc转换

正如上面分析的,通过调用小程序内置的可执行程序执行wcc xxx.wxml,将指定的wxml转换为js脚本内容。其具体用法可以--help查看,如下图:

小程序开发者工具底层会将小程序项目中所有wxml转为js内容,可以理解为为每个页面wxml进行了注册。例如我们小程序demo有两个页面index.wxml和logs.wxml,其中index.wxml内容如下图:

通过wcc可执行程序生成的相关页面注册的代码如下图所示:

从页面转换的js内容来看,主要记录标签的属性及其值等。另外,转化的js脚本提供最核心的方法是$gwx方法,可以在开发者工具开发控制台访问到,其方法签名如下:

$gwx = function(path, global) {
    ...
    return function(env,dd,global){
        ...
    }
}

该方法根据传入具体的页面wxml路径,找到对应的页面,然后返回一个函数,向该函数传入页面渲染需要的数据(即Page中data对象)就能得到该页面wxml对应的js对象形式表示的dom树。其实每个小程序页面在页面准备初始化渲染时会调用这个$gwx方法,调用如下图所示:

另外,我们直接在开发者工具的控制台直接调用,输入如下语句,可以得到的js对象表示如下图:

 $gwx('./pages/index/index.wxml')({show: true});

2、wxss使用wcsc转换

wcsc可执行程序用于处理wxss,小程序底层使用该可执行程序转换为js内容来处理页面css的引用。首先我们来看下wxss提供功能,如下图:

小程序底层使用wcsc -db -pc来转换对应wxss文件的,其生成的js内容如下图eval函数中的字符串所示:

生成是js主要作用:

  • 添加尺寸单位rpx转换,可根据屏幕宽度自适应
  • 提供setCssToHead方法将转换后的css内容添加到header

开发者工具主入口

小程序开发者工具的主入口也是小程序的启动入口,是整个小程序开发者工具的控制层,例如创建或者销毁webview等。它主要包括小程序的视图层的webview,业务逻辑层webview,调试器的webview和编辑区的webview几大块;我们只需关心视图层和业务逻辑层的webview。启动入口对应这一个index.html页面,里面引入主入口js,如下:

<div id=container class=container></div>
<script src=../js/core/index.js> </script> 

最终初次进入小程序主页后,主入口index.html的渲染html中有关视图层和业务逻辑层结果如下图所示:

由此可以证明,小程序开发者工具业务逻辑层是在webview中执行的,该webview虽然提供浏览器相关接口,但是小程序只是在其中单纯的执行js代码。

在我们小程序demo中有index首页navigateTo到logs日志页时,可以看主入口dom的变化,见下图:

从dom变化可以看出,调用navigateTo相当于新打开一个webview加载另一个页面视图,随着打开的页面越来越多,内存就比较吃紧。这也是为什么小程序对打开页面数量有限制的原因。从图中可能也看出了,为啥多加载了一个pageframe.html的webview,这个是干什么用的?后面会说到它的作用。

视图层页面的实现

我们在写小程序页面视图时,貌似并不关心webview中的html结构,这些都是小程序底层帮我们实现, 我们只需要写页面ui和业务逻辑即可。下面我们来看看view视图层小程序帮我们做了什么。先来看一下视图层pageframe.html的模板:

其中,模板中的注释占位符经过后台服务处理会注入不同js脚本,主要js内容:

  • <!-- deviceinfo -->: 暂时无用的占位符,会被空字符串""替换
  • <!-- jsdebug -->: 提供视图层的WeixinJSBridge模拟实现以及一些事件的处理如enablePullDownRefresh,其对应的js内容为extensions/pageframe/index.js.
  • <!-- plugincode -->: 小程序插件相关的代码,若小程序使用插件则会注入
  • <!-- wxmlcode -->: 调用wcc可执行命令生成的小程序注册所有页面wxml对应的js脚本内容
  • <!-- wxsscode -->: 调用wcss可执行命令生成的js脚本内容,提供注入css到页面的js方法;该内容会提前注入全局的css。
  • <!-- wxappcode -->: 小程序当前视图页面相关的配置json内容以及wxml和wxss转换为js的内容,可在控制台输入__wxAppCode__看相关信息
  • <!-- vendorlist -->: 小程序为视图层注入的基础库功能,包括WAWebview.js、WARemoteDebug.js和hls.js

视图层页面实现技术细节

本节来详细介绍下小程序视图层实现的一些技术细节

视图层快速打开原理

首先看一下小程序官网页面层级准备小节描述的一段内容:

wx.navigateTo会创建一个新的页面层级,对于每一个新的页面层级,视图层都需要进行一些额外的准备工作。在小程序启动前,微信会提前准备好一个页面层级用于展示小程序的首页。除此以外,每当一个页面层级被用于渲染页面,微信都会提前开始准备一个新的页面层级,使得每次调用wx.navigateTo都能够尽快展示一个新的页面。

正如上文提到的,我们在打开pages/logs/logs视图页面时,发现dom中多加载了一个__pageframe__/pageframe.html的视图层,其模板内容正如上一节描述的。这个视图层的作用正是为了小程序提前为一个新的页面层准备的。

小程序每个视图层页面内容都是通过pageframe.html模板来生成的,包括小程序启动的首页;下面来看看小程序为快速打开小程序页面做的技术优化:

  • 首页启动时,即第一次通过pageframe.html生成内容后,后台服务会缓存pageframe.html模板首次生成的html内容
  • 非首次新打开页面时,页面请求的pageframe.html内容直接走后台缓存
  • 非首次新打开页面时,pageframe.html页面引入的外链js资源(如上图所示)走本地缓存

这样在后续新打开页面时,都会走缓存的pageframe的内容,避免重复生成,快速打开一个新页面。

视图层新打开页面流程

其实在小程序开发者工具实现中,在创建每个视图层页的webview时,都会为其绑定了onLoadCommit事件(它会在页面加载完成后触发,包含当前文档的导航和副框架的文档加载)。初始时webview的src会被指定为空页面地址http://127.0.0.1:${global.proxyPort}/aboutblank?${c},其中c为对应webview的id。webview从空页面到具体页面视图的过程如下:

  • 空页面地址webview加载完毕后执行事件中的reload方法,即设置webview的src为pageframe地址http://127.0.0.1:${global.proxyPort}/__pageframe__/pageframe.html

加载完成后,设置其src为pageframe.html:

  • 新的src内容加载完成后再次触发onLoadCommit事件但根据条件不会执行reload方法。

  • pageframe.html页面在dom ready之后触发注入并执行具体页面相关的代码,此时通过history.pushState方法修改webview的src但是webview并不会发送页面请求。

pageframe.html模板生成的内容除小程序基础库视图层的底层功能之外,还包括小程序所有页面的模板信息、配置信息以及样式内容,这些都可以在生成pageframe.html的dom结构中窥探一二。

那么,既然每个视图层页面由pageframe模板生成,那么小程序每个页面独有的页面内容如dom和样式等如何生成呢,这主要是利用nw.js的executeScript方法来执行一段js脚本来注入只与当前页面相关的代码,包括当前页面的配置,注入当前页的css以及当前页面的virtual dom的生成,注入的代码如下:

最终生成的js代码(拿pages/index/index为例)如下图:

其中:

history.pushState('','', 'http://127.0.0.1:59524/__pageframe__/pages/index/index')

这句代码的作用修改当前webview的src,因为视图层的webview的src为pageframe.html,通过这句代码将其变更为具体的页面地址。

另外,需要注意的是nw.js的executeScript方法注入的代码是需要时机的,需要等到视图层的初始化工作准备ready之后才行,那么这个时机如何知道呢?细心的读者可能发现,在pageframe模板的最后一个script的内容:

<script>alert("DOCUMENT_READY")</script>

这个从字面意思可以看出此时应该是页面dom ready的一个时机,通过alert来进行通知。
alert能通知消息?当然可以的,在nw.js的webview中alert、prompt对应的弹框是被会阻止的,那么通过为webview绑定dialog事件来知道是那种弹框类型,以及提示内容,具体可以查看这篇文章。例如小程序开发者工具绑定事件部分代码(便于查看有修改):

this.webview.on('dialog', (a) => {
   a.preventDefault();
   const b = a.messageType || '',
            c = a.messageText,
            d = a.dialog;
    if ('alert' === b) {
        c === 'DOCUMENT_READY' && (this.documentReady = !0, this.loadPage())
    }
    ...
})

这样方法loadPage就会触发nw注入并执行页面相关的代码。最终生成的页面视图对应dom结构如下图:

可以看出,视图页面生成的dom结构中,document.body已无pageframe.html模板中对应body中的script内容,这是因为视图层的WAWebview.js在通过virtual dom生成真实dom过程中,它会挂载到页面的document.body上,覆盖掉pageframe.html模板中对应document.body的内容。

业务逻辑层页面的实现

小程序将所有业务代码置于同一个线程中运行,小程序开发者工具是在一个webview中执行;webview中的appservice.html引入业务代码js之外,还有后台服务内嵌的一些基础功能代码,appservice.html对应的模板内容如下:

经过后台服务的处理,模板中的各种占位符就被对应的js内容注入,下面就来简单说几个重要的注入内容:

  • <!-- wxconfig -->: 小程序的配置项,包括用户自定义与系统默认的整合结果。在控制台输入__wxConfig可以看出打印结果
  • <!--devtoolsconfig-->:小程序开发者配置,包括开发者工具版本,设置的请求域名、默认开发者工具的设置以及访问Native方法需要permission的方法。控制台输入__devtoolsconfig可以看到其对应的信息
  • <!-- wxmlxcjs -->: 调用wcc可执行命令生成的小程序注册所有页面wxml对应的js脚本内容,js脚本提供$gwx方法。
  • <!-- asdebug -->: 提供业务逻辑层的WeixinJSBridge模拟以及一些针对开发者工具的接口,如在控制台输入help可以看到提供的接口。其内容为extensions/appservice/index.js.
  • <!-- vendorlist -->: 为业务逻辑层注入WAService.js,为业务逻辑层提供小程序底层基础库的功能

此外,开发者工具服务还在appservice.html的body注入一段脚本,脚本的作用是将业务逻辑代码通过script动态注入到head中执行,这段代码如下:

最终生成的appservice.html中的head情况如下图所示:

通过上图可以看出,我们写的页面逻辑都引入到页面中,并且分别从app.js开始一一执行;小程序代码调用Page构造器的时候,小程序基础库会记录页面的基础信息,如初始数据(data)、方法等。需要注意的是,如果一个页面被多次创建,并不会使得这个页面所在的JS文件被执行多次,而仅仅是根据初始数据多生成了一个页面实例(this),在页面JS文件中直接定义的变量,在所有这个页面的实例间是共享的。

参考