小程序开发需要的技术

小程序的基本技术层次

微信技术架构

小程序框架的核心是一个响应的数据绑定系统。

整个小程序框架系统分为两部分：视图层（View）和逻辑层（App Service）

框架可以让数据与视图非常简单地保持同步。当做数据修改的时候，只需要在逻辑层修改数据，视图层就会做相应的更新。

• 视图层和逻辑层分离，通过数据驱动，事件交互，不直接操作DOM
• 视图层负责渲染页面结构，逻辑层负责逻辑处理、数据请求、接口调用等
• 视图层与逻辑层通过数据和事件进行通信，逻辑层提供数据给视图层，视图层通过绑定/捕获事件发起交互让逻辑层处理
• 视图使用WebView渲染，JS由JSCore(IOS)/X5(Android)/nwjs(DevTool)渲染解析
• JSBridge架起上层开发与Native（系统层）的桥梁，使得小程序可通过API使用原生的功能，且部分组件为原生组件实现，从而有良好体验
  附：浏览器内核了解

技术方案

一般来说，实图层渲染界面的技术栈有这么一些：

1. 客户端原生或编译到原生的：Flutter / iOS / Android
2. 用纯 Web 的：React / Vue / Angular, PWA / MPA, SPA
3. 以及用原生与 Web 二者结合，用桥接的方式通信的混合技术

优缺点：原生的技术需要和微信客户端一起编译发布版本，显然不适合快读迭代；纯web最灵活，但是也会有性能问题，和安全问题。

 

其他方案，混合技术Hybrid, with Multi-Webview + SharedWorker? + JS2Native

而 Hybrid 技术主要有以下两种：

1. 用 Web 技术描述界面但转成原生渲染，或称之为 JS2Native 的：ReactNative / Weex / NativeScript
2. 以及用 Web 技术渲染，原生提供 JS-SDK 模式的混合技术： PhoneGap + Cordova / Ionic, Electron / ns.js (Node-Webkit)

从渲染底层来看，微信 JS-SDK 跟 PhoneGap 是类似的，都还是使用浏览器内核来渲染界面。所以我们的答案也就呼之欲出了，小程序最终选择在 Hybrid 这个方向上延续，就很好理解了。

其实，微信提供的开发者工具，也是用桌面 Hybrid 技术中比较成熟的 nw.js

 

微信框架提供了自己的视图层描述语言 WXML 和 WXSS，以及基于 JavaScript 的逻辑层框架，并在视图层与逻辑层间提供了数据传输和事件系统，让开发者能够专注于数据与逻辑。

 

小程序视图层

WXML(WeiXin Markup Language)

支持数据绑定

支持逻辑算术、运算

支持模板、引用

支持添加事件

 

WXML先被编译成JS文件，引入数据后会初始完成虚拟DOM，最终把虚拟DOM构建成DOM树，在WebView中渲染。

WXSS（WeiXin Style Sheets）

支持大部分CSS特性

添加尺寸单位rpx，可根据屏幕宽度自适应

使用@import语句可以导入外联样式表

不支持多层选择器，避免被组件内结构破坏

 

 

WXSS被编译成JS运行。常用选择器、组件，略过。

小程序的组件基于Web Component标准，使用Polymer框架实现Web Component。Polymer框架是Google提出的，但在使用过程中发现其性能较低，所以微信自研了一套。

Native组件层在WebView层之上。

 

小程序逻辑层

逻辑层讲数据进行处理后发送给视图层，同时接受视图层的事件反馈。

App()小程序的入口；Page()页面的入口

提供丰富的API，如微信用户数据，扫一扫，支付等微信特有能力

每个页面有独立的作用域，并提供模块化能力

数据绑定，事件分发，生命周期管理，路由管理

运行环境：iOS-JSCore、Android-X5 JS解析器、DevTool-nwjs Chrome内核

逻辑层生命周期

用户从微信打开一个小程序的执行过程：

Native执行一个拉起的操作，告诉App Service层

App Service层执行拉起，同时通知View层进行初始化

接下来要打开页面，通过路由通知App Service层

App Service层创建一个Page，然后通知Web层初始化，同时通知View层渲染并发送初始化数据

App Service层的Page会进行onLoad、onShow事件的执行，渲染完成onReady

当用户进行操作时，就出发一次用户事件，用户事件会通知到App

Service层并在此层执行，然后通知View层进行局部渲染，这样就完成了一次交互。

New View是在Web View初始化完成之后建立的，用于等待用户执行下一个界面时使用，减少Web View创建的花销，用户不需要等待了。App Service层的New Page也是同理。

 

小程序可以借鉴的优点

提前新建Web View，准备新页面渲染

View层和逻辑层分离，通过数据驱动，不直接操作DOM

使用Virtual DOM，进行局部更新

全部使用https，确保传输过程中安全

前端组件化开发

加入rpx单位，隔离设备尺寸，方便开发

小程序存在的问题

小程序仍然使用WebView渲染，并非原生渲染

需要独立开发，不能再非微信环境运行

开发者不可以扩展新组件

服务端口返回的头无法执行，如Set-Cookie

以来浏览器环境的js库不能使用，因为是JSCore执行的，没有window、document对象

WXSS中无法使用本地（图片、字体等）

WXSS转化成js而不是css,为了兼容rpx

WXSS不支持级联选择器

小程序无法打开页面，无法拉起APP

脱离微信的“小程序”：PWA渐进式应用

优点：

渐进增强：支持的新特性的浏览器获得更好的体验，不支持的保持原来的体验

离线访问：通过Service Workers可以再离线或者网速差的环境下工作

类原生应用：使用app shell model做到原生应用般的体验

可安装：允许用户保留对他们有用的应用在主屏幕上，不需要通过应用商店

容易分享：通过URL可以轻松分享应用

持续更新：受益于service worker的更新进行，应用能够始终保持更新

安全：可通过https来提供服务来防止网络窥探，保证内容不被篡改

可搜索：得益于W3C manifests元数据和service worker的等级，让搜索引擎能够找到wen应用

再次访问：通过消息推送等特性让用户再次访问变得容易