微信小程序基本环境
参考 https://www.zhihu.com/question/50920642
1. 提供了JavsScript运行环境，由JavaScript编写的业务代码完成逻辑层的处理
2. 通过数据传输接口（注册Page时的data属性及后续的setData方法调用）将逻辑层的数据传输给视图层
3. 视图层由WXML语言编写的模板通过“数据绑定”与逻辑层传输过来的数据merge成展现结果并展现
4. 视图的样式控制由WXSS语言编写的样式规则进行配置
再分别来看这4点各自的细节问题：
1. 提供了JavsScript运行环境，由JavaScript编写的业务代码完成逻辑层的处理
JavaScript运行环境是什么？
开发文档Q&A(https://mp.weixin.qq.com/debug/wxadoc/dev/qa/qa.html)中这句已给出，JS运行环境是在JsCore里：
为什么脚本内不能使用window等对象页面的脚本逻辑在是在JsCore中运行
2. 通过数据传输接口（注册Page时的data属性及后续的setData方法调用）将逻辑层的数据传输给视图层
数据在逻辑层与视图层间如何传输？
视图为纯native渲染，故位于native端。
而逻辑层如上所述，是跑在JsCore中的JavaScript代码。
有了JsCore，微信小程序框架的native端与js端就可以通过JsCore来相互通信了。于是，微信小程序框架的native端与js端可以约定好通信协议/规范，再把js端通过此通信协议/规范与native通信的部分封装并暴露接口为API（最上层的传输或说设置数据的API也就是上面说的注册Page时的data属性与后续的setData方法），这样逻辑层的业务代码就可以实现向视图层传输数据了。
（对native其他API的调用也用类似的方法即能走通）
3. 视图层由WXML语言编写的模板通过“数据绑定”与逻辑层传输过来的数据merge成展现结果并展现
视图层与数据如何merge为展现结果并展现？
首先看WXML语言提供的接口，发现它：
- 类似于html/xml，用标签方式来描述视图
- 类似angular/vue，通过指令(标签的特殊属性)与双大括号来实现模板的增强功能，使模板与数据merge为结果标签
- 但细看发现，指令其实很简单，只提供了用于循环列表的wx:for指令，与用于控制逻辑的wx:if,wx:else,wx:elif指令
- 双大括号内支持简单的表达式，表达式中的变量即逻辑层输入的数据
- 每次逻辑层更新数据，视图层会相应更新merge并更新渲染
native端读取WXML模板文件，再根据逻辑层传来的数据将其中的指令与双大括号处理解析(可根据大括号表达式从数据中取值并计算，再以对表达式值进行循环与判断便可相应解除wx:for,wx:if指令)，生成与数据merge后、可以表征最终展现内容的标签串，
再以解析xml的方式解析标签为带有属性的节点树，并对应节点树中各节点相应创建native中的视图元素(可能为系统组件、也可能为微信框架中的视图组件)、设置相应属性、维护为正确的父子关系即可。
逻辑层数据更新时，也更新相应属性即可。
当然实际处理中，要考虑的因素要多许多，也会做许多优化，但基本思路应大致如此。
4. 视图的样式控制由WXSS语言编写的样式规则进行配置
样式如何匹配与设置？
构建出各视图元素后，仍由native读取WXSS文件，用简单字符串匹配即可将其解析为一对一对的"选择器-规则"对，规则内即为属性键值。之后再对各视图元素与"选择器-规则"对中的选择器进行匹配，匹配成功设置相应属性值（还要考虑全局样式与页面样式及style属性样式中的优先级）即可
如何使用css样式对native元素进行布局？
最基本的flex布局可以由facebook的css-layout来完成(GitHub - facebook/css-layout: A subset of CSS (specifically flex-box) re-implemented as a stand alone project for use primarily on mobile. Used by react-native)
另外，事件方面，native接收到用户事件后，必要时通过JsCore反向与其内运行的js进行通信，将事件数据传递给js端的框架，再由js端框架调起相应回调即可。
========================
使用了前端技术栈 JavaScript/WXML/WXSS。但和常规的前端开发又有一些区别：
- JavaScript: 微信小程序的 JavaScript 运行环境即不是 Browser 也不是 Node.js。它运行在微信 App 的上下文中，不能操作 Browser context 下的 DOM，也不能通过 Node.js 相关接口访问操作系统 API。所以，严格意义来讲，微信小程序并不是 Html5，虽然开发过程和用到的技术栈和 Html5 是相通的。
- WXML: 作为微信小程序的展示层，并不是使用 Html，而是自己发明的基于 XML 语法的描述。
- WXSS: 用来修饰展示层的样式。官方的描述是 “ WXSS (WeiXin Style Sheets) 是一套样式语言，用于描述 WXML 的组件样式。WXSS 用来决定 WXML 的组件应该怎么显示。” “我们的 WXSS 具有 CSS 大部分特性...我们对 CSS 进行了扩充以及修改。”
微信小程序最大的好处是不需要做设备适配，只要微信能运行，小程序就能运行。小程序虽然是一个封闭形态下的前端开发技术，但借助微信的巨大影响力，几乎所有人都在往里面冲。
运行时会有两个JS线程：数据线程和渲染线程
数据线程 (headless js)：
- 运行你的JS，把data 发去渲染线程 (App/Page生成时是深拷贝，以后是每次diff。BTW注入渲染线程时用的是 evaluateJavascript )
- 接受Event和其他东西，发射新的data
- 运行企鹅自己的代码，让你可以用 wx.* API
渲染线程 (webview)：
- 运行你写的 wxml，接受data返回VDOM (wxml会被编译成一个类似react的函数component的东西)
- 把VDOM中的一些component，如text，在webview内渲染成DOM
- 另一些component，如map，被发去不知哪里，渲染成native view
---
总体上是个想学PWA又不肯放权的尴尬产物。
实现上和 react-native 更类似，不过渲染不是纯dom也不是纯native，是杂种的。这有一些后果：
- wxss（没有，无法）支持CSS的多级选择器等。可能是因为性能，以及让css layout兼容 “完整的” CSS太难
- 样式不统一，比如android 的text-input在选中和非选中状态字体有微妙不同。可能对企鹅来说做得像ios就是好UI了。