十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
目前Flutter平台主流的两个播放器是video_player和fijkplayer
创新互联专注于雁塔企业网站建设,自适应网站建设,商城系统网站开发。雁塔网站建设公司,为雁塔等地区提供建站服务。全流程按需制作网站,专业设计,全程项目跟踪,创新互联专业和态度为您提供的服务
pub
github
1、Flutter平台官方插件,作者是国外的,有问题沟通比较困难,只能通过提交issue
2、硬解码
4、UI封装: better_player
基于video_player和Chewie的高级视频播放器。它解决了许多典型的用例,并且易于运行。
5、播放器宽高比例与视频内容宽高比例不一致时,会出现图像压缩变形的问题
6、调用原生内核播放器:iOS--AVPlayer, Android--ExoPlayer
7、对于分段源 m3u8 的播放不友好,如果一个切片播放超时,会导致整个播放都失败
8、better_player可以缓存视频,但不能自定义缓存的地址,只能指定key,和缓存的最大内存量(还未研究超出最大的话是不能缓存新的,还是删除最旧的)
9、better_player不能完全自定义UI,只能修改类中的一些开放属性,比如说icon图标,文字颜色啥的
10、无网络有缓存时,封面可以正常展示
11、better_player播放失败有手动retry的设计
pub
github
1、fijkplayer 是一个 Flutter 生态的媒体播放器,是对 ijkplayer 的 Flutter 封装,支持 Android 和 iOS。 fijkplayer 使用 ijkplayer 作为播放器内核,ijkplayer 使用 ffmpeg 进行音视频解封装和解码,同时添加了 Android 和 iOS 平台特有的硬件加速解码能力。
2 、国内有QQ群,但是活跃度也是不高。
3、可以缓存视频,可以自定义缓存的地址,方便后续的内存维护。
4、可以通过FijkPanelWidgetBuilder较大程度上自定义UI。
5、无网络有缓存视频时,无法展示封面,因为内部是通过imageProvider去加载网络图片的。
7、播放失败无手动retry的设计
1、两种播放器都是通过外接纹理方案 (Texture),将播放器视频画面渲染接入 flutter 中,性能上优于 PlatformView 的接入方法。
如何自己实现?
下面以video_palyer的iOS源码部分解释:
iOS用CVPixelBufferRef将渲染出来的数据存在内存中,Flutter engine会将Texture的数据在内存中直接进行映射无需通过Channel传输,然后Texture Widget就可以把你提供的这些数据显示出来。在我们传输数据的时候会需要将其与 TextureID 绑定,绑定的过程通过BasicMessageChannel实现数据流的传输,以做到实时展示的效果
有两种方法,一,自己找人才从零开始研发,当然要耗费对应的时间和资金,并且需要多次调试,不能绝对保证能提供良好的体验感;二,直接接入第三方互联网巨头研发的视频通话SDK,要想快速搭建的话,建议选择后者,即构科技的产品就不错,可以提供90天的体验。
文/陈炉军
整理/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教程全套 (全网独家)百度网盘免费资源在线学习
链接:
提取码: m9z8
Flutter教程全套 (全网独家)
第一套:Flutter 携程17章全-整理好
第五套:Flutter高仿谷歌翻译项目课程
第四套:两小时掌握Flutter移动App开发视频
第三套:flutter入门到精通全套
第七套:Flutter小实战20个
第六套:仿直聘boss的flutter完整教程
第九套:Flutter跨平台开发
第二套:flutter移动电商实战-技术胖
第八套:Flutter基础教程(基础不好的优先看)
24Flutter的打包.mp4
23静态资源和项目图片的处理.mp4
22页面跳转并返回数据_.mp4
21导航的参数传递和接受-2_.mp4
20导航的参数传递和接受-1.mp4
Flutter 零基础入门实战视频教程 #01 环境搭建 「14:03」
Flutter 零基础入门实战视频教程 #02 Dart 语言 「17:49」
Flutter 零基础入门实战视频教程 #03 建立 Android studio 虚拟设备 「04:12」
Flutter 零基础入门实战视频教程 #04 建立第一个项目 「08:23」
Flutter 零基础入门实战视频教程 #05 安装配置过程中可能遇到的问题(没遇到者可以跳过) 「05:07」
Flutter 零基础入门实战视频教程 #06 运行 iOS 模拟器 「04:07」
Flutter 零基础入门实战视频教程 #07 Flutter 概述 「06:15」
Flutter 零基础入门实战视频教程 #08 Scaffold AppBar 「Pro」「06:50」
Flutter 零基础入门实战视频教程 #09 文档和快捷键 「Pro」「02:36」
Flutter 零基础入门实战视频教程 #10 颜色 Colors 「Pro」「05:47」
Flutter 零基础入门实战视频教程 #11 自定义字体 fonts 「Pro」「05:09」
Flutter 零基础入门实战视频教程 #12 hot reload StatelessWidget 「Pro」「04:56」
Flutter 零基础入门实战视频教程 #13 使用图片 「Pro」「04:59」
Flutter 零基础入门实战视频教程 #14 使用图标 - Icon 「Pro」「01:27」
Flutter 零基础入门实战视频教程 #15 Button 按钮使用指南 「Pro」「04:35」
Flutter 零基础入门实战视频教程 #16 Container 和 Padding 「Pro」「04: 52」
Flutter 零基础入门实战视频教程 #17 Row 「Pro」「05:24」
Flutter 零基础入门实战视频教程 #18 Column 「Pro」「05:36」
Flutter 零基础入门实战视频教程 #19 Flutter Outline Shortcuts 「Pro」「03:18」
Flutter 零基础入门实战视频教程 #20 Expanded Widgets 「Pro」「06:06」
Flutter 零基础入门实战视频教程 #21 实战开始 「Pro」「11:42」
Flutter 零基础入门实战视频教程 #22 换个编辑器 - Visual Studio Code 「Pro」「04:50」
Flutter 零基础入门实战视频教程 #23 Stateful vs Stateless Widget 「Pro」「09:45」
Flutter 零基础入门实战视频教程 #24 列表处理 「Pro」「04:54」
Flutter 零基础入门实战视频教程 #25 自定义 class 「Pro」「05:37」
Flutter 零基础入门实战视频教程 #26 card widget 「Pro」「04:26」
Flutter 零基础入门实战视频教程 #27 Extracting Widgets 「Pro」「06:59」
Flutter 零基础入门实战视频教程 #28 删除 - Functions as Parameters - 完结 - 进入实战课 「Pro」「04:35」
GITHUB地址:
我们依赖国际化的两个package:
intl_translation 是用来生成arb的翻译文件,所以添加的依赖只用在dev环境下
这里我们会创建一个代理文件
Provider使用起来学习成本更小而且管理容易
Provider
Provider学习文章
创建一个通知的基类
主题和语言改变发出通知
在main中注册
主题相对来说比较简单,不需要依赖太多外部的框架
global设置
在上面写的函数中可以找到,添加了通知
shared_preferences
shared_preferences很多人都已经用过了不做过多的介绍.主要说明下,如何把原来异步的任务变成同步.
shared_preferences 异步有两个地方,一个是初始一个是存储
项目初始化的时候,可以将shared_preferences初始化然后存储下来,shared_preferences在get的时候是同步的,我们就不需要处理了,存储的时候我们依旧是异步的,这样能解决app启动是需要初始化的参数问题
1.NavigationService 不需要context的push工具
2.ScreenService获取屏幕宽高工具
3.EventBusService 通知工具
.....