简介：面临多种多样的跨端诉求，有哪些跨端计划？跨端的素质是什么？做为营业手艺开发者，应该怎么做？本文分享阿里巴巴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 能否值得，需要按照我们场景的详细诉求考量。
FlutterFlutter 要处理的问题和上面的计划差别，完全不筹算继续在 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 HybridWebView 可能是浩瀚容器中最为特殊的一个，固然很难满足部门场景关于性能和体验的极致要求，但是会是最不变、持久存在且得到撑持的计划。
从开发效率和将来持久的维护演变来看，在可以满足性能体验要求的前提下，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
评论列表