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

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

  可能性: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 公用样式表:每个页面的样式表,都是从这个应用级公有样式表继承下来的。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zgwgxf.html