flutter全局架构,flutter 模块开发

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

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

创新互联公司主营城中网站建设的网络公司,主营网站建设方案,app软件定制开发,城中h5小程序开发搭建,城中网站营销推广欢迎城中等地区企业咨询

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

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

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

2、Flutter发布Package(Pub.dev或私有Pub仓库)

首先，我们知道flutter有四种工程模式：Flutter Application、Flutter Module、Flutter Plugin和Flutter Package。

我们这里就主要讲Package 纯Dart插件的发布吧，都差不多。

创建工程后，就可以编写你的公共组件，或者公用字体库呀啥的， 都行。

在更改下你的pubspec.yaml文件，修改下你的versionCode，项目名称，项目描述，作者等

如果上传失败试试????的命令：

在执行该命令时，可能会中途调到网页，要求你登录google账号，登录授权，到时候登录账号并授权就可以了。

因为我们直接使用flutter packages pub publish是发布到Pub.dev上，并不是发布到私有仓库，该怎么办呢？

其实呢，也很简单！像versionCode，项目名，等都和发布Pub.dev是一样的。没啥区别。

有两种方式：

就是这么简单o( ＠ )o

相信大家引用Pub.dev上的第三方库都会了哈，到处都是这里不讲了

在使用flutter pub get就可以拉到私有仓库项目了

以上就差不多聊了聊package发布和获取的事儿了，都很明了，大家可以试试，挺简单的。

PS: 写文不易，觉得没有浪费你时间，请给个点赞~ ????

flutter_riverpod基础使用

1.全局增加ProviderScope

2.增加一个全局的store.dart文件，用于注册各个业务使用的store。以下是store.dart文件中的内容。

3.实现实际的业务需要。

4.在具体的页面，使用store。让页面继承ConsumerWidget

flutter为什么不推荐getx

使用这个版本的GetX写了Demo之后，发现有几个问题：

感觉不太像是稳定版本，存在一些比较明显的问题；而且2.0.6到2.0.7只是一个小版本，全局状态管理逻辑似乎就有比较大的改动。

不支持响应式编程，这个版本的状态管理还是基于state的逻辑；因为想要比较高效的解耦页面和逻辑，可能需要搭配响应式编程框架。

相关功能可能比较少，没有最新版本的功能那么全面。

Flutter是Google开源的构建用户界面（UI）工具包，帮助开发者通过一套代码库高效构建多平台精美应用，支持移动、Web、桌面和嵌入式平台。

Flutter 开源、免费，拥有宽松的开源协议，适合商业项目。Flutter已推出稳定的2.0版本。

产生背景：

Flutter可以方便的加入现有的工程中。在全世界，Flutter 正在被越来越多的开发者和组织使用，并且 Flutter是完全免费、开源的。它也是构建未来的 Google Fuchsia 应用的主要方式。

Flutter组件采用现代响应式框架构建，这是从React中获得的灵感，中心思想是用组件(widget)构建你的UI。

组件描述了在给定其当前配置和状态时他们显示的样子。当组件状态改变，组件会重构它的描述(description)，Flutter 会对比之前的描述， 以确定底层渲染树从当前状态转换到下一个状态所需要的最小更改。

Archsummit 2019重磅分享｜闲鱼Flutter＆FaaS云端一体化架构

作者：闲鱼技术－国有

国有，闲鱼架构团队负责人。在7月13号落幕的2019年Archsummit峰会上就近一年来闲鱼在FlutterFaaS一体化项目上的 探索 和实践进行了分享。

随着无线，IoT的发展，5G的到来，移动研发越发向多端化发展。传统的基于Native＋Web＋服务端的开发方式，研发效率低下，显然已经无法适应发展需要。

我们希望 探索 闲鱼这样规模的独立APP的高效研发架构。主要思路是围绕Flutter解决多端问题，并使Flutter与FaaS等无服务容能力打通，形成云端一体化的研发能力，支持一云多端的发展需要。在某些场景已经取得效果，希望分享过程中的思考，与大家交流。

闲鱼选择Flutter主要是出于高性能的考虑。Flutter高性能主要来源于2个原因：

更多比较：

没有银弹的解决方案，Flutter与RN各有优点。如何选择因素很多，关键看如何取舍，举个例子：

云端技术栈的打通，是减少协同的不错的解法。以往前端＋Node.js的一体化方案大家应该不会陌生，然而如果端侧使用了Flutter，那云侧Dart自然是第一选择。

FaaS的本质是运行在云端，那Dart适合用在云/Server上吗？

Dart语言早于Flutter，在最初的设计上，Dart就可以用于Web、Server。Dart具备一些服务端语言的特点：

闲鱼首先尝试将Dart作为普通的Server，替代传统的Java　Server，然后再将Dart容器嵌入到FaaS容器中。建立Dart Server能力是第一步，也是主要的工作量所在。

闲鱼在Dart　Server方面的建设思路：

开发期：

运行期：

上述内容实现了FlutterDart FaaS的技术栈的统一，但仅技术栈统一还远远不够，端、云的同学仍然无法真正互补和一体化打通，原因在于还有更多深入问题需要考虑：

面向这些问题，闲鱼的解法思路：

案例一，一体化在资源均衡方面的体现。在近期的一个项目中，云端一体化使原本2个月的项目时间，减少了20天。

案例二，一体化在业务闭环方面的体现。负责增长的一位开发同学，专注在增长业务上，在合适的情况下为合适的人投放合适的内容，以此带来用户的增长和活跃效果。一体化的方式下，可以统一云、端的切面，业务研发不再受云、端的限制。

一体化是建设高效研发框架的方向，并不是所有场景都需要一体化的开发，但一体化的Flutter、FaaS等技术组件，可以独立使用，也会带来效率提升，并且与原有的开发模式兼容。从一体化的思路去建设，可以使整体架构体系更加一致，也有机会做一体的架构沉淀。

未来闲鱼希望在一体化上做更多尝试和深入 探索 ，包括一体化工具、一体化业务平台、数据化智能化等方向。

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

Flutter Android端集成排坑 - armeabi 适配 & FlutterBoost

Flutter可以算是当下最火热的新技术之一，我现在所在团队也准备将Flutter技术应用到线上工程中。

关于混合工程，官方文档其实写的已经比较清楚了，按着文档走一般问题不大，

但是有一点值得注意的是，Flutter工程引入的库的gradle的 buildTypes 要与原工程保持一致，如果不一致需要手工添加。

进入正题，现在Flutter官方默认只提供armeabi-v7a、arm64-v8a、x86和x86-64，其中x86和x86-64是为模拟器准备的。目前我们使用的SDK大部分只使用了armeabi架构，直接使用我们会遇见找不到 libflutter.so，libapp.so 的情况，所以我们需要对FlutterSDK做一定的改造。

首先我们要了解下Flutter编译产物，因为不同版本产物是不同的，这里我们只针对Flutter 1.9.1-hotfixes来说。除了资源文件之外，Flutter打包会生成两个非常重要的so库，他们分别是 libflutter.so，libapp.so 。其中 libflutter.so 是Flutter的SDK产物而 libapp.so 正是我们编写的dart文件的产物。默认情况下，这两个文件都会出现在armeabi-v7a中，因此我们要作出对应的改造。

libflutter.so 位于FlutterSDK中，这里顺带提一句，除了这对不同CPU架构，它还分为Debug版和Release版，它们的区别在于Debug是为JIT编译方式打造的，体积较大而Release是为AOT编译方式打造的，体积很小。对 libflutter.so 的改造，只要将其移动文件路径即可，运行以下脚本即可，此脚本来自美团分享的Flutter文章。

移动完了 libflutter.so 之后我们打包发现， libapp.so 仍然会出现在armeabi-v7a中，所以第二部我们就是移动 libapp.so 。这个需要更改 flutter.gradle ，我们在 flutter.gradle 的45行可以看到如下定义，它定义了我们的环境。

在524行我们可以看到，abiValue的取值就是根据上述定义值。

所以结论很简单，只要将

private static final String ARCH_ARM32 = "armeabi-v7a";

改为

private static final String ARCH_ARM32 = "armeabi";

就可以完成对与 libflutter.so 的移动。

前期工作我们都做好了，打成aar就非常简单了

直接使用 flutter build aar --target-platform android-arm

打出来后可以解压检查下 libflutter.so，libapp.so 是否都在armeabi文件夹下即可。

说完了armeabi适配问题，这里下说下有关于有关于FlutterBoost的接入。这个东西接入有两点要注意。

在主app内加上即可，常规操作，强制统一support包的版本号

注释flutter.gradle第655行。因为编译过程中，会去初始化插件项目的buildType下面的debug配置，而插件项目下并未配置debug，导致报错。

如果发现文章中有错误或者有更好的解决方案欢迎指正留言，当然如果本篇文章帮助你解决了问题，也不要吝啬你的感谢。谢谢各位。