258资源分享网

伴随着从2017年1月9日凌晨的夜色，张小龙和他的团队正式发布了微信小程序，瞬间刷爆了业内人士的各种信息流，一个看似『银弹』的产品形态被大家所热捧，一股开发浪潮也随之而来。而近期，微信又做成了两个很大的突破：微信悖逆苹果做小程序市场（应用内搜索已经有『市场性质』）和允许小程序通过社交传播（可以通过小程序第三方平台朋友圈和聊天传播，二维码可以长按识别），同时让开发者们看到微信小程序发展的信心和前景。总之，不管是『红利』还是『鸡血』，小程序将成为产品布局中重要的一个组成部分。因此，在公司内部，将小程序开发流程统一化、规划化，让小程序开发变得优雅是相当有必要的。

下面，GitChator将以去哪儿网微信小程序为背景，详细对去哪儿网微信小程序工程流程化方案进行剖析，同时与读者们进行交流探讨。

读者们一定很奇怪，为什么先聊到『开发问题的转变』？因为做架构、做工程流程化的目的是为了降低开发、测试、发布、运维等一系列环节的成本的同时，解决这些环节之间存在的问题和痛点。所以理清开发小程序的过程中遇到的问题，才能更好的做架构、做工程流程化。

那么，小程序开发急需解决什么问题？而问题又有什么转变呢？

从内测开始到半个月之前，有一个数字非常让人头疼 —— 1024 。这个数字代表着小程序的总 Size，小程序打包后的总体积不能超过 1024 KB （也就是 1 MB）。在这个有限的空间内，放入更多的业务逻辑，这才是当时小程序开发遇到的最大的问题。因此， 压缩 是当时首当其冲的工作。

当初，公司准备将去哪儿酒店、去哪儿门票和去哪儿交通三个小程序中的五个业务线合并到统一的一个小程序中。笔者所在的团队接到了这个任务，并在业务线配合下，在一个星期的时间里，完成任务上线，而后又在剩余的体积内塞入了两个其他的业务。在当时的情况下，每压缩出 10KB 的体积，都是一件很令人兴奋的事。

而现在不同了，微信将小程序的 Size 增加到 2MB ，也就是 2048 KB，足足 翻了一倍 。 由于有之前 1024 的经验，翻倍后，在相同的压缩逻辑下，已经足够满足绝大多数 App 的要求。例如，将去哪儿旅行 App 上的主要业务的主要流程都放进微信小程序内，应该是没问题的。

所以，在压缩问题并不突出明显后， 如何更好的管制作小程序控小程序的代码 ， 如何做好业务隔离 ， 如何分配业务资源的配比 ，这些问题将会成为现在以及以后核心要解决的问题。当然，压缩也是工程流程化的一部分，只是优先级降低而已。

最后，提出一个问题：据上文所述， 可以将去哪儿旅行 App 上的主要业务的主要流程都放进微信小程序内 ，但是在灵活的小程序应用场景下，这样真的好吗？真的适合小程序的场景吗？这也是工程流程化要考虑和完善的一个问题。

对于小程序的架构，用一句话总结就是 『类 React Native 的 MVC Web UI 架构』。小程序的架构思想与 React Native 类似，都是以组件化的方式和 MVC 的模式将 UI 层和 Service 层分离，在保证 UI 层的显示效率的同时，也保持了 Service 层的一致性；而与 React Native 最大的不同是：React Native 使用的是 Native 的 UI，而微信使用的 Web UI。

相比来说，Native 的 UI 性能更好，但也更依赖系统和 App 本身的 Native，不易维护和进行热更新；而 Web UI 性能和 Native UI 有一定的差距，但是依赖少，易维护并且容易实现热更新。

小程序的架构就先简单介绍到这里，大家可以从其他的 GitChat 文章里了解更多。这次GitChat 主要要阐述的是小程序的工程流程化问题，而为了实现工程流程化，在简单了解小程序架构的同时，也必须先了解基于这套架构的一些技术细节，例如代码结构、构建方法、调试发布方式等。

下面简单列举一些比较重要的点。

首先，在工程内有三个公共入口文件：

app.json ：配置文件，配置路由列表、程序信息等。

app.js ：公共入口文件，小程序启动时的 Init 逻辑。

app.wxss ：公共样式文件，公共样式用于每个视图 View 中。

同样的，对于每个视图 View 都存在与其对应的入口文件，假设此 View 为 page ，那么

page.json ：此视图 View 的配置。

page.js : 此视图的脚本逻辑。

page.wxss : 此视图的样式。

其他的，不论是 JavaScript 脚本还是 Wxml 模板和 Wxss 样式，应被入口文件 require/import 使用。