简介： Flutter从实质上来讲还是一个UI框架，它解决的是一套代码在多端渲染的问题。在渲染管线的设计上更加精简，加上自建渲染引擎，相比ReactNative、Weex以及WebView等计划，具备更好的性能体验。本文将从架构和源码的角度详细分析Flutter渲染机制的设计与实现。较长，同学们可珍藏后再看。

写在后面

跨平台技术因为其一码多端的生产力晋升而体现出微小的生命力，从晚期的Hybrid App到ReactNative/Weex、小程序/快利用，再到当初的Flutter，跨平台技术始终在解决效率问题的根底上最大化的解决性能和体验问题。这也引出了任何跨平台技术都会面临的外围问题：

  • 效率：解决在多利用、多平台、多容器上开发效率的问题，一码多端，业务快跑。
  • 性能：解决的是业务的性能和体验问题。

效率作为跨平台技术的基本功能，大家都能做到。问题是谁能把性能和体验做得更好，在渲染技术这块一共有三种计划：

  • WebView渲染：依赖WebView进行渲染，在性能和性能上有斗争，例如PhoneGap、Cordova、小程序（有的小程序底层也采纳了ReactNative等渲染计划）等。
  • 原生渲染：下层拥抱W3C，通过中间层把前端框架翻译为原生控件，例如ReactNative+React、Weex+Vue的组合，这种计划多了一层转译层，性能上有损耗。随着原生零碎的降级，在兼容性上也会有问题。
  • 自建渲染：自建渲染框架，底层应用Skia等图形库进行渲染，例如Flutter、Unity。

Flutter因为其自建渲染引擎，贴近原生的实现形式，取得了优良的渲染性能。

Flutter领有本人的开发工具，开发语言、虚拟机，编译机制，线程模型和渲染管线，和Android相比，它也能够看做一个小型的OS了。

第一次接触Flutter，能够看看Flutter的创始人Eric之前的访谈《What is Flutter？》，Eric之前致力于Chromium渲染管线的设计与开发，因而Flutter的渲染与Chromium有肯定的相似之处，前面咱们会做下类比。

前面咱们会从架构和源码的角度剖析Flutter渲染机制的设计与实现，在此之前也能够先看看Flutter官网对于渲染机制的分享《How Flutter renders Widgets》。视频+图文的形式会更加直观，能够有一个大体的了解。

架构剖析

架构设计

从构造上看，Flutter渲染由UI Thread与GPU Thread相互配合实现。

1）UI Thread

对应图中1-5，执行Dart VM中的Dart代码（蕴含应用程序和Flutter框架代码），次要负责Widget Tree、Element Tree、RenderObject Tree的构建，布局、以及绘制生成绘制指令，生成Layer Tree（保留绘制指令）等工作。

2）GPU Thread

对应图中6-7，执行Flutter引擎中图形相干代码（Skia），这个线程通过与GPU通信，获取Layer Tree并执行栅格化以及合成上屏等操作，将Layer Tree显示在屏幕上。

注：图层树（Layer Tree）是Flutter组织绘制指令的形式，相似于Android Rendering里的View DisplayList，都是组织绘制指令的一种形式。

UI Thread与GPU Thread属于生产者和消费者的角色。

流程设计

咱们晓得Android上的渲染都是在VSync信号驱动下进行的，Flutter在Android上的渲染也不例外，它会向Android零碎注册并期待VSync信号，等到VSync信号到来当前，调用沿着C++ Engine->Java Engine，达到Dart Framework，开始执行Dart代码，经验Layout、Paint等过程，生成一棵Layer Tree，将绘制指令保留在Layer中，接着进行栅格化和合成上屏。

具体说来：

1）向Android零碎注册并期待VSync信号

Flutter引擎启动时，会向Android零碎的Choreographer（治理VSync信号的类）注册并接管VSync信号的回调。

2）接管到VSync信号，通过C++ Engine向Dart Framework发动渲染调用

当VSync信号产生当前，Flutter注册的回调被调用，VsyncWaiter::fireCallback() 办法被调用，接着会执行 Animator::BeiginFrame()，最终调用到 Window::BeginFrame() 办法，WIndow实例是连贯底层Engine和Dart Framework的重要桥梁，基本上与平台相干的操作都会通过Window实例来连贯，例如input事件、渲染、无障碍等。

3）Dart Framework开始在UI线程执行渲染逻辑，生成Layer Tree，并将栅格化工作post到GPU线程执行

Window::BeiginFrame() 接着调用，执行到 RenderBinding::drawFrame() 办法，这个办法会去驱动UI界面上的dirty节点（须要重绘的节点）进行从新布局和绘制，如果渲染过程中遇到图片，会先放到Worker Thead去加载和解码，而后再放到IO Thread生成图片纹理，因为IO Thread和GPI Thread共享EGL Context，因而IO Thread生成的图片纹理能够被GPU Thread间接拜访。

4）GPU线程接管到Layer Tree，进行栅格化以及合成上屏的工作

Dart Framework绘制实现当前会生成绘制指令保留在Layer Tree中，通过 Animator::RenderFrame() 把Layer Tree提交给GPU Thread，GPU Thread接着执行栅格化和上屏显示。之后通过 Animator::RequestFrame() 申请接管零碎的下一次VSync信号，如此周而复始，驱动UI界面不断更新。

一一调用流程比拟长，然而外围点没多少，不必纠结调用链，抓住要害实现即可，咱们把外面波及到的一些次要类用色彩分了个类，对着这个类图，根本能够摸清Flutter的脉络。


绿色：Widget 黄色：Element 红色：RenderObject

以上便是Flutter渲染的整体流程，会有多个线程配合，多个模块参加，抛开简短的调用链，咱们针对每一步来具体分析。咱们在剖析构造时把Flutter的渲染流程分为了7大步，Flutter的timeline也能够清晰地看到这些流程，如下所示：

UI Thread

1）Animate

由 handleBeiginFrame() 办法的transientCallbacks触发，如果没有动画，则该callback为空；如果有动画，则会回调 Ticker.tick() 触发动画Widget更新下一帧的值。

2）Build

由 BuildOwner.buildScope() 触发，次要用来构建或者更新三棵树，Widget Tree、Element Tree和RenderObject Tree。

3）Layout

由 PipelineOwner.flushLayout() 触发，它会调用 RenderView.performLayout()，遍历整棵Render Tree，调用每个节点的 layout()，依据build过程记录的信息，更新dirty区域RenderObject的排版数据，使得每个RenderObject最终都能有正确的大小（size）和地位（position，保留在parentData中）。

4）Compositing Bits

由 PipelineOwner.flushCompositingBits() 触发，更新具备dirty合成地位的渲染对象，此阶段每个渲染对象都会理解其子项是否须要合成，在绘制阶段应用此信息抉择如何实现裁剪等视觉效果。

5）Paint

由 PipeOwner.flushPaint() 触发，它会调用 RenderView.paint()。最终触发各个节点的 paint()，最终生成一棵Layer Tree，并把绘制指令保留在Layer中。

6）Submit（Compositing）

由 renderView.compositeFrame() 办法触发，这个中央官网的说法叫Compositing，不过我感觉叫Compositing有歧义，因为它并不是在合成，而是把Layer Tree提交给GPU Thread，因此我感觉叫Submit更适合。

GPU Thread

7）Compositing

由 Render.compositeFrame() 触发，它通过Layer Tree构建一个Scene，传给Window进行最终的光栅化。

GPU Thread通过Skia向GPU绘制一帧数据，GPU将帧信息保留在FrameBuffer里，而后依据VSync信号周期性的从FrameBuffer取出帧数据交给显示器，从而显示出最终的界面。

Rendering Pipeline

Flutter引擎启动时，向Android零碎的Choreographer注册并接管VSync信号，GPU硬件产生VSync信号当前，零碎便会触发回调，并驱动UI线程进行渲染工作。

1 Animate

触发办法：由 handleBeiginFrame() 办法的transientCallbacks触发

Animate在 handleBeiginFrame() 办法里由transientCallbacks触发，如果没有动画，则该callback为空；如果有动画，则会回调 Ticker._tick() 触发动画Widget更新下一帧的值。

void handleBeginFrame(Duration rawTimeStamp) {    ...    try {      // TRANSIENT FRAME CALLBACKS      Timeline.startSync('Animate', arguments: timelineWhitelistArguments);      _schedulerPhase = SchedulerPhase.transientCallbacks;      final Map<int, _FrameCallbackEntry> callbacks = _transientCallbacks;      _transientCallbacks = <int, _FrameCallbackEntry>{};      callbacks.forEach((int id, _FrameCallbackEntry callbackEntry) {        if (!_removedIds.contains(id))          _invokeFrameCallback(callbackEntry.callback, _currentFrameTimeStamp, callbackEntry.debugStack);      });      ...    } finally {      ...    }  }

handleBeiginFrame() 解决实现当前，接着调用 handleDrawFrame()，handleDrawFrame() 会触发以下回调：

  • postFrameCallbacks用来告诉监听者绘制曾经实现。
  • pesistentCallbacks用来触发渲染。

这两个回调都是SchedulerBinding外部的回调队列，如下所示：

  • _transientCallbacks：用于寄存一些长期回调，目前是在 Ticker.scheduleTick() 中注册，用来驱动动画。
  • _persistentCallbacks：用来寄存一些长久回调，不能在此回调中再申请新的绘制帧，长久回调一经注册就不嫩嫩移除， RenderBinding.initInstaces().addPersitentFrameCallback() 增加了一个长久回调，用来触发 drawFrame()。
  • _postFrameCallbacks：在Frame完结时会被调用一次，调用后会被移除，它次要是用来告诉监听者这个Frame曾经实现。

接着会调用 WidgetBinder.drawFrame() 办法，它会先调用会先调用 BuildOwner.buildScope() 触发树的更新，而后才进行绘制。

@overridevoid drawFrame() {  ...  try {    if (renderViewElement != null)      buildOwner.buildScope(renderViewElement);    super.drawFrame();    buildOwner.finalizeTree();  } finally {    assert(() {      debugBuildingDirtyElements = false;      return true;    }());  }  ...}

接着调用 RenderingBinding.drawFrame() 触发layout、paingt等流程。

void drawFrame() {  assert(renderView != null);  pipelineOwner.flushLayout();  pipelineOwner.flushCompositingBits();  pipelineOwner.flushPaint();  if (sendFramesToEngine) {    renderView.compositeFrame(); // this sends the bits to the GPU    pipelineOwner.flushSemantics(); // this also sends the semantics to the OS.    _firstFrameSent = true;  }}

以上便是外围流程代码，咱们接着来Build的实现。

2 Build

触发办法：由 BuildOwner.buildScope() 触发。

咱们下面说到，handleDrawFrame() 会触发树的更新，事实上 BuildOwner.buildScope() 会有两种调用机会：

  • 树构建（利用启动时）：咱们下面提到的 runApp() 办法调用的 scheduleAttachRootWidget() 办法，它会构建Widgets Tree、Element Tree与RenderObject Tree三棵树。
  • 树更新（帧绘制与更新时）：这里不会从新构建三棵树，而是只会更新dirty区域的Element。

也即是说树的构建和更新都是由 BuildOwner.buildScope() 办法来实现的。它们的差异在于树构建的时候传入了一个 element.mount(null, null) 回调。在 buildScope() 过程中会触发这个回调。

这个回调会构建三棵树，为什么会有三棵树呢，因为Widget只是对UI元素的一个形象形容，咱们须要先将其inflate成Element，而后生成对应的RenderObject来驱动渲染，如下所示：

  • Widget Tree：为Element形容须要的配置，调用createElement办法创立Element，决定Element是否须要更新。Flutter通过查分算法比对Widget树前后的变动，来决定Element的State是否扭转。
  • Element Tree：示意Widget Tree特定地位的一个实例，调用createRenderObject创立RenderObject，同时持有Widget和RenderObject，负责管理Widget的配置和RenderObjec的渲染。Element的状态由Flutter保护，开发人员只须要保护Widget即可。
  • RenderObject Tree：RenderObject绘制，测量和绘制节点，布局子节点，解决输出事件。

3 Layout

触发办法：由 PipelineOwner.flushLayout() 触发。

  • 相干文档：Understanding constraints
  • 相干源码：PipelineOwner.flushLayout()

Layout是基于单向数据流来实现的，父节点向子节点传递束缚（Constraints），子节点向父节点传递大小（Size，保留在父节点的parentData变量中）。先深度遍历RenderObject Tree，而后再递归遍历束缚。单向数据流让布局流程变得更简略，性能也更好。

对于RenderObject而言，它只是提供了一套根底的布局协定，没有定义子节点模型、坐标零碎和具体的布局协定。它的子类RenderBox则提供了一套笛卡尔坐标体系（和Android&iOS一样），大部分RenderObject类都是间接继承RenderBox来实现的。RenderBox有几个不同的子类实现，它们各自对应了不同的布局算法。

  • RenderFlex：弹性布局，这是一种很常见的布局形式，它对应的是Widget组件Flex、Row和Column。对于这一块的布局算法代码正文里有形容，也能够间接看这篇文章的解释。
  • RenderStack：栈布局。

咱们再来聊聊Layout流程中波及的两个概念边界束缚（Constraints）和从新布局边界（RelayoutBoundary）。

边界束缚（Constraints）：边界束缚是父节点用来限度子节点的大小的一种形式，例如BoxConstraints、SliverConstraints等。

RenderBox提供一套BoxConstraints，如图所示，它会提供以下限度：

  • minWidth
  • maxWidth
  • minHeight
  • maxHeight

利用这种简略的盒模型束缚，咱们能够非常灵活的实现很多常见的布局，例如齐全和父节点一样的大小，垂直布局（宽度和父节点一样大）、程度布局（高度和父容器一样大）。

通过Constraints和子节点本人配置的大小信息，就能够最终算出子节点的大小，接下来就须要计算子节点的地位。子节点的地位是由父节点来决定的。

从新布局边界（RelayoutBoundary）：为一个子节点设置从新布局边界，这样当它的大小发生变化时，不会导致父节点从新布局，这是个标记位，在标记dirty的markNeedsLayout()办法中会查看这个标记位来决定是否从新进行布局。

从新布局边界这种机制晋升了布局排版的性能。

通过Layout，咱们理解了所有节点的地位和大小，接下来就会去绘制它们。

4 Compositing Bits

触发办法：由 PipelineOwner.flushCompositingBits() 触发。

在Layout之后，在Paint之前会先执行Compositing Bits，它会查看RenderObject是否须要重绘，而后更新RenderObject Tree各个节点的needCompositing标记。如果为true，则须要重绘。

5 Paint

触发办法：由 PipeOwner.flushPaint() 触发。

相干源码：

  • Dart层调用入口：painting.dart
  • C++层实现：canvas.cc

咱们晓得古代的UI零碎都会进行界面的图层划分，这样能够进行图层复用，缩小绘制量，晋升绘制性能，因而Paint（绘制）的外围问题还是解决绘制命令应该放到哪个图层的问题。

Paint的过程也是单向数据流，先向下深度遍历RenderObject Tree，再递归遍历子节点，遍历的过程中会决定每个子节点的绘制命令应该放在那一层，最终生成Layer Tree。

和Layout一样，为了提到绘制性能，绘制阶段也引入了从新绘制边界。

从新绘制边界（RepaintBoundary）：为一个子节点设置从新绘制边界，这样当它须要从新绘制时，不会导致父节点从新绘制，这是个标记位，在标记dirty的markNeedsPaint()办法中会查看这个标记位来决定是否从新进行重绘。

事实上这种重绘边界的机制绝对于把图层分层这个性能凋谢给了开发者，开发者能够本人决定本人的页面那一块在重绘时不参加重绘（例如滚动容器），以晋升整体页面的性能。从新绘制边界会扭转最终的图层树（Layer Tree）构造。

当然这些重绘边界并不都须要咱们手动搁置，大部分Widget组件会主动搁置重绘边界（主动分层）。

设置了RepaintBoundary的就会额定生成一个图层，其所有的子节点都会被绘制在这个新的图层上，Flutter中应用图层来形容一个档次上（一个绘制指令缓冲区）的所有RenderObject，根节点的RenderView会创立Root Layer，并且蕴含若干个子Layer，每个Layer又蕴含多个RenderObject，这些Layer便造成了一个Layer Tree。每个RenderObject在绘制时，会产生相干的绘制指令和绘制参数，并保留在对应的Layer上。

相干Layer都继承Layer类，如下所示：

  • ClipRectLayer：矩形裁剪层，能够指定裁剪和矩形行为参数。共有4种裁剪行为，none、hardEdge、antiAlias、antiAliashWithSaveLayer。
  • ClipRRectLayer：圆角矩形裁剪层，行为同上。
  • ClipPathLayer：门路裁剪层，能够指定门路和行为裁剪参数，行为同上。
  • OpacityLayer：通明层，能够指定透明度和偏移（画布坐标系原点到调用者坐标系原点的偏移）参数。
  • ShaderMaskLayer：着色层，能够指定着色器矩阵和混合模式参数。
  • ColorFilterLayer：色彩过滤层，能够指定色彩和混合模式参数。
  • TransformLayer：变换图层，能够指定变换矩阵参数。
  • BackdropFilterLayer：背景过滤层，能够指定背景图参数。
  • PhysicalShapeLayer：物理性状层，能够指定色彩等八个参数。

具体能够参考文章上方的Flutter类图。

聊完了绘制的基本概念，咱们再来看看绘制的具体流程，下面提到渲染第一帧的时候，会从根节点RenderView开始，一一遍历所有子节点进行操作。如下所示：

1）创立Canvas对象

Canvas对象通过PaintCotext获取，它外部会创立一个PictureLayer，并通过ui.PictureRecorder调用到C++层创立一个Skia的SkPictureRecorder的实例，并通过SkPictureRecorder创立SkCanvas，而后将SkCanvas返回给Dart Framework应用。SkPictureRecorder能够用来记录生成的绘制命令。

2）通过Canvas执行绘制

绘制命令会被SkPictureRecorder记录下来。

3）通过Canvas完结绘制，筹备进行栅格化

绘制完结后，会调用 Canvas.stopRecordingIfNeeded() 办法，它会接着去调用C++层的SkPictureRecorder::endRecording()办法生成一个Picture对象并保留在PictureLayer中，Picture对象蕴含了所有的绘制指令。所有的Layer绘制实现，造成Layer Tree。

绘制实现当前，接着就能够向GPU Thread提交Layer Tree了。

6 Submit（Compositing）

触发办法：由 renderView.compositeFrame() 办法触发。

  • Dart层调用入口：compositing.dart widow.dart
  • C++层实现：scene.cc scene_builder.cc
注：这个中央官网的说法叫Compositing，不过我感觉叫Compositing有歧义，因为它并不是在合成，而是把Layer Tree提交给GPU Thread，因此我感觉叫Submit更适合。
void compositeFrame() {    Timeline.startSync('Compositing', arguments: timelineArgumentsIndicatingLandmarkEvent);    try {      final ui.SceneBuilder builder = ui.SceneBuilder();      final ui.Scene scene = layer.buildScene(builder);      if (automaticSystemUiAdjustment)        _updateSystemChrome();      _window.render(scene);      scene.dispose();      assert(() {        if (debugRepaintRainbowEnabled || debugRepaintTextRainbowEnabled)          debugCurrentRepaintColor = debugCurrentRepaintColor.withHue((debugCurrentRepaintColor.hue + 2.0) % 360.0);        return true;      }());    } finally {      Timeline.finishSync();    }  }
  • 创立SceneBuilder对象，并通过 SceneBuilder.addPicture() 将上文中生成的Picture增加到SceneBuilder对象对象中。
  • 通过 SceneBuilder.build() 办法生成Scene对象，接着会通过window.render(scene)将蕴含绘制指令的Layer Tree提交给CPU线程进行光栅化和合成。

在这个过程中Dart Framework层的Layer会被转换为C++层应用的flow::layer，Flow模块是一个基于Skia的简略合成器，运行在GPU线程，并向Skia上传指令信息。Flutter Engine应用flow缓存Paint阶段生成的绘制指令和像素信息。咱们在Paint阶段的Layer，它们都与Flow模块里的Layer一一对应。

Graphics Pipeline

7 Raster&Compositing

有了蕴含渲染指令的Layer Tree当前就能够进行光栅化和合成了。

光栅化是把绘制指令转换成对应的像素数据，合成是把各图层栅格化后的数据进行相干的叠加和个性解决。这个流程称为Graphics Pipeline。

相干代码：rasterizer.cc

Flutter采纳的是同步光栅化。什么是同步光栅化？

同步光栅化：

光栅化和合成在一个线程，或者通过线程同步等形式来保障光栅化和合成的的程序。

间接光栅化：间接执行可见图层的DisplayList中可见区域的绘制指令进行光栅化，在指标Surface的像素缓冲区上生成像素的色彩值。
间接光栅化：为指定图层调配额定的像素缓冲区（例如Android提供View.setLayerType容许利用为指定View提供像素缓冲区，Flutter提供了Relayout Boundary机制来为特定图层调配额定缓冲区），该图层光栅化的过程中会先写入本身的像素缓冲区，渲染引擎再将这些图层的像素缓冲区通过合成输入到指标Surface的像素缓冲区。

异步分块光栅化：

图层会依照肯定的规定粉尘同样大小的图块，光栅化以图块为单位进行，每个光栅化工作执行图块区域内的指令，将执行后果写入分块的像素缓冲区，光栅化和合成不在一个线程内执行，并且不是同步的。如果合成过程中，某个分块没有实现光栅化，那么它会保留空白或者绘制一个棋盘格图形。

Android和Flutter采纳同步光栅化策略，以间接光栅化为主，光栅化和合成同步执行，在合成的过程中实现光栅化。而Chromium采纳异步分块光栅化测量，图层会进行分块，光栅化和合成异步执行。

从文章上方的序列图能够看到，光栅化的入口是 Rasterizer::DoDraw() 办法。它会接着调用 ScopedFrame::Raster() 办法，这个办法就是光栅化的外围实现，它次要实现以下工作：

  • LayerTree::Preroll()：解决绘制前的一些筹备工作。
  • LayerTree::Paint()：嵌套调用不通Layer的绘制办法。
  • SkCanvas::Flush()：将数据flush给GPU。
  • AndroidContextGL::SwapBuffers()：替换帧缓存给显示器显示。

到这里咱们Flutter整体的渲染实现咱们就剖析完了。

Android、Chromium与Flutter

Android、Chromium、Flutter都作为Google家的明星级我的项目，它们在渲染机制的设计上既有类似又有不同，借着这个机会咱们对它们做个比拟。

古代渲染流水线的根本设计：

咱们再别离来看看Android、Chromium和Flutter是怎么实现的。

Android渲染流水线：

Chromium渲染流水线：

Flutter渲染流水线：

互相比拟：

写在最初

最初的最初，谈一谈我对跨平台生态的了解。

跨平台容器生态至多能够分为三个方面：

前端框架生态

前端框架生态间接面向的是业务，它应该具备两个特点：

  • 拥抱W3C生态
  • 绝对稳定性

它应该是拥抱W3C生态的。W3C生态是一个凋敝且充满活力的生态，它会倒退的更久更远。试图摈弃W3C生态，自建子集的做法很难走的久远。这从微信小程序、Flutter都推出for web系列就能看出端倪。

它应该是绝对稳固的。不能说咱们每换一套容器，前端的业务就须要从新写一遍，例如咱们之前做H5容器，起初做小程序容器，因为DSL不通，前端要花大力量将业务重写。尽管小程序是一码多端，然而我认为这并没有解决效率问题，次要存在两个问题：

  • 前端的学习成本增加，小程序的DSL还算简略，Flutter的Widget体系学习起来就须要花上一点工夫，这些对于团队来说都是老本。
  • 业务代码重写，大量逻辑须要梳理，而且老业务并不一定都适宜迁徙到新容器上，比方小程序原本就是个很轻量的解决方案，然而咱们在下面沉积了很多性能，造成了重大的体验问题。

在这种状况下，业务很难实现疾速奔跑。所以说不论底层容器怎么变，前端的框架肯定是绝对稳固的。而这种稳定性就有赖于容器对立层。

容器对立层

容器对立层是在前端框架和容器层之间的一个层级。它定义了容器提供的根本能力，这些能力就像协定一样，是绝对稳固的。

协定是十分重要的，就像OpenGL协定一样，有了OpenGL协定，不论底层的渲染计划如何实现，下层的调用是不必变的。对于咱们的业务也是一样，围绕着容器对立层，咱们须要积淀通用的解决方案。

  • 对立API解决方案
  • 对立性能解决方案
  • 对立组件解决方案
  • 对立配套设施解决方案
  • 等等

这些货色不能说每搞一套容器，咱们都要大刀阔斧重来一遍，这种做法是有问题的。曾经做过的货色，遇到新的技术就推倒重来，只能阐明以前定义的计划考虑不周全，没有思考积淀对立和扩大的状况。

如果咱们自顾自的一遍遍做着性能反复的技术计划，业务能等着咱们吗。

容器层

容器层的迭代外围是为了在解决效率问题的根底上最大化的解决性能和体验问题。

晚期的ReactNative模式解决了效率了问题，然而多了一个通信层（ReactNative是依附将虚构DOM的信息传递给原生，而后原生依据这些布局信息构建对应的原生控件树来实现的原生渲染）存在性能问题，而且这种转译的形式须要适配零碎版本，带来更多的兼容性问题。

微信后续又推出了小程序计划，在我看来，小程序计划不像是一个技术计划，它更像是一个商业解决方案，解决了平台大流量标准治理和散发的问题，给业务方提供通用的技术解决方案，当然小程序底层的渲染计划也是多种多样的。

后起之秀Flutter解决的痛点是性能能力，它自建了一套GUI零碎，底层间接调用Skia图形库进行渲染（与Android的机制一样），进而实现了原生渲染。然而它基于开发效率、性能以及本身生态等因素的思考最终抉择了Dart，这种做法无疑是间接摈弃了凋敝的前端生态，就跨平台容器的倒退历史来看，在解决效率与性能的根底上，最大化的拥抱W3C生态，可能是将来最好的方向。Flutter目前也推出了Flutter for Web，从它的思路来看，是先买通Android与iOS，再逐渐向Web浸透，咱们期待它的体现。

容器技术是动静向前倒退的，咱们往年搞Flutter，明年可能还会搞其余技术计划。在计划变迁的过程中，咱们须要保障业务疾速平滑的适度，而不是每次大刀阔斧的再来一遍。

随着手机性能的晋升，WebView的性能也越来越好，Flutter又为解决性能问题提供了新的思路，一个基础设施欠缺，体验至上，一码多端的跨平台容器生态值得期待。

最初的最初

欢送退出本地生存终端技术部！

本地生存终端技术部隶属于阿里本地生存用户技术部，从事客户端技术研发工作，次要负责本地生存饿了么App 和 口碑App 的客户端架构、根底中间件、跨平台技术解决方案，以及账号、首页、全局购物车、收银台、订单列表、红包卡券、直播、短视频等平台化外围业务链路。目前团队规模50+人，咱们依靠阿里弱小的终端技术底盘，以及本地生存的业务土壤，致力于打造最优良的O2O技术团队。

招聘本地生存-客户端开发专家/高级技术专家-杭州/上海/北京，欢迎您的加盟！简历发送至 wushi@alibaba-inc.com

附录

相干平台
[1]Flutter pub.dev
（https://pub.dev/flutter/packages）
相干文档
[1]Flutter 官网文档
（https://flutter.dev/docs/get-started/install/macos）
[2]Flutter for Android developers
（https://flutter.dev/docs/get-started/flutter-for/android-devs）
[3]Flutter Widget Doc
（https://flutter.dev/docs/reference/widgets）
[4]Flutter API Doc（https://api.flutter.dev/）
[5]Dart Doc
（https://dart.dev/guides/language）
相干源码
[1]Dart Framework
（https://github.com/flutter/flutter/tree/master/packages）
[2]Flutter Engine
（https://github.com/flutter/engine）
相干资源
[1]Flutter Render Pipeline
（https://www.youtube.com/watch?v=UUfXWzp0-DU）
[2]How Flutter renders Widgets
（https://www.youtube.com/watch?v=996ZgFRENMs）
[3]深刻理解Flutter的高性能图形渲染 video
（https://www.bilibili.com/video/av48772383）
[4]深刻理解Flutter的高性能图形渲染 ppt
（https://files.flutter-io.cn/events/gdd2018/Deep_Dive_into_Flutter_Graphics_Performance.pdf）