混合开发-选型-技术调研

结论

• Cordova/Ionic 仅适合小项目或集成简单页面到 apps
• React Native 天花板较低，对于交互和性能要求较高、需求复杂、需要长期快速迭代的项目优势不大。
• Flutter 起点比 RN 高，然而不成熟不适合商用。

主流混合开发方案

• Web UI + JSCore/V8/Other（PWA、Cordova、Ionic）
• Native UI + JSCore（React-Native、Weex）
• Native UI + AOT（Flutter）
• Native UI + WebUI + JSCore （小程序）

一开始 Hybrid 指的是使用 WebView 渲染页面、混合原生页面的开发模式，但是目前 Native UI + JSCore 等方案明显不属于此类，所以口头上经常把纯 Native 以外的都叫做混合开发。

但是 RN 官方并没有标榜为 Hybrid：
Build native mobile apps using JavaScript and React。

JSCore

JavaScriptCore is the built-in JavaScript engine for WebKit. It currently implements ​ECMAScript as in ​ECMA-262 specification.
一开始作为 Safari 的浏览器引擎，后来在 iOS 7 作为一个系统级 Framework 提供给开发者，活生生撑起了 RN 和 Weex 等跨平台方案。

浏览器 WebKit

当我们用小程序 IDE/其他模拟器运行 RN/小程序的时候基本都是使用的 PC 浏览器的引擎，和移动端的浏览器引擎很明显是不一样的，所以不要再说什么在模拟器上是没问题这种话了好吗

H5 页面渲染（Web UI）

• WebView 常见的渲染方式（WebKit）:
  HTML + CSS -> DOM Tree + CSSOM -> Render Tree -> Render Layer （Measure） -> GPU 渲染

WebKit 渲染流程

CSS Object Model 是 CSS 样式的映射，在结构上和 DOM 相似，提供了 API 让开发者动态获取和修改 CSS 样式。

CSSOM

Render Tree 描述可见的 DOM 内容，并将 CSSOM 的样式信息关联到节点上。

Render Tree

• Google 页面渲染和优化的相关文章

• CSS/JS 的加载和解析都会阻塞页面的渲染

• JS 直接操作 DOM 会引起 reflow/repaint：
  reflow (回流): 根据 Render Tree 布局(几何属性)，意味着元素的内容、结构、位置或尺寸发生了变化，需要重新计算样式和渲染树；
  repaint (重绘): 意味着元素发生的改变只影响了节点的一些样式（背景色，边框颜色，文字颜色等），只需要应用新样式绘制这个元素就可以了；
  reflow 回流的成本开销要高于 repaint 重绘，一个节点的回流往往回导致子节点以及同级节点的回流；

• React/Vue 用 Virtual DOM 算法去减少重复绘制不必要的 DOM：
  1、用 JavaScript 对象结构表示 DOM 树的结构 (Virtual DOM)，然后用根据 Virtual DOM 构建 DOM 树；
  2、当状态变更的时候，重新构造一棵新的 Virtual DOM。对比新旧的 Virtual DOM 树差异；
  3、把（2）的 Virtual DOM 树的差异应用到第一步构建的 DOM 树以触发渲染。
  两个树的完全的 diff 算法是一个时间复杂度为 O(n^3) 的问题。但是在前端当中，你很少会跨越层级地移动DOM元素。所以 Virtual DOM 只会对同一个层级的元素进行对比：

Virtual DOM diff

• 在具体的开发中，无限列表、路由切换和手势交互方面的问题是比较多的。
  web 端细粒度的手势检测已经不是问题，问题是通过手势检测带来的像素级动画会极大的降低帧率。

Cordova/H5 （Web UI + JSCore）

在内嵌的浏览器中运行界面和逻辑。

• 实现成本最低；
• 运行效率最差；
• 可能存在较多平台兼容问题且无太好解决办法。

React-Native （Native UI + JSCore）

• 使用 OEM Widgets 渲染出 Native 组件。但是也导致了相对于 React 能实现的布局，RN 仅支持 10%（CSS 子集）。
  在 iOS 上 RN 通过 addSubview() 去渲染 UI，参考文章。

• 将平台兼容问题完全交给 Native 层处理，也就是常说的要写两套代码。

• JSCore 的通信成为性能的瓶颈，在例如处理滑动回调时毫米级别的高频率的通信将导致性能问题。
  一是因为 Bridge 本身的通信成本问题，这一点 RN 使用 JSContex 避免。
  另一个则是因为 RN 的本身的渲染机制是做了节流的，防止 DOM 变化带来的复杂的高频次渲染。
  （这种频繁通信的需求在传统的 Hybrid 方案中并不常见）

• 架构上还存在诸如 ListView 长列表的性能问题。

React-Native

更多可见 Airbnb 的文章

Flutter

Flutter 使用 dart 语言：

• 实现了通过 AOT 编译成多个平台的本地代码，避免了 JSCore 通信频次问题；
• dart 语言的生态小。

并且 Flutter 通过将 Widgets 相关内容移动到程序包中并通过 Canvas 的方式绘制，不再使用平台的 OEM Widgets：

• 在跨平台的兼容方面较优，可以实现高度自定义而不受平台限制。
• APK 会相应增大；

参考闲鱼在 Flutter 的实践：

• 性能上，Flutter 页面和 Native 页面体验接近，甚至数据上看在一些低端机上 Flutter 会更流畅，人肉眼已经很难区别。
• Android 的 Apk 增加 8M，iOS 压缩包增加 16M。

Flutter

资料：
闲鱼掘金文章 & 技术文章
Alibaba 文章及 demo

小程序

基于 Web 且 UI 层与逻辑层分离，业务逻辑都跑在 JavaScript Context 中，UI 在单独的 WebView 上绘制。
可以参考官方人员的架构设计解析。

小程序架构

用户在屏幕点击某个按钮，开发者的逻辑层要处理一些事情，然后再通过setData引起界面变化，整个过程需要四次通信。对于一些强交互（例如拖动视频进度条）的场景，这样的处理流程会导致用户的操作很卡。
对于这种强交互的场景，我们引入了原生组件，这样用户和原生组件的交互可以节省两次通信。

原生组件

其他参考文章：
React: The Virtual DOM
Why Flutter doesn’t use OEM widgets
Performance Limitations of React Native and How to Overcome Them
React Native vs Real Native Apps