本文会先带领大家一起简单回顾下跨端技术背景与演进历程与在这一波儿接着一波儿的跨端浪潮中的饿了么跨端现状，以及在这个背景下，相较于业界基于 React/Vue 研发习惯出发的各种跨端方案，饿了么为什么会选择走另外一条路，这个过程中我们的一些思考、遇到及解决的问题和取得的一些成果，希望能给大家带来一些跨端方面的新思路。
自 90 年的万维网出现，而后的三十多年，我们依次经历了 PC 时代、移动时代，以及现在的万物互联（的 IoT ）时代，繁荣的背后，是越来越多的设备、越来越多的系统以及各种各样的解决方案。
总的来说，按照跨端的场景来划分，主要包含以下 4 类：
而在当下，移动领域依然是绝对的主角，我们来看一下移动端的跨端技术都经历了哪些阶段。
随着移动互联网的蓬勃发展，端形态变的多样，除了传统的 Native、H5 之外，以动态化与小程序为代表的新兴模式百花齐放大行其道，世面上的框架/容器/工具也层出不穷，整个业态朝着碎片化方向发展。
对开发者来说，碎片化的直接影响，是带来了包括但不限于，刚才提到的设备平台、操作系统、渲染容器、语法标准等方面的各种不确定性，增加了大量的学习、开发与维护成本。
于是，应运而生的各类跨端技术，核心在于从不确定性中找寻确定性，以保障研发体验与产物一致性为前提，为各端适配到最优解，用最少成本达到最好效果，真正做到 "一次编写，到处运行"。
移动跨端大致经历了如下几个阶段：
回顾了以上跨端技术背景与演进历程，在这股浪潮里面，饿了么的跨端投放情况是什么样的？投了哪些端？遇到了哪些问题？又是如何解决的？
众所周知，饿了么是围绕 O2O 为用户提供线上到线下服务的公司，通过对时、空、人、货 的有机结合，来链接商家与消费者，相比于传统电商，时空人货本身具有区域属性，这意味着我们做的不是一个大卖场生意，更多的是需要围绕区域特性提供精细化的服务，这里面有一系列时空、体验、规模、成本的约束需要考虑与应对
而在这一系列约束背后，其实有一个各方共通的经营诉求：
这都导向一个目的：哪里流量多，我们就需要在哪里提供与消费者的连接能力。
那么问题来了，流量在哪里？现在的互联网，更多都是在做用户的时间与精力生意，背后拆解下来，其实有几个关键因素可以衡量：用户密度、用户活跃度、市场占有率与用户时间分配，细化来看，其中任意几个条件满足，都可以作为我们流量阵地的候选集。
饿了么经过多年耕耘，对外部关键渠道做了大量布局，业务阵地众多，从效果上看，渠道业务无论是用户流量规模还是订单规模均对大盘贡献度较高，且随着业务的持续精进与外部合作环境的持续改善，增量渠道也在不断的涌现中。
在这么多的业务阵地中，投放在各个端的应用的形态基于：
等的差异和限制，目前形成了 以小程序为主，H5为辅 的承接方式，而这些差异带来了大量的不确定性，主要体现在：
而我们要做的，就是在这两种不确定性中，找到技术能带来的确定性的事情。如何系统性的解决这些问题，则成为我们在保障渠道业务灵活性的基础上持续提升研发效率和体验的关键。
在差异应对上，业务研发最理想的方式是对底层的变化与不一致无感，安心应对业务诉求，基于这个点出发，我们的主要策略是：围绕 “研发体验一致性提升与复杂应用协作机制改进”来保障业务高效迭代。这需要一套强有力的、贴合业务特性的基础设施来支撑。首先想到的便是如何通过“推动框架统一”和“实现一码多端”，来为业务研发降本增效，然而理想很丰满，现实很骨感：
框架的升级通常情况下，大概率会带来业务重构，综合评估之后，作为外部渠道流量大头的小程序业务，则成为了我们优先要保障的业务，也基于此，为了尽可能降低对业务的影响和接入成本，我们明确了以小程序为第一视角来实现多端。
在明确了方向之后，那么问题来了：业界有没有适合我们的开源的框架或解决方案呢？
市面上，从小程序视角出发，具备类似能力的优秀多端框架有很多，有代表性的如 Taro、uni-app、Rax 等，大多以 React 或者 Vue 作为 DSL
那么这些框架能否解决我们所面临的问题？答案是：并不能。
综合 饿了么 的渠道业务背景需要考虑以下几点：
在做了较多的横向对比与权衡之后，上面的这些框架对于我们而言采纳成本过高，所以我们选择了另外一条相对艰辛但更为契合饿了么多端演进方向的路：以小程序原生 DSL 为基础建设跨端解决方案，最大限度保障各端产物代码贴合小程序原生语法，以此尽可能降低因同构带来的体验损耗和业务多端接入成本。
确定以小程序 DSL 作为方向建设跨端解决方案之后，首先要解决的就是如果将已有的小程序快速适配到多端。这就需要对各个端的差异做细致的分析并给出解决方案。
为了能够兼顾性能和研发体验，我们选择了 编译时（重）+运行时（轻） 的解决方案。
静态编译转换主要用于处理 JS、WXS/SJS、WXML/AXML、WXSS/ACSS、JSON 等源码中约束强且不能动态修改的部分，如：
等，原理是通过将源码文件转换为 AST（抽象语法树），并通过操作 AST 的方式来实现将源码转换为目标平台的代码。
但静态编译只能解决一部分的差异，还有一些差异需要通过运行时来抹平。
运行时补偿主要用于处理静态编译无法处理或者处理成本较高的一些运行时动态内容，如：
等等，类似的场景有很多，这里不再一一列举。
通过静态编译 + 运行时补偿的方式，我们便可以让现有的微信或支付宝小程序快速的迁移到其他小程序平台。
伴随外卖小程序上线多年之后，各个大的渠道（支付宝、手淘、微信等）已切流为小程序承载，但是还有很多细分渠道或非小程序环境渠道，比如：各个银行金融渠道，客户端的极小包等，还需要依赖 H5 的形态快速投放，但当前饿了么的业务越来越复杂，相关渠道的投入资源有限，历史包袱重、迭代成本大等原因，产品功能和服务能力远远落后于小程序和饿了么App。而业务急需一个可以将小程序的功能快速复制到 h5 端的技术方案，以较低的研发和维护成本，满足业务多渠道能力对齐上线的诉求。
基于这个背景，我们自然而然的可以想到，即然小程序可以转其他小程序，那么是否也可以直接将小程序直接转换为 Web，从而最大程度上提升人效和功能对齐效率。
具体是怎么实现的？主要手段还是通过编译时 + 运行时的有机结合：
Web 转端编译原理
编译部分和小程序转小程序的主要区别和难点是：需要将 JS、WXS/SJS、WXML/AXML 等文件统一转换并合并为 JS 文件并将 WXML/AXML 文件转换为 JSX 语法，将样式文件统一转换为 CSS 文件，并将小程序的页面和组件都转换为 React 组件。
运行时原理
转 Web 的运行时相较于转换为其他小程序会重很多，为了兼顾性能和体验，运行时的核心在于提供与小程序对等的高效运行环境，这里面包含四个主要模块：
基于这四个模块，配合编译时的自动注入和代码转换，以及路由映射等，我们就可以把一个小程序转换为一个 Web 的 SPA（单页） 或者 MPA（多页） 应用，也成功的解决了业务的研发效率问题，目前 饿了么的新 M 站就是基于这套方案在运行。
解决了各端的编译转换问题，是不是就万事大吉，业务接下来只要按部就班的基于这套能力实现一码多端就可以了？
然而并不是，随着饿了么的业务场景和范围快速拓展，诞生了一些新的诉求，比如：
等等，大家如果仔细观察这些诉求，就会发现一个共同的点：就是小程序的形态不一样。
虽然我们已经具备了多端的能力，但是形态的差异没有解决掉，而之前相关业务的做法是，尽可能将通用功能沉淀到组件库，并按照多端的方式分端输出产物，然而由于相同业务在不同小程序端形态差异性的问题，业务上难以自行规避，而重构的成本又比较高，所以有一部分业务选择了直接按照不同的端不同的形态（如微信、支付宝、淘宝、抖音）各自维护一套代码，但这样做不仅功能同步迭代周期被拉长，而且 BUG 较多，维护困难，研发过程也是异常痛苦。
形态差异是指 小程序、小程序分包、小程序插件 三种不同形态的运行方式差异以及转换为其他形态之后产生的差异，具体如下：
等等，相关形态差异可结合各个小程序平台查看，这里仅罗列常见的部分。
这里举几个例子：
通过在编译过程中，自动向产物中注入对 App 和 getApp 的运行时模拟实现，这样就可以解决分包和插件下方法缺失或者是冲突引起的报错问题。
方法也是类似，可以在编译的过程中检测全局样式是否存在，如果存在，则将对应的全局样式引用自动注入到每一个页面和组件中来解决全局样式失效的问题。
而针对各个小程序平台的 NPM 使用规则不同的问题，可以通过依赖解析、动态分组、组件提取打包、引用替换等方式，将 NPM 抽取到特定的地方，并将对应的组件和页面中的引用进行替换，来解决 NPM 的支持问题，这样业务就可以基本无脑使用各类 NPM 而不用关心平台差异。
以此类推，将业务难以自行适配的差异，逐一解决之后，剩余的一些功能差异，则由业务基于条件编译的方式来自行适配，这样便可以大大的降低业务形态转换成本，同时也形成了我们面向多端场景下的形态转换方案。
那么到这里，多端转换的问题才算是基本解决了。
如果说上面讲的内容都是聚焦在如何通过编译的方式来解决多端同构以及形态问题的话，那么接下来要解决的就是针对“复杂小程序”的应用架构与研发协作的问题了。
首先介绍下我们所定义的“复杂小程序”，即具备跨业务领域的、长周期的、多团队协同的、呈现主链路+多分支业务模式的应用，其之所以“复杂”，主要体现在应用形态多样、诉求多样、关联业务面广等特性上。
对于饿了么来说，每个渠道阵地均相当于一个小型饿了么APP，除了在研发上提供便利外，还需一套可靠的应用架构来保证其有序演进。
同时，由于渠道之间定位不同，各域的业务、产品及研发对各渠道重视程度与投入比重均有差异，间接导致渠道间相同业务能力的参差不齐，且不同渠道功能缺失的情况持续出现。
我们以饿了么微信小程序为例：
针对上面两个“复杂小程序”所面临的核心问题，我们针对性的通过 「线下集成研发」和「线上研发协作」来解决。
线下集成研发
重点考虑的是提供什么样的集成研发能力，允许以业务单元维度将多个独立的构建（宿主、小程序、插件、分包等）组成一个可用的小程序，消除业务之间强依赖关系，从而达成业务可独立开发、调试和部署的目的，方面统一业务协作流程、降低多端同构成本，关键策略：
将小程序宿主和各个业务模块（分包、小程序、插件）通过形态转换、拉包、编译、构建、合并等一系列处理后，合并为一个完整小程序，且根据不同的场景可以支持：
这样我们就可以解决线下研发的问题。
线上研发协作
前面介绍的“线下集成研发”为业务单元提供了无阻塞的开发与调试能力，但对于饿了么业务整体演进来说，重视的是每个版本功能的可用与可控，这里面除了将集成的范围扩展到所有业务域的之外，还需要标准化的流程约束：
具体方式上，在机制层面提供了业务类型定义的能力，开发者可将工程做对应标记（主包、分包、插件、独立小程序），在流程层面定义了开发、集成与发布三个阶段，这和 APP 的研发流程有些类似：
再进一步，多端业务的最佳实践
通过线下集成+线上协作的双重能力加持，结合已有的多端编译能力，在成功的支撑了饿了么多端渠道业务的稳定高效研发的同时，我们也在思考，面向于未来的多端研发模式应该是个什么样子？
下图是我们期望同时也是饿了么目前多端应用架构正在演进中的样子：
从图上可以看出，我们将应用架构划分为三层（从下往上看）：
基于这种分层协作模式，可以最大程度上消除业务对多端差异的感知，可以将重心放在如何更好的为用户提供服务上。
以上内容为饿了么基于小程序 DSL 的跨端实践和解决方案，下面我们来看一下具体取得的成果。
我们将饿了么在跨端多渠道上的多年沉淀和解决方案，融合为 MorJS 多端研发框架，并通过 Github 开源的方式向社区开放。
GitHub 仓库地址：https://github.com/eleme/morjs
下图为 MorJS 的完整架构图：
MorJS 框架目前支持 ：
并支撑了饿了么 C 端大多数业务在各个渠道上的研发和投放。
MorJS 为饿了么解决了大量业务在多端研发上的差异问题，让小程序开发的重心回到产品业务本身，减少使用者对多端差异兼容的投入。通过 MorJS 的开源，我们期望能把其中的实现细节、架构设计和技术思考呈现给大家，为更多有类似多端同构需求的企业和开发者服务。同时，我们也希望能够借此吸引到更多志趣相投的小伙伴参与共建，一起加速小程序一码多端能力的发展。欢迎广大小程序开发者们与我们交流。
为了能够帮助社区的用户可以快速上手，我们在易用性、标准化和灵活性方面做了大量的准备：
易用性：
标准化：
灵活性：
同时也提供了丰富的文档：https://mor.eleme.io/ 供大家查阅。
MorJS 上线的这几个月里面，我们收到了一些社区用户的正向反馈，也收到了一些诉求和问题，其中用户最担心的问题是：MorJS 是不是 KPI 项目，是否会长期维护？
这里借用一下我在 Github 项目的讨论区（Discussions）的回复：
未来，在现有的 MorJS 的能力基础上，我们会进一步完善已有的多端能力，提升多端转换可用度，完善对各类社区组件库的兼容，并持续扩展编译目标平台的支持（如 鸿蒙、快应用等），在持续为饿了么自身业务和社区用户提供高质量服务的同时，期望有朝一日 MorJS 可以成为业界小程序多端研发的基础设施之一。
作者｜羽境
点击立即免费试用云产品 开启云上实践之旅！
本文为阿里云原创内容，未经允许不得转载。
微信关注我们
转载内容版权归作者及来源网站所有！
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。
Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。
WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。
扫码在手机上查看文章
扫描二维码，手机阅读更方便
有任何问题或合作意向欢迎联系我们
Email: 99873273@qq.com
QQ: 99873273