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

的公众号、服务号类似，安装出现在会话列表可能性:90%。新的开放能力和旧的开放能力用一样的入口不奇怪吧。假设三：安装后和native app一样，直接出现在桌面可能性:10%。和微信在同一级入口，腾讯同意Apple都不一定同意。假设四：微信多一个小程序的tab可能性:1%。多一个tab太丑了，而且小程序刚发布，不可能立刻就对微信的整体结构产生影响。假设五：出现在一些内置流程中（比如和好友的聊天界面内，发朋友圈的界面（拍照后处理）可能性:1%。小程序和微信本体使用不同的框架技术开发，互相嵌套有困难。微信小程序框架浅析官方已经正式公开了小程序的开发资料，小程序的开发框架包含两大块内容，分别是：API 与 组件。官方的资料在组织和内容上都写的还不错，阅读体验也很顺畅，没看过的话推荐先简单的通读一遍。基本上有一定经验的前端开发都可以没有什么障碍的掌握目前资料里的内容，我就不去做入门性的介绍了，直接浅析吧。先看框架的底层API部分。微信一直有一个贯穿的"JS-SDK"在不断演进。对比一下小程序的底层API的功能范围，和JS-SDK还是有很多相似的感觉，相信未来会在形式上达到统一(JS-SDK这名字也足够霸气，塞进去什么都不会觉得奇怪。不过JS-SDK的很多接口设计的实在不敢恭维，希望这次统一的进程也能重新修正下)。小程序的API部分由于可以跳出浏览器的框架，理论上肯定可以是JS-SDK的超集。JS-SDK这名字也足够霸气，塞进去什么都不会觉得奇怪。不过JS-SDK的很多接口设计的实在不敢恭维，希望这次统一的进程也能重新修正下这里面我觉得比较有意思的地方有：>>网络通信只要目标服务器的域名在小程序配置的安全列表之类，就可以直接通信。不用考虑js的跨域问题了。既然跨域都支持了，没准以后能像nodejs一样，直接在小程序里使用tcp,udp协议，并基于buffer有一定的二进制协议的开发能力。跳出HTTP协议的框架，对于IoT方向是很有想象空间的。>>数据缓存数据缓存接口的设计看起来和 HTML5里的localStorage基本上一样，本来没什么好说的。但文档里的一句话引起了我的兴趣：“注意：?localStorage 是永久存储的，但是我们不建议将关键信息全部存在 localStorage，以防用户换设备的情况。”难道微信提供的数据缓存能力虽然不是永久的存储，但可以做到跟随用户账号而不是当前设备？ 也就是说，不管用户怎么换手机，已安装使用过的小程序都能使用同一份缓存（不存在不登陆使用小程序的场景）？虽然微信自己的聊天记录跨设备漫游都没做，但这种app personal file cloud的支持，还是能在不增加开发的工作量的情况下，大幅提升用户体验的（作为一个steam的重度用户我已经完全离不开游戏存档的自动同步功能）。这也让我对小程序在云端的能力，开始有了一些初步的想象。不存在不登陆使用小程序的场景作为一个steam的重度用户我已经完全离不开游戏存档的自动同步功能>>并不兼容一些常见js底层框架小程序的官方QA里有一段话：zepto/jquery 会使用到window对象和document对象，所以无法使用zepto/jquery 会使用到window对象和document对象，所以无法使用这意味着所有基于HTML5的已有底层代码资产，并不能完全无缝的迁移过来。不过连jQuery这么常用的库都不能兼容还是有一点伤的。当然，现在用裁剪或兼容的方法，提供能在小程序平台运行的常见js底层库，短期内会很有市场。MINA框架剖析接下来我要解读微信小程序提供的界面部分功能，也是最令人兴奋的部分。一个小程序，必须基于MINA框架（从泄漏的资料里得知这个框架叫MINA,正式的资料里删除了这个名字，但为了后面行文方便，我会一直把小程序的应用框架称之为MINA）构建。一个典型的小程序的结构如下：从泄漏的资料里得知这个框架叫MINA,正式的资料里删除了这个名字，但为了后面行文方便，我会一直把小程序的应用框架称之为MINAapp.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可以通过数据绑定机制直接访问）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。开发者写的所有代码最终将会打包成一份 JavaScript，并在小程序启动的时候运行，直到小程序销毁。类似 ServiceWorker，所以逻辑层也称之