第一章 微信小程序与微信之间的关系

在2017年以前，微信公众号（主要是服务号）是作为企业/商家私域流量的主阵地。

公众号服务器端API结合Webview-JSAPI的微信生态接入，让用户与公众号间实现了多种形式的交流与沟通（网页多媒体呈现，模版消息，支付，卡包操作等）。

那么问题来了，在基础功能差异不大的前提下，为何微信要重新开辟一个名为“小程序”的新产品形态呢？

下面，我就通过技术和业务两个角度去阐述这个问题。

一、微信小程序到底是不是Webview+框架

UI是，但不全是。

先上图：

微服务与小程序 小程序与微服务的关系_微信

图1 微信小程序的概略实现架构

和大部分框架不同，微信小程序其实同时运行着两套javascript引擎，一套只负责逻辑，一套负责UI的渲染。

其中通过setData(obj)方法进行数据传递。

反之web渲染层通过指定方法名的方式，调用逻辑层暴露的方法（主要用于操作UI事件的逻辑响应，比如点击监听等）。

例：将学生list，传递给页面

this.setData({
	students:[{
		name:a,
		age:6
	}]
})
<text>学生姓名：{{students[0].name}}</text>

例2：界面的监听实现

<button bindtap="submitFunc">提交</button>
page({
	submitFunc(){
		//do something
	},
	//...
});

如此，微信小程序从技术上解决了Webview带来的几大痛点：

1、因为浏览器脚本引擎的限制（JS引擎只有一个阻塞状态），导致对于JS驱动的动态Web应用而言，UI和逻辑二者是无法真正分开线程的（严格上讲，动态Web应用就不存在“多线程”这个概念）。

这也就导致了首次加载慢等问题，而微信小程序通过两套引擎，提升了首次加载的速度。

2、因为逻辑层在native（原生）应用的引擎中，所以数据和逻辑相对更安全，更可信。也正因为如此，微信小程序在微信数据开放相关的能力相比公众号更强，也更激进。

3、能够调用更多的native（原生）能力。

那么问题来了，代价呢？请听下回分解。