作者 | 圣司
点击查看视频
伴随互联网业务形态的多样化，无线流量渠道矩阵逐步成型，更多场景化的流量入口带来了天然细分的人群与触点，流量红利的逐渐式微也让越来越多的业务开始重视用户增长。在小程序、轻应用等开放平台，及腾讯广告、微博、巨量引擎、百度信息流、阿里汇川等商业化引擎能力加持下，全域投放、全域触达、全域营销的思路逐渐成为标配，IoT、OTT、POS 等设备需求也爆发式增长，端侧业务需要在合适的时机，通过合适的端/渠道，出现在合适的人手中形成承接，朴素的业务需求之下，也对面向多端场景的业务研发提出了更高的要求与挑战。
当我们聊跨端时，我们在聊什么？
1990 年，Tim Berners-Lee 在自家的 NeXT 电脑上打开了 Web 技术的大门，并带来了 HTML 和 HTTP，前端技术的种子自此落地，开始生根发芽。随后的三十年风起云涌，从 PC 时代、移动时代到万物互联的 IoT 时代，繁荣的背后越来越多的设备、系统与解决方案纷至沓来。
跨端作为大前端技术的一个分支，重点在于面向不同终端设备，提供高效的业务场景研发解决方案，并保障性能与体验。今天我们提到的跨端，一般包含四类场景：
- 跨设备平台，如
PC/Mobile/OTT/IoT。不同的设备平台往往意味着不同的硬件能力、传感器、屏幕尺寸与交互方式，尤其在移动互联网早期，由于研发主力仍在 PC 上，而移动设备作为下一个风口也需要布局，诞生了大量跨平台解决方案，Web 技术下典型的就是响应式布局。 - 跨操作系统，如
Android/iOS/HarmonyOS。对于传统前端开发来说，移动端各类操作系统差异已被图形库、渲染引擎等基础设施抹平，并以标准化的形式提供上层 API；但在 RN、Weex 等依赖原生控件渲染的方案下，依然会对跨端差异有明显感知。 - 跨 App，如
淘宝/微信/头条。由于移动平台 CS 架构 App 间天然的壁垒，不同 App 间无法再通过超链接的形式完成资源的索引，而是在各个 App 封闭体系内遵循一套自有标准进行资源的索引与定位。而同一业务投放至不同 App 端时，同样需要适配这些不同的路由规则与原生方法。 - 跨渲染容器，如
Webview/RN/Weex。前面三类场景催生了不同平台、不同操作系统、不同 App 间解决方案的差异性，无线领域各种 native 化渲染、自绘渲染与魔改 Webview 的方案被设计出来，也大大提高了跨端场景下的迁移成本。
考虑到当下移动领域仍是互联网绝对的统治者，我们先将问题的讨论范围收束到移动技术领域。
跨端技术发展史
2007 年苹果发布初代 iPhone 拉开了移动互联网的序幕，08~14 年迎来了 全球范围年复合 35.1% 的高速增长，伴随终端设备的日趋多样化，PC 之后，Mobile、IoT、OTT 等一系列新设备开始登上历史舞台，而在 Web 标准向移动设备适配的过程中，诞生了种类繁多的跨端解决方案，大体上可以分为几个阶段：
19/20 全球移动开发者跨端解决方案使用率，数据来源 statista
- H5 wap 阶段，
jquery/KISSY → Zepto/KISSY-mini。Web 天然跨平台，但由于早期网络环境原因，页面加载速度无法满足业务预期，加之设备传感器标准缺失、内存占用大、GPU 利用率低等问题，在移动设备量爆发伊始，难堪大任的论调一下子被推上风口浪尖，并在 12 年达到顶峰：
"The biggest mistake we made as a company was betting too much on HTML5 as opposed to native. It just wasn't ready." —— Mark Zuckerberg, 2012
彼时标准化组织与浏览器厂商正在酣战，04年 WHATWG 诞生，直至 10年后 HTML5 标准终于发布；相对后来的跨端解决方案，PWA 是 Web 正统，完全的标准化运作实现，但由于受多方阻力，推进缓慢，国际层面 相对有一些声浪，而在国内甚至只能存在于各大厂商的面试题中，近两年受小程序的冲击尤甚。
- Hybrid 阶段，典型代表是
Cordova/PhoneGap/ionic。从核心功能上看，Hybrid 解决了 web 跨端时代的两大痛点问题，1）性能，依靠容器能力，各类离线化、预装包、prefetch 方案大幅减少页面渲染所需加载资源数量，或提前加载时间，配合一些编码上的优化，在 2/3G 及 4G 时代早期把 Web 的秒开体验拉到了与 Native 一个数量级的水平；2）功能，通过 JSBridge 桥接的方式，规避了 Web 标准制定长流程，及与 Native 原生的割裂带来的底层能力缺失。
Hybrid 本质上是 Web 标准/实现滞后于无线业务发展速度之下的一种权衡与妥协，Web 技术借助 hybrid 的加持在无线时代成功撕开了口子，让前端有了一席之地，也为后来的演进方向作了不少探索与铺垫。但 Hybrid 带来的 Web 标准超集，不同 App 间容器能力、配套设施的差异也导致了 PC 浏览器、移动操作系统之后，前端开发的第三次碎片化。
- Native 容器化阶段，典型代表是 ReactNative/Weex。通过 JSC（V8）链接 Web 生态与原生控件，结合 React/Vue 等框架，尝试在研发效率与性能体验间寻找更佳的平衡点，也为前端与无线的协同模式开辟了一条新的道路，各类领域解决方案（受限 DSL + 魔改 web 标准 + Native 渲染能力）开始涌现。Native 容器化拉开了大前端融合渲染方案的序幕，传统前端/客户端的职能边界开始变得模糊。
"It's worth noting that we're not chasing 'write once, run anywhere.' Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach 'learn once, write anywhere.'" —— Tom Occhino, 2015
相比 RN “Learn Once, Write Anywhere”，Weex 的 “Write Once, Run Everywhere” 更理想化也更贴近前端的思想，但从两者的发展脉络上看，两个弊端无法回避：1）Native 容器化本质上没有消灭一致性问题，而是把问题转移到了容器层解决，瓶颈依然存在；2）伴随业务需求的复杂化，每个新特性的支持都会带来容器复杂度的升高，进而影响到性能/体验/稳定性，更多的分层也带来了问题排查难度的提升；当这两个问题达到某个临界点，Native 容器化方案表现甚至会弱于传统 Web，“屠龙少年最终变成了恶龙”。
数据来源 google trends
- 同层渲染阶段，典型代表是
WVC/BlendUI/CoverView。是一种介于 Hybrid 与 Native 容器化之间的中间态跨端增强渲染方案。早期通过在 Webview 上直接绘制 Native 组件并跟随滑动的方式，实现客户端内视频等富交互组件原生化，增强体验；之后借力 Android U4 与 iOS WKWebView 提供的同层渲染技术，可以使 Native 组件像普通 DOM 元素一样使用，滑动跟随、层级控制/遮盖、事件透传、生命周期打通，跨端场景下能够更好贴合所处渲染环境的自有方案，渐进增强。严格来说相较其他几个阶段，同层渲染技术并没有达到同样体量的影响力，但它所代表的思想对于当下与未来诸多方向的融合具有重要意义，因此在此也作简要记录。 - 小程序/快应用阶段，典型代表是
Taro/uni-app/mpvue。小程序的核心是商业模式，而非技术实现，它不为解决跨端问题而生，在此将它列为一个阶段，是因为双线程模型及自建 DSL 的引入带来了新的跨端问题。
从技术上说，小程序跨端方案大体分为编译时与运行时两类，前者主要通过静态编译的方式将基于 React/Vue 等框架的业务代码转换为小程序原生 DSL，如 Rax 编译时、Taro 2.x，优势在于性能相对较好，但受编译限制需要使用非标的受限语法，研发体验比较差；后者则通过运行时框架对接小程序 setData 的方式来实现跨端，优缺点与编译时正好相反；按具体实现不同运行时方案可再细分为两类，1）利用 React 框架特性，通过 react-reconciler 在 VDOM 层直接对接对接小程序渲染，如 Remix；2）通过模拟 DOM/BOM API 的方式，在运行时框架层维护 VDOM 并对接小程序渲染，如 KBone、Rax 运行时、Taro 3.x，这个方案理论上可以对接 react、vue、Angular 等任何上层框架。
小程序在帮助头部 App 建立起封闭流量体系的同时，也让国人第一次在跨端技术领域 “走在了世界前列”（手动狗头保命），各类开发框架、配套工程体系及魔改 DSL 在神秘的东方国度创造出了 “小程序宇宙”（Rax、Remix、wepy、mpvue、uni-app、Megalo、mpx、Chameleon、Taro，相信你还能说出不少），魔幻而现实。
- 自绘渲染阶段，如
Flutter/Qt。自绘本身不是个新词，在此把自绘和 H5、原生渲染并列也不够严谨，这里的 “自绘” 更强调不使用系统原生控件或 Webview 的渲染管线，而是依赖 Skia、Cairo 等跨平台图形库，自底向上自建渲染引擎、研发框架及基础配套的方式，解决跨端一致性问题。自绘渲染能作为一个独立阶段，很大程度上源于 Flutter 这个跨端研发新贵的崛起，双端一致、HMR、状态驱动，以及 Dart 带来的异步编程体验等特性迅速点燃了客户端研发领域。
然而自绘也并非万能，与 iOS/Android 原生设计语言分离，对于使用原生控件、遵循平台交互视觉标准的存量 App 接入不够友好，未来系统层面规范升级也需要投入更高成本适配；2020Q1 调研拿到的 反馈数据 显示，调试、Debug、崩溃、内存问题等 RN/Weex 曾经历的阵痛 Flutter 也一个不缺；从 社区层面 看，生态建设繁荣，但达到成熟的程度尚需时日。
对于前端来说，Dart Framework 本身上手成本并不高，甚至相较客户端，前端能更快适应它的语法与设计模式，但 JS 的背后是标准与生态，切换到 Dart 远不只是学习一门新语言那么简单，而是庞杂生态秩序的重建。从数据上看，Flutter 虽然增长迅猛，但对 RN 等偏前端驱动的解决方案目前 有很多讨论，但没有造成太多冲击，而更多是替换掉了 Cordova/Xamarin 等传统解决方案，未来其在大前端领域的定位仍需摸索，与前端的关联关系也需我们更积极地探索。
其他涉及跨端的方案还有很多，如 Xamarin/SwiftUI/Kotlin/Qt/Unity/Electron 等，考虑到这些方案或不面向前端领域、或在国内缺少广泛受众和讨论、或不以无线领域为重点、或已进入衰退期，在此略过不表。 
纵观跨端技术发展史，想象一根线段，左边是 H5，代表研发效率与动态性；右边是 Native，代表高性能与体验，这几年技术演进的过程，就是通过不断在两个端点间找寻更好平衡的过程，方案无绝对的好坏，而更多是看业务场景诉求，没有银弹，未来这些方案也将在很长一段时间内和平相处，共同构建起大前端的边界与生态。
阿里跨端方向现状与思考
阿里跨端技术发展脉络
财年初我们对经济体超过 25 个 BU/部门端技术现状进行了 1v1 沟通交流，从采样结果上看，91.7% 的团队业务涉及多 App 端（手淘、支付宝、飞猪、高德、钉钉...）投放场景，其中涉及大量工程能力不统一、跨端 API 不统一、跨端埋点/账号不统一等问题；在此基础上，超过 95.8% 的部门存在多渲染容器适配的场景，在一/二/三方容器选型不统一情况下需要同时兼容 Web/Hybrid/Weex/小程序等渲染方案，也暴露出多套 DSL 重复开发成本、性能体验不统一及搭建能力缺失等问题；同时，37.5% 的业务需要适配多种类型的设备，保障功能统一的同时，实现特性匹配的交互视觉，这类场景也面临着跨端适配能力、组件库缺失的高要求。
传统角度看跨端技术，聚焦的点无非性能体验、一致性、研发效率，这些问题过去存在，当下存在，未来很长一段时间也会持续存在，阿里跨端技术经过多年发展，新的挑战也在不断涌现：
- 难以单纯依靠硬件升级解决性能体验问题。摩尔定律下硬件技术的突破没有带来预想中的性能体验问题默认解决，业务研发中，依然需要投入不小的精力进行针对性优化，究其原因，本质上是端技术架构与业务功能复杂度的提升对冲掉了硬件升级带来的性能红利。并且伴随移动互联网流量见顶，业务进入存量博弈阶段，复杂度会进一步提高，纯粹的 Web 解决方案天花板依然会长期存在，因此结合 PHA/SPA/SSR/Snapshot/Prerender 等方向，各业务独立定制容器侧渲染方案依然无可避免；
- 前端与无线不匹配的技术演进节奏，重构沦为常态。从 H5 与 Native 技术演进上看，前端技术更多聚焦在编程思想突破上（MVC/MVVM/reactive/one-way data flow），而容器技术更多聚焦在性能与体验上（Bridge/Native 化容器/自绘渲染引擎）。两者背后的主导力量不同，发展很难说是同步的，而新的编程思想与新的渲染容器技术往往都会带来新的解决方案、研发配套，直接导致 1）业务代码需要跟随两条主线频繁重构；2）演进与迭代过程中进一步加深跨端技术方案的碎片化，包括端内框架/容器的碎片化（稳定性风险），与跨端投放不同 App 异构解决方案的碎片化（高兼容成本）。
- Flutter 等新物种对前端标准的冲击：作为跨端技术新贵，在性能体验接近原生、研发效率接近前端的基础上，通过自绘保障了双端一致性，对未来客户端研发提供了更好的选择。同时，面向未来 Flutter for Web 瞄准的是更大的领域空间，依靠 HTML Mode/WebGL Mode 两套方案有条不紊的推进，从前端角色角度看未来大前端格局迷雾重重，如何定位 Web 标准与 Flutter 之间的关系并协作共存，将是未来一段时间内必须直面的问题。
- 愈发多样化的设备与使用场景带来的兼容适配成本：伴随新零售业务的铺开，大量线下业务场景带来了各具特色的设备，以盒马业务距离，除了常规 Mobile 端外，还涉及 PC、Pad、RF、餐饮一体机及各类 OTT 设备，同时同样一个屏幕，使用者日常使用场景与屏幕距离的不同也需要对应的适配解决方案，甚至不同门店的光线差异也要考虑并妥善处理。
业务最本质的诉求，是在一套研发流程下，一份业务代码（哪怕对代码规范存在一定限制）可以跨端适配，同时在新的 App 或渲染容器方案之上，能够实现业务代码的无缝平迁。今年阿里前端委员会将跨端技术定为重点突破技术之一，期望在容器标准化、研发框架统一、配套设施完善、性能体验优化等方向形成一定突破，赋能各类业态实现更好更快增长。同时今年第 15 届 D2 前端技术论坛也对应推出跨端技术专场，与业内同仁共同分享、探讨一些跨端方向的新思路、新解法。
D2 跨端技术专场
本次 「15 届 D2 前端技术论坛-跨端技术专场」我们邀请了国内外一线技术专家，围绕性能体验度量、跨平台适配、跨端渲染、Flutter 等方向进行话题探讨，目前已入驻以下主题，更多高质量话题也会逐步放出：
主题：以全球 Web 角度谈前端性能的更新与趋势
讲师：Palances Liao，Google 资深 Web 技术专家。专注于 Web 前端技术及确保 Web 生态的完整性 ，同时为许多大型合作伙伴提供 Web 技术解决方案及分享 Web 技术。
简介：前端性能一直以来都是一个艰深的话题，除了各家都有自己不同的量测标准之外，怎样取得更精确的真实用户性能数据及通过工具的辅佐让我们更快速的调试成为了性能优化的一大难点。本专题会注重在 Google 如何定义性能指标，采集及提供优化性能的工具链如何帮助所有开发者快速调优前端性能，带来 Google 的最新研究。
主题：盒马多端一体化前端体验基建
讲师：景庄，阿里巴巴前端技术专家。目前负责盒马中后台多端体验基建产品 Hippo，包括多端一体化的设计体系和盒马工作台体验管理体系；Alibaba Fusion Design 技术体系前核心开发。
简介：实体零售数字化过程中，盒马对人货场进行了全新的重构，在多元的业态和作业场景中，传统中后台的体验边界也进一步被延展，前端不再单一面向单一类型设备进行开发与交付，而是需要触及到 TVPCPadPhonePOSRFWatch 等更多的智能设备。在盒马，我们通过构建多端体验产品 Hippo 去解决新零售科技场景下的多端内容交付与体验一体化的问题，本次分享主要介绍盒马的中后台跨端探索过程，包括多端统一的设计体系，可跨设备复用的组件架构，以及支持跨端协同的应用架构。
总结
从 IE6 到 Chrome；从自动屏蔽图片的 wap 浏览器，到即用即走的小程序；从应用开发/UED 兼职写页面，到前端成为独立岗位，跨端这个话题几乎贯穿了前端技术发展的全过程。本次 D2 前端技术论坛也期待与更多开发者一起开拓视野、碰撞思想、凝聚共识，为构造更好的跨端技术生态，共同努力！
🔥一起来 D2 跨端技术专场学习更多精彩内容
关注「Alibaba F2E」
把握阿里巴巴前端新动向
