flutter网络封装,flutter 路由封装

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

Flutter开发--视频播放器

目前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实现数据流的传输，以做到实时展示的效果

相关问答

Q1: 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框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

Q2: Flutter Dio源码分析(四)--封装

Flutter Dio源码分析(一)--Dio介绍

Flutter Dio源码分析(二)--HttpClient、Http、Dio对比

Flutter Dio源码分析(三)--深度剖析

Flutter Dio源码分析(四)--封装

Flutter Dio源码分析(一)--Dio介绍视频教程

Flutter Dio源码分析(二)--HttpClient、Http、Dio对比视频教程

Flutter Dio源码分析(三)--深度剖析视频教程

Flutter Dio源码分析(四)--封装视频教程

github仓库地址

本文会手把手教你该怎么去封装一个类库，平时在我们的工作中都是拿着别人的造好的轮子在使用，这篇文章将带你怎么去自己造轮子，以后再碰到别的类库需要对其进行封装的时候提供一个的思路和方法。

在前面的文章中，我们对 Dio 的基本使用、请求库对比、源码分析，我们知道 Dio 的使用非常的简单，那为什么还需要进行封装呢？有两点如下：

当组件库方法发生重要改变需要迁移的时候如果有多处地方用到，那么需要对使用到的每个文件都进行修改，非常的繁琐而且很容易出问题。

当不需要 Dio 库的时候，我们可以随时方便切换到别的网络请求库，当然 Dio 目前内置支持使用第三方库的适配器。

因为一个应用程序基本都是统一的配置方式，所以我们可以针对拦截器、转换器、缓存、统一处理错误、代理配置、证书校验等多个配置进行统一管理。

因为我们的应用程序在每个页面中都会用到网络请求，那么如果我们每次请求的时候都去实例化一个 Dio ，无非是增加了系统不必要的开销，而使用单例模式对象一旦创建每次访问都是同一个对象，不需要再次实例化该类的对象。

这是通过静态变量的私有构造器来创建的单例模式

我们对超时时间、响应时间、 BaseUrl 进行统一设置

因为不管是 get() 还是 post() 请求， Dio 内部最终都会调用 request 方法，只是传入的 method 不一样，所以我们这里定义一个枚举类型在一个方法中进行处理

我们已经把 Restful API 风格简化成了一个方法，通过 DioMethod 来标明不同的请求方式。在我们平时开发的过程中，需要在请求前、响应前、错误时对某一些接口做特殊的处理，那我们就需要用到拦截器。 Dio 为我们提供了自定义拦截器功能，很容易轻松的实现对请求、响应、错误时进行拦截

我们发现虽然 Dio 框架已经封装了一个 DioError 类库，但如果需要对返回的错误进行统一弹窗处理或者路由跳转等就只能自定义了

在我们发送请求的时候会碰到几种情况，比如需要对非open开头的接口自动加上一些特定的参数，获取需要在请求头增加统一的 token

在我们请求接口前可以对响应数据进行一些基础的处理，比如对响应的结果进行自定义封装，还可以针对单独的 url 做特殊处理等。

我们看了转换器的介绍，发现和拦截器的功能差不多，那为什么还要存在转换器，有两点：

执行流程：请求拦截器请求转换器发起请求响应转换器响应拦截器最终结果。

只会被用于 'PUT'、 'POST'、 'PATCH'方法，因为只有这些方法才可以携带请求体(request body)

会被用于所有请求方法的返回数据。

在开发过程中，客户端和服务器打交道的时候，往往会用一个 token 来做校验，因为每个公司处理刷新token的逻辑都不一样，我这里举一个简单的例子

为什么我们需要有取消请求的功能，如果当我们的页面在发送请求时，用户主动退出当前界面或者app应用程序退出的时候数据还没有响应，那我们就需要取消该网络请求，防止不必要的错误。

由服务器生成的一小段文本信息，发送给浏览器，浏览器把 cookie 以kv形式保存到本地某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。

cookie 的使用需要用到两个第三方组件 dio_cookie_manager 和 cookie_jar

因为在我们平时的开发过程中，会碰到一种情况，在进行网络请求时，我们希望能正常访问到上次的数据，对于用户的体验比较好，而不是展示一个空白的页面，该缓存主要是《Flutter实战》网络接口缓存提供参考。

我们在程序退出后内存缓存将会消失，所以我们用 shared_preferences 进行磁盘缓存数据。

在我们用flutter进行抓包的时候需要配置 Dio 代理。由 DefaultHttpClientAdapter 提供了一个 onHttpClientCreate 回调来设置底层 HttpClient 的代理。

用于验证正在访问的网站是否真实。提供安全性，因为证书和域名绑定，并且由根证书机构签名确认。

日志打印主要是帮助我们开发时进行辅助排错

Q3: 【Flutter】利用Future封装出js中的Promise

前端的同学对 Promise 肯定都很熟悉，而 Future 便是 dart 中 Promise ，但方法名称和使用方式还是有些许的差异的。

下面我们尝试，利用 Future 封装出js中我们熟悉的 Promise 。

使用示例

Promise.all , Promise.race , Promise.resolve , Promise.reject

Promise.allSettled 方法接受一组 Promise 实例作为参数，包装成一个新的 Promise 实例。只有等到所有这些参数实例都返回结果，不管是 fulfilled 还是 rejected ，包装实例才会结束。该方法由 ES2020 引入

Promise.any() 方法接受一组 Promise 实例作为参数，包装成一个新的 Promise 实例。只要参数实例有一个变成 fulfilled 状态，包装实例就会变成 fulfilled 状态；如果所有参数实例都变成 rejected 状态，包装实例就会变成 rejected 状态。该方法目前是一个第三阶段的提案。

Promise.any() 跟 Promise.race() 方法很像，只有一点不同，就是不会因为某个 Promise 变成 rejected 状态而结束。

顺便把延迟函数也封装一下，毕竟毫秒延迟的使用频率是最高的。

Q4: Flutter 网络请求 Dio 拦截器详解

昔日的小王凭借这他的小心谨慎和借助漂亮能干的女友 Dio 的辅助，终于干下了一番事业，成为中华大地响当当的人物，小王也变成老王。如今，老王已经年近花甲，看似迈上了人生巅峰，却也遇到了人生的烦恼——那就是他的儿子，新的小王。

小王和他爹当年的小心谨慎不同，小王自海外留学回来，也不愿意接手老王的事业。反而迷恋起了互联网，玩游戏、微博喷人、撩网红等等。前两项倒还好，但是后一项，让老王心烦得很。这网红哪能随便撩的，万一弄出许多小小王来，多大家业都不够分的啊！

关键时刻，还是老王的媳妇，曾经被金屋藏娇的Dio 想出了新的招术，再次让老王佩服不已。老王媳妇Dio给小王搞了个拦截器，只要小王要在互联网做什么，都会被她给先拦截下来，然后她再根据小王要做的事情决定是不是要替他发出去；或者是收到什么消息的时候，也会先看一遍，没问题再给小王看。而且，最为关键的是，小王对这一切压根都不知道！

老王媳妇一开始是这么干的，小王在互联网有什么新的动向直接向老王汇报。

这下小王在互联网就完全被监视了——而且他压根不知道！只是，每次他说要钱的时候，老王不再随便给了！

但这个时候，小王还能在网上撩，毕竟上网在这个时代是不怎么要钱的。

老王媳妇 Dio 一看这种方式不行，就又心生一计，每次小王聊网红的时候，直接狠心拒绝！

小王这下子懵圈了，难道是他的那些“土味情话”已经失效了？每次发出去消息都遭受到了无情的打击，让他心灰意冷。渐渐地他就淡出了互联网，至于现在在干什么，谁也不知道。感觉又像是当初老王金屋藏娇一样，现在的小王也逐渐被隐藏了起来。从此，互联网只剩下小王和各个网红的传说。

借着老王和小王的故事，我们讲述了 Dio 的封装和 Dio 的拦截器。其中拦截器可以应用于很多实际场景：

注意，Dio 的实例可以同时添加多个拦截器，以便处理不同的情况。

Q5: Flutter发布Package(Pub.dev或私有Pub仓库)

因为我们使用Flutter跨平台技术开发App时，会有很多公用组件，因为Flutter中一切皆为Widget，widget也比较细粒度，所以我们需要进行封装，用于一个项目或者公司不同项目中去~

那么今天写写如何发布package或者插件到Pub.dev上，扯扯谈O(∩_∩)O哈哈~

《Flutter的拨云见日》系列文章如下：

1、Flutter中指定字体(全局或者局部，自有字库或第三方)