From 1bd4cca5276668b7cf8bab36ce97b6cd2c19feae Mon Sep 17 00:00:00 2001 From: guoshuyu <359369982@qq.com> Date: Wed, 4 Jan 2023 09:38:40 +0800 Subject: [PATCH] update --- FWREADME.md | 6 + GCH.md | 12 ++ N15.md | 112 +++++++++++++++ README.md | 13 ++ SQS.md | 316 ++++++++++++++++++++++++++++++++++++++++ SUMMARY.md | 92 +++++++++++- Z1.md | 249 ++++++++++++++++++++++++++++++++ Z10.md | 266 ++++++++++++++++++++++++++++++++++ Z2.md | 332 ++++++++++++++++++++++++++++++++++++++++++ Z3.md | 233 ++++++++++++++++++++++++++++++ Z5.md | 408 ++++++++++++++++++++++++++++++++++++++++++++++++++++ Z6.md | 164 +++++++++++++++++++++ 12 files changed, 2198 insertions(+), 5 deletions(-) create mode 100644 GCH.md create mode 100644 N15.md create mode 100644 SQS.md create mode 100644 Z1.md create mode 100644 Z10.md create mode 100644 Z2.md create mode 100644 Z3.md create mode 100644 Z5.md create mode 100644 Z6.md diff --git a/FWREADME.md b/FWREADME.md index 9ca6c2b..f4b7771 100644 --- a/FWREADME.md +++ b/FWREADME.md @@ -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) + + + + diff --git a/GCH.md b/GCH.md new file mode 100644 index 0000000..93a680b --- /dev/null +++ b/GCH.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) \ No newline at end of file diff --git a/N15.md b/N15.md new file mode 100644 index 0000000..a81c80f --- /dev/null +++ b/N15.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` 时的参数搭配来参与到事件竞技场里。 + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image1.png) + +举个例子，当你使用了 `GestureDetector` 并配置了 `onTap` 、`onLongPress` 和 `onDoubleTap` ，它们是如何分别响应手势事件的？ + +**这里的核心逻辑就在于 deadline (时间) 的处理，不管是 `onLongPress` 还是 `onDoubleTap` 都是靠 deadline 来判断胜负**。 + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image2.png) + +例如，当用户只是普通点击时，如下代码所示，因为默认 `LongPressGestureRecognizer` 的 deadline 是 500 毫秒，所以**在定时器达到 500ms 响应之前，就会因为 `PointerUpEvent` 导致长按定时器停止，无法触发响应长按事件**。 + +反之如果没有 `PointerUpEvent` 产生，那么 500 ms 之后 `LongPressGestureRecognizer` 就会响应，直接宣布胜利(accepted)。 + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image3.png) + +> 默认情况下 `GestureDetector` 是不支持修改 deadline ，只有直接使用 `LongPressGestureRecognizer` 时才可以修改 deadline 的时长。 + +类似的逻辑在 `DoubleTapGestureRecognizer` 下也有，DoubleTap 的 deadline 是 300 毫秒，当用户首次点击时会注册一个定时器，**如果 300 毫秒以内用户没有产生新的点击，那么 `DoubleTapGestureRecognizer` 就会宣布“失败“退出竞技**，反之如果在 300 毫秒内有新的点击，则直接宣布“获胜”，响应 DoubleTap 回调。 + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image4.png) + +那这时候有人就要问了：“*在 `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` 下，它们的响应逻辑会是怎么样的？ + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image5.png) + +当区域内有两个 `GestureDetector` 的时候，用户在普通点击时，因为 deadline 影响，依旧会是在竞技场 `close` 时才响应 `onTap` ， **但是不同在于此时竞技场里还会有多个 `Recognizer` 存在，这时候只有排在列表的第一个的 `Recognizer` 可以赢得事件**，也就是上门代码里的红色 200x200 小方块。 + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image6.png) + +因为对于多个 `GestureDetector` 的情况， `Recognizer` 在竞技场列表(`List 同时对于单个 `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` 事件。 + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image7.png) + +那么问题又来了，既然长按会触发 `onTapDown` 事件，如果点击区域内有两个 `TapGestureRecognizer` ，长按的时候因为定时器都触发了 `didExceedDeadline` ，那是不是两个都会收到 `onTapDown` 事件 ？ + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image8.png) + +答案是：会的！**因为定时器都触发了 `didExceedDeadline`，从而都发出了 `onTapDown` 事件，所以两个 `onTapDown` 回调都会执行，但是后续竞争只会有一个控件能响应 `onLongPress` 。** + +> 另外，如果不是长按导致的 Down 事件， 是不会导致两个 `GestureDetector` 都触发回调 `onTapDown` 回调。 + +第二个补充的是 `Listener` ， 如果你还想深入去看 `GestureDetector` 的实现，你就会发现 `GestureDetector` 对 `Listener` 的封装也许和你想象不大一样， **因为 `Listener` 的封装只用到了 `PointerDown` ，并没有用到 `onPointerUp`** ，那 `GestureDetector` 是怎么响应 Up 和 Move 事件？ + +![](http://img.cdn.guoshuyu.cn/20221215_N15/image9.png) + +这就需要说到前面介绍 [《面深入触摸和滑动原理》](https://juejin.cn/post/6844903841742192648) 里的源码分析，但是为了简单，我们这里只说结论： + +> 因为只有响应了 `PointerDown` 事件，对应的 `GestureRecognizer` 才能被添加到 `GestureBinding` 的 `PointerRouter` 事件路由和 `GestureArenaManager` 事件竞技中，而**后续的 Up 和 Move 事件主要是通过 `GestureBinding` 来处理**。 + +更简单的说，**就是只有响应了 `PointerDown` 事件，控件的 `Recognizer` 才能响应后续统一处理的其他手势事件，而其他事件不需要在 `Listener` 这里获取回调**。 + + + +# 结束 + +那本篇的小技巧到这里就结束了，本篇主要是用更直观和简单的方式，帮助大家理解 Flutter 里的触摸响应逻辑，如果对更详细实现感兴趣，可以结合 [《面深入触摸和滑动原理》](https://juejin.cn/post/6844903841742192648) 帮助理解，如果你还有什么感兴趣或者有疑惑的，欢迎留言评论～ + diff --git a/README.md b/README.md index 518d6b9..0f9e67e 100644 --- a/README.md +++ b/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) + + diff --git a/SQS.md b/SQS.md new file mode 100644 index 0000000..f81405c --- /dev/null +++ b/SQS.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 纪元里的超新星**。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image1.png) + + + +**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 都还处于徘徊观望状态**。 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image2.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image3.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + +另外也可以看到 ， Flutter 出来比较久，所以如今他的热度会比较高，当然这也是现在跨平台的需求剧增有关系，很多平台开发人员不再仅仅 ”安居” 于自己的平台，**并且从国内的数据可以看到，国内对于跨平台的热情其实一直很高**。 + +> 虽然 Flutter 从发布以来一直争议不断，但是这些年下来 Flutter 也证明了自己的价值，后面我们会有单独的详细的数据分析。 + +再看 StackOverFlow 的数据，可以看到 Flutter 和 Compose 都在稳步上升，这里面 Compose 相关看起来比较少的原因，和它发布时间还较短有关系，而 Flutter 从目前的占有比例上看其实不算低了。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image4.png) + +既然说 Flutter 和 Compose 就不得不说 Dart 和 Kotlin ，同样是 StackOverFlow 的数据，可以看到虽然他们发布都有一段时间了，但是其实是在 2017 年开始它们的占有率才出现了爆发式的上升，这是为什么呢？ + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image5.png) + +其实这个现象和 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**。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image6.png) + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image7.png) + + + +再看国外调研的一份关于 Flutter 和 Compose 在 Droidcon 上有多少次关于这两个项目的演讲主题和结果，虽然数据相对较小和局限，但是可以看到 Flutter 自发布以来每年都在稳定的主题，而 Compose 在稳定版发布后有明显爆发式增长 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image8.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image9.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + + + +最后，恰好 GitHub 也发布了 2022年度报告，其中一些数据还是值得我们关注，例如在开发语言增长上， Kotlin 排进了前十，另外移动端开发依旧是开源主流之一，其中 Kotlin、Dart 、Flutter 、Android 都是主要的对象。 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image10.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image11.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + +当然，就像前面说的，**不管是 Dart 还是 Kotlin ，它们主要是场景还是在于 Flutter 和 Android ，通过 [TIOBE](https://www.tiobe.com/tiobe-index/) 在 2022 年 11 月的编程语言指数上可以看到， Dart 和 Kotlin 还是未能进入 TIOBE 指数前 20 名**，该指数每月更新一次，在编程语言的流行程度上有比较高的参考价值。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image12.png) + +不是说其他领域不能用，比如 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 位，从应用领域看，这两种语言目前的势头还是不错的。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image13.png) + + + +> 所以总结来说： **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 是一些的基础核心**。 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image14.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image15.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + +*那么大家肯定很关心一个问题，有哪些大厂 App 在使用 Compose* ？ + +目前关于 Flutter 的技术文章我们可能看到过很多大厂的分享，但是 Compose 相关的比例却不多，所以我也只能从我自己手机里一些常用软件的归类，目前恰好可以找到如下图所示的 6 款 App 里有存在 Compose 的痕迹。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image16.png) + + + +> **当然，使用 Jetpack Compose 和使用 compose-jb 其实是两码事**，所以我也不知道上述产品是否也有使用 compose-jb 的场景，因为其实 compose-jb 目前在跨平台开发上的体验还是有些差别的。 + +**而作为全新的独立 UI 框架， Compose 自然不会像以前一样的控件体系**，类似的声明式布局方式对于 Android 开发者来说可能会有一定的学习成本，最直观的就是 Compose 里会使用状态管理和绑定，而不会是像以前一样拿 `view.xxxx` 这样的操作方法，这是一个思路转变的过程。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image17.png) + +另外从反编译后的代码里可以看到，**Compose 里的控件和原生控件并不是一个体系**，大家如果去看编译后的内容，就会发现例如 `BOX` 这样的控件在编译后是通过 `ComposerKt` 和 `BoxKt` 等的 framework 实现来完成的布局与绘制。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image18.png) + +所以 **Compose 编译后不是转化为原生的 Android 上的 View 去显示**，而是依赖于平台的 `Canvas` ，在这点上和 Flutter 有点相似，简单地说可以理解为 Compose 是全新的一套 View 。 + +> 另外友情提示：虽然是全新的 View ，但是 `Compose` 的组件在 Android 上是可以显示了布局边界。 + +**另外 Compose 里的代码基本都是可以被混淆的**，所以开启混淆之后代码的压缩率也很高。 + +在 Compose 里两棵树的设计，虚拟 Dom 风格的 SlotTable 和 React 设计类似，从而保证了 LayoutNode 的性能，Compose 的核心设计开发人员 Jim Sproch 之前是 React 的核心开发。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image19.png) + +> **其实这也是一种大前端的趋势，不管你是客户端还是前端开发，你的能力都应该可以得到应用。** + +再说 compose-jb ，如下图所示， compose-jb 在跨平台开发体验上还是有所区别，**Compose 目前是通过多个模块实现来支持多平台，所以目前 Jetpack Compose 和 compose-jb 有一些“割裂”**， compose-jb 本质上是将 compose-desktop，compose-web 以及 compose-android 进行了整合，特别是在 Web 端，想要达到 Flutter 一样共享代码的比例还需要继续努力。 + +![](http://img.cdn.guoshuyu.cn/20221027_M1/image7.png) + + + +如上图所示的 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 并不遥远。 + +![](http://img.cdn.guoshuyu.cn/20221027_M1/image8.png) + + + +另外 **Jetpack Compose 现在针对 Compose 体系的官方依赖支持，也推出了 Gradle BOM (Bill of Materials) 依赖模式**，用于指定每个 Compose 库的稳定版本。 + +> 目前第一个版本是 Compose 2022 年 10 月版，现在最新的应该是 2022.11.00。 + +那么 Gradle BOM 的作用是什么？如下图所示，**简单说就是不用再单独写依赖版本， 我们可以通过仅指定 BOM 的版本管理所有 Compose 库版本**，BOM 本身具有指向不同 Compose 库的稳定版本的链接，所以它们可以很好地协同工作。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image20.png) + +*当然，聊到这个就顺便聊一聊制约 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 允许在预览时进行交互，就像是已经运行到设备上工作一样。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image21.gif) + +> 这里的 Preview interactive 模式直接在 Android Studio 中运行，无需运行模拟器，这会导致一些限制：没有网络访问权限、没有文件访问权限、某些上下文 API 可能不完全可用。 + +值得一提的是， **Compose 目前不支持 hotload**，Android Studio 的 apply code 的实用程度相信大家深有体会，不过 Compose 有支持 preview 时的文本 Live Edit of literals ，这也算是一个可将一下的工具。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image22.gif) + + + +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 或更高版本。 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image23.gif) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image24.gif) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + + + +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 何时进行或不进行重构 + +| ![](http://img.cdn.guoshuyu.cn/20220916_AS/image1.gif) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image25.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + +最后，如果你好奇现在哪些大厂在使用 compose-jb ，目前我还没找到比较有价值的数据，不过据称 JetBrains 目前就已经将 Toolbox 应用通过 compose-jb 实现并且发布使用。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image26.png) + + + + + +# 三、 Flutter 对于 Android 开发来说是什么 + +接下来我们聊聊 Flutter 对于 Android 开发者来说又是什么？**你如果选择还是只做 Android ，那么 Flutter 对你来说可能意义不大**，Flutter 其实起源于 Chrome 内部团队，所示它其实和 Android 没什么关系，**但是如果你对其他平台感兴趣，那么 Flutter 绝对是你不错的选择**。 + +Flutter 正式版是在 2018 年发布，发布之后几乎就是每个季度都会更新一个大版本，如下图所示可以看到 Flutter 的推进和迭代速度是很快的，这也侧面反映了 Flutter 社区的活力。 + + + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image27.png) + + + +**如果大版还不够有说服力，那么近期的小版本迭代速度，这也可以体现 Flutter 社区的生命力，当然也侧面反映出全平台支持的困难，需要解决的问题很多**，因为跨平台需要兼容处理的问题会更多，这也是 Flutter 坑多的原因。 + +![](http://img.cdn.guoshuyu.cn/20221124_SQS/image28.png) + + + +我们再从 Github 发布的 2022 年度报告上看，在各项开源数据里 Flutter 都名列前矛： + +- 顶级开源项目里按贡献者排序 Flutter 排第三 +- 顶级开源项目里按首次贡献者统计的，Flutter 在获取贡献“一血”里排名第四 +- 在每个项目的贡献者数量里 Flutter 排名第二 +- 在外部贡献者百分比里 Flutter 排名第三 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image29.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image30.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image31.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image32.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | + +> **由此可以看到 Flutter 强大的生命力，特别是来自社区的活跃，Flutter 每个版本发布都会合并大量来着社区的 PR ，这也是 Flutter 这些年来快速发展的原因**，同时也是在本次 Github 发布的报告里，随处可以见 Flutter 的原因。 + +*那么说一千道一万，目前有哪些我们熟知的企业在使用 Flutter 呢*？ + +如下图所示是目前我手机里有 Flutter 存在的 App ，另外还有过去三年里 Flutter 在跨平台领域的占有率增长，**可以看到 Flutter 目前在跨平台领域的存在感并不低，其实介绍这么多数据，只是为了和大家说明一个问题：Flutter 已经不算小众了**。 + +> 百度网盘、转转、阿里云盘、闲鱼、微信、掘金、企业微信、微博、B站漫画、阿里云、 UC浏览器、优酷视频、钉钉、360摄像头、网易邮箱、天猫精灵、链家、美团众包、凤凰新闻、腾讯课堂、喜马拉雅、携程旅行、贝壳找房、WPS、学习强国、唯品会、同花顺 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image33.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image34.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + +回到 Flutter 本身上，**Flutter 的优势体现在于 single codebase ，它是真的做道一套代码编译成不同平台的 native 代码运行**，Flutter 跨平台最特殊在于它不依赖平台控件，控件最后都是利用 Skia 通过平台 GPU 渲染出来。 + +![](http://img.cdn.guoshuyu.cn/20221027_M1/image9.png) + +**所以 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 的代码对比： + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image35.png) | ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image36.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + +**所以这也是 Andorid 开发会了 Flutter 就离 Compose 不远的原因，反过来也是**。 + +这里可以顺便推荐下大佬的 Flutter 和 Compose 入门项目 [FlutterUnit](https://github.com/toly1994328/FlutterUnit) 和 [ComposeUnit](https://github.com/toly1994328/ComposeUnit) ，上面的代码就是来自这两个项目，里面列举了很多案例，特别适合入门的小伙伴。 + +| ![](http://img.cdn.guoshuyu.cn/20221124_SQS/image37.png) | ![image-20221115171152896](http://img.cdn.guoshuyu.cn/20221124_SQS/image38.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + + + +# 最后 + +本次分享的核心还行想告诉大家，目前 Compose 和 Flutter 成熟度已经不错了，当你的领导和你说，Kotlin、Dart 还不够普及，Flutter 和 Compose 还太小众的时候，或者你就可有一些数据依据。 + +最后可以总结的是： + +- Compose 的核心还是 Android 的 UI 库，做 Android 的必须掌握这个未来的能力，至于 compose-jb 的跨平台增值能力，还有一段路要走。 +- Flutter 的核心是全平台更稳定的支持，更有社区活力，特别是在相对“冷清”的桌面端上的优势，在目前公开信息上，钉钉、字节和企业微信都在 Flutter 桌面端开始有投入。 + +**所以结合自己的路线，选哪个应该就很清楚了，而不管选择哪一个，都会对另外一个框架有提前铺垫的作用，所以也不用担心得此失彼，感兴趣的小伙伴可以开始动起来了**～ diff --git a/SUMMARY.md b/SUMMARY.md index 10324b1..c21516c 100644 --- a/SUMMARY.md +++ b/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) + + + +​ + + + + + + + + + diff --git a/Z1.md b/Z1.md new file mode 100644 index 0000000..82065a4 --- /dev/null +++ b/Z1.md @@ -0,0 +1,249 @@ +# Flutter 工程化框架选择——搞定 Flutter 动画 + +> 本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！ + +首先，这次会写一个新的系列《Flutter 工程化框架选择》，但是系列其实并非前端的工程治理方面的内容，**这个系列只是单纯告诉你，创建一个 Flutter 工程，或者说搭建一个 Flutter 工程脚手架，应该如何选择快速适合自己的插件模块，或者说这是一个指引系列，相信会适合新手同学**。 + +> **为什么会想要写一个这样的系列？因为这类的问题太多了**，简单检索一个群的聊天记录，单单 `有没有` 这个关键字就可以搜索翻好几页，所以这个系列的目的，是帮大家整理 Flutter 工程里可能会需要的各种第三方模块，并对比一些技术细节，**也是方便以后回答问题我可以直接甩链接**。 + +![](http://img.cdn.guoshuyu.cn/20220920_Z1/image1.png) + +首先作为系列第一篇文章，本篇我们先聊动画。 + +为什么第一篇聊它，因为近期刚好做了一些关于 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 + with TickerProviderStateMixin { + late final AnimationController _controller = AnimationController( + duration: const Duration(seconds: 2), + vsync: this, + )..repeat(reverse: true); + late final Animation _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 过渡 效果。 + +![](http://img.cdn.guoshuyu.cn/20220920_Z1/image2.gif) + +另外也可以使用 `PageTransitionSwitcher` 实现一些非路由的页面切换动画，可以理解为是一个变异版本的 `AnimatedSwitcher` ，或者是 `Stack` 版动画 `PageView` ，不过支持自定义进入和退出动画，还可以支持自定义布局，一般默认使用默认 `defaultLayoutBuilder` 的话，就是使用 `Stack` 作为布局。 + +![](http://img.cdn.guoshuyu.cn/20220920_Z1/image3.gif) + +官方 Demo 里也会使用 `PageTransitionSwitcher` 来做步进页面跳转的效果，**所以 [animations](https://github.com/flutter/packages/tree/main/packages/animations) 的核心动画能力主要是在于页面过渡方面**。 + +![](http://img.cdn.guoshuyu.cn/20220920_Z1/image4.gif) + + + +> 总的来说，这个库是官方维护，值得信赖。 + +## simple_animations + +[simple_animations](https://github.com/felixblaschke/simple_animations) 如同它的名字所示，它主要是简化了自定义动画的过程，正如前面所示，在 Flutter 里使用动画，我们一般需要定义 `AnimationController` 、`Animatable` 和 `Animation` 等对象来配置动画效果。 + +而 simple_animations 提供了 `AnimationMixin` 对象，如下代码所示，你只需要通过 `with` 关键字就可以简化接入动画的代码。 + +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image5.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image6.png) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image7.gif) | +| ------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------- | + +同时 simple_animations 也提供了各种 Builder 来简化，例如使用 `MirrorAnimationBuilder` 就可以实现一个循环反复的动画效果。 + +![](http://img.cdn.guoshuyu.cn/20220920_Z1/image8.png) + +**所以 simple_animations 针对显式动画进行了优化封装，在更方便的情况下做到能更灵活控制动画效果**，如下图所示，在 [gsy_fluter_demo](https://github.com/CarGuo/gsy_flutter_demo/tree/master/lib/widget/particle) 里就利用了 simple_animations 来实现一些动画效果： + +- `MirrorAnimation` 和 `MovieTween ` 实现渐变的背景 +- `LoopAnimation` 和 `MovieTween` 实现了粒子动画 + +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image9.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image10.gif) | +| ---------------------------------------- | ------------------------------------------ | + +> 不过这个库有个小问题，就是它最近几次大版本，每个版本总是会有一些 break change ，但是可能就是改改名字，换换参数位置，如果你一段时间没关注，再升级可能会有些成本。 + +## animate_do + +**[animate_do](https://github.com/Klerith/animate_do_package) 是一个轻量级动画包，它比 simple_animations “更懒”，代码也相对简单很多，内部提供了丰富的动画封装 Widget 可直接使用**。 + +> 你可以理解为更丰富的隐式动画。 + +animate_do 就是通过 `AnimatedBuilder ` 配合 `Transform` 、`Opacity` 进行了封装，然后开发者可以通过 `FlipInX` 、`FadeInDown` 、`ElasticIn` 等对象直接实现动画效果。 + +![](http://img.cdn.guoshuyu.cn/20220920_Z1/image11.png) + +既然 animate_do 十分简单，那为什么会推荐它呢？因为它真的很实用。 + +**首先简单代表着好维护，作者不玩了我们自己也能接**，其次 animate_do 提供了相当丰富的封装，这对于懒人来说它真的很实用，特别是对于一些 “相对复杂” 的动画效果上（如下图3）可以节省很多时间，特别是在 `Tween` 和 `CurvedAnimation`的封装上。 + +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image12.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image13.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image14.gif) | +| --------------------------------------- | ----------------------------------------- | --------------------------------------- | + +> 目前有一段时候没更新，但是问题不大～ 同类型的库还有 [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) 等，具体可以自己按需选择。 + +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image15.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image16.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image17.gif) | +| ------------------------------------------- | ------------------------------------------- | ----------------------------------------- | + +## 跑马灯 + +既然聊到文字动画，就不得不说跑马灯，如下表格所示是 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) | +| ----------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image18.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image19.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image20.gif) | + +## 加载动画 + +加载动画是最常见的 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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image21.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image22.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image23.gif) | + +> 纯代码实现有什么好处？当样式需要做一些简单调整时，作为开发者可以通过代码快速修改，这是我喜欢纯代码实现动画的原因。 + + + +## 指引动画 + +指引动画也是常见的需求之一，基本实现都会通过 `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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------- | ---------------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image24.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image25.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image26.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image27.gif) | + + + +## 列表动画 + +列表动画也是常见的 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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image28.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image29.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image30.gif) | + +## 3D 立体动画 + +这个类目可能关注的人反而不是很多，但是恰好是我近期比较关注的动画实现，这里主要推荐两个利用矩阵变换绘制 3D 视觉效果的第三方库，它们不同在于： + +- zwidget 能力相对比较弱，直接使用的是 `Transform` 的能力 +- zflutter 来源于前端 zdog 项目，是直接对 `Canvas` 的 `path` 进行矩阵变换 + +| [zflutter](https://github.com/jamesblasco/zflutter) | [zwidget](https://github.com/apalala-dev/zwidget) | +| --------------------------------------------------- | ------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220806_N11/image30.gif) | ![](http://img.cdn.guoshuyu.cn/20220920_Z1/image31.gif) | + +在不久前我也写过一篇文章 [《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 上的动画效果。 + +![](http://img.cdn.guoshuyu.cn/20220920_Z1/image32.gif) + +**使用 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 官方推荐的动画框架。 + +| ![](http://img.cdn.guoshuyu.cn/20220731_N10/image3.gif) | ![](http://img.cdn.guoshuyu.cn/20220731_N10/image4.png) | +| ------------------------------------------------------- | ------------------------------------------------------- | + +**[rive](https://link.juejin.cn/?target=https%3A%2F%2Frive.app)** 同样是一个面向设计师的动画框架，只不过他是在 **Web Editor** 里进行 UI 编排和动画绘制，所以他在开发环境上相对会轻量化。 + +| ![](http://img.cdn.guoshuyu.cn/20220731_N10/image18.gif) | ![img](http://img.cdn.guoshuyu.cn/20220731_N10/image9.gif) | ![img](http://img.cdn.guoshuyu.cn/20220731_N10/image10.gif) | +| ------------------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------- | + +同时 rive 同样是通过导出矢量的动画数据文件（也可以包含一些静态资源），然后利用平台的 `Canvas` 来实现动画效果，所以它的占用提及也不会很大。 + +另外 rive 现在也是全平台支持， **Android、 iOS、Web、Desktop、Flutter 、React、Vue、C++** 等都在支持范围之内。 + +> 如果想深入了解 rive ，也可以看我之前的 [《给掘金 Logo 快速添加动画效果》](https://juejin.cn/post/7126661045564735519) ，其实对于程序员来说，rive 同时很好上手。 + +![](http://img.cdn.guoshuyu.cn/20220731_N10/image1.gif) + +> 目前 rive 的问题是，第二代 rive 和第一代 flare 存在断档不兼容，而且基本可以忽略迁移的可能，同时没有本地化免费开发 IDE 有时候也是一种麻烦。 + +好了，关于 Flutter 动画相关的内容推荐就到这里，如果你还有什么关于 Flutter 工程或者框架的疑问，欢迎留言评论，也许又可以多一期的素材～ + diff --git a/Z10.md b/Z10.md new file mode 100644 index 0000000..ac9acc5 --- /dev/null +++ b/Z10.md @@ -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)这种“鬼畜”需求，**所以既然大家都有这样的需要，那就来聊聊这类工程下有哪些选择**。 + +| ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image1.png) | ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image2.png) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | + +# 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挡住**； + + + +![](http://img.cdn.guoshuyu.cn/20221101_Z10/image3.png) + + + +所以通过这部分内容可以看出来，**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 混合模式下保持极低的内存占用**。 + +| ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image4.gif) | ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image5.png) | +| ------------------------------------------- | ------------------------------------------------------------ | + +之所以 `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` 共享数据 + +| ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image6.png) | +| ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image7.png) | +| ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image8.png) | + +接入 `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 内存共享的方式** 。 + +![](http://img.cdn.guoshuyu.cn/20221101_Z10/image9.png) + +这种实现方式的好处很明显：**那就是 Dart 层面数据状态支持共享**，因为只有一个 Engine ，但是问题也很明显，如下图是 flutter_boost 在 2.0 时的渲染流程，维护一个 Engine 渲染多个 Surface 这种非官方实让 flutter_boost 在很长一段时间没能快速推进项目。 + +![](http://img.cdn.guoshuyu.cn/20221101_Z10/image10.png) + +不过 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) + +![](http://img.cdn.guoshuyu.cn/20221101_Z10/image11.gif) + +可以看到在 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 容器页面。 + +![](http://img.cdn.guoshuyu.cn/20221101_Z10/image12.png) + +flutter_thrio 的内部实现的多 Engine 模式和 `FlutterEngineGroup` 那套基本一样，不过它是通过反射拿到 `FlutterEngine` 里的 `flutterJNI` ，然后通过 `spawn` 构建新的 `FlutterEngine` 。 + +> PS，目前 flutter_thrio 里的 `isMultiEngineEnabled `标识位感觉有些具备迷惑性，其实它更多是控制 `entrypoint` ，通过 `entrypoint` 来决定是否启动新的 `FlutterEngine` 容器。 + +![](http://img.cdn.guoshuyu.cn/20221101_Z10/image13.png) + + + +另外 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 来实现路由混合。 + +![](http://img.cdn.guoshuyu.cn/20221101_Z10/image14.png) + +在 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` 。 + +| ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image15.png) | ![](http://img.cdn.guoshuyu.cn/20221101_Z10/image16.gif) | +| ------------------------------------------------------------ | ------------------------------------------- | + +如上图右侧动态，在页面内通过 `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 运行的情况下内存占用问题也还可以。![](http://img.cdn.guoshuyu.cn/20221101_Z10/image17.png) + +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 并不重要，重要的是它提供的思路是否有用，这才是我认为的开源里最大的价值。 + + + diff --git a/Z2.md b/Z2.md new file mode 100644 index 0000000..f4f3b2e --- /dev/null +++ b/Z2.md @@ -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` 等各类框架“百花齐放”，**虽然这对于社区来说是这是好事，但是对于普通开发者来说很容易造成过度选择困难症**，特别早期不少人被各种框架“伤害过”。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image1.png) + + + +其次，状体管理在 Flutter 里一直是一个“敏感”话题，每次聊到状态管理就绕不开 `GetX` ，但是一旦聊 `GetX` 又会变成“立场”问题，所以一直以来我都不是很喜欢写状态管理的内容。 + +| ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image2.png)![image-20221109095950845](http://img.cdn.guoshuyu.cn/20221109_Z2/image3.png) | ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image4.png) | +| ------------------------------------------------------------ | ----------------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image5.png) | ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image6.png) | + +所以本来应该在第一篇就出现的内容，一直被拖到现在才放出来，这里提前声明一些，本篇不会像之前一样从大小和性能等方面去做对比，因为对于状态管理框架来说这没什么意义： + +- **集成后对大小的影响可能还不如一张图片** +- **性能主要取决于开发者的习惯，在状态管理框架上对比性能其实很主观** + +当然，如果你对集成后对大小的影响真的很在意，那可以在打包时通过 `--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` 就可以进行分析。 + +| ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image7.png) | ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image8.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +例如这里是将 `Riverpod` 和 `GetX` 在同一项项目集成后导出不同 json 在 Diff 进行对比，可以看到此时差异也就在 78.5kb ，这个差异大小还不如一张 png 资源图片的影响大。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image9.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 里，有更新就通知。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image10.png) + +但是 `select` 做了二次处理，就是用 `dependOnInheritedElement` 做了颗粒化的判断，如果是不等于了才更新，所以它对 context 有要求，如下图对就是对 context 类型进行了判断。 + +| ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image11.png) | ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image12.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +所以 `select` 算是 Provider 里的“小魔法“之一，总的来说 **Provider 是一个符合 Flutter 的行为习惯，但是不大符合前端和原生的开发习惯的优秀状态管理框架**。 + +**优点：** + +- 简单好维护 +- read、watch、select 提供更简洁的颗粒度管理 +- 官方推荐 + +**缺点：** + +- 相对依赖 Flutter 和 Widget +- 需要依赖 Context + +最后顺带辟个谣，之前有 “传闻” Provider 要被弃坑的说法，作者针对这个也有相应对澄清，所以你还是可以继续安心使用 Provider。 + +| ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image13.png) | ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image14.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + + + + + +# Riverpod + +[Riverpod](https://github.com/rrousselGit/riverpod) 和 Provider 是同个作者，**因为 Provider 存在某些局限性，所以作者根据 Provider 这个单词重新排列组合成 Riverpod**。 + + + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image15.png) + +如果说 Provider 是 `InheritedWidget` 的封装，那 Riverpod 就是在 Provider 的基础上重构出更灵活的操作能力，最直观的就是 **Riverpod 中的 Provider 可以随意写成全局，并且不依赖 `BuildContext` 来编写我们需要的业务逻**。 + +> 注意： Riverpod 中的 Provider 和前面的 [Provider](hhttps://github.com/rrousselGit/provider) 没有关系。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image16.png) + +在 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` 这样的依赖关系，**它是基于事件驱动来实现的状态管理**。 + + + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image17.png) + + + +**`flutter_bloc` 基于事件驱动的核心就是 `Stream` 和 Provider** ， 是的， `flutter_bloc` 依赖于 Provider，然后在其基础上设计了基于 `Stream` 的事件响应机制。 + +所以严格意义上 BLoC 其实是 Provider + `Stream` ，如果你一直很习惯基于事件流开发模式，那么 BLoC 就很适合你，**但是其实从我个人体验上看，BLoC 在开发节奏上并不是快，相反还有点麻烦**，不过优势也很明显，基于 `Stream` 的封装可以更方便做一些事件状态的监听和转换。 + +```dart +BlocSelector( + selector: (state) { + // return selected state based on the provided state. + }, + builder: (context, state) { + // return widget here based on the selected state. + }, +) + +MultiBlocListener( + listeners: [ + BlocListener( + listener: (context, state) {}, + ), + BlocListener( + listener: (context, state) {}, + ), + BlocListener( + 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 时使用的状态管理框架就是它。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image18.png) + +> 其实前端开始者对 redux 可能会更熟悉一些，当时我恰好用 RN 项目切换到 Flutter 项目，在 RN 时代我就一直在使用 redux，flutter_redux 自然就成了我首选的状态管理框架。 + +其实这也是 Flutter 最有意思的，很多前端的状态管理框架都可以迁移到 Flutter ，例如 flutter_redux 里就是利用了 `Stream`特性，通过 `redux` 单向事件流的设计模式来完成解耦和拓展。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image19.png) + +在 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` 。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image20.png) + +**所以不管是 flutter_redux 还是 fish_redux 都是很适合团队协作的开发框架，但是它的开发体验和开发过程，注定不是很友好**。 + + + +# GetX + +[GetX](https://pub.flutter-io.cn/packages/get) 可以说是 Flutter 界内大名鼎鼎，**Flutter 不能没有 GetX 就像程序员不能没有 PHP ，GetX 很好用，很具备话题，很全面同时也很 GetX**。 + + + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image21.png) + +严格意义上说现在 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 上的解决方案**。 + +| ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image3.png) | ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image6.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +**当然，使用 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` 的绑定和更新 + +| ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image22.png) | ![](http://img.cdn.guoshuyu.cn/20221109_Z2/image23.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +**可以说 GetX 内部有很多“魔法”，这些魔法或者是对 Flutter API 的 Hook、或者是直接脱离 Flutter 设计的自定义实现，总的来说 GetX “有自己的想法”**。 + +这也就带来一个了个问题，很多人新手一上手就是 GetX ，然后对 Flutter 一知半解，特别是深度解绑了 Context 之后，很多 Flutter 问题就变成了 GetX 上如何 xxxx，例如前面的： *Flutter GetX 如何调用谷歌地图这种问题*。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image24.png) + +> 如果使用 GetX 而不去思考和理解 GetX 的实现，就很容易在 Flutter 的路上走歪，比如上面各种很基础的问题。 + +这其实也是 GetX 的最大问题：**GetX 做的很多，它入侵到很多领域，而且它拥有很多“魔法”**，这些“魔法”让 Flutter 开发者不知布局的脱离了本来应有的轨迹。 + + + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image25.png) + +当然，你说我就是想完成需求，好用就行，何必关心它们的实现呢？从这个角度看 GetX 无疑是非常不错的选择，只要 GetX 能继续维护下去并把“魔法”继续兼容。 + +> 大概就是：**GetX “王国” 对初级开发者友好，但是“魔法全家桶”其实对社区的健康发展很致命**。 + +**优点：** + +- 瑞士军刀式护航 +- 对新人友好 +- 可以减少很多代码 + +**缺点：** + +- 全家桶，做的太多对于一些使用者来说是致命缺点，需要解决的 Bug 也多 +- “魔法”使用较多，脱离 Flutter 原本轨迹 +- 入侵性极强 + +总的来说，GetX 很优秀，他帮你都写好了很多东西，省去了开发者还要考虑如何去组合和思考的过程，从我个人的角度我不喜欢这种风格，但是它总归是可以帮助你提高开发效率。 + +**另外还有一个状态管理库 [Mobx](https://github.com/mobxjs/mobx.dart) ，它库采用了和 GetX 类似的风格，虽然 Mobx 的知名度和关注度不像 GetX 那么高，但是它同样采用了隐式依赖的模式，某种意义上可以把 [Mobx](https://github.com/mobxjs/mobx.dart) 看成是只有状态管理版本的 GetX**。 + +![](http://img.cdn.guoshuyu.cn/20221109_Z2/image26.png) + + + +# 最后 + +通过上面分享的内容，相信大家对于选哪个状态管理框架应该有自己的理解了，**还是那句废话，采用什么方案和框架具体还是取决于你的需求场景，不管是哪个框架目前都有坑和局限，重点还是在于它未来是否持续维护，或者不维护了你自己能否继续维护下去**。 + +最后，如果你还有什么疑问，或者针对 Flutter 工程选择上还有哪些茫然，欢迎留言评论。 + + + + + + + + + + + diff --git a/Z3.md b/Z3.md new file mode 100644 index 0000000..5cf11cc --- /dev/null +++ b/Z3.md @@ -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 有没有办法解决嵌套**？ + +![](http://img.cdn.guoshuyu.cn/20220923_Z3/image1.png) + +**首先第一点就是，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` 的对比情况。 + +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image2.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image3.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +所以在使用 Flutter 构建 UI 时，就可以谈及到两个点： + +- `Widget` 是配置文件，它一般很轻，不怕嵌套，真正绘制渲染的是它背后的 `RenderObject` +- 通过各种 UI 配置模版来解决嵌套，特别是抽象出适合自己业务逻辑的 UI 模版 + +举个例子，如下方的第三方开源布局包 [dashboard](https://github.com/Mehmetyaz/dashboard) ，在这种复杂的 UI 布局上难道就靠直接一级一级嵌套 `Column` 和 `Row` 来解决？答案肯定不是！ + +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image4.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image5.png) | +| --------------------------------------------- | ----------------------------------------------------------- | + +[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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![image-20220922120414245](http://img.cdn.guoshuyu.cn/20220923_Z3/image6.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image7.png) | + +你说上面的布局用 `Stack` + `Positioned` 的模式能不能做？肯定是可以，但是在 `RenderObject` 层实现不是更优雅吗？**把脏活累活写在 `RenderObject` ， 通过 `Widget` 提供配置接口，这样就不会一上来就向用户露 “底裤” 不是么**。 + +> 所以，把眼界打开，不要什么都盯着 `Widget` 嵌套，往 `RenderObject` 层面探索，你会发现 Flutter 其实不像表面那么浮躁，再不济来尝试下 `CustomMultiChildLayout` ，它也可以帮助你解决一些复杂布局下的嵌套问题。 + +当然，还有一些项目另辟蹊径，**比如 [niku](https://github.com/SaltyAom/niku) ，这个项目通过 `typedef` 和抽象拓展，利用语法对官方控件进行二次封装**，实现创建了一个 “非正道” 的 UI 配置效果，具体如下图所示，喜不喜欢就看个人爱好了，但是它确实一定程度解决了嵌套可视化的问题。 + +![](http://img.cdn.guoshuyu.cn/20220923_Z3/image8.png) + + + +> 作者是个二次元，但是看地址他应该是泰国哥们 + +当然，我们这一期的关键是提高 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) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image9.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image10.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image11.png) | + +当然，除了 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) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image12.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image13.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image14.png) | + +## 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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image15.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image16.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image17.png) | + +## 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) | +| ---------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image18.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image19.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image20.gif) | + +> [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) | +| ---------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image21.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image22.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image23.GIF) | + + + +## 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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image24.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image25.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image26.gif) | + +## 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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image27.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image28.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image29.gif) | + +## 指引 + +启动指引这个需求，正常情况下一个 `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) | +| ------------------------------------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image30.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image31.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image32.gif) | + +## 角标 + +这个应该无需多言了，基本上 App 都会需要用到，这两个库基本覆盖了 90% 的场景 + +| [flutter_badges](https://github.com/yadaniyil/flutter_badges) | [corner_decoration](https://github.com/kalaganov/corner_decoration) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image33.png) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image34.png) | + + + +## 动画按键 + +这个可能一般情况下大家都不需要这么花里胡哨的效果，但是万一呢？Material 风格上这种交互还是挺多的，不过国内对 Material 确实不是很感冒。 + +| [flutter_animated_button](https://github.com/NikhilVadoliya/FlutterAnimatedButton) | [progress_state_button](https://github.com/slm/progress-state-button) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image35.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image36.gif) | + +## 头像 + +没想到吧？头像为什么还需要库？ + +其实就是下面的这个场景，相信这个场景可能大家都不会陌生，有社交需求的时候，经常会存在这样的 UI ，掘金沸点不也有类似 UI 么？ + +| [avatar_stack](https://github.com/cyrax111/avatar_stack) | [overflow_view](https://github.com/letsar/overflow_view) | | +| -------------------------------------------------------- | -------------------------------------------------------- | ---- | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image37.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image38.gif) | | + + + +## 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) | +| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image39.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image40.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image41.gif) | + + + +## bottom sheet + +这其实更多是一个 Route 相关的动画效果，感觉好像国内也不常用到，但是之前确实有好几次咨询有没有类似的实现。 + +| [we_slide](https://github.com/luciano-work/we_slide) | [sliding_up_panel](https://github.com/akshathjain/sliding_up_panel) | +| ---------------------------------------------------- | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image42.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image43.gif) | + + + +## 时间轴 UI + +这是我在群里被问过好多次的一个需求场景，我也不知道为什么那么多应用会需要用到这样的 UI ？不过这类需求自己从头实现确实会比较费事。 + +| [timeline_tile](https://github.com/JHBitencourt/timeline_tile) | [timelines](https://pub.dev/packages/timelines) | +| ------------------------------------------------------------ | ----------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image44.gif) | ![](http://img.cdn.guoshuyu.cn/20220923_Z3/image45.gif) | + +好了，关于 Flutter UI 相关的内容推荐就到这里，**本篇主要还是提供给大家如何理解 Flutter 的 UI 布局，并且尽可能去解决嵌套，同时提供一些有意思的第三方 package ，进一步提高大家开发 UI 的生产力**。 + +最后，如果你还有什么关于 Flutter 工程或者框架的疑问，欢迎留言评论，也许新的素材又有了～ \ No newline at end of file diff --git a/Z5.md b/Z5.md new file mode 100644 index 0000000..09248f6 --- /dev/null +++ b/Z5.md @@ -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 开发对这个名称会很亲切，官方维护，实现简单，支持全平台，适合对性能要求不高和数据量不大的场景 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image1.png) + +> 不过也是因为 `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 就可以很方便提供本地化数据库查看的能力。 + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image2.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image3.gif) | +| ----------------------------------------------------------- | -------------------------------------- | + + + +# 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` 。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image4.png) + + + +# 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 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 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，并且还会在构建时提供错误警告。 + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image5.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image6.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +这里顺便提一嘴，**在 Flutter 里通过状态管理工具往下传递 `database` 大家应该不陌生吧**， drift 官方同样建议使用 `provider` 或者 `riverpod` 往下传递 `database` 对象，例如： + +```dart +void main() { + runApp( + Provider( + 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) 来预览数据库内容数据。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image7.gif) + + + + + +# Realm + +可能不少人对 [realm](https://github.com/realm/realm-dart) 还并不了解，第一次接触 realm 是在 2016 年开发 React Native 的时候，那时候 realm 几乎就是我首选的数据库，它作为 SQLite 的替代，采用的是 MongoDB 的数据库方案。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image8.png) + +如今 realm 也开始支持 Flutter ，虽然还在 Beta（已经 Beta 挺久了），但是它同样采用了基于 `dart:ffi` 的实现，所以 realm 同样支持脱离 Flutter 纯 Dart 运行，并且支持 Android、iOS 、Linux、MacOS 、Windows 等平台运行。 + +> 关于 MongoDB 和 SQL 的差异对比这里就不说，主要就是关系型数据库与非关系型数据库的区别 + +那 realm 最大的特别之处是什么？**那就是它除了提供本地数据库能力之外，它还提供数据同步和后端存储能力**。 + +简单来说，就是 realm 的数据库支持实时同步，在此之前我设计的 React Native 项目里，就有基于 realm 很快就开发出一套支持数据备份和同步的聊天应用的场景。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image9.png) + +简单介绍一下，就是在 realm 的后台服务上，主要需要通过定义 Schema Table 和 sync 权限，就可以通过 realm SDK 在启动时同步数据，并对数据进行实时同步，而在 realm 上，你可以通过 `Credentials` 和 `User` 来定义角色的读写权限和管理数据。 + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image10.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image11.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +如下图所示，开启 sync 之后，在 iPhone 模拟器上点击添加的任务，在 Android 模拟器上就会实时同步 iPhone 上对数据库的操作更改，并且 realm 的 sync 后台默认就支持集群服务，如果用户量不是特别大的情况下，拿来做聊天或者客服场景还是很可行的。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image12.gif) + + + +> [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 上也可以实时看到对应的数据更新。 + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image13.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image14.png) | +| ------------------------------------------------ | ----------------------------------------------------------- | + +不过还是那句话，目前 realm 还在 beta ，例如： + +- 很多 API 上可以看到文档紧缺 +- 不支持 reload ，sync 模式下一 reload 就crash + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image15.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image16.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +另外，比如我不说，你翻阅文档也很难找到 Flutter 上如何监听和同步查询结果变化，而其实这部分代码其实你只需要通过 `stream` 就可以接入实现。 + +```dart +StreamBuilder>( + stream: MyApp.allTasksRealm.all().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(); + +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 +``` + +> 目前 objectbox 支持 dart 、java、kotlin 、swift 甚至还支持 GO 和 Python + +在使用体验上，ObjectBox 可能会更贴近 NoSQL 的操作习惯， 另外它也可以直接在服务端被使用，从官方提供的基准测试中看，ObjectBox 的整体性能确实很优秀（其中的 Hive 后面介绍）。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image17.png) + +> 对测试感兴趣的可以看 [objectbox-dart-performance](https://github.com/objectbox/objectbox-dart-performance) ，不要问我它是不是真的这么好用，因为我也没在生产项目上使用它。 + +ObjectBox 另外一个特点就是支持离线数据同步：[ObjectBox Sync](https://objectbox.io/sync/) ，和 realm 还有 firebase 类似，这其实已经成为 NoSQL 服务商都会提供的特色之一。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image18.png) + +ObjectBox Sync 离线同步的支持主要在：**当设备离线时数据操作会被保存在本地，当设备连接上网络时，数据会恢复同步**。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image19.png) + +> 抛开 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 进行加密，目前官方提供的基准测试数据上性能表现还不错（虽然数据一大可能就拉胯）。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image20.png) + +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 { + @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 更好。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image21.png) + +当然，在 [#170](https://github.com/hivedb/hive/issues/170#issuecomment-573874355) 里有通过对 `isolate` 提供共享内存的支持来优化 Hive ，但是很明显这条路是走不通的。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image22.png) + +另外目前针对 **Hive 好像没有比较合适的可视化工具，这也许会影响部分人在选型上的考量**，不过 [hivedb](https://docs.hivedb.dev/#/more/vscode-snippets) 在 VSCode 上提供了模版代码片段的支持，也算是具备另外一种“微弱”的优势。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image23.gif) + +> 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 地址进行绑定访问。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image24.gif) + +其实 isar 另外的好处就是完全开源，从构建脚本到逻辑代码都是开源，例如其中通过 [`Cargo.toml` ](https://github.com/isar/isar/blob/main/packages/isar_core_ffi/Cargo.toml) 编排 `isar_core_ffi `，然后在 github action 会在发布时通过 shell 脚本执行如何构建 isar 的动态库等。 + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image25.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image26.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +例如 isar 在 iOS 上最重接入的是 `isar.xcframework` ，在 Android 上是 `isar.so` + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image27.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image28.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +目前集成 isar 库本身并不是很大，例如在 Android 上集成之后，大小只增加了大概 600 多k ，所以作为 Hive 的升级版本，isar 确实值得一试，。 + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image29.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image30.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +> 目前由于 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 + +| ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image31.png) | ![](http://img.cdn.guoshuyu.cn/20220928_Z5/image32.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +这两份数据虽然看起来有矛盾点，但是这其实和测试环境有关系： + +- 左侧的图片时在较为正常设备上的测试，可以视为一般情况 + +- 右侧的数据测试的是在低端设备上的表现，可以视为最坏的情况 + +就像 [#211](https://github.com/isar/isar/discussions/211) 里讨论的，同样的基准测试，作者在它的设备上测试反而 isar 表现更好，讨论的结论上看也是，**除了速度之外，在是否导致 UI 卡顿上 isar 的表现也更好，所以基准测试的覆盖范围也是一种考量**。 + +![](http://img.cdn.guoshuyu.cn/20220928_Z5/image33.png) + + + + + +# 最后 + +最后，本篇介绍了 [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 工程或者框架的疑问，欢迎留言评论，这个系列是否更新就取决于是否还有新的素材～ \ No newline at end of file diff --git a/Z6.md b/Z6.md new file mode 100644 index 0000000..33e9184 --- /dev/null +++ b/Z6.md @@ -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 ，事实上控件并不在渲染位置。 + +![](http://img.cdn.guoshuyu.cn/20221011_Z6/image1.png) + +- **`HybridComposition`** ： 通过 `addView` 直接添加原生平台控件，需要层级覆盖时利用 `FlutterImageView` 承载 Flutter 控件的渲染进行堆叠，原生控件会在渲染位置。 + +![](http://img.cdn.guoshuyu.cn/20221011_Z6/image2.png) + + + +- **`TextureLayer`** ：在渲染位置通过原生的透明 ` PlatformViewWrapper` 做容器，然后通过替换 Canvas 将原生控件的纹理渲染到特定 Surface 上，控件不在渲染位置，但是可以通过父容器做事件拦截。 + +![](http://img.cdn.guoshuyu.cn/20221011_Z6/image3.png) + +> 是不是看完有点懵？不怕后面会有对应的例子解释，不理解也不要紧，这一篇是教你如何选，所以也并不需要真的理解内部是如何实现。 + +但是上面介绍的这三种实现也是有前提条件的，比如： + +- 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 | +| ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image4.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image5.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image6.png) | + +这里就不得不提以前的 issue ，如果你的 WebView 存在触摸或者键盘问题就可以通过下述代码来解决，因为正如前面说过， `HybridComposition` 是通过 `addView` 的方式添加原生控件，所以能尽可能保存控件本身的特性。 + +```dart +if (Platform.isAndroid) WebView.platform = SurfaceAndroidWebView(); +``` + +而后来 webview_flutter 在更新迭代里默认实现里也修改为了 `SurfaceAndroidWebView` ，因为 `HybridComposition` 确实更适合 WebView 的场景，比如 H5 的详情页。 + +| 默认判断 | TextureLayer | HybridComposition | +| ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image7.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image8.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image9.png) | + +上面的例子可能还不够典型，接着我们再看一个典型的例子： 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 | +| ----------------------------------------------------------- | ----------------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image10.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image11.png) | + +这里额外需要注意的是：**由于隐私政策等原因，现在基本地图框架都需要做一定的隐私相关适配**，高德也不例外，所以如果想正常使用 SDK ，就需要注意初始化时的适配问题。 + +![](http://img.cdn.guoshuyu.cn/20221011_Z6/image12.png) + +> 对隐私和权限问题感兴趣可以看 [《2022 年 App 上架审核问题集锦，全面踩坑上线不迷路》](https://juejin.cn/post/7142363251911688222) + +- [华为 Flutter 地图插件](https://pub.dev/packages/huawei_map)选择的则是 `HybridComposition` 的实现方式，注意下图代码里的 `initExpensiveAndroidView ` ，因为**现在使用 `PlatforViewLink` 已经不能作为是否使用 `HybridComposition` 的判定标准**，3.0 开始必须显式配置了 `initExpensiveAndroidView ` 才是 `HybridComposition` 。 + +![](http://img.cdn.guoshuyu.cn/20221011_Z6/image13.png) + + + +| 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` 两种实现选择，这又产生了不同的组合结果。 + +![](http://img.cdn.guoshuyu.cn/20221011_Z6/image14.png) + + + +| 3.0之前 | 3.0 | 3.0之后 | +| ----------------- | ---------------------------------------------- | ------------------------------------------------------------ | +| `VirtualDisplays` | `TextureLayer` （ `SurfaceView` 方案无法工作） | `VirtualDisplays`（SurfaceView）/ `TextureLayer`（TextureView） | + +从下方的 Layout Inspector 可以看到，在 Flutter 3.3 下，**百度地图插件如果使用了 `MapSurfaceView` 就会采用 `VirtualDisplays` ，而如果使用了 `MapTextureView` 就会采用 `TextureLayer` ，这是为什么呢**？ + +| SurfaceView | TextureView | +| ----------------------------------------------------------- | ----------------------------------------------------------- | +| ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image15.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image16.png) | + +前面我们不是说过，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` 的相关实现，这也算是折中的实现**。 + +| ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image17.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image18.png) | +| ----------------------------------------------------------- | ----------------------------------------------------------- | + +> 如果对这部分感兴趣的可以查阅 [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 万起步的授权费用要求**，如果你打算用在公司的项目里，那么这个是逃不掉的，因为迟早平台会打电话联系你缴费，所以在评估时最好将这个费用问题和产品沟通下。 + +| 高德 | 百度 | 腾讯 | +| ----------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------ | +| ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image19.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image20.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image21.png) | +| ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image22.png) | ![](http://img.cdn.guoshuyu.cn/20221011_Z6/image23.png) | ![image-20221009093013634](http://img.cdn.guoshuyu.cn/20221011_Z6/image24.png) | + +当然，华为的地图服务目前看起来没有商业授权的要求，但是它打包配置麻烦，特别是需要 HMS 的场景，所以如果为了省点钱又不怕麻烦，也可以考虑华为地图。 + +![](http://img.cdn.guoshuyu.cn/20221011_Z6/image25.png) + +那有人就要说了，我自己做一个行不行？我比较牛，有数据有能力自己做个简易版地图不就免费了？答案时不行，如下所示，应用平台会有关于地图相关的资质要求，如果没有你做出来了也上不去。 + +> **审核意见：我们发现您的应用内含有互联网地图服务相关内容，依据《关于加强互联网地图管理工作的通知》互联网地图服务单位应当依法取得相应的互联网地图服务测绘资质，并在资质许可的范围内提供互联网地图服务。 ­修改建议：请补充提供《测绘资质证书》并在专业范围中注明互联网地图服务；若接入第三方开放平台地图服务的，可提供双方合作协议（授权证明），同时需在地图显著位置补充标明合作单位。** + +好了，本篇就到这里结束了，可能相对而言会比之前的内容更“技术性”一些，但是本质还是希望可以帮助大家搞清楚 `PlatformView` 在选型上的区别，最后，如果你还有什么关于 Flutter 工程或者框架的疑问，欢迎留言评论， +