Flutter:移动端跨平台技术演进之路

1. 导读

本文约4688字，阅读可能需要15分钟。

最早的跨平台开发(摘自《Apache Cordova移动应用开发实战》王亚飞，王洪飞编著)

从广义上来说，跨平台技术早于移动端的出现。因此，本文标题前面也加上了一个定语：“移动端”。而由上图也可窥见一二：移动端跨平台技术几乎和移动端本身的历史一样长。跨平台技术之所以生命力如此强大，个人认为有以下几个原因：

1. 开发效率 : 这也是跨平台技术出现的初衷，理想状态下，一次开发，多端运行，组件复用，提升效率。

• 对于管理者，跨平台可以降低用人成本，避免了同时养两个（Android/iOS）开发团队的现状

• 对于开发者，跨平台可以降低学习成本，只需要了解一套框架，就可以实现双端开发，提升了自我价值

• 业务价值 : 跨平台开发成本更低，适合产品的快速验证，待功能稳定后再进行性能体验上的优化

• 二级生态 : 举一个例子，JVM在操作系统上建立了自己的二级生态，所有的Java开发者只需要面向JVM编程和优化，可以忽视操作系统的存在。在原生、底层的平台上做一层封装，以很小的性能损失为代价，为开发者带来巨大的效率提升，这在软件工业是屡见不鲜的。二级生态有重要的战略意义，掌握了二级生态，就掌握了话语权和影响力。所以Facebook和Google都在发力。

• 平台能力 : 乘上第三点，跨平台还有一个好处就是拥有了自己的生态就可以开放自己的能力，制定游戏规则让其他开发者参与，典型有小程序（微信/QQ/支付宝）、快应用等

• 跨平台好处颇多，但挑战也不少，主要集中在以下四个方面：

  1. 研发效率

  • 工具支持程度：补全、提示、构建管理等

  • Debug是否方便，错误日志是否详细

  • 文档完备、项目活跃

  • 隐藏平台差异，如React Native需要大量桥接工作

  • 开发语言生态，js生态庞大，开发者众，Dart则名不见经传

  • 等等

• 动态化

• • iOS禁止，但国内平台普遍需要

• 多端一致性

• • Web方案无法还原体验

• 性能

• • Web方案UI绘制效率低，网络流量消耗高

  • 游戏引擎耗电严重，不能应用在普通应用开发中

  • SDK引入导致的安装包增量

  2. 历史行程

  在过去的十多年间，主流的(不考虑一些小众、没有取得成功的方案)移动端跨平台技术经历了三次变革：

  • Hybrid，代表有：Ionic/Cordova

  • OEM Wrapper，代表有：React Native/Weex

  • 自渲染，代表有：Flutter

  从时间上看，这三种方案不是孤立的，既有对前人不足之处的改进（如UI绘制策略），也有对优秀思想的继承（如React的思想）。如果站在更高的高度上，我们会看到这些方案并不是在移动端独立演进的。在移动端普及之前，PC端已经积累了很多成熟的方案，对于移动端的探索起到了指导作用，仔细比较一下会发现每一种方案都能找到已有方案的影子，只不过结合了移动端的特点做了定制。无论哪种跨平台方案，都要回答两个问题：

  1. UI如何绘制

  2. 逻辑（包括用户交互的逻辑和与宿主系统通讯的逻辑）如何响应

  对于这两个问题，Hybrid给出的答案是webview+js，OEM Wrapper给出的是VirtualDOM转Native组件+js，自渲染（Flutter）给出的答案是Skia+Dart。下文开始详述。

  2.1. Hybrid

  

  架构图

  

  Hybrid是客户端跨平台技术的第一个阶段，核心原理是
  

  将原生的接口封装后暴露给 JavaScript，可以运行在系统自带的 WebView中或者其他内核中。这种方案在上文提到的评价体系里表现如下：

  1. 开发效率

  • 对前端开发者友好，背靠前端庞大的JavaScript生态

  • 涉及到Native调用的部分不可避免要熟悉Android/iOS

  • 能力受限于桥接层，扩展性弱

  • 在移动端开发，调试和错误日志并不是很友好

• 动态化

• • Web天生自带动态能力

• 多端一致性

• • 浏览器内核的渲染独立于系统组件，无法保证原生体验

  • 涉及宿主的问题，需要开发者处理，做不