2亿用户背后的Flutter最新开源框架；Fish-Redux

Redux 的缺点

• Redux 核心仅仅关心数据管理，不关心具体什么场景来使用它，这是它的优点同时也是它的缺点。

• 在我们实际使用 Redux 中面临两个具体问题

• Redux 的集中和 Component 的分治之间的矛盾。

• Redux 的 Reducer 需要一层层手动组装，带来的繁琐性和易错性。

Fish Redux 的改良

Fish Redux 通过 Redux 做集中化的可观察的数据管理。然不仅于此，对于传统 Redux 在使用层面上的缺点，在面向端侧 flutter 页面纬度开发的场景中，我们通过更好更高的抽象，做了改良。
一个组件需要定义一个数据（Struct）和一个 Reducer。同时组件之间存在着父依赖子的关系。通过这层依赖关系，
我们解决了【集中】和【分治】之间的矛盾，同时对 Reducer 的手动层层 Combine 变成由框架自动完成，大大简化了使用 Redux 的困难。
我们得到了理想的集中的效果和分治的代码。

对社区标准的 follow

• State、Action、Reducer、Store、Middleware 以上概念和社区的 ReduxJS 是完全一致的。我们将原汁原味地保留所有的 Redux 的优势。
• 如果想对 Redux 有更近一步的理解，请参考  https://github.com/reduxjs/redux

Component

组件是对局部的展示和功能的封装。 基于 Redux 的原则，我们对功能细分为修改数据的功能(Reducer)和非修改数据的功能(副作用 Effect)。
于是我们得到了，View、 Effect、Reducer 三部分，称之为组件的三要素，分别负责了组件的展示、非修改数据的行为、修改数据的行为。
这是一种面向当下，也面向未来的拆分。在面向当下的 Redux 看来，是数据管理和其他。在面向未来的 UI-Automation 看来是 UI 表达和其他。
UI 的表达对程序员而言即将进入黑盒时代，研发工程师们会把更多的精力放在非修改数据的行为、修改数据的行为上。
组件是对视图的分治，也是对数据的分治。通过逐层分治，我们将复杂的页面和数据切分为相互独立的小模块。这将利于团队内的协作开发。

关于 View

View 仅仅是一个函数签名: (T,Dispatch,ViewService) => Widget
它主要包含三方面的信息

• 视图是完全由数据驱动。
• 视图产生的事件／回调，通过 Dispatch 发出“意图”，不做具体的实现。
• 需要用到的组件依赖等，通过 ViewService 标准化调用。

比如一个典型的符合 View 签名的函数

关于 Effect

Effect 是对非修改数据行为的标准定义，它是一个函数签名: (Context, Action) => Object
它主要包含四方面的信息

• 接收来自 View 的“意图”，也包括对应的生命周期的回调，然后做出具体的执行。
• 它的处理可能是一个异步函数，数据可能在过程中被修改，所以我们不崇尚持有数据，而通过上下文来获取最新数据。
• 它不修改数据， 如果修要，应该发一个 Action 到 Reducer 里去处理。
• 它的返回值仅限于 bool or Future， 对应支持同步函数和协程的处理流程。

比如：良好的协程的支持

关于 Reducer

Reducer 是一个完全符合 Redux 规范的函数签名:(T,Action) => T
一些符合签名的 Reducer

同时我们以显式配置的方式来完成大组件所依赖的小组件、适配器的注册，这份依赖配置称之为 Dependencies。
所以有这样的公式 Component = View + Effect(可选) + Reducer(可选) + Dependencies(可选)。
一个典型的组装

通过 Component 的抽象，我们得到了完整的分治，多纬度的复用，更好的解耦。

Adapter

Adapter 也是对局部的展示和功能的封装。它为 ListView 高性能场景而生，它是 Component 实现上的一种变化。

• 它的目标是解决 Component 模型在 flutter-ListView 的场景下的 3 个问题

• 1）将一个"Big-Cell"放在 Component 里，无法享受 ListView 代码的性能优化。

• 2）Component 无法区分 appear|disappear 和 init|dispose 。

• 3）Effect 的生命周期和 View 的耦合，在 ListView 的场景下不符合直观的预期。

概括的讲，我们想要一个逻辑上的 ScrollView，性能上的 ListView ，这样的一种局部展示和功能封装的抽象。
做出这样独立一层的抽象是，
我们看实际的效果， 我们对页面不使用框架，使用框架 Component，使用框架 Component+Adapter 的性能基线对比

• Reducer is long-lived, Effect is medium-lived, View is short-lived.
  我们通过不断的测试做对比，以某 android 机为例：
• 使用框架前 我们的详情页面的 FPS，基线在 52FPS。
• 使用框架， 仅使用 Component 抽象下，FPS 下降到 40， 遭遇“Big-Cell”的陷阱。
• 使用框架，同时使用 Adapter 抽象后，FPS 提升到 53，回到基线以上，有小幅度的提升。

Directory

推荐的目录结构会是这样

sample_page
– action.dart
– page.dart
– view.dart
– effect.dart
– reducer.dart
– state.dart
components
sample_component
– action.dart
– component.dart
– view.dart
– effect.dart
– reducer.dart
– state.dart

上层负责组装，下层负责实现,   同时会有一个插件提供， 便于我们快速填写。
以闲鱼的详情场景为例的组装：

组件和组件之间，组件和容器之间都完全的独立。

Communication Mechanism

• 组件|适配器内通信
• 组件|适配器间内通信

简单的描述：采用的是带有一段优先处理的广播， self-first-broadcast。
发出的 Action，自己优先处理，否则广播给其他组件和 Redux 处理。
最终我们通过一个简单而直观的 dispatch 完成了组件内，组件间（父到子，子到父，兄弟间等）的所有的通信诉求。

Refresh Mechanism

数据刷新

• 局部数据修改，自动层层触发上层数据的浅拷贝，对上层业务代码是透明的。

• 层层的数据的拷贝

• 一方面是对 Redux 数据修改的严格的 follow。

• 另一方面也是对数据驱动展示的严格的 follow。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后

一线互联网Android面试题含详解（初级到高级专题）

这些题目是今年群友去腾讯、百度、小米、乐视、美团、58、猎豹、360、新浪、搜狐等一线互联网公司面试被问到的题目。并且大多数都整理了答案，熟悉这些知识点会大大增加通过前两轮技术面试的几率

如果设置门槛，很多开发者朋友会因此错过这套高级架构资料，错过提升成为架构师的可能。这就失去了我们的初衷；让更多人都能通过高效高质量的学习，提升自己的技术和格局，升职加薪。

最后送给大家一句话，望共勉，永远不要放弃自己的梦想和追求；

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

升成为架构师的可能。这就失去了我们的初衷；让更多人都能通过高效高质量的学习，提升自己的技术和格局，升职加薪。

最后送给大家一句话，望共勉，永远不要放弃自己的梦想和追求；

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！