正文
flutter并发,flutter 快速开发
提示：扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
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框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。
相关问答
Q1: 离不开DART的Flutter（dart篇）
hello world例子
在终端打印字符串‘Hello World!’
计算斐波那契数列
一个简单的类
计算两点距离
异步并发示例
使用了Isolate
1.面向对象
对于面向对象这个概念，相信了解Java的同学对这个概念一定不会陌生。
例如：我们有个Person Object他有很多特征和行为。
这些都是这个Person Object的属性。
也就是因为有了这些特征，行为等等才决定了这个人是谁。
那么回到Dart当中，所有的都是对象，那么在就可以可以跟进对象的属性的特征，方法等等来进行编程。
之所以我们在这里又特别强调了一下面向对象的概念，是因为这个概念在Dart语言当中，至关重要！
2.最重要的几个概念
3.Dart的部分特性
4.Dart的内置库
包名
描述
dart:asynv
异步编程，提供Future，Stream类
dart：collection
集合
dart：convert
不同类型的字符编码解码
dart：core
Dart语言核心功能，内置类型
dart:html
网页开发用到的库
dart:io
文件读写，IO相关
dart:math
数字常量以及函数，随机算法等
dart:svg
事件和动画矢量图支持
综上述所说要想学Flutter，先学Dart！关于Flutter下篇我会讲到。为什么离不开dart！
有关更多面经、核心技术笔记；自己也是从事Android开发5年有余了；整理了一些Android开发技术核心笔记和面经题纲， 如有需要的同学请私信我回复“核心笔记”或“面试”领取！
Q2: 做混合的话Uniapp和Flutter我应该学哪个啊？
Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策
Q3: 过了40的“程序猿”会后悔当初进入这个行业吗？
真实来说，做程序员没有五年经验，根本无法理解其中的奥秘，很多高深的知识，比如框架设计，分布式原理，领域专用语言，这些高级点的知识，没书没材料没人讲，没经验根本就是要止步了，国内需要的根本就不是真正的程序员而是代码的搬运工，把业务给我写出来，加班写出来就行了。而国外，那些程序员都会去想着把业务写得更好，更具有创新，快捷，方便大众。还是思想的问题。忙着赚钱的公司太多。
你看看很多著名的框架，比如前端jQuery bootstrap 爬虫框架scrap，深度学习框架keras，TensorFlow. Flutter都是国外程序写的，还有大量的工具型无盈利网站，国内为啥写不出，很简单，因为在你正钻研更高深的知识的时候，把你裁掉，让你转行搞其他的，你自己饭碗都保不住，还怎么去想着搞？
中国企业很简单的一点就是，出业务，做PPT，拿融资，扩大推广，裁掉程序员，这叫卸磨杀驴。这是小中型企业的模式，招程序员就是看能不能加班，能不能抗压。
不想讲了，当兴趣不能当饭吃的时候，你们还怪这片土地出不了天才。
我年过40，进入这个行业已经二十多年了，总的来说，谈不上后悔，有得有失。现在谈谈我的几点感悟吧。
一、综合素质很重要
进入这个行业开始，就是做一个程序员，到后面成为了架构师，再到技术总监。给我的启示就是，偏科的程序员发展前景是有限的。综合素质包括沟通能力，领导能力和组织能力有时候比编程能力更为重要。有很多程序员不善于沟通，但是在中国 社会 ，沟通很重要，和领导的沟通，和同事的沟通，和下级的沟通。不会沟通的程序员，注定是难于转型的，只能干程序员，干编程，而编程是青春饭。
二、自学能力很重要
在IT这个行业，自学能力太重要了，不能自学最新的技术并运用到工作中，你会发现很快就跟不上这个行业的发展，工作起来力不从心，进而被淘汰。自学的过程中，合理的分配时间是关键，很多程序员平常工作很忙，基本没有时间去学习，而领导分配任务的时候是不会给你专门留出学习时间的，你只有合理利用好时间，忙里偷闲。
三、尽早向上“提升”
在中国，程序员做到30多岁就算“大龄”了，在这之前，就要考虑好自己的向上晋升渠道，是适合继续做技术？还是转型管理？如果还想做技术，必须要在技术上往上提升一层，能够达到架构师的水平，否则，30多岁的程序员如果被公司末位淘汰请不要吃惊。如果转型做管理，这个就要体现出你的管理能力，尽早被上司赏识，从 而 被提拔到管理岗位上。
一路走来，感悟很多，不管怎样，选择了程序员这个职位，就没必要后悔，后悔也没有用，愿天下所有程序员都 人生无悔，活在当下 。
人类 历史 长河中，各行各业有几个小黄人儿留下的东西？小黄人儿哪都短 不是吗？
这个问题应该不同人有不同答案吧，说说我自己吧，入行十几年了，谈不上后悔，但整体有点无奈。
回顾这十几年的经历，弯路没少走，错误没少犯，就算一些现在看来走对的路，也是误打误撞。
总结起来走过两个阶段，个人观点，仅供参考。
入行第一个阶段，无论职业规划是否正确，发展都还算顺利
这个阶段基本就是学习和工作的循环阶段，即便没有很明确的目标性，只要努力，薪资一般都会持续增长，所以现在回头看这个阶段，应该是最爽的一个阶段了。
当然，如果想要在这个行业持续做下去，并且中年以后依然可以游刃有余，最好能在这个阶段完成三件事外加明白一个道理
需要完成的三件事：
明白一个道理：
人过中年靠投简历找工作不太靠谱，需要为未来铺条路（也就是说一旦发生职业危机，他可以帮个忙），尽管这条路未必用得上，也但愿永远别用上。
也就是说要选择发展自己的技术优势还是人脉优势留在日后备用。
如果要发展技术优势，也就是人们常说的技术大牛，这个大牛可不是某个小技术团队的大牛，而是某个领域内切切实实的牛人，至少在某个领域内有一定的知名度。这就不仅仅对你个人努力程度有一定要求，还要看机遇。例如，你想成为并发领域专家，如果没有机会接触真真的大并发场景，仅仅靠啃几本书想成为这个领域的专家，无异于水中捞月。
如果要发展人脉，前提条件要求你也具备相当的技术能力，否则到时候别人怎么帮你也没用。
入行第二个阶段，决定未来职业走向的关键时期
如果第一个阶段随波逐流的走过来（注意，是随波逐流，不是混，如果是混过来，可能在第三四个年头就不好找工作了），除非运气特别好，否则在第二个六年中再找工作就会感觉力不从心了，也就是人们常说的实力和工龄不符。
然而这一切才刚刚开始，如果第二个阶段依然得过且过的工作，第三个阶段的职场将更加难混。
在这个阶段要完成的事情
需要确定好自己未来的职业方向，管理还是技术。
不论选择哪一个，在选择好之后最好确定一个偏向，因为无论管理还是技术，里面涉及的东西都太多，一个人有限的精力很难全面精通。
过了技术积累期之后，任何工作都离不开对业务的深入理解，这也意味着每一次跳槽都需要重新组建自己的业务架构。
因此，有一个可以持续打拼而不需要不断更换的平台就显得尤为重要。
以上就是十几年经历过的两个阶段的总结，至于后面该怎么走，依旧处于迷茫阶段^0^。
过了40的程序员基本上几百万的资产是有的，这是大多数人一辈子才能挣到的钱，所以应该说是很辛运的，大部分学计算机的其实一毕业就转行了，根本就进不了这个行业，进来的也会有不少半路不愿干或者干不下去转行的，中国大环境其实对程序员不是太友好，所以来说能干到40来岁的只有很少一部分。
