背景

飞猪对小程序业务的尝试是比较早的，随着支付宝小程序的出现飞猪的各条业务线都在不断尝试小程序化以更好的在支付宝端获客、触达、留存，但是因为众所周知的原因飞猪一直没有尝试过微信小程序。随着21年反垄断的风越吹越盛，阿里的一些业务开始在微信领域伸出了触角，飞猪也随势而动尝试开垦“微信小程序”这块对我们来说是“处女地”的地方。

从获客角度来看，微信小程序是一块十分适合旅行类业务的土地。19年全国门票的线上购买率仅有20%，绝大部分的游客仍然是到景区后再购票，基于这个实际场景各厂的门票业务均推出了“码上游”业务——通过将购票二维码部署在景区的方式获取线下用户。与门票类似，汽车票也有线下自助机、上车扫码购票的场景。而微信在“扫码”场景的打开率是其他app都难以望其项背的，这种线下的场景只需要我们能在微信小程序上保持存在就可以获得立竿见影的巨大业务收益。另外，基于微信巨大的用户、活跃的社交场景、优秀的触达能力，线上运营也有广阔的空间和丰富的工具。

在21年我们上线了第一版抢占5.1窗口的仅含门票业务的微信小程序后，其他像度假、汽车票、酒店、火车票等业务也在源源不断进入。随着项目的不断迭代、业务的快速发展，前端也面对着从开发模式选型、集成管理，到技术生态建设、性能优化、体积优化等各个方面的挑战。

技术建设

开发模式选型

技术栈

每个项目启动之初技术都会面临这个问题——如何选择适合的技术栈，飞猪微信小程序也不例外。一般选择技术栈要看具体业务场景和项目核心诉求，就前端来说业务场景一般不会影响技术栈选型，那么飞猪微信小程序项目启动时的核心诉求是什么呢：

1. 快速实现：项目时间紧迫，2-3周内要完成开发
2. 一码多端：小程序页面有降级投放H5的需求

快速实现就要求我们选择的技术栈要么能快速上手最好是大家已经有一定的熟练度，并且需要对这个技术栈的稳定性有信心或者出了问题能得到及时的解决；一码多端既有历史原因（我们有现存的H5页面需要进入小程序）也有面向未来的考虑，未来飞猪前端需要面对H5、微信小程序、支付宝小程序多种容器类型，因此选择的技术栈必须要有多端适配的能力以节省开发人力。因此我们毫无疑问的选择了Rax1.0，一者我们已经存在基于Rax的基础组件库以及大量的开发经验，二者Rax作为集团内的产品我们比较相信其对我们项目的支持度。这里有个伏笔，Rax的主推技术方案是“运行时模式”（和taro@3.0、kbone类似都是利用template的递归渲染 + 模拟DOM BOM实现），加上我们依赖的部分二方页面也是运行时方案、商详页面动态化方案不适应编译时方案等原因，我们一期是采用了全运行时方案开发，这个是后期做混编的背景。

合作模式

由于需要多条业务线的前端团队同学共荣开发，势必需要采用业务线独立开发 + 小程序主体集成的合作方式。要实现这种模式有两种选择：1. 页面插件化；2. 页面组件化。就小程序来说插件化是将各个业务团队隔离最彻底的方式，并且插件的发布也更自由不受集成节奏的限制，业务线的同学是比较倾向于这种自己掌握业务迭代节奏的方式的。但是对于我们需要做集成的平台同学看来这种太自由的方式存在较大的稳定性风险，因为太过自由信息互通的必要性就会降低，如果一些插件变更没有同步到平台同学或者平台同学对框架的改动没同步到业务线同学就容易引发线上问题，做集成的同学天然反感这种失控感。最终我们选择的依然是比较保守的页面组件化方案，但主要原因却并不是稳定性，反而是微信小程序自身的限制：

1. 插件个数不能超出10个
2. 只有静态插件：插件体积会计入包体积，因为插件无法天然共享主包内公共模块需要特殊处理
3. 使用插件需要声明具体版本：插件版本更新后主体小程序需要修改依赖的插件版本号声明并重新发版，业务线的迭代节奏依然需要依赖集成

研发平台

核心迭代集成功能

在项目早期我们是通过人肉的方式来进行迭代管控（红色是人肉沟通）：

整个过程充满了让程序员深恶痛绝的“人肉操作”，尤其是对做集成的同学来说简直是个灾难。为此我们拉动业务线开发&测试同学一起制定了《小程序集成规范》，清晰了每周一次的集成节奏，明确了各业务的测试边界，约定了小程序的集成、灰度、回滚、紧急版本的机制，让流程规范化起来。然后借力集团的“王守义”钉钉机器人实现了通过钉钉消息（开发分支号）打微信小程序预览码的能力，开发同学只需要将分支号给到测试同学，测试同学可以自行通过钉钉打预览码，降低了开发&测试同学的沟通成本。

但仅是这样还不够，我们希望能有更自动化的方式将沟通成本和重复人工尽量降低到0，希望能有工具化的方法让规范自动run起来而不是简单的文档化。于是我们诞生了做一个“研发平台”的想法，不仅要将集成规范化、自动化起来，还希望将其打造为“小程序开发者的日常工作平台”。

目前“研发平台”已经包含迭代集成管理、包信息展示、包依赖分析、在线抓包、自动化测试、性能&稳定性数据大盘等功能。基本涵盖了一个小程序的业务需求从开发=> 测试 => 集成 => 数据的全生命周期。其核心的迭代管理功能流程已基本实现自动化，人肉沟通不再是必要手段，各职责同学按照节奏&通知进行在研发平台进行相应操作即可：

界面展示

迭代日历

迭代集成

迭代完成

其他辅助工具

除了迭代集成外，我们在研发平台还为开发者提供了一系列的小程序开发工具，希望一个平台能满足日常开发所需：

1. 扫码在线抓包
2. 扫码在线验证埋点
3. 微信域短链生成服务
4. 小程序源代码包依赖变更分析
5. 小程序包结构信息图表：分包数、页面数、分包技术栈、分包业务信息
6. 集成版本自动化测试报告
7. 小程序二维码生成工具

技术生态

套壳

我们这边把使用web-view组件方式引入H5页面的小程序页称之为套壳页以和小程序页面、H5页面区分。众所周知，taobao.com的域名是无法在微信体系内打开的，因此我们只能通过代理的方式绕过这层限制，代理本身没什么好说的，这里主要讲下套壳页面的登录态怎么处理。如果让用户

1. 进入需要登录的套壳H5页面时，跳转H5的登录：做法简单；但这种做法会造成用户需要二次登录并且无法保障用户两次登录的账号一致，严重影响用户体验，完全不可取。
2. 将小程序的登录态同步到套壳H5页面：最符合用户直觉保障业务正常流转的做法，但由于小程序容器内没有cookie的概念，并且小程序的容器和webview容器也不互通，需要有“小程序 => H5”登录态传递的方案。

“小程序 => H5”登录态传递比较常规的做法是：在用户登录小程序后打开一个空白的H5链接专门同步登录态（将cookie种在webview中）。但是这种做法，一来影响用户体验二来也无法保障webview中的登录态时效和小程序一致，如果为了webview的登录态时效让用户每次进入小程序都同步一次登录态则用户体验更差，因此我们最终使用了比较曲折的方式：

域名防封杀

和传统意义上的页面域名防封杀不同，我们在去年的国庆遇到了甘肃地区因接口域名被举报涉嫌诈骗被运营商封杀的问题（后向公安部门申诉解封了），导致当地微信小程序无法使用。虽然只是甘肃某个流量不大的景区但也是给我们敲响了警钟，域名池必须要做起来。飞猪微信小程序面对的域名封杀和一般意义上的微信域名封杀有较大的区别，其特点我归纳如下：

1. 运营商层面的封杀是对主域名做了DNS劫持，不是微信小程序无法打开，但是会导致接口请求失败
2. 封杀有地域性特点的点状爆发，并且可以申诉可以解封，不是永久封禁
3. 我们线下的竞对较多，防封杀策略必须稳定保证所有用户可用，避免用户流失

根据上面的特点，我们设计了一个纯端侧版本的域名池方案：

1. 接口和登录的域名池事先配套，并配置在静态代码中
2. 用户出现域名被封杀的特征后立即切换端侧全局域名配置，更新接口和登录的请求域名，并为用户重新发送请求
3. 建立报警机制，出现点状爆发后立即走申请解封流程

这套机制保障了用户的可用性并且基本用户无感，并且成本较低也比较健壮。

url统一化

在微信小程序一期时我们就经历过痛苦的分包策略变更导致的页面路由变化，更新路由虽然不难但是很耗时间也很容易遗漏，在后续在多次经历了分包/页面变动后，我们决定启动URL统一化的建设。url统一化后小程序内可以直接使用H5的链接打开对应的小程序页面，业务不再需要判断端来打开不同的页面地址，也无需担心小程序页面路径变化引起大范围修改问题。

url统一化有两种做法，一是纯端侧配置二是服务端下发配置。微信小程序考虑到如果使用服务端下发会出现数据缓存和小程序版本不一致问题，导致可能会因为没找到H5链接对应的小程序路由配置而误打开套壳，而微信小程序的套壳限制比较大无法保证正常浏览，因此采用了本地配置的做法。

技术方案比较简单，我们在统一的页面open方法中引入了这段H5链接和小程序页面的一一对应的配置，判断当前需要open的H5链接如果hostname + pathname + query（如果配置中出现query）均能和某个配置匹配的话则打开对应的小程序页面并透传query。

性能优化

混编&独立分包

由于框架的限制，我们无法在一个项目中同时存在运行时方案页面和编译时方案的页面，框架提供的运行时页面使用编译时组件的方案不支持分包处理，该方案会将所有的编译时组件统一放在主包内，而我们的开发模式是页面既组件，所以这个方案也无法满足我们，因此我们最终利用框架提供的工程hook自己“外挂”了一套工程解决，这套“外挂”的工程同时解决了框架不支持独立分包的问题，具体实践和框架绑定较强就不再赘述，以下仅贴出在DOM较多的场景下运行时&编译时的性能对比。

编译时

运行时

prefetch

值得一提的是我们统一各厂家小程序实现的接口预加载（prefetch）方案，通过配合微信小程序提供的“冷启动数据预拉取”功能，我们在微信小程序完成了从启动到页面浏览过程中的全生命周期预加载能力。

PS: 以下图片中，rxpi为我们的一码多端组件库，rxpi-mtop为我们的统一接口请求组件，配置平台即研发平台的prefetch配置中心

冷启动

主动触发prefetch

页面跳转时被动触发prefetch

体积优化

随着接入的业务线越来越多，业务页面越来越丰富，飞猪微信小程序的体积不可避免的迅速膨胀起来，至10月份时体积已经膨胀到了18M+，已经无法承担火车票入微的要求，因此我们需要有有效的手段优化包体积、遏制包体积的过分扩张。

在此背景下，我们出台了一份微信小程序《业务&分包体积分析和规范》，分析了各个业务的包体积现状并对各业务提出了包体积要求，业务超出分配的包体积则需要想办法优化或者和其他业务做空间置换。然后我们从平台角度立刻着手从工程、业务两个层面想办法删减体：

• 编译时分包公共模块主包化
• 运行时分包公共模块主包化
• 功能重复页面删减
• 部分非核心页面套壳处理

以上手段和框架、业务相关性较大所以不做具体阐述，仅编译时&运行时公共模块主包化就让我们成功将体积从18M+缩减到了13M，而且其意义不仅限于这个一次性的效果，后续新增的页面都会从中受益。以目前小程序的总体积和页面数相除，目前我们每个小程序页面约占体积172KB的体积，这个数值并不太令人满意，体积优化的路还是任重道远呀~

未来

优化是前端的一个长期的课题，只要微信小程序项目存在一天都不可能停止对优化的探索，无论是工具、技术、业务。从我个人的体感出发，起码这些方面还需要继续优化下去：

• 开发&集成方式仍然不够自动化：文档说明和人肉操作还存在，如何开始开发以及如何集成如果是一个需要经验的事情，那就仍有优化的空间。
• 测试工具依然不够完善：全链路信息不够，端上调试功能弱，无事故现场还原能力。
• 运营工具缺失：这点有项目草创的原因，但是客观上也导致了我们从业务视角看待生态的动作缺失，有哪些技术可以带来新的业务视角，怎么用技术的手段帮助业务在全微信域运营起来是必须要研究的课题。
• 性能提升还有未尽手段：在混编、独立分包、体积优化、prefetch之后，我们还需要针对不同的业务场景做针对性的优化，为业务提供指导意见，例如微信官方的分包异步化的能力、定时更新离线数据、代码的按需注入的能力，这些应该都有比较适合的业务土壤。