移动端跨平台开发方案的演进

天之衡

从 Android、iOS 推出至今，已有十几年，移动端的开发技术也在不断发展，最开始的时候，都是使用原生开发，但却有一个明显的痛点，就是相同的功能需要在不同的平台上都实现一遍，所以就有了一个很迫切的需求，能否只需要写一次代码，就可以在各个端都运行？
所以从本质上讲，跨平台开发是为了增加业务代码的复用率，减少因为要适配多个平台带来的工作量，从而降低开发成本。在提高业务专注度的同时，能够为用户提供一致的用户体验。用一个词来概括这些好处的话，就是“多快好省”。
跨平台开发方案的三个时代根据实现方式的不同，业内常见的观点是将主流的跨平台方案划分为三个时代。

• Web 容器时代：
  基于 Web 相关技术通过浏览器组件来实现界面及功能，典型的框架包括 Cordova(PhoneGap)、Ionic 和微信小程序。
  
• 泛 Web 容器时代：
  采用类 Web 标准进行开发，但在运行时把绘制和渲染交由原生系统接管的技术，代表框架有 React Native、Weex 和快应用，广义的还包括天猫的 Virtual View 等。
  
• 自绘引擎时代：
  自带渲染引擎，客户端仅提供一块画布即可获得从业务逻辑到功能呈现的多端高度一致的渲染体验。Flutter，是为数不多的代表。
  

Web 容器时代

Web 时代的方案，主要采用的是原生应用内嵌浏览器控件 WebView的方式进行 HTML5 页面渲染，并定义 HTML5 与原生代码交互协议，将部分原生系统能力暴露给 HTML5，从而扩展 HTML5 的边界。这类交互协议，就是我们通常说的 JS Bridge。
这种开发模式既有原生应用代码又有 Web 应用代码，因此又被称为 Hybrid 开发模式。由于 HTML5 代码只需要开发一次，就能同时在多个系统运行，因此大大降低了开发成本。由于采用了 Web 开发技术，社区和资源非常丰富，开发效率也很高。但一个完整 HTML5 页面的展示要经历浏览器控件的加载、解析和渲染三大过程，性能消耗要比原生开发增加 N 个数量级。

泛 Web 容器时代

虽然 Web 容器方案具有生态繁荣、开发体验友好、生产效率高、跨平台兼容性强等优势，但它最大的问题在于承载着大量 Web 标准的 Web 容器过于笨重，以至于性能和体验都达不到与原生同样的水准，在复杂交互和动画上较难实现出优良的用户体验。而在实际的产品功能研发中，我们通常只会用到 Web 标准中很小的一部分。面对这样的现实，我们很快就想到：能否对笨重的 Web 容器进行功能裁剪，在仅保留必要的 Web 标准和渲染能力的基础上，使得友好的开发体验与稳定的渲染性能保持一个平衡？
答案当然是可以。
泛 Web 容器时代的解决方案优化了 Web 容器时代的加载、解析和渲染这三大过程，把影响它们独立运行的 Web 标准进行了裁剪，以相对简单的方式支持了构建移动端页面必要的 Web 标准（如 Flexbox 等），也保证了便捷的前端开发体验；同时，这个时代的解决方案基本上完全放弃了浏览器控件渲染，而是采用原生自带的 UI 组件实现代替了核心的渲染引擎，仅保持必要的基本控件渲染能力，从而使得渲染过程更加简化，也保证了良好的渲染性能。
也就是说，在泛 Web 容器时代，我们仍然采用前端友好的 JavaScript 进行开发，整体加载、渲染机制大大简化，并且由原生接管绘制，即将原生系统作为渲染的后端，为依托于 JavaScript 虚拟机的 JavaScript 代码提供所需要的 UI 控件的实体。这，也是现在绝大部分跨平台框架的思路，而 React Native 和 Weex 就是其中的佼佼者。

自绘引擎时代—Flutter

泛 Web 容器时代使用原生控件承载界面渲染，固然解决了不少性能问题，但同时也带来了新的问题。抛开框架本身需要处理大量平台相关的逻辑外，随着系统版本变化和 API 的变化，我们还需要处理不同平台的原生控件渲染能力差异，修复各类奇奇怪怪的 Bug。始终需要 Follow Native 的思维方式，就使得泛 Web 容器框架的跨平台特性被大打折扣。
而这一时期的代表 Flutter 则开辟了一种全新的思路，即从头到尾重写一套跨平台的 UI 框架，包括渲染逻辑，甚至是开发语言。

• 渲染引擎依靠跨平台的 Skia 图形库来实现，Skia 引擎会将使用 Dart 构建的抽象的视图结构数据加工成 GPU 数据，交由 OpenGL 最终提供给 GPU 渲染，至此完成渲染闭环，因此可以在最大程度上保证一款应用在不同平台、不同设备上的体验一致性。
  
• 而开发语言选用的是同时支持 JIT（Just-in-Time，即时编译）和 AOT（Ahead-of-Time，预编译）的 Dart，不仅保证了开发效率，更提升了执行效率（比使用 JavaScript 开发的泛 Web 容器方案要高得多）。
  
  
  
  
  

现在跨平台方案有了新的发展方向，就是 Flutter。
Flutter 开辟了一种全新的思路，利用 Dart 语言，同时支持 JIT 和 AOT 两种编译方式的特性，在不同场景下使用不同的编译方式，达到最高效的开发和运行体验。
在 Debug 模式下，为了保证开发体验，采用 JIT 这种动态编译的方式，将代码运行在 Dart 虚拟机上，使得我们编写的代码可以实时更新，实现 HotReload 的特性，提升开发体验。
而在 Release 模式下，又需要保证运行速度和渲染流程度，则会采用 AOT 的编译方式，将代码直接编译成各自平台的 Native 代码，以此提高使用体验。
在 UI 渲染方面， Flutter 的渲染不依赖于平台，基于自带的 Skia 渲染引擎 ，构建了一套完整的跨平台 UI 渲染框架；在和平台交互方面，Flutter 提供了 Platform Channel 的通道，可以方便的和 Native 交互。可以说是 Google 融合多种技术才有的产物，也是跨平台方案发展的必然产物。
除此之外，一个好的技术，还需要有完善的文档去让人学习，有专业的人去维护，让技术不断发展，而在这方面，Flutter 即有完善的文档，也有 Google 团队的维护。因此 Flutter 肯定会更好的发展。
经过上面的介绍，以跨平台作为 X 轴，以性能作为 Y 轴，就可以得出如下的图：

Flutter 在跨平台和性能上都是比其他方案要好。
Flutter：为未来而生

Flutter 不仅是一个跨平台的 UI 框架，也是 Google 的新一代操作系统 Fuchsia 的 UI 框架。
Fuchsia 是 Google 开发的下一代操作系统。和以前 Google 开发的操作系统，如基于 Linux 内核的 Chrome OS 和 Android 等不同，Fuchsia 基于新的名为 Zircon 的微内核， Fuchsia 的设计目标之一是可运行在众多的设备上，包括汽车的娱乐媒体系统和嵌入式设备，如红绿灯、数字手表、智能手机、平板电脑与个人计算机。
根据 Bloomberg 2018 年 7 月 19 号的一篇文章，Fuchsia 团队计划在 3 年内首先将 Fuchsia OS 用于智能设备，5 年内将 Fuchsia OS 搭载在智能手机和个人计算机上。在 2018 年 10 月，有报道称 Google Home Hub 将搭载 Fuchsia OS，代号为 Astro ，可见 Fuchsia OS 离我们应该不远了.
所以使用 Flutter 开发，不仅可以运行在 Android 和 iOS 上，也可以运行在 Fuchsia 上，不仅可以用于现在，也可以用于未来。
（摘自极客时间，掘金）。

来源：https://www.jianshu.com/p/b524b360b55f
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！