笔者注：本文来自于迅雷首席工程师刘智聪的个人分享，他毕业于南昌大学化学系，加入迅雷后设计开发了多款迅雷核心产品，凭借“大规模网络流媒体服务关键支撑技术”项目获得2015年国家科学技术进步奖二等奖，同时也是第四代UI交互技术-----BOLT 界面引擎的发明人，目前担任WebApp解决方案商--火速移动的首席技术顾问。
21号晚上正和朋友一起打牌，难得的小七对刚刚定口，突然间手机传来了“叮咚”的消消息提示音，随后就是“叮叮，咚咚”的连续震动。打开手机一看，微信上一堆人发信息给我，先是一篇《微信应用号来了》，然后就是：“你怎么看？”
虽然之前曾经得到过消息说“微信应用号”会在年底发布，但没想到居然来的这么快，而且还改名叫“微信小程序了”（简称小程序）。已经无心打牌，赶紧完成一吃三后速度回到电脑前开始了持续几天的研究。而且这几天里各种相关资料都开始相继出现，内测用的开发工具也有破解版漏出了。
身边已经有不少朋友已经根据资料开始干活了，差不多有如下几类：
1）好好释放想象力，要是能在公测的时候做个有趣的小程序出来一炮而红那就赚大了
2）公司有一打的服务号，其实改成小程序会更合适（管它合不合适，改了再说！）
3）又是一轮洗牌的机会！那个公众号的功能是我先想到的但被别人抢了，这次我要在小程序里第一个做出来并做到第一名！
4）微信果然是互联网的“国务院”，新政策草案刚出立刻引起全行业的连夜研究。这么重要的关头，变革的前夜，我认为正确的做法是“战术上立刻响应，站略上不必着急”。不学习，不了解微信小程序是万万不行的，但立刻根据现在的资料，调整公司的方向，也有点为时过早。毕竟现在还在内测阶段，万一内测结果是“回炉重造”或则“大幅调整”（目前泄漏的资料已经处于正式发布的状态，应该不会大改了），那花在这里的时间都赔进去了还没地哭。所以我觉得对公司来说比较合理的做法是在立刻成立一个短期的临时小组，鼓励对小程序有兴趣的同学加入，一起开发几个有趣的小程序，主要目的就是学习。如果做出来的结果好还能赚一波眼球。等微信小程序正式公测了，再决策要不要把这个临时小组升级成一个正式的产品团队。
这几天通过目前公开的资料我已经对小程序的整体架构有了个初步的认识。我的风格一向是从架构和系统设计的视角做一些深度的，有观点的分析。现在终于可以回应朋友们的问题，谈谈我怎么看了。
微信小程序是什么？
官方这么说：
“我们提供了一种新的开放能力，让开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验”。
听起来非常美好，咱们具体一点，结合目前公开的信息和微信目前其它的开放形式对比一下吧
可以看到，腾讯还是非常有诚意的，这次在微信小程序上新开放的能力很多，不再是渐进式的演变而有一点像革命了。
小程序的入口在哪？
目前公开的资料里对大家最关系的入口问题只提到了小程序可以扫二维码打开，于是业界对小程序的入口有了这么几种流行的假设：
假设零：朋友圈，朋友可以把自己喜欢的小程序分享在朋友圈，看到了可以点击打开直接使用。
可能性: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的跨域问题了。
既然跨域都支持了，没准以后能像nodejs一样，直接在小程序里使用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 小程序配置：
1.小程序里一共包含哪些页面。
2.页面套在一个怎么样的 window里显示。
3.window是否需要支持多tab,支持的话每个tab的默认page是什么。
4.一些底层组件的默认参数。
app.js（可以理解为入口函数）处理app的几个关键事件:onLaunch,onShow，定义了app级（可以在不同的页面之间共享）的数据的格式。
app.wxss 公用样式表：每个页面的样式表，都是从这个应用级公有样式表继承下来的。
MINA一个最主要的核心概念是Page，一个Page是应用内可以导航到的最小粒度的界面。而如何构建Page是与大家过去猜测差别最大的地方。微信并没有使用HTML5，而是提供了一套新的设计。新的设计要求每个 Page由3个文件构成：
index.js :包含Page的逻辑处理代码，其中比较重要的就是定义Page的数据（wxml可以通过数据绑定机制直接访问）
index.wxml : Page的布局文件。随便从demo中选一个布局文件来看，其整体结构非常简介清晰，即使没有提供任何资料也大概能看出来表达了一个什么样的页面。
.wxml不算是完全的静态布局文件，还支持条件渲染和列表渲染。.wxml使用{{}}语法来简单直接的支持数据绑定。可以通过template的方法进行复用
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 技术来做应用号（正式名称：小程序），但是它并没有真正用到 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的具体平台特性无关的。
要面向更多的非专业开发者，所以学习门槛要低。
大规模的专业团队进行团队开发时，能有足够的工程支持。工程支持包括：
模块化
代码易于长期维护和修改。这意味着基于框架的实现具体需求的结果要足够清晰，好读。
可复用性设计。
小程序不需要安装就可以快速开始使用，只需要加载必要的资源就可以尽快展现用户需要的页面。
进一步思考这些需求该如何解决，并对不同的解决方案进行评价需要的领域知识非常多，已经超过了本文的讨论范围。我在这里要做的只是带你入门，让你开始思考设计问题就够了。这也是本文的核心目的：学会对新技术，新设计进行独立的分析和判断。至于结果么，现在小程序还处于一个早期的状态，等公测了之后在下结论也不迟。
而如何更好更快的探索小程序的可能性，也将是我接下来创业的方向。我将以火速移动技术顾问的身份，和小伙伴们一起从微信小程序开始，去探索移动Web的可能性。
感谢各位关心。