参考文档
小程序底层实现原理及一些思考
为了安全和管控, 双线程执行
Web Worker执行用户的代码; UI线程执行大部分的功能.
微信小程序架构原理
只通过mvvm模板语法动态改变页面, 不支持BOM操作
编译过程:
wcc可执行程序编译.xml文件生成js脚本, js脚本在传入正确路径, 得到了一个virtual dom树.
WAWebview.js
wx下注册是api, 最终都会调用WeixinJSBrige方法.
wxparser对象, 提供dom到wx element之间的映射, 元素操作管理, 事件功能管理
部分组件使用原生代码实现, 例如:wx-video, wx-canvas, wx-map, wx-textarea等
native组件悬浮在webview之上, 大部分组件使用前端实现.
WeixinJSBridge
wx.request实际调用WeixinJSBridge, 区分浏览器环境调用.
WAService.js
wx API; APP(), Page(); 页面具有作用域, 提供模块化; 数据绑定; 事件分发; 生命周期; 路由;
具体架构由两个webview组成: UI层, Logic层
UI层运行在第一个webview中, 执行DOM操作和交互事件响应, 里面是WAWebview代码和编译后内容
Logic层运行在独立的JS引擎: ios: JavaScriptCore, android: x5, 开发工具: nwjs chrome内核
逻辑层包括WAService.js代码和业务
两层之间通过WeixinJSBridge, => ? (native) 之间进行交互
微信小程序架构分析 (上)
一个程序有多个view, 也就是多个webview
一个小程序只有一个service进程, 也是一个webview, 在程序生命周期内在后台运行
两者都通过WeixinJSBridge和后台通信
view模块和service模块均使用postMessage进行通信
contentScript.js的代码提供了message消息到chrome.runtime通信接口的转换
浅谈小程序运行机制
使用客户端提供的JavaScript引擎, 沙箱只是单纯的提供JavaScript解释环境, 没有浏览器任何接口
小程序的基础库分别注入到视图层和逻辑层运行
视图层: 提供各类组件来组建界面
逻辑层: 提供各种API来处理逻辑
处理数据绑定, 组件系统, 事件系统, 通信系统等一系列框架
基础库不会打包到某个小程序代码, 会提前内置在微信客户端
基于shadow dom模型
启动机制
热启动: 打开过小程序, 在一定时间内再次打开
冷启动: 首次打开或者被微信销毁后打开
没有重启概念
进入后台后, 维持一段时间的运行后被销毁, 目前是五分钟.
短时间(5s), 连续收到两次系统内存告警, 会进行小程序销毁.
更新机制
冷加载读取缓存/检查更新
热加载直接后台切前台
冷启动时发现有新版本, 会异步下载新版本的代码包, 并同时用客户端本地的包进行启动
即新版小程序发布后, 需要经历两次冷启动, 才会应用
如果需要新版本, 可以使用指定API进行更新
setData
webview和jsCore是单独模块
两边都通过evaluateJavaScript实现, 即用户传输的数据.
需要将其转换成一份JS脚本, 通过执行脚本进行执行
小程序更新机制
未启动时更新
微信客户端有若干个时机检查本地缓存的小程序有没有新版本, 有静默升级
发布新版本后, 无法同步所有的用户, 24小时, 同步所有新版本信息到用户手机
下次进行冷启动时, 先更新最新版本再打开.
启动时更新
每次冷启动都会检查更新, 异步下载最新的版本的代码包, 但会用本地的包进行启动
新版本在下一次冷启动时, 应用.
疑问
为什么微信小程序两个webview, 其中有给logic线程, 是跑在webview中, 怎么没有window对象?
如何在某个操作系统写引入JS解释环境呢?
shadowdom是什么?
