微信小程序底层原理与运行机制类文章学习

参考文档

小程序底层实现原理及一些思考

• 为了安全和管控, 双线程执行
• 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是什么?