第一章

第二章、构建基于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
video_player,camera

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

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

3.1.1 架构设计

（1）单一职责。给行动节点设定明确的唯一目标。
（2）有限周期。设定生命周期是时间维度的体现，非常自然，易于理解。
（3）单向链条。要有核心的逻辑链条，方向清晰，分支越少越好

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.不拆分数据，拆分逻辑。

image.png

2.拆分数据，不拆分逻辑。

image.png

3.拆分数据，拆分逻辑。

image.png

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这样外接纹理，播放卡顿
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.资源管理存在内存问题，资源加载后一直不会释放

3.5云端一体化的架构设计与开发

第四章 性能优化和高可用体系

flutter摒弃了weex用webview渲染和rn用原生渲染，直接开发了新渲染引擎

4.1 高可用标准

4.1.1 首屏显示时间

4.1.2 流畅度

4.1.3 CPU使用率

4.1.4 错误率

4.1.5 内存使用率

4.2 flutter性能优化最佳实践

4.2.1 性能技术优化

4.2.2 交互体验优化

1.复杂动画优化
2.转场动画优化
3.列表优化

4.3 Flutter稳定性保障最佳实践

三大稳定性问题：Flutter异常、内存泄露和CPU使用率

4.3.1 异常治理

1.收集上报异常
2.解决线上存量异常，并总结容易犯的错
3.限制增量异常，做好版本把关

a。flutter error
b。isolate抛出的异常
c。exception

4.3.2内存泄露治理

1.内存泄露实例
2.定位内存泄露的工具

4.3.3 CPU使用率治理

1.优化算法，减少无效逻辑消耗
2.合理利用缓存，减少重复逻辑

4.4可持续发展的高可用体系

4.4.1 基于录屏的卡顿分析

1.侵入式
2.无侵入式

4.4.2 基于录屏的页面可交互时长分析

4.4.3 flutter 代码规范扫描

1.flutter静态代码扫描分析工具
AST、Dart Analyze
2.持续集成环境
SonarQube

第五章 高级UI及动画效果

5.1 动态布局方案 DinamicX DSL

5.1.1整体架构设计

a。Decoration层，用户支持 背景色、边框、圆角和触摸事件等
b。rander层，表达 Node再转化后的布局规则与尺寸
c。content层，负责显示具体内容，对布局控制来说，内容就是children，而textView、imageView等非布局控件将裁踢不过rebderparagraph，renderImage表达

5.1.2DSL渲染的实现？

5.1.3 flutterLayout原理

1.如何实现sizeByParent
2.如何实现performResize
3.非布局控件如何实现performLayout
4.布局控件如何实现performResize
5.flutter如何解决“两次测量”的问题

5.1.4 实际应用场景

5.2 流式布局PowerScrollView

5.3转场动画

5.4Lottie

第六章前沿探索与行业案例

6.1flutter for windows探索