本文首先会带大家简单回顾一下跨端技术的背景和演进，以及饿了么在这一波跨端浪潮中的现状。在这样的背景下，相较于业界基于 Vue 开发习惯的各类跨端方案，饿了么为何选择了一条不一样的路？在这个过程中，我们会回顾一下我们的一些思考，遇到和解决的问题，以及取得的一些成果。希望这能给大家在跨端方面带来一些新的思路。

跨越终点，我们跨越的是哪些终点？

从1990年万维网出现以来，在随后的三十多年里，我们相继经历了PC时代、移动时代，以及现在的万物互联时代，繁荣的背后是越来越多的设备、越来越多的系统、以及各种各样的解决方案。

总体来说，按照跨终端的场景主要包括以下四类：

目前来看，移动领域依然是绝对的主角，我们来盘点一下移动端跨终端技术经历了哪些阶段。

移动跨终端技术演进

随着移动互联网的蓬勃发展，终端形态变得多样化，除了传统、H5之外，以动图、小程序为代表的新兴模式蓬勃发展，框架/容器/工具层出不穷，整个行业朝着碎片化的方向发展。

对于开发者来说，碎片化的直接影响就是带来各种不确定性，包括但不限于前文提到的设备平台、操作系统、渲染容器、语法标准等等，增加不少学习、开发和维护的成本。

因此，陆续出现的各种跨端技术，核心就是从不确定性中寻找确定性，保证研发经验和产品的一致性，适配各个端的最优方案，用最小的成本达到最好的效果，真正实现“一次编写，到处运行”。

移动跨终端大致经历了以下几个阶段：

回顾了跨端技术的背景和演进，那么在这波跨端分发浪潮中，饿了么的跨端分发情况如何？分发到了哪些端？遇到了哪些问题？又是如何解决的？

众所周知，饿了么是一家围绕O2O为用户提供线上到线下服务的公司，通过时间、空间、人、货的有机结合，连接商家和消费者。相比传统电商，时间、空间、人、货都有地域属性。这意味着我们做的不是大超市的生意，我们需要围绕区域特色，提供更加精细化的服务。这里面有一系列时间、空间、体验、规模、成本等约束需要考虑和处理。

在这一系列约束的背后，其实是各方共同的业务诉求：

这一切都是为了一个目标：我们需要在流量较大的地方为消费者提供连接。

那么问题来了，流量在哪？今天的互联网更多的是在用用户的时间和精力做生意。分解下来，其实可以衡量的关键因素有以下几个：用户密度、用户活跃度、市场份额、用户时间分配。具体来说，这其中任何一个条件，都可以作为我们流量定位的候选集。

经过多年的耕耘，饿了么在外部重点渠道布局颇多，拥有多个业务阵地。从业绩来看，渠道业务无论在用户流量规模还是订单规模上，都对整体市场贡献较高。随着业务的不断完善和外部合作环境的不断改善，增量渠道也在不断涌现。

在这么多的业务领域中，应用在各个终端上的部署形态都是基于：

由于存在差异和限制，目前承接的模式以小程序为主，H5为辅，这些差异带来了很大的不确定性，主要体现在：

我们要做的就是在这两种不确定性中寻找技术能够带来的确定性，如何系统性地解决这些问题，成为在保证渠道业务灵活性的同时，持续提升研发效率和体验的关键。

在差异化处理上，业务发展最理想的方式是对底层的变化和不一致不敏感，安心响应业务诉求。基于这一点，我们的主要策略是围绕“提升研发体验一致性、完善复杂应用协同机制”来保证业务高效迭代。这需要一套符合业务特点的强大基础设施来支撑。首先想到的是如何通过“推进框架统一”、“实现多端一份代码”来为业务发展降本增效。然而理想很丰满，现实却很骨感：

一般而言，框架升级极有可能导致业务重构。综合评估后，占据外部渠道流量绝大部分的小程序业务成为我们的重点业务。基于此，为了最大程度降低对业务的影响和接入成本，我们明确将小程序作为实现多端落地的第一视角。

基于跨终端小程序的行业现状与思考

明确了方向之后，接下来的问题是：业界有没有适合我们的开源框架或者解决方案？

市面上，从小程序角度来看，有不少具备类似能力的优秀多端框架，比如Taro、uni-app、Rax等，大多采用Vue作为DSL

那么这些框架能解决我们面临的问题吗？答案是：不能。

饿了么为什么选择用小程序DSL作为跨终端实现的基础？

结合饿了么的渠道业务背景，需要考虑以下几点：

在做了大量横向比较和权衡之后，上述框架的采用成本对于我们来说太高了，所以我们选择了另一条相对困难但更符合饿了么多端演进方向的道路：基于小程序原生 DSL 构建跨终端解决方案，最大化保证各个端的产品代码与小程序原生语法一致，从而最大程度降低同构带来的体验损失和多端访问业务的成本。

基于小程序DSL的跨端解决方案

在确定以小程序 DSL 为方向构建跨端解决方案之后，首先要解决的就是如何将现有的小程序快速适配到多端，这需要详细分析各个端与解决方案之间的差异。

如何解决小程序多端编译的问题？

为了平衡性能和开发体验，我们选择了编译时（重度）+运行时（轻度）的方案。

静态编译解决了什么问题？

静态编译转换主要用于处理JS、WXS/SJS、WXML/AXML、WXSS/ACSS、JSON等源代码中约束较强、无法动态修改的部分，比如：

其原理是将源代码文件转化为AST（抽象语法树），通过操作AST将源代码转化为目标平台的代码。

但是静态编译只能解决部分差异，有些差异需要在运行时才能消除。

运行时补偿解决了哪些问题？

运行时补偿主要用来处理一些静态编译无法处理或者处理成本较高的运行时动态内容，比如：

诸如此类，类似的场景还有很多，这里就不一一列举了。

通过静态编译+运行时补偿的方式，我们可以快速将现有的微信或者支付宝小程序迁移到其他小程序平台。

小程序转Web的问题该如何解决？

外卖APP上线多年后，各大渠道（支付宝、手机淘宝、微信等）纷纷切换到小程序，但还是有很多小众渠道或者非小程序环境的渠道，比如各类银行金融渠道、客户端极小包等，依然需要依赖H5实现快速投放。而饿了么业务越来越复杂，相关渠道投入资源有限、历史包袱重、迭代成本高等原因，产品功能和服务能力远远落后于小程序和饿了么APP。业务迫切需要一个能够将小程序的功能快速复制到H5端，研发和维护成本更低的技术方案，满足业务多渠道的能力和上线要求。

基于这样的背景，我们很自然的想到，既然小程序可以转换成其他小程序，那么是否也能直接将小程序转换成Web端，从而最大程度的提高人工效率和功能对齐。

具体是如何实现的呢？主要方法是通过编译时+运行时的有机结合：

Web到终端编译原理

编译部分和小程序到小程序转换的主要区别和难点为：需要统一将JS、WXS/SJS、WXML/AXML等文件转换合并为JS文件、将WXML/AXML文件统一转换为JSX语法、将样式文件统一转换为CSS文件、将小程序的页面、组件统一转换为组件。

运行时原理

转换为 Web 运行时比转换为其他小程序要复杂得多。为了兼顾性能和体验，运行时的核心是提供与小程序相当的高效运行环境。它主要包括四个模块：

基于这四个模块，结合编译时的自动注入和代码转换，以及路由映射，我们可以将小程序转化为Web SPA（单页）或者MPA（多页）应用，成功解决了业务研发效率的问题。目前饿了么新M站就是基于这个方案运行的。

解决了各端的编译转换问题是不是就万事大吉了呢？业务接下来要做的就是基于这套能力，实现多端一份代码吧？

但事实并非如此，随着饿了么业务场景和范围的快速拓展，也出现了一些新的需求，比如：

等等，如果你仔细观察这些诉求，就会发现一个共同点：小程序的表现形式各有不同。

虽然我们已经具备了多端能力，但是形态的差异性问题一直没有解决。之前相关业务的做法是将通用功能尽可能沉淀到组件库中，以多端的方式输出产品。但由于同一业务在不同小程序端的形态差异，业务很难自行规避，重构成本也比较高。因此部分业务选择直接根据不同端（如微信、支付宝、淘宝、抖音）的不同形态维护一套代码。但这样做不仅延长了功能同步迭代周期，而且 Bug 较多，维护难度大，研发过程也极其痛苦。

小程序形态有哪些区别？

形态差异是指小程序、小程序子包、小程序插件三种不同形态运行方式的差异，以及转换成其他形态后的差异，具体如下：

1.小程序：可以通过()获取全局App实例以及实例上挂载的属性或方法

2. 小程序插件：无法调用（）

3.小程序分包：可以通过()获取全局App实例以及挂载在实例上的属性或方法；但当小程序转为分包后，原有的分包本身的调用会失效，被宿主小程序替代

1. 小程序：应用会执行、、、等生命周期

2. 小程序插件：无应用生命周期

3. 小程序分包：无应用生命周期

1.小程序：可以通过全局样式声明全局样式

2. 小程序插件：无全局样式

3. 小程序分包：无全局样式

1. 小程序：不同平台的支持和限制各有不同

2. 小程序插件：每个小程序平台的支持和限制都不同

3. 小程序分包：每个小程序平台的支持和限制都不同

1. 小程序：无限制

2.小​​程序插件：接口调用限制较多，比如开发支付宝小程序插件，或者开发微信小程序插件

3.小程序分包：无限制

1. 小程序：切换到其他形式后，路由会发生变化

2、小程序插件：切换到其他形式后，路由会发生变化，跳转插件页面需要包含://或者-://等前缀，小程序或者子包则不需要。

3.小程序分包：转换成其他形式后路由会发生变化

1. 小程序：无限制

2.小​​程序插件：无法获取小程序页面堆栈

3.小程序分包：无限制

1. 小程序：无限制

2、小程序插件：基础选择器仅支持ID选择器，不支持标签、属性、通配符选择器。

3.小程序分包：无限制

等等，相关形态差异可以结合各个小程序平台来看，这里只列出共同的部分。

如何解决这些分歧？

这里有一些例子：

通过在编译过程中自动将App的运行时模拟实现注入到产品中，解决由于子包和插件中方法缺失或者冲突导致的错误问题。

方法类似，可以在编译过程中检测全局样式是否存在，如果存在则自动在各个页面、组件中注入对应的全局样式引用，解决全局样式失效的问题。

针对各个小程序平台 NPM 使用规则不同的问题，可以通过依赖解析、动态分组、组件抽取打包、引用替换等方式将 NPM 抽取到特定的地方，替换页面中对应的组件和引用，解决 NPM 支持问题。这样业务基本就可以使用各种 NPM，不用担心平台差异。

以此类推，在解决了业务自身难以适配的差异之后，剩下的功能差异都可以由业务基于条件编译自行适配。这样可以大大降低业务形态转换的成本，也形成了我们针对多端场景的形态转换解决方案。

所以至此，多端转换的问题已经基本解决了。

如何管理“复杂的小程序”？

如果说以上内容都集中在如何通过编译解决多端同构、形态问题的话，那么接下来要解决的就是针对“复杂小程序”的应用架构、研发协同问题。

首先介绍一下我们定义的“复杂小程序”，即跨业务领域、周期长、涉及多团队协作、呈现主干+多分支业务模式的应用。之所以说是“复杂”，主要体现在应用形态多样、需求多样、关联业务广泛。

对于饿了么来说，每一个频道仓位都相当于一个小型的饿了么APP，除了在研发上提供便利之外，还需要一个可靠的应用架构来保障其有序演进。

同时，由于渠道定位不同，各渠道在各领域业务、产品、研发的重视程度和投入比重不同，间接导致各渠道同一业务能力参差不齐，不同渠道功能持续缺失。

我们以饿了么微信小程序为例：

我们面临什么问题？

解决方案：线上线下相结合的一体化研发模式

针对上述两个“复杂小程序”面临的核心问题，我们通过“线下一体化研发”和“线上研发协同”进行针对性解决。

线下一体化研发

重点考虑的是提供什么样的一体化研发能力，让多个独立的构建（宿主机、小程序、插件、子包等）在业务单元维度上可以组合成一个可以使用的小程序，消除业务间的强依赖，从而达到业务独立开发、调试、部署的目的，统一业务协作流程，降低多端部署成本。关键策略：

小程序宿主机与各个业务模块（子包、小程序、插件）经过形态转换、打包、编译、构建、合并等一系列流程，合并为一个完整的小程序，根据不同的场景可以支持：

这样就能解决线下研发的问题。

线上研发合作

上文介绍的“离线集成研发”为业务单元提供了无阻塞的开发调试能力，但对于饿了么业务的整体演进，重点是各个版本功能的可用性和可控性。除了将集成范围拓展到所有业务域，还需要标准化的流程约束：

具体做法上，在机制层面提供了业务类型定义的能力，开发者可以对项目进行相应的标记（主包、子包、插件、独立小程序）。在流程层面，定义了开发、集成、发布三个阶段，有点类似APP的研发流程：

更进一步，多终端服务的最佳实践

通过线下融合+线上协同的双重能力，结合已有的多端编译能力，在成功支撑饿了么多端渠道业务稳定、高效的研发的同时，我们也在思考，未来的多端研发模式应该是什么样的？

下图是我们的预期，也是目前饿了么多端应用架构的演进情况：

从图中可以看出，我们将应用程序架构分为三层（从下到上）：

基于这种分层的协作模型，可以最大程度地消除企业对于多端差异的感知，将重点放在如何更好地为用户提供服务上。

以上内容是饿了么基于小程序DSL的跨端实践和解决方案，我们来看一下具体的成果。

跨端结果

饿了么各渠道业务表现

业务一码多终端研发效能提升数据

能力积累——饿了么自研多终端研发框架

开源

我们将饿了么多年来在多平台、多渠道积累的经验和解决方案，整合成一个多平台的研发框架，并以开源的方式向社区开放。

仓库地址：

下图是完整的架构图：

该框架目前支持：

并支撑了饿了么各渠道大部分C端业务的研发和部署。

我们为饿了么解决了大量业务多端研发差异化的问题，让小程序开发的重心回归到产品业务本身，减少用户在多端兼容方面的投入。我们希望通过开源的方式，将实现细节、架构设计、技术思考呈现给大家，服务更多有类似多端同构需求的公司和开发者。同时也希望吸引更多志同道合的伙伴参与共建，加速小程序一码多端能力的建设。欢迎各位小程序开发者与我们交流。

特征

为了帮助社区用户快速上手，我们在易用性、标准化、灵活性等方面做了很多准备：

使用方便：

标准化：

灵活性：

同时也提供了丰富的文档资料：供大家参考。

用户声音

上线几个月以来，我们收到了一些社区用户的积极反馈，也收到了一些请求和疑问。用户最关心的问题是：这是一个 KPI 项目吗？它会长期维护吗？

以下是我在该项目讨论区的回复：

展望未来

未来，我们将在已有能力的基础上，进一步完善已有的多端能力，增强多端转换的可用性，完善与各类社区组件库的兼容性，并持续拓展对编译目标平台（如鸿蒙、快应用等）的支持。在持续为饿了么自有业务和社区用户提供优质服务的同时，希望有朝一日能成为业界小程序多端开发的基础设施之一。

作者：

点击立即免费试用云产品：

原文链接：