fluttergpu的简单介绍

Android 图形系统（Graphics）

本文将从三个方面介绍Android 图形系统。

成都创新互联公司主要从事网站制作、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务广平,10多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:13518219792

图形系统提供绘图和图形处理支持。

Android 框架提供了各种用于 2D 和 3D 图形渲染的 API、图片解码库，以及各种Driver支持。

• 绘图API：2D引擎 Skia，3D引擎 OpenGL ES，RenderScript，OpenCV和Vulkan。

• 图片解码库：jpg，png，gif等。

应用开发者可通过三种方式将图像绘制到屏幕:

• Canvas : 2D图形API，Android View树实际的绘制者。

• OpenGL ES : 嵌入式设备的OpenGL 三维图形API子集。

• Vulkan :跨平台的2D和3D绘图引擎,Android 7.0后支持，NDK。

整个图形系统架构是一个生产者和消费者模式，五层依次介绍：

2D绘制：Canvas api / view 的子类 (button ,list)/自定义view

3D绘制：应用直接使用OpenGL 接口绘制图形(PixelFlinger对应的是openGl 1.0 ，GUP driver 对应的是2.0和3.0)

所有情况下的绘图都渲染到一个包含 GraphicBuffer的Surface上，当一块 Surface 显示在屏幕上时，就是用户所看到的窗口。

• Canvas：画布，2D图形API，Android View树实际的渲染者。

• Skia绘制：Android4.0之前默认使用，主线程通过CPU完成绘图指令操作，在复杂场景下单帧容易超过16ms导致卡顿。

WindowManagerService（WMS）窗口管理服务，管理系统中所有的窗口。

• 管理window （view的容器）

• Window与surface对应，一块显示区域。添加一个window，就是 WMS 为其分配一块 Surface 的过程。

Google 在Android source官网提示：

这里就对这些控件进行简单介绍：

Surface : Handle onto a raw buffer that is being managed by the screen compositor.

Surface 对应一块屏幕缓冲区。生产者是： SurfaceTexture、MediaRecorder 等，消费者是： OpenGL、MediaPlayer 或 CameraDevice等。每个window对应一个Surface。Canvas或OpenGL ES等最终都渲染到Surface上。

• Flutter在Android平台上也是直接渲染到Surface。例如：一个Activity/Dialog都是一个Surface，它承载了上层的图形数据，与SurfaceFlinger侧的Layer相对应。

Canvas（画布）实现由 Skia 图形库提供。为了确保两个客户端不会同时更新某个缓冲区，使用以下命令处理画布锁：

使用双缓冲机制，有自己的 surface，View只是一个透明的占位符，Surface可以在后台线程中绘制。双缓冲机制提高渲染效率，独立线程

绘制，提升流畅性。适合一些场景：需要界面迅速更新、UI绘制时间长、对帧率要求较高的情况。

提供访问和控制Surface 相关的方法 。通过SurfaceView的getHolder()函数可以获取SurfaceHolder对象，Surface 就在SurfaceHolder对象内。

addCallback(SurfaceHolder.Callbackcallback) /Canvas lockCanvas() /unlockCanvasAndPost(Canvascanvas)

SurfaceTexture： Surface 和 OpenGL ES (GLES) 纹理（Texture）的组合。将图像流转为 OpenGL 外部纹理。

TextureView：持有 SurfaceTexture，将图像处理为 OpenGL 纹理更新到 HardwareLayer。

GLSurfaceView：加入 EGL 管理，自带 GL 上下文和 GL 渲染线程

这些View通常涉及到Android音视频相关，需要高效的渲染能力。如下面的SurfaceTexture在camera中的应用。

简称Buffer, 一个Buffer包含一帧图像，Buffer由gralloc分配和回收。Buffer 属性包含：width, height, format, usage等

BufferQueue 的引入是为了解决显示和性能问题。

• Surface属于APP进程，Layer属于系统进程，如果它们之间只用一个Buffer，会存在显示和性能问题。

• 一些Buffer用于绘制，一些Buffer用于显示，双方处理完之后，交换一下Buffer，提高效率。

• BufferQueue中包含多个Buffer对象。

Android图形系统包含了两对生产者和消费者模型，它们都通过BufferQueue进行连接：

1.Canvas和OpenGL ES生产图形数据，SurfaceFlinger消费图形数据。

2.SurfaceFlinger合成所有图层的图形数据，Display显示合成结果。

code：frameworks/native/services/surfaceflinger

• Surface表示APP进程的一个窗口，承载了窗口的图形数据。

• SurfaceFlinger是系统进程合成所有窗口的系统服务，负责合成所有Surface提供的图形数据，然后送显到屏幕。

• SurfaceFlinger既是上层应用的消费者，又是Display的生产者，起到了承上启下的作用。

数据流：

合成示意图：

在介绍Vsync机制之前先介绍两个重要概念：

屏幕刷新率：屏幕每秒钟可以刷新多少次。60HZ刷新率，16.7ms刷新一次。（120HZ/8.3ms），硬件指标。

GPU 绘制帧率：GPU 每秒能够合成绘制多少帧。

软件层触发 View 绘制的时机是随机的，当下一次屏幕刷新时，屏幕从 Frame Buffer 中拿到的数据还是“帧1”的数据，导致“丢帧”。

每隔 16ms 硬件层发出 vsync 信号，应用层接收到此信号后会触发UI 的渲染流程，同时 vsync 信号也会触发 SurfaceFlinger 读取Buffer 中的数据，进行合成显示到屏幕上。

总结：Vsync机制将 CPU 和 GPU 的开始时间与屏幕刷新强行拖拽到同一起跑线

Android提供的Graphics流程相对比较复杂对其进行具象后的流程如下两张图所示：

Flutter_定义控件StatefulWidgets和StatelessWidget

Stateful（有状态） 和 stateless（无状态） widgets

stateless widget 没有内部状态. Icon、 IconButton, 和Text 都是无状态widget, 他们都是 StatelessWidget的子类。

stateful widget 是动态的. 用户可以和其交互 (例如输入一个表单、 或者移动一个slider滑块),或者可以随时间改变 (也许是数据改变导致的UI更新). Checkbox, Radio, Slider, InkWell, Form, and TextField 都是 stateful widgets, 他们都是 StatefulWidget的子类。

StatefulWidget类

具有可变状态的小部件。

状态是（1）在构建窗口小部件时可以同步读取的信息，以及（2）在窗口小部件的生命周期内可能会更改的信息。这是小工具实施者的责任，以确保国家的及时通知当这种状态的改变，使用State.setState。

有状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。

当您描述的用户界面部分可以动态更改时（例如由于具有内部时钟驱动状态或依赖于某些系统状态），状态窗口小部件非常有用。对于仅依赖于对象本身中的配置信息以及窗口小部件膨胀的 BuildContext的组合，请考虑使用 StatelessWidget。

StatefulWidget实例本身是不可变的，并且将它们的可变状态存储在由createState方法创建的单独State对象中 ，或者存储在State订阅的对象中，例如Stream或ChangeNotifier对象，其引用存储在StatefulWidget的最终字段中本身。

框架在膨胀StatefulWidget时 调用createState，这意味着如果该窗口小部件已插入到多个位置的树中，则多个State对象可能与同一StatefulWidget关联。同样，如果StatefulWidget从树中移除，后来在树再次插入时，框架将调用createState再创建一个新的国家目标，简化的生命周期状态的对象。

如果StatefulWidget的创建者使用GlobalKey作为其 键，则StatefulWidget在从树中的一个位置移动到另一个位置时保持相同的State对象。由于具有GlobalKey的窗口小部件可以在树中的至多一个位置使用，因此使用GlobalKey的窗口小部件最多只有一个关联元素。当通过将与该窗口小部件关联的（唯一）子树从旧位置移植到新位置（而不是在该位置重新创建子树）时，框架利用此属性将全局键从树中的一个位置移动到另一个位置时利用此属性。新的位置）。与StatefulWidget关联的State对象与子树的其余部分一起被移植，这意味着State对象在新位置被重用（而不是被重新创建）。但是，为了有资格进行嫁接，必须将窗口小部件插入到从旧位置移除它的同一动画帧中的新位置。

StatefulWidget有两个主要类别。

首先是其中一个分配资源State.initState并在他们的处置State.dispose，但不依赖于InheritedWidget S或致电State.setState。这些小部件通常在应用程序或页面的根目录中使用，并通过ChangeNotifier， Stream或其他此类对象与子小部件进行通信。遵循这种模式的有状态小部件相对便宜（就CPU和GPU周期而言），因为它们构建一次然后永不更新。因此，它们可能有一些复杂和深刻的构建方法。

第二类是使用State.setState或依赖于 InheritedWidget的小部件。这些通常会在应用程序的生命周期内重建多次，因此最小化重建此类窗口小部件的影响非常重要。（他们也可以使用State.initState或 State.didChangeDependencies并分配资源，但重要的是他们重建。）

可以使用几种技术来最小化重建有状态窗口小部件的影响：

StatelessWidget类

一个不需要可变状态的小部件。

无状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。

当您描述的用户界面部分不依赖于对象本身的配置信息以及窗口小部件膨胀的BuildContext时，无状态窗口小部件非常有用。对于可以动态更改的组合，例如由于具有内部时钟驱动状态或依赖于某些系统状态，请考虑使用StatefulWidget。

无状态窗口小部件的构建方法通常仅在以下三种情况下调用：第一次将窗口小部件插入树中，窗口小部件的父窗口更改其配置时，以及何时依赖于更改的InheritedWidget。

如果窗口小部件的父级将定期更改窗口小部件的配置，或者它依赖于经常更改的继承窗口小部件，则优化构建方法的性能以保持流畅的呈现性能非常重要。

可以使用几种技术来最小化重建无状态窗口小部件的影响：

flutter sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory

使用 cached_network_image 加载网络图片时，遇到 sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory ，然后app会闪退。

解决办法，设置缓存图片的宽高，如下：

Have fun.

Flutter浪潮下的音视频研发探索

文/陈炉军

整理/LiveVideoStack

大家好，我是阿里巴巴闲鱼事业部的陈炉军，本次分享的主题是Flutter浪潮下的音视频研发探索，主要内容是针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践，介绍其在音视频领域碰到的一些困难以及解决方案。

分享内容主要分为四个方面，首先会对Flutter有一个简单介绍以及选择Flutter作为跨平台框架的原因，其次会介绍Flutter中与音视频关系非常大的外接纹理概念，以及对它做出的一些优化。之后会对闲鱼在音视频实践过程中碰到的一些Flutter问题提出了一些解决方案——TPM音视频框架。最后是闲鱼Flutter多媒体开源组件的介绍。

Flutter

Flutter是一个跨平台框架，以往的做法是将音频、视频和网络这些模块都下沉到C++层或者ARM层，在其上封装成一个音视频的SDK，供UI层的PC、iOS和Android调用。

而Flutter做为一个UI层的跨平台框架，顾名思义就是在UI层也实现了一个跨平台开发。可以预想的是未Flutter发展的好的话，会逐渐变为一个从底层到UI层的一个全链路的跨平台开发，技术人员分别负责SDK和UI层的开发。

在Flutter之前已经有很多跨平台UI解决方案，那为什么选择Flutter呢？

我们主要考虑性能和跨平台的能力。

以往的跨平台方案比如Weex，ReactNative，Cordova等等因为架构的原因无法满足性能要求，尤其是在音视频这种性能要求几乎苛刻的场景。

而诸如Xamarin等，虽然性能可以和原生App一致，但是大部分逻辑还是需要分平台实现。

我们可以看一下，为什么Flutter可以实现高性能：

原生的native组件渲染以IOS为例，苹果的UIKit通过调用平台自己的绘制框架QuaztCore来实现UI的绘制，图形绘制也是调用底层的API,比如OpenGL、Metal等。

而Flutter也是和原生API逻辑一致，也是通过调用底层的绘制框架层SKIA实现UI层。这样相当于Flutter他自己实现了一套UI框架，提供了一种性能超越原生API的跨平台可能性。

但是我们说一个框架最终性能怎样，其实取决于设计者和开发者。至于现在到底是一个什么状况：

在闲鱼的实践中，我们发现在正常的开发没有特意的去优化UI代码的情况下，在一些低端机上，Flutter界面的流畅性是比Native界面要好的。

虽然现在闲鱼某些场景下会有卡顿闪退等情况，但是这是一个新事物发展过程中的必然问题，我们相信未来性能肯定不会成为限制Flutter发展的瓶颈的。

在闲鱼实践Flutter的过程中，混合栈和音视频是其中比较难解决的两个问题，混合栈是指一个APP在Flutter过程中不可能一口气将所有业务全部重写为Flutter，所以这是一个逐步迭代的过程，这期间原生native界面与Flutter界面共存的状态就称之为混合栈。闲鱼在混合栈上也有一些比较好的输出，例如FlutterBoost。

外接纹理

在讲音视频之前需要简要介绍一下外接纹理的概念，我们将它称之为是Flutter和Frame之间的桥梁。

Flutter渲染一帧屏幕数据首先要做的是，GPU发出的VC信号在Flutter的UI线程，通过AOT编译的机器码结合当前Dart Runtime，生成Layer Tree UI树，Layer Tree上每一个叶子节点都代表了当前屏幕上所需要渲染的每一个元素，包含了这些元素渲染所需要的内容。将Layer Tree抛给GPU线程，在GPU线程内调用Skia去完成整个UI的渲染过程。Layer Tree中有PictureLayer和TextureLayer两个比较重要的节点。PictureLayer主要负责屏幕图片的渲染，Flutter内部实现了一套图片解码逻辑，在IO线程将图片读取或者从网络上拉取之后，通过解码能够在IO线程上加载出纹理，交给GPU线程将图片渲染到屏幕上。但是由于音视频场景下系统API太过繁多，业务场景过于复杂。Flutter没有一套逻辑去实现跨平台的音视频组件，所以说Flutter提出了一种让第三方开发者来实现音视频组件的方式，而这些音视频组件的视频渲染出口，就是TextureLayer。

在整个Layer Tree渲染的过程中，TextureLayer的数据纹理需要由外部第三方开发者来指定，可以把视频数据和播放器数据送到TextureLayer里，由Flutter将这些数据渲染出来。

TextureLayer渲染过程：首先判断Layer是否已经初始化，如果没有就创建一个Texture，然后将Texture Attach到一个SufaceTexture上。

这个SufaceTexture是音视频的native代码可以获取到的对象，通过这个对象创建的Suface，我们可以将视频数据、摄像头数据解码放到Suface中，然后Flutter端通过监听SufaceTexture的数据更新就可以顺利把刚才创建的数据更新到它的纹理中，然后再将纹理交给SKIA渲染到屏幕上。

然而我们如果需要用Flutter实现美颜，滤镜，人脸贴图等等功能，就需要将视频数据读取出来，更新到纹理中，再将GPU纹理经过美颜滤镜处理后生成一个处理后的纹理。按Flutter提供的现有能力，必须先将纹理中的数据从GPU读出到CPU中，生成Bitmap后再写入Surface中，这样在Flutter中才能顺利的更新到视频数据，这样做对系统性能的消耗很大。

通过对Flutter渲染过程分析，我们知道Flutter底层需要渲染的数据就是GPU纹理，而我们经过美颜滤镜处理完成以后的结果也是GPU纹理，如果可以将它直接交给Flutter渲染，那就可以避免GPU-CPU-GPU这样的无用循环。这样的方法是可行的，但是需要一个条件，就是OpenGL上下文共享。

OpenGL

在说上下文之前，得提到一个和上线文息息相关的概念：线程。

Flutter引擎启动后会启动四个线程：

第一个线程是UI线程，这是Flutter自己定义的UI线程，主要负责GPU发出的VSync信号时候用当前Dart编译的机器码和当前运行环境创建出Layer Tree。

还有就是IO线程和GPU线程。和大部分OpenGL处理解决方案中一样，Flutter也采取一个线程责资源加载，一部分负责资源渲染这种思路。

两个线程之间纹理共享有两种方式。一种是EGLImage(IOS是 CVOpenGLESTextureCache)。一种是OpenGL Share Context。Flutter通过Share Context来实现纹理共享，将IO线程的Context和GPU线程的Context进行Share，放到同一个Share Group下面，这样两个线程下资源是互相可见可以共享的。

Platform线程是主线程，Flutter中有一个很奇怪的设定，GPU线程和主线程共用一个Context。并且在主线程也有很多OpenGL 操作。

这样的设计会给音视频开发带来很多问题，后面会详细说。

音视频端美颜处理完成的OpenGL纹理能够让Flutter直接使用的条件就是Flutter的上下文需要和平台音视频相关的OpenGL上下文处在一个Share Group下面。

由于Flutter主线程的Context就是GPU的Context，所以在音视频端主线程中有一些OpenGL操作的话，很有可能使Flutter整个OpenGL被破坏掉。所以需要将所有的OpenGL操作都限制在子线程中。

通过上述这两个条件的处理，我们就可以在没有增加GPU消耗的前提下实现美颜和滤镜等等功能。

TPM

在经过demo验证之后，我们将这个方案应用到闲鱼音视频组件中，但改造过程中发现了一些问题。

上图是摄像头采集数据转换为纹理的一段代码，其中有两个操作：首先是切进程，将后面的OpenGL操作都切到cameraQueue中。然后是设置一次上下文。然后这种限制条件或者说是潜规则往往在开发过程中容易被忽略的。而这个条件一旦忽略后果就是出现一些莫名其妙的诡异问题极难排查。因此我们就希望能抽象出一套框架，由框架本身实现线程的切换、上下文和模块生命周期等的管理，开发者接入框架以后只需要安心实现自己的算法，而不需要关心这些潜规则还有其他一些重复的逻辑操作。

在引入Flutter之前闲鱼的音视频架构与大部分音视频逻辑一样采用分层架构：

1：底层是一些独立模块

2：SDK层是对底层模块的封装

3：最上层是UI层。

引入Flutter之后，通过分析各个模块的使用场景，我们可以得出一个假设或者说是抽象：音视频应用在终端上可以归纳为视频帧解码之后视频数据帧在各个模块之间流动的过程，基于这种假设去做Flutter音视频框架的抽象。

咸鱼Flutter多媒体开源组件

整个Flutter音视频框架抽象分为管线和数据的抽象、模块的抽象、线程统一管理和上下文同一管理四部分。

管线，其实就是视频帧流动的管道。数据，音视频中涉及到的数据包括纹理、Bit Map以及时间戳等。结合现有的应用场景我们定义了管线流通数据以Texture为主数据，同时可以选择性的添加Bit Map等作为辅助数据。这样的数据定义方式，避免重复的创建和销毁纹理带来的性能开销以及多线程访问纹理带来的一些问题。也满足一些特殊模块对特殊数据的需求。同时也设计了纹理池来管理管线中的纹理数据。

模块：如果把管线和数据比喻成血管和血液，那框架音视频的场景就可以比喻成器官，我们根据模块所在管线的位置抽象出采集、处理和输出三个基类。这三个基类里实现了刚才说的线程切换，上下文切换，格式转换等等共同逻辑，各个功能模块通过集成自这些基类，可以避免很多重复劳动。

线程：每一个模块初始化的时候，初始化函数就会去线程管理的模块去获取自己的线程，线程管理模块可以决定给初始化函数分配新的线程或者已经分配过其他模块的线程。

这样有三个好处：

一是可以根据需要去决定一个线程可以挂载多少模块，做到线程间的负载均衡。第二，多线程并发式能够保证模块内的OpenGL操作是在当前线程内而不会跑到主线程去，彻底避免Flutter的OpenGL 环境被破坏。第三，多线程并行可以充分利用CPU多核架构，提升处理速度。

从Flutter端修改Flutter引擎将Context取出后，根据Context创建上下文的统一管理模块，每一个模块在初始化的时候会获取它的线程，获取之后会调用上下文管理模块获取自己的上下文。这样可以保证每一个模块的上下文都是与Flutter的上下文进行Share的，每个模块之间资源都是共享可见的，Flutter和音视频native之间也是互相共享可见的。

基于上述框架如果要实现一个简单的场景，比如画面实时预览和滤镜处理功能，

1：需要选择功能模块，功能模块包括摄像头模块、滤镜处理模块和Flutter画面渲染模块，

2：需要配置模块参数，比如采集分辨率、滤镜参数和前后摄像头设置等，

3：在创建视频管线后使用已配置的参数创建模块

4：最后管线搭载模块，开启管线就可以实现这样简单的功能。

上图为整个功能实现的代码和结构图。

结合上述音视频框架，闲鱼实现了Flutter多媒体开源组件。

组要包含四个基本组件分别是：

1：视频图像拍摄组件

2：播放器组件

3：视频图像编辑组件

4：相册选择组件

现在这些组件正在走内部开源流程。预计9月份，相册和播放器会实现开源。

后续展望和规划

1：实现开头所说的从底层SDK到UI的全链路的跨端开发。目前底层框架层和模块层都是各个平台各自实现，反而是Flutter的UI端进行了跨平台的统一，所以后续会将底层也按照音视频常用做法把逻辑下沉到C++层，尽可能的实现全链路跨平台。

2：第二部分内容为开源共建，闲鱼开源的内容不仅包括拍摄、编辑组件，还包括了很多底层模块，希望有开发者在基于Flutter开发音视频应用时可以充分利用闲鱼开源出的音视频模块能力，搭建APP框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

Flutter面试：渲染原理

页面中的各界面元素（Widget）以树的形式组织，即控件树。Flutter通过控件树中的每个控件创建不同类型的渲染对象，组成渲染对象树。而渲染对象树在Flutter的展示过程分为三个阶段：布局、绘制、合成和渲染。

（一）布局

Flutter采用深度优先机制遍历渲染对象树，决定渲染对象树中各渲染对象在屏幕上的位置和尺寸。在布局过程中，渲染对象树中的每个渲染对象都会接收父对象的布局约束参数，决定自己的大小，然后父对象按照控件逻辑决定各个子对象的位置，完成布局过程。

为了防止因子节点发生变化而导致整个控件树重新布局，Flutter加入了一个机制——布局边界（Relayout Boundary），可以在某些节点自动或手动地设置布局边界，当边界内的任何对象发生重新布局时，不会影响边界外的对象，反之亦然。

二）绘制

布局完成后，渲染对象树中的每个节点都有了明确的尺寸和位置。Flutter会把所有的渲染对象绘制到不同的图层上。与布局过程一样，绘制过程也是深度优先遍历，而且总是先绘制自身，再绘制子节点。

以下图为例：节点1在绘制完自身后，会再绘制节点2，然后绘制它的子节点3、4和5，最后绘制节点6。

可以看到，由于一些其他原因（比如，视图手动合并）导致2的子节点5与它的兄弟节点6处于了同一层，这样会导致当节点2需要重绘的时候，与其无关的节点6也会被重绘，带来性能损耗。

为了解决这一问题，Flutter提出了与布局边界对应的机制——重绘边界（Repaint Boundary）。在重绘边界内，Flutter会强制切换新的图层，这样就可以避免边界内外的互相影响，避免无关内容置于同一图层引起不必要的重绘。

重绘边界的一个典型场景是Scrollview。ScrollView滚动的时候需要刷新视图内容，从而触发内容重绘。而当滚动内容重绘时，一般情况下其他内容是不需要重绘的，这时候重绘边界就派上用场了。

（三）合成和渲染

终端设备的页面越来越复杂，因此Flutter的渲染树层级通常很多，直接交付给渲染引擎进行多图层渲染，可能会出现大量渲染内容的重复绘制，所以还需要先进行一次图层合成，即将所有的图层根据大小、层级、透明度等规则计算出最终的显示效果，将相同的图层归类合并，简化渲染树，提高渲染效率。

合并完成后，Flutter会将几何图层数据交由Skia引擎加工成二维图像数据，最终交由GPU进行渲染，完成界面的展示。

四、总结

咱们从各种业界主流跨端方案与Flutter的对比开始，到Flutter的简要介绍以及Flutter的运行机制，并以界面渲染过程为例，从布局、绘制、合成和渲染三个阶段讲述了Flutter的实现原理。相信大家对Flutter已经有一个整体认知，赶快一起上手操作起来吧！

跨平台技术；H5和Flutter谁是未来？

前言

为什么跨平台是发展趋势？

同一个应用，各个“端”独立开发，不仅开发周期长，而且人员成本高。同时，作为技术人员，也不应该满足于这种重复、低能的工作状态。在这样的形势下，跨平台的技术方案也受到越来越多人和企业的关注。

本篇文章我将从原理、优缺点等方面为大家分享跨平台技术

一. H5

说到跨平台，没人不知道H5。不管是在Mac、Windows、Linux、iOS、Android还是其他平台，只要给一个浏览器，连“月球”上它都能跑。

1.浏览器架构

下面，我们来看看让H5如此横行霸道的浏览器的架构：

浏览器由以上7个部分组成，而“渲染引擎”是性能优化的重中之重，一起了解其中的渲染原理。

2.渲染引擎原理

不同的浏览器内核不同，渲染过程会不太一样，但主要流程还是一致的。

分为下面6步骤：

从以上6步，我们可以总结渲染优化的要点：

以上就是浏览器端的内容。但H5作为跨平台技术的载体，是如何与不同平台的App进行交互的呢？这时候JSBridge就该出场了。

3.JSBridge原理

JSBridge，顾名思义，是JS和Native之间的桥梁，用来进行JS和Native之间的通信。

通信分为以下两个维度：

那么App内加载H5的过程是什么样的呢？

4.App打开H5过程

打开H5分为4个阶段：

这四步，对应的过程如上图所以，我们可以针对性的做性能优化。

5.优缺点分析

下面，我们进行H5的优缺点分析：

优点

缺点

虽然H5目前还存在不足，但随着PWA、WebAssembly等技术的进步，相信H5在未来能够得到越来也好的发展。

二.小程序

2018年是微信小程序飞速发展的一年，19年，各大厂商快速跟进，已经有了很大的影响力。下面，我们以微信小程序为例，分析小程序的技术架构。

小程序跟H5一样，也是基于Webview实现。但它包含View视图层、App Service逻辑层两部分，分别独立运行在各自的WebView线程中。

1.View

可以理解为h5的页面，提供UI渲染。由WAWebview.js来提供底层的功能,具体如下：

每个窗口都有一个独立的WebView进程，因此微信限制不能打开超过5个层级的页面来保障用户体验。

2. App Service

提供逻辑处理、数据请求、接口调用。由WAService.js来提供底层的功能,具体如下：

运行环境：

仅有一个WebView进程

3.View App Service通信

视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层将触发的事件通知到逻辑层进行业务处理。

4. 优缺点分析

优点

缺点

既然WebView性能不佳，那有没有更好的方案呢？下面我们看看React Native。

三.React Native

RN的理念是在不同平台上编写基于React的代码，实现Learn once, write anywhere。

Virtual DOM在内存中，可以通过不同的渲染引擎生成不同平台下的UI，JS和Native之间通过Bridge通信

1.React Native 工作原理

在 React 框架中，JSX 源码通过 React 框架最终渲染到了浏览器的真实 DOM 中，而在 React Native 框架中，JSX 源码通过 React Native 框架编译后，与Native原生的UI组件进行映射，用原生代替DOM元素来渲染，在UI渲染上非常接近Native App。

2.React Native 与Native平台通信

3.优缺点分析

优点

缺点

4.RN展望

虽然RN还存在不足，但RN新版本已经做了如下改进，并且RN团队也在积极准备大版本重构，能否成为开发者们所信赖的跨平台方案，让我们拭目以待。

既然React Native在渲染方面还摆脱不了原生，那有没有一种方案是直接操控GPU，自制引擎渲染呢，我们终于迎来了Flutter！

四.Flutter

Flutter是Google开发的一套全新的跨平台、开源UI框架，支持iOS、Android系统开发，并且是未来新操作系统Fuchsia的默认开发套件。渲染引擎依靠跨平台的Skia图形库来实现，依赖系统的只有图形绘制相关的接口，可以在最大程度上保证不同平台、不同设备的体验一致性，逻辑处理使用支持AOT的Dart语言，执行效率也比JavaScript高得多。

1.Flutter架构原理

2.Dart优势

很多人会好奇，为什么Flutter要用Dart，而不是用JavaScript开发，这里列下Dart的优势

3.优缺点分析

优点

缺点