闲鱼flutter游戏,闲鱼放弃fluttergo

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

闲鱼前端基于serverless的一种多端开发解决方案

前端的发展太快了，前端框架和技术的发展也层出不穷，还包括不同智能设备的出现，对前端开发同学来说是个很大的跳转，简单列举下：

这样就滋生了一些问题，比如我要开发一个通用的页面，兼容不同的端侧和小程序，显然目前是做不到的，我们只能开发多套页面去适配不同的场景，这样的话成本就太高了。

很多同学都在尝试解决这个问题，也催生了类似taro这样的多端统一开发框架，这是一个好的解决方案，但是比较被动，缺乏一定的扩展性。

这篇文章我们要探讨的是，看能不能换个角度去解决这个问题，提升开发效率。

ViewModel

当我们在开发一个页面的时候，不管用的是哪一种框架，通常都会抽象出一层viewmodel层，它主要有2个作用

从上图中我们可以看出，viewmodel是一段独立的通用代码逻辑，起到了承前启后的作用。它和view层关系更加紧密，因此通常会放在前端测。

既然viewmodel是独立的，那我们能不能把它放在后端呢？这样一个最大的好处就是viewmodel可以进行复用，不需要在重复编写，而且只需要改动一个viewmodel，就可以全量生效。

似乎是一个很美好的想法，但是这部分代码由谁去开发呢，总不可能寄希望于后端同学吧，当然只能是我们自己，也感谢于serverless架构的出现，让这件事情变成了可能。

有些同学可能会问，既然viewmodel后移了，那view呢？后续会考虑结合我们的ui2code技术，那真的就比较完美了。

什么是serverless

架构上，我们可以把serverless分为FaaS和BaaS。

FaaS是用于创建、运行、管理函数服务的计算平台，它支持多种开发语言，比如java、nodejs、dart等，这有利于不同端侧的开发同学介入开发。FaaS是基于事件驱动的思想，只有当一个函数被事件触发时才会占用服务器资源执行，不然都是无需占用服务器资源的。

BaaS提供了用于函数调用的第三方基础服务，比如身份校验、日志、数据库等，它是由服务商直接提供，开发者无需关系实现，直接调用即可。

业务落地

我们是通过gaia平台开发后端接口，gaia可以理解为上文提到的FaaS平台。

日常开发中有这样一个需求，下面是这个需求的一个页面。

因为这个页面上的数据比较多，先把它切分成一个个小的模块，后台返回数据的时候也根据模块来返回数据。

我们是根据viewmodel来设计接口，首先肯定有一个首屏数据接口；然后是页面上的交互，比如切换卡片、切换芝麻信用按钮，切换会引起页面数据变化，我们可以统一封装一个页面更新的接口；最后是一个开通的接口。

后端接口

前后端交互最重要的数据结构的设计，我们省略了中间的业务逻辑处理，看下接口的数据结构。

首屏接口返回的数据主要有几个特征：

更新接口的返回数据结构和首屏接口类似，但是入参有所不同，主要包括2个字段：

前端处理

从后端返回的数据可以看到，数据是及其详细的，无需我们做任何的业务逻辑处理，直接映射到页面即可。这样，前端已经变成了很薄的一层数据，没有任务的业务逻辑处理，变的很简单，当需要迁移到其他端时，只需要迁移视图层即可。当有任何的业务变动时，只需要修改后端的接口，就能生效。

收益与总结

通过具体的实践，我们发现，对于前端开发同学来说，变的简单了，开发效率有很大的提升，前端同学甚至都不需要去理解具体的业务逻辑，就能完成页面的开发。而且，提取的viewmodel可以复用到不同的端侧，设置还包括native端。我们还可以将viewmodel拆分成更小粒度的viewmodel，方便在不同的页面接口中进行复用。我们有同学还在FaaS侧基于redux的思想封装了一个通用的状态管理框架，规范了前后端的交互。

后面，还有一些问题待我们去解决，比如开发成本、viewmodel的逻辑拆分、具体接口问题定位等。

闲鱼团队是Flutter+Dart FaaS前后端一体化新技术的行业领军者，就是现在！客户端／服务端java／架构／前端／质量工程师面向社会招聘，base杭州阿里巴巴西溪园区，一起做有创想空间的社区产品、做深度顶级的开源项目，一起拓展技术边界成就极致！

*投喂简历给小闲鱼→ guicai.gxy@alibaba-inc .com

开源项目、峰会直击、关键洞察、深度解读

请认准闲鱼技术

相关问答

Q1: 像美团外卖这样的APP用一种开发语言，能开发得出来吗？

像美团外卖这样的APP用一种开发语言，能开发得出来吗？答案是不能。

美团发展到现在可以说已经是一个【巨无霸】了，里面集成了很多很多功能，除了核心的外卖，还有旅游、娱乐、购物、出行，金融等等业务线，那么这么多复杂的业务根本不可能用同一种开发语言实现。

那么美团都用到哪些开发语言和技术了呢？下面就根据我的理解详细说一下。

前端是把产品的核心服务交给用户的呈现者，它的表述方式、展示形式以及交互逻辑都跟用户息息相关，都影响着用户使用产品的体验，也就是说直接影响产品的用户留存。

前端开发主要分为三大类型：Andriod、IOS和PC（H5） ,Android开发语言是Kotlin和Java，IOS开发语言是Object-c和Swift，PC（H5）开发语言就比较杂了，有JS、CSS、HTML，还有很多第三方的前端框架，比如Angular.js、vue.js、Bootstrap、JQuery等等。

关于后端的功能，这一点可以说是众说纷纭，主要需要考虑的是如何实现功能、数据的交互流程和存取、平台的稳定性与性能等。

那么后端都用到哪些开发语言和技术呢？

根据后端技术选型的标准，后端可选的开发语言和技术是非常多的。

比如Java体系的话，可以选用SpringMVC、Spring cloud、Hibernate，Mybatis、Mysql、Redis、Memcache、zookeeper、Kafka......；

比如Python体系的话，可以选用Django、Flask、Tarnado、Web2py等，中间件都是通用的，Redis，MQ、MySQL、Kafka等都可以用在python体系中；

当然还有PHP、C、Perl等开发语言。

综上所述，美团这个巨无霸公司，随着业务线的扩展用到的技术肯定会越来越多，而且越来越复杂，技术快速变革的时代，适者生存的竞争性也会越来越激烈。

俗话说：罗马不是一日建成的，任何事都不可能一蹴而就，包含技术。在以后的发展中美团也会逐步更新自己的技术和开发语言的。

至少三种语言。后端一种语言（比如Java丶Go丶Python丶PHP等），后端语言及生态比较成熟。下面重点聊前端App开发。

前台两种语言（Android和iOS是不同的开发环境。比如Android用Java或者Kotlin，iOS采用Object C++或Swift），称之为Native开发。

当然创业公司可以用一种前端语言写App前端，这样就不需要Android和苹果分两种语言写，写一次代码可以编译成Android和iOS的App，现在通行的方案有Vue之类的DOM渲染模式，以及ReactNative方案（RN）。性能上RN优于DOM渲染但低于用Native开发的App。所以美团这种公司，一定是Native方式写App，但RN是初创项目不错的选择。

与RN竞争的还有一种新贵flutter，是google推出来的，但设计原理与RN不同，性能方面优于RN，只是目前生态不够健全，国内有闲鱼app是采用此技术。未来可能会占一席之地。

最后，其实App开发已经是强努之末，我觉得主流应该是朝PWA和小程序方向发展。

你好，开发譬如美团这种APP，用一种语言是实现不了的，一个APP有安卓和苹果两个操作系统，开发能在安卓iOS端应用的APP主流的开发语言和技术是很多的，如后台有JAVA、C++、PHP、Python等多种开发语言，前端有kotlin、HTML、css、jquery、ajax、bootstrap、angular.js、react、vue.js、node.js、swift、object-c等多种语言和框架。

一个APP的开发是需要前端技术和后台技术共同配合完成，这样的APP不论是功能还是性能都给用户很好的体验，单一开发语言毕竟技术支持有限，所以即使能开发出来，APP的用户体验也是不理想的。

一般APP有这几种开发组合模式：1、原生安卓iOS开发，前端：JAVA、kotlin、swift、object-c后台：JAVA、PHP、C++等后台技术，这种模式开发周期长，成本高，性能好；2、混合APP开发即hybrid app，前端以网页技术为主，穿插原生开发功能，兼具原生APP和web app的优点，如淘宝、微信等应用都是走的这个技术；3、web app，前端纯网页技术，后台为主流开发语言，这种模式开发速度快，成本低，界面体验可能弱一些。

可见开发一款APP大多数都是多种语言配合完成，谢谢阅读。

看完之前的评论，依然好奇为什么一个语言不能完全胜任。

前端跨平台的方案有react native，cordova,flutter等，如果需要兼容开发小程序，h5页面，可以采用taro来开发，一套代码，所有平台通吃。

后端的方案有服务端运行时nodejs，大数据背景下运用而生的数据库mobgodb，缓存解决方案redis，搜索工具elasticsearch，负载均衡ngix，基本上是需要什么就有什么

所以总结下来，一句话，一种语言可以实现类似美团这样的app和小程序。为什么美团使用的语言那么多，一大原因估计是美团app开发的早，当时前端技术不成熟，工具没现在这么多。

使用混合开发与C++ 进行跨平台开发，有好有坏。

C++ 进行跨平台开发

编写一次，随处运行。早在 2013 年，Dropbox 就采用上述策略进行移动开发，这背后的想法很简单：用 C++ 编写一次代码，而不是用 Java 和 Objective-C 编写两次。那时，整个移动工程团队相对还比较小，但需要支持快速增长的移动路线图。因此，公司希望找到一种方法，使这个小团队可以快速交付大量 Android 和 iOS 代码。

如今，Dropbox 完全放弃了这个策略，转而使用各个平台的原生语言（主要是 Swift 和 Kotlin ，这两种语言在刚开始制定移动策略时还不存在）。

Hybrid App混合开发

Hybrid App主要以JS+Native两者相互调用为主，从开发层面实现“一次开发，多处运行”的机制，成为真正适合跨平台的开发。Hybrid App兼具了Native App良好用户体验的优势，也兼具了Web App使用HTML5跨平台开发低成本的优势。

目前已经有众多Hybrid App开发成功应用，比如美团、爱奇艺、支付宝等知名移动应用，都是采用Hybrid App开发模式。

移动应用开发的方式，目前主要有三种：

几种模似都可以开发出应用，小应用无所谓，但是大流量应用，对图形要求高的如游戏等原生开发的效果还是最好

支付宝打开很慢，就是因为采用混合开发，使用人多了不如原生开发

不行的哦。任何你看到的应用和网页，都需要多个语言开发的，大的分比如前端和后端，用的语言都是不一样的

Q2: 开源精粹（二）！22个实用、有趣的开源项目

作为一名开源爱好者，发掘优秀的开源项目是一件非常有趣的事情。在第一期中，我分享了单页个人网站模板、组装式 Flutter 应用框架、PHP 客户端库、Java 诊断工具等一些实用的库和工具。本期依旧会为大家分享一些前端、后端、移动开发的相关工具，希望你能“淘”到适合自己的工具。

1.Vue-EasyTable

Vue-EasyTable 是一款基于 Vue2.x 的 table 组件，具备自适应、表头与列固定、自定义单元格样式、自定义 Loading 等功能。

2.React-Calendar

这是一款具备原生日期格式的日历组件。它不依赖 Moment.js，支持日期选择范围，涵盖了各国语言，开箱即用。

3.Matter

CSS 实现的 Material 组件合集项目，作者已将部分作品开源，效果可以在 CodePen 上查看。

4.Revery

Revery 是一款用于构建高性能、跨平台桌面应用的框架。它类似于加速版的原生 Electron，除了拥有类似 React / Redux 的库，还具备 GPU 加速渲染功能，其内置的编译器速度也相当快。

5.Web Accessibility Guide

这是一个精选了 Web 可访问性贴士、技巧和最佳实践的开源项目，你将会学习到一些改善 Web 可访问性的实用做法。

1.SOFAJRaft

SOFAJRaft 是蚂蚁金服开源的生产级 Java Raft 算法库，它基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景，易于使用。

2. Dragonwell

阿里开源了 OpenJDK 发行版 Dragonwell，它提供长期支持，包括性能增强和安全修复。在数据中心大规模 Java 应用部署情况下，可以大幅度提高稳定性、效率以及性能。

3.Lawoole

Lawoole 是一款基于 Laravel 和 Swoole 的高性能 PHP 框架。它兼具了 Laravel 的特点，还解决了其功能背后的性能问题。同时，你还能感受到与 Laravel 一样的编码体验。

4.AntNest

AntNest 是一个简洁、快速的异步爬虫框架。它仅有 600 行代码，基于 Python 3.6+.

5.PHP-Awesome

这个仓库汇集了 PHP 优秀的资源，供你查询和参考。

1.FlutterBoost

FlutterBoost 是闲鱼开源的新一代 Flutter-Native 混合解决方案。它能够帮你处理页面的映射和跳转，你只需要关心页面的名字和参数即可。

2.MyLayout

MyLayout 是一套 iOS 界面视图布局框架，可谓 iOS 下的界面布局利器。它集成了 iOS Autolayout、Size Classes、Android 的 5 大布局体系、HTML/CSS 的浮动定位技术以及 Flex-Box 和 Bootstrap 框架等主流的平台的界面布局功能，并提供了一套简单、完备的多屏幕尺寸适配的解决方案。

3.SegementSlide

SegementSlide 是一个 iOS UI 库，它具备完整的滑滚及切换组件，旨在解决多层 UIScrollView 嵌套滚动的问题。

1.DevHub

DevHub 是一款跨平台的 GitHub 通知管理客户端，支持 Android、 iOS、网页和桌面上使用，帮助你便捷的接收 GitHub 各类通知。

2.Reqman

Reqman 是一个帮助后端工程师进行 API 测试的工具，同时也是一个基于 Node.js 的爬虫工具。

3.FreeCodeCamp

说到 FreeCodeCamp，或许大家不会陌生，而这个项目就是他们建立的开源课程和相应的代码库。网站提供了 6 大认证课程，也涉及了全栈开发认证。如果你感兴趣，不妨了解下。

4.Gitter

Gitter 是 GitHub 小程序客户端，作者采用 Taro 框架 + Taro UI 进行开发，而小程序内数据则来自 GitHub Api V3.

5.Awesome Podcasts

这个项目收集了各类实用的播客，涵盖了主流的编程语言，希望对你提升技术水平有所帮助。

6.编程图书大全

书籍不光能在你迷茫的时候，给予你答案，还能在你提升技能的时候，给予你帮助。这个仓库收集了众多编程图书，涉及主流编程语言、人工智能、算法、Linux、大数据等。看看，有木有你需要的。

7.VS Code Netease Music

很多开发者喜欢边写代码，边听音乐，VS Code Netease Music 这个插件就能满足你在 VS Code 上听歌的愿望。它使用 Webview 实现，不依赖命令行播放器。

Star-Battle

Star-Battle 是一款使用 JavaScript ES6、Canvas 开发的飞船射击类游戏。来 Enjoy 吧。

注：

如需转载，烦请按下方注明出处信息，谢谢！

Q3: 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：相册选择组件