React Native 0.64 新变化 & 再聊跨端技术

<aside> 💡 简单谈一谈跨端技术的现状、变化和未来，集中讨论下其在渲染层面上的回顾与展望。

</aside>

一些想说的

Flutter 最近也出了 2.0 版本，但大家可能觉得变化不大，而且社区的讨论主要围绕着 Dart 的空类型，可是我也看到了 Flutter 对于目前它的最弱项——对周边能力的支持做出努力。可以看出在未来，Flutter 作为主流跨平台开发潜力无限。

而作为老牌 Hybrid 框架，React Native 也逐渐要面临新的变革：

React 团队目前正朝着 CM 模式进行努力，这是一个 UI 框架的一个变革，因为像是 Vue、Angular 等 UI 框架，他们解决的大部分还是开发者本身的问题，只是为了赋能开发流程本身而存在，而目前 React 在 CM 的方向意味着终于能有一个 UI 框架能够去注重用户的体验了。

React Native 自从 0.6x 以来，就开始着力于对原先较为低效的线程模型进行重构，并在 UI 渲染、JS 引擎和原生模块加载进行大刀阔斧的变革。这个方向从19年到现在仍然在进行着，而在即将到来的 0.64 版本中，这些变革即将迎来终章。而就算完成了这些变革，React Native 仍然将处于 0.x 版本下，对于这些变革产生的一系列问题的解决，将也会长期困扰整个框架的开发。

我们再回到跨端技术本身上来谈谈：

跨端技术的核心问题就是如何使多个平台达到一致性的 UI / 逻辑 / 体验。而这本身就是个伪命题，因为不可能存在完全一致的体验，我们在开发跨端框架的过程中，要注重的是尽量抹平这些差异。

UI 渲染的两种方案：

采用统一渲染引擎，由设备 GPU 绘制页面，类似于 Unity 等一众游戏引擎，优点：页面一致性几乎完全保证、事件绑定解决；缺点：引擎需要初始化，预热通常较慢。安装包体积通常较大，因为封装了强大的渲染引擎。渲染引擎通常着力于压榨 GPU 性能，会使移动端设备耗电较快。
使用原生组件拼接，通过 DSL 中间层对原生组件样式和布局进行修改，优点：页面渲染效率高，TTI（用户可交互时间）较快，安装包体积相对较小。缺点：需要花大量时间抹平各平台差异，比如事件绑定问题、表现略差的页面一致性（最经典的就是阴影、圆角和 scroll 体验问题），对于用户体验会略有影响。

而 UI 渲染是所有人最关切的东西，所以大家通常都觉得像是 mini program、Flutter、Web 等这种统一或半统一渲染引擎的方案会是未来，而随之带来的引擎体积和预热似乎可以在他们所构想的场景中可以忽略。我个人可能觉得，如果作为个人开发者，对于 Flutter 可能不会太感冒，因为它带来的周边问题对于一个应用要经历最长的生命周期——启动周期是非常致命的。

比如一个新的 App，在产品角度来讲，最重要的是“冷启动”（此冷启动非彼冷启动），而冷启动是触达链路的最低层，触达链路如果有一个地方出现意外，很容易导致用户直接放弃 “从认识、到接触” 整个事务流程，而 Flutter 巨大安装包和较为缓慢的预热，会造成“冷启动”成本过高，而冷启动成本过高的后果就是用户很容易去放弃完成这个事务。

应用本身的性能和表现一致性往往并不是用户最有欲望去关心的，而是开发者或团体为了提升开发效率进行努力（有人会说：但长期来讲，提升开发效率是为了优化用户体验呀。其实这就像是：老师说，如果我能快速给你们批作业，你们一定能考上好大学。显然提高开发效率这本不是提升用户体验的充分必要条件，开发效率的提升带来的是开发成本的降低，一个是成本，一个是体验，差距已经很明显了吧。），所以这就目前造成了用户和开发者的认知和目标具有偏差的原因。

这可能是我对 Flutter 和 Game Engine App 有一种莫名的偏见的原因**（其实也不是偏见，这些厉害关系一般纯技术的开发者也很难去注意到的）**，因为如果你将这些厉害关系讲给 PM / 个人开发者，他们是很难接受去全面去使用这种东西的（除非是纯跟风）。技术选型肯定不能光考虑技术团队的需要，去对整个业务进行一定尺度的考量也是很有必要的。

当然，如果是那种有极其完善的触达方案，而且该方案和方法论经过业界数年检验，项目立项时对于 App 本身的冷启动并不感冒的话，这样的开发者或团队去使用这东西完全没啥问题。

统一渲染引擎说完了，那我们再疯狂吐槽下类似于 React Native / Weex / Taro / Rax / NativeScirpt 这样的原生组件布局渲染（实际上也不是吐槽，因为我这个人在表达意见之前，尽可能会从一些别人难以注意的角度，把所有厉害关系给讲得很明白），这种方案的精髓在于两个单词：Bridge + Compile ，桥接和编译。

为什么是 Bridge 而不是 Runtime？因为 Runtime 本身就分为：Bridge + VM，而且我们讨论的是渲染引擎，Bridge 本质上是为了抹平平台差异而存在的。而 Compile 过程通常也是为了抹平平台差异而存在的，而两者的关系举个不恰当的例子，就是 JIT 和 AOT 的关系（笑）———都是为了一个目的，但发生作用的时机是不同的。