简介： 面对多种多样的跨端诉求，有哪些跨端计划？跨端的实质是什么？作为业务技术开发者，应该怎么做？本文分享阿里巴巴 ICBU 技术部在跨端开发上的一些思考，介绍了以后支流的跨端计划，以及跨端开发的教训心得。

跨端

Write once, run everywhere。

咱们都据说过这句经典的宣传用语，起初咱们都晓得，没有什么货色是能够真正 run everywhere 的，充其量也只能做到 debug everywhere。

而当咱们议论一次编写多端运行时，显然不可能真的指跨所有所有端，大多数状况下你不会须要在电脑和手环上同步开发一个性能。

• 跨 PC 和无线端。
• 跨多 Native 平台：例如跨 Android 和 iOS，甚至跨 Windows。
• 跨投放 APP：随着超级 APP 越来越多，很多业务须要在多个 APP 中投放同一个页面。
• 跨 Web 和 APP：Web 在很多状况下依然是不可避免的，咱们的页面可能须要分享、SEO 或者投放到 M 站上等等，这时候就须要同时能在 Web 和 APP 内运行。
• 跨 Web、多小程序、QuickApp 等：其实原本相似跨 APP，然而奈何小程序自身是各家管制的关闭生态，故而有了开发一次适配到多种关闭生态的诉求。
• 其余端的跨端诉求：例如跨 POS 机，手表等。

与咱们多种多样的跨端诉求绝对应的，是百花齐放的跨端计划。

百花齐放的跨端计划

以 Web 为根底的 H5 Hybrid 计划

这类计划最为间接，简略来说就是用网页来跨端。因为咱们绝大多数端上（甚至包含关闭的小程序生态）都反对 Webview，所以只有开发网页而后投放到多个端即可，在桌面端对应的计划就是 Electron。

为什么不间接全用 Web？

从开发成本低、规范对立、生态凋敝上来说，H5 Hybrid 计划根本是不二之选。然而这种计划难以避免在性能和体验上存在差距。Web 的生态凋敝来自于其良好的历史兼容性，也意味着惨重的历史包袱。

• W3C 规范作为凋谢技术标准，历史包袱多，逻辑简单。
• Web 规范在设计上不是 Design for Performance 的，导致很多中央难以进一步改善，例如 JS 执行和 Layout、渲染互斥无奈并行，导致过长的 JS 执行工作会执行失常的渲染导致卡顿。
• Web 的标准化在推动上也比较慢，新的能力可能要比拟长的工夫能力应用。

React-Native/Weex 类计划

在挪动平台上尤其是晚期 WebView 的性能体验十分蹩脚，后面咱们也提到这种差距次要来自于 Web 生态自身惨重的历史累赘。

而 React-Native/Weex 这类计划通过尽可能的舍短取长，通过联合 Web 的生态和 Native 的组件，让 JS 执行代码后用 Native 的组件进行渲染。因为摈弃了 Web 的历史包袱，这类计划能够做一些大刀阔斧的改变。

例如 RN 就如下图中，把 JS 执行、布局（Yoga）和渲染（Native 组件）放在三个过程离开执行，防止了 JS 执行简单工作时界面卡顿。通过摈弃 CSS 中的大量规范，只反对局部 flex 布局能力来缩小布局和渲染的复杂度。

这种计划同样存在一些缺点：

• iOS/Android 双端自身不统一的组件和布局机制，让双端一致性难以失去保障。
• 依赖于 Native 机制也让一些 CSS 属性实现起来比拟艰难，例如老大难的 z-index 问题。

而最麻烦的一点在于，这套计划意味着十分高的保护反对老本。

• 借用了 Web 的生态但并不齐全是 Web 生态，很多中央不统一，最常见的吐槽就是习用的 CSS 布局形式无奈应用。
• 相比于浏览器新增一个传感器 API 都要配套欠缺的 devtool，这类计划大部分状况下的开发体验保障能够说是刀耕火种（下图为 Chrome 的方向传感器 API 的 devtool）。

在 WebView 性能差距逐步放大的明天，保护这一套简单计划的 ROI 是否值得，须要依据咱们场景的具体诉求考量。

Flutter

Flutter 要解决的问题和下面的计划不同，齐全不打算持续在 Web 生态上借力，从设计之初也并没有把 Web 生态思考进去。相比于 RN 依赖 Native View 渲染，Flutter 则是自绘的组件，间接通过 Skia 绘制到屏幕上。

因为能够齐全施展 GPU 的能力，也不须要去 Native 绕一圈。Flutter 实践上能做到更好的性能和两端一致性，这一意味着实践上将来可能基于 Flutter 的 JS 动态化计划可能在款式上反对的比 WEEX 更好。

从前端的视角看依然更像是一个 Native 开发计划而非跨端计划（尽管其实是跨 Android/iOS 的）。目前最次要的问题是 Flutter for Web 从技术原理上来说离生产可用可能还十分边远。除此之外动态化能力的的确也会让局部场景不实用。

研发框架 for 小程序

小程序是被发明进去的问题，各家小程序出于商业上的考量被动在 Web 生态的根底上结构了绝对关闭的生态。导致和 Web 生态心心相印。然而有多端小程序投放，或者同时投放小程序和 Web 端的场景难以承受应用。

因为小程序的端关闭且不受控，要解决小程序的跨端问题往往只能从研发框架层面登程。

编译时计划

比拟出名的编译时计划是 Taro，大抵的原理能够解释为将 JSX 编译到小程序的 WXML/WXSS/JS 上，而这类框架的实现原理其实并非真的是一个 React 或者类 React 框架，而是把看起来像是 JSX 的模板通过动态编译的形式翻译成小程序本身的模板。

这样做的限度非常明显，那就是 JSX 是 JavaScript 的拓展语言（React Blog 写的是 is a syntax extension to JavaScript），而小程序所采纳的 WXML 却是一个表达能力十分受限的模板语言，咱们不可能实现从一个通用编程语言到模板语言的编译。

而动态编译类框架为了做到这一点，采取的形式就是限度开发者的写法，这也是为什么 taro 对 JSX 的写法做出了诸多限度。这一点间接导致了无穷尽的保护老本和重大受损的开发体验，而后 taro/next 也转向了运行时计划 + 动态编译优化的联合。

运行时计划

不谦虚的说，针对小程序的运行时计划应该是最早我在写下 remax 第一个 issue 时 [1] 提出的。

通过 React Reconciler（相似于 Rax Driver）咱们能够让运行在小程序容器中的 React 不去间接操作 DOM，而是把操作的数据通过 setData 传递给小程序的 View 层映射到最初的界面上。

尽管 Remax、Rax 运行时、Taro Next 等几种计划不尽相同，然而思路大同小异，就是利用小程序模板肯定水平上的动态化能力 + 类 React 框架的 VirtualDOM 来进行渲染。当然这种做法绝对于小程序原生的渲染形式存在肯定的性能损耗。

remax 的支付宝端性能测试

在局部场景下，这种损耗是值得的。这些运行时框架也都在陆续通过容许关掉编译产生的模板中的不必的属性、局部动态编译、虚构列表等形式来改良性能。

当然了，最初内嵌 Webview 依然是一个计划。

作为业务技术团队，咱们该做什么

下面介绍的都是针对某些具体的场景的一些解决方案，然而对于业务技术团队来说，跨端的实质是提效。针对新的变动提出新的计划是一方面，更重要的如何让这种提效真的长治久安，让咱们的提效不会变成从一个新计划跳到另外一个新计划。

让咱们从新看下面这张图，能够确定的是，跨端的诉求和与之对应的计划依然会处于频繁的变动中，也不会呈现一个解决所有跨端问题的计划。而其中绝对不变的局部是值得咱们为了长治久安必须要投入的。

WebView & H5 Hybrid

WebView 可能是泛滥容器中最为非凡的一个，尽管很难满足局部场景对于性能和体验的极致要求，然而会是最稳固、长期存在且失去反对的计划。

从开发效率和将来长期的保护演变来看，在可能满足性能体验要求的前提下，Web 计划依然是最优先应该思考的。

同时，在 APP 的 WebView 容器上咱们能做更多的工作，例如通过容器来提供一些端内的能力，联合 Native 能力实现的并行数据加载，页面保活等等。

根底建设

无论采纳何种跨端计划，在哪个容器中，性能、稳定性、效力都是绕不开的三驾马车。

性能

对于不同的计划往往存在不同的性能计划，下面咱们也提到在小程序的运行时计划中就会有缩小编译模板产出的字段这样的优化。然而，其实除了这种特定计划的优化外，大部分优化伎俩是大同小异的：离线缓存、数据预取、快照、SSR、NSR 等等计划。

对于不同的端和容器，对于性能问题的度量和发现也应该是统一的，咱们须要对页面在不同端的性能到底如何有明确的感知和横向比照。

性能的端侧建设（端能力、具体到某一个端的性能测算计划、性能打点等）可能须要依据不同的端、不同的跨端计划而不同。但性能的根底建设（首屏规范、数据分析、根底优化能力）在跨端中应该是绝对稳固的。

在端侧能力方面，ICBU 晚期在 WEEX 性能优化时引入了并行加载的能力，通过 wh_prefetch 协定来应用容器的并行加载能力。而后在新的容器（WebView、浏览器）中，尽管底层能力存在差别，但依然辨认雷同的协定。

在数据采集和剖析方面，咱们通过对立跨端根底库，让不同端不同技术计划能够在同样的规范下剖析、度量和比照。

稳定性建设

在无线端咱们经常把性能 & 稳定性并称为“高可用”，稳定性次要涵盖的范畴包含灰度能力、业务监控、报警、谬误监控、白屏检测等等。

这些能力相比起来对具体端和跨端计划的依赖更少，除了在端侧的数据采集逻辑稍有区别外其余建设局部绝对也是比较稳定的。团体针对这些场景也存在一些跨端可用的计划、例如 iTrace 等。

工程基建

对于不同场景的跨端，尽管在计划上存在肯定的差别，然而咱们的工程基建是能够放弃对立

• 容器层提供对立的 API 和文档能力
• 对立的研发流程
• 研发工具提供对立的抓包、debug 能力等
• 统一的工具库等等

这样，当有新的容器或者计划呈现时，咱们只须要依照相应的能力进行对齐，就能让咱们下层的业务代码和开发体验维持绝对稳固的状态。

业务逻辑跨端

相对来说，咱们会发现在多种跨端计划的演变中，如何渲染、如何布局等 UI 层面的变动要远远大于业务逻辑层面。甚至是小程序和 Flutter，其大抵的开发范式都没有产生太大的扭转。例如 Flutter 开发范式和 React 十分类似，同样是申明式 UI，同样存在 VirtualDOM。

思考到 SEO 和性能等问题和 Flutter 自身基于 Skia 的渲染模式，Flutter for Web 在相当长一段时间内可能都不会是一个生产环境可用的计划。

而在对立了业务逻辑代码的组织形式后，咱们能够通过 Hooks for ALL 的计划让 Flutter 和 Web 端能够共享一份基于 Hooks 的业务逻辑代码。

有时候你不须要真的 run everywhere，可能进步效力、保持一致就曾经达到目标了。

视图层

目前来看视图层的跨端依然充斥了变数，在咱们的业务逻辑层跨端做的足够原子化后，兴许咱们局部交互逻辑不是特地重的视图层可能通过 DX + 绑定原子化逻辑 + 数据参数的形式笼罩更多的跨端场景。从而同时满足性能、效力方面的诉求。

然而对于通用场景的视图跨端，依然没有银弹。

总结

总体来说，跨端处于且将长期处于多计划并存且一直变动的状态。除了针对新的变动新的场景抉择或发明适合的计划，咱们更要做好这种动态变化中长治久安的局部：

• H5 Hybrid。
• 性能、稳定性、效力三驾马车的统一性和延续性。
• 在不强求 write once 的场景下，思考比 UI 跨端更简略的业务逻辑跨端。

作者：开发者小助手_LS
原文链接
本文为阿里云原创内容，未经容许不得转载