小程序运行机制与原理

笔记上记载了不少关于小程序的零散片段,有必要把它们整合起来

运行环境差异

微信小程序运行在三端:iOS、Android 和 用于调试的开发者工具。
三端的脚本执行环境以及用于渲染非原生组件的环境是各不相同的:
  • 在 iOS 上,小程序的 javascript 代码是运行在 JavaScriptCore 中,是由 WKWebView 来渲染的,环境有 iOS8、iOS9、iOS10
  • 在 Android 上,小程序的 javascript 代码是通过 X5 JSCore来解析,是由 X5 基于 Mobile Chrome 53/57 内核来渲染的
  • 在 开发工具上, 小程序的 javascript 代码是运行在 nwjs 中,是由 Chrome Webview 来渲染的
尽管三端的环境是十分相似的,但是还是有些许区别:
  • ES6 语法支持不一致 语法上开发者可以通过开启 ES6 转 ES5 的功能来规避。详情
  • wxss 渲染表现不一致 尽管可以通过开启样式补全来规避大部分的问题 详情,还是建议开发者需要在 iOS 和 Android 上分别检查小程序的真实表现。

框架/DSL

为了提高体验,及开发代码质量,让开发者只能按框架的规则去开发。那应该使用怎样的框架?
在 PC SNS 时代,Facebook 做开放平台时有类似的场景,为了第三方开发者能在 Facebook 平台上开发,同时又能限制住开发者的权限,Facebook 要求开发者使用自定义的一套 DSL(FBML)去开发,而这个 DSL 能怎么写,最终能转成什么,如何执行,都是平台说了算,同时也可以很方便做代码扫描和审查。
小程序正好能借鉴这样的设计思路,界面不使用 HTML 开发,而是自定义一套 DSL,这样就可以很容易配合审核/代码扫描/域名限制等系列措施去做管控,这就是小程序这一套框架的来源。这套框架通过 wxml 去描述界面,wxss 描述样式,js 去处理逻辑和数据,再通过工具一系列处理把这些转为 HTML/CSS/JS 显示在 webview 上,并处理界面交互和数据更新。
这样用一套框架去限制开发方式,再造一层 DSL,除了管控外还有一个好处,就是容易进行针对性优化,DSL 最终转成什么,最终如何执行渲染都由框架决定,上层不感知,可以做成由 webview 渲染,小程序部分组件有自己实现原生渲染层,比如 canvas,video ,cover-view等标签,所以层级最高服务覆盖,且对仅实现了基本的css 支持。

JS 环境

通过框架限定开发方式后,管控上还有个问题,就是如何限制应用端类JS语言调用dom API?小程序跑在 webview 上,渲染时必然要通过 JS 操作 dom,如果小程序框架和应用 JS 代码都有权限操作 dom,应用可能会通过各种方式在上线后绕过检查,注入 JS 调用 dom 接口去修改页面结构和内容,变成跟审核时不一样的应用。怎样能限制应用的 JS 调用 dom 的权限?微信想了个比较创新的解决方案,就是:JS 运行环境与浏览器分离,运行在单独的 JS 引擎上。
脱离了浏览器,JS 自然没有 dom 的调用权限,任何跟 webview 界面相关的 API 都无法拿到。而小程序框架核心JS运行在webview上,可以自由操作dom,通过小程序框架定义的机制,应用端通过 wxml/wxss 定义固定的渲染样式,JS 端只管数据绑定,数据可以通过 native 桥梁从 JS 引擎传递到 webview,JS端无法做任何渲染相关的操作,可以对渲染的内容有完整的管控权。
独立的 JS 运行环境除了满足管控需求外,也额外带来一些好处和一些坏处,好处在于:
1. 多个页面可以共享一个 JS 运行环境,数据可以很方便地共享,整个小程序生命周期里共享同一个上下文,更接近 APP 的开发体验。
2. JS 与页面渲染分离并行执行,不会出现 JS 执行时卡住页面渲染的情况,提升渲染性能。
坏处在于:
1. 多了数据序列化传输的开销,数据需要从 JS 传到 webview 给视图层渲染,需要序列化为字符串格式再进行传输。
2. iOS 上 WKWebview 的 JS 引擎比 JavaScriptCore 多了 JIT 优化,执行速度快很多倍,小程序的 JS 运行在 JavaScriptCore 上无法享受到这个优化。

生命周期

小程序的视图层目前使用 WebView 作为渲染载体,而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上,WebView 和 JavascriptCore 都是独立的模块,并不具备数据直接共享的通道。当前,视图层和逻辑层的数据传输,实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据,需要将其转换为字符串形式传递,同时把转换后的数据内容拼接成一份 JS 脚本,再通过执行 JS 脚本的形式传递到两边独立环境。而 evaluateJavascript 的执行会受很多方面的影响,数据到达视图层并不是实时的。所以频繁的去 setData及大量传输数据会导致性能问题
界面线程有四大状态: 
1. 初始化状态:初始化界面线程所需要的工作,包括工作机制,基本和我们开发者没有关系,等初始化完毕就向 “服务线程”发送初始化完毕信号,然后进入等待传回初始化数据状态。
2.首次渲染状态:收到“服务线程”发来的初始化数据后(就是 json和js中的data数据),就开始渲染小程序界面,渲染完毕后,发送“首次渲染完毕信号”给服务线程,并将页面展示给用户。
3.持续渲染状态:此时界面线程继续一直等待“服务线程”通过this.setdata()函数发送来的界面数据,只要收到就重新局部渲染,也因此只要更新数据并发送信号,界面就自动更新。
4.结束状态
服务线程五大状态: 
1 初始化状态:无需和其他模块交流,跟小程序开发也没多大关联,此阶段就是启动服务线程所需的基本功能,比如信号发送模块。系统的初始化工作完毕,就调用自定义的onload和onshow,
然后等待界面线程的“界面线程初始化完成”信号。
onload是只会首次渲染的时候执行一次,onshow是每次界面切换都会执行,简单理解,这就是唯一差别。
2 等待激活状态:接收到“界面线程初始化完成”信号后,将初始化数据发送给“界面线程”,等待界面线程完成初次渲染。
3.激活状态:收到界面线程发送来的“首次渲染完成”信号后,就进入激活状态既程序的正常运行状态,并调用自定义的onReady()函数。
此状态下就可以通过 this.setData 函数发送界面数据给界面线程进行局部渲染,更新页面。
4.后台运行状态:如果界面进入后台,服务线程就进入后台运行状态,从目前的官方解读来说,这个状态挺奇怪的,和激活状态是相同的,也可以通过setdata函数更新界面的。毕竟小程序的框架刚推出,应该后续会有很大不同吧。

体验

小程序最主要的两个技术点 — 框架和JS运行分离 都是源自管控需求,而体验上的需求就是由各种细致的性能优化组成了,很多文章也分析过,这里简单说下,包括:
1. 离线包:整个小程序打包下发,不需要打开每个页面都去请求,减少第二次打开时间以及页面切换时间。
2. 预加载:预加载多一个wkwebview放后台,用户打开小程序时省去初始化wkwebview时间。另外对于一个小程序内的页面切换,得益于框架的设计,可以做到预渲染模板,切换时再填充数据,加快渲染速度。

3. 缓存:退出小程序后不会立即销毁,会在后台继续跑5分钟,在这期间用户切回小程序时速度快。

4. 视觉:小程序首次加载通过loading和动画的方式过渡,拒绝白屏,给人一种快的感觉,同时提升了小程序的标识度。

另外推荐一篇 cocos 介绍的关于小游戏适配原理http://forum.cocos.com/t/faq/54842
相关来源:

文档信息

发表评论

电子邮件地址不会被公开。 必填项已用*标注