深入理解Flutter引擎线程模式

在终端业务需求日益复杂，版本迭代日趋于频繁的情况下，我们迫切需要优秀的多端统一跨平台开发方案以提升研发效率。目前已有类似RN，Weex这种通过JavaScript桥接到Native的终端技术方案。但是，基于JavaScript的桥接模式有JavaScriptCore自身的性能瓶颈和桥接层的消耗。闲鱼产品界面的复杂度和我们制定的高性能基线使得我们无法选择这些方案。

目前我们正在积极尝试和探索Flutter在业务中的实践以追求更加高性能的跨平台终端方案。同为跨平台技术，Flutter为什么有其它方案所不具备的高性能特性？

• Flutter在Rlease模式下直接将Dart编译成本地机器码，避免了代码解释运行的性能消耗。

• Dart本身针对高频率循环刷新（如屏幕每秒60帧）在内存层面进行了优化，使得Dart运行时在屏幕绘制实现如鱼得水。

• Flutter实现了自己的图形绘制避免了Native桥接。

Flutter体系结构： 

为了更好地应用和实践，我们需要深入到引擎内部去理解的它的实现原理和构造。线程一直是在开发当中令人比较头疼的话题，我们也在实践过程中踩过不少坑，本文就Flutter引擎的线程模式进行一些探讨。

对于刚接触Flutter的朋友，更加详尽的Flutter相关信息可以浏览它的官方网站：Flutter IO

Flutter 线程模型

Flutter Engine自己不创建管理线程。Flutter Engine线程的创建和管理是由embedder负责的。Embeder指的是将引擎移植到平台的中间层代码。

Flutter Engine要求Embeder提供四个Task Runner。尽管Flutter Engine不在乎Runner具体跑在哪个线程，但是它需要线程配置在整一个生命周期里面保持稳定。也就是说一个Runner最好始终保持在同一线程运行。这四个主要的Task Runner包括：

Platform Task Runner

Flutter Engine的主Task Runner，运行Platform Task Runner的线程可以理解为是主线程。类似于Android Main Thread或者iOS的Main Thread。但是我们要注意Platform Task Runner和iOS之类的主线程还是有区别的。

对于Flutter Engine来说Platform Runner所在的线程跟其它线程并没有实质上的区别，只不过我们人为赋予它特定的含义便于理解区分。实际上我们可以同时启动多个Engine实例，每个Engine对应一个Platform Runner，每个Runner跑在各自的线程里。这也是Fuchsia（Google正在开发的操作系统）里Content Handler的工作原理。一般来说，一个Flutter应用启动的时候会创建一个Engine实例，Engine创建的时候会创建一个线程供Platform Runner使用。

跟Flutter Engine的所有交互（接口调用）必须发生在Platform Thread，试图在其它线程中调用Flutter Engine会导致无法预期的异常。这跟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 Thr