关于微信小程序的架构与系统设计的几点观感

本文来自于迅雷首席工程师刘智聪的个人分享，他毕业于南昌大学化学系，加入迅雷后设计开发了多款迅雷核心产品，凭借“大规模网络流媒体服务关键支撑技术”项目获得2015年国家科学技术进步奖二等奖，同时也是第四代UI交互技术 BOLT 界面引擎的发明人，目前担任 WebApp 解决方案商 – 火速移动的首席技术顾问。

微信小程序是什么？

官方这么说：

“我们提供了一种新的开放能力，让开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验”。

听起来非常美好，咱们具体一点，结合目前公开的信息和微信目前其它的开放形式对比一下吧。

可以看到，腾讯还是非常有诚意的，这次在微信小程序上新开放的能力很多，不再是渐进式的演变而有一点像革命了。

小程序的入口在哪？

目前公开的资料里对大家最关系的入口问题只提到了小程序可以扫二维码打开，于是业界对小程序的入口有了这么几种流行的假设。 

假设一： 朋友圈，朋友可以把自己喜欢的小程序分享在朋友圈，看到了可以点击打开直接使用。

可能性：99%。小程序不能出现在朋友圈，流量从哪来？

假设二： 出现在发现 Tab 页面中，游戏下面（每个小程序占用一列），同时摇一摇也可以得到附近的小程序。

可能性：80%。和腾讯的游戏挤在一起，不亏待你吧。

假设三： 和当前的公众号、服务号类似，安装出现在会话列表。

可能性：90%。新的开放能力和旧的开放能力用一样的入口不奇怪吧。

假设四： 安装后和 Native App 一样，直接出现在桌面。

可能性:10%。和微信在同一级入口，腾讯同意 Apple 都不一定同意。

假设五： 微信多一个小程序的 Tab。

可能性：1%。多一个 Tab 太丑了，而且小程序刚发布，不可能立刻就对微信的整体结构产生影响。

假设六： 出现在一些内置流程中，比如和好友的聊天界面内、发朋友圈的界面（拍照后处理）。

可能性：1%。小程序和微信本体使用不同的框架技术开发，互相嵌套有困难。

微信小程序框架浅析

官方已经正式公开了小程序的开发资料，小程序的开发框架包含两大块内容，分别是：API 与组件。官方的资料在组织和内容上都写的还不错，阅读体验也很顺畅，没看过的话推荐先简单的通读一遍。基本上有一定经验的前端开发都可以没有什么障碍的掌握目前资料里的内容，我就不去做入门性的介绍了，直接浅析吧。

先看框架的底层 API 部分。微信一直有一个贯穿的“JS-SDK”在不断演进。对比一下小程序的底层 API 的功能范围，和 JS-SDK 还是有很多相似的感觉，相信未来会在形式上达到统一(JS-SDK 这名字也足够霸气，塞进去什么都不会觉得奇怪。不过 JS-SDK 的很多接口设计的实在不敢恭维，希望这次统一的进程也能重新修正下)。小程序的 API 部分由于可以跳出浏览器的框架，理论上肯定可以是 JS-SDK 的超集。

这里面我觉得比较有意思的地方有：

网络通信

只要目标服务器的域名在小程序配置的安全列表之类，就可以直接通信，不用考虑 JS 的跨域问题了。

既然跨域都支持了，没准以后能像 Node.js 一样，直接在小程序里使用 TCP、UDP 协议，并基于 Buffer 有一定的二进制协议的开发能力。跳出 HTTP 协议的框架，对于 IoT 方向是很有想象空间的。

数据缓存

数据缓存接口的设计看起来和 HTML5 里的 localStorage 基本上一样，本来没什么好说的。但文档里的一句话引起了我的兴趣：  

> 注意：localStorage 是永久存储的，但是我们不建议将关键信息全部存在 localStorage，以防用户换设备的情况。 

难道微信提供的数据缓存能力虽然不是永久的存储，但可以做到跟随用户账号而不是当前设备？也就是说，不管用户怎么换手机，已安装使用过的小程序都能使用同一份缓存（不存在不登陆使用小程序的场景）？

虽然微信自己的聊天记录跨设备漫游都没做，但这种 App Personal File Cloud 的支持，还是能在不增加开发的工作量的情况下，大幅提升用户体验的（作为一个 Steam 的重度用户，我已经完全离不开游戏存档的自动同步功能）。这也让我对小程序在云端的能力，开始有了一些初步的想象。

并不兼容一些常见 JS 底层框架

小程序的官方 QA 里有一段话：

zepto/jquery 会使用到 window 对象和 document 对象，所以无法使用。

这意味着所有基于 HTML5 的已有底层代码资产，并不能完全无缝的迁移过来。不过连 jQuery 这么常用的库都不能兼容还是有一点伤的。当然，现在用裁剪或兼容的方法，提供能在小程序平台运行的常见 JS 底层库，短期内会很有市场。  

MINA 框架剖析

接下来我要解读微信小程序提供的界面部分功能，也是最令人兴奋的部分。一个小程序，必须基于 MINA 框架（从泄漏的资料里得知这个框架叫 MINA，正式的资料里删除了这个名字，但为了后面行文方便，我会一直把小程序的应用框架称之为 MINA）构建。一个典型的小程序的结构如下：

app.json 小程序配置：

小程序里一共包含哪些页面；
页面套在一个怎么样的 window 里显示；
window 是否需要支持多tab，支持的话每个 tab 的默认 page 是什么；
一些底层组件的默认参数。

app.js（可以理解为入口函数）：

处理 app 的几个关键事件：onLaunch、onShow；
定义了 app 级（可以在不同的页面之间共享）的数据的格式；

app.wxss 公用样式表：

每个页面的样式表，都是从这个应用级公有样式表继承下来的。
 MINA 一个最主要的核心概念是 Page，一个 Page 是应用内可以导航到的最小粒度的界面。而如何构建 Page 是与大家过去猜测差别最大的地方。微信并没有使用 HTML5，而是提供了一套新的设计。新的设计要求每个 Page 由 3 个文件构成：

1. index.js：包含Page的逻辑处理代码

其中比较重要的就是定义 Page 的数据（wxml 可以通过数据绑定机制直接访问）。

2. index.wxml: Page 的布局文件

随便从 Demo 中选一个布局文件来看，其整体结构非常简介清晰，即使没有提供任何资料也大概能看出来表达了一个什么样的页面。

.wxml不算是完全的静态布局文件，还支持条件渲染和列表渲染。
.wxml使用{{}}语法来简单直接的支持数据绑定。可以通过template的方法进行复用。

3. index.wxss：样式表

决定了在 wxml 中定义的各种组件最终应该如何显示。官方文档并没有列出 wxss 的 selector 语法和支持的 style，只是说“具有CSS的大部分特性”，wxss 样式表里也扩展了一些微信小程序专用的样式是属性。

Page 的整体设计上有比较明显的“反应式”编程风格，相信有 Vue.js、AngularJS、Reactive.js 开发经验的同学可以很快上手。由于没有内测资格所以没法在手机上测试性能，不清楚小程序的这套框架有没有反应式编程常见的性能问题。这个等公测后写个有 10 万条数据的列表，看看滚动流不流畅就知道了。  
目前 Demo 没有使用 ES6，所以看起来没那么“现代化”，这也可能是因为小程序这个项目立项比较早的缘故吧。不过 ES6 是大势所趋，相信未来小程序会支持使用 ES6 开发。

一个基于MINA的小程序最后是如何跑起来的呢？

官方这么说：

开发者写的所有代码最终将会打包成一份 JavaScript，并在小程序启动的时候运行，直到小程序销毁。类似 ServiceWorker，所以逻辑层也称之为 App Service。

网上已经有不少人通过琢磨开发工具的实现的方法，做了比较深度的研究了，推荐阅读：微信小程序「官方示例代码」剖析【下】：运行机制 。

简单地总结一下：

wxml文件通过编译会得到 HTML，wxss 文件通过编译会得到 CSS，分离的各个页面的 JS 和 App 的主 JS 文件最终会打包在一起得到 App Service。开发状态下运行小程序，基于 blink 内核，每个 HTML 会加载一些 moko js 用来支持框架功能。生产环境在手机上估计是运行在一个专用，定制的浏览器内核中。

为什么是 MINA?

业界对目前微信使用的 UI 框架，有两种截然相反的观点，比如“微信“小程序”带动HTML5发展”、“微信小程序的本质说来就是一个 HTML5 应用”。而有的人又认为“微信虽然用了 HTML5 技术来做应用号（正式名称：小程序），但是它并没有真正用到 HTML5 的精髓 —— 开放、互联，也就决定了它可能无法实现“微信OS”的最终野心。”

这两个观点是矛盾的，那么，到底那种观点是正确的呢？首先简化一下问题，微信小程序是基于 HTML5 开发的么？

通过分析小程序的运行原理，这个答案是明确的：小程序的开发过程会用到大量 HTML5 相关的技术,但并不是使用 HTML5 开发。有 HTML5 经验的前端工程师学习微信小程序的开发相对会更容易一些。微信小程序的运行并不需要一个完整支持 HTML5 特性的标准浏览器内核，但也可以通过添加一些辅助设施，让小程序在个完整支持 HTML5 标准的浏览器上运行起来。

“由于框架并非运行在浏览器中，所以 JavaScript 在 Web 中一些能力都无法使用，如 document、window 等。”也就是说，一个已存在的 HTML5 页面，并不能通过自动转换工具变成一个合法的 Page，而需要有工程师根据 HTML5 页面的功能，使用 MINA 框架再实现一次。

搞清楚 MINA 和 HTML5 的关系后，我们还是没有搞清楚为什么微信要提供一个新的 MINA 框架。事实上这个问题是一个讨论设计的问题，所以要回答这个问题，需要具备一定的设计能力，而不是只是停留在研究MINA实现的层面。而设计能力，是一种比较稀缺的能力。

想要系统地提升自己的设计能力，简单的来说就是“多看+多想”，那么如何多想呢？我有一套还算完整的方法的，简单来说有如下几步：

首先，在研究一个新东西以前，先想想这个新东西，是为了解决什么样的问题出现的。问题要多提，往深了提，反复提炼，最后得到几个好问题。或从一个问题，引申出一些子问题。很多时候只要问题提对了，设计就明白了大半。

下一步就是试着自己解决一下，回答一下自己提的问题，并比较不同的解决思路的优劣，形成一个对问题解的标准。比如说问题是“如何在一个超长文本中查找子串？” 那么对问题的评价标准就可以是查找速度，以及查找过程中的内存占用。

接下里就是看别人是如何解决这些问题的了。如果和自己的设计差不多，一边窃喜一边开始按自己预先设计的评价标准对别人的设计的好坏进行判断。如果是自己完全没想到过的解法（这通常会出现在第一次接触某个领域问题），可以按图索骥的补充一些基础知识，再回来看。如果这个领域或解法非主流到不是常见范式，那么可以安下心来好好搞清楚，想明白。这样带着问题研究设计，才能有效的提高自己的设计能力。

介绍完套路后咱们回到正题：我们如何来评价微信小程序选择MINA框架？让我来持续提问吧。

第一个问题：“为什么微信小程序不使用HTML5而是使用MINA来构建Page？”

不用 HTML5，我可以提供一个非技术答案：微信需要通过这种方法来转化开发者，这些开发者未来会逐渐演变成“微信OS平台”的忠实开发者。其实开发者通常都有患有“斯德哥尔摩综合症”，一旦在一个平台上投入了智力资源进行学习，就会开始下意识的维护这个平台（比如看不到平台的缺点，只看到平台的优点）。

如果使用 HTML5 作为开发方式，那么现在小程序聚拢的开发者都是为了流量来的，并没有投入额外的学习成本，对平台不够忠诚。而微信要成为 OS 是一个长期的演变过程，那么现在就要通过要求学习一个新的开发框架的方法开始多转化一些忠诚的开发者。

当然是不是这个原因也只有张小龙自己知道了，这是一个揣摩动机的答案，所以没有评价标准。问题终结。

为什么不用 HTML5 的技术答案可以是非常庸俗的。毕竟业界对于 HTML5 技术的优劣讨论已经持续了一段很长的时间了。但基本上，大家认为 HTML5 的主要缺点集中在性能上：同样的交互，用 HTML5 实现需要更多的系统资源，也可能会不够流畅。同时，应用还需要集成一个非常巨大的浏览器内核。

这个答案尽管能让大部分人满意，但实际上是非建设性的（这些对 HTML5 性能的结论，是别人告诉你的）。大家一边相信 HTML5 的美好前景，一边把对性能问题的解决寄托于几家传统的浏览器厂商。按我们的套路，这个性能问题再往深了问是这样的：“渲染指定页面最少需要多少资源？”，“在当前硬件水平下，渲染指定页面最快需要多少时间？”，“实现一个完整支持HTML5标准的浏览器内核，需要大概多少代码？”。要回答这些问题就需要了解浏览器的实现了，这不会是一件容易的事情，在阅读浏览器的实现的时候，肯定会持续提出针对HTML的设计问题。最终你会对浏览器厂商什么时候能解决性能问题，得到一个更合理的预期：至少在 5 年内，HTML5 的性能是不够的。

虽然 SAY NO 的理由，有一条就够了。但如能从其它角度思考一下为什么不是HTML5,可以得到一些更有建设性的答案。

第二个问题：“MINA作为一个新框架，为什么会设计成现在的样子？”

可以肯定的是，这是 MINA 的架构师在综合了多个因素后，拿出来的一个自己最满意的答案。所以这是一个非常有建设性的问题，思考这个问题的时候，就开始逐步代入 MINA 的架构师视角了。
 
让我们一起进入 MINA 架构师的角色，首先在否决了 HTML5 后，要设计一个什么样的框架来支持小程序的交互开发？第一步就是要给这个新框架提一些基础性的目标与需求。  
这是一个现代化的框架，在最终表现力上要足够好。

小程序跑在微信里，所以必然是和 Android、iOS 的具体平台特性无关的。

要面向更多的非专业开发者，所以学习门槛要低。

大规模的专业团队进行团队开发时，能有足够的工程支持。工程支持包括： 
- 模块化 
代码易于长期维护和修改。这意味着基于框架的实现具体需求的结果要足够清晰，好读。

可复用性设计

小程序不需要安装就可以快速开始使用，只需要加载必要的资源就可以尽快展现用户需要的页面。

进一步思考这些需求该如何解决，并对不同的解决方案进行评价需要的领域知识非常多，已经超过了本文的讨论范围。我在这里要做的只是带你入门，让你开始思考设计问题就够了。这也是本文的核心目的：学会对新技术，新设计进行独立的分析和判断。至于结果么，现在小程序还处于一个早期的状态，等公测了之后在下结论也不迟。

微信小程序的未来？

 
 虽然现在小程序开放的功能并不丰富，处于一个早期的状态，但结合上面的观点去看微信小程序的设计，还是能从中读到许多远大的理想。而微信的核心愿景之一是“连接一切”，没准小程序是腾讯实现这个愿景道路上的重要一步。有超过7亿用户的微信如果成为一个新的平台，具有不可忽视的能量，下面让我来对小程序的下一步动作做一些无责任的预测吧。  

假设一、微信小程序未来会解决应用内搜索的问题

目前小程序规范的页面结构很方便实现应用内搜索。以后使用微信的搜索功能可以直达小程序内部的某个特点内容页面。

这种规范的设计也方便实现小程序之间的互相访问，可以通过一个类似 wxapp://appid/pageid/ 的 URL 直接导航到另一个小程序的某个特定页面。这是 App 时代的超连接系统，App 的信息孤岛也许就此打破。

假设二、微信小程序会从本地数据读取开始，进化出一定的云端API。

现在小程序只提供了前端的开发功能，但从整体逻辑上已经包含了应用的上传、审核、发布流程。

以后腾讯也许会为小程序提供托管服务（https://www.qcloud.com/act/event/yingyonghao.html），让应用开发者可以用更少的精力完成一个完整小程序的开发，而不需要去管服务器申请，后台开发，服务器运维等反繁琐的工作，进一步降低一个真正小程序的开发门槛。我相信微信一定有团队在为这个方向努力，但最终实现目标需要更有创造力的云端API设计，这是需要有大智慧的工作。

假设三、使用小程序连接一切

我并不认为小程序只是一个体验更好的服务号。张小龙说小程序是“触手可及”、“用完即走”、“无处不在”的。那么什么场景会需要这种能力? 我觉得“有复杂程序的低频商业行为”会有这种需求。举两个实际的例子：

例1：有一间智能会议室，入口处有一个二维码。会议室的使用者扫描后可以打开一个小程序，通过这个小程序可以更好地访问、控制会议室的各种设备，比如灯光、窗帘、幕布等。

例2：去体检，体检表上有个二维码，扫描后打开一个小程序，通过这个小程序可以更好地引导用户自助完成自己的体检项目。

这两个场景的需求能通过小程序解决，意味着小程序的种类极大丰富，硬件厂商对微信生态的极大支持。我们可以通过小程序简单方便的进入各种陌生的环境，让生活更加智能。未来已经悄悄敞开了大门。

而如何更好更快的探索小程序的可能性，也将是我接下来创业的方向。我将以火速移动技术顾问的身份，和小伙伴们一起从微信小程序开始，去探索移动 Web 的可能性。

了解最新移动开发相关信息和技术，请关注mobilehub公众微信号（ID: mobilehub)。