跨平台技术&&混合开发
一、跨平台开发方案的三个时代
根据其原理，主要分为三类：
- H5+原生（Cordova、Ionic、微信小程序）
- JavaScript开发+原生渲染 （React Native、Weex、快应用）
- 自绘UI+原生(QT for mobile、Flutter)
根据实现方式的不同，业内常见的观点是将主流的跨平台方案划分为三个时代。
- Web 容器时代：基于 Web 相关技术通过浏览器组件来实现界面及功能，典型的框架包括 Cordova(PhoneGap)、Ionic 和微信小程序。
- 泛 Web 容器时代：采用类 Web 标准进行开发，但在运行时把绘制和渲染交由原生系统接管的技术，代表框架有 React Native、Weex 和快应用，广义的还包括天猫的 Virtual View 等。
- 自绘引擎时代：自带渲染引擎，客户端仅提供一块画布即可获得从业务逻辑到功能呈现的多端高度一致的渲染体验。Flutter，是为数不多的代表。
Web 时代的方案，主要采用的是原生应用内嵌浏览器控件 WebView（iOS 为 UIWebView 或 WKWebView，Android 为 WebView）的方式进行 HTML5 页面渲染，并定义 HTML5 与原生代码交互协议，将部分原生系统能力暴露给 HTML5，从而扩展 HTML5 的边界。这类交互协议，就是我们通常说的 JS Bridge（桥）。
一个完整 HTML5 页面的展示要经历浏览器控件的加载、解析和渲染三大过程，性能消耗要比原生开发增加 N 个数量级。
接下来，我以加载过程为例，和你说明这个过程的复杂性。
- 浏览器控件加载 HTML5 页面的 HTML 主文档；
- 加载过程中遇到外部 CSS 文件，浏览器另外发出一个请求，来获取 CSS 文件；
- 遇到图片资源，浏览器也会另外发出一个请求，来获取图片资源。这是异步请求，并不会影响 HTML 文档的加载。
- 加载过程中遇到 JavaScript 文件，由于 JavaScript 代码可能会修改 DOM 树，因此 HTML 文档会挂起渲染（加载解析渲染同步）的线程，直到 JavaScript 文件加载解析并执行完毕，才可以恢复 HTML 文档的渲染线程。
- JavaScript 代码中有用到 CSS 文件中的属性样式，于是阻塞，等待 CSS 加载完毕才能恢复执行。
而这，只是完成 HTML5 页面渲染的最基础的加载过程。加载、解析和渲染这三个过程在实际运行时又不是完全独立的，还会有交叉。也就是说，会存在一边加载，一边解析，一边渲染的现象。这，就使得页面的展示并不像想象中那么容易。
二、跨平台的优劣势
跨平台方案：
1、ReactNative
React Native 希望开发者能够在性能、展示、交互能力和迭代交付效率之间做到平衡。
它在 Web 容器方案的基础上，优化了加载、解析和渲染这三大过程，以相对简单的方式支持了构建移动端页面必要的 Web 标准，保证了便捷的前端开发体验；并且在保留基本渲染能力的基础上，用原生自带的 UI 组件实现代替了核心的渲染引擎，从而保证了良好的渲染性能。
但是，由于 React Native 的技术方案所限，使用原生控件承载界面渲染，在牺牲了部分 Web 标准灵活性的同时，固然解决了不少性能问题，但也引入了新的问题：除开通过 JavaScript 虚拟机进行原生接口的调用，而带来的通信低效不谈，由于框架本身不负责渲染，而是由原生代理，因此我们还需要面对大量平台相关的逻辑。
而随着系统版本和 API 的变化，我们还需要处理不同平台的原生控件渲染能力上的差异，修复各类怪异的 Bug，甚至还需要在原生系统上打各类补丁。
2、Flutter
https://flutter.dev/docs/development/tools/sdk/releases?tab=macos
Flutter提供了一整套从底层渲染逻辑到上层开发语言的完整解决方案：视图渲染完全闭环在其框架内部，不依赖于底层操作系统提供的任何组件，从根本上保证了视图渲染在 Android 和 iOS 上的高度一致性；
Flutter 的开发语言 Dart，是 Google 专门为（大）前端开发量身打造的专属语言，借助于先进的工具链和编译器，成为了少数同时支持 JIT 和 AOT 的语言之一，开发期调试效率高，发布期运行速度快、执行性能好，在代码执行效率上可以媲美原生 App。
而这与 React Native 所用的只能解释执行的 JavaScript，又拉开了性能差距。
Flutter学习成本高，且不支持热更新。
