迅雷首席架构师刘智聪：微信小程序的架构与系统设计的几点观感

 

　　笔者注：本文来自于迅雷首席工程师刘智聪的我的分享，他毕业于南昌大学化学系，加入迅雷后设计开发了多款迅雷核心产品，凭借“大规模网络流媒体服务关键支撑技术”项目得到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 技术来作应用号(正式名称：小程序)，可是它并无真正用到 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的可能性。

　　感谢各位关心。

本文连接:http://www.yixieshi.com/54848.html(转载请保留)

做者： 三少爷的剑