微信小程序的架构与系统设计的心得

　　业界对目前微信使用的UI框架，有两种截然相反的观点，比如“微信小程序带动HTML5发展”“微信小程序的本质说来就是一个HTML5应用”。而有的人又认为：“微信虽然用了HTML5技术来做应用号（正式名称：小程序），但是它并没有线的精髓——开放、互联，也就决定了它可能无法实现‘微信OS’的最终野心。”这两个观点是矛盾的，那么，到底哪种观点是正确的呢？首先简化一下问题：微信小程序是基于HTML5开发的么？

　　搞清楚MINA和HTML5的关系后，我们还是没有搞清楚为什么微信要提供一个新的MINA框架。事实上这个问题是一个讨论设计的问题，所以要回答这个问题，需要具备一定的设计能力，而不是只停留在研究MINA实现的层面。而设计能力是一种比较稀缺的能力，想要系统地提升自己的设计能力，简单来说就是“多看多想”。那么如何多想呢？我有一套还算完整的方法，简单来说有如下几步：首先，在研究一个新东西以前，先想想这个新东西是为了解决什么样的问题出现的。问题要多提，往深了提，反复提炼，最后得到几个好问题。或从一个问题引申出一些子问题。很多时候只要问题提对了，设计就明白了大半。下一步就是试着自己解决一下，回答一下自己提的问题，并比较不同的解决思路的优劣，形成一个对问题解的标准。比如说问题是“如何在一个超长文本中查找子串”，那么对问题的评价标准就可以是查找速度，以及查找过程中的内存占用。接下来就是看别人如何解决这些问题的了。如果和自己的设计差不多，一边窃喜一边开始按自己预先设计的评价标准对别人的设计的好坏进行判断。如果是自己完全没想到过的解法（这通常会出现在第一次接触某个领域的问题），可以按图索骥地补充一些基础知识，再回来看。如果这个领域或解法非主流到不是常见范式，那么可以安下心来好好搞清楚、想明白。这样带着问题研究设计，才能有效地提高自己的设计能力。

　　假设三：和当前的公众号、服务号类似，安装出现在会线%。新的开放能力和旧的开放能力用一样的入口不奇怪吧。

　　官方已经正式公开了小程序的开发资料，小程序的开发框架包含两大块内容，分别是API与组件。官方的资料在组织和内容上都写得不错，阅读体验也很顺畅，没看过的话推荐先简单地通读一遍。基本上有一定经验的前端开发都可以没有什么障碍地掌握目前资料里的内容，我就不做入门性的介绍了，直接浅析吧。

　　目前公开的资料里对大家最关心的入口问题只提到了小程序可以扫二维码打开，于是业界对小程序的入口有了这么几种流行的假设。

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

　　假设二：出现在发现Tab页面中，游ຫໍສະໝຸດ Baidu下面（每个小程序占用一列），同时摇一摇也可以得到附近的小程序。

　　只要目标服务器的域名在小程序配置安全列表之类，就可以直接通信，不用考虑JS的跨域问题了。既然跨域都支持了，没准以后能像Node.js一样，直接在小程序里使用TCP、UDP协议，并基于Buffer有一定的二进制协议的开发能力。跳出HTTP协议的框架，对于IoT方向是很有想象空间的。

　　数据缓存接口的设计看起来和HTML5里的localStorage基本上一样，本来没什么好说的，但文档里的一句话引起了我的兴趣。注意：localStorage是永久存储的，但是我们不建议将关键信息全部存在localStorage，以防用户换设备的情况。难道微信提供的数据缓存能力虽然不是永久的存储，但可以做到跟随用户账号而不是当前设备？也就是说，不管用户怎么换手机，已安装使用过的小程序都能使用同一份缓存（不存在不登陆使用小程序的场景）？

　　先看框架的底层API部分。微信一直有一个贯穿的“JS-SDK”在不断演进。对比一下小程序的底层API的功能范围，和JS-SDK还是有很多相似的感觉，相信未来会在形式上达到统一（JS-SDK这名字也足够霸气，塞进去什么都不会觉得奇怪。不过JS-SDK的很多接口设计得实在不敢恭维，希望这次统一的进程也能重新修正下)。小程序的API部分由于可以跳出浏览器的框架，理论上肯定可以是JS-SDK的超集。

　　通过分析小程序的运行原理，这个答案是明确的：小程序的开发过程会用到大量HTML5相关的技术,但并不是使用HTML5开发。有HTML5经验的前端工程师学习微信小程序的开发相对会更容易一些。微信小程序的运行并不需要一个完整支持HTML5特性的标准浏览器内核，但也可以通过添加一些辅助设施，让小程序在完整支持HTML5标准的浏览器上运行起来。“由于框架并非运行在浏览器中，所以JavaScript在Web中一些能力都无法使用，如document、window等。”也就是说，一个已存在的HTML5页面，并不能通过自动转换工具变成一个合法的Page，而需要有工程师根据HTML5页面的功能，使用MINA框架再实现一次。