13518219792
文/陈炉军
昭苏网站制作公司哪家好，找成都创新互联！从网页设计、网站建设、微信开发、APP开发、自适应网站建设等网站项目制作，到程序开发，运营维护。成都创新互联从2013年开始到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联。
整理/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框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。
既然有了 Metal 我们是否还有学习 OpenGL ES 的必要呢.我个人认为暂时还是有必要的.OpenGL /OpenGL ES/ Metal 在任何项目中解决问题的本质就是利用GPU芯片来⾼效渲染图形图像.所以它们底层的原理相近,首先了解OpenGL之后再去了解Metal会更加容易, 其二OpenGL是跨平台的框架.保不齐以后会在其他的地方用到,所谓技多不压身.毕竟不可能保证一直都做苹果开发吧.
理论枯燥且乏味, 但是我们联想一下flutter开发中用到的context, iOS开发中CoreGraphics里也有用到context. 是不是此时心中就有了一定的答案.我个人理解其设计模式大同小异. 顾名思义我们能够通过context拿到很多必要的状态和数据.
比如需要显示一个正方形, 则需要两个正等边三角形图元来完成
为了读取效率起见, 提前分配一块显存, 将顶点数组存放在显存中. 这部分显存就叫做 顶点缓冲区
OpenGL渲染的过程中会经历很多节点. 这些节点串起来就是管线.
常见的着⾊器主要有: 顶点着⾊器(VertexShader) , ⽚段着⾊器(FragmentShader) , 几何着⾊(GeometryShader) , 曲⾯细分着⾊器(TessellationShader)
OpenGL ES 中只⽀持 顶点着⾊器 和 片段着⾊器 .
光栅化就是把顶点数据转换为片元的过程。片元中的每一个元素对应于帧缓冲区中的一个像素。
如果把渲染比作是画画, 那么顶点着色器操作相当与确定画的内容的框架. 而之后往框架里填充内容的过程就是光栅化.
填充好内容之后就是片元着色器操作像素点填充颜色等操作
这里附上一张流程图:
纹理可以理解为图⽚。 在渲染图形时需要在顶点围成的区域中填充图⽚，使得场景更加逼真。⽽这⾥使⽤的图⽚，就是常说的纹理。只是在OpenGL，我们更加习惯叫纹理，⽽不是图⽚。
在出现布局错误时能尽快找到错误原因。
以下是对关键内容的翻译和注解。
flutter的布局模型是“一步布局模型”（one-pass layout model），在渲染树中，向下treewalk传递给子 盒约束，然后再向上treewalk将计算好的几何形状(比如高度、宽度等)传递给父。我理解one-pass layout model就是一遍就将布局计算好。不会多次treewalk去计算布局，或多次重绘(repaint)并多次计算布局。
计算的好的几何形状必须符合盒约束的要求。
盒约束有四个值，minWidth,maxWidth,minHeight,maxHeight，符合盒约束的意思就是说 计算出的宽高必须在最大值和最小值之间 。
我猜测，在将盒约束向子传递的过程中，子会根据父的盒约束，设置自己的盒约束，而不是单纯的继承父的盒约束。稍后结合Flex布局可以解释。
盒约束的最小值和最大值相等。因此在tight约束下的子的高宽将等于父的高宽，也就是说子是紧紧(tight)贴着父的。
盒约束的最小值为0，也就是说子可以是小于盒约束最大值的任何值，也就是说子是不紧贴(松的，loose)父的。
盒约束的最大值不是infinite(无穷大)
盒约束的最大值是infinite(无穷大)
盒约束的最小值是infinite(无穷大)，他的子的宽或高只能取无穷大。
子的宽高(Size)符合盒约束的要求。
以下摘抄原文档并翻译，并加以分析。为了关注要点， 忽略crossAxis方向(水平方向)的处理 。
以下图为Column布局实例。
给column布局进行了以下6步操作
首先给每个非flex子元素，设置竖直方向unbounded(无界)的盒约束。结合图片，也就是将1、2两个子设置好竖直方向无界的盒约束。示例中1和2设置了高度，因此一共占用高度是5+3=8.
按flex的比例给flex元素分配剩余的空间。因为示例只有一个flex元素，即3号元素，因此将占有剩余全部空间，高度是20-5-3 = 12。
在第二步中分配好空间的flex元素，给他设置的盒约束不是竖直方向unbounded(给非flex元素设置的是竖直方向unbounded)，而是有界的盒约束，盒约束的maxHeight是12，即第二步中被分配的高度。
水平方向不解释了。高度设置完了他去设置宽度。
Column组件的总高度是由mainAxisSize属性决定的，如果值是MainAxisSize.max，Column的高度就是Column的盒约束的maxHeight值，示例中我们给Column设置了高度为20的bounded盒约束，假设Column.mainAxisSize=MainAxisSize.max,那么Column的高度就是20.如果mainAxisSize=MainAxisSize.min，Column的高度将由其子元素的高度和决定。假设3号flex元素不设置成flex元素，而是固定高度为8，那么Column的高度就是5+3+8=16.
设置子元素的位置，即设置靠左，靠右，居中，分散等，与本示例关系不大。
根据第一步，inner column被outer column设置了无界(unbounded)的盒约束，Column会紧包children，而inner column的Expanded要撑开以占用inner column的剩余空间，这就冲突了。
解决方案:给inner column设置有界的盒约束即可。比如给inner column外包一层有高度的Container。
下面这种方案，给inner column包一层Expanded也可以，是因为在outer column中，Expanded会被设置成有界的盒约束(结合第三步)，因此Expanded就可以向外扩展(expand)了。
CustomPaint class提供了让用户自定义widget的能力，它暴露了一个canvas，可以通过这个canvas来绘制widget，CustomPaint会先调用painter绘制背景，然后再绘制child，最后调用foregroundPainter来绘制前景，CustomPaint的定义如下
CustomPaint的绘制过程都将会交给CustomPainter来完成，CustomPainter是个抽象接口，在子类化CustomPainter的时候必须要重写它的 paint 跟 shouldRepaint 接口，可以根据自己的场景来选择性的重写 hitTest 跟 shouldRebuildSemantics 方法。
canvas--画布，真正的绘制是由canvas跟paint来完成的，画布提供了各种绘制的接口来绘制图形，除此以外画布还提供了平移、缩放、旋转等矩阵变换接口，画布都有固定大小跟形状，还可以使用画布提供的裁剪接口来裁剪画布的大小形状等等。
常用的绘制接口有 更多请查看官方文档
Paint---笔画，是用来设置在画布上面绘制图形时的一些笔画属性，如：颜色、线宽、绘制模式、抗锯齿等等。常用属性有 更多请查看官方文档
color ： 设置画笔颜色
isAntiAlias ： 设置画笔是否扛锯齿
shader : 着色器，填充形状或者画线时用到，如果没设置将会使用color
strokeWidth ： 设置画笔画线宽度
style ：绘制模式，画线或充满
下面这个例子来自于官方，通过 CustomPaint 画出了一个蓝天跟太阳出来
效果如下：
页面中的各界面元素（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已经有一个整体认知，赶快一起上手操作起来吧！
1.要绘制贝塞尔线，我们需要四个点： 起点 ， 终点 和 两个控制点 ，如下图所示。移动控制点会改变曲线的斜率。您可以在此 在线工具中 使用控制点。
我们可以使用类Path的cubicTo方法绘制贝塞尔曲线：
使用控制点（x1，y1）和（x2，y2）添加从当前点到给定点（x3，y3）的曲线的三次贝塞尔曲线段。
如您所见，该cubicTo方法接受三个参数。其中两个是控制点，最后一个参数是终点。起点是您的笔已经位于画布上的位置。
不要忘记在画布坐标中，左上角是（0,0）点，右下角是（size.width，size.height）。因此，请尝试相应地调整四点：
请记住，paint对象就像我们的笔，我们将其颜色设置为蓝色，宽度设置为3。
我们用path对象描述了bezier路径。该moveTo方法已用于将笔移动到路径的起点。然后我们调用cubicTo方法来定义控制点和终点。之后，我们使用该drawPath方法绘制了路径。
贝塞尔曲线参考:
///推荐一些曲线图/折线图/柱状图参考:
all first_rank_v2~rank_v25-2-95632571.nonecaseutm_term=flutter%20%E5%8A%A8%E6%80%81%E7%BB%98%E5%88%B6%E6%9B%B2%E7%BA%BF
