如何解决小程序开发中的协同和平台兼容性问题？

受访者 | 薛端阳

采访者 | 伍杏玲

出品 | CSDN（ID：CSDNnews）

2017 年 1 月 9 日，微信小程序诞生，自此我们从移动互联网时代踏入小程序时代。目前各大巨头公司正在紧锣密鼓地布局小程序市场：

微信小程序日活达 6 亿；百度小程序月活用户达 2 亿；支付宝小程序日活用户达 2.3 亿；快应用覆盖 10 亿设备，月活 2 亿……

同时小程序亦是开发者较关注的技术趋势。那么这么多的小程序平台，作为开发者，我们该如何选择？在小程序开发过程中，多前端生态下，后端该如何部署呢？多部门协同发布一个小程序时，我们又该注意些什么呢？

在阿拉丁统计平台上，携程微信小程序位居 7 月总榜单的 23 位，且携程在各生态均有布局。所以 CSDN（ID：CSDNnews）邀请到携程小程序的技术负责人薛端阳，为我们分享携程小程序的技术开发经验。

CSDN：请您自我介绍下。

薛端阳：我是携程小程序的技术负责人，薛端阳，主要负责公司所有对接小程序相关技术业务，包括对外合作技术引进，对内业务向框架技术研究，技术布道，打通内部横向合作障碍，努力为携程系各业务 BU 提供方便、高效、稳定、易用的小程序接入整体解决方案。

在我的职业生涯期间，先后开源过 KitJs 移动端 UI 框架、ReactMix 通用 RN for Web解决方案等，经历了 Web 技术从最早的 prototype.js 到现在的 React 的飞速发展，平台从 H5 到 RN，再到现在很火的小程序。

我们经过多年的探索研究，从用户体验、技术上手难度、深度使用体验、社区活力市场支持力度等几个方面看下来，一致觉得目前小程序技术具有旺盛的生命力，在综合能力上属于极具市场前瞻性的技术平台产品，值得大力投资，并跟随风口。

携程网是 2017 年开始开发小程序，属于市场上第一批接入，并对接所有小程序平台的内容供应商，包括微信、QQ 浏览器、支付宝、高德、快应用、百度、头条。

在第三方智库发布的小程序排行榜上，携程小程序始终稳定在前五的排名。

自研小程序框架开发过程遇协同难题

CSDN：目前小程序的框架有很多，例如滴滴的 Chameleon、美团的 Mpvue、京东的 Taro、腾讯的 WePY 等，请问携程网采用的是自研框架还是市场上的其中一个框架？

薛端阳：携程有自己一套自研的小程序框架，内部代号叫 Cwx（意为 Ctrip Weixin）。

因为历史原因，我们是第一批接入微信小程序的团队，那个时候还没有这些框架。

并且携程对于框架功能的需求，更多会倾向于如何方便的解决跨部门协同的合作问题，降低冲突（版本代码冲突、区分内外网），优化资源整合（三大基础业务登录、业绩统计、支付），质量问题跟踪（行为流水、代码级错误回溯）等。

从需求来看，我们偏向于内部的技术需求比较重，从组织架构体系来看，携程没有独立组织意义上的小程序独立团队，我们需要整合公司各个业务 BU 之间的技术资源，一起合作开发一个大的技术产品。

我们有一个内部用于技术产品沟通交流的微信群，群内人员是流动的，最大的技术产品携程微信小程序的群内关联的技术人员已经高达 500+了。

由此可见的是，携程区别不同于其他几家公司的小程序开发流程，面对第一个难题是协同问题。

因为参与的人多，我们需要合理有效的解决开发隔离，但是又要高效利用公共资源，Cwx 框架诞生初期就是为了实现这个目标而产生的。

幸运的是经过了 2 年的沉淀，也感受到了多人协作的好处，让我们能有市面上最丰富的的小程序代码样本数据，在以微信小程序为基础 DSL，我们很好地解决了微信转其他小程序的各种兼容和边界问题。

在这点上，已知市面上其他家已开源产品大多以封闭规则的方式来实现跨多端，这一理念在携程小程序上行不通，因为我们携程做的比较早，本身又秉承一个内部开放多元的体系，我们对于技术并无限制，只要在微信容器能玩得起来的，我们都会支持，并给予提供多端转换的持续支持。

所以我们以点为目标，线为工具，针对我们内部业务 BU 的各种需求，我们开发了一套整体的小程序解决方案，涵盖目前小程序开发中遇到的各种技术问题。

当然我们也包容和支持市面上已有的第三方小程序框架，虽然在代码冗余度上，我们的解决方案包含了他们支持的绝大部分功能，我们提倡的是一个多元化的技术理念，你中有我 ，我中有你。

我们追求的目标是整体的通用解决方案，一个稳定、高效能的开发+调试+业务运维监控体系。

开发难点：平台限制的接口不全

CSDN：目前携程网已对接各平台的小程序，那么后端服务是如何实现的呢？是一后端对应多前端，还是一后端对应一前端的方式呢？

薛端阳：在设计之初，我们在请求封装层面针对平台特征有封装很多标记，后端服务拥有足够的指纹特征去做灵活判断，至于是否分平台分发，由具体的业务产品决定。同时，我们代码分层层面上，有独立的业务 DAO 层指导，BU 可以自行选择参数配置。

CSDN：相比 App，对比这几种小程序生态，您觉得开发难点各是什么？

薛端阳：对比 App 来说，小程序最大的问题是因为平台限制的接口不全/权限不够大，App+Hybrid 理论上来说仅次于 root 权限，很多产品设计上的功能都能实现，小程序因为安全原因以及平台限制，并不能提供很多 App 上已有的功能。

以分享举例，很多小程序不能主动分享，但是 App 就可以，就导致了代码逻辑的分离，不能一套代码 App+小程序通用，当然在携程的 Cwx 解决方案内，我们通过 postCompiler 预编译的方式来掩盖了这一问题。但是在实际的产品业务逻辑设计上，这些都绕不开的。

第二个比较严重的问题是平台兼容性问题，在市面上数以万计的终端用户面前，一个真实用户假如 Crash 是极其难以定位和调试的。

目前市面已开源的框架产品都没有重视这个问题，我们 Cwx 是提供了 crash 面包屑收集、堆栈 SourceMap、用户行为流水、错误回溯等等，帮助开发人员快速准确定位，1小时修复发布。

这里面包含了很多细节的核心技术难点，包括 crash dump 文件的本地压缩传输、断点续传、断网重试、SourceMap 加解密、用户画像、前后端单一用户日志打通等等。

我们提供的是一套整体的解决方案，而不只是一个框架，当然在解决这些细节技术问题的过程中，我们必须和小程序容器厂商，微信、快应用等紧密合作，我们一直都有内部沟通渠道，可以无缝对接，我们会提出第三方定制要求，共同讨论必要性和实施细节，这些为了让小程序这个大平台能更易用，更活血地良性发展，我们和容器厂商一直是互相依存的状态。

虚拟开发团队，多级分层容灾

CSDN：对比了携程在微信小程序、支付宝小程序、百度智能小程序，携程网在各生态的提供的功能服务有很大差异，例如在微信端提供的服务和 App 的差不多，而在支付宝、百度仅提供基础服务，这样部署是基于什么标准衡量呢？

薛端阳：这个是由业务部门自身业务发展决定的，我们由于一段时间一直同步微信的版本到其他家小程序平台的，但是因为每个小程序平台都有自己的审核标准和业务限制，并不是微信的功能都直接搬过去用，所以业务出于自身发展的考虑，会做一些区别。

CSDN：携程网有很多个部门，在小程序开发上是单独由一支团队负责，还是各业务部门有专门的人来开发协同呢？

薛端阳：我们是虚拟团队，每个业务线有相对固定的开发人员。

CSDN：小程序和 App 目前的开发资源投入分配大致是怎样的？

薛端阳：目前 App 的资源优先级高于小程序。

CSDN：在小程序的发布上，目前各部门的协同工作是如何进行的呢？

薛端阳：小程序虚拟团队的沟通主要基于内网 IM 以及外网微信，自动化程度较高，很多发布协同指令都开发了对应的机器人去完成自动化无人值守操作，我们是实际意义上的 24 小时 Hold on。

CSDN：是否有容灾性？如某个部门的入口有问题，是否能迅速下掉呢？

薛端阳：多级分层容灾，很多入口都是基于配置系统下发的，所以可以不用发布，实时生效。

未来：打通小程序和 Hybrid

CSDN：您对这几种生态有什么看法和展望呢？

薛端阳：可以预计的是，在相当长的一段时间内，几种生态都是各自独立良性发展的，这是必然性和必要性，不会产生冲突。

因为从用户画像上来说，长期使用单一平台的用户是不存在使用其他平台的必要性的，所以小程序有自己独立一部分长期用户群，满足他们的需要和提升满意度，是当下我们需要重点考量的目标。

在短期性来看，存在给 App 导流的业务逻辑也是各个公司内部指标之一，拉活、导流、短期活动的用户群体也有它自身独立存在的必要性和必然性，因为爆款产品可以短期在口碑上，和品牌认知度上大幅提升公司形象。

CSDN：未来携程在小程序上的技术研究方向是什么呢？

薛端阳：

1、继续深入完善现有体系，因为小程序是从刀耕火种走过来的，文档化完成度确实不高，我们正在不断努力完善，目前已经内部有一套基于相关代码的自动化文档体系。

2、打通小程序和 Hybrid，未来我们期望小程序可以直接接替现有的 Hybrid，这两个技术栈是非常相似和同构的。

【END】