跨平台开发的救星-让咱们来了解一下flutter

第一次看文章的朋友能够关注个人专栏，会不按期发布Android面试内容、进阶专题等等。

简介

不少人已经用上了flutter，今天就来介绍一下

Flutter 架构

image

Flutter框架分三层
Framework，Engine， Embedder

Framework使用dart语言实现，包括UI，文本，图片，按钮等Widgets，渲染，动画，手势等。此部分的核心代码是flutter仓库下的flutter package，以及sky_engine仓库下的 io, async, ui(dart:ui库提供了Flutter框架和引擎之间的接口)等package。

Engine使用C++实现，主要包括:Skia, Dart 和 Text。

• Skia是开源的二维图形库，提供了适用于多种软硬件平台的通用API。其已做为Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其余众多产品的图形引擎，支持平台还包括Windows, macOS, iOS，Android，Ubuntu等。

• Dart 部分主要包括:Dart Runtime，Garbage Collection(GC)，若是是Debug模式的话，还包括JIT(Just In Time)支持。Release和Profile模式下，是AOT(Ahead Of Time)编译成了原生的arm代码，并不存在JIT部分。

• Text 即文本渲染，其渲染层次以下:衍生自 Minikin的libtxt库(用于字体选择，分隔行)；HartBuzz用于字形选择和成型；Skia做为渲染/GPU后端，在Android和Fuchsia上使用FreeType渲染，在iOS上使用CoreGraphics来渲染字体。

Embedder是一个嵌入层，经过该层把Flutter嵌入到各个平台上去，Embedder的主要工做包括渲染Surface设置, 线程设置，以及插件等。平台(如iOS)只是提供一个画布，剩余的全部渲染相关的逻辑都在Flutter内部，这就使得它具备了很好的跨端一致性。

Dart语言

Dart 也是一种VM语言，因此在每一个运行flutter的app中都有一个dart的运行环境。编译模式支持AOT和JIT。
Dart最开始是google设计出来替代javascript的，可是并无凑效。后面Flutter选择了Dart, 才使Dart活跃起来。

Dart语言的特色：

• 单进程异步事件模型

• 强类型，能够类型推断

• 具备极高的运行效率和优秀的代码运行优化的VM，根据早前的基准测试，性能比肩 Java7 的JVM；

• 独特的隔离区( Isolate )，能够实现多线程

• 面向对象编程，一切数据类型均派生自 Object

• 运算符重载，泛型支持

• 强大的 Future 和 Stream 模型,能够简单实现高效的代码

• Minix 特性，能够更好的实现方法复用

• 全平台语言，能够很好的胜任移动和先后端的开发

• 在语法上，Dart 提供了不少便捷的操做

Flutter线程管理

Flutter Engine本身不建立, 管理线程。Flutter Engine线程的建立和管理是由embedder负责的

Embeder提供四个Task Runner, 每一个Task Runner负责不一样的任务，Flutter Engine不在意Task Runner具体跑在哪一个线程，可是它须要线程配置在整一个生命周期里面保持稳定。也就是说一个Runner最好始终保持在同一线程运行

Platform Task Runner

是Flutter Engine的主Task Runner，运行Platform Task Runner的线程能够理解为是主线程。相似于Android Main Thread或者iOS的Main Thread。对于Flutter Engine来讲Platform Runner所在的线程跟其它线程并无实质上的区别。 能够同时启动多个Engine实例，每一个Engine对应一个Platform Runner，每一个Runner跑在各自的线程里。这也是Fuchsia（Google正在开发的操做引擎）里Content Handler的工做原理。通常状况下，一个Flutter应用启动的时候会建立一个Engine实例，Engine建立的时候会建立一个线程供Platform Runner使用。

跟Flutter Engine的全部交互（接口调用）必须发生在Platform Thread，试图在其它线程中调用Flutter Engine会致使没法预期的异常。这跟Android和IOS对于UI的操做都必须在主线程进行相相似。须要注意的是在Flutter Engine中有不少模块都是非线程安全的。一旦引擎正常启动运行起来，全部引擎API调用都将在Platform Thread里发生。

Platform Runner所在的Thread不只仅处理与Engine交互，它还处理来自平台的消息。这样的处理比较方便的，由于几乎全部引擎的调用都只有在Platform Thread进行才能是安全的，Native Plugins没必要要作额外的线程操做就能够保证操做可以在Platform Thread进行。若是Plugin本身启动了额外的线程，那么它须要负责将返回结果派发回Platform Thread以便Dart可以安全地处理。规则很简单，对于Flutter Engine的接口调用都需保证在Platform Thread进行。

阻塞Platform Thread不会直接致使Flutter应用的卡顿（跟iOS android主线程不一样）。尽管如此，平台对Platform Thread仍是有强制执行限制。因此建议复杂计算逻辑操做不要放在Platform Thread而是放在其它线程（不包括咱们如今讨论的这个四个线程）。其余线程处理完毕后将结果转发回Platform Thread。长时间卡住Platform Thread应用有可能会被系统Watchdot强行杀死。

UI Task Runner

Flutter Engine用于执行Dart root isolate代码。Root isolate比较特殊，它绑定了很多Flutter须要的函数方法。Root isolate运行应用的main code。引擎启动的时候为其增长了必要的绑定，使其具有调度提交渲染帧的能力。

1. 对于每一帧，引擎要作的事情有：

2. Root isolate通知Flutter Engine有帧须要渲染。

3. Flutter Engine通知平台，须要在下一个vsync的时候获得通知。

4. 平台等待下一个vsync

5. 对建立的对象和Widgets进行Layout并生成一个Layer Tree，Layer Tree立刻被提交给Flutter Engine。当前阶段没有进行任何光栅化，这个步骤仅是生成了对须要绘制内容的描述。

6. 建立或者更新Tree，这个Tree包含了用于屏幕上显示Widgets的语义信息。这个东西主要用于平台相关的辅助Accessibility元素的配置和渲染。

除了渲染相关逻辑以外Root Isolate仍是处理来自Native Plugins的消息响应，Timers，MicroTasks和异步IO。
Root Isolate负责建立管理的Layer Tree最终决定什么内容要绘制到屏幕上。所以这个线程的过载会直接致使卡顿掉帧。
若是确实有没法避免的繁重计算，建议将其放到独立的Isolate去执行，好比使用compute关键字或者放到非Root Isolate，这样能够避免应用UI卡顿。可是须要注意的是非Root Isolate缺乏Flutter引擎须要的一些函数绑定，你没法在这个Isolate直接与Flutter Engine交互。因此只在须要大量计算的时候采用独立Isolate。

GPU Task Runner

用于执行设备GPU的相关调用。UI Task Runner建立的Layer Tree信息是平台不相关，也就是说Layer Tree提供了绘制所须要的信息，具体如何实现绘制取决于具体平台和方式，能够是OpenGL，Vulkan，软件绘制或者其余Skia配置的绘图实现。GPU Task Runner中的模块负责将Layer Tree提供的信息转化为实际的GPU指令。GPU Task Runner同时也负责配置管理每一帧绘制所须要的GPU资源，这包括平台Framebuffer的建立，Surface生命周期管理，保证Texture和Buffers在绘制的时候是可用的。

基于Layer Tree的处理时长和GPU帧显示到屏幕的耗时，GPU Task Runner可能会延迟下一帧在UI Task Runner的调度。通常来讲UI Runner和GPU Runner跑在不一样的线程。存在这种可能，UI Runner在已经准备好了下一帧的状况下，GPU Runner却还正在向GPU提交上一帧。这种延迟调度机制确保不让UI Runner分配过多的任务给GPU Runner。

GPU Runner能够致使UI Runner的帧调度的延迟，GPU Runner的过载会致使Flutter应用的卡顿。通常来讲用户没有机会向GPU Runner直接提交任务，由于平台和Dart代码都没法跑进GPU Runner。可是Embeder仍是能够向GPU Runner提交任务的。所以建议为每个Engine实例都新建一个专用的GPU Runner线程。

IO Task Runner

主要功能是从图片存储（好比磁盘）中读取压缩的图片格式，将图片数据进行处理为GPU Runner的渲染作好准备。在Texture的准备过程当中，IO Runner首先要读取压缩的图片二进制数据（好比PNG，JPEG），将其解压转换成GPU可以处理的格式而后将数据上传到GPU。这些复杂操做若是跑在GPU线程的话会致使Flutter应用UI卡顿。可是只有GPU Runner可以访问GPU，因此IO Runner模块在引擎启动的时候配置了一个特殊的Context，这个Context跟GPU Runner使用的Context在同一个ShareGroup。事实上图片数据的读取和解压是能够放到一个线程池里面去作的，可是这个Context的访问只能在特定线程才能保证安全。这也是为何须要有一个专门的Runner来处理IO任务的缘由。获取诸如ui.Image这样的资源只有经过async call，当这个调用发生的时候Flutter Framework告诉IO Runner进行刚刚提到的那些图片异步操做。这样GPU Runner可使用IO Runner准备好的图片数据而不用进行额外的操做。

用户操做，不管是Dart Code仍是Native Plugins都是没有办法直接访问IO Runner。尽管Embeder能够将一些通常复杂任务调度到IO Runner，这不会直接致使Flutter应用卡顿，可是可能会致使图片和其它一些资源加载的延迟间接影响性能。因此建议为IO Runner建立一个专用的线程

android & iOS平台上面每个Engine实例启动的时候会为UI，GPU，IO Runner各自建立一个新的线程。全部Engine实例共享同一个Platform Runner线程

isolate

image

An isolated Dart execution context

isolate是Dart对actor并发模式的实现。运行中的Dart程序由一个或多个actor组成，actor也就是Dart概念里面的isolate。isolate是隔离的，每一个isolate有本身的内存和单线程运行的实体. isolate之间不互相共享内存，且独立GC。
isolate中的代码是顺序执行的，且是单线程，因此不存在资源竞争和变量状态同步的问题，也就不须要锁。Dart中的并发都是多个isolate并行实现的

因为isolate不共享内存，因此isolate之间不能直接互相通讯，只能经过Port进行通讯，并且是异步的

Flutter Engine Runners与Dart Isolate

Dart的Isolate是Dart虚拟机本身管理的，Flutter Engine没法直接访问。Root Isolate经过Dart的C++调用能力把UI渲染相关的任务提交到UI Runner执行, 这样就能够跟Flutter Engine相关模块进行交互，Flutter UI相关的任务也被提交到UI Runner也能够相应的给Isolate一些事件通知，UI Runner同时也处理来自App方面Native Plugin的任务。 Dart isolate跟Flutter Runner是相互独立的，它们经过任务调度机制相互协做。

Dart内存管理

Dart VM将内存管理分为新生代(New Generation)和老年代(Old Generation)

• 新生代：初次分配的对象都位于新生代中，该区域主要是存放内存较小而且生命周期较短的对象，好比局部变量。新生代会频繁执行内存回收(GC)，回收采用“复制-清除”算法，将内存分为两块，运行时每次只使用其中的一块，另外一块备用。当发生GC时，将当前使用的内存块中存活的对象拷贝到备用内存块中，而后清除当前使用内存块，最后，交换两块内存的角色。

• 老年代: 在新生代的GC中“幸存”下来的对象，它们会被转移到老年代中。老年代存放生命力周期较长，内存较大的对象。老年代的GC回收采用“标记-清除”算法，分红标记和清除两个阶段。在标记阶段会触发停顿，多线程并发的完成对垃圾对象的标记，下降标记阶段耗时。在清理阶段，由GC线程负责清理回收对象，和应用线程同时执行，不影响应用运行。

Flutter中的image所占的内存

Android将中内存分java内存或native内存，一般在代码中的申请的内存都在这两个范围内

java内存是指java或kotlin分配的内存对象
native内存是指由C/C++中分配的内存，也包括一些android原生系统占用的内存，如图像资源和其余图形等

Flutter中的image占用的不用这两种内存，而是Graphics内存，Graphics内存内存是指图形缓冲区队列向屏幕显示像素所使用的内存，图形缓冲区是指GL表面，GL纹理等。Graphics内存是与CPU共享的内存，而不是GPU专用的内存

Flutter运行模式

Flutter常见的种运行模式：Debug，Release和Profile

Release和Profile模式比较相似，不用之处在于Profile模式的服务扩展的支持，支持跟踪，以及最小化使用跟踪信息须要的依赖。Profile并不支持模拟器，缘由在于模拟器上的诊断并不表明真实的性能。全部重点截介绍
Debug和Release的差别

• Debug模式：使用JIT编译，支持模拟器和设备。打开了断言支持，包括全部的调试信息，服务扩展和Observatory等调试辅助。此模式为快速开发和运行作了优化，但并未对执行速度，包大小和部署作优化。
  因此能实现秒级别的hot reload

• Release模式：使用AOT编译，只支持真机，不支持模拟器。关闭了全部断言，尽量多地去掉了调试信息，关闭了全部调试工具。为快速启动，快速执行，包大小作了优化。禁止了全部调试辅助手段，服务扩展。

Flutter Platform Channel

Platform Channel用来实现flutter和Native之间的通信，实现方式相似远程通信。

Flutter定义了三种Channel：

• BasicMessageChannel：用于传递字符串和半结构化的信息

• MethodChannel：用于传递方法调用（method invocation）

• EventChannel: 用于数据流（event streams）的通讯

这三种channel的工做原理都一致，都用三个基本的属性：

• name: String类型，表明Channel的名字，也是其惟一标识符

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

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

BinaryMessenger是Native端与Flutter端通讯的工具，其通讯使用的消息格式为二进制格式数据。初始化一个Channel，并向该Channel注册处理消息的Handler时，实际上会生成一个与之对应的BinaryMessageHandler，并以channel name为key，注册到BinaryMessenger中。当Flutter端发送消息到BinaryMessenger时，BinaryMessenger会根据其入参channel找到对应的BinaryMessageHandler，并交由其处理。

BinaryMessenger只和BinaryMessageHandler通信。而Channel和BinaryMessageHandler则是一一对应的。因为Channel从BinaryMessageHandler接收到的消息是二进制格式数据，没法直接使用，故Channel会将该二进制消息经过Codec（消息编解码器）解码为能识别的消息并传递给Handler进行处理。

当Handler处理完消息以后，会经过回调函数返回result，并将result经过编解码器编码为二进制格式数据，经过BinaryMessenger发送回Flutter端。

Codec：息编解码器，主要用来将二进制格式的数据转化为Handler可以识别的数据，Flutter定义了两种Codec：MessageCodec和MethodCodec

MessageCodec用于二进制格式数据与基础数据之间的编码和解码。有多重实现如：BinaryCodec， StringCodec， JSONMessageCodec等

MethodCodec用于二进制数据与方法调用(MethodCall)和返回结果之间的编解码。MethodChannel和EventChannel所使用的编解码器均为MethodCodec。

MethodCodec用于MethodCall对象的编解码，一个MethodCall对象表明一次从Flutter端发起的方法调用。MethodCall有2个成员变量：String类型的method表明须要调用的方法名称，通用类型(Android中为Object，iOS中为id)的arguments表明须要调用的方法入参。

因为处理的是方法调用，MethodCodec多了对调用结果的处理。当方法调用成功时，使用encodeSuccessEnvelope将result编码为二进制数据，而当方法调用失败时，则使用encodeErrorEnvelope将error的code、message、detail编码为二进制数据。

MethodCodec有两种实现：JSONMethodCodec和StandardMethodCodec

因为Platform Channel运行在flutter App的UI Task Runner, 对应的native实现运行在Platform Task Runner，而Platform Task Runner运行在主线程，因此在native实现是不能进行耗时的操做，且Platform Task Runner是非线程安全的，因此要保证回调函数在主线程中执行

Platform Channel支持大数据传递，传递大内存数据块时，使用BasicMessageChannel以及BinaryCodec。而整个数据传递的过程当中，惟一可能出现数据拷贝的位置为native二进制数据转化为Dart语言二进制数据。若二进制数据大于阈值时（目前阈值为1000byte）则不会拷贝数据，直接转化，不然拷贝一份再转化。

学习

看到这里，你了解了吗？点个赞支持一下