如何自己建设简单的手机网站首页,大连网络推广运营,中国建设网站企业网上银行业务功能,网站注销跨端技术背景与演进历程
跨端#xff0c;究竟跨的是哪些端#xff1f;
自 90 年的万维网出现#xff0c;而后的三十多年#xff0c;我们依次经历了 PC 时代、移动时代#xff0c;以及现在的万物互联#xff08;的 IoT #xff09;时代#xff0c;繁荣的背后#xff…跨端技术背景与演进历程
跨端究竟跨的是哪些端
自 90 年的万维网出现而后的三十多年我们依次经历了 PC 时代、移动时代以及现在的万物互联的 IoT 时代繁荣的背后是越来越多的设备、越来越多的系统以及各种各样的解决方案。
总的来说按照跨端的场景来划分主要包含以下 4 类 跨设备平台如 PC电脑/ Mobile手机/ OTT机顶盒/ IoT物联网设备。不同的设备平台往往意味着不同的硬件能力、传感器、屏幕尺寸与交互方式跨操作系统如 Android/iOS/HarmonyOS。不同的操作系统为应用开发通常提供了不同的编程语言、应用框架和 API跨移动应用如 微信 / 支付宝 / 手淘 / 抖音 / 快手等。由于移动平台 CS 架构 及 App 间天然的壁垒不同 App 间相互隔离并各自在其封闭体系内遵循一套自有标准进行各类资源的索引、定位及渲染。而同一业务投放至不同 App 端时就需要分别适配这些不同的规则。跨渲染容器如 Webview/React Native/Flutter。前面三类场景催生了针对不同设备平台、不同操作系统、不同 App 间解决方案因而移动领域的各种 Native 化渲染、自绘渲染与魔改 Webview 的方案也由此被设计出来在尝试解决跨端问题的同时也一定程度上提高了跨端的迁移门槛和方案选择难度。
而在当下移动领域依然是绝对的主角我们来看一下移动端的跨端技术都经历了哪些阶段。
移动跨端技术演进
随着移动互联网的蓬勃发展端形态变的多样除了传统的 Native、H5 之外以动态化与小程序为代表的新兴模式百花齐放大行其道世面上的框架 / 容器 / 工具也层出不穷整个业态朝着碎片化方向发展。
对开发者来说碎片化的直接影响是带来了包括但不限于刚才提到的设备平台、操作系统、渲染容器、语法标准等方面的各种不确定性增加了大量的学习、开发与维护成本。
于是应运而生的各类跨端技术核心在于从不确定性中找寻确定性以保障研发体验与产物一致性为前提为各端适配到最优解用最少成本达到最好效果真正做到 一次编写到处运行。
移动跨端大致经历了如下几个阶段 H5 Wap 阶段Web 天然跨平台响应式布局是当时的一个主要手段但由于早期网络环境原因页面加载速度无法满足业务预期加之设备传感器标准缺失、内存占用大、GPU 利用率低等问题在移动设备量爆发伊始难堪大任的论调一下子被推上风口浪尖并在 12 年达到顶峰。Hybrid 阶段典型代表是 Cordova/ionic。功能上看Hybrid 解决了历史两大痛点 1性能依靠容器能力各类离线化、预装包、Prefetch 方案大幅减少加载耗时配合编码优化在 3/4G 时代使 H5 的体验上了一个台阶2功能通过 JSBridge 方式规避了与 Native 原生割裂带来的底层能力缺失。框架 原生阶段典型代表是 ReactNative/Weex。基于 JSC 或类似的引擎在语法层与 React/Vue 结合渲染层使用原生组件绘制尝试在研发效率与性能体验间寻找更佳的平衡点各类领域解决方案受限 DSL 魔改 web 标准 Native 渲染能力开始涌现拉开了大前端融合渲染方案的序幕。自绘渲染阶段典型代表是 Flutter/Qt。这里的 “自绘” 更强调不使用系统原生控件或 Webview 的渲染管线而是依赖 Skia、Cairo 等跨平台图形库自底向上自建渲染引擎、研发框架及基础配套的方式其跨 Android/iOS 的特性迅速点燃了客户端研发领域。小程序阶段典型代表是 微信 / 支付宝小程序。小程序是被创造出来的其本质是各 APP 厂商出于商业考量构造了相对封闭的生态在标准与能力上无论与 Web 还是厂商之间均存在差异能力上是自定义 DSL API Hybrid 同层渲染 商业管控的综合体。市面跨端方案策略均是锚定一种研发规约进行各形态编译时与运行时的差异抹平与适配。
回顾了以上跨端技术背景与演进历程在这股浪潮里面饿了么的跨端投放情况是什么样的投了哪些端遇到了哪些问题又是如何解决的 众所周知饿了么是围绕 O2O 为用户提供线上到线下服务的公司通过对时、空、人、货 的有机结合来链接商家与消费者相比于传统电商时空人货本身具有区域属性这意味着我们做的不是一个大卖场生意更多的是需要围绕区域特性提供精细化的服务这里面有一系列时空、体验、规模、成本的约束需要考虑与应对
而在这一系列约束背后其实有一个各方共通的经营诉求
对于商家来说为了有更好的经营需要有更多曝光与客户有更多的触达以便带来成交。对于平台来说为了能够让更多消费者享受我们的服务除了深耕自己的超级 APP饿了么 APP外还需要在人流量大的地方加大曝光、声量与服务能力来扩大我们的规模。
这都导向一个目的哪里流量多我们就需要在哪里提供与消费者的连接能力。
那么问题来了流量在哪里现在的互联网更多都是在做用户的时间与精力生意背后拆解下来其实有几个关键因素可以衡量用户密度、用户活跃度、市场占有率与用户时间分配细化来看其中任意几个条件满足都可以作为我们流量阵地的候选集。
饿了么经过多年耕耘对外部关键渠道做了大量布局业务阵地众多从效果上看渠道业务无论是用户流量规模还是订单规模均对大盘贡献度较高且随着业务的持续精进与外部合作环境的持续改善增量渠道也在不断的涌现中。 在这么多的业务阵地中投放在各个端的应用的形态基于
渠道的运行环境渠道的流量特性渠道的业务定位渠道的管控规则
等的差异和限制目前形成了 以小程序为主H5 为辅 的承接方式而这些差异带来了大量的不确定性主要体现在
渠道环境的高度不确定性对接了这么多渠道每个端的运行环境存在巨大差异拿小程序能力举例即使是个别 APP 的小程序方案借鉴了微信的思路由于其内部商业能力、产品设计思路、能力成熟度与完整度、研发配套语法、框架、工具等的不一致也会使研发体感有明显的不同这对技术同学来说带来的是渠道环境的高度不确定性业务诉求的高度不确定性同时我们所投放的 APP 都可划分到某些细分领域用户特性与用户在该平台上的诉求不一渠道定位也不一致随着每个业务域的功能演进越来越多多个渠道功能是否对齐、要不要对齐、有没有对齐、什么时候对齐成了一个非常现实和麻烦的事情同时业务域之间可能还存在功能上的关联这进一步提高了其复杂度在没有一个好的机制与能力保障下业务、产品、研发对每个渠道的同步策略、能力范围的感知会有较大偏差甚至于一个需求的迭代每个端什么时候能同步都变成了一个无法预期的事情这对于业、产、研来说带来的是业务诉求上的高度不确定性。
而我们要做的就是在这两种不确定性中找到技术能带来的确定性的事情。如何系统性的解决这些问题则成为我们在保障渠道业务灵活性的基础上持续提升研发效率和体验的关键。
在差异应对上业务研发最理想的方式是对底层的变化与不一致无感安心应对业务诉求基于这个点出发我们的主要策略是围绕 “研发体验一致性提升与复杂应用协作机制改进” 来保障业务高效迭代。这需要一套强有力的、贴合业务特性的基础设施来支撑。首先想到的便是如何通过 “推动框架统一” 和 “实现一码多端”来为业务研发降本增效然而理想很丰满现实很骨感 框架的升级通常情况下大概率会带来业务重构综合评估之后作为外部渠道流量大头的小程序业务则成为了我们优先要保障的业务也基于此为了尽可能降低对业务的影响和接入成本我们明确了以小程序为第一视角来实现多端。
基于小程序跨端的行业现状和思考
在明确了方向之后那么问题来了业界有没有适合我们的开源的框架或解决方案呢 市面上从小程序视角出发具备类似能力的优秀多端框架有很多有代表性的如 Taro、uni-app、Rax 等大多以 React 或者 Vue 作为 DSL
那么这些框架能否解决我们所面临的问题答案是并不能。
为什么饿了么选择以小程序 DSL 为基础实现跨端 综合 饿了么 的渠道业务背景需要考虑以下几点
改造成本以支付宝、微信、淘宝为代表的饿了么小程序运营多年大部分存量业务是以支付宝或微信小程序 DSL 来编写需关注已有业务逻辑或组件库的改造成本而采纳业界框架基本上会直接引发业务的大量重构这个改造成本是难以接受的。性能体验渠道业务是饿了么非常重要的流量阵地重视程度与 APP 无差在体验和性能上有极致的要求所以我们期望在推动跨端的同时尽可能减少运行时引入带来的性能损耗。业务协同由于每个渠道都基本相当于一个小型的饿了么 APP复杂度高涉及到多业务域的协同包括主线步调一致性考量、多业务线 / 应用类型集成、全链路功能无缝衔接等在此之外还需给各业务线最大限度的自控与闭环能力背后需要的是大型小程序业务的一体化研发支撑。
在做了较多的横向对比与权衡之后上面的这些框架对于我们而言采纳成本过高所以我们选择了另外一条相对艰辛但更为契合饿了么多端演进方向的路以小程序原生 DSL 为基础建设跨端解决方案最大限度保障各端产物代码贴合小程序原生语法以此尽可能降低因同构带来的体验损耗和业务多端接入成本。
基于小程序 DSL 的跨端解决方案
确定以小程序 DSL 作为方向建设跨端解决方案之后首先要解决的就是如果将已有的小程序快速适配到多端。这就需要对各个端的差异做细致的分析并给出解决方案。 如何解决小程序多端编译
为了能够兼顾性能和研发体验我们选择了 编译时重 运行时轻 的解决方案。
静态编译解决了哪些问题 静态编译转换主要用于处理 JS、WXS/SJS、WXML/AXML、WXSS/ACSS、JSON 等源码中约束强且不能动态修改的部分如
模块引用JS/WXS/SJS/WXML/AXML/WXSS/ACSS/JSON 等源码中的模块引用替换和后缀名修改模版属性映射或语法兼容AXML/WXML 中如 a:if → wx:if、 onTap → bind:tap、{{${name} Props}} → { {name Props}} 等配置映射如页面 {titleBarColor: #000000} → { navigationBarBackgroundColor:#000000,navigationBarTextStyle:white }
等原理是通过将源码文件转换为 AST抽象语法树并通过操作 AST 的方式来实现将源码转换为目标平台的代码。
但静态编译只能解决一部分的差异还有一些差异需要通过运行时来抹平。
运行时补偿解决了哪些问题 运行时补偿主要用于处理静态编译无法处理或者处理成本较高的一些运行时动态内容如
JSAPI实际业务使用上不管是 JSAPI 的名字还是 JSAPI 的入参都会存在动态赋值的情况导致了在 JSAPI 的真实调用上很难通过 AST 去解析出实际传参自定义组件 - Props 属性比如支付宝属性使用 props 声明而微信属性使用 properties 声明配置方式不同且使用时分别使用 this.props.x 及 this.properties.x 的方式获取同时可能存在动态取值的情况自定义组件 - 生命周期支付宝小程序中的 didUpdate 生命周期在触发了 props 和 data 更新后都会进入 didUpdate 这个生命周期且能够在 didUpdate 中访问到 prevProps /prevData而在微信小程序中静态转义出这个生命周期就意味着你需要去动态分析出 didUpdate 里面要用到的所有属性然后去动态生成出这些属性的监听函数。这显然可靠程度是极其低的
等等类似的场景有很多这里不再一一列举。
通过静态编译 运行时补偿的方式我们便可以让现有的微信或支付宝小程序快速的迁移到其他小程序平台。
如何解决小程序转 Web
伴随外卖小程序上线多年之后各个大的渠道支付宝、手淘、微信等已切流为小程序承载但是还有很多细分渠道或非小程序环境渠道比如各个银行金融渠道客户端的极小包等还需要依赖 H5 的形态快速投放但当前饿了么的业务越来越复杂相关渠道的投入资源有限历史包袱重、迭代成本大等原因产品功能和服务能力远远落后于小程序和饿了么 App。而业务急需一个可以将小程序的功能快速复制到 h5 端的技术方案以较低的研发和维护成本满足业务多渠道能力对齐上线的诉求。
基于这个背景我们自然而然的可以想到即然小程序可以转其他小程序那么是否也可以直接将小程序直接转换为 Web从而最大程度上提升人效和功能对齐效率。
具体是怎么实现的主要手段还是通过编译时 运行时的有机结合
Web 转端编译原理 编译部分和小程序转小程序的主要区别和难点是需要将 JS、WXS/SJS、WXML/AXML 等文件统一转换并合并为 JS 文件并将 WXML/AXML 文件转换为 JSX 语法将样式文件统一转换为 CSS 文件并将小程序的页面和组件都转换为 React 组件。
运行时原理 转 Web 的运行时相较于转换为其他小程序会重很多为了兼顾性能和体验运行时的核心在于提供与小程序对等的高效运行环境这里面包含四个主要模块
框架提供了小程序在 Web 中的基础运行时功能比如Page 、Component 、App 等全局函数并且提供完整的生命周期实现事件的注册、分发等组件提供小程序公共组件的支持比如 view、button、scroll-view 等小程序原生提供的组件API提供了类似小程序中 wx 或者 my 的 一系列 api 的实现路由提供了页面路由支持和 getCurrentPages 等方法支持
基于这四个模块配合编译时的自动注入和代码转换以及路由映射等我们就可以把一个小程序转换为一个 Web 的 SPA单页 或者 MPA多页 应用也成功的解决了业务的研发效率问题目前 饿了么的新 M 站就是基于这套方案在运行。 解决了各端的编译转换问题是不是就万事大吉业务接下来只要按部就班的基于这套能力实现一码多端就可以了
然而并不是随着饿了么的业务场景和范围快速拓展诞生了一些新的诉求比如
支付宝的独立小程序作为分包接入微信小程序淘宝 / 支付宝的小程序插件作为分包接入某个现有的微信小程序支付宝的独立小程序作为插件接入淘宝小程序插件支付宝小程序插件作为分包接入微信或抖音小程序
等等大家如果仔细观察这些诉求就会发现一个共同的点就是小程序的形态不一样。
虽然我们已经具备了多端的能力但是形态的差异没有解决掉而之前相关业务的做法是尽可能将通用功能沉淀到组件库并按照多端的方式分端输出产物然而由于相同业务在不同小程序端形态差异性的问题业务上难以自行规避而重构的成本又比较高所以有一部分业务选择了直接按照不同的端不同的形态如微信、支付宝、淘宝、抖音各自维护一套代码但这样做不仅功能同步迭代周期被拉长而且 BUG 较多维护困难研发过程也是异常痛苦。
小程序形态差异有哪些
形态差异是指 小程序、小程序分包、小程序插件 三种不同形态的运行方式差异以及转换为其他形态之后产生的差异具体如下
getApp 差异 小程序 可通过 getApp () 来获取全局 App 实例及实例上挂载的属性或方法小程序插件 无法调用 getApp ()小程序分包 可通过 getApp () 来获取全局 App 实例及实例上挂载的属性或方法但当通过小程序转换为分包后分包自身原本调用的 getApp 将失效并被替换为宿主小程序的 getAppApp 应用生命周期 差异 小程序 应用会执行 onLaunch、onShow、onHide 等生命周期小程序插件 无应用生命周期小程序分包 无应用生命周期全局样式如app.wxss 或 app.acss差异 小程序 可通过全局样式来声明全局样式小程序插件 无全局样式小程序分包 无全局样式NPM 使用限制 小程序 各个小程序平台支持和限制情况不一小程序插件 各个小程序平台支持和限制情况不一小程序分包 各个小程序平台支持和限制情况不一接口调用限制 小程序 无限制小程序插件 存在大量的接口调用限制如 开发支付宝小程序插件 或 开发微信小程序插件小程序分包 无限制路由差异 小程序 转换到其他形态后自身路由会发生变化小程序插件 转换到其他形态后自身路由会发生变化跳转插件页面需要包含 plugin:// 或 dynamic-plugin:// 等前缀小程序或分包则不需要小程序分包 转换到其他形态后自身路由会发生变化getCurrentPages 差异 小程序 无限制小程序插件 无法通过 getCurrentPages 获取到小程序的页面堆栈小程序分包 无限制页面或组件样式差异 小程序 无限制小程序插件 基本选择器只支持 ID 与 class 选择器不支持标签、属性、通配符选择器小程序分包 无限制
等等相关形态差异可结合各个小程序平台查看这里仅罗列常见的部分。
如何解决这些差异
这里举几个例子 通过在编译过程中自动向产物中注入对 App 和 getApp 的运行时模拟实现这样就可以解决分包和插件下方法缺失或者是冲突引起的报错问题。 方法也是类似可以在编译的过程中检测全局样式是否存在如果存在则将对应的全局样式引用自动注入到每一个页面和组件中来解决全局样式失效的问题。 而针对各个小程序平台的 NPM 使用规则不同的问题可以通过依赖解析、动态分组、组件提取打包、引用替换等方式将 NPM 抽取到特定的地方并将对应的组件和页面中的引用进行替换来解决 NPM 的支持问题这样业务就可以基本无脑使用各类 NPM 而不用关心平台差异。
以此类推将业务难以自行适配的差异逐一解决之后剩余的一些功能差异则由业务基于条件编译的方式来自行适配这样便可以大大的降低业务形态转换成本同时也形成了我们面向多端场景下的形态转换方案。
那么到这里多端转换的问题才算是基本解决了。
如何治理 “复杂小程序”
如果说上面讲的内容都是聚焦在如何通过编译的方式来解决多端同构以及形态问题的话那么接下来要解决的就是针对 “复杂小程序” 的应用架构与研发协作的问题了。 首先介绍下我们所定义的 “复杂小程序”即具备跨业务领域的、长周期的、多团队协同的、呈现主链路 多分支业务模式的应用其之所以 “复杂”主要体现在应用形态多样、诉求多样、关联业务面广等特性上。
对于饿了么来说每个渠道阵地均相当于一个小型饿了么 APP除了在研发上提供便利外还需一套可靠的应用架构来保证其有序演进。
同时由于渠道之间定位不同各域的业务、产品及研发对各渠道重视程度与投入比重均有差异间接导致渠道间相同业务能力的参差不齐且不同渠道功能缺失的情况持续出现。
我们以饿了么微信小程序为例 面临的问题有哪些
工程复杂导致研发效率低大量的团队在一个单体小程序应用上研发带来的直接问题就是小程序巨大化带来的研发体验差和编译效率低且业务相互依赖单一模块构建失败会引发整个项目的失败比如饿了么微信小程序单次编译的时间超过了半个小时且体积逼近 20m 上限。研发流程不规范导致稳定性差同时由于不同的业务团队迭代周期不一致而每次发版都需要所有业务的代码一起发哪怕是某个业务分包或者插件没有更新但是对应的底层依赖库发生了变更也极有可能引入线上 BUG导致测试回归的成本居高不下发版质量难以保障。
解决方案线下线上结合的集成研发模式
针对上面两个 “复杂小程序” 所面临的核心问题我们针对性的通过 「线下集成研发」和「线上研发协作」来解决。
线下集成研发
重点考虑的是提供什么样的集成研发能力允许以业务单元维度将多个独立的构建宿主、小程序、插件、分包等组成一个可用的小程序消除业务之间强依赖关系从而达成业务可独立开发、调试和部署的目的方面统一业务协作流程、降低多端同构成本关键策略
提供统一的集成研发方式和流程提供标准、可复用的集成产物规范为复杂小程序提供解耦工具和集成方法标准化小程序宿主、小程序插件、小程序分包、小程序模块之间的通信及能力注入方式 将小程序宿主和各个业务模块分包、小程序、插件通过形态转换、拉包、编译、构建、合并等一系列处理后合并为一个完整小程序且根据不同的场景可以支持
主子分包研发模式基于不同业务对小程序中的分包进行拆分以达到各个业务相互解耦独立迭代的目的SDK 研发模式将通用的页面或组件封装置某个 NPM 包中作为提供特定功能的 SDK 交由业务使用小程序插件研发模式集成研发也可以用支持标准的小程序插件研发。
这样我们就可以解决线下研发的问题。
线上研发协作
前面介绍的 “线下集成研发” 为业务单元提供了无阻塞的开发与调试能力但对于饿了么业务整体演进来说重视的是每个版本功能的可用与可控这里面除了将集成的范围扩展到所有业务域的之外还需要标准化的流程约束 具体方式上在机制层面提供了业务类型定义的能力开发者可将工程做对应标记主包、分包、插件、独立小程序在流程层面定义了开发、集成与发布三个阶段这和 APP 的研发流程有些类似
开发各业务应用自行研发并结合平台部署测试开发测试通过等待窗口期开启进入集成测试集成管理员设置集成窗口期在窗口期允许业务多次集成研发确认最终要进集成的稳定版本期间主包管理员可多次部署体验版用于集成测试。窗口期结束后不允许随意变更发布集成测试通过各业务进行代码 CR 并进入发布阶段等候主包提审通过发布上线最终由管理员完成本次迭代发布发布完成后符合标准的主分包产物会被保存下来后续的迭代中如果某个分包未发生变更则会直接复用产物极大的降低了业务的发布风险并提升了整体的构建效率。
再进一步多端业务的最佳实践
通过线下集成 线上协作的双重能力加持结合已有的多端编译能力在成功的支撑了饿了么多端渠道业务的稳定高效研发的同时我们也在思考面向于未来的多端研发模式应该是个什么样子
下图是我们期望同时也是饿了么目前多端应用架构正在演进中的样子 从图上可以看出我们将应用架构划分为三层从下往上看
基础服务与研发规范最底部的是基础服务与研发规范由 多端研发框架、多端研发平台和多端研发规范来提供统一的研发支撑保障业务研发的基础能力、体验和效率并负责将相关的业务统一打包、封装、集成并部署和投放到不同的渠道宿主应用框架第二层是宿主应用框架Framework也可以认为是多端统一解决方案承接了面向于业务研发并适配了多端差异的基础 API如 登录、定位、请求、路由、实验、风控、埋点、容器等、基础组件和最佳实践通过分渠道的配置化运行、标准化的接入手段和中心化的能力管理来保障整体框架的轻量化、标准化与持续迭代和升级渠道应用主体最上层是各个业务的应用实体有一个壳工程 N 个业务工程组成壳工程承接各个渠道定制化的一些能力而并将下层应用框架的能力暴露给上层的各个业务各个业务只需要关心两件事即可 多端形态以什么样的形态接入到对应的渠道即壳工程中业务功能不同的渠道需要展示哪些功能
基于这种分层协作模式可以最大程度上消除业务对多端差异的感知可以将重心放在如何更好的为用户提供服务上。
以上内容为饿了么基于小程序 DSL 的跨端实践和解决方案下面我们来看一下具体取得的成果。
跨端成果
饿了么各渠道业务效果展示 业务一码多端研发提效数据
研发提效采用一码多端和集成研发模式的业务平均提效 70%同构的端越多提效越多多端占比饿了么内部 85% 的多端业务在基于这套方案实现多渠道业务研发和投放业务覆盖涵盖了饿了么全域的各个业务板块
能力沉淀 — 饿了么自研 MorJS 多端研发框架
MorJS 开源 我们将饿了么在跨端多渠道上的多年沉淀和解决方案融合为 MorJS 多端研发框架并通过 Github 开源的方式向社区开放。
GitHub 仓库地址https://github.com/eleme/morjs
下图为 MorJS 的完整架构图 MorJS 框架目前支持
2 种 DSL微信小程序 DSL 或 支付宝小程序 DSL4 种编译形态小程序、小程序插件、小程序分包、小程序多端组件9 个目标平台微信、支付宝、百度、字节、快手、钉钉、手淘、QQ、Web
并支撑了饿了么 C 端大多数业务在各个渠道上的研发和投放。
MorJS 为饿了么解决了大量业务在多端研发上的差异问题让小程序开发的重心回到产品业务本身减少使用者对多端差异兼容的投入。通过 MorJS 的开源我们期望能把其中的实现细节、架构设计和技术思考呈现给大家为更多有类似多端同构需求的企业和开发者服务。同时我们也希望能够借此吸引到更多志趣相投的小伙伴参与共建一起加速小程序一码多端能力的发展。欢迎广大小程序开发者们与我们交流。
MorJS 特性介绍 为了能够帮助社区的用户可以快速上手我们在易用性、标准化和灵活性方面做了大量的准备
易用性
DSL 支持可使用微信小程序 DSL 或 支付宝小程序 DSL 编写小程序无额外使用成本多端支持支持将一套小程序转换为各类小程序平台及 Web 应用节省双倍人力快速接入仅需引入两个包增加一个配置文件即可简单快速接入到现有小程序项目
标准化
开箱即用内置了脚手架、构建、分析、多端编译等完整研发能力仅需一个依赖即可上手开发表现一致通过编译时 运行时抹平多端差异性让不同平台的小程序获得一致的用户体验形态转换支持同一个项目的不同的形态允许小程序、分包、插件不同形态之间的相互转换
灵活性
方便扩展MorJS 将完备的生命周期和内部功能插件化使用插件 (集) 以满足功能和垂直域的分层需求类型支持除小程序标准文件类型外还支持 ts、less/scss、jsonc/json5 等多种文件类型按需适配可根据需求选择性接入适配能力小项目仅需编译功能中等项目可结合编译和页面注入能力大型项目推荐使用复杂小程序集成能力
同时也提供了丰富的文档https://mor.eleme.io/ 供大家查阅。
用户原声 MorJS 上线的这几个月里面我们收到了一些社区用户的正向反馈也收到了一些诉求和问题其中用户最担心的问题是MorJS 是不是 KPI 项目是否会长期维护
这里借用一下我在 Github 项目的讨论区Discussions的回复 展望未来 未来在现有的 MorJS 的能力基础上我们会进一步完善已有的多端能力提升多端转换可用度完善对各类社区组件库的兼容并持续扩展编译目标平台的支持如 鸿蒙、快应用等在持续为饿了么自身业务和社区用户提供高质量服务的同时期望有朝一日 MorJS 可以成为业界小程序多端研发的基础设施之一。
