美团外卖小程序的探索和实践（演讲内容整理）丨掘金开发者大会

2017年1月9日，微信官方在2017微信公开课Pro上发布的小程序正式上线，开创了小程序开发的时代。咱们的美团外卖的业务也逐步加入到小程序开发的队伍中。小程序有着无需安装、触手可及、用完即走、无须卸载的特色，属于“轻”量级的应用。

可是这样的“轻”量级应用却承载咱们很是复杂的外卖业务，对于咱们外卖团队来讲，也面临着不少新的机遇和挑战。本文将详细介绍咱们外卖小程序的解决方案与经验，但愿可以对你们有所启发。本次分享主要由如下四个部分展开：

第一部分：技术架构

小程序发布时，其定位主要是功能比较简单的轻应用，因此原生框架设计相对比较简单，而对于业务相对复杂的中大型互联网企业，小程序产品支持还不够完善，项目较难进行管理和维护。

而美团外卖小程序按照业务、主流程、营销、广告等划分了多个团队共同进行开发，如何保证多团队高效协同地开发小程序就是一个难题；同时在美团外卖小程序中，主流程要求稳定增量更新，营销活动则须要快速迭代多渠道支持，针对不一样的业务场景需求，如何去作好支持工做也是很是重要的一环。那么如何应对这些挑战呢？

业务场景

针对业务场景的多样性，咱们采用了较开放的框架策略：项目既支持原生框架开发，又支持自由引入第三方框架，以知足各业务场景的需求。

• 原生框架开发：对主流程等相对独立且稳定性要求高的业务采用了原生框架进行开发。

  • 一方面，咱们考虑小程序原生框架不够完善，随着基础版本库的升级，存在须要处理的兼容性问题，避免引入第三方框架增长调试难度或引入新的问题。
  • 另外一方面，小程序代码体积限制比较严格，避免引入第三方框架在编译过程当中引入较大的框架代码。

• 支持mpvue（第三方框架）：营销业务须要支持Web页、小程序页等多种渠道，经过引入mpvue，可使各渠道复用Vue组件，进而提高开发效率。

通用组件

针对咱们面对的业务场景，咱们将各业务通用的基础功能进行了梳理，抽离成一些组件来进行统一管理和维护。高复用性组件可以有效提高开发效率，并且研发质量也能够获得很好的保障。

协同开发

多团队合做开发小程序的模式下，咱们将核心的主流程业务放在主包，其余各业务都存放在各自子包当中。这样作的目的，是确保每一个包中的业务相关性较强，避免了用户使用中会有频繁的子包模块加载过程，也能保证各业务团队之间的隔离，避免出现业务冲突。

咱们的通用组件和各业务子包都托管在npm上，而后进行模块化的管理。并经过对构建脚本的改造，将npm引入到小程序主包中，进一步保证各业务间的隔离性，以下图所示：

同时咱们在小程序开发周期中，制定了版本管理、准入流程、发布流程等，规范化小程序各环境版本的使用，进一步确保各团队间的顺畅合做。总体架构图以下图所示：

咱们的系统架构，最底层是微信小程序的原生API，中层是各业务通用的核心组件，如登录、WebView封装组件、监控、数据上报等，均由统一的团队建设和维护。对编译构建工具进行插件化改造，能够自由引入第三方框架进行开发。最上层是各业务方经过拆包将业务隔离开来。

第二部分：流程与工具

• 工具规范方面：咱们提供了子包项目、组件建立脚手架。好比登录、WebView等通用组件以及业务组件都使用咱们的组件脚手架来进行建立，简化并较低成本规范了子包项目搭建和构建过程，提高项目搭建效率与合做效率。
• 测试方面：咱们为组件接入了单元测试。小程序整个项目的单元测试和UI的自动化测试也在建设中。咱们在小程序开发周期中，制定了版本管理、准入流程、发布流程等，规范化小程序各环境版本的使用，进一步确保各团队间的顺畅合做。

开发过程

在本地开发过程的整个构建流程以下图所示。开发者在本地工做目录执行操做，经过gulp构建目标文件到本地工做目录中，再经过微信开发者工具对生成的代码进行调试和发布。同时咱们的构建支持Mock服务，模拟后端服务器接口，提升联调效率。

发布过程

咱们的发布规范过程以下图所示。和通常的前端发布过程相似，差别点在于必须通过微信开发工具才能上传代码进行微信方的审核与发布。

而咱们的指望和后期规划是将整个CI构建和发布过程一体化。以下图所示：

近期微信开发者工具提供了命令行工具和HTTP方式来支持小程序的预览和上传，咱们正在将整个流程进行整合与改造。经过在服务器中安装微信开发者工具，将整个过程使用CI链接起来，减小人工操做的过程，来提高发布流程的效率和质量。

不过在实现彻底自动化发布的道路上依然面临着一些问题：

• 开发者工具的登录，公众后台的提交审核和发布都须要人工介入。
• 因为微信开发者工具目前仅有macOS和Windows两个版本，而CI服务器大可能是在Linux系统上，还须要额外启动服务器来部署开发者工具，改造过程也相对复杂。

第三部分：组件化

原生组件化演进

小程序原生框架对于模块和组件的支持也处在不断完善的过程当中。最先小程序框架支持CommonJS规范，可使用require、module关键词定义和引入js模块，支持经过@import来引入样式文件，支持在布局文件wxml中支持定义template模板，能够经过include、import和wxs等标签引用外部文件。

而实现一个组件，经常wxs逻辑，wxss样式和wxml布局三个文件都须要进行定义，这就意味着引用一个组件时，须要在三个文件中同时引入。组件独立性差，与页面文件高耦合，不利于开发和维护，使用起来很是不便。

所以在基础库1.6.3版本中，小程序开始支持自定义组件，只须要经过标签就能够很方便的引入本身开发的组件。但早期的自定义组件版本，只容许绑定JSON兼容格式的数据，并不支持回调函数，在使用上存在很大局限性。直到2.0.9版本才开始支持函数传入。

近期，小程序原生支持了npm，但基础版本库要求在2.2.1及以上，而且须要经过微信开发者工具进行一遍构建。整体来讲，小程序框架在不断完善对组件的支持，但若是考虑低版本用户的兼容性，开发者开始有较多工做要作。

组件分类

咱们将组件划分为三种类型，页面组件、UI组件、功能组件。

• 页面组件：功能相对比较独立的页面，如用于内嵌H5的WebView封装页面等；
• UI组件：页面中局部功能较独立的UI部分，好比页面中嵌入的登录组件，商家列表等；
• 功能组件指：无UI和交互，纯JS的模块。

通用组件关注方向

咱们基于微信组件的演化也在扩充和完善咱们的通用组件过程当中，同时也相同存在着一些局限性，以后针对通用组件的关注方向主要在如下两方面：

• 小程序组件原生功能的补充和完善。
• 通用基础及业务功能统一封装。

Storage组件

大小约100k随机对象读写清空缓存各100次，小程序Storage与Web LocalStorage 耗时比较以下图所示：

可见小程序的性能远低于Webview的LocalStorage，因此针对这样的现状，咱们Storage组件的封装与设计必须重点考虑性能问题的解决与规避。

Storage组件优化

针对小程序Storage的读写性能差，且存储量有限的状况下，咱们Storage的设计有如下特色：

• 内存高性能读写数据：利用内存存储数据替代大量数据存在小程序Storage中，从而规避Storage读写操做的性能瓶颈，同时减轻存储量的占用率。
• 文件持久化存储：采用内存与Storage相结合的形式，保证缓存数据的可用性。
• 数据同步：因为持久化的策略，因此须要有完整并保证准确性的流程来同步内存数据与Storage数据。

整个流程以下图所示：

防止误调用底层API致使数据不一样步：

• 写入文件时key追加特殊前缀
• 编译时进行语法检查，误调用及时告警

第四部分：展望与规划

目前小程序开发工具也在不断完善中，最近增长了不少诸如npm 支持、命令行调用、HTTP调用、Git版本管理、云开发、体验评分等功能，工具的完善为开发者带来了必定便利。

小程序的特殊性致使小程序开发人员与微信提供的开发工具的强粘黏性，能够感知到微信小程序开发工具的设计是指望实现一个小程序开发的闭环。

但这样的一个“黑盒”工具也存在着必定问题——没法知足不一样团队和业务的一些需求。因此咱们也但愿，将来小程序开发工具能提供一些工具开放功能的API，咱们能够对开放功能进行改造实现，最终知足各个团队不一样的需求。

同时小程序在最初的定位（功能比较简单的轻应用）和设计下，性能不会过高。若是承载较大型复杂的业务，势必会遇到一些性能问题，因此性能问题的关注是比较重要的。官方对于性能问题在开发上的建议是控制setData 的数据体积大小、控制setData的频率。但真实的业务场景中有不少是没法避免频繁setData的，如对滑动操做（较高频的动做）后的一些特殊需求、复杂页面点击快速响应等。

美团外卖在基于这些问题的规划包括：

• 小程序性能的测试指标定制：及时发现项目的性能瓶颈，进行有针对性的优化。通过测试小程序渲染数据达到100Kb时卡顿明显，尤为在安卓手机，因此其中就包括对渲染数据大小制定必定指标。
• 性能分析工具：开发一些工具对性能进行分析。
• 框架优化：从框架层来针对性规避遇到的一些问题。
• 长列表组件的实现：使用官方提供的长列表组件。

此外，与性能并存的一个问题是小程序体积的限制（不超过2M，包含子包的主包，总包不超过8M）。这样的限制有必定道理，由于小程序渲染前，须要通过下载整个小程序的包体、后端请求数据、对数据进行渲染这样相对较长的周期，包体过大必然影响用户感知渲染的时间，影响用户体验。

减少体积的规划采起方案包括：

• npm依赖优化：npm包之间内部的依赖包会存在重复的状况，重复的部分都占用包体积，采起对代码预解析简化npm包代码来缩小包体。
• 图片部署CDN：图片体积占包较大，非关键图片部署到CDN。
• 非关键页面迁移子包：采用子包、独立子包的方式减小对主包体积的占用。
• 页面动态下发：小程序不支持动态下发功能，目前咱们正在探索和考虑。

这两大重点问题在咱们的业务场景和当前架构设计下，都是将来长期须要关注和解决的问题。

总结

咱们复杂的业务在开发小程序时虽然面临着这样一些问题：“轻”量应用的小程序对于较大型的应用和较复杂的业务场景存在着必定的局限性，“轻”量理念的原生框架稍简单，不足以完美支撑咱们较大型和复杂的业务；多团队合做如何保证高效性；如何更友好地知足不一样的业务场景。

最终咱们经过在技术框架层面优化设计和规避一些小程序局限性问题，制定更合理的流程和建设更强大的工具来提升工做效率，基于微信小程序组件化演进建设咱们的组件化生态，来解决咱们所面临的问题。同时也对微信小程序工具、性能、体积等方面进行展望和规划咱们的后续进程，保持咱们的深度探索和实践。