update
This commit is contained in:
guoshuyu
parent
164cb988ad
commit
1bd4cca527
|
|
@ -67,4 +67,10 @@
|
|||
* [Flutter 小技巧之优化你的代码性能](Fluttter-N13.md)
|
||||
* [Flutter 之快速理解混合开发里的手势事件传递](Flutter-N17.md)
|
||||
* [一文快速带你了解 KMM 、 Compose 和 Flutter 的现状](Flutter-CCK.md)
|
||||
* [Android 开发者的跨平台 - Flutter or Compose ？](SQS.md)
|
||||
* [Flutter 小技巧之快速理解手势逻辑](N15.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
# Flutter 工程化框架选择
|
||||
|
||||
Flutter 开发如何快速搭建工程脚手架，在繁杂的第三方插件中快速挑选合适的开发工具，如状态管理、数据库、UI控件库、混合开发模式、动画库等，满足你对 Flutter 工程的快速落地需求。
|
||||
|
||||
[Flutter 工程化选择](GCH.md)
|
||||
|
||||
- [Flutter 工程化框架选择——搞定 Flutter 动画](Z1.md)
|
||||
- [Flutter 工程化框架选择 — 搞定 UI 生产力](Z3.md)
|
||||
- [Flutter 工程化框架选择 — 搞定数据存储选型](Z5.md)
|
||||
- [Flutter 工程化框架选择 — 混合开发的摸爬滚打](Z6.md)
|
||||
- [Flutter 工程化框架选择 — add-to-app 的指路明灯](Z10.md)
|
||||
- [Flutter 工程化框架选择 — 状态管理何去何从](Z2.md)
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
# Flutter 小技巧之快速理解手势逻辑
|
||||
|
||||
又到了小技巧系列更新时间，今天我们主要分享 Flutter 里的手势触摸逻辑，其实在很久之前我就写过 [《面深入触摸和滑动原理》](https://juejin.cn/post/6844903841742192648)相关的源码分析文章，但是最近有人说源码分析看不懂，有没有简要好理解的，**那么本篇就用更简单的角度，带大家理解 Flutter 里的手势相关逻辑**。
|
||||
|
||||
# GestureDetector
|
||||
|
||||
不管你用 `InkWell` 、`InkResponse` 、`TextButton` 还是 `ElevatedButton` ， 它们针对手势的处理逻辑都是来自于 `GestureDetector` ，也就是理解 Flutter 的手势处理逻辑入门，核心可以从分析 `GestureDetector` 开始。
|
||||
|
||||
> 其实更严格意义上讲，手势事件是来自 `Listener` ， `GestureDetector` 是针对 `Listener` 进行了封装，只是为了避免复杂的源码分析，这里就不做展开，你可以简单理解为：**并不是所有的控件都会响应手势，只有带有 `Listener` 的才会响应**，这主要体现在触摸事件的递归响应上。
|
||||
|
||||
**在 `GestureDetector` 里关于事件的响应逻辑主要来自于各种 `GestureRecognizer` （手势识别）的实现逻辑**，不同的手势识别逻辑会响应不同手势结果，相互竞争，最后在 `GestureArenaManager` (竞技场) 决定出一个胜利者。
|
||||
|
||||
简单来说，在竞技场里手势基本遵循两个逻辑：
|
||||
|
||||
- **每个 Recognizer 都可以随时选择失败退出，当竞技场只有它一个的时候它就赢了**
|
||||
- **每个 Recognizer 都可以随时宣布自己获得胜利，这时其他 Recognizer 也将不再响应**
|
||||
|
||||
那么如下图所示，在 `GestureDetector` 里主要有这 8 种 `GestureRecognizer` 在处理不同的场景，他们会根据用户使用 `GestureDetector` 时的参数搭配来参与到事件竞技场里。
|
||||
|
||||
|
||||
|
||||
举个例子，当你使用了 `GestureDetector` 并配置了 `onTap` 、`onLongPress` 和 `onDoubleTap` ，它们是如何分别响应手势事件的？
|
||||
|
||||
**这里的核心逻辑就在于 deadline (时间) 的处理，不管是 `onLongPress` 还是 `onDoubleTap` 都是靠 deadline 来判断胜负**。
|
||||
|
||||
|
||||
|
||||
例如，当用户只是普通点击时，如下代码所示，因为默认 `LongPressGestureRecognizer` 的 deadline 是 500 毫秒，所以**在定时器达到 500ms 响应之前，就会因为 `PointerUpEvent` 导致长按定时器停止，无法触发响应长按事件**。
|
||||
|
||||
反之如果没有 `PointerUpEvent` 产生，那么 500 ms 之后 `LongPressGestureRecognizer` 就会响应，直接宣布胜利(accepted)。
|
||||
|
||||
|
||||
|
||||
> 默认情况下 `GestureDetector` 是不支持修改 deadline ，只有直接使用 `LongPressGestureRecognizer` 时才可以修改 deadline 的时长。
|
||||
|
||||
类似的逻辑在 `DoubleTapGestureRecognizer` 下也有，DoubleTap 的 deadline 是 300 毫秒，当用户首次点击时会注册一个定时器，**如果 300 毫秒以内用户没有产生新的点击，那么 `DoubleTapGestureRecognizer` 就会宣布“失败“退出竞技**，反之如果在 300 毫秒内有新的点击，则直接宣布“获胜”，响应 DoubleTap 回调。
|
||||
|
||||
|
||||
|
||||
那这时候有人就要问了：“*在 `DoubleTap` 过程中，为什么不会触发 `onTap`*” ? 这就需要说到 `TapGestureRecognizer` 的触发逻辑。
|
||||
|
||||
继续前面 `GestureDetector` 并配置了 `onTap` 、`onLongPress` 和 `onDoubleTap` 的例子，在用户只做普通点击的时候，前面说过：
|
||||
|
||||
- `LongPressGestureRecognizer` 的定时器 deadline 还没到 500 毫秒会因为 Up 事件而导致失败退出
|
||||
- `DoubleTapGestureRecognizer` 会因为定时器超过 deadline 300 毫秒，没有下一个点击而宣布退出
|
||||
|
||||
**那么在 Long 和 Double 都失败的情况下，此时 `GestureArenaManager` (竞技场) 里的成员就只有 `TapGestureRecognizer`** ，这时候竞技场会 close ，会触发竞技场的 `sweep` 逻辑，直接让最后剩下来的 `Recognizer `“胜利”，响应 `onTap` 事件。
|
||||
|
||||
> 所以 `TapGestureRecognizer` 靠的是胜者为王。
|
||||
|
||||
所以基于这个例子，配合一开始说的两个逻辑，就可以直观的理解 Flutter 手势竞技场里的响应逻辑和关键 `deadline` 的作用。
|
||||
|
||||
# 多个 GestureDetector
|
||||
|
||||
那么前面都是只有一个 `GestureDetector` 的场景，如果有两个呢？如下代码所示，在嵌套两个 `GestureDetector` 下，它们的响应逻辑会是怎么样的？
|
||||
|
||||
|
||||
|
||||
当区域内有两个 `GestureDetector` 的时候，用户在普通点击时，因为 deadline 影响，依旧会是在竞技场 `close` 时才响应 `onTap` ， **但是不同在于此时竞技场里还会有多个 `Recognizer` 存在，这时候只有排在列表的第一个的 `Recognizer` 可以赢得事件**，也就是上门代码里的红色 200x200 小方块。
|
||||
|
||||
|
||||
|
||||
因为对于多个 `GestureDetector` 的情况， `Recognizer` 在竞技场列表(`List<GestureArenaMember`)里的顺序和 `HitTest` 时的递归调用有关系，简单说就是：**递归调用会就让我们自下而上的得到一个 `HitTestResult` 列表，代码里最后的 child 会在最上面**。
|
||||
|
||||
> 同时对于单个 `GestureDetector` 而言，`TapGestureRecognizer` 会是 `_recognizers` 的第一个，所以 `first` 会是响应了 `TapGestureRecognizer` ，详细逻辑可以看 [《面深入触摸和滑动原理》](https://juejin.cn/post/6844903841742192648) 。
|
||||
|
||||
所以简单理解：
|
||||
|
||||
- 两个 `GestureDetector` 在竞技场里的 `member` 列表排序时，作为 child 的红色 `GestureDetector` 因为 HitTest 递归会被排前面
|
||||
- `GestureDetector` 内部 `TapGestureRecognizer` 会在其内部 `_recognizers` 排第一
|
||||
|
||||
所以 `member.first` 最终响应了 `TapGestureRecognizer` ，回到上面两个定律，如果结合多个 `GestureDetector` 的场景，就应该是：
|
||||
|
||||
- **每个 Recognizer 都可以随时选择失败退出，当竞技场只有它一个的时候它就赢了；如果不止一个，那么在竞技场 `close` 时， `member.first` 会获得响应**
|
||||
- **每个 Recognizer 都可以随时宣布自己获得胜利，这是其他 Recognizer 也将不再响应**
|
||||
|
||||
#####
|
||||
|
||||
# 进阶补充
|
||||
|
||||
前面简单介绍了 Flutter 的手势响应的基础逻辑，这里再额外补充两个知识点。
|
||||
|
||||
首先，*当用户在长按的时候， `GestureDetector` 何时会发出 `onTapDown` 事件*？
|
||||
|
||||
这其实就涉及了另外一个 deadline 参数，当用户在长按的时候，Recognizer 还会触发另外一个定时器，然后通过执行 `didExceedDeadline` 来发出 `onTapDown` 事件。
|
||||
|
||||
|
||||
|
||||
那么问题又来了，既然长按会触发 `onTapDown` 事件，如果点击区域内有两个 `TapGestureRecognizer` ，长按的时候因为定时器都触发了 `didExceedDeadline` ，那是不是两个都会收到 `onTapDown` 事件 ？
|
||||
|
||||
|
||||
|
||||
答案是：会的！**因为定时器都触发了 `didExceedDeadline`，从而都发出了 `onTapDown` 事件，所以两个 `onTapDown` 回调都会执行，但是后续竞争只会有一个控件能响应 `onLongPress` 。**
|
||||
|
||||
> 另外，如果不是长按导致的 Down 事件， 是不会导致两个 `GestureDetector` 都触发回调 `onTapDown` 回调。
|
||||
|
||||
第二个补充的是 `Listener` ， 如果你还想深入去看 `GestureDetector` 的实现，你就会发现 `GestureDetector` 对 `Listener` 的封装也许和你想象不大一样， **因为 `Listener` 的封装只用到了 `PointerDown` ，并没有用到 `onPointerUp`** ，那 `GestureDetector` 是怎么响应 Up 和 Move 事件？
|
||||
|
||||
|
||||
|
||||
这就需要说到前面介绍 [《面深入触摸和滑动原理》](https://juejin.cn/post/6844903841742192648) 里的源码分析，但是为了简单，我们这里只说结论：
|
||||
|
||||
> 因为只有响应了 `PointerDown` 事件，对应的 `GestureRecognizer` 才能被添加到 `GestureBinding` 的 `PointerRouter` 事件路由和 `GestureArenaManager` 事件竞技中，而**后续的 Up 和 Move 事件主要是通过 `GestureBinding` 来处理**。
|
||||
|
||||
更简单的说，**就是只有响应了 `PointerDown` 事件，控件的 `Recognizer` 才能响应后续统一处理的其他手势事件，而其他事件不需要在 `Listener` 这里获取回调**。
|
||||
|
||||
|
||||
|
||||
# 结束
|
||||
|
||||
那本篇的小技巧到这里就结束了，本篇主要是用更直观和简单的方式，帮助大家理解 Flutter 里的触摸响应逻辑，如果对更详细实现感兴趣，可以结合 [《面深入触摸和滑动原理》](https://juejin.cn/post/6844903841742192648) 帮助理解，如果你还有什么感兴趣或者有疑惑的，欢迎留言评论～
|
||||
|
||||
13
README.md
13
README.md
|
|
@ -168,6 +168,19 @@
|
|||
* [Flutter 小技巧之优化你的代码性能](Fluttter-N13.md)
|
||||
* [Flutter 之快速理解混合开发里的手势事件传递](Flutter-N17.md)
|
||||
* [一文快速带你了解 KMM 、 Compose 和 Flutter 的现状](Flutter-CCK.md)
|
||||
* [Android 开发者的跨平台 - Flutter or Compose ？](SQS.md)
|
||||
* [Flutter 小技巧之快速理解手势逻辑](N15.md)
|
||||
|
||||
[Flutter 工程化选择](GCH.md)
|
||||
|
||||
- [Flutter 工程化框架选择——搞定 Flutter 动画](Z1.md)
|
||||
- [Flutter 工程化框架选择 — 搞定 UI 生产力](Z3.md)
|
||||
- [Flutter 工程化框架选择 — 搞定数据存储选型](Z5.md)
|
||||
- [Flutter 工程化框架选择 — 混合开发的摸爬滚打](Z6.md)
|
||||
- [Flutter 工程化框架选择 — add-to-app 的指路明灯](Z10.md)
|
||||
- [Flutter 工程化框架选择 — 状态管理何去何从](Z2.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,316 @@
|
|||
# Android 开发者的跨平台 - Flutter or Compose ？
|
||||
|
||||
hello 大家好，我是 Flutter GDE 郭树煜，同时也是 Github GSY 项目的负责人，比如 GSYVideoPlayer ，今天要给大家分享的主题是 Android 开发者的跨平台 - Flutter or Compose ？ 今天的分享不会是很深入的技术内容，更多可能是科普向，特别是对 Flutter 和 Compose 还不是特别了解的 Androider 们，通过数据帮助大家来理解 Flutter 和 Compose。
|
||||
|
||||
# 一、Android 开发和跨平台开发的现状
|
||||
|
||||
首先我们聊聊现状，不知道你有没有这种感觉，就是现在的 Android 开发者很多时候不再是 Android 开发，或者说不是纯 Android App 开发，目前简单总结大致可以分为两类：
|
||||
|
||||
- **以 Android 为技术栈的嵌入式开发**，如电视、手表、教育平板、监控等，这里面近年来又以车机开发较为突出。
|
||||
- **大前端开发**，从 Android 、 iOS 、Web 到小程序等各类面向 UI 相关的工作内容
|
||||
|
||||
这个现状的具体原因在于：**Android 开源让它可以更好地被各行各业消化，同时这些年 App 开发体系越发成熟**。
|
||||
|
||||
> 我还记得 2015 年那会我带的移动团队开发一款 App ，标配就是 Android 和 iOS 各自 4-5 个人，还经常需要加班加点，项目里会用到大量第三方的开源框架。
|
||||
|
||||
而现在随着官方这些年 Jetpack 体系的成熟，Android 开发者更多会聚焦到 Jetpack 体系内，比如：`Room`、`CameraX`、`Hilt`、`Navigation`、`Paging`、`WorkManager`、`Emoji2`、`DataStore`、`Media`、`Startup` 等，而 Compose 就是 Jetpack 里的最大亮点之一，**如果说 Android 开发现在进入了 Jetpack 纪元，那 Jetpack Compose 就是 Jetpack 纪元里的超新星**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Jetpack Compose 是 Android 新推出的声明式 UI 工具包，它主要是用于简化和加速 Android 上的 UI 开发，同时 Compose 经过 Jetbrains 开源的 compose-jb 支持到跨平台开发的能力**。
|
||||
|
||||
这里三个重点：
|
||||
|
||||
- Jetpack Compose 是 Android 的 UI 的工具包
|
||||
- Jetbrains 开源了 compose-jb 支持跨平台
|
||||
- Compose 是声明式开发
|
||||
|
||||
**从大前端开发的角度看，声明式开发可以说是当今的主流**，React、Vue、SwiftUI、Flutter 等都是声明式编程，还有如近期发布的 HarmonyOS 3.1版本，也着重标注了它将全面进入声明式开发阶段。
|
||||
|
||||
> 所以不管你喜不喜欢，声明式开发是主流，虽然它近期看起来不会完全替代 Android 的 XML 布局，但是这是主流的趋势。
|
||||
|
||||
再说跨平台，如今跨平台开发相信大家都不会陌生，各类跨平台开发框架都相当成熟，**但是对于 Android 开发来说， Flutter 和 Compose 确实会显得比较特殊**，因为它们都是属于 Google 开源的产品，都能支持跨平台，所以可以对于部分 Android 开发者来说会陷入困惑：我该选哪个？
|
||||
|
||||
针对这个疑惑，我们先看一些数据对比，首先如下图所示，是 Google Trend 上 Flutter 和 Compose 在全球和国内的一些关键词搜索热度对比，可以看到**全球范围内都是在稳步上升，但是在国内是属于强烈波动的状态，也就是国内有很多人对于 Flutter 和 Compose 都还处于徘徊观望状态**。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
另外也可以看到 ， Flutter 出来比较久，所以如今他的热度会比较高，当然这也是现在跨平台的需求剧增有关系，很多平台开发人员不再仅仅 ”安居” 于自己的平台，**并且从国内的数据可以看到，国内对于跨平台的热情其实一直很高**。
|
||||
|
||||
> 虽然 Flutter 从发布以来一直争议不断，但是这些年下来 Flutter 也证明了自己的价值，后面我们会有单独的详细的数据分析。
|
||||
|
||||
再看 StackOverFlow 的数据，可以看到 Flutter 和 Compose 都在稳步上升，这里面 Compose 相关看起来比较少的原因，和它发布时间还较短有关系，而 Flutter 从目前的占有比例上看其实不算低了。
|
||||
|
||||
|
||||
|
||||
既然说 Flutter 和 Compose 就不得不说 Dart 和 Kotlin ，同样是 StackOverFlow 的数据，可以看到虽然他们发布都有一段时间了，但是其实是在 2017 年开始它们的占有率才出现了爆发式的上升，这是为什么呢？
|
||||
|
||||
|
||||
|
||||
其实这个现象和 2017 Google I/O 大会有直接关系：
|
||||
|
||||
- Kotlin 是 2012 年开源的，而 2017 Google I/O 大会上官方正式支持将 Kotlin 作为 Android 开发的 First-Class（一等公民）语言
|
||||
|
||||
- Dart 亮相于 2011 年，而 2017 年 Google I/O 正式向外界公布了 Flutter，Dart 是它的主要开发语言
|
||||
|
||||
> 所以 Kotlin 本来不温不火，但是因为 Android 它开始被更多人所使用，同样 Dart 本来已经快被雪藏，却因为 Flutter 而焕发第二春，**看起谷歌在这方面运营能力还是很值得肯定的**。
|
||||
|
||||
我们再看一份数据，这是目前 Kotlin 和 Dart 在 Github 上关于 PR 和 Star 的数据趋势，可以看到开始增长的时间节点依然是 2017，不过 Dart 的关注度还是从 Flutter 正式版发布后才有爆发式增长， 而从增长上看，不管是 Kotlin 还是 Dart 目前都很过得去，**不过目前它们的主要应用场景还是局限在 Android 和 Flutter**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
再看国外调研的一份关于 Flutter 和 Compose 在 Droidcon 上有多少次关于这两个项目的演讲主题和结果，虽然数据相对较小和局限，但是可以看到 Flutter 自发布以来每年都在稳定的主题，而 Compose 在稳定版发布后有明显爆发式增长
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
|
||||
|
||||
最后，恰好 GitHub 也发布了 2022年度报告，其中一些数据还是值得我们关注，例如在开发语言增长上， Kotlin 排进了前十，另外移动端开发依旧是开源主流之一，其中 Kotlin、Dart 、Flutter 、Android 都是主要的对象。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
当然，就像前面说的，**不管是 Dart 还是 Kotlin ，它们主要是场景还是在于 Flutter 和 Android ，通过 [TIOBE](https://www.tiobe.com/tiobe-index/) 在 2022 年 11 月的编程语言指数上可以看到， Dart 和 Kotlin 还是未能进入 TIOBE 指数前 20 名**，该指数每月更新一次，在编程语言的流行程度上有比较高的参考价值。
|
||||
|
||||
|
||||
|
||||
不是说其他领域不能用，比如 Kotlin 和 Dart 都能写后端，我以前自己也有一些后端项目，当时为了方便，直接把Android 上 kotlin 的逻辑复用到服务端，而 Dart 本身通过 ffi 直接支持数据库等的能力，也让它可以脱离 Flutter 作为单独的后台服务运行，这在我以前的文章也分享过，目前支持 Dart 的 ffi 数据库也有好几款了，所以不是说不能用不支持，只是相对还是少很多。
|
||||
|
||||
我们最后在看一份数据， [RedMonk 2022 Q3](https://redmonk.com/sogrady/2022/10/20/language-rankings-6-22/) 的调查里，在 Github 和 StackOverflow 的流行指数上还是比较靠前的，Kotin 排在第 17 位，而 Dart 排在第 19 位，从应用领域看，这两种语言目前的势头还是不错的。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> 所以总结来说： **Android 成就了 Kotlin ，而 Kotlin 成就了 Compose ，同样 Flutter 成就了 Dart **。
|
||||
|
||||
# 二、Compose 对于 Android 开发来说是什么
|
||||
|
||||
接下来进入第二个主题，Compose 对于 Android 开发来说是什么：
|
||||
|
||||
- **Compose 对 Android 来说最重要的是新的现代化 UI 开发框架，Compose 提供了 Andorid 声明式的 UI 开发能力，这是核心的重点**。
|
||||
- **Jetbrains 开源的 compose-jb 让 Compose 得到了额外的增值，可以把开发能力拓展到其他平台，这是附带价值**。
|
||||
|
||||
> 所以从这个角度看，如果你继续做 Android 开发，那么学会 Compose 是必须的技能，因为它未来可能会是 Android 上主流的开发模式，尽管它目前还比较年轻。
|
||||
|
||||
说他年轻，是因为目前他的正式版发布也就一年的时间，目前 Jetpack Compose 和 compose-jb 的正式版本都在 1.2 ，第一个正式版是都是在 2021 年发布，并且在近一年时间内发布了两个大版本，另外可以看到 compose-jb 都是在 Jetpack Compose 发布之后再跟进版本更新，**所以 Jetpack Compose 是一些的基础核心**。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
*那么大家肯定很关心一个问题，有哪些大厂 App 在使用 Compose* ？
|
||||
|
||||
目前关于 Flutter 的技术文章我们可能看到过很多大厂的分享，但是 Compose 相关的比例却不多，所以我也只能从我自己手机里一些常用软件的归类，目前恰好可以找到如下图所示的 6 款 App 里有存在 Compose 的痕迹。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> **当然，使用 Jetpack Compose 和使用 compose-jb 其实是两码事**，所以我也不知道上述产品是否也有使用 compose-jb 的场景，因为其实 compose-jb 目前在跨平台开发上的体验还是有些差别的。
|
||||
|
||||
**而作为全新的独立 UI 框架， Compose 自然不会像以前一样的控件体系**，类似的声明式布局方式对于 Android 开发者来说可能会有一定的学习成本，最直观的就是 Compose 里会使用状态管理和绑定，而不会是像以前一样拿 `view.xxxx` 这样的操作方法，这是一个思路转变的过程。
|
||||
|
||||
|
||||
|
||||
另外从反编译后的代码里可以看到，**Compose 里的控件和原生控件并不是一个体系**，大家如果去看编译后的内容，就会发现例如 `BOX` 这样的控件在编译后是通过 `ComposerKt` 和 `BoxKt` 等的 framework 实现来完成的布局与绘制。
|
||||
|
||||
|
||||
|
||||
所以 **Compose 编译后不是转化为原生的 Android 上的 View 去显示**，而是依赖于平台的 `Canvas` ，在这点上和 Flutter 有点相似，简单地说可以理解为 Compose 是全新的一套 View 。
|
||||
|
||||
> 另外友情提示：虽然是全新的 View ，但是 `Compose` 的组件在 Android 上是可以显示了布局边界。
|
||||
|
||||
**另外 Compose 里的代码基本都是可以被混淆的**，所以开启混淆之后代码的压缩率也很高。
|
||||
|
||||
在 Compose 里两棵树的设计，虚拟 Dom 风格的 SlotTable 和 React 设计类似，从而保证了 LayoutNode 的性能，Compose 的核心设计开发人员 Jim Sproch 之前是 React 的核心开发。
|
||||
|
||||
|
||||
|
||||
> **其实这也是一种大前端的趋势，不管你是客户端还是前端开发，你的能力都应该可以得到应用。**
|
||||
|
||||
再说 compose-jb ，如下图所示， compose-jb 在跨平台开发体验上还是有所区别，**Compose 目前是通过多个模块实现来支持多平台，所以目前 Jetpack Compose 和 compose-jb 有一些“割裂”**， compose-jb 本质上是将 compose-desktop，compose-web 以及 compose-android 进行了整合，特别是在 Web 端，想要达到 Flutter 一样共享代码的比例还需要继续努力。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
如上图所示的 iOS 其实目前也已经进入[实验阶段](https://github.com/JetBrains/compose-jb/issues/2397#issuecomment-1277536570) ，[` androidx.compose.ui.main.defaultUIKitMain` ](https://github.com/JetBrains/compose-jb/blob/master/experimental/examples/falling-balls-mpp/src/uikitMain/kotlin/main.uikit.kt) 相关的支持距离正式发布可以期待，而 compose-jb 目前对跨平台的支持的 “割裂” 也来自于此，比如 Web 下的代码会是这种感觉。
|
||||
|
||||
```kotlin
|
||||
import org.jetbrains.compose.web.dom.*
|
||||
import org.jetbrains.compose.web.css.*
|
||||
|
||||
fun main() {
|
||||
var count: Int by mutableStateOf(0)
|
||||
|
||||
renderComposable(rootElementId = "root") {
|
||||
Div({ style { padding(25.px) } }) {
|
||||
Button(attrs = {
|
||||
onClick { count -= 1 }
|
||||
}) {
|
||||
Text("-")
|
||||
}
|
||||
|
||||
Span({ style { padding(15.px) } }) {
|
||||
Text("$count")
|
||||
}
|
||||
|
||||
Button(attrs = {
|
||||
onClick { count += 1 }
|
||||
}) {
|
||||
Text("+")
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> **另外值得一提的是，Compose for Wear OS 的 1.0 稳定版也发布了**。
|
||||
|
||||
还有一个关键点就是，如果使用 compose-jb ，你可能还会接触到 Kotlin/JS 、Kotlin/Native、KMM 等对应的名词，这部分对于 Android 开发来说也算是额外的学习成本，**所以在跨平台体验上目前 compose-jb 的路才刚刚开始，一致性的跨平台开发体验相信会是 compose-jb 努力的方向**。
|
||||
|
||||
其实前面所说的“割裂”问题，目前可以看到官方也在有序推进，其中就有 desktop 的部分代码已经挪到了androidx 上，从这里看或者统一的 Compose lib 并不遥远。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
另外 **Jetpack Compose 现在针对 Compose 体系的官方依赖支持，也推出了 Gradle BOM (Bill of Materials) 依赖模式**，用于指定每个 Compose 库的稳定版本。
|
||||
|
||||
> 目前第一个版本是 Compose 2022 年 10 月版，现在最新的应该是 2022.11.00。
|
||||
|
||||
那么 Gradle BOM 的作用是什么？如下图所示，**简单说就是不用再单独写依赖版本， 我们可以通过仅指定 BOM 的版本管理所有 Compose 库版本**，BOM 本身具有指向不同 Compose 库的稳定版本的链接，所以它们可以很好地协同工作。
|
||||
|
||||
|
||||
|
||||
*当然，聊到这个就顺便聊一聊制约 compose-jb 的问题：缺少插件社区*。
|
||||
|
||||
这其实是跨平台领域必不可少的配置：**前端有 npm 、Flutter 有 pub，你可以通过它们的中央官网搜索你想要的库，查看它们的热度，版本，兼容和使用量等等信息，设置官方认证和安全保障，甚至还有趋势推荐，库支持的平台有哪些等等，但是 Maven 时代在这方面一直很弱**，这是 compose-jb 后续发展需要解决的最大问题之一。
|
||||
|
||||
最后说到 Compose 就不得不说 Android Studio ：**Compose 和 Android Studio 版本其实有很强的依赖关系**，例如：
|
||||
|
||||
1、Android Studio Arctic Fox （白狐狸） 开始支持 Compose preview 、 Interactive preview 和 Deploy to Device ，并开始支持 Live Edit of literals 和 Layout Inspector 。
|
||||
|
||||
2、Android Studio Bumblebee （小蜜蜂） Layout Inspector 才支持检查 Compose 布局中的语义信息，并且默认启用 interactive preview，interactive preview 允许在预览时进行交互，就像是已经运行到设备上工作一样。
|
||||
|
||||
|
||||
|
||||
> 这里的 Preview interactive 模式直接在 Android Studio 中运行，无需运行模拟器，这会导致一些限制：没有网络访问权限、没有文件访问权限、某些上下文 API 可能不完全可用。
|
||||
|
||||
值得一提的是， **Compose 目前不支持 hotload**，Android Studio 的 apply code 的实用程度相信大家深有体会，不过 Compose 有支持 preview 时的文本 Live Edit of literals ，这也算是一个可将一下的工具。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3、Android Studio Chipmunk （小松鼠） 开始支持 [`animatedVisibility`](https://link.juejin.cn/?target=https%3A%2F%2Fdeveloper.android.com%2Fjetpack%2Fcompose%2Fanimation%23animatedvisibility) 的动画预览，动画预览和`animatedVisibility`需要使用 Compose 1.1.0 或更高版本。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
|
||||
|
||||
4、Android Studio Dolphin （海豚） 支持 Compose Animation Coordination，如果你的动画是用于 composable preview，那么可以使用 [Animation Preview](https://link.juejin.cn/?target=https%3A%2F%2Fdeveloper.android.com%2Fjetpack%2Fcompose%2Ftooling%23animations) 来同时检查和协调所有动画，甚至还可以冻结特定的动画，并且支持 composables 何时进行或不进行重构
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
最后，如果你好奇现在哪些大厂在使用 compose-jb ，目前我还没找到比较有价值的数据，不过据称 JetBrains 目前就已经将 Toolbox 应用通过 compose-jb 实现并且发布使用。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 三、 Flutter 对于 Android 开发来说是什么
|
||||
|
||||
接下来我们聊聊 Flutter 对于 Android 开发者来说又是什么？**你如果选择还是只做 Android ，那么 Flutter 对你来说可能意义不大**，Flutter 其实起源于 Chrome 内部团队，所示它其实和 Android 没什么关系，**但是如果你对其他平台感兴趣，那么 Flutter 绝对是你不错的选择**。
|
||||
|
||||
Flutter 正式版是在 2018 年发布，发布之后几乎就是每个季度都会更新一个大版本，如下图所示可以看到 Flutter 的推进和迭代速度是很快的，这也侧面反映了 Flutter 社区的活力。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**如果大版还不够有说服力，那么近期的小版本迭代速度，这也可以体现 Flutter 社区的生命力，当然也侧面反映出全平台支持的困难，需要解决的问题很多**，因为跨平台需要兼容处理的问题会更多，这也是 Flutter 坑多的原因。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
我们再从 Github 发布的 2022 年度报告上看，在各项开源数据里 Flutter 都名列前矛：
|
||||
|
||||
- 顶级开源项目里按贡献者排序 Flutter 排第三
|
||||
- 顶级开源项目里按首次贡献者统计的，Flutter 在获取贡献“一血”里排名第四
|
||||
- 在每个项目的贡献者数量里 Flutter 排名第二
|
||||
- 在外部贡献者百分比里 Flutter 排名第三
|
||||
|
||||
|  |  |  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
> **由此可以看到 Flutter 强大的生命力，特别是来自社区的活跃，Flutter 每个版本发布都会合并大量来着社区的 PR ，这也是 Flutter 这些年来快速发展的原因**，同时也是在本次 Github 发布的报告里，随处可以见 Flutter 的原因。
|
||||
|
||||
*那么说一千道一万，目前有哪些我们熟知的企业在使用 Flutter 呢*？
|
||||
|
||||
如下图所示是目前我手机里有 Flutter 存在的 App ，另外还有过去三年里 Flutter 在跨平台领域的占有率增长，**可以看到 Flutter 目前在跨平台领域的存在感并不低，其实介绍这么多数据，只是为了和大家说明一个问题：Flutter 已经不算小众了**。
|
||||
|
||||
> 百度网盘、转转、阿里云盘、闲鱼、微信、掘金、企业微信、微博、B站漫画、阿里云、 UC浏览器、优酷视频、钉钉、360摄像头、网易邮箱、天猫精灵、链家、美团众包、凤凰新闻、腾讯课堂、喜马拉雅、携程旅行、贝壳找房、WPS、学习强国、唯品会、同花顺
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
回到 Flutter 本身上，**Flutter 的优势体现在于 single codebase ，它是真的做道一套代码编译成不同平台的 native 代码运行**，Flutter 跨平台最特殊在于它不依赖平台控件，控件最后都是利用 Skia 通过平台 GPU 渲染出来。
|
||||
|
||||
|
||||
|
||||
**所以 Flutter 里的控件基本和平台无关，这对于跨平台来说有很大优势**，因为控件只和 Flutter 框架有关系，在 Andriod 上得到的效果，在 iOS 上也可以得到一样的结果，所见即所得，这对开发效率有很高的帮助。
|
||||
|
||||
> 但是这也大大提供了框架维护的工作量，例如文本输入框 `TextFiled` 和 `Text` 都针对移动平台和 PC 平台，需要在控件内部兼容手势触摸和键鼠操作，，这也是为什么类似 Global Selection 等功能会到 3.3 才开始有官方支持。
|
||||
|
||||
所有 Flutter 需要面对的 Bug 也很多，在面对越来越多不可控的底层渲染问题之后，**Flutter 开始自建渲染引擎，因为直接使用 Skia 已经无法满足日益增长的 Bug 和性能极限，所以官方开始了自研[渲染引擎Impeller](https://link.juejin.cn/?target=https%3A%2F%2Fmp.weixin.qq.com%2Fs%2FGptJbPXPediNRc4KvZzr6g)** 。
|
||||
|
||||
因为 Flutter 团队现在出现问题每次都要和 Skia 团队沟通，然后等跟进，这样的节奏太慢了，从前面官方的小版本更新日志上就可以看出目前 Flutter 的迭代速度依然很夸张。
|
||||
|
||||
> **这次自研的 Impeller 本质上是为了解决 Skia 需要运行时遇到的问题，让 Impeller 可以直接在编译器就完成 GLSL 和 MSL ，不需要 SKSL 从而提高了性能和运行时的稳定性** ，目前优先在 iOS 平台上开始支持 ，配合 Metal 做优化，后续如果没问题也会同步支持 Android 和 Vulkan 。
|
||||
|
||||
从这个角度猜测，Flutter 在 Skia 遇到的问题 compose-jb 也很可能会遇上，而如果后续 Impeller 项目进展顺利，那它或者并不会局限在 Flutter ，也许也可以拓展支持到 compose-jb上，
|
||||
|
||||
> 其实**在 Jetbrains 的开源项目里有一个叫 [skiko ](https://github.com/JetBrains/skiko) 的项目**，Skiko（Kotlin 的 Skia 的缩写）是一个图形库，它支持 Kotlin/JVM 、Kotlin/JS 、Kotlin/Native 等相关实现。
|
||||
|
||||
所以自研发引擎的模式并不奇怪，随着项目的发展和深入，很多底层问题没办法快速推进就会反推自研，例如 [Hermes 在 RN 0.7 成为默认 Engine](https://juejin.cn/post/7140474062211383333) 也是类似问题的体现，**自研底层属于是一个负责任的开源团队的必经之路**。
|
||||
|
||||
最后，**如果真要总结 Flutter 对于 Android 开发者最大的意义，就是拥有开发其他平台的能力**，通过 Flutter 去了解和接触开发其他平台的，同时还能提前习得大部分 Compose 的开发能力，如下图所示是 Compose 和 Flutter 的代码对比：
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
**所以这也是 Andorid 开发会了 Flutter 就离 Compose 不远的原因，反过来也是**。
|
||||
|
||||
这里可以顺便推荐下大佬的 Flutter 和 Compose 入门项目 [FlutterUnit](https://github.com/toly1994328/FlutterUnit) 和 [ComposeUnit](https://github.com/toly1994328/ComposeUnit) ，上面的代码就是来自这两个项目，里面列举了很多案例，特别适合入门的小伙伴。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
|
||||
|
||||
# 最后
|
||||
|
||||
本次分享的核心还行想告诉大家，目前 Compose 和 Flutter 成熟度已经不错了，当你的领导和你说，Kotlin、Dart 还不够普及，Flutter 和 Compose 还太小众的时候，或者你就可有一些数据依据。
|
||||
|
||||
最后可以总结的是：
|
||||
|
||||
- Compose 的核心还是 Android 的 UI 库，做 Android 的必须掌握这个未来的能力，至于 compose-jb 的跨平台增值能力，还有一段路要走。
|
||||
- Flutter 的核心是全平台更稳定的支持，更有社区活力，特别是在相对“冷清”的桌面端上的优势，在目前公开信息上，钉钉、字节和企业微信都在 Flutter 桌面端开始有投入。
|
||||
|
||||
**所以结合自己的路线，选哪个应该就很清楚了，而不管选择哪一个，都会对另外一个框架有提前铺垫的作用，所以也不用担心得此失彼，感兴趣的小伙伴可以开始动起来了**～
|
||||
92
SUMMARY.md
92
SUMMARY.md
|
|
@ -70,76 +70,158 @@
|
|||
* [番外](FWREADME.md)
|
||||
|
||||
* [Flutter 跨平台框架应用实战-2019极光开发者大会](Flutter-jg-meet.md)
|
||||
|
||||
* [Flutter 面试知识点集锦](Flutter-msjj.md)
|
||||
|
||||
* [全网最全 Flutter 与 ReactNative深入对比分析](qwzqdb.md)
|
||||
|
||||
* [Flutter 开发实战与前景展望 - RTC Dev Meetup](Flutter-rtc-meetup.md)
|
||||
|
||||
* [Flutter Interact 的 Flutter 1.12 大进化和回顾](Flutter-Interact-2019.md)
|
||||
|
||||
* [Flutter 升级 1.12 适配教程](Flutter-update-1.12.md)
|
||||
|
||||
* [Spuernova 是如何提升 Flutter 的生产力](Flutter-Supernova.md)
|
||||
|
||||
* [Flutter 中的图文混排与原理解析](Flutter-TWHP.md)
|
||||
|
||||
* [Flutter 实现视频全屏播放逻辑及解析](Flutter-Player-Full.md)
|
||||
|
||||
* [Flutter 上的一个 Bug 带你了解键盘与路由的另类知识点](Flutter-keyboard-rs.md)
|
||||
|
||||
* [Flutter 上默认的文本和字体知识点](Flutter-Font-Other.md)
|
||||
|
||||
* [带你深入理解 Flutter 中的字体“冷”知识](Flutter-Font-Cool.md)
|
||||
|
||||
* [Flutter 1.17 中的导航解密和性能提升](Flutter-nav+1_17.md)
|
||||
|
||||
* [Flutter 1.17 对列表图片的优化解析](Flutter-Image+1_17.md)
|
||||
|
||||
* [Flutter 1.20 下的 Hybrid Composition 深度解析](flutter-hy-composition.md)
|
||||
|
||||
* [2020 腾讯Techo Park - Flutter与大前端的革命](Flutter-TECHO.md)
|
||||
|
||||
* [带你全面了解 Flutter，它好在哪里？它的坑在哪里？ 应该怎么学？](Flutter-WHAT.md)
|
||||
|
||||
* [Flutter 中键盘弹起时，Scaffold 发生了什么变化](Flutter-KEY.md)
|
||||
|
||||
* [Flutter 2.0 下混合开发浅析](Flutter-Group.md)
|
||||
|
||||
* [Flutter 搭建 iOS 命令行服务打包发布全保姆式流程](Flutter-iOS-Build.md)
|
||||
|
||||
* [不一样角度带你了解 Flutter 中的滑动列表实现](Flutter-N-Scroll.md)
|
||||
|
||||
* [带你深入 Dart 解析一个有趣的引用和编译实验](DEMO-INTEREST.md)
|
||||
|
||||
* [Dart 里的类型系统](Dart-SYS.md)
|
||||
|
||||
* [Dart VM 的相关简介与运行模式解析](Dart-VM.md)
|
||||
|
||||
* [Flutter 里的语法糖解析，知其所然方能潇洒舞剑](Flutter-SU.md)
|
||||
|
||||
* [Flutter 实现完美的双向聊天列表效果，滑动列表的知识点](Flutter-SC.md)
|
||||
|
||||
* [Flutter 启动页的前世今生适配历程](Flutter-LA.md)
|
||||
|
||||
* [Flutter 快速解析 TextField 的内部原理](Flutter-TE.md)
|
||||
|
||||
* [谷歌DevFest 2021 广州国际嘉年华-带你了解不一样的 Flutter](Flutter-DevFest2021.md)
|
||||
|
||||
* [Flutter for Web 2022 年：简单探讨](Flutter-W2022.md)
|
||||
|
||||
* [2021 年的 Flutter 状态管理：如何选择？](Flutter-StateM.md)
|
||||
|
||||
* [Flutter 2.10 升级填坑指南](Flutter-210-FIX.md)
|
||||
|
||||
* [Flutter Riverpod 全面深入解析，为什么官方推荐它？](Flutter-Riverpod.md)
|
||||
|
||||
* [ Flutter 2022 战略和路线解读与想法](Flutter-2022-roadmap.md)
|
||||
|
||||
* [原生开发如何学习 Flutter | 谷歌社区说](Flutter-SQS.md)
|
||||
|
||||
* [Fluttter 混合开发下 HybridComposition 和 VirtualDisplay 的实现与未来演进](Flutter-HV.md)
|
||||
|
||||
* [Flutter 双向聊天列表效果进阶优化](Flutter-Chat2.md)
|
||||
|
||||
* [Flutter 上字体的另类玩法：FontFeature ](Flutter-FontFeature.md)
|
||||
|
||||
* [移动端系统生物认证技术详解](Flutter-BIO.md)
|
||||
|
||||
* [完整解析使用 Github Action 构建和发布 Flutter 应用](Flutter-GB.md)
|
||||
|
||||
* [Flutter 120hz 高刷新率在 Android 和 iOS 上的调研总结](Flutter-120HZ.md)
|
||||
|
||||
* [Flutter Festival | 2022 年 Flutter 适合我吗？Flutter VS Other 量化对比](Flutter-FF.md)
|
||||
|
||||
* [Flutter 从 TextField 安全泄漏问题深入探索文本输入流程](Flutter-TL.md)
|
||||
|
||||
* [Flutter iOS OC 混编 Swift 遭遇动态库和静态库问题填坑](Flutter-BIOS.md)
|
||||
|
||||
* [Flutter Web ： 一个编译问题带你了解 Flutter Web 的打包构建和分包实现 ](Flutter-WP.md)
|
||||
|
||||
* [大前端时代的乱流：带你了解最全面的 Flutter Web](Flutter-Web-T.md)
|
||||
|
||||
* [Flutter 深入探索混合开发的技术演进](Flutter-DWW.md)
|
||||
|
||||
* [Flutter 3.0 之 PlatformView ：告别 VirtualDisplay ，拥抱 TextureLayer](Flutter-P3.md)
|
||||
|
||||
* [Google I/O Extended | Flutter 游戏和全平台正式版支持下 Flutter 的现状](Flutter-Extended.md)
|
||||
|
||||
* [掘金x得物公开课 - Flutter 3.0下的混合开发演进](Flutter-DWN.md)
|
||||
|
||||
* [Flutter 小技巧之 ButtonStyle 和 MaterialStateProperty ](Flutter-N1.md)
|
||||
|
||||
* [Flutter 小技巧之 Flutter 3 下的 ThemeExtensions 和 Material3 ](Flutter-N2.md)
|
||||
|
||||
* [Flutter 小技巧之玩转字体渲染和问题修复 ](Flutter-N3.md)
|
||||
|
||||
* [Flutter 小技巧之有趣的动画技巧](Flutter-N4.md)
|
||||
|
||||
* [Flutter 小技巧之 Dart 里的 List 和 Iterable 你真的搞懂了吗？](Flutter-N6.md)
|
||||
|
||||
* [Flutter 小技巧之 MediaQuery 和 build 优化你不知道的秘密](Flutter-N7.md)
|
||||
|
||||
* [Flutter 小技巧之 ListView 和 PageView 的各种花式嵌套](Flutter-N5.md)
|
||||
|
||||
* [Flutter 小技巧之优化你使用的 BuildContext](Flutter-N8.md)
|
||||
|
||||
* [如何利用 Flutter 实现炫酷的 3D 卡片和帅气的 360° 展示效果](Flutter-N9.md)
|
||||
|
||||
* [给掘金 Logo 快速添加动画效果，并支持全平台开发框架](Flutter-N10.md)
|
||||
|
||||
* [Flutter 实现 “真” 3D 动画效果，用纯代码实现立体 Dash 和 3D 掘金 Logo](Flutter-N11.md)
|
||||
|
||||
* [Flutter 3.3 之 SelectionArea 好不好用？用 “Bug” 带你全面了解它](Flutter-N12.md)
|
||||
|
||||
* [Flutter 小技巧之优化你的代码性能](Fluttter-N13.md)
|
||||
|
||||
* [Flutter 之快速理解混合开发里的手势事件传递](Flutter-N17.md)
|
||||
|
||||
* [一文快速带你了解 KMM 、 Compose 和 Flutter 的现状](Flutter-CCK.md)
|
||||
|
||||
* [Android 开发者的跨平台 - Flutter or Compose ？](SQS.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* [Flutter 小技巧之快速理解手势逻辑](N15.md)
|
||||
|
||||
* [Flutter 工程化选择](GCH.md)
|
||||
* [Flutter 工程化框架选择——搞定 Flutter 动画](Z1.md)
|
||||
* [Flutter 工程化框架选择 — 搞定 UI 生产力](Z3.md)
|
||||
* [Flutter 工程化框架选择 — 搞定数据存储选型](Z5.md)
|
||||
* [Flutter 工程化框架选择 — 混合开发的摸爬滚打](Z6.md)
|
||||
* [Flutter 工程化框架选择 — add-to-app 的指路明灯](Z10.md)
|
||||
* [Flutter 工程化框架选择 — 状态管理何去何从](Z2.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,249 @@
|
|||
# Flutter 工程化框架选择——搞定 Flutter 动画
|
||||
|
||||
> 本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
|
||||
|
||||
首先，这次会写一个新的系列《Flutter 工程化框架选择》，但是系列其实并非前端的工程治理方面的内容，**这个系列只是单纯告诉你，创建一个 Flutter 工程，或者说搭建一个 Flutter 工程脚手架，应该如何选择快速适合自己的插件模块，或者说这是一个指引系列，相信会适合新手同学**。
|
||||
|
||||
> **为什么会想要写一个这样的系列？因为这类的问题太多了**，简单检索一个群的聊天记录，单单 `有没有` 这个关键字就可以搜索翻好几页，所以这个系列的目的，是帮大家整理 Flutter 工程里可能会需要的各种第三方模块，并对比一些技术细节，**也是方便以后回答问题我可以直接甩链接**。
|
||||
|
||||
|
||||
|
||||
首先作为系列第一篇文章，本篇我们先聊动画。
|
||||
|
||||
为什么第一篇聊它，因为近期刚好做了一些关于 Flutter 动画的调研，不久前也刚好发布过一些关于它的内容，所以素材比较多，而本篇将针对你可能会遇到的动画场景，**给你推荐各式各样的动画框架来加速开发**。
|
||||
|
||||
# 前言
|
||||
|
||||
在之前的 [Flutter 小技巧](https://juejin.cn/post/7111071430292275213) 系列里我们聊过，如果没有使用封装， Flutter 里创建动画一般需要：
|
||||
|
||||
- `AnimationController` ： 用于控制动画启动、暂停
|
||||
- `TickerProvider` ： 用于创建 `AnimationController` 所需的 `vsync` 参数，一般最常使用 `SingleTickerProviderStateMixin`
|
||||
- `Animation` ： 用于处理动画的 value ，例如常见的 `CurvedAnimation`
|
||||
- 接收动画的对象：例如 `FadeTransition`
|
||||
|
||||
这种写法如下代码所示，我们一般可以称为显式动画（不要纠结名词叫法），大致特征就是：以 **`*Transition`** 命名，比如 `FadeTransition` 、`SizeTransition` 和 `RotationTransition` 等，**需要我们自己定义和操作 `AnimationController`** 。
|
||||
|
||||
```dart
|
||||
class _AnimatedOpacityState extends State<AnimatedOpacity>
|
||||
with TickerProviderStateMixin {
|
||||
late final AnimationController _controller = AnimationController(
|
||||
duration: const Duration(seconds: 2),
|
||||
vsync: this,
|
||||
)..repeat(reverse: true);
|
||||
late final Animation<double> _animation = CurvedAnimation(
|
||||
parent: _controller,
|
||||
curve: Curves.easeIn,
|
||||
);
|
||||
|
||||
@override
|
||||
void dispose() {
|
||||
_controller.dispose();
|
||||
super.dispose();
|
||||
}
|
||||
|
||||
@override
|
||||
Widget build(BuildContext context) {
|
||||
return Container(
|
||||
color: Colors.white,
|
||||
child: FadeTransition(
|
||||
opacity: _animation,
|
||||
child: const Padding(padding: EdgeInsets.all(8), child: FlutterLogo()),
|
||||
),
|
||||
);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
但是，如果都采用这种方式去使用动画，那么项目里就会存在很多的重复代码，所以 Flutter 官方默认提供了一些动画封装，也可以叫做隐式动画（不要纠结名词叫法）：
|
||||
|
||||
> **也就是开箱即用**，常见是 **`Animated*`** 开头的 Widget，例如 `AnimatedPositioned` 、`AnimatedContainer` 、 `AnimatedPadding` 、`AnimatedOpacity` 等控件，它们最大的特点就是内部已经完全封装好逻辑，你只需要配置对应参数就可以触发动画。
|
||||
|
||||
如下代码所示，你只需要改变 `_width` 和 `_height` 就可以触发动画效果，动画中间过程的数据会通过 `Curves` 变化的 “插值” 来得到。
|
||||
|
||||
```dart
|
||||
body: Center(
|
||||
child: AnimatedContainer(
|
||||
width: _width,
|
||||
height: _height,
|
||||
decoration: BoxDecoration(
|
||||
color: _color,
|
||||
borderRadius: _borderRadius,
|
||||
),
|
||||
duration: Duration(seconds: 1),
|
||||
curve: Curves.fastOutSlowIn,
|
||||
),
|
||||
),
|
||||
```
|
||||
|
||||
虽然隐式动画挺方便，但真正的项目里可能很多情况还是不满我们的需求，往往业务逻辑会需要更灵活或者更细致的封装，那么这就要聊到本篇后面的内容。
|
||||
|
||||
# 基础动画
|
||||
|
||||
说到基础动画的部分，主要就是在隐式动画的基础上进一步的封装，可以通过简单配置快速实现一些更精致的动画效果。
|
||||
|
||||
## animations
|
||||
|
||||
[animations](https://github.com/flutter/packages/tree/main/packages/animations) 是官方封装的动画库，主要卖点在于 Material 风格的动画过渡，所以**这个库的核心重点是路由过渡动画或者页面切换动画**，例如下图就是 Demo 里利用库里自带的 `OpenContainer` 实现页面跳转的 Material 过渡 效果。
|
||||
|
||||
|
||||
|
||||
另外也可以使用 `PageTransitionSwitcher` 实现一些非路由的页面切换动画，可以理解为是一个变异版本的 `AnimatedSwitcher` ，或者是 `Stack` 版动画 `PageView` ，不过支持自定义进入和退出动画，还可以支持自定义布局，一般默认使用默认 `defaultLayoutBuilder` 的话，就是使用 `Stack` 作为布局。
|
||||
|
||||
|
||||
|
||||
官方 Demo 里也会使用 `PageTransitionSwitcher` 来做步进页面跳转的效果，**所以 [animations](https://github.com/flutter/packages/tree/main/packages/animations) 的核心动画能力主要是在于页面过渡方面**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> 总的来说，这个库是官方维护，值得信赖。
|
||||
|
||||
## simple_animations
|
||||
|
||||
[simple_animations](https://github.com/felixblaschke/simple_animations) 如同它的名字所示，它主要是简化了自定义动画的过程，正如前面所示，在 Flutter 里使用动画，我们一般需要定义 `AnimationController` 、`Animatable` 和 `Animation` 等对象来配置动画效果。
|
||||
|
||||
而 simple_animations 提供了 `AnimationMixin` 对象，如下代码所示，你只需要通过 `with` 关键字就可以简化接入动画的代码。
|
||||
|
||||
|  |  |  |
|
||||
| ------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------- |
|
||||
|
||||
同时 simple_animations 也提供了各种 Builder 来简化，例如使用 `MirrorAnimationBuilder` 就可以实现一个循环反复的动画效果。
|
||||
|
||||
|
||||
|
||||
**所以 simple_animations 针对显式动画进行了优化封装，在更方便的情况下做到能更灵活控制动画效果**，如下图所示，在 [gsy_fluter_demo](https://github.com/CarGuo/gsy_flutter_demo/tree/master/lib/widget/particle) 里就利用了 simple_animations 来实现一些动画效果：
|
||||
|
||||
- `MirrorAnimation` 和 `MovieTween ` 实现渐变的背景
|
||||
- `LoopAnimation` 和 `MovieTween` 实现了粒子动画
|
||||
|
||||
|  |  |
|
||||
| ---------------------------------------- | ------------------------------------------ |
|
||||
|
||||
> 不过这个库有个小问题，就是它最近几次大版本，每个版本总是会有一些 break change ，但是可能就是改改名字，换换参数位置，如果你一段时间没关注，再升级可能会有些成本。
|
||||
|
||||
## animate_do
|
||||
|
||||
**[animate_do](https://github.com/Klerith/animate_do_package) 是一个轻量级动画包，它比 simple_animations “更懒”，代码也相对简单很多，内部提供了丰富的动画封装 Widget 可直接使用**。
|
||||
|
||||
> 你可以理解为更丰富的隐式动画。
|
||||
|
||||
animate_do 就是通过 `AnimatedBuilder ` 配合 `Transform` 、`Opacity` 进行了封装，然后开发者可以通过 `FlipInX` 、`FadeInDown` 、`ElasticIn` 等对象直接实现动画效果。
|
||||
|
||||
|
||||
|
||||
既然 animate_do 十分简单，那为什么会推荐它呢？因为它真的很实用。
|
||||
|
||||
**首先简单代表着好维护，作者不玩了我们自己也能接**，其次 animate_do 提供了相当丰富的封装，这对于懒人来说它真的很实用，特别是对于一些 “相对复杂” 的动画效果上（如下图3）可以节省很多时间，特别是在 `Tween` 和 `CurvedAnimation`的封装上。
|
||||
|
||||
|  |  |  |
|
||||
| --------------------------------------- | ----------------------------------------- | --------------------------------------- |
|
||||
|
||||
> 目前有一段时候没更新，但是问题不大～ 同类型的库还有 [spring](https://github.com/KaushickSArgekar/spring) ，可以作为替代项目，也实现了类似的封装。
|
||||
|
||||
# UI 动画
|
||||
|
||||
介绍完基础动画效果，接下来推荐一些常用的动画框架，因为经常有人问到`有没有xxx` 的实现可以直接拿来使用，秉承着有做好的就不自己动手原则，下面这些 UI 动画框架，也许在你开发过程中就会需要用到。
|
||||
|
||||
> UI 动画部分就不介绍实现了，主要就看功能符不符合你需求。
|
||||
|
||||
## 数字动画
|
||||
|
||||
首先是数字动画，常见的有 [flutter-animated-counter](https://github.com/h65wang/flutter-animated-counter) ，本身它就提供了丰富的 API 和动画效果，类似的第三方库还有 [odometer](https://github.com/KirsApps/odometer) 和 [animated_digit ](https://github.com/mingsnx/animated_digit) 等，具体可以自己按需选择。
|
||||
|
||||
|  |  |  |
|
||||
| ------------------------------------------- | ------------------------------------------- | ----------------------------------------- |
|
||||
|
||||
## 跑马灯
|
||||
|
||||
既然聊到文字动画，就不得不说跑马灯，如下表格所示是 Flutter 里常用到的文字跑马灯的第三方 package ，其中 [marquee_widget](https://github.com/yousifk/marquee_widget) 提供的接口相对更佳丰富。
|
||||
|
||||
| [marquee_widget](https://github.com/yousifk/marquee_widget) | [text_scroll](https://github.com/yurii-khi/text_scroll) | [marquee_text](https://pub.dev/packages/marquee_text) |
|
||||
| ----------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------- |
|
||||
|  |  |  |
|
||||
|
||||
## 加载动画
|
||||
|
||||
加载动画是最常见的 UI 动画，如果你没有设计师，如果你不知道 loading 动画用什么好，那你可以考虑下面几个 package，这三个 loading 库都是纯代码实现，提供了丰富的样式选择。
|
||||
|
||||
| [flutter_spinkit](https://github.com/jogboms/flutter_spinkit) | [loading_animation_widget](https://github.com/watery-desert/loading_animation_widget) | [loading_indicator](https://github.com/TinoGuo/loading_indicator) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
> 纯代码实现有什么好处？当样式需要做一些简单调整时，作为开发者可以通过代码快速修改，这是我喜欢纯代码实现动画的原因。
|
||||
|
||||
|
||||
|
||||
## 指引动画
|
||||
|
||||
指引动画也是常见的需求之一，基本实现都会通过 `Overlay` 来完成，不同的可能就是动画效果和定位方式的差异，具体也可以按照自己的需要选择。
|
||||
|
||||
| [feature_discovery](https://github.com/ayalma/feature_discovery) | [flutter_showcaseview](https://github.com/simformsolutions/flutter_showcaseview) | [flutter_intro](https://pub.dev/packages/flutter_intro) | [BubbleShowcase](https://github.com/Skyost/BubbleShowcase) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------- | ---------------------------------------------------------- |
|
||||
|  |  |  |  |
|
||||
|
||||
|
||||
|
||||
## 列表动画
|
||||
|
||||
列表动画也是常见的 UI 动画能力之一，基本上 Flutter 上最常见用都的第三方列表动画库就是下面表格里这三个，坑还是有的，但是“又不是不能用”。
|
||||
|
||||
| [flutter_staggered_animations](https://github.com/mobiten/flutter_staggered_animations) | [animation_list](https://github.com/turlvo/flutter_animation_list) | [transformable_list_view](https://github.com/TBR-Group-software/transformable_list_view) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
## 3D 立体动画
|
||||
|
||||
这个类目可能关注的人反而不是很多，但是恰好是我近期比较关注的动画实现，这里主要推荐两个利用矩阵变换绘制 3D 视觉效果的第三方库，它们不同在于：
|
||||
|
||||
- zwidget 能力相对比较弱，直接使用的是 `Transform` 的能力
|
||||
- zflutter 来源于前端 zdog 项目，是直接对 `Canvas` 的 `path` 进行矩阵变换
|
||||
|
||||
| [zflutter](https://github.com/jamesblasco/zflutter) | [zwidget](https://github.com/apalala-dev/zwidget) |
|
||||
| --------------------------------------------------- | ------------------------------------------------------ |
|
||||
|  |  |
|
||||
|
||||
在不久前我也写过一篇文章 [《Flutter 实现 “真” 3D 动画效果》](https://juejin.cn/post/7129239231473385503)，内容主要分析了 zflutter 的实现逻辑和如何使用 zflutter ，利用纯代码渲染 3D 效果的动画。
|
||||
|
||||
> 当然，上门两个 3D 动画，它们在使用上相对会比较复杂，如果需要更高级的动画效果，建议看下面的推荐。
|
||||
|
||||
# 高级动画支持
|
||||
|
||||
介绍完面向程序员的动画支持之后，最后我们来介绍两个面向设计师的动画支持库，同时也是更好支持复杂动画实现的库。
|
||||
|
||||
## Lottie
|
||||
|
||||
[Lottie](https://github.com/xvrh/lottie-flutter) 相信大家不会陌生，[airbnb ](https://github.com/airbnb) 最优秀的动画开源库，设计师可以通过 AE 插件导出设计好的动画效果，然后利用平台的 `Canvas` 等能力渲染出 AE 上的动画效果。
|
||||
|
||||
|
||||
|
||||
**使用 Lottie 的好处在于，设计师可以更自由的去尝试更炫酷的动画**，而程序员只需要关心如何控制动画（时长，循环，方向，帧率等），同时因为动画大部分时候都是矢量数据，所以 Lottie 文件相对不大。
|
||||
|
||||
> 在早期的时候，由于 Lottie 本身只支持原生平台，所以 Flutter 上都是通过外界纹理或者 `PlatformView ` 等形式接入，这样的后果就是导致各种性能和兼容问题，好在现在 [lottie-flutter](https://github.com/xvrh/lottie-flutter) 已经支持 Dart `Canvas` 的原生 API 。
|
||||
|
||||
当然， Lottie 本身的问题也很明显，那就是你的交互设计师要会 AE ，很遗憾的是，我接触的大部分设计师都不会 AE ，而且会 AE 还不够，还需要会 [Bodymovin](https://github.com/airbnb/lottie-web) 插件相关的兼容，熟悉什么属性可以用，整体开发环境也比较重。
|
||||
|
||||
## Rive
|
||||
|
||||
对于 **[rive](https://link.juejin.cn/?target=https%3A%2F%2Frive.app)** 可能大家会感觉比较陌生，而做过 Flutter 开发的可能对 rive 会有所耳闻，因为 rive 在此之前叫 flare ，是 2dimensions 公司的开源动画产品，在发布之初由于和 Flutter 团队有深入合作，所以在初期一直是 Flutter 官方推荐的动画框架。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------- | ------------------------------------------------------- |
|
||||
|
||||
**[rive](https://link.juejin.cn/?target=https%3A%2F%2Frive.app)** 同样是一个面向设计师的动画框架，只不过他是在 **Web Editor** 里进行 UI 编排和动画绘制，所以他在开发环境上相对会轻量化。
|
||||
|
||||
|  |  |  |
|
||||
| ------------------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
同时 rive 同样是通过导出矢量的动画数据文件（也可以包含一些静态资源），然后利用平台的 `Canvas` 来实现动画效果，所以它的占用提及也不会很大。
|
||||
|
||||
另外 rive 现在也是全平台支持， **Android、 iOS、Web、Desktop、Flutter 、React、Vue、C++** 等都在支持范围之内。
|
||||
|
||||
> 如果想深入了解 rive ，也可以看我之前的 [《给掘金 Logo 快速添加动画效果》](https://juejin.cn/post/7126661045564735519) ，其实对于程序员来说，rive 同时很好上手。
|
||||
|
||||
|
||||
|
||||
> 目前 rive 的问题是，第二代 rive 和第一代 flare 存在断档不兼容，而且基本可以忽略迁移的可能，同时没有本地化免费开发 IDE 有时候也是一种麻烦。
|
||||
|
||||
好了，关于 Flutter 动画相关的内容推荐就到这里，如果你还有什么关于 Flutter 工程或者框架的疑问，欢迎留言评论，也许又可以多一期的素材～
|
||||
|
||||
|
|
@ -0,0 +1,266 @@
|
|||
# Flutter 工程化框架选择 — add-to-app 的指路明灯
|
||||
|
||||
```
|
||||
本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
|
||||
```
|
||||
|
||||
这是 《Flutter 工程化框架选择》 系列的第五篇 ，就像之前说的，这个系列只是单纯告诉你，创建一个 Flutter 工程，或者说搭建一个 Flutter 工程脚手架，应该如何快速选择适合自己的功能模块，或者说这是一个指引系列，所以比较适合新手同学。
|
||||
|
||||
> **这算是目前 Flutter 上少有关于 add-to-app 支持的指导分析了**。
|
||||
|
||||
本来没想写这个话题，因为 add-to-app 混合开发一直是 Flutter 的痛，但目前又属于无法避免的场景 ，有时候甚至还有 [RN内嵌 Flutter UI ](https://cloud.tencent.com/developer/article/1896484)这种“鬼畜”需求，**所以既然大家都有这样的需要，那就来聊聊这类工程下有哪些选择**。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|
||||
# add-to-app
|
||||
|
||||
首先为什么 add-to-app 在 Flutter 里很特殊？**因为 Flutter 里的控件和路由等是通过独立的 FlutterEngine 进行绘制和管理，所以 Flutter 脱离会平台的 UI 渲染机制和页面堆栈**。
|
||||
|
||||
也就是 Flutter 对于原生平台来说是一个“单页面”应用，举一个之前经常说的例子，如下图所示：
|
||||
|
||||
- 在当前 Flutter 端路由堆栈里有 `FlutterA` 和 `FlutterB` 两个页面 Flutter 页面；
|
||||
- 这时候打开新的 `Activity` / `ViewController`，启动了**原生页面X**，可以看到**原生页面 X** 作为新的原生页面加入到原生层路由后，把默认的 `FlutterActivity` / `FlutterViewController` 给挡住，也就是把 `FlutterA` 和 `FlutterB` 都被挡住；
|
||||
- **这时候在 Flutter 层再打开新的 `FlutterC` 页面，可以看到依然会被原生页面X挡住**；
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所以通过这部分内容可以看出来，**Flutter 默认情况下作为“单页面”应用，他们的路由堆栈是和原生层存在不兼容的隔离**，其他问题还有如：内存数据互通、UI 控件嵌套等，这些都是 add-to-app 的痛点。
|
||||
|
||||
那关于 add-to-app 集成方式的选择上，官方在 Android 提供了两种集成方法，在 iOS 提供了三种集成方式，我个人推荐选择以下的集成方式：
|
||||
|
||||
- **Android [本地aar + 远程aar](https://docs.flutter.dev/development/add-to-app/android/project-setup#option-a---depend-on-the-android-archive-aar)** ，这种集成方式 Android 开发团队本地可以不需要安装 Flutter SDK
|
||||
|
||||
- **iOS [生成 xcframework ](https://docs.flutter.dev/development/add-to-app/ios/project-setup#option-b---embed-frameworks-in-xcode)**，这种集成方式 iOS 开发团队本地可以不需要安装 Flutter SDK
|
||||
|
||||
当然以上集成方式最大的问题就是需要分开调试，但从项目耦合上和协调开发上我个人觉得会更符合要求。
|
||||
|
||||
**另外，如果你对如何使用 add-to-app 还有疑问，那官方的 [put-flutter-to-work](https://github.com/flutter/put-flutter-to-work) 项目就是一个很好的参考例子。**
|
||||
|
||||
> add-to-app 跑不起来？参考这个 Demo 是你的最佳选择，例如配置依赖和通过 `FlutterEngineCache` 和 `executeDartEntrypoint` 预热 Engine 等。
|
||||
|
||||
# 混合路由
|
||||
|
||||
这是本篇的重点，通过前面简单的例子，我们可以预见在 add-to-app 里混合路由和数据共享将会是最大的障碍，例如：
|
||||
|
||||
- 打开一个原生页面 A
|
||||
- 再打开一个 Flutter 页面 B
|
||||
- 再打开一个原生页面 C
|
||||
- 再打开一个 Flutter 页面 D
|
||||
|
||||
而这个过程中既要保证混合路由的同步，又要保证数据交互的畅通，那么在这个基础上，**统一路由到原生页面堆栈， “多开 Flutter 页面” 就成为必然的需求**，但是对“多开”的实现又有不同的选择：
|
||||
|
||||
- 每个 Flutter 页面新建一个 Flutter Engine
|
||||
- 多个 Flutter 页面共享一个 Flutter Engine
|
||||
|
||||
**不同实现各自的利弊，而本篇也是主要介绍它们的实现者各自的利弊**。
|
||||
|
||||
## FlutterEngineGroup
|
||||
|
||||
`FlutterEngineGroup` 可能对部分人来说比较陌生，它是在 Flutter 2.0 时发布的 add-to-app 的官方解决方案，**`FlutterEngineGroup` 方案使用了多 Engine 混合支持，官方宣称除了一个 Engine 对象之外，后续每个 Engine 对象在 Android 和 iOS 上仅占用 180kB** 。
|
||||
|
||||
> 以前的方案每多一个Engine ，可能就会多出 19MB Android 和 13MB iOS 的占用。
|
||||
|
||||
在使用 `FlutterEngineGroup` 之后，`FlutterEngine` 都将由 `FlutterEngineGroup` 去生成，生成的 `FlutterEngine` 可以独立应用于 `FlutterActivity`/`FlutterViewController`、 `FlutterFragment` 和 `FlutterView` 等。
|
||||
|
||||
其实 `FlutterEngineGroup` 不一定是用于混合路由，如下动图所示，在官方的 [multiple_flutters](https://github.com/flutter/samples/tree/main/add_to_app/multiple_flutters) 例子里也有在一个页面内放置两个 `FlutterFragment` 的实现，**重点还是在于 `FlutterEngineGroup` 可以在多 Engine 混合模式下保持极低的内存占用**。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------- | ------------------------------------------------------------ |
|
||||
|
||||
之所以 `FlutterEngineGroup` 能在多 Engine 模式下保持极低的内存占用， **其实得益于通过 `FlutterEngineGroup` 生成的 `FlutterEngine` 可以共享 GPU 上下文， font metrics 和 isolate group snapshot** ，也就是新 Engine 可以通过旧 Engine `spawn` 出来。
|
||||
|
||||
而 `FlutterEngineGroup` 里主要是通过 `dartEntrypoint` 来制定入口：
|
||||
|
||||
- **`findAppBundlePath` 默认指向的 `flutter_assets` 目录**；
|
||||
- **`entrypoint` 其实就是 dart 代码里启动方法的名称**；也就是绑定了在 dart 中 `runApp` 的方法，在 dart 可以通过 `@pragma('vm:entry-point')` 来指定
|
||||
- dart 层和原生层通过 `MethodChannel` 共享数据
|
||||
|
||||
|  |
|
||||
| ------------------------------------------------------------ |
|
||||
|  |
|
||||
|  |
|
||||
|
||||
接入 `FlutterEngineGroup` 之后：
|
||||
|
||||
- 在 dart 层面可以通过 `MethodChannel` 打开原始页面；
|
||||
- 在原生层可以通过新建 `FlutterEngine` 打开新的 Flutter 页面；
|
||||
- 甚至你还可以在原生层打开一个 `FlutterView` 的 Dialog；
|
||||
|
||||
当然，到这里你可能已经注意到了，因为每个 Flutter 页面都是一个独立的 Engine ，由于 dart isolate 的设计理念，**每个独立 Engine 的 Flutter 页面内存是无法共享的**。
|
||||
|
||||
也就是说，当你需要共享数据时，只能在原生层持有数据，然后注入或者传递到每个 Flutter 页面中，就像官方所说的，**每个 Flutter 页面更像是一个独立 Flutter 模块**。
|
||||
|
||||
> 当然这也造成了一些不必要的麻烦，比如：**同一张图片，在原生层、不同 Flutter Engine 会出现多次加载的问题**，这种问题可能就需要你针对 Flutter 的图片加载使用外界纹理，来实现在原生层统一的内存管理等。
|
||||
|
||||
**而 `FlutterEngineGroup` 的好处也很直观：官方维护，不需要第三方框架，轻量级**。
|
||||
|
||||
其实 FlutterEngineGroup 不只是在多页面下的场景有价值，就算你只有一个 Engine 也可以考虑它，例如当你在 Service 里去创建 Flutter Engine 并构建独立的 `FlutterView` 效果，但是页面在静止 20 分钟左右后就可能会出现：
|
||||
|
||||
> E/MessageQueue-JNI: java.lang.RuntimeException: Cannot execute operation because FlutterJNI is not attached to native.
|
||||
|
||||
这个时候如果将 Engine 的创建方式换成 FlutterEngineGroup ，你会发现 Engine 因为多次创建和被回收的问题将得到极大程度的缓解。
|
||||
|
||||
> **这里为什么要介绍那么长的 `FlutterEngineGroup` ，因为它是后面的框架有很大关系。**
|
||||
|
||||
## flutter_boost
|
||||
|
||||
在 Flutter add-to-app 这个领域里， [flutter_boost ](https://github.com/alibaba/flutter_boost)相信大家肯定不会陌生，作为最早开源并且支持混合开发路由的框架，**flutter_boost 采用的是单 Engine 内存共享的方式** 。
|
||||
|
||||
|
||||
|
||||
这种实现方式的好处很明显：**那就是 Dart 层面数据状态支持共享**，因为只有一个 Engine ，但是问题也很明显，如下图是 flutter_boost 在 2.0 时的渲染流程，维护一个 Engine 渲染多个 Surface 这种非官方实让 flutter_boost 在很长一段时间没能快速推进项目。
|
||||
|
||||
|
||||
|
||||
不过 flutter_boost 几乎是早期 add-to-app 的不二之选，**但如果你现在要使用 flutter_boost， 那么最好你的 Flutter SDK 是从 3.0 开始**。
|
||||
|
||||
因为在 3.0 之前 flutter_boost 自己拷贝并维护了一套 Engine Embedding 层的自定义代码，这部分代码导致 flutter_boost 更新速度慢并且入侵性更强，而 **flutter_boost 3.0 开始采用继承的方式扩展，后期兼容性更好**。
|
||||
|
||||
> 虽然 flutter_boost 也表示 flutter_boost 3.0 会兼容 Flutter 2.0 ，但是你懂的。
|
||||
|
||||
从目前的 flutter_boost 3.0 上来看，新版本优势主要有：
|
||||
|
||||
- 和 flutter_boost 2.0 对比 Android 和 iOS 两端 API 得到对齐，统一生命周期，代码优化后更好阅读
|
||||
|
||||
- 不侵入 Engine 代码，兼容更多 Flutter 版本，避免因为 flutter_boost 而导致的无法升级 Flutter SDK 等问题
|
||||
- 目前在仍在维护
|
||||
|
||||
当然，如果是对比 `FlutterEngineGroup` flutter_boost 的优势在于：
|
||||
|
||||
- 支持页面间数据传递
|
||||
- 统一的混合路由调用接口
|
||||
- Dart 层面数据支持共享
|
||||
- 支持跨端事件传递
|
||||
|
||||
那缺陷可能是什么？flutter_boost 采用的单 Engine 实现，最大问题就是可能遇到渲染切换上的时机问题，例如：
|
||||
|
||||
- [动画区域会有不停地闪烁出现](https://github.com/alibaba/flutter_boost/issues/1740)
|
||||
- [后台停留出现假死](https://github.com/alibaba/flutter_boost/issues/1671)
|
||||
- [路由跳转或返回可能出现白屏](https://github.com/alibaba/flutter_boost/issues/1719)
|
||||
|
||||
|
||||
|
||||
可以看到在 Flutter 的实现机制上维护一套机制外的逻辑缺失不容易，更不容易的是 flutter_boost 现在还在积极推进和维护，从目前来看 flutter_boost 3.0 会是一个不错的选择。
|
||||
|
||||
|
||||
|
||||
## flutter_thrio
|
||||
|
||||
[flutter_thrio](https://github.com/flutter-thrio/flutter_thrio) 一开始是哈罗单车开源的 add-to-app 集成方案，**后来哈罗不再维护之后，由 flutter_thrio 组织社区开源进行维护**。
|
||||
|
||||
flutter_thrio 采用多 Engine 模式，同时又支持 Engine 复用的逻辑，从目前的代码（[bf16529](https://github.com/flutter-thrio/flutter_thrio/commit/2e0f53861a7c91ba13c0b2c262e4733dfbf16529)）上看，大概逻辑就是：
|
||||
|
||||
> 所有路由操作都通过原生端支持维护，而一个 `ThrioFlutterActivity` / `FlutterViewController` 可以承载多个 Dart 页面，如果 last 页面不是 Flutter 容器，就 `spawn` 一个新的 `FlutterEngine` 并构建新的 Flutter 容器页面。
|
||||
|
||||
|
||||
|
||||
flutter_thrio 的内部实现的多 Engine 模式和 `FlutterEngineGroup` 那套基本一样，不过它是通过反射拿到 `FlutterEngine` 里的 `flutterJNI` ，然后通过 `spawn` 构建新的 `FlutterEngine` 。
|
||||
|
||||
> PS，目前 flutter_thrio 里的 `isMultiEngineEnabled `标识位感觉有些具备迷惑性，其实它更多是控制 `entrypoint` ，通过 `entrypoint` 来决定是否启动新的 `FlutterEngine` 容器。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
另外 flutter_thrio 通过封装，在三端利用统一的 `notify` 接口来实现页面通知进行数据同步，这也是目前 add-to-app 里数据联通的常规实现方案。
|
||||
|
||||
那 flutter_thrio 有什么优势？
|
||||
|
||||
- `FlutterEngine` 可以按需启动
|
||||
- 更低的内存占用
|
||||
- 统一的路由堆栈和数据接口
|
||||
- 轻量级代码，更简便接入
|
||||
|
||||
那这个库有什么问题？
|
||||
|
||||
- 不兼容 `Fragment` 级别支持
|
||||
- 不提供 iOS 中存在的 `present` 功能
|
||||
- 官方不再维护，社区库维护投入有限，理解项目迭代纯靠源码：”**不打算好好看看源码的使用者可以放弃这个库了，因为很多设定是比较死的，而我本人不打算花时间写太多文档**“
|
||||
|
||||
> flutter_thrio 很多 [Feat ](https://github.com/flutter-thrio/flutter_thrio/issues/4)和想法还是很不错的，只是维护的资源有限，希望未来项目还能够继续持续推进。
|
||||
|
||||
## mix_stack
|
||||
|
||||
[mix_stack](https://github.com/yuewen/mix_stack) 是个人开源的混合路由库，从设计上看它类似于早期更轻量级的 boost ，采用的是单 Engine 模式，所以也是通过跳转 Flutter 容器时切换 Surface 来实现路由混合。
|
||||
|
||||
|
||||
|
||||
在 mix_stack 里每一个 Native Flutter Container 都会包含了一个独立的 Navigator 用于维持 Flutter 内栈管理，通过 Flutter 内 Stack 控制当前渲染 Native Container 所属的 Flutter 页面堆栈。
|
||||
|
||||
而 mix_stack 的特点就是**支持多 Tab Flutter View 和 Flutter 端控制 Native 界面隐藏显示** ，其中最有意思的就是 Flutter 端控制 Native 界面隐藏显示的 `NativeOverlayReplacer` 。
|
||||
|
||||
举个例子，如下图所示，此时 `FlutterView` 上面有两个 Native 的控件 navigationBar 和 tabBar ，如果此时我们直接弹出新的 Flutter Route 肯定会被这两个 Native 控件遮挡，但是因为需要 `Hero` 效果，所以又不希望用新的原生容器去承载，这时候就可以用 `NativeOverlayReplacer` 。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ------------------------------------------- |
|
||||
|
||||
如上图右侧动态，在页面内通过 `NativeOverlayReplacer` 指定 `autoHidesOverlayNames` ，然后在弹出 Flutter popup 路由之前调用 `registerAutoPushHiding` ，最终就可以实现 Flutter 控件“渲染在 Native” 之上的效果。
|
||||
|
||||
```dart
|
||||
NativeOverlayReplacer(
|
||||
autoHidesOverlayNames: ["tabBar", "navigationBar"],
|
||||
····
|
||||
NativeOverlayReplacer.of(context).registerAutoPushHiding
|
||||
```
|
||||
|
||||
这里面的原理其实是在页面打开时，通过在原生层利用 `createBitmap` 将两个 Native 控件进行截图，并将 bitmap `toByteArray` 传递到 Flutter 层，之后只需要在 Flutter 控件展示时对原生控件进行隐藏，并通过 `Stack` 在相应位置绘制出 native 控件的 Bitmap ，就可以达到类似 Flutter 控件“渲染在 Native” 之上的效果。
|
||||
|
||||
所以针对 mix_stack 的优势在于：
|
||||
|
||||
- 支持 View 级别调用
|
||||
- 更加灵活
|
||||
- 拥有 `NativeOverlayReplacer` 特性
|
||||
- 支持多 Tab Flutter View
|
||||
|
||||
mix_stack 的劣势也很明显：
|
||||
|
||||
- mix_stack 相对入侵性较强， 例如它在 android 上通过各种反射获取 `FlutterView` 里的 `FlutterEngine` 、 `FlutterTextureView` 等 ，同时还利用反射获取了 `embedding` 的各种内部变量和方法，这对持续维护和稳定性有一定的影响
|
||||
- 个人维护，目前用户不多，可踩坑程度未知。
|
||||
|
||||
> PS：如果你跑 Demo 发现 Android Install Failed ，可以将 `android/app` 目录下的 `debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.4'` 屏蔽
|
||||
|
||||
|
||||
|
||||
## fusion
|
||||
|
||||
[fusion](https://pub.dev/packages/fusion) 采用的是 `FlutterEngineGroup` 方案，默认在 Flutter 与 Native 页面多次跳转情况下，APP 始终仅有一份 FlutterEngine 实例，也就是对应 fusion 里的 `REUSE_MODE` 。
|
||||
|
||||
> 当然， fusion 针对 `FusionFragment` 和 `Dialog` 等场景也提供了不复用场景，可以通过 `FlutterEngineGroup` 底成本构建独立 Engine 的支持。
|
||||
|
||||
如果从代码层面看，fusion 代码相对会简洁不少，比如 `FusionActivity` 在继承 `FlutterActivity` 之后，主要做的两件事：
|
||||
|
||||
- 找到当前 activity 下的 `FlutterView` ，调用 `detachFromFlutterEngine` 停用
|
||||
- 在 `onResume` 里调用 `engine.activityControlSurface.attachToActivity` 和 `flutterView?.attachToFlutterEngine` 复用引擎。
|
||||
|
||||
fusion 的设计理念就是尽可能简洁地去融合对应逻辑，所以侵入性不高，能复用 `embedding ` 相关的逻辑就不自定义，从目前 Demo 运行的情况下内存占用问题也还可以。
|
||||
|
||||
fusion 的优势其实在于作者对一些细节处理比较上心，比如：
|
||||
|
||||
- Flutter 容器与 Native 容器跳转时状态栏图标颜色可能出现显示不正确的问题；
|
||||
- 混合开发时当栈顶是 Flutter 页面时进入到任务界面其应用名称不显示的问题；
|
||||
- 混合开发时 Android APP 在后台被系统回收后再次进入 Flutter 页面不能恢复的问题
|
||||
- 支持生命周期调用
|
||||
|
||||
当然 fusion 的劣势也很明显：
|
||||
|
||||
- 作者 [gtbluesky ]( https://github.com/gtbluesky/fusion) 好像并没有在 Github 开源，所以目前交流反馈存在问题
|
||||
- 存在某些场景下闪动问题
|
||||
- 暂不知道是否还有什么坑
|
||||
|
||||
> PS：如果 demo 跑不起来，先把 compileSdkVersion 改为 32 ，所有 ext.kotlin_version 改为 '1.7.10' 就可以了
|
||||
|
||||
|
||||
|
||||
# 最后
|
||||
|
||||
通过上面分享关于 add-to-app 的现状和框架支持，相信大家对于相关的实现应该都有了一定的了解，采用什么方案和框架具体还是取决于你的需求场景，不管是哪个框架目前都有坑和局限，重点还是在于它未来是否持续维护，或者不维护了我们自己能否继续维护下去。
|
||||
|
||||
这里说一个题外话，其实开源更多是提供解决思路，有效的沟通和 PR 才能推进项目的健康发展，如果社区内基本都是一味的 issue 等待解决，那基本项目都很难长久，所以项目是不是 KPI 并不重要，重要的是它提供的思路是否有用，这才是我认为的开源里最大的价值。
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,332 @@
|
|||
|
||||
|
||||
# Flutter 工程化框架选择 — 状态管理何去何从
|
||||
|
||||
```
|
||||
本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
|
||||
```
|
||||
|
||||
这是 《Flutter 工程化框架选择》 系列的第六篇 ，就像之前说的，这个系列只是单纯告诉你，创建一个 Flutter 工程，或者说搭建一个 Flutter 工程脚手架，应该如何快速选择适合自己的功能模块，或者说这是一个指引系列，所以比较适合新手同学。
|
||||
|
||||
> **其实这是我最不想写的一个篇**。
|
||||
|
||||
状态管理是 Flutter 里 ♾️ 的话题，**本质上 Flutter 里的状态管理就是传递状态和基于 `setState` 的封装，状态管理框架解决的是如何更优雅地共享状态和调用 `setState`** 。
|
||||
|
||||
*那为什么我不是很想写状态管理的对比内容*？
|
||||
|
||||
首先因为它很繁，繁体的煩，从 Flutter 发布到现在，`scoped_model` 、`BLoC` 、`Provider` 、 `flutter_redux` 、`MobX`、 `fish_redux` 、`Riverpod` 、`GetX` 等各类框架“百花齐放”，**虽然这对于社区来说是这是好事，但是对于普通开发者来说很容易造成过度选择困难症**，特别早期不少人被各种框架“伤害过”。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
其次，状体管理在 Flutter 里一直是一个“敏感”话题，每次聊到状态管理就绕不开 `GetX` ，但是一旦聊 `GetX` 又会变成“立场”问题，所以一直以来我都不是很喜欢写状态管理的内容。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------------------ | ----------------------------------------------------------- |
|
||||
|  |  |
|
||||
|
||||
所以本来应该在第一篇就出现的内容，一直被拖到现在才放出来，这里提前声明一些，本篇不会像之前一样从大小和性能等方面去做对比，因为对于状态管理框架来说这没什么意义：
|
||||
|
||||
- **集成后对大小的影响可能还不如一张图片**
|
||||
- **性能主要取决于开发者的习惯，在状态管理框架上对比性能其实很主观**
|
||||
|
||||
当然，如果你对集成后对大小的影响真的很在意，那可以在打包时通过 `--analyze-size` 来生成 analysis.json 文件用于对比分析：
|
||||
|
||||
```shell
|
||||
flutter build apk --target-platform android-arm64 --analyze-size
|
||||
```
|
||||
|
||||
上诉命令在执行之后，会在 `/Users/你的用户名/.flutter-devtools/` 目录下生成一个 `apk-code-size-analysis_01.json` 文件，之后我们只需要打开 Flutter 的 DevTools 下的 `App Size Tooling` 就可以进行分析。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
例如这里是将 `Riverpod` 和 `GetX` 在同一项项目集成后导出不同 json 在 Diff 进行对比，可以看到此时差异也就在 78.5kb ，这个差异大小还不如一张 png 资源图片的影响大。
|
||||
|
||||
|
||||
|
||||
**所以本次主要是从这些状体管理框架自身的特点出发，简单列举它们的优劣，至于最后你觉得哪个适合你，那就见仁见智了**～
|
||||
|
||||
> 本篇只是告诉你它们的特点和如何去选择，并不会深入详细讲解，如果对实现感兴趣的可以看以前分享过的文章：
|
||||
>
|
||||
> >- [Flutter Riverpod 全面深入解析](https://juejin.cn/post/7063111063427874847)
|
||||
> >
|
||||
> >- [全面理解 State 与 Provider](https://juejin.cn/post/6844903866706706439)
|
||||
> >
|
||||
> >- [全面深入理解状态管理设计](https://juejin.cn/post/6844904035439345671)
|
||||
>
|
||||
|
||||
|
||||
|
||||
# Provider
|
||||
|
||||
2019 年的 Google I/O 大会 [Provider](hhttps://github.com/rrousselGit/provider) 成了 Flutter 官方新推荐的状态管理方式之一，它的特点就是： **不复杂，好理解，代码量不大的情况下，可以方便组合和控制刷新颗粒度** ， 其实一开始官方也有一个 [flutter-provide](https://github.com/google/flutter-provide) ，不过后来宣告GG ， [Provider](https://github.com/rrousselGit/provider) 成了它的替代品。
|
||||
|
||||
> ⚠️注意，`provider` 比 `flutter-provide` 多了个 `r`，所以不要再看着 provide 说 Provider 被弃坑了。
|
||||
|
||||
**简单来说，Provider 就是针对 `InheritedWidget` 的一个包装工具**，他让 `InheritedWidget` 的使用变得更简单，在往下共享状态的同时，可以通过 `ChangeNotifier` 、 `Stream` 、`Future` 配合 `Consumer*` 组合出多样的更新模式。
|
||||
|
||||
所以使用 Provider 的好处之一就是简单，同时你可以通过 `Consumer*` 等来决定刷新的颗粒度，其实也就是 `BuildContext` 在 `of(context)` 时的颗粒度控制。
|
||||
|
||||
> 登记到 `InheritedWidget` 里的 context 决定了更新是 rebuild 哪个` ComponentElement` ，感兴趣的可以看 [全面理解 State 与 Provider](https://juejin.cn/post/6844903866706706439)
|
||||
|
||||
*当然，虽然一直说 Provider 简单，但是其实还是有一些稍微“复杂”的地方，例如 `select`* 。
|
||||
|
||||
Provider 里 `select` 是对 `BuildContext` 做了 “二次登记” 的行为，就是以前你用 context 是 `watch` 的时候 ，是直接把这个 Widget 登记到 Element 里，有更新就通知。
|
||||
|
||||
|
||||
|
||||
但是 `select` 做了二次处理，就是用 `dependOnInheritedElement` 做了颗粒化的判断，如果是不等于了才更新，所以它对 context 有要求，如下图对就是对 context 类型进行了判断。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
所以 `select` 算是 Provider 里的“小魔法“之一，总的来说 **Provider 是一个符合 Flutter 的行为习惯，但是不大符合前端和原生的开发习惯的优秀状态管理框架**。
|
||||
|
||||
**优点：**
|
||||
|
||||
- 简单好维护
|
||||
- read、watch、select 提供更简洁的颗粒度管理
|
||||
- 官方推荐
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 相对依赖 Flutter 和 Widget
|
||||
- 需要依赖 Context
|
||||
|
||||
最后顺带辟个谣，之前有 “传闻” Provider 要被弃坑的说法，作者针对这个也有相应对澄清，所以你还是可以继续安心使用 Provider。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Riverpod
|
||||
|
||||
[Riverpod](https://github.com/rrousselGit/riverpod) 和 Provider 是同个作者，**因为 Provider 存在某些局限性，所以作者根据 Provider 这个单词重新排列组合成 Riverpod**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
如果说 Provider 是 `InheritedWidget` 的封装，那 Riverpod 就是在 Provider 的基础上重构出更灵活的操作能力，最直观的就是 **Riverpod 中的 Provider 可以随意写成全局，并且不依赖 `BuildContext` 来编写我们需要的业务逻**。
|
||||
|
||||
> 注意： Riverpod 中的 Provider 和前面的 [Provider](hhttps://github.com/rrousselGit/provider) 没有关系。
|
||||
|
||||
|
||||
|
||||
在 Riverpod 里基本是每一个 “Provider” 都会有一个自己的 “Element” ，然后通过 `WidgetRef` 去 Hook 后成为 `BuildContext` 的替代，所以这就是 Riverpod 不依赖 Context 的 “魔法” 之一
|
||||
|
||||
> ⚠️**这里的 “Element” 不是 Flutter 概念里三棵树的 `Element`，它是 Riverpod 里 `Ref` 对象的子类**。`Ref` 主要提供 Riverpod 内的 “Provider” 之间交互的接口，并且提供一些抽象的生命周期方法，所以它是 Riverpod 里的独有的 “Element” 单位。
|
||||
|
||||
另外对比 Provider ，Riverpod 不需要依赖 Flutter ，所以也不需要依赖 `Widget`，也就是不依赖 `BuildContext `，所以可以支持全局变量定义 “Provider” 对象。
|
||||
|
||||
**优点：**
|
||||
|
||||
- 在 Provider 的基础上更加灵活的实现，
|
||||
- 不依赖 `BuildContext ` ，所以业务逻辑也无需注入 `BuildContext`
|
||||
- Riverpod 会尽可能通过编译时安全来解决存在运行时异常问题
|
||||
- 支持全局定义
|
||||
- `ProviderReference` 能更好解决嵌套代码
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 实现更加复杂
|
||||
- 学习成本提高
|
||||
|
||||
**目前从我个人角度看，我觉得 Riverpod 时当前之下状态管理的最佳选择，它灵活且专注，体验上也更符合 Flutter 的开发习惯**。
|
||||
|
||||
> 注意，很多人一开始只依赖 `riverpod` 然后发现一些封装对象不存在，因为 `riverpod` 是不依赖 flutter 的实现，所以在 flutter 里使用时不要忘记要依赖 `flutter_riverpod` 。
|
||||
|
||||
|
||||
|
||||
# BLoC
|
||||
|
||||
[BLoC](https://github.com/felangel/bloc) 算是 Flutter 早期比较知名的状态管理框架，它同样是存在 `bloc` 和 `flutter_bloc` 这样的依赖关系，**它是基于事件驱动来实现的状态管理**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**`flutter_bloc` 基于事件驱动的核心就是 `Stream` 和 Provider** ， 是的， `flutter_bloc` 依赖于 Provider，然后在其基础上设计了基于 `Stream` 的事件响应机制。
|
||||
|
||||
所以严格意义上 BLoC 其实是 Provider + `Stream` ，如果你一直很习惯基于事件流开发模式，那么 BLoC 就很适合你，**但是其实从我个人体验上看，BLoC 在开发节奏上并不是快，相反还有点麻烦**，不过优势也很明显，基于 `Stream` 的封装可以更方便做一些事件状态的监听和转换。
|
||||
|
||||
```dart
|
||||
BlocSelector<BlocA, BlocAState, SelectedState>(
|
||||
selector: (state) {
|
||||
// return selected state based on the provided state.
|
||||
},
|
||||
builder: (context, state) {
|
||||
// return widget here based on the selected state.
|
||||
},
|
||||
)
|
||||
|
||||
MultiBlocListener(
|
||||
listeners: [
|
||||
BlocListener<BlocA, BlocAState>(
|
||||
listener: (context, state) {},
|
||||
),
|
||||
BlocListener<BlocB, BlocBState>(
|
||||
listener: (context, state) {},
|
||||
),
|
||||
BlocListener<BlocC, BlocCState>(
|
||||
listener: (context, state) {},
|
||||
),
|
||||
],
|
||||
child: ChildA(),
|
||||
)
|
||||
```
|
||||
|
||||
|
||||
|
||||
**优点：**
|
||||
|
||||
- 代码更加解耦，这是事件驱动的特性
|
||||
- 把状态更新和事件绑定，可以灵活得实现状态拦截，重试甚至撤回
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 需要写更多的代码，开发节奏会有点影响
|
||||
- 接收代码的新维护人员，缺乏有效文档时容易陷入对着事件和业务蒙圈
|
||||
- 项目后期事件容易混乱交织
|
||||
|
||||
> 类似的库还有 [rx_bloc](https://github.com/Prime-Holding/rx_bloc) ，同样是基于 `Stream` 和 Provider ， 不过它采用了 rxdart 的 `Stream` 封装。
|
||||
|
||||
|
||||
|
||||
# flutter_redux
|
||||
|
||||
[flutter_redux](https://github.com/brianegan/flutter_redux) 虽然也是 pub 上的 Flutter Favorite 的项目，但是现在的 Flutter 开发者应该都不怎么使用它，而恰好我在刚使用 Flutter 时使用的状态管理框架就是它。
|
||||
|
||||
|
||||
|
||||
> 其实前端开始者对 redux 可能会更熟悉一些，当时我恰好用 RN 项目切换到 Flutter 项目，在 RN 时代我就一直在使用 redux，flutter_redux 自然就成了我首选的状态管理框架。
|
||||
|
||||
其实这也是 Flutter 最有意思的，很多前端的状态管理框架都可以迁移到 Flutter ，例如 flutter_redux 里就是利用了 `Stream`特性，通过 `redux` 单向事件流的设计模式来完成解耦和拓展。
|
||||
|
||||
|
||||
|
||||
在 flutter_redux 中，开发者的每个操作都只是一个 `Action` ，而这个行为所触发的逻辑完全由 `middleware` 和 `reducer` 决定，这样的设计在一定程度上将业务与UI隔离，同时也统一了状态的管理。
|
||||
|
||||
当然缺陷也很明显，你要写一堆代码，开发逻辑一定程度上也不大符合 Flutter 的开发习惯。
|
||||
|
||||
**优点：**
|
||||
|
||||
- 解耦
|
||||
- 对 redux 开发友好
|
||||
- 适合中大型项目里协作开发
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 影响开发速度，要写一堆模版
|
||||
- 不是很贴合 Flutter 开发思路
|
||||
|
||||
说到 redux 就不得不说 [fish_redux](https://pub.flutter-io.cn/packages/fish_redux) ，如果说 redux 是搭积木，那闲鱼最早开源的 fish_redux 可以说是积木界的乐高，闲鱼在 `redux` 的基础上提出了 `Comoponent` 的概念，这个概念下 `fish_redux` 是从 `Context` 、`Widget` 等地方就开始全面“入侵”你的代码，从而带来“超级赛亚人”版的 `redux` 。
|
||||
|
||||
|
||||
|
||||
**所以不管是 flutter_redux 还是 fish_redux 都是很适合团队协作的开发框架，但是它的开发体验和开发过程，注定不是很友好**。
|
||||
|
||||
|
||||
|
||||
# GetX
|
||||
|
||||
[GetX](https://pub.flutter-io.cn/packages/get) 可以说是 Flutter 界内大名鼎鼎，**Flutter 不能没有 GetX 就像程序员不能没有 PHP ，GetX 很好用，很具备话题，很全面同时也很 GetX**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
严格意义上说现在 GetX 已经不是一个简单的状态管理框架，它是一个统一的 Flutter 开发脚手架，在 GetX 内你可以找到：
|
||||
|
||||
- 状态管理
|
||||
- 路由管理
|
||||
- 多语言支持
|
||||
- 页面托管
|
||||
- Http GetConnect
|
||||
- Rx GetStream
|
||||
- 各式各样的 extension
|
||||
|
||||
可以说大部分你想到的 GetX 里都有，甚至还有基于 GetX 的 [get_storage ](https://github.com/jonataslaw/get_storage) 实现纯 Dart 文件级 key-value 存储支持。
|
||||
|
||||
所以很多时候使用 GetX 开发甚至不需要关心 Flutter ，当然这也导致经常遇到的奇怪情况：*大家的问题集中在 GetX 里如何 xxxx，而不是 Flutter 如何 xxxx* ，**所以 GetX 更像是依附在 Flutter 上的解决方案**。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
**当然，使用 GetX 最直观的就是不需要 `BuildContext ` ，甚至是你在路由跳转时都不需要关心 Context ，这就让你的代码看起来很“干净”，把整个开发过程做到“面向 GetX 开发”的效果** 。
|
||||
|
||||
另外 GetX 和 Provider 等相比还具备的特色是：
|
||||
|
||||
- ` Get.put` 、`Get.find` 、`Get.to` 等操作完全无需 Widget 介入
|
||||
- 内置的 `extension` 如各类基础类似的 `*.obs` 通过 `GetStream` 实现了如 `var count = 0.obs;` 和 `Obx(() => Text("${controller.name}"));` 这样的简化绑定操作
|
||||
|
||||
那 GetX 是如何脱离 Context 的依赖？说起来也不复杂，例如 ：
|
||||
|
||||
- `GetMaterialApp` 内通过一个会有一个 `GlobalKey` 用于配置 `MaterialApp` 的 `navigatorKey` ，这样就可以通过全局的 `navigatorKey` 获取到 `Navigator` 的 `State` ，从而调用 `push` API 打开路由
|
||||
|
||||
- `Get.put` 和 `Get.find` 是通过一个内部全局的静态 `Map` 来管理，所以在传递和存放时就脱离了 `InheritedWidget` ，结合 `Obx` ，在对获取到的 `GetxController` 的 value 时会有个 `addListener` 的操作，从而实现 ` Stream` 的绑定和更新
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
**可以说 GetX 内部有很多“魔法”，这些魔法或者是对 Flutter API 的 Hook、或者是直接脱离 Flutter 设计的自定义实现，总的来说 GetX “有自己的想法”**。
|
||||
|
||||
这也就带来一个了个问题，很多人新手一上手就是 GetX ，然后对 Flutter 一知半解，特别是深度解绑了 Context 之后，很多 Flutter 问题就变成了 GetX 上如何 xxxx，例如前面的： *Flutter GetX 如何调用谷歌地图这种问题*。
|
||||
|
||||
|
||||
|
||||
> 如果使用 GetX 而不去思考和理解 GetX 的实现，就很容易在 Flutter 的路上走歪，比如上面各种很基础的问题。
|
||||
|
||||
这其实也是 GetX 的最大问题：**GetX 做的很多，它入侵到很多领域，而且它拥有很多“魔法”**，这些“魔法”让 Flutter 开发者不知布局的脱离了本来应有的轨迹。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
当然，你说我就是想完成需求，好用就行，何必关心它们的实现呢？从这个角度看 GetX 无疑是非常不错的选择，只要 GetX 能继续维护下去并把“魔法”继续兼容。
|
||||
|
||||
> 大概就是：**GetX “王国” 对初级开发者友好，但是“魔法全家桶”其实对社区的健康发展很致命**。
|
||||
|
||||
**优点：**
|
||||
|
||||
- 瑞士军刀式护航
|
||||
- 对新人友好
|
||||
- 可以减少很多代码
|
||||
|
||||
**缺点：**
|
||||
|
||||
- 全家桶，做的太多对于一些使用者来说是致命缺点，需要解决的 Bug 也多
|
||||
- “魔法”使用较多，脱离 Flutter 原本轨迹
|
||||
- 入侵性极强
|
||||
|
||||
总的来说，GetX 很优秀，他帮你都写好了很多东西，省去了开发者还要考虑如何去组合和思考的过程，从我个人的角度我不喜欢这种风格，但是它总归是可以帮助你提高开发效率。
|
||||
|
||||
**另外还有一个状态管理库 [Mobx](https://github.com/mobxjs/mobx.dart) ，它库采用了和 GetX 类似的风格，虽然 Mobx 的知名度和关注度不像 GetX 那么高，但是它同样采用了隐式依赖的模式，某种意义上可以把 [Mobx](https://github.com/mobxjs/mobx.dart) 看成是只有状态管理版本的 GetX**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 最后
|
||||
|
||||
通过上面分享的内容，相信大家对于选哪个状态管理框架应该有自己的理解了，**还是那句废话，采用什么方案和框架具体还是取决于你的需求场景，不管是哪个框架目前都有坑和局限，重点还是在于它未来是否持续维护，或者不维护了你自己能否继续维护下去**。
|
||||
|
||||
最后，如果你还有什么疑问，或者针对 Flutter 工程选择上还有哪些茫然，欢迎留言评论。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,233 @@
|
|||
# Flutter 工程化框架选择 — 搞定 UI 生产力
|
||||
|
||||
|
||||
|
||||
```
|
||||
本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
|
||||
```
|
||||
|
||||
这是 《Flutter 工程化框架选择》 系列的第二篇 ，就像之前说的，这个系列只是单纯告诉你，创建一个 Flutter 工程，或者说搭建一个 Flutter 工程脚手架，应该如何快速选择适合自己的功能模块，或者说这是一个指引系列，所以比较适合新手同学。
|
||||
|
||||
本篇主要介绍 UI 相关的，**但是完全单纯介绍 UI 好像又有点水，那就是加一些小知识来吸吸水分吧**。
|
||||
|
||||
做为前端开发，我们的大部分职责就是开发 UI ，但是如果有人帮我们提前把 UI 做好，那岂不美哉？事实上很多时候 UI 确实是可以模版化，而前端领域也一直是这样，例如 `Ant Design` 、`Element-UI` 等 ，那 Flutter 上是否也有这样的支持？
|
||||
|
||||
答案肯定是有的，但是在介绍它们之前，**我们先聊一个 Flutter UI 的问题：嵌套**。
|
||||
|
||||
> 为了不太水，我们前言聊技术，后半部分推荐项目。
|
||||
|
||||
# 前言- UI 嵌套
|
||||
|
||||
谈到 Flutter 肯定就有人说嵌套，是的， Flutter 本身就是通过直接嵌套 `Widget` 来渲染 UI ， 所以大家可能就会吐槽类似下面的代码，虽然这段代码没有意义，但是这里我们要先思考两个问题：
|
||||
|
||||
- **Flutter 怕不怕 `Widget `嵌套影响性能**？
|
||||
- **Flutter 有没有办法解决嵌套**？
|
||||
|
||||
|
||||
|
||||
**首先第一点就是，Flutter 一般情况下不怕嵌套影响性能，因为 “众所周知” 的原因，Flutter 里的 `Widget` 并不是真正的控件，我更愿意说 `Widget` 是配置文件，真正的绘制和布局对象是它背后的 `RenderObejct` 等相关逻辑**。
|
||||
|
||||
> 嵌套层级看起来很多的原因，是因为 `Widget` 颗粒度太细。
|
||||
|
||||
当然这个还要看你嵌套的 `Widget` 做了什么？或者说是嵌套的 `Widget` 的 `RenderObject` 做了什么，例如：
|
||||
|
||||
- `Padding` 的 `RenderPadding` 就是在 layout 时多了一个 `Size` 和 `childParentData.offset` 计算
|
||||
- `ColoredBox` 的 `_RenderColoredBox` 就是多一句 `drawRect`
|
||||
- `Align` 的 `RenderPositionedBox` 就是多计算一个 `childParentData.offset`
|
||||
|
||||
所以这些 `Widget` 的颗粒度很细，但是也很轻，我们直接用的时候可能会一层一层嵌套，看起来不美观，但是实际渲染时对性能影响不大。
|
||||
|
||||
> **当然，并不是所有的 `Widget` 都很轻不怕嵌套**，例如 `Clip` 、`Transform` 和 `Opacity ` 等，如果涉及到 `pushLayer` 等操作时，在需要做图层合成的时候，那确实对性能影响还是比较大的。
|
||||
|
||||
**那第二个问题，如何解决嵌套？这时候你就需要 “配置模版” ，通过封装来优化代码结构**。
|
||||
|
||||
“配置模版”是什么意思？举个例子 ： `Container` 应该用过吧？ `Container` 其实就是官方给大家准备的 “模版” ，它本身只是一个 `StatelessWidget` ，也就是一个没有 `RenderObject` 的 `Widget` ，它靠的就是把各种功能的 `Widget ` 组合起来使用，如下图就是使用 `Container` 的对比情况。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
所以在使用 Flutter 构建 UI 时，就可以谈及到两个点：
|
||||
|
||||
- `Widget` 是配置文件，它一般很轻，不怕嵌套，真正绘制渲染的是它背后的 `RenderObject`
|
||||
- 通过各种 UI 配置模版来解决嵌套，特别是抽象出适合自己业务逻辑的 UI 模版
|
||||
|
||||
举个例子，如下方的第三方开源布局包 [dashboard](https://github.com/Mehmetyaz/dashboard) ，在这种复杂的 UI 布局上难道就靠直接一级一级嵌套 `Column` 和 `Row` 来解决？答案肯定不是！
|
||||
|
||||
|  |  |
|
||||
| --------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
[dashboard](https://github.com/Mehmetyaz/dashboard) 的是通过 `Stack` + `Positioned` 组成模版，在手势移动时计算，通过 `AnimatedBuilder` 实现动画偏移，自动计算控件位置。
|
||||
|
||||
> 其实也可以直接用 `AnimatedPositioned` ，具体可见 [《Flutter 小技巧之有趣的动画技巧》](https://juejin.cn/post/7111071430292275213)
|
||||
|
||||
所以可以看到， **Flutter 里你其实可以不那么嵌套，具体还是看你的封装方式**，除了这样，还有就是直接在 `RenderObject` 上进行自定义布局，比如下方这两个例子：
|
||||
|
||||
| [cloud](https://github.com/CarGuo/gsy_flutter_demo/tree/master/lib/widget/cloud) | [custom_multi_render](https://github.com/CarGuo/gsy_flutter_demo/blob/master/lib/widget/custom_multi_render_demo_page.dart) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |
|
||||
|
||||
你说上面的布局用 `Stack` + `Positioned` 的模式能不能做？肯定是可以，但是在 `RenderObject` 层实现不是更优雅吗？**把脏活累活写在 `RenderObject` ， 通过 `Widget` 提供配置接口，这样就不会一上来就向用户露 “底裤” 不是么**。
|
||||
|
||||
> 所以，把眼界打开，不要什么都盯着 `Widget` 嵌套，往 `RenderObject` 层面探索，你会发现 Flutter 其实不像表面那么浮躁，再不济来尝试下 `CustomMultiChildLayout` ，它也可以帮助你解决一些复杂布局下的嵌套问题。
|
||||
|
||||
当然，还有一些项目另辟蹊径，**比如 [niku](https://github.com/SaltyAom/niku) ，这个项目通过 `typedef` 和抽象拓展，利用语法对官方控件进行二次封装**，实现创建了一个 “非正道” 的 UI 配置效果，具体如下图所示，喜不喜欢就看个人爱好了，但是它确实一定程度解决了嵌套可视化的问题。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> 作者是个二次元，但是看地址他应该是泰国哥们
|
||||
|
||||
当然，我们这一期的关键是提高 UI 生产力，单说源码实现就没劲了，所以重点让我们看后半部分。
|
||||
|
||||
# UI 套件
|
||||
|
||||
在前端领域，**使用统一的 UI 套件可以加快开发的节奏，减少开发和设计之间的摩擦，而且风格统一**。一般情况下，在企业内部都是在不知不觉中沉淀下来各种组件，最后形成组件池，从而落地成 UI 套件。
|
||||
|
||||
比如**贝壳的 [bruno](https://github.com/LianjiaTech/bruno) ，我愿意称它为 Flutter 界的 `Element-UI`** ，目前已经支持到 Flutter 3 ，作为少有国内大厂维护的 Flutter UI 项目，甚至它还提供了 [sketch 设计指引](https://bruno.ke.com/page/guide/sketch) 和 [设计物料下载](https://bruno.ke.com/download/sketch) 。
|
||||
|
||||
| [bruno](https://github.com/LianjiaTech/bruno) | [getwidget](https://github.com/ionicfirebaseapp/getwidget) | [fsuper](https://github.com/Fliggy-Mobile/fsuper) |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|  |  |  |
|
||||
|
||||
当然，除了 bruno 之后，像 [getwidget](https://github.com/ionicfirebaseapp/getwidget) 、 [fsuper](https://github.com/Fliggy-Mobile/fsuper) 也提供了日常开发中常用的 UI 套件，虽然风格风格上可能并没有 bruno 统一，但是还是可以在一定程度提高开发的生产力。
|
||||
|
||||
> 事实上对于个人开发者来说，这种套件可以解决很多设计上的问题。
|
||||
|
||||
**另外聊到 Flutter UI 套件就要一定要介绍国内的 [fluttercandies](https://github.com/fluttercandies)** 组织，fluttercandies 是由大佬们共同维护的一系列 Flutter 开源项目，记住，是大佬们，并且一直在持续更新：
|
||||
|
||||
- [extended_image](https://pub.flutter-io.cn/packages/extended_image)
|
||||
- [extended_nested_scroll_view](https://pub.flutter-io.cn/packages/extended_nested_scroll_view)
|
||||
- [extended_text](https://pub.flutter-io.cn/packages/extended_text)
|
||||
- [extended_text_field](https://pub.flutter-io.cn/packages/extended_text_field)
|
||||
- [extended_list](https://pub.flutter-io.cn/packages/extended_list)
|
||||
- [extended_sliver](https://pub.flutter-io.cn/packages/extended_sliver)
|
||||
- [extended_tabs](https://pub.flutter-io.cn/packages/extended_tabs)
|
||||
- [wechat_assets_picker](https://pub.flutter-io.cn/packages/wechat_assets_picker)
|
||||
- [waterfall_flow](https://pub.flutter-io.cn/packages/waterfall_flow)
|
||||
|
||||
> 举个例子，如果 flutter framework 短期不能解决的问题，那就大佬就会 cv 一份控件自己维护，这就是 fluttercandies 的节奏和优势。
|
||||
|
||||
## PC
|
||||
|
||||
既然介绍 Flutter UI ，就不得不介绍 PC 相关的风格的 UI ，因为 Flutter 不只是 Android 和 iOS ，它还支持 Web 和 PC， 所以类似 PC 的 UI 风格也值得推荐，**比如 ant_design_flutter 就是一个很有意思的项目**。
|
||||
|
||||
| [fluent_ui](https://github.com/bdlukaa/fluent_ui) | [macos_ui](https://github.com/GroovinChip/macos_ui) | [ant_design_flutter](https://github.com/CalsRanna/ant_design_flutter) |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
## Responsive
|
||||
|
||||
那有的人可能就说，**我想要一套代码适配多平台的屏幕尺寸**行不行？答案肯定是可以的，下面这几个 package 就提供了不同屏幕尺寸下一套代码的动态适配方案，我个人可能会比较喜欢 ResponsiveFramework 。
|
||||
|
||||
| [ResponsiveFramework](https://github.com/Codelessly/ResponsiveFramework) | [responsive_sizer](https://github.com/CoderUni/responsive_sizer/) | [flutter_adaptive_ui](https://github.com/mohammadtaherri/flutter_flexible_ui/tree/main/packages/flutter_adaptive_ui) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
## Appbar
|
||||
|
||||
这类 Appbar 的实现其实是我被问过最多的，其实它的核心实现都是 Sliver ，严格意义上我觉得并不需要第三方库，自己用 Sliver 就可以实现，但是本着能不动手就不动手原则，也推荐几个库吧：
|
||||
|
||||
| [draggable_home](https://github.com/4-alok/draggable_home) | [extended_sliver](https://github.com/fluttercandies/extended_sliver) | [scroll_app_bar](https://github.com/edsonbonfim/scroll_bars/tree/master/scroll_app_bar) |
|
||||
| ---------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
> [gsy_flutter_demo](https://github.com/CarGuo/gsy_flutter_demo) 里也提供了几种实现思路，其实并不复杂。
|
||||
|
||||
## Drawer
|
||||
|
||||
可能有人会觉得，不会吧不会吧， Drawer 也需要第三方库？
|
||||
|
||||
还真有，因为有时候可能需要不一样的动画效果，另外这里的 `sidebarx` ，也和官方提供的 `NavigationRail`有异曲同工之妙，能在 UI 上适配多平台的操作习惯。
|
||||
|
||||
| [sidebarx](https://github.com/Frezyx/sidebarx) | [flutter_advanced_drawer](https://github.com/alex-melnyk/flutter_advanced_drawer) | [curved_drawer](https://github.com/undrbridge/curved_drawer) |
|
||||
| ---------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
|
||||
|
||||
## Tarbar
|
||||
|
||||
既然都说到 `Drawer `，那 `Tabbar` 也提供几个花里胡哨的动画效果，主要是切换时的动画效果，另外 `tab_container` 可能算是比较有意思的库，用的 `Path` 来编绘背景动画效果。
|
||||
|
||||
| [flutter-cupertino-tabbar](https://github.com/aliyigitbireroglu/flutter-cupertino-tabbar) | [tab_indicator_styler](https://github.com/adar2378/tab_indicator_styler) | [tab_container]( https://github.com/sourcemain/tab_container) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
## BottomBar
|
||||
|
||||
说到 `Tabbar` 相对应的还有 BottomBar 相关，这里也提供几个库，主要是动画效果很有趣，我个人还是挺喜欢这种曲线的动画效果。
|
||||
|
||||
| [curved_navigation_bar](https://github.com/rafalbednarczuk/curved_navigation_bar) | [salomon_bottom_bar](https://github.com/lukepighetti/salomon_bottom_bar) | [bubble_bottom_bar](https://github.com/westdabestdb/bubble_bottom_bar) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
## 指引
|
||||
|
||||
启动指引这个需求，正常情况下一个 `PageView` 就可以满足产品经理的场景，但是有时候可能会需要你来“亿”点点动画效果来增加 KPI，所示拿着也许就对你有用了，当然你也可以把它当作 `PageView` 动画来使用。
|
||||
|
||||
| [concentric_transition](https://pub.dev/packages/concentric_transition) | [nice_intro](https://github.com/Ethiel97/nice_intro) | [intro_views_flutter](https://github.com/aagarwal1012/IntroViews-Flutter) |
|
||||
| ------------------------------------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
## 角标
|
||||
|
||||
这个应该无需多言了，基本上 App 都会需要用到，这两个库基本覆盖了 90% 的场景
|
||||
|
||||
| [flutter_badges](https://github.com/yadaniyil/flutter_badges) | [corner_decoration](https://github.com/kalaganov/corner_decoration) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |
|
||||
|
||||
|
||||
|
||||
## 动画按键
|
||||
|
||||
这个可能一般情况下大家都不需要这么花里胡哨的效果，但是万一呢？Material 风格上这种交互还是挺多的，不过国内对 Material 确实不是很感冒。
|
||||
|
||||
| [flutter_animated_button](https://github.com/NikhilVadoliya/FlutterAnimatedButton) | [progress_state_button](https://github.com/slm/progress-state-button) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |
|
||||
|
||||
## 头像
|
||||
|
||||
没想到吧？头像为什么还需要库？
|
||||
|
||||
其实就是下面的这个场景，相信这个场景可能大家都不会陌生，有社交需求的时候，经常会存在这样的 UI ，掘金沸点不也有类似 UI 么？
|
||||
|
||||
| [avatar_stack](https://github.com/cyrax111/avatar_stack) | [overflow_view](https://github.com/letsar/overflow_view) | |
|
||||
| -------------------------------------------------------- | -------------------------------------------------------- | ---- |
|
||||
|  |  | |
|
||||
|
||||
|
||||
|
||||
## swipe 卡片
|
||||
|
||||
这个需求可能一般人不会需要，推荐它是因为我还记得几年的时候，收了 1000 给人做了这样的一个外包，就是做一个这样的控件。
|
||||
|
||||
| [swipe_deck](https://github.com/retroportalstudio/swipe_deck.git) | [swipeable_card_stack](https://github.com/codetoart/cta-flutter-tinder-card-animation) | [appinio_swiper](https://github.com/appinioGmbH/flutter_packages/tree/main/packages/appinio_swiper) |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|
||||
|
||||
|
||||
## bottom sheet
|
||||
|
||||
这其实更多是一个 Route 相关的动画效果，感觉好像国内也不常用到，但是之前确实有好几次咨询有没有类似的实现。
|
||||
|
||||
| [we_slide](https://github.com/luciano-work/we_slide) | [sliding_up_panel](https://github.com/akshathjain/sliding_up_panel) |
|
||||
| ---------------------------------------------------- | ------------------------------------------------------------ |
|
||||
|  |  |
|
||||
|
||||
|
||||
|
||||
## 时间轴 UI
|
||||
|
||||
这是我在群里被问过好多次的一个需求场景，我也不知道为什么那么多应用会需要用到这样的 UI ？不过这类需求自己从头实现确实会比较费事。
|
||||
|
||||
| [timeline_tile](https://github.com/JHBitencourt/timeline_tile) | [timelines](https://pub.dev/packages/timelines) |
|
||||
| ------------------------------------------------------------ | ----------------------------------------------- |
|
||||
|  |  |
|
||||
|
||||
好了，关于 Flutter UI 相关的内容推荐就到这里，**本篇主要还是提供给大家如何理解 Flutter 的 UI 布局，并且尽可能去解决嵌套，同时提供一些有意思的第三方 package ，进一步提高大家开发 UI 的生产力**。
|
||||
|
||||
最后，如果你还有什么关于 Flutter 工程或者框架的疑问，欢迎留言评论，也许新的素材又有了～
|
||||
|
|
@ -0,0 +1,408 @@
|
|||
# Flutter 工程化框架选择 — 搞定数据存储选型
|
||||
|
||||
```
|
||||
本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
|
||||
```
|
||||
|
||||
这是 《Flutter 工程化框架选择》 系列的第三篇 ，就像之前说的，这个系列只是单纯告诉你，创建一个 Flutter 工程，或者说搭建一个 Flutter 工程脚手架，应该如何快速选择适合自己的功能模块，可以说这是一个指引系列，所以比较适合新手同学。
|
||||
|
||||
> **Flutter 上关于数据存储或者数据库详细选型介绍的内容很少，也算是一个补全吧**。
|
||||
|
||||
本篇主要介绍数据存储相关，可能就有人会觉得，数据存储有什么好说的？不就是写个 Plugin 接个原生数据库就好了吗？这都能水？
|
||||
|
||||
确实，最简单快捷的方法就是写个 Plugin ，通过 Dart 直接调用原生平台的数据存储能力，这样实现成本最低，但是对于 Flutter 来说可能不够优雅：
|
||||
|
||||
- 通过 `MethodCallHandler` 调用的方式，中间过程存在一定程度的性能消耗，特别是读写数据量比较大的时候
|
||||
- Flutter 需要多平台支持，通过 `MethodCallHandler` 调用原生平台，就需要在每个平台的使用不同的代码和适配逻辑，会提高维护成本
|
||||
|
||||
**所以针对 Flutter 平台，现在社区的数据存储工具实现都默契的采用了另外一种方式**，当然不是说使用 `MethodCallHandler` 的 Plugin 实现不行，具体选型还是需要看你所需要的场景。
|
||||
|
||||
> Let's go 💗 ～
|
||||
|
||||
# Plugin 调用原生平台实现
|
||||
|
||||
首先简单介绍一下大家比较熟悉的两个数据存储的库，它们都是通过 Plugin 直接调用原生平台 API 进行数据存储：
|
||||
|
||||
- **[shared_preferences](https://github.com/flutter/plugins/tree/main/packages/shared_preferences) key-value 的简单数据存储**，相信 Android 开发对这个名称会很亲切，官方维护，实现简单，支持全平台，适合对性能要求不高和数据量不大的场景
|
||||
|
||||
|
||||
|
||||
> 不过也是因为 `MethodCallHandler` 调用的方式，从维护和调用路径上会显得比较复杂，**federated plugin 的写法和版本管理方式容易出现问题**，已经不止一次在使用官方的 federated plugin 因为内部版本问题踩坑。
|
||||
|
||||
- [sqflite](https://github.com/tekartik/sqflite/tree/master/sqflite) 可以说是最早的第三方 Flutter 数据库之一，支持 iOS、 Android 和 MacOS ，为什么不支持全平台，**这其实也是 Plugin 直接调用多平台的问题之一，你需要重复在每个平台上实现同一个逻辑，虽然初期开发成本低，但是后续维护成本并不低**，同时 [sqflite](https://github.com/tekartik/sqflite/tree/master/sqflite) 提供的能力也比较弱，封装程度不高，主要还是解决了早期对数据库迫切支持的需求。
|
||||
|
||||
**既然说到 [sqflite](https://github.com/tekartik/sqflite/tree/master/sqflite) ，这里推荐一个 [flutter-sqlite-viewer](https://github.com/frgmt/flutter-sqlite-viewer) 的第三方工具**，相信大家在操作数据的时候都有可视化查看的需求，虽然开发过程中可以如下左图一样在 Android Studio 里通过 App Inspection 查看，但是有一些场景你没办法提供直连 Debug 调试，这时候 flutter-sqlite-viewer 就可以很方便提供本地化数据库查看的能力。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | -------------------------------------- |
|
||||
|
||||
|
||||
|
||||
# sqlite3
|
||||
|
||||
从这里开始我们介绍不大一样的，[sqlite3](https://github.com/simolus3/sqlite3.dart/tree/master/sqlite3) 采用的是 `dart:ffi` 实现直接通过 Dart 访问数据库的能力，那这里的区别是什么？
|
||||
|
||||
- dart 和 c/c++ 的相关代码可以跨平台，不需要维护多份同样的平台逻辑（虽然需要维护多份编译产物）
|
||||
- dart 和数据库直接交互，省去中间过程的转换需要
|
||||
- **有问题了你不好调试**
|
||||
|
||||
> 其实从 Flutter 2.0 和 Dart 2.12 提供 FFI 支持开始，到现在的 Dart 3.0 正式版发布，官方一直都在完善 ffi 还有和平台语言直接交互的能力，例如在 [Dart 2.18 里 Dart 就支持与 Objective-C 和 Swift 直接交互](https://juejin.cn/post/7137874832988831751)。
|
||||
|
||||
目前 sqlite3 支持 Android、iOS、Linux、MacOS、Window 平台，并且在特定平台还提供了切换到 [SQLCipher](https://www.zetetic.net/sqlcipher/) 的支持：
|
||||
|
||||
- Android 平台可以**依赖 `sqlite3_flutter_libs` 来集成最新的 sqlite3 版本，也可以通过依赖 `sqlcipher_flutter_libs` 来切换到 SQLCipher**
|
||||
- iOS 平台和 macOS 平台与 Android 类似
|
||||
- Windows 和 Linux 平台可以依赖 `sqlite3_flutter_libs` 来集成最新的 sqlite3 版本
|
||||
- Web 平台其实也支持，只是只支持在 WASM 模式下，也就是 `--web-renderer canvaskit ` 的时候使用，同时还需要一些额外的操作，例如把 `sqlite3.wasm` 放到 `web/` 目录下
|
||||
|
||||
> **当然其实 sqlite3 不只是支持 Flutter ，它的 ffi 也是 Dart 的能力，所以它也可以直接用在 dart server 上**。
|
||||
|
||||
所以在 sqlite3 里 Dart 就是通过 `dart:ffi` 直接和数据库交互，而 Plugin 里的内容更多只是一个初始化的作用，例如 `sqlcipher_flutter_libs` 的 Plugin 就是加载对应的 `sqlcipher.so` 。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Drift
|
||||
|
||||
**可能是直接使用 sqlite3 还不够优雅，所以作者针对 sqlite3 又封装了一套 [Drift](https://github.com/simolus3/drift)** ，Drift 同样可以脱离 Flutter 运行，因为它底层 sqlite3 依然基于 `dart:ffi` ，支持 Android、iOS、macOS、Linux 、 Windows 和 web ， **不同之处是它对事务、 migrations、复杂过滤、表达式、批量更新和 joins 等操作做了封装**，例如：
|
||||
|
||||
- 根据注解生成映射代码
|
||||
- 对查询结果根据 Stream 实现自动更新
|
||||
- 更方便的管理 schema migrations 和 `CREATE TABLE`
|
||||
|
||||
例如你可以通过如下所示进行聚合查询，将多个数据结果合并到一起：
|
||||
|
||||
```dart
|
||||
Future<void> countTodosInCategories() async {
|
||||
final amountOfTodos = todos.id.count();
|
||||
|
||||
final query = select(categories).join([
|
||||
innerJoin(
|
||||
todos,
|
||||
todos.category.equalsExp(categories.id),
|
||||
useColumns: false,
|
||||
)
|
||||
]);
|
||||
query
|
||||
..addColumns([amountOfTodos])
|
||||
..groupBy([categories.id]);
|
||||
|
||||
final result = await query.get();
|
||||
|
||||
for (final row in result) {
|
||||
print('there are ${row.read(amountOfTodos)} entries in'
|
||||
'${row.readTable(categories)}');
|
||||
}
|
||||
}
|
||||
|
||||
Stream<double> averageItemLength() {
|
||||
final avgLength = todos.content.length.avg();
|
||||
final query = selectOnly(todos)..addColumns([avgLength]);
|
||||
return query.map((row) => row.read(avgLength)!).watchSingle();
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
当然，这并不是最有趣的，**Drift 里最有意思的是提供了 sql 解析器和分析器**，所以你可以通过 sql 语句来生成 API，并且还会在构建时提供错误警告。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
这里顺便提一嘴，**在 Flutter 里通过状态管理工具往下传递 `database` 大家应该不陌生吧**， drift 官方同样建议使用 `provider` 或者 `riverpod` 往下传递 `database` 对象，例如：
|
||||
|
||||
```dart
|
||||
void main() {
|
||||
runApp(
|
||||
Provider<MyDatabase>(
|
||||
create: (context) => MyDatabase(),
|
||||
child: MyFlutterApp(),
|
||||
dispose: (context, db) => db.close(),
|
||||
),
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
同时，针对 sqlite，作者还提供了相关的选择建议：
|
||||
|
||||
- 如果你不怕麻烦，想更轻量级，那么可以直接使用 [sqlite3](https://github.com/simolus3/sqlite3.dart/tree/master/sqlite3)
|
||||
- 如果你只需要 Stream 实现自动更新，不需要自动生成 dart 查询映射，那可以选择 [sqlcool]([Homepage](https://github.com/synw/sqlcool))
|
||||
- 如果你需要和 Drift 功能类似，但是需要更灵活的自定义能力且不介意麻烦的话，可以选择 [floor](https://github.com/vitusortner/floor)
|
||||
|
||||
最后，如下图所示，你还可以用 [db_viewer ](https://github.com/vanlooverenkoen/db_viewer) 来预览数据库内容数据。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Realm
|
||||
|
||||
可能不少人对 [realm](https://github.com/realm/realm-dart) 还并不了解，第一次接触 realm 是在 2016 年开发 React Native 的时候，那时候 realm 几乎就是我首选的数据库，它作为 SQLite 的替代，采用的是 MongoDB 的数据库方案。
|
||||
|
||||
|
||||
|
||||
如今 realm 也开始支持 Flutter ，虽然还在 Beta（已经 Beta 挺久了），但是它同样采用了基于 `dart:ffi` 的实现，所以 realm 同样支持脱离 Flutter 纯 Dart 运行，并且支持 Android、iOS 、Linux、MacOS 、Windows 等平台运行。
|
||||
|
||||
> 关于 MongoDB 和 SQL 的差异对比这里就不说，主要就是关系型数据库与非关系型数据库的区别
|
||||
|
||||
那 realm 最大的特别之处是什么？**那就是它除了提供本地数据库能力之外，它还提供数据同步和后端存储能力**。
|
||||
|
||||
简单来说，就是 realm 的数据库支持实时同步，在此之前我设计的 React Native 项目里，就有基于 realm 很快就开发出一套支持数据备份和同步的聊天应用的场景。
|
||||
|
||||
|
||||
|
||||
简单介绍一下，就是在 realm 的后台服务上，主要需要通过定义 Schema Table 和 sync 权限，就可以通过 realm SDK 在启动时同步数据，并对数据进行实时同步，而在 realm 上，你可以通过 `Credentials` 和 `User` 来定义角色的读写权限和管理数据。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
如下图所示，开启 sync 之后，在 iPhone 模拟器上点击添加的任务，在 Android 模拟器上就会实时同步 iPhone 上对数据库的操作更改，并且 realm 的 sync 后台默认就支持集群服务，如果用户量不是特别大的情况下，拿来做聊天或者客服场景还是很可行的。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> [realm-dart-samples ](https://github.com/realm/realm-dart-samples)里同样提供了对应的例子，但是它的例子有问题，所以你需要自己注册 realm.io 上的服务，并且获取到 appId 后，替换 appId 并在 realm 后台创建自己的 Task 表，开启 sync 服务。
|
||||
|
||||
同时 realm 也提供 [realm-studio](https://github.com/realm/realm-studio) 支持数据库可视化的能力，当然，如果你使用了 realm 的数据同步服务，那么在 Atlas 上也可以实时看到对应的数据更新。
|
||||
|
||||
|  |  |
|
||||
| ------------------------------------------------ | ----------------------------------------------------------- |
|
||||
|
||||
不过还是那句话，目前 realm 还在 beta ，例如：
|
||||
|
||||
- 很多 API 上可以看到文档紧缺
|
||||
- 不支持 reload ，sync 模式下一 reload 就crash
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
另外，比如我不说，你翻阅文档也很难找到 Flutter 上如何监听和同步查询结果变化，而其实这部分代码其实你只需要通过 `stream` 就可以接入实现。
|
||||
|
||||
```dart
|
||||
StreamBuilder<RealmResultsChanges<Task>>(
|
||||
stream: MyApp.allTasksRealm.all<Task>().changes,
|
||||
builder: (c, s) {
|
||||
return Text((s.data != null) ? s.data!.results.length.toString() : "null",
|
||||
style: Theme.of(context).textTheme.headline4);
|
||||
})
|
||||
```
|
||||
|
||||
所以目前在 Flutter 上，如果在其他平台之前用过 realm ，那可以试试；但是如果没有，建议先不躺坑，等正式版吧。
|
||||
|
||||
> 其实和 Realm 一样具有实时同步能力，同样是基于文件的非关系数据库，并且更稳定更可靠的数据库是 [firebase_database](https://github.com/firebase/flutterfire/tree/master/packages/firebase_database/firebase_database) ，不过周所周知的欢迎，国内基本不会选择它。
|
||||
|
||||
# ObjectBox
|
||||
|
||||
[ObjectBox ](https://github.com/objectbox/objectbox-dart) 其实和 Realm 类似，也是 NoSQL 类型的数据库，同样是基于 `dart:ffi` ，支持 Android 、iOS 、Linux 、MacOS 和 Window，**号称在能耗和速度上有绝对的优势，同时因为是纯 Dart API，所以它完全不需要你熟悉或者学习 SQL 语法** 。
|
||||
|
||||
```dart
|
||||
@Entity()
|
||||
class Person {
|
||||
int id;
|
||||
|
||||
String firstName;
|
||||
String lastName;
|
||||
|
||||
Person({this.id = 0, required this.firstName, required this.lastName});
|
||||
}
|
||||
|
||||
final store = await openStore();
|
||||
final box = store.box<Person>();
|
||||
|
||||
var person = Person(firstName: 'Joe', lastName: 'Green');
|
||||
|
||||
final id = box.put(person); // Create
|
||||
|
||||
person = box.get(id)!; // Read
|
||||
|
||||
person.lastName = "Black";
|
||||
box.put(person); // Update
|
||||
|
||||
box.remove(person.id); // Delete
|
||||
|
||||
// find all people whose name start with letter 'J'
|
||||
final query = box.query(Person_.firstName.startsWith('J')).build();
|
||||
final people = query.find(); // find() returns List<Person>
|
||||
```
|
||||
|
||||
> 目前 objectbox 支持 dart 、java、kotlin 、swift 甚至还支持 GO 和 Python
|
||||
|
||||
在使用体验上，ObjectBox 可能会更贴近 NoSQL 的操作习惯， 另外它也可以直接在服务端被使用，从官方提供的基准测试中看，ObjectBox 的整体性能确实很优秀（其中的 Hive 后面介绍）。
|
||||
|
||||
|
||||
|
||||
> 对测试感兴趣的可以看 [objectbox-dart-performance](https://github.com/objectbox/objectbox-dart-performance) ，不要问我它是不是真的这么好用，因为我也没在生产项目上使用它。
|
||||
|
||||
ObjectBox 另外一个特点就是支持离线数据同步：[ObjectBox Sync](https://objectbox.io/sync/) ，和 realm 还有 firebase 类似，这其实已经成为 NoSQL 服务商都会提供的特色之一。
|
||||
|
||||
|
||||
|
||||
ObjectBox Sync 离线同步的支持主要在：**当设备离线时数据操作会被保存在本地，当设备连接上网络时，数据会恢复同步**。
|
||||
|
||||
|
||||
|
||||
> 抛开 sync 能力不谈，ObjectBox 作为本地数据库在性能和开发体验上真的很不错。
|
||||
|
||||
# Hive
|
||||
|
||||
前面介绍的都是比较重的数据库类型，那接下来介绍个轻量型的存储框架： [Hive ](https://github.com/hivedb/hive/tree/master/hive)。
|
||||
|
||||
**Hive 是一个纯 Dart 实现的轻量 key-value 数据库，主要通过 dart/io 对文件进行读写**，支持 Android 、iOS、Linux、MacOS、Window、Web 平台。
|
||||
|
||||
作为 key-value 数据库，它其实很适合用来替代 shared_preferences ，并且它支持使用 AES 进行加密，目前官方提供的基准测试数据上性能表现还不错（虽然数据一大可能就拉胯）。
|
||||
|
||||
|
||||
|
||||
Hive 的使用介绍这里就不赘述了，因为真的很简单直接，在 Hive 里：
|
||||
|
||||
- Box 就类似 SQL 里的表
|
||||
|
||||
- Object 就类似于数据库中的实体对象
|
||||
|
||||
- Adapter 可以用来做自定义对象的适配器，可以用于实现一些`read` / `write` 操作
|
||||
|
||||
```dart
|
||||
import 'package:hive/hive.dart';
|
||||
|
||||
void main() async {
|
||||
Hive.registerAdapter(PersonAdapter());
|
||||
var persons = await Hive.openBox('persons');
|
||||
|
||||
var person = Person()
|
||||
..name = 'Lisa';
|
||||
|
||||
persons.add(person); // Store this object for the first time
|
||||
|
||||
print('Number of persons: ${persons.length}');
|
||||
print("Lisa's first key: ${person.key}");
|
||||
|
||||
person.name = 'Lucas';
|
||||
person.save(); // Update object
|
||||
|
||||
person.delete(); // Remove object from Hive
|
||||
print('Number of persons: ${persons.length}');
|
||||
|
||||
persons.put('someKey', person);
|
||||
print("Lisa's second key: ${person.key}");
|
||||
}
|
||||
|
||||
@HiveType()
|
||||
class Person extends HiveObject {
|
||||
@HiveField(0)
|
||||
String name;
|
||||
}
|
||||
|
||||
class PersonAdapter extends TypeAdapter<Person> {
|
||||
@override
|
||||
final typeId = 0;
|
||||
|
||||
@override
|
||||
Person read(BinaryReader reader) {
|
||||
return Person()..name = reader.read();
|
||||
}
|
||||
|
||||
@override
|
||||
void write(BinaryWriter writer, Person obj) {
|
||||
writer.write(obj.name);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**另外 Hive 也支持如 `Hive.openLazyBox` 进行懒加载和 `compactionStrategy` 压缩数据来针对大数据量进行优化**，但是正如作者在 [#782 ](https://github.com/hivedb/hive/issues/782) 介绍的，当数据超过一定数量时，比如 50,000 ，那从性能上还是使用 SQLite 更好。
|
||||
|
||||
|
||||
|
||||
当然，在 [#170](https://github.com/hivedb/hive/issues/170#issuecomment-573874355) 里有通过对 `isolate` 提供共享内存的支持来优化 Hive ，但是很明显这条路是走不通的。
|
||||
|
||||
|
||||
|
||||
另外目前针对 **Hive 好像没有比较合适的可视化工具，这也许会影响部分人在选型上的考量**，不过 [hivedb](https://docs.hivedb.dev/#/more/vscode-snippets) 在 VSCode 上提供了模版代码片段的支持，也算是具备另外一种“微弱”的优势。
|
||||
|
||||
|
||||
|
||||
> PS：其实你可以拿 hivedb 当简单状态管理用，并且 Hive 脱离 Flutter 放在 dart server 端也是可以的运行。
|
||||
|
||||
**同样支持 key-value 高效存储的还有 [MMKV](https://github.com/Tencent/MMKV/tree/master/flutter ) ，MMKV 同样是利用 `dart:ffi` 支持了 Flutter ，相信 Android 开发对它不会陌生， 另外 [GetStorage](https://github.com/jonataslaw/get_storage) 也是基于二进制文件的键值对存储，不过更“低能”一些**。
|
||||
|
||||
# isar
|
||||
|
||||
**也许是因为觉得 Hive 不够优秀，或者是 Hive 不支持高级查询，所以作者后续新推了新的数据库框架： [isar](https://github.com/isar/isar/tree/main/packages/isar)** ，同样基于 `dart:ffi` ，支持 Android 、iOS、Linux、MacOS、Window、Web 平台。
|
||||
|
||||
**如果说 Hive 可以简单代替 shared_preferences ，那 isar 就更像是平替 sqlite 的数据库**，所以 isar 更像是为了解决 query 问题而做的 Hive2.0 ，例如：
|
||||
|
||||
- 支持复合和多索引、查询修饰符、JSON等
|
||||
- 多 isolate 支持
|
||||
- 支持十万条记录存储在单个 NoSQL 数据库
|
||||
|
||||
和 Hive 相比 isar 功能更丰富，不再只是单纯的 key-value 操作，可以支持更复杂的 filter 等查询条件，从使用体验上更符合 NoSQL 的数据库能力。
|
||||
|
||||
```dart
|
||||
await isar.writeTxn(() async {
|
||||
final idsOfUnstarredContacts = await contacts.filter()
|
||||
.isStarredEqualTo(false)
|
||||
.idProperty()
|
||||
.findAll();
|
||||
|
||||
contacts.deleteAll(idsOfUnstarredContacts);
|
||||
});
|
||||
```
|
||||
|
||||
同时 isar 提供了强大的可视化工具 ，通过 Isar Inspector 也是在一定程度补全了 Hive 的不足，使用 Inspector 只需要在 open 时设置 `inspector: true` 就可以看到 ws 地址进行绑定访问。
|
||||
|
||||
|
||||
|
||||
其实 isar 另外的好处就是完全开源，从构建脚本到逻辑代码都是开源，例如其中通过 [`Cargo.toml` ](https://github.com/isar/isar/blob/main/packages/isar_core_ffi/Cargo.toml) 编排 `isar_core_ffi `，然后在 github action 会在发布时通过 shell 脚本执行如何构建 isar 的动态库等。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
例如 isar 在 iOS 上最重接入的是 `isar.xcframework` ，在 Android 上是 `isar.so`
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
目前集成 isar 库本身并不是很大，例如在 Android 上集成之后，大小只增加了大概 600 多k ，所以作为 Hive 的升级版本，isar 确实值得一试，。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
> 目前由于 Isar Web 依赖于 IndexedDB ，所以可能和其他平台相比较存在一定限制。
|
||||
|
||||
最后我们看来自 [guide-to-isar](https://itnext.io/a-minimalist-guide-to-isar-ee43c1e51a85) 和 [flutter-db-benchmarks](https://github.com/msxenon/flutter-db-benchmarks) 的一份数据对比：
|
||||
|
||||
- 左边的数据对比提供了在 50,000 条数据下
|
||||
- 插入耗时 isar < ObjectBox < Realm
|
||||
- 删除耗时 isar < Realm < ObjectBox
|
||||
- 数据库大小 isar < Realm < ObjectBox
|
||||
- 条件查询 isar < Realm < ObjectBox
|
||||
- 右边的数据对比了在 10,000 条数据下
|
||||
- 插入耗时 ObjectBox < isarAsync < isarSync < Hive
|
||||
- 读取耗时 Hive < ObjectBox < isarAsync < isarSync
|
||||
- 更新耗时 ObjectBox < isarAsync < isarSync < Hive
|
||||
- 删除耗时 ObjectBox < isarAsync < isarSync < Hive
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
这两份数据虽然看起来有矛盾点，但是这其实和测试环境有关系：
|
||||
|
||||
- 左侧的图片时在较为正常设备上的测试，可以视为一般情况
|
||||
|
||||
- 右侧的数据测试的是在低端设备上的表现，可以视为最坏的情况
|
||||
|
||||
就像 [#211](https://github.com/isar/isar/discussions/211) 里讨论的，同样的基准测试，作者在它的设备上测试反而 isar 表现更好，讨论的结论上看也是，**除了速度之外，在是否导致 UI 卡顿上 isar 的表现也更好，所以基准测试的覆盖范围也是一种考量**。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 最后
|
||||
|
||||
最后，本篇介绍了 [shared_preferences](https://github.com/flutter/plugins/tree/main/packages/shared_preferences) 、 [sqlite3](https://github.com/simolus3/sqlite3.dart/tree/master/sqlite3) 、 [Drift](https://github.com/simolus3/drift) 、 [realm](https://github.com/realm/realm-dart) 、 [ObjectBox ](https://github.com/objectbox/objectbox-dart) 、 [Hive ](https://github.com/hivedb/hive/tree/master/hive) 和 [isar](https://github.com/isar/isar/tree/main/packages/isar) 等数据存储框架，简略带过的还有 [sqlcool]([Homepage](https://github.com/synw/sqlcool)) 、 [floor](https://github.com/vitusortner/floor) 、 [MMKV](https://github.com/Tencent/MMKV/tree/master/flutter ) 和 [GetStorage](https://github.com/jonataslaw/get_storage) 等，可以看到，**这份数据也侧面体现了目前 Flutter 生态的健全，至少在数据存储框架上就可以让人产生“选择困难症”** 。
|
||||
|
||||
如果你还有什么关于 Flutter 工程或者框架的疑问，欢迎留言评论，这个系列是否更新就取决于是否还有新的素材～
|
||||
|
|
@ -0,0 +1,164 @@
|
|||
# Flutter 工程化框架选择 — 混合开发的摸爬滚打
|
||||
|
||||
```
|
||||
本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
|
||||
```
|
||||
|
||||
这是 《Flutter 工程化框架选择》 系列的第四篇 ，就像之前说的，这个系列只是单纯告诉你，创建一个 Flutter 工程，或者说搭建一个 Flutter 工程脚手架，应该如何快速选择适合自己的功能模块，可以说这是一个指引系列，所以比较适合新手同学。
|
||||
|
||||
> **本篇将着重介绍混合开发里的一些技术选型，顺便额外科普一些坑，看到后面你就会明白为什么要做这一期分类，算是相对偏技术的一期**。
|
||||
|
||||
在 Flutter 里进行混合开发一直都是“痛点”，其中最主要的原因就是：**Flutter 有自己独立的渲染引擎，因为 Flutter 控件渲染脱离了平台控件的 render tree，这也造成了 Flutter 在混合开发上的实现相对复杂了不少**。
|
||||
|
||||
> 比较形象的理解：类似于把原生控件塞到 WebView 里渲染。
|
||||
|
||||
事实上在 Flutter 里混合开发也分为两种：**在 Flutter 里混合原生平台控件**（`PlatformView`）和**将 Flutter 混合到原生平台项目（`add-to-app `）**，今年我们的主题是 `PlatformView` ，这其中又以 Android 的 `PlatformView` 混合原生控件“故事最多”，当然今天我们不是从头去讲解它的技术实现，对历史技术实现感兴趣的可以看之前的文章，今天主要是聊如何去“选“。
|
||||
|
||||
> - [Flutter 3.0下的混合开发演进](https://juejin.cn/post/7113655154347343909)
|
||||
> - [Flutter 深入探索混合开发的技术演进](https://juejin.cn/post/7093858055439253534)
|
||||
> - [混合开发下 HybridComposition 和 VirtualDisplay 的实现与未来演进](https://juejin.cn/post/7071549421116194847)
|
||||
> - [《1.20 下的 Hybrid Composition 深度解析》](https://juejin.cn/post/6858473695939084295)
|
||||
> - [《 Android PlatformView 和键盘问题》](https://juejin.cn/post/6844904070906380296)
|
||||
|
||||
|
||||
|
||||
# PlatformView
|
||||
|
||||
在 Flutter 里混合原生平台的控件需要通过 `PlatformView` 进行接入实现，**在这方面 iOS 的实现方式一直变化不大，但是在 Android 上不同版本到目前就出现了三种实现逻辑**，所以本篇主要介绍 Android 平台如何选择合适的 `PlatformView` 方案。
|
||||
|
||||
抛开最早期如 [flutter_webview_plugin](https://pub.dev/packages/flutter_webview_plugin) 这种直接进行覆盖原生控件的实现不谈， `PlatformView` 在 Android 上目前官方提供的就有三种实现方式：
|
||||
|
||||
- **`VirtualDisplays`** ：类似于一个虚拟显示区域，将虚拟显示区域的内容渲染在一个内存 `Surface`上，然后同步纹理到 Engine ，事实上控件并不在渲染位置。
|
||||
|
||||
|
||||
|
||||
- **`HybridComposition`** ： 通过 `addView` 直接添加原生平台控件，需要层级覆盖时利用 `FlutterImageView` 承载 Flutter 控件的渲染进行堆叠，原生控件会在渲染位置。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **`TextureLayer`** ：在渲染位置通过原生的透明 ` PlatformViewWrapper` 做容器，然后通过替换 Canvas 将原生控件的纹理渲染到特定 Surface 上，控件不在渲染位置，但是可以通过父容器做事件拦截。
|
||||
|
||||
|
||||
|
||||
> 是不是看完有点懵？不怕后面会有对应的例子解释，不理解也不要紧，这一篇是教你如何选，所以也并不需要真的理解内部是如何实现。
|
||||
|
||||
但是上面介绍的这三种实现也是有前提条件的，比如：
|
||||
|
||||
- Flutter 1.2 之前，你只能用 `VirtualDisplays`
|
||||
- Flutter 3.0 之前，你只能用 ` VirtualDisplays` 和 `HybridComposition`
|
||||
- Flutter 3.3 之前，你只能用 `TextureLayer` 和 `HybridComposition`
|
||||
- Flutter 3.3 开始，你能用 `VirtualDisplays`、 `TextureLayer` 和 `HybridComposition`
|
||||
|
||||
是不是觉得有些奇怪，为什么会有奇怪的排列方式？这里面的故事线大概是这样的：
|
||||
|
||||
- 因为 `VirtualDisplays` 存在触摸事件和键盘等问题，所以通过 `addView` 进行原生堆叠的 `HybridComposition` 出现，解决了手势和键盘等问题
|
||||
- 因为 `HybridComposition ` 存在一些场景缺陷，比如列表卡顿，渲染线程不同步导致闪动等问题，所以 `VirtualDisplays` 得以继续服役
|
||||
- 3.0 开始默认 `VirtualDisplays` 和 `HybridComposition` 被替换为 `TextureLayer` ，但是 `HybridComposition` 实现依旧保留，在使用时需要显式执行 **`PlatformViewsService.initExpensiveAndroidView`** 才能使用，因为 `TextureLayer` 存在没办法替代原生控件 Canvas 的场景，同时 `TextureLayer` 要求 Flutter Mini SDK API 23
|
||||
- 3.3 开始 `VirtualDisplays` 实现又回来了，因为需要支持 Mini SDK API 23 以下的场景，同时比如 `SurfaceView` 机制原因，这类场景 `TextureLayer` 实现没办法直接兼容，所以 3.3 开始在遇到 `SurfaceView` 实现时 `TextureLayer` 会切换为 `VirtualDisplays` 模式
|
||||
|
||||
> **这里面固然有实现成本的问题，同时也有社区把控的问题，才造成了这样“混乱”的局面**。
|
||||
|
||||
上面这么说可能有些抽象，我们再看具体例子，首先看官方的 [webview_flutter](https://pub.dev/packages/webview_flutter) 实现， 如下表格所示，最初的时候 WebView 插件默认是使用了 `AndroidWebView` ，也就是 `VirtualDisplays` 相关的实现；后来有了 `HybridComposition` 之后就新增了 `SurfaceAndroidWebView` ，用户在需要时可以根据场景自行切换。
|
||||
|
||||
| 默认判断 | VirtualDisplays | HybridComposition |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|  |  |  |
|
||||
|
||||
这里就不得不提以前的 issue ，如果你的 WebView 存在触摸或者键盘问题就可以通过下述代码来解决，因为正如前面说过， `HybridComposition` 是通过 `addView` 的方式添加原生控件，所以能尽可能保存控件本身的特性。
|
||||
|
||||
```dart
|
||||
if (Platform.isAndroid) WebView.platform = SurfaceAndroidWebView();
|
||||
```
|
||||
|
||||
而后来 webview_flutter 在更新迭代里默认实现里也修改为了 `SurfaceAndroidWebView` ，因为 `HybridComposition` 确实更适合 WebView 的场景，比如 H5 的详情页。
|
||||
|
||||
| 默认判断 | TextureLayer | HybridComposition |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|  |  |  |
|
||||
|
||||
上面的例子可能还不够典型，接着我们再看一个典型的例子： MapView ，如下所示，目前国内 Flutter 里常见的地图实现有：
|
||||
|
||||
- 华为：[huawei_map](https://pub.dev/packages/huawei_map)
|
||||
- 高德：[amap_flutter_map](https://pub.flutter-io.cn/packages/amap_flutter_map)
|
||||
- 百度： [flutter_baidu_mapapi_map ](https://pub.flutter-io.cn/packages/flutter_baidu_mapapi_map)
|
||||
|
||||
虽然他们都是采用了 `PlatformView` 的实现，但是选择的实现方式却存在一定差异，而通过这些差异也可以很好比对 `PlatformView` 实现的区别：
|
||||
|
||||
- [高德 Flutter 插件](https://developer.amap.com/api/flutter/guide/map-flutter-plug-in/map-flutter-info)采用的是 `AndroidView` 的实现方式，也就是在 3.0 以下是 `VirtualDisplays` ，在 3.0 以上是 `TextureLayer` ， 从表中的图 2 也可以看到在 Flutter 3.0 MapView 父容器对应的 `TextureLayer` 的 ` PlatformViewWrapper` 。
|
||||
|
||||
| dart 实现 | TextureLayer |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|  |  |
|
||||
|
||||
这里额外需要注意的是：**由于隐私政策等原因，现在基本地图框架都需要做一定的隐私相关适配**，高德也不例外，所以如果想正常使用 SDK ，就需要注意初始化时的适配问题。
|
||||
|
||||
|
||||
|
||||
> 对隐私和权限问题感兴趣可以看 [《2022 年 App 上架审核问题集锦，全面踩坑上线不迷路》](https://juejin.cn/post/7142363251911688222)
|
||||
|
||||
- [华为 Flutter 地图插件](https://pub.dev/packages/huawei_map)选择的则是 `HybridComposition` 的实现方式，注意下图代码里的 `initExpensiveAndroidView ` ，因为**现在使用 `PlatforViewLink` 已经不能作为是否使用 `HybridComposition` 的判定标准**，3.0 开始必须显式配置了 `initExpensiveAndroidView ` 才是 `HybridComposition` 。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
| 3.0之前 `PlatforViewLink` | 3.0之后 `PlatforViewLink` + `initSurfaceAndroidView` | 3.0之后 `PlatforViewLink` + `initExpensiveAndroidVie` |
|
||||
| -------------------------- | ------------------------------------------------------ | ------------------------------------------------------- |
|
||||
| `HybridComposition` | `TextureLayer` | `HybridComposition` |
|
||||
|
||||
> 对 `HybridComposition` 详细实现感兴趣的可以了解：[混合开发下 HybridComposition 和 VirtualDisplay 的实现与未来演进](https://juejin.cn/post/7071549421116194847) 和 [《1.20 下的 Hybrid Composition 深度解析》](https://juejin.cn/post/6858473695939084295)
|
||||
|
||||
- [百度 Flutter 地图插件](https://lbsyun.baidu.com/index.php?title=flutter/loc/create-project/configure)采用的是 `AndroidView` 的实现方式，但是原生端提供了 `TextureView` 和 `SurfaceView` 两种实现选择，这又产生了不同的组合结果。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
| 3.0之前 | 3.0 | 3.0之后 |
|
||||
| ----------------- | ---------------------------------------------- | ------------------------------------------------------------ |
|
||||
| `VirtualDisplays` | `TextureLayer` （ `SurfaceView` 方案无法工作） | `VirtualDisplays`（SurfaceView）/ `TextureLayer`（TextureView） |
|
||||
|
||||
从下方的 Layout Inspector 可以看到，在 Flutter 3.3 下，**百度地图插件如果使用了 `MapSurfaceView` 就会采用 `VirtualDisplays` ，而如果使用了 `MapTextureView` 就会采用 `TextureLayer` ，这是为什么呢**？
|
||||
|
||||
| SurfaceView | TextureView |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|  |  |
|
||||
|
||||
前面我们不是说过，Flutter 在 3.0 的时候通过 `TextureLayer` 取代了 `VirtualDisplays` ，而 `TextureLayer` 的实现方式就是通过 ` PlatformViewWrapper` 来替换 child 的 Canvas 从而提取纹理，但是在某些场景下就会有问题，例如 `SurfaceView` 。
|
||||
|
||||
> 简单来说，`SurfaceView` 是比较特殊的场景，本身它具备双缓冲机制，类似于两个 `Canvas` ，同时在 WMS 有独立的 `WindowState `， 所以渲染逻辑其实是脱离了原本的 View hierachy ，因此 Flutter 3.0 下的 `TextureLayer` 的 hook Canvas 实现没办法兼容。
|
||||
|
||||
所以在 Flutter 3.3 中 `VirtualDisplays` 又回来了，作为多年服役的"老将"，**当运行平台低于 23 或者原生控件是 `SurfaceView` 时，就会继续降级采用 `VirtualDisplays` 的相关实现，这也算是折中的实现**。
|
||||
|
||||
|  |  |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
|
||||
> 如果对这部分感兴趣的可以查阅 [Flutter 3.0下的混合开发演进](https://juejin.cn/post/7113655154347343909) / [Flutter 深入探索混合开发的技术演进](https://juejin.cn/post/7093858055439253534)
|
||||
|
||||
所以现在知道为什么要做这一期了吧？**Flutter 的 `PlatformView` 实现因为历史包袱留下了很多“坑”，不理清楚这些坑，很可能就会让你在遇到问题时找不到方向**，总结一下：
|
||||
|
||||
- `VirtualDisplays` 老骥伏枥，采用的是虚拟显示提取纹理的方式，可能存在手势和键盘问题，适合列表和小控件场景，在 3.0 版本中缺席
|
||||
- `HybridComposition` 在 1.2 版本之后出现，因为是通过 `addView` 和层级堆叠实现混合，能尽可能保证控件的“原汁原味”，但是性能开销会比较大，不适合列表里使用，在 3.0 之后需要显式调用 `initExpensiveAndroidView`
|
||||
- `TextureLayer` 在 3.0 版本开始出现，通过 Hook 住控件 Canvas 的方式实现纹理提取，但是需要 miniSDK 23 ，适用于替代 `VirtualDisplays` 的场景，但是在 3.3 开始遇到 `SurfaceView` 时会降级为 `VirtualDisplays` 。
|
||||
|
||||
> 其实我有预感，在之后的版本这部分逻辑还会出现变化，但是可能 3.0 和 3.3 的发布一样，并不会将这种变更放在 release note 里。
|
||||
|
||||
最后，这里额外介绍一个关于地图的小知识点，**现在国内三大地图 SDK 厂商都有商用 5 万起步的授权费用要求**，如果你打算用在公司的项目里，那么这个是逃不掉的，因为迟早平台会打电话联系你缴费，所以在评估时最好将这个费用问题和产品沟通下。
|
||||
|
||||
| 高德 | 百度 | 腾讯 |
|
||||
| ----------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------ |
|
||||
|  |  |  |
|
||||
|  |  |  |
|
||||
|
||||
当然，华为的地图服务目前看起来没有商业授权的要求，但是它打包配置麻烦，特别是需要 HMS 的场景，所以如果为了省点钱又不怕麻烦，也可以考虑华为地图。
|
||||
|
||||
|
||||
|
||||
那有人就要说了，我自己做一个行不行？我比较牛，有数据有能力自己做个简易版地图不就免费了？答案时不行，如下所示，应用平台会有关于地图相关的资质要求，如果没有你做出来了也上不去。
|
||||
|
||||
> **审核意见：我们发现您的应用内含有互联网地图服务相关内容，依据《关于加强互联网地图管理工作的通知》互联网地图服务单位应当依法取得相应的互联网地图服务测绘资质，并在资质许可的范围内提供互联网地图服务。 修改建议：请补充提供《测绘资质证书》并在专业范围中注明互联网地图服务；若接入第三方开放平台地图服务的，可提供双方合作协议（授权证明），同时需在地图显著位置补充标明合作单位。**
|
||||
|
||||
好了，本篇就到这里结束了，可能相对而言会比之前的内容更“技术性”一些，但是本质还是希望可以帮助大家搞清楚 `PlatformView` 在选型上的区别，最后，如果你还有什么关于 Flutter 工程或者框架的疑问，欢迎留言评论，
|
||||
|
||||
Loading…
Reference in New Issue