跨端浪潮下前端开发者的机遇与挑战

跨端一直都是一个前端开发者绕不开的话题，无论是基于研发效率的考量还是从业务场景的需求出发，跨端都是一个“刚需”。从最早的 PC 时代到移动时代，从移动时代到 IOT 时代，不断地涌现各种端，除了最常见的智能手机，它可能是小到一块智能手表，也可以是大到一个大屏终端 IOT 设备。而层出不穷的跨端技术，也为我们跨端方案提供了更多的选择。

那么我们究竟要跨哪些端？

• PC 端与移动端：从最早期的 PC 时代过度到移动时代，开发者希望通过一套代码同时在 PC 跟移动两端复用，于是产生了响应式等技术，使业务在 PC 发展的同时，也完成了在移动端的布局，保证业务不会在移动时代落后。

• Native 与 Web：最常见的两种智能手机的操作系统 Android 与 iOS，Android 应用是用 JAVA 编码的，而 iOS 使用 oc 或者 Swift 编码的。同样，基于降级策略以及外放的考虑，我们也希望一套代码可以同时运行在 Web 上，而 Web 则是使用 JavaScript 编码的。天然的差异需要我们在端上适配时提供多套不同的代码实现，这使得研发周期加长，研发工作量剧增。

• IOT 设备：随着进入万物互联的时代，越来越多的 IOT 设备涌现在我们的生活中，随处可见的大大小小的带屏终端设备，都是新的“端”，譬如智能家具、可穿戴设备以及车载设备等等。跨端早就不只是 Android 跟 iOS 的事情了，各种各样的设备终端带来的新的挑战。

• 小程序、轻应用：各种标准以及 DSL 诞生了新的“端”。

• APP：各种 APP 之间互相投放。

• and more......

跨端技术的演进

本着对研发效率以及用户体验的极致追求，跨端技术也随着历史的浪潮不断地发展。从最早的 H5 方案到 Hybrid 方案，以及后来的 Weex/React Native 方案，到现在如火如荼的 Flutter。

每个方案的演进都是为了解决当下方案的一些已知问题，但需要考量的因素都逃不过这些方面——渲染一致性、性能、体验、研发效率。我们并不希望需要去为不同的操作系统分别开发两份不同的 UI，期望可以通过一份代码使他们的渲染结果完全一致。同时，我们希望可以直接使用强大的生态去支撑我们的开发，拥抱标准，使得每次升级方案不需要对现有代码或者方案做一次大规模的重构。同样，性能与体验，也是端上绕不开的话题，这直接影响到我们的用户体验。

那么，下面来介绍一下跨端技术演进的几个重要阶段。

Web 以及 Hybrid APP

其实大家熟悉的 Web 就是最成功的跨平台方案之一，它与生俱来的跨平台能力、开放的标准以及强大的生态使它成为赤手可热的容器之一。

但是 Web 本身还是存在一些问题：

• 内存消耗大、GPU 利用率低、长列表滚动等，这使得它在移动端的表现并不尽人意。

• 由于各个浏览器厂商实现标准的迭代节奏慢，兼容性差，往往我们无法在 Web 上使用一些较新的能力，这使得我们的业务开发非常受限。

• 性能差，尽管网络以及硬件的发展给了性能足够多的红利，但是日益复杂的业务总能把已有的性能吃透。

• 由于 Web 需要向前兼容，有着非常重的历史包袱，一些古老的或者低性能的 CSS 可能会导致相当复杂的布局计算逻辑，消耗大量的时间。

于是在 Web 之上，衍生出一系列增强 Web 能力的方案：

• Hybrid App：依赖原生容器提供给 Web 更多的能力，包括 prefetch、离线化等。

• PWA：提供了离线缓存、系统通知等能力，但是目前在国内发展不容乐观。

• PHA：使用 Hybrid 的手段让 Web 的体验更加趋向 Native。

但是 Web 的方案还是存在性能问题，但是原生开发我们需要适配多端开发多端代码，于是我们需要寻求一个性能与研发效率的平衡点，于是产生了 Weex 以及 React Native 等方案。

Weex/React Native

Weex 等方案通过 DSL 与 W3C 标准的子集向上结合了前端开发的生态，使我们熟悉的任何前端相关的工具都可以直接使用，保证了研发效率。而向下则是调用了系统自带的原生空间，使用原生渲染保证了性能与体验。

用前端代码开发原生 UI，这是一个非常美好的愿景，但是事与愿违，实际上还是存在一些问题。Weex 方案并没有抹平多端的差异，而是把差异的问题放在了容器侧去解决。由于底层直接调用了原生组件，而原生组件本身就存在一些限制，有限的能力不能满足开发者所有的需求，所以在实现 W3C 标准时有些牵强，会有一些在多端表现不一致的行为，没法保证完全的多端一致性。

Flutter

Flutter 可以说是这两年跨端方案的新宠，它既不使用原生组件，也不依赖 WebView，而是通过自己的高性能渲染引擎直接调用底层的 Skia 进行自绘渲染，保证了多端的渲染一致性。

Flutter 使用 Dart 语言进行开发，Dart 既支持 AOT 也支持 JIT，在开发时可以使用 JIT，这使得我们可以直接使用 HMR，保证良好的开发体验。但是在运行时它是在 AOT 模式下的，这也使得它在运行时会有更佳的运行效率。

但是对于前端开发者来说， Widget 这种基于状态驱动的开发模式已经是非常熟悉，同时学习一门 Dart 语言的成本也不算高。但是对于已有前端生态与基建等的替换成本却是无法接受的，同时，它本身不支持动态化在复杂多变快速迭代的业务中并不能很好的胜任。所以在 Flutter 的基础上，也出现了非常多与 Web 结合的方案的探索，比如说 Kraken、WFlutter 等。通过对接 W3C 标准，保证上层直接使用 Web生态，底层使用 Flutter 的自绘渲染保证多端的渲染一致性。

跨端中的变与不变

各种新的技术层出不穷，在技术的迭代演进中，也演化出了各种新的技术方案以及新的容器。技术在演进，容器在发展，这是“变”。

那么什么是不变？容器那么多，如何进行适配，是否每出现一种新的容器，我们必须要把目前的所有业务代码进行重构才能保证在新的容器上稳定运行呢？我们的上层所有基础设施是否需要重新开发？我们怎么样快速复用我们的强大的前端生态保证我们的开发效率？任何软件工程遇到的问题都可以通过增加一个中间层来解决，我们通过 Rax.js 等研发框架，抹平了不同容器的差异，向上提供了同一套 DSL 给开发者，实现 “Write once, run everywhere”。

当然，标准化也是未来的趋势，标准化的流程可以使未来各种新的方案无缝衔接。提到标准，前端开发者自然会想到 W3C，各种容器各种端，最终会殊途同归，拥抱 W3C 标准，向标准化迈出一大步。

机遇与挑战

无论方案怎么变，我们无非是想要在性能、体验、研发效率以及渲染一致性这几个纬度中找到一个最佳的平衡点。在跨端的浪潮中前端开发者如何找准方向，以及将会遇到怎么样的机遇与挑战呢？

欢迎关注第十五届D2前端技术论坛跨端技术专场，我们将 邀请一线技术专家，为各位带来有关跨端研发解决方案的新思路、新进展、新挑战，结合真实业务场景共同剖析跨端研发提效、性能优化的最佳实践。

以全球 Web 角度谈前端性能的更新与趋势

Palances Liao / Google 资深 Web 技术专家

前端性能一直以来都是一个艰深的话题，除了各家都有自己不同的量测标准之外，怎样取得更精确的真实用户性能数据及通过工具的辅佐让我们更快速的调试成为了性能优化的一大难点。本专题会注重在 Google 如何定义性能指标，采集及提供优化性能的工具链如何帮助所有开发者快速调优前端性能，带来 Google 的最新研究。

盒马中后台跨端方案探索

孙伟伟（景庄） / 阿里巴巴前端技术专家

实体零售数字化过程中，盒马对人货场进行了全新的重构，在多元的业态和作业场景中，传统中后台的体验边界也进一步被延展，前端不再单一面向单一类型设备进行开发与交付，而是需要触及到 TVPCPadPhonePOSRFWatch 等更多的智能设备。在盒马，我们通过构建多端体验产品 Hippo 去解决新零售科技场景下的多端内容交付与体验一体化的问题，本次分享主要介绍盒马的中后台跨端探索过程，包括多端统一的设计体系，可跨设备复用的组件架构，以及支持跨端协同的应用架构。

跨端的另一种思路

佘锦鑫（当轩） / 阿里巴巴前端技术专家

Write Once, Run Everywhere 是诸多跨端方案的最终理想，然而理想和现实往往存在差距，跨端方案本身在带来提效的同时也伴随着 相应 的成本。 本次分享主要介绍从场景出发，以 Flutter 和 Web 的逻辑跨端为例，介绍除 Write Once, Run Everywhere 之外的另一种思路。

关注 「Alibaba F2E」

把握阿里巴巴前端新动向