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

Hybrid是客户端跨平台技术的第一个阶段，核心原理是
将原生的接口封装后暴露给 JavaScript，可以运行在系统自带的 WebView中或者其他内核中。这种方案在上文提到的评价体系里表现如下：

1. 开发效率

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

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

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

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

2. 动态化

   • Web天生自带动态能力

3. 多端一致性

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

   • 涉及宿主的问题，需要开发者处理，做不到完全屏蔽

4. 性能

   • 受限于网络环境，比Native更加消耗流量

   • 受限于浏览器、系统平台特性

   • 渲染性能 ，Webview性能差

   • 特别指出:对于列表的支持差，移动端几乎全是列表（feed流）

评价：Hybrid是矛盾的结合体，HTML/CSS 过于复杂导致性能问题，但其实这正是 Web 最大的优势所在，因为 Web 最初的目的就是显示文档，如果你想显示丰富的图文排版，虽然 iOS/Android 都有富文本组件，但比起 CSS 差太远了，所以在很多 Native 应用中是不可避免要嵌 Web 的（比如很多运营活动的页面，存在周期短，开发时间短，样式丰富繁多，适合H5开发）。

既然Web强大的的绘制能力限制了其在移动端的性能，那么能不能对此进行优化? 这是一个很重要的问题，很多看起来无关的方案都是基于这种思想发源来的：

• React Native使用系统组件封装，可以认为是把原来的浏览器内核换成了一个简化版的内核：一个不能做物理渲染，只能转换成有限原生组件的内核。

• Flutter的 Engine 模块也可以认为是一个浏览器内核的角色！事实上Flutter的前身Sky就是打算基于一个精简的Chromium内核来实现跨平台。

大概到了2015年，经历了各种Hybrid方案割据混战长达数年后，Facebook推出了React Native，这种方案迎合了大前端的趋势，一经推出就备受关注。核心改变是抛弃了低效的浏览器内核渲染，转而使用自己的DSL生成中间格式，进而映射到对应的平台。
其实这个方案其实也算不上什么创举，在PC时代，The Standard Widget Toolkit采用的就是这种方案（当然要做到React Native这种水平，非Facebook级别的公司不能为也）：

React Native 在评价体系表现如下：

1. 开发效率

   • 在Web基础上引进了React等能力，符合前端大趋势

   • 版本变动频繁，需要开发者自己优化，工作量大

   • 与Native交互需要开发者自己支持，维护成本高

   • 文档不完善、调试信息、错误日志提示不够友好

2. 动态化

   • 可以支持

3. 多端一致性

   • 渲染成各自平台的组件，可以保证Native的体验

   • 由于渲染依赖原生控件，不同平台的控件需要单独维护，并且当系统更新时，社区控件可能会滞后

   • 其控件系统也会受到原生UI系统限制，例如，在Android中，手势冲突消歧规则是固定的，这在使用不同人写的控件嵌套时，手势冲突问题将会变得非常棘手

4. 性能

   • 稍差于Native，但远好于Hybrid

   • 渲染时需要JavaScript和原生之间通信，在有些场景如拖动可能会因为通信频繁导致卡顿

   • JavaScript为脚本语言，执行时需要JIT，执行效率和AOT代码仍有差距。

评价：使用类前端的语法，但又不在浏览器内核直接绘制，而是转成Native控件，交由系统绘制。这样既保留了前端这套开发体系，又最大限度保证了渲染的性能。咋一看，React Native解决了 Hybrid 技术的痛点：渲染性能，又充分发挥了Hybrid 的优势：前端技术栈。但就在2018年，Airbnb和Udacity相继宣布弃用React Native,Facebook也宣布要大规模重构React Native,导致其前景堪忧，比起React Native的美好愿景，其在开发过程中需要踩的坑更多，长期的维护成本也很高，反而降低了开发效率，此外，库的增量也不容忽视。

Flutter 在评价体系表现如下：

1. 开发效率

   • 开发工具完备，提供了VS Code（最流行的编辑器），Intellij IDEA 插件

   • Google背书，文档完备，社区较完备

   • Dart语言本身有上手成本，没有前端的生态，但Dart语言本身是及其优秀的

2. 动态化

   • 动态性不足，为了保证UI绘制性能，自绘UI系统一般都会采用AOT模式编译其发布包

   • 可能涉及安全政策，Flutter Release目前不支持

   • 国内开发者正在做积极探索

3. 多端一致性

   • 自绘制UI，提供了Material Design和Cupertino两种风格的Widget

4. 性能

   • 性能和Native绘制一样

评价：Flutter站在前人的肩膀上，取长（React的状态管理、Web的自绘制UI、React Native的HotReload等）补短（与Native通信的Channel机制、自渲染、完备的开发工具链），并且有Google作为作为支撑，在跨平台领域后发制人，是目前最被看好的方案。

关于Dart，在开发者踩了十几年坑之后，Google和Microsoft两大巨头似乎看清了需要一种新的、更现代、更适合UI开发的编程语言来重新建立秩序。

谷歌要推Dart，微软要推Rust，这两门语言的年龄比很多开发者的从业年龄都要小，大概是要以牺牲一代开发者为代价换取一个没有历史包袱（做梦）的新生态吧（手动狗头）。

在Framework层，有以下内容

• Foundation 底层库

• 负责UI绘制和交互处理的 Animation 、 Paint 等模块

• 基于上面的接口实现的基础组件 Widgets

• 基于组件实现的 Material 风格组件（Google推荐）和 Cupertino 风格组件（iOS风格）

在Engine层，有以下内容

• Skia 图形处理库

• Dart 运行时

• Text 文字排版引擎

这张图和Android自身的架构很像

这种设计符合Unix哲学的 正交性 原则（计算机网络中的OSI模型也是），可以很好地屏蔽每一个层的细节，接下来我们基于这个架构图讨论几个问题

• Flutter如何绘制UI

• 为什么选择Dart

• 如何和Native交互

• HotReload与动态化

在开始下文之前，需要介绍一下现代GUI框架的模型，无论是Web、PC、移动端、游戏开发，都是基于这种框架工作

• Widgets（控件，也叫 View Tree），它是用于描述用户界面原始数据的树状结构。通常这一层根本不关心绘制，它只关心用户对数据的操作。

• Render Tree，它是一种更为抽象的树状数据结构，一般来说它是和上一步的 View Tree结构相同，并且它不关心原始数据，只关心控件的布局和大小。通过这一步计算出控件布局后才能真正地确定控件的外观。

• Layer Tree 跟 Render Tree是相对应的，这一步会主动触发 Render Tree中每个元素的外观渲染，在已知控件大小和位置的情况下决定每个控件的真正外观。但 Layer Tree的树状结构不是和 Render Tree一一对应的，Layer Tree有可能因为 Layer合并优化导致一层的 Render Tree叶子节点最终只对应一个 Layer。

• 在已经决定好控件的大小位置以及长相后，剩下的工作就需要把这些东西组合起来显示到屏幕上。这一步原理比较简单，就是将前一步的 Layer合并成一张 Bitmap，这是一种最简单的图像存储形式。将 Bitmap光栅化后便可以提交给 GPU渲染。

比如Android开发都很熟悉的 measure layout draw 就和前三层吻合，有了原始数据还不够，屏幕只关心每个像素点的值，所以最后要进行一次光栅化，历史已经证明这种模型是目前来说相对高效的GUI方案。

有了以上背景，我们来看Flutter的UI绘制过程。

• GPU发出 Vsync 信号，Dart捕获后就开始一帧的绘制。

• Throttle: 用来做节流，防止短时间内重复调用，提高性能。

• Compositor: 这一步进行 Layer合成，决定某一块具体显示哪一个 Layer的数据，可以额外的计算开支。

• GL or Vulkan: 这一阶段过后得到的将是一份矢量图数据，在进行光栅化后提交给 GPU执行渲染即可。

官方解释：

• Developer productivity

  • JIT + AOT

  • Dart开发团队对于Flutter支持粒度很大

• Object-orientation

• Predictable, high performance

• Fast allocation.

其他声音：

• Dart 的性能更好，对高帧率下的视图数据计算很有帮助。

• 多生代无锁垃圾回收器，专门为UI框架中常见的大量Widgets对象创建和销毁优化

• Native Binding，在 Android上，v8的 Native Binding可以很好地实现，但是 iOS上的 JavaScriptCore不可以，所以如果使用 JavaScript，Flutter 基础框架的代码模式就很难统一了。而 Dart的 Native Binding可以很好地通过 Dart Lib实现。

• Fuchsia OS（谷歌的野心：5G + IOT）　

• Dart是类型安全的语言，拥有完善的包管理和诸多特性。

关于IOT，国内已经有开发者尝试在树莓派上使用Flutter了。

总的来说，想要挑战JavaScript的地位还是很难的，JavaScript虽然有很多缺陷，但庞大的生态已经为自己建立了稳固的堡垒。

有一个关于Lisp的笑话，我觉得也可以改个Dart版本的：某小偷偷了美国国防部机密软件的源码的最后几页打算拿回去好好研究，但等他真的打开时发现是这样

通过 Platform Channel机制进行通信，常用的 Platform Channel主要有三种

• BasicMessageChannel：传递字符串和半结构化数据

• MethodChannel：方法调用

• EventChannel：数据流的通信

每种Channel具有三个重要的成员变量：

• name: String类型，代表Channel的名字，也是其唯一标识符。

• messager：BinaryMessenger类型，代表消息信使，是消息的发送与接收的工具。

• codec: MessageCodec类型或MethodCodec类型，代表消息的编解码器。

Flutter的HotReload确实让人耳目一新，但这东西可能只是对于客户端开发比较稀奇，从Instant Run到freeline，开发者一直希望能提高项目构建速度，更快地看到代码改动的结果，从原理上来说，只要这门语言及其所在平台支持解释执行（or JIT）和增量编译就可以做到很好的HotReload效果，flutter的这一个特性算是填上了之前Android开发的一个坑，创举肯定是算不上的。 至于动态化，可以算是国内开发者的刚需了，Flutter之前移除了对动态化的支持，可能是担心iOS的政策原因，目前不少开发者也对Flutter展开了研究，后面应该有一批魔改方案。
Flutter的HotReload过程：

1. 首先会扫描代码，找到上次编译之后有变化的Dart代码；

2. 将这些变化的Dart代码转化为增量的Dart Kernel文件；

3. 将增量的Dart Kernel文件发送到正在移动设备上运行的Dart VM；

4. 触发widgets树的重新建立、重新布局、重新绘制

不能使用的场景（所以对这个功能不能过于乐观，业务复杂之后能用的场景就不会太多）：

1. 代码出现编译错误的不能使用 Hot Reload

2. Widget的状态更改不能使用 Hot Reload

3. 在 Flutter 中，全局变量和静态字段被视为状态，因此在 Hot Reload 期间不会重新初始化。

4. 修改通用类型声明时