背景

飞猪对于小程序业务的尝试比较早。 随着支付宝小程序的出现，飞猪各业务线都在不断尝试利用小程序更好地获客、触达和留存支付宝客户。 但由于众所周知的原因，飞猪从未尝试过微信小程序。 随着2021年的反垄断风愈演愈烈，阿里巴巴的部分业务开始将触角伸向微信领域，飞猪也顺势而为，尝试开辟“微信小程序”，这是对我们来说是“处女地”。 地方。

从获客角度来看，微信小程序是一块非常适合旅游业务的土地。 2019年全国门票网上购买率仅为20%。 绝大多数游客到达景区后仍然购买门票。 基于这一实际场景，各厂门票业务推出了“码上游”业务——通过购买在景区部署门票二维码来获取线下用户。 与车票类似，公交车票也有线下自助机和车上扫码购票的场景。 微信在“扫码”场景下的打开率是其他App无法比拟的。 在这种线下场景下，我们只需要保持微信小程序的存在，就能获得立竿见影的巨大商业利益。 此外，基于微信庞大的用户、活跃的社交场景、优秀的触达能力，还有广阔的线上运营空间和丰富的工具。

2021年，我们推出第一版只包含票务服务的微信小程序抢占5.1窗口后，其他业务如度假、汽车票、酒店、火车票也在不断进入。 随着项目的不断迭代和业务的快速发展，前端也面临着从开发模式选择、集成管理到技术生态建设、性能优化、体量优化等各方面的挑战。

技术建设

开发模式选择

技术栈

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

快速实施：项目时间紧张，必须在2-3周内完成开发。

一份代码，多终端：需要将小程序页面降级为H5

快速实施要求我们选择的技术栈要么能够快速上手，要么最好是大家都有一定的熟练程度，并且必须对这个技术栈的稳定性或者出现问题能够及时解决有信心; 一个代码，多个终端，既有历史原因（我们有现有的H5页面需要进入小程序），也有未来的考虑。 未来飞猪的前端需要面对H5、微信小程序、支付宝小程序等多种容器类型，所以选择的技术栈必须是多端的。 适应能力强，节省开发人力。 因此，我们毫无疑问地选择了Rax1.0。 首先，我们已经拥有基于Rax的基础组件库和大量的开发经验。 其次，由于 Rax 是集团内部的产品，我们相信它对我们项目的支持。 这里有一个伏笔。 Rax的主要技术方案是“运行时模式”（类似于taro@3.0，采用递归渲染+模拟DOM BOM实现）。 另外，我们依赖的一些二方页面也是运行时的解决方案。 由于详细页面动态方案不适应编译时方案等原因，我们第一阶段采用了完整的运行时方案进行开发。 这就是后来混合编译的背景。

合作方式

由于需要多个业务线的前端团队成员共同开发，因此需要采取业务线独立开发+小程序主体集成的合作方式。 实现这种模式有两种选择： 1. 页面插件； 2.页面组件化。 就小程序而言，插件化是最彻底隔离各个业务团队的方式，而且插件的发布更加自由，不受集成节奏的限制。 业务线的同学更倾向于这种控制业务迭代节奏的方式。 。 但对于我们需要整合的平台同学来说，似乎这种过于自由的做法存在着较大的稳定性风险，因为如果过于自由的话，信息交流的必要性就会降低。 如果一些插件的改动没有同步到平台同学或者平台同学，如果框架的改动没有同步到业务线的同学，很容易造成线上问题。 做整合的学生自然会反感这种失控感。 最终我们还是选择了比较保守的页面组件化方案，但主要原因并不是稳定性，而是微信小程序本身的局限性：

插件数量不能超过10个

仅静态插件：插件卷会包含在包卷中，因为插件自然无法共享主包中的公共模块，需要特殊处理

使用插件时，需要声明具体版本：插件版本更新后，主小程序需要修改依赖的插件版本号声明并重新发布。 业务线的迭代节奏还是需要依靠整合。

研发平台

核心迭代集成能力

项目初期，我们使用人肉进行迭代控制（红色为人肉通信）：

整个过程充满了程序员深恶痛绝的“人为操纵”，尤其对于做集成的学生来说，更是一场灾难。 为此，我们动员业务线开发、测试同学制定了《小程序集成规范》，明确了每周的集成节奏，明确了各业务的测试边界，约定了集成、灰度、回滚、应急等。版本机制标准化了流程。 然后，借助集团的“王守义”钉钉机器人，实现了通过钉钉消息（开发分支号）打印微信小程序预览代码的能力。 开发同学只需要把分支号给测试同学，测试同学就可以自己通过钉钉打印预览代码，减少了开发和测试同学的沟通成本。

但仅此还不够。 我们希望有一种更自动化的方式，将沟通成本和重复劳动降低到0。我们希望有一种基于工具的方法来自动运行规范，而不是简单地记录它们。 于是我们萌生了打造“研发平台”的想法，不仅要标准化、自动化集成，还要将其打造成“小程序开发者的日常工作平台”。

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

界面显示

迭代日历

迭代集成

迭代完成

其他辅助工具

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

扫描二维码在线抓包

扫码在线验证

微信域名短链接生成服务

小程序源码包依赖变化分析

小程序包结构信息图：分包数量、页数、分包技术栈、分包业务信息

集成版自动化测试报告

小程序二维码生成工具

技术生态

套管

这里我们把采用web-view组件方式引入H5页面的小程序页面称为页面，以区别于小程序页面和H5页面。 众所周知，域名无法在微信系统中开放，所以我们只能通过代理来绕过这个限制。 代理本身没什么可说的。 这里主要讲一下如何处理页面的登录状态。如果用户被允许

当进入需要登录的 H5页面时，跳转到H5登录：方法很简单； 但这种方法会导致用户两次登录，并且无法保证两次登录的用户账号一致，严重影响用户体验，是完全不可取的。

将小程序的登录状态同步到 H5页面：这是保证业务正常流通的最直观的做法。 然而，由于小程序容器中没有概念，并且小程序的容器之间不具有互操作性，因此需要一个“小程序”。 => H5”登录状态交付解决方案。

“小程序=>H5”转移登录状态比较常见的方式是在用户登录小程序后打开一个空白的H5链接，专门同步登录状态（植入）。 但这种做法一来影响用户体验，二来无法保证小程序内的登录状态时效性与小程序内一致。 如果为了时效性，要求用户每次进入小程序时都同步登录状态，用户体验会更差。 因此，我们最终使用了一种更迂回的方法：

域名拦截预防

与传统的页面域名防封不同，去年国庆期间我们遇到了甘肃地区界面域名被举报涉嫌诈骗后被运营商封的问题（后向公安部门申诉）并且被解封），导致本地微信小程序无法使用。 虽然只是甘肃的一个景点，人流量很少，但也给我们敲响了警钟。 我们必须启动一个域名池。 飞猪微信小程序面临的域名屏蔽与一般的微信域名屏蔽有很大不同。 我总结其特点如下：

运营商层面的封禁是对主域名的DNS劫持。 并不是说微信小程序无法打开，而是会导致接口请求失败。

封锁点爆发具有地域特色，封锁可以通过申诉解封，但并不是永久封禁。

我们线下比赛很多，防堵策略一定要稳定，保证所有用户可用，避免用户流失。

基于以上特点，我们设计了纯客户端版本的域名池解决方案：

接口和登录域名池是预先匹配好的，并在静态代码中配置。

当用户的域名被屏蔽时，他立即切换客户端的全局域名配置，更新界面和登录请求域名，并为该用户重新发送请求。

建立报警机制，点位爆发后立即办理申请解封流程

这种机制保证了用户可用性，并且对用户基本不敏感。 它的成本也相对较低且坚固耐用。

网址统一

在微信小程序的第一阶段，我们经历了分包策略变化带来的痛苦的页面路由变化。 虽然更新路线并不困难，但既耗时又容易错过。 在经历了以后的多次分包/页面变更之后，我们决定开始URL统一的建设。 统一URL后，小程序中可以直接使用H5链接打开对应的小程序页面。 业务不再需要判断终端打开不同的页面地址，也不用担心小程序页面路径变化带来的大规模修改问题。

统一URL有两种方式，一种是纯客户端配置，另一种是服务器下发配置。 微信小程序考虑到如果使用服务器下发，会出现数据缓存与小程序版本不一致的情况，可能会因为H5对应的小程序路由配置而导致被意外打开找不到链接，且微信小程序的限制比较大，无法保证正常浏览，所以采用本地配置。

技术方案比较简单。 我们在统一页面打开方式中介绍了这个H5链接和小程序页面的一一配置。 判断当前需要打开的H5链接如果是++（如果配置中出现），则可以与某个配置匹配，如果两个配置匹配，则打开对应的小程序页面并透传。

性能优化

混合和独立分包

由于框架的限制，我们无法在一个项目中同时拥有运行时方案页面和编译时方案页面。 框架提供的运行时页面使用不支持分包处理的编译时组件方案。 该方案将删除所有编译时方案页面。 组件统一放在主包中，而我们的开发模式是页面既是组件，这种方案不能满足我们。 因此，我们最终利用框架提供的工程钩子“插件”了一套工程方案。 这套“插件”项目还解决了框架不支持独立分包的问题。 具体做法和强框架绑定就不详细介绍了。 下面仅列出大量 DOM 场景下的运行时和编译时性能对比。

编译时间

运行

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

PS：下图中，rxpi是我们的一码多端组件库，rxpi-mtop是我们的统一接口请求组件，配置平台是研发平台的配置中心。

冷启动

主动触发

页面跳转时被动触发

音量优化

随着越来越多的业务线相连、业务页面越来越丰富，飞猪微信小程序的规模不可避免地迅速扩大。 到了10月份，规模已经扩大到18M+，已经无力承担火车票的费用了。 要求，因此我们需要有有效的手段来优化包裹体积，遏制包裹体积的过度膨胀。

在此背景下，我们推出了微信小程序“业务及分包量分析及规范”，对各业务当前的包量进行分析，并提出各业务的包量要求。 如果该业务超出了分配的包裹量，则需要想办法优化或用其他业务替换空间。 然后我们立即开始从平台的角度思考如何从工程和业务层面删除实体：

上述方法与框架和业务相关性较高，不再详细阐述。 仅编译时和运行时公共模块的主包就让我们成功地将大小从18M+缩小到了13M，其意义不仅仅限于这一一次性效果。 随后添加的页面将从中受益。 用小程序当前的总体积除以页面数量，我们每个小程序页面目前大约占据了100%的体积。 这个值不太令人满意。 体积优化还有很长的路要走~

未来

优化是前端一个长期的话题。 只要微信小程序项目存在，就不可能停止探索优化，无论是工具、技术还是业务。 就我个人的经验来看，至少这几个方面还需要进一步优化：

关注“F2E”微信公众号，掌握阿里巴巴前端新动态