flutter boost

# 第一章

​​​​​​​flutter组件化调研_lvwuxue的专栏-CSDN博客# 一、组件化接入方式跟原生组件化类似，共有两种方式接入：pod和framework怎么配置flutter环境，flutter官网上讲得很详细了，不在累赘了## 1.以pod的方式接入 1.创建一个flutter_module```flutter create -t module flutter_module```![[email protected]](https://upload-images.jianshu.io/upload_images/3355903-f99...https://blog.csdn.net/lvwuxue/article/details/123263386?spm=1001.2014.3001.5501

# 第二章、构建基于flutter的混合应用
## 2.2常见的原生解决方案

##### 2.2.1 flutter boost演进''
0.0 双引擎
利用AB两个引擎，对界面进行预加载
解决flutterVC切换时，加载时间长的问题

1.0 共享视图
将页面通过key：value的形式进行存储，减少放回页面时的视图构建时间
内存只存两个截图，其余存磁盘
解决平级flutterVC页面切换，（会被栈顶丢出去）状态丢失的问题

2.0 共享引擎
将VC与引擎相关联，使flutterVC与app生命周期捆版
解决

## 2.2.2常用框架

交互:
platform channel，三种方式

纹理：
texture，flutterTextureRegest

platform view：
外接纹理
原理：盖个uiview在flutter view上面
解决：修改SDK内部的view渲染

第三章 多场景应用框架和设计

## 3.1.2 flutter编程模型分析
1.controller 混沌打包
2.presenter 隔离view和model，定义行为方向，protecol
3.viewmodel 定义行为模式，双向绑定，rac
4.flux 简化行为模式，单向通信，Redux

5.flutter基础编程
statelessWidget：创建时就定义了view，简单而安全
fullWidget：statelessWidget+model
1）fullWidget分治能力：
1.不拆分数据，拆分逻辑。
2.拆分数据，不拆分逻辑。
3.拆分数据，拆分逻辑。
2）fullWidget之间的通信
1.notify模式。通知/监听模式，单向
2.transfer模式。数据传输模式，单向，socket，stream
3.invoke模式。接口调用模式，双向
分治:flutter-redux, flutter-hook;
通信:provider,BLoC;
分治和通信:scoped_model,fish-redux

3.2流式场景下的框架设计与应用

3.3 flutter场景下的多媒体框架实践
3.3.1 基本概念：外界纹理、channel、FFI和PlatformView
1）.PlatformView
2）Dart-FFI，解决跨语言访问（C和C++） 的问题
3）外界纹理，解决不支持大批量数据的访问 的问题

3.3.2 多媒体消费端实践：视频播放
1.基于外界纹理的播放器方案
解码数据格式问题：iOS端系统播放器的视频帧输出格式只支持YUV或RGBA
格式转换成YUE：
1.libyue ，视频分辨率高时，CPU消耗大，发烫
2.OpenGL通过RTT渲染成RGBA，线程卡顿，界面卡顿
3）共享纹理--[万万没想到-Flutter这样外接纹理](https://blog.csdn.net/weixin_38912070/article/details/93857098)，播放卡顿
4)基于CPU和GPU共享内存的方案，iOS用CVOpenGLESTextureXaxheRef，android用SurfaceTexture，从内存获取对于的OpenGL的纹理
2.基于platformView的播放器方案

3.3.3 多媒体消耗端实践：图片组件
下载ImageStream，解码ImageDecode,缓存ImageCache,渲染Image
1.基于外界纹理的图片组件 。Texture
2.基于flutter引擎层扩展图片加载器的方案。 引擎层和C++的交互方式--Register Natives，与FFI原理一致
3.基于内存地址传递的图片解决方案。用FFI的pointer类，用asTypedList转换为Uint8Liat的预想，在用decodeImageFromPixels讲图片地址转换成image

3.3.4 platform 线程和EGLContext
flutterEngine同时运行四个线程：UI、I/O、GPU、Platform
如果OPeGL在主线程运行会导致，GPU和Platform使用同一个线程，导致bug

3.3.5 小结
1.内存问题。
flutterEngine启动占了较大内存，所以对于内存消耗较大的音视频来说，开发者要遵循“省吃俭用”的原则，并贯穿整个开发设计过程
2.线程问题。
主线程不能有OpenGL的操作
3.异步调用。
Flutter Channel是异步调用的，所以可能有一些原油的同步逻辑都需要改成异步化并保证稳定性相比普通flutter业务开发，音视频开发有很大不同。它的native端逻辑开发可能占了过半的工作量。因此相对于普通业务开发，flutter的优势并没有发挥得很明显。但随着日益完善的第三方库Camera、OpenGL、MediaCodec等APi，会慢慢变好

3.4 游戏化场景的架构设计与应用
游戏风口
3.4.1 技术选型
Flame：轻量化的游戏引擎
1.没有没有使用flutter的开发方式。而是用Game和Componet定义新的游戏开发框架，对于flutter开发和传统游戏开发都不友好
2.与flutter融合较为生硬，Flame采用Canvas实现，在游戏场景中无法实现局部刷新，存在性能隐患。缺少GUI系统，场景内嵌套UI比较难。缺少手势事件。
3，动画指出格式不主流，骨骼动画支持Flare，不支持DragoneBone。且粒子动画对主流格式的支持也不够友好
4.资源管理存在内存问题，资源加载后一直不会释放