- 运行环境:小程序基于浏览器内核重构内置解析器,而
h5
的宿主环境是浏览器。所以小程序中没有DOM
和BOM
的相关API
,jQuery
和一些NPM
包都不能在小程序中使用; - 系统权限:小程序能获得更多的系统权限,如网络通信状态、数据缓存能力等;
- 渲染机制:小程序的逻辑层和渲染层是分开的,而
h5
页面UI
渲染跟JavaScript
的脚本执行都在一个单线程中,互斥。所以h5
页面中长时间的脚本运行可能会导致页面失去响应。
其实,小程序开发过程中我们面对的是iOS
和Android
微信客户端和辅助开发的小程序开发者工具。根据官方文档,这三大运行环境也是有所区别的:
运行环境 | 逻辑层 | 渲染层 |
---|---|---|
iOS | JavaScriptCore | WKWebView |
Android | X5 JSCore | X5浏览器 |
小程序开发者工具 | NWJS | Chrome WebView |
所以微信小程序介于 web
端和原生 App
之间,能够丰富调用功能接口,同时又跨平台。
2. 小程序架构
2.1 双线程模型
小程序的渲染层和逻辑层分别由2个线程管理:
- 渲染层:界面渲染相关的任务全都在
WebView
线程里执行。一个小程序存在多个界面,所以渲染层存在多个WebView
线程。 - 逻辑层:采用
JsCore
线程运行JS脚本。
视图层和逻辑层通过系统层的WeixinJsBridage
进行通信:逻辑层把数据变化通知到视图层,触发视图层页面更新,视图层把触发的事件通知到逻辑层进行业务处理。
(页面渲染的具体流程是:在渲染层,宿主环境会把WXML
转化成对应的JS
对象,在逻辑层发生数据变更的时候,我们需要通过宿主环境提供的setData
方法把数据从逻辑层传递到渲染层,再经过对比前后差异,把差异应用在原来的Dom树上,渲染出正确的UI界面)
双线程模型是小程序框架与业界大多数前端Web
框架不同之处。基于这个模型,可以更好地管控以及提供更安全的环境。缺点是带来了无处不在的异步问题(任何数据传递都是线程间的通信,也就是都会有一定的延时),不过小程序在框架层面已经封装好了异步带来的时序问题。
2.2 组件系统
我们知道小程序是有自己的组件的,这些基本组件就是基于Exparser
框架。Exparser
基于WebComponents
的ShadowDOM
模型,但是不依赖浏览器的原生支持,而且可在纯JS
环境中运行。
小程序中,所有节点树相关的操作都依赖于Exparser
,包括WXML
到页面最终节点树的构建CreateSelectorQuery
调用和自定义组件特性等。现在微信小程序也支持自定义组件,用法和组件间通信类似于Vue
2.3 原生组件
在内置组件中,有一些组件并不完全在Exparser
的渲染体系下,而是由客户端原生参与组件的渲染。比如说Map
组件。它渲染的层级比在WebView
层渲染的普通组件要高。
引入原生组件的优点是:
代码语言:javascript复制WebWebView
setData
2.4 运行机制
2.4.1 启动
- 热启动:假如用户已经打开过某小程序,然后在一定时间内再次打开该小程序,此时无需重新启动,只需将后台态的小程序切换到前台,这个过程就是热启动;
- 冷启动:用户首次打开或小程序被微信主动销毁后再次打开的情况,此时小程序需要重新加载启动,即冷启动。
2.4.2 销毁
只有当小程序进入后台一定时间,或者系统资源占用过高,才会被真正的销毁。
2.5 更新机制
开发者在后台发布新版本之后,无法立刻影响到所有现网用户,但最差情况下,也在发布之后 24 小时之内下发新版本信息到用户。
小程序每次冷启动时,都会检查是否有更新版本,如果发现有新版本,将会异步下载新版本的代码包,并同时用客户端本地的包进行启动,即新版本的小程序需要等下一次冷启动才会应用上。
所以如果想让用户使用最新版本的小程序,可以利用wx.getUpdateManager
做个检查更新的功能:
checkNewVersion() { const updateManager = wx.getUpdateManager();
updateManager.onCheckForUpdate((res) => { console.log('hasUpdate', res.hasUpdate); // 请求完新版本信息的回调
if (res.hasUpdate) {
updateManager.onUpdateReady(() => { this.setData({ hasNewVersion: true
});
});
}
});
}
微信小程序的基础底层架构大概就这么多,有机会再看看源码思考解析吧。