作者注：本文来自迅雷总工程师刘志聪的个人分享。毕业于微信大学化学系。加入迅雷后，设计开发了迅雷的多款核心产品。 2015年获得国家科技进步二等奖。第四代UI交互技术——BOLT界面引擎的发明者，现任解决方案提供商——火速出行首席技术顾问。

21日晚上，我和朋友们在打牌。难得的小七刚刚安顿好，突然手机里传来“叮咚”的短信提示音，紧接着是“叮叮，咚咚”的持续震动。我打开手机，看到一堆微信上给我发消息，先是一篇文章“微信应用号来了”，然后：“你怎么看？”

虽然之前收到消息说“微信申请号”将在年底发布，但没想到来得这么快，更名为“微信小程序”（简称“微信小程序”）小程序）。我没有打牌的打算，匆匆吃完一顿，三顿，然后回到电脑前，开始了我持续了几天的研究。而这几天，各种相关资料开始陆续出现，内测使用的开发工具也陆续泄露出去。

身边已经有很多朋友根据信息已经开始工作了，大致有以下几类：

1）释放你的想象力。如果你可以在公测中制作一个有趣的小程序并让它大受欢迎，那将是一大笔钱

2）公司有十几个服务号，其实改成小程序会更合适（合适不合适，改吧！）

3） 又一次洗牌的机会！公众号的功能是我最先想到的，结果被别人抢了。这一次，我会是第一个在小程序中做出来的，做到第一！

4）微信不愧是互联网的“国务院”，新政草案立马引起全行业一夜研究。在如此重要的关头，在变革的前夜，我认为正确的做法是“战术上立即应对，一点站位都不用担心”。不学习和理解微信小程序是绝对不可能的，但是根据目前的信息来调整公司的方向还为时过早。毕竟还处于内测阶段。如果内测结果是“重建”或者“大幅调整”（泄露的信息已经处于正式发布的状态，应该不会有太大的改变），那就花在这里时间已经浪费了，我还没哭所以我觉得公司马上成立一个短期的临时小组，鼓励对小程序感兴趣的同学加入，一起开发几个有趣的小程序，主要是为了学习，比较合理。效果好的话，可以赚一波眼球。微信小程序正式公测后，将决定是否将这个临时组升级为正式的产品团队。

这几天，通过目前掌握的信息，我对小程序的整体架构有了初步的了解。我的风格一直是从架构和系统设计的角度做一些深入的、固执己见的分析。现在终于可以回答小伙伴们的问题，说说自己的想法了。

什么是微信小程序？

官方说：

“我们提供了新的开放能力，让开发者可以快速开发小程序。小程序可以在微信内轻松获取和传播，用户体验极佳。”

听起来很不错，具体点，和目前公开的信息和微信其他开放形式对比一下

看得出来，腾讯还是很有诚意的。这次在微信小程序上开启了很多新的能力。不再是渐进的演进，而是有点像一场革命。

小程序入口在哪里？

目前公开的信息中最相关的入口点只提到了小程序可以通过扫描二维码打开，所以业界对小程序的入口有几个流行的假设：

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

概率：99%。小程序无法出现在朋友圈，流量从何而来？

假设1：出现在发现标签页，游戏下方（每个小程序占一栏），同时摇一摇得到附近的小程序

可能性：80%。围观腾讯游戏，别亏待你。

假设2：与当前公众号和服务号类似，安装出现在会话列表中

概率：90%。新的开启能力和旧的开启能力使用同一个入口也就不足为奇了。

假设3：安装后，和app一样，会直接出现在桌面上

概率：10%。与微信同级，腾讯未必同意。

假设4：微信多一个小程序标签

可能性：1%。多一个tab太丑了，小程序刚刚发布，不可能马上影响微信的整体架构。

假设5：出现在一些内置流程中（如与好友聊天界面，发朋友圈界面（拍照后处理））

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

微信小程序框架分析

官方已经正式发布了小程序的开发资料。小程序的开发框架由API和组件两部分组成。官方资料在组织和内容上都写的很好，阅读体验也很流畅。如果您还没有阅读过，建议您先简单阅读一下。基本上，有一定经验的前端开发者可以毫无障碍地掌握当前素材的内容。

首先看一下框架的低级 API 部分。微信一直有一个运行中的“JS-SDK”，不断进化。对比小程序底层 API 的功能范围，与 JS-SDK 还是有很多相似之处的。相信以后形式会统一（JS-SDK的名字也够霸气，里面放什么也不会奇怪。不过JS-SDK的很多接口的设计真的不讨人喜欢.我希望这个统一的流程也可以再次修改）。由于小程序的API部分可以跳出浏览器的框架，理论上可以是JS-SDK的超集。

我觉得有趣的是：

>>网络通信

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

既然支持跨域，也许以后可以在小程序中直接使用tcp和udp协议，是基于某种二进制协议的开发能力。跳出HTTP协议的框架，对于物联网方向很有想象力。

>>数据缓存

数据缓存接口的设计看起来和中的基本一样，就不多说了。但是文档中的一句话激起了我的兴趣：

“注意：永久存储，但我们不建议存储所有关键信息小程序的开发文件系统架构，以防用户更换设备。”

有没有可能微信提供的数据缓存能力虽然不是永久存储，但是可以跟随用户账号而不是当前设备？也就是说，无论用户怎么换手机，安装的和使用的小程序都可以使用同一个缓存（没有不登录使用小程序的场景）？虽然微信自己的聊天记录还没有跨设备漫游，但是这个app文件的支持可以在不增加开发工作量的情况下大大提升用户体验（作为一个重度用户，我完全离不开。开启自动同步游戏存档） 这也让我对小程序在云端的能力有了一些初步的想象。

小程序官方QA中有一段话：

/会用到对象和对象，所以不能用

这意味着所有基于它的现有底层代码资产都无法完全无缝迁移。但是，即使是这样一个常用的库也不兼容，仍然很痛苦。当然，现在可以通过剪裁或者兼容的方式提供可以在小程序平台上运行的通用js底层库，短期内会有市场。

MINA框架分析

接下来我会讲解微信小程序提供的一些界面功能，这也是最精彩的部分。一个小程序肯定是基于MINA框架的（我从泄露的信息中知道这个框架叫MINA，官方资料中已经把名字删掉了，但是为了后面写的方便，我会一直叫应用框架小程序MINA) 构造。一个典型的小程序结构如下：

app.json 小程序配置：

1.小程序中包含哪些页面。

2.页面以包的形式显示。

3.是否需要支持多个标签页，如果需要，每个标签页的默认页面是什么？

4.一些底层组件的默认参数。

app.js（可以理解为入口函数）处理app的几个关键事件：，，定义了app级别的数据格式（可以在不同页面之间共享）。

app.wxss 公共样式表：每个页面的样式表都继承自这个应用级公共样式表。

MINA 的主要核心概念之一是 Page。页面是可以在应用程序中导航到的最小粒度界面。而如何搭建一个Page，与以往大家的猜测最大的不同。微信没有使用，但提供了一套新的设计。新设计要求每个页面包含 3 个文件：

.js ：包含Page的逻辑处理代码，其中最重要的是定义Page的数据（可以通过数据绑定机制直接访问wxml）

.wxml ：页面的布局文件。如果从演示中随机选择一个布局文件，其整体结构非常简洁明了。即使没有提供任何信息，您也大概可以看到表达了什么样的页面。

.wxml 不是一个完整的静态布局文件，但也支持条件渲染和列表渲染。 .wxml 使用 {{}} 语法简单直接地支持数据绑定。可以通过方法复用

.wxss：样式表。确定 wxml 中定义的各种组件最终应如何显示。官方文档没有列出 wxss 的语法和支持，只是说它“具备 CSS 的大部分特性”，而且 wxss 样式表还扩展了一些微信小程序特有的样式作为属性。

Page 的整体设计具有比较明显的“反应式”编程风格。相信有vue.js、.js开发经验的同学可以很快上手。由于没有内测资质，所以无法在手机上测试性能。目前尚不清楚小程序的框架是否存在反应式编程的常见性能问题。公测后，写个10万条数据的列表，看看滚动流不流畅。

目前该演示没有使用 ES6，所以它看起来并不那么“现代”。这可能是因为小程序项目成立的比较早。不过ES6是大势所趋，相信未来小程序会支持使用ES6开发。

基于 MINA 的小程序最终如何运行？

官方说：

所有开发者编写的代码最终都会打包成一个副本，在小程序启动时运行，直到小程序被销毁。类似，所以逻辑层也叫App。