在《The Pragmatic Programmer》（中文翻译为《程序员修炼之道》）中，作者提了一个 DRY(Don’t Repeat Yourself)原则，主要指在程序设计以及计算中避免重复代码，因为这样会降低灵活性、简洁性。 把一切重复的代码抽象出来复用，当需要修改的时候只需要修改一次。 这里的复用有如下一些级别：函数级复用、对象级复用、模块级复用、类库级复用、框架级复用。 咱们今天聊的跨端是更高层面的复用，是端的复用。
现实中我们常见的工作方式是安卓的同学写安卓，iOS 的同学写 iOS，前端写 Web，小程序，H5 等等。 随着整体技术的进步，前端技术的发展，大前端的兴起，跨端实现越来多了，一些跨端的框架层出不穷。最终想要实现的跨端架构希望能做到：一次编写，多端运行
这里的端包括如下：
以上跨端的逻辑分为三个层面
应用运行在某个操作系统之上，操作系统位于硬件设备与用户之间，是两者沟通的桥梁。不同的硬件有不同的架构和指令集，其对应也会有不同的操作系统。不同的操作系统其对应的执行程序结构不同，如 Windwos 下的 exe 结尾的程序不能在 Mac 下执行。这就是所谓的平台。
那么如何跨平台？
跨平台也是跨端的一部分，我们常见的跨平台应用，如浏览器，它所实现的跨平台是指运行在浏览器中的网页是跨平台的，而浏览器本身并不会跨平台，浏览器的生产厂商根据不同的平台，不同的操作系统分别实现了对应的版本，在应用层面抹平了平台和操作系统的差异，实现了跨端的目的。
浏览器在实现过程中会提供一个容器给到开发者，屏蔽平台差异，提供统一的 API 接口，让一份代码可以在不同的平台运行。 与浏览器类似的还有 Docker、JVM、Node 等。
在浏览器跨端的基础上，Electron 整合 Chromium 的渲染引擎、NodeJS 和用于调用系统本地功能的 API，使用 JavaScript，HTML 和 CSS 构建跨平台的桌面应用程序，其可构建出兼容 Mac、Windows 和 Linux 三个平台的应用程序。
在跨平台之外，我们还需要跨应用，如在不同的小程序、H5 之间，既然是应用，那就一定会包含界面，业务逻辑，如何只写一次业务逻辑，在不同的应用中执行，在代码重复层面追求更极致的体验，遵从 DRY 原则，让代码一次编写，多端运行。
我们在追求跨端的同时，也希望跨端的体验能趋近于原生的体验。
跨端架构的本质用稍微文艺一点的话来说就是：「世上本没有什么岁月静好，只不过是有人替你负重前行」
一个跨端的架构至少包含渲染、逻辑和原生能力支撑、端的构建方式。一般会通过实现自己的容器来抹平（或者兼容）端的差异。
这个容器一般会提供两个能力：一个是渲染，另一个逻辑和原生能力支撑。 看我们常见的几种方案：
浏览器自带跨端属性，通过各平台都有的浏览器，我们可以直接实现跨端，除了浏览器应用，我们也会把浏览器引擎嵌入到 APP 中，部分或全部使用浏览器渲染引擎，常见的如 Webkit、Blink 等。我们通过 Javascript 实现逻辑并且通过 JSBridge 调用 Native 的 API，透出的 API 需要应用在内部定制。我们一般用原生来实现要求高的界面，对于一些比较通用型，展示型的页面完全用 web 来实现，达到跨平台效果，各家的区别在于对于这块的定制和优化到了什么程度。
组成：渲染：WebView，逻辑：JS Engine，底层能力：JSBridge + 原生能力
优点：
缺点：
如：网易云音乐，腾讯 QQ 中的大部分运营功能
以 React Native 和 Weex 为代表的方案，通过结合 Web 的生态和 Native 的组件，尽可能地取长补短，让 JS 执行代码后用 Native 的组件进行渲染，实现了远超 webview 的效果。以 React Native 为例
组成：渲染：原生组件；逻辑：JS Engine + JSI；底层能力：原生组件；
优点：
缺点：
使用 RN 的 APP: Facebook、youtube、discord、QQ、百度等等 使用 Weex 的 APP: 淘宝、天猫、饿了么等
以 Flutter 为代表，Flutter 将代码编译成原生代码，并且直接在各个平台中使用高效渲染引擎 Skia 进行渲染，没有桥接，不调用平台相关控件。Flutter 没有直接借用原生能力去渲染组件，而是利用了更底层的渲染能力，自己去渲染组件。这种方式的链路会比 RN 的链路跟短，性能也会更好，同时在保证多端渲染一致性上效果更优。
组成：渲染：Skia；逻辑：Dart VM；底层能力：原生组件
优点：
缺点：
除了最开始的 Android 和 iOS 跨平台支持，最新已经开始支持 Web 和 MacOS，未来还会继续支持 Win 和 Linux 平台的。在 Web 场景下，目前 Flutter 只能说可以用，但是还有挺多需要优化的空间，比如编译后 Web 文件大小，特定场景下的性能以及不同浏览器内核的兼容等等。
使用 Flutter 的应用：如钉钉（定制了较多的功能）、美团外卖、马蜂窝等
该方案提供自定义 DSL 静态编译转化成目标源代码，包括 iOS、Android，H5 以及中国特色的各小程序平台。主要包括 uni-app、taro、Chameleon、Rax 等等。但各家实现不同，支持的平台类型也不一致，以 uni-app 为例：
组成：渲染：混合渲染、weex原生渲染、webview渲染，小程序和 app-vue 页面属于混合渲染，app-nvue 页面全部是 weex 原生渲染，H5 全部为 webview 渲染；逻辑：JS Engine + VUE; 底层能力：原生组件、原生插件；
优点：
缺点：
我们要做到应用的跨端，在 PC 端相对好确定一些，以前端为主，客户端辅助实现部分前端薄弱的部分，如安装过程和一些和操作系统打交道或对性能要求比较高的部分。我们常用的 PC 端架构可以基于 Electron 、Tauri，在多平台客户端和 Web 端实现跨端。
在移动端，则更复杂一些，不仅要跨 iOS 和安卓这种操作系统级，还要跨微信小程序、支付宝小程序这种应用的衍生应用。下面我们聊聊一些有人在用的方案。
在考虑实际落地之前需要明确一下是在什么层面的跨端，最理想的是跨全端，即跨硬件平台，在 PC、移动端设备，另一种是分两种，大屏和小屏，大屏主要是针对 PC 端、小屏主要是针对移动端。
如果是跨全端，不仅仅要考虑技术实现，从产品、到设计都要考虑，产品要考虑针对不同的端的应用场景，设计要考虑不同的屏大小下的体验效果和交互方式。这里我们只考虑移动端的情况。
Qunar 方案的主要逻辑是基于 Qunar 已有的 RN 技术栈，已经解决了 iOS 和 Android 的跨端问题，在此条件下，其问题变成了如何将 RN 转换为 H5 和各小程序。业内没有现成的方案，只能曲线救国，分别处理：
Flutter 可以理解为使用 Dart 语言定义了一套和原生一样的图形系统，其底层使用和 Android 原生一样的 Skia 引擎，安卓下直接用系统引擎，苹果生态下用自带的 SKia，这样就完全避免了 RN 中 JS Core 和原生模块通信造成的各种开销。
Flutter 这种自实现的引擎能带来目前体验最好的两端一致性，同一套代码，在 Android 和 iOS 上执行，从业务逻辑到页面布局再到最终渲染，都是在 Flutter 内部完成，通过 Flutter 实现的功能，在不同系统手机上的呈现效果是高度一致的。
Flutter 在 Android 和 iOS 上对跨端的支持较好，现在也有较多的业务在用 Flutter 完成这两端的跨端。对于 H5 而言，2019 年 2 月 Flutter1.2 版本和后面 5 月发布的 1.5 版本都主要支持了 Web ，但是到现在为止，Flutter 在 Web 端目前只支持 Dart–>JS 的转换，以及 UI 层的对齐，在工程化和性能优化方面做的工作并不多。Google 官方对 Flutter Web 性能优化所做的事项还比较少，编译输出的页面存在较大的性能问题，主要体现在以下两方面：
在阿里钉钉，基于 Flutter 构建的跨四端研发框架 Dutter，自己解决了数据通信问题、实现了自己的组件库，目前核心组件可以做到四端兼容，具体可以见：钉钉 Flutter 跨四端方案设计与技术实践
这种反而在大厂是更常用的方案，其主要原因是大厂一般会有自己的框架团队，能够做比较多的定制，甚至有些把 Flutter 改吧改吧，自己实现一套，或者以容器化的方式实现自己的 Hybrid 方案。具体实现就不介绍了，这里主要介绍一下常用的一些性能优化的点，Hybrid 方案的性能优化的关键点就六个字：更早，更近、更快。
为什么标题中带一个 2022 呢？ 因为技术是不断演进的，是不断发展的，今年的方案不一定适用于明年，期望有更好的方案出现。
写了这么多，把跨端的问题粗略的过了一遍，给自己温习一下，也分享一下。
任何跨端都是有成本的，当你选择跨端的时候，需要想的第一件事情，是否有必要这么做？ROI 如何？
跨端的问题很多最终都需要回归到当前端来解决，特别是一些对性能，对底层要求比较高的问题往往要在端来解决。
整体来看，跨端技术选型需要考虑如下 4 个问题：
最后，祝大家国庆节快乐~
参考文档：