[移动开发] Flutter Fish

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 移动开发 -> Flutter Fish_Redux 3.0起航 -> 正文阅读

[移动开发]Flutter Fish_Redux 3.0起航

作者：闲鱼技术——啊丘

链接原文：https://juejin.cn/post/7031739146372644901

序言

fish_redux 2.0 FlowAdapter 功能优化，整体业务落地后，我们着手fish_redux新一轮的优化与架构演进。fish_redux 3.x 版本最终的目标保持fish_redux的“生命力”，在框架的易用性，可扩展，核心能力部分做到可持续发展。本文分为三大主题，3.0版本首轮优化部分，架构的思考，后续fish_redux可持续输出部分。

?

fish_redux 3.0.1

关于涉及应用开发领域，相信绝大多数同学都听过或多或少了解MVC模型。MVC 是一个架构的描述，它有不少变种，如MVP， MVVM等，但本质上这些都属于MVC的范畴。MVC的定义或解释，不同的语言/领域/框架，又有不同的解释。MVC模式（Model–View–Controller）是软件工程[1]中的一种软件架构[2]模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

当视图（View）从传统的直接操作GUI对象变为声明式UI/响应式UI。会带来两个巨大的变化（MVVM变种）： 1）视图（View）层，对开发者，抹去了GUI的中间状态，复杂度进一步降低 2）MVC的之间的结构关系得到简化和解耦，模型（Model）和控制器（Controller）不再依赖视图（View）。

易用性和可维护性，往往是两个层面的考虑：

?易用性是对过往的归纳总结；?可维护性是对场景需求的进一步的抽象演绎；

那么以fish_redux为例：

?State定义 & Reducer函数对应 Model层?Effect函数对应Controller层?View函数对应View层

fish_redux3.0目的是解决由于客户端/前端应用层软件墒快速上升, 提升软件可维护性, 提高团队协作效率。客户端/前端应用层软件复杂度快速上升,它的原因可能有这些:

1.项目中缺少应用架构, 将完全无法应对需求迭代和人员迭代的变化。2.应用架构和现实需求的不匹配, 导致应用架构无法起到有效的隔离和复用的作用, 甚至成为一种阻碍。3.开发者的认知和设计水平差异, 没有达成团队内有效的共识。

应用框架是应用架构的一种具体的代码实现，以上几点是fish_redux产生和演进的主要动机。而当下fish_redux3.0的阶段性目标:

1.收到大家的反馈, 需要提升易用性。2.提高软件的可维护性, 有传承和延续性。3.试图去整合覆盖更多的闲鱼内场景, 形成应用框架的统一编程范式。

fish_redux3.0.1版本第一步，提升fish_redux的易用性，可维护性。因此核心能力的概念精简，整体实现代码的瘦身是我们的首要目标。fish_redux2.0版本代码量在3k+行，经过这次的精简后整体代码保持在1k行左右。接下来分三个纬度来介绍概念是如何精简。?

1.核心能力

fish_redux结合了Redux的状态管理特点, 产生的基于状态驱动&组装式组件化&函数式&高性能的应用框架。?

状态驱动 在现代化的UI库中, 都是响应式, 状态驱动的。更进一步，在fish_redux中, 驱动UI是自动的。只要状态变化，组件就会得到刷新。 从分层视角看: **第一层状态管理层, 负责了状态的集中化管理, 向上提供了单一数据源下的组件化/状态的读写和变更订阅的能力. **Middleware是设计用来做这一层的切面扩展能力.?

组装式组件化 在fish_redux中, 对组件和组件之间的关系, 做了全新的定义，目的是

1.构建高度隔离的业务代码.2.在隔离的基础上, 提供了业务组件的复用单元.3.将组件与组件之间的依赖关系, 显式声明. 在众多类型的详情/发布场景中, 提高了业务编排可读性可维护性可扩展性.?

函数式 将组件内的业务代码, 通过抽象, 将业务代码划分为View/Reducer/Effect三个角色. 每一角色负责单一职责. 每一单一职责都有每一确定的函数签名来约束.?

上诉核心能力梳理后，明确了各个功能层的核心类以及API。在状态管理我们保留了基础能力部分以及切面能力。 Redux：Store/Connector/DispatchBus/Action 切面能力：MiddleWare 我们做到了最小代码两情况下支持Redux框架能正常work，状态驱动能力得到完美实现。

组件部分（Component）：View/Reducer/Effect/Context 组成。?

优化前：

优化后：

显而易见的是我们去除了redux_aop/redux_routes/redux_component_mixin等部分能力，这样子做的目的是这一部分的能力非fish_redux的核心能力，是一些基于redux做的一些能力扩展，在fish_redux增加部分代码徒增概念，使用者的理解成本会加大。同时redux_middleware,redux_connector合并至redux之中，redux_adapter合并至redux_component之中。?

2.层级收拢

fish_redux2.0实现Component引出了许多功能相近，差异度较低的抽象类,Component/Logic/AbstractLogic/AbstractComponent等。同时Adapter的实现在此基础上更为复杂，Adapter/AbstractAdapter/AbstractAdapterBuilder/Logic/AbstractLogic/AbstractComponent。如此层级下去阅读实现，调试等成本是巨大的。因此我们对组件层的实现做到的了层级收拢，减少多余的概念，保留了BasicComponent/Component/Adapter。

优化前：
abstract class Component<T> extends Logic<T> implements AbstractComponent<T> {
 .....
}

abstract class Logic<T> implements AbstractLogic<T> {
 ......
}

abstract class AbstractComponent<T> implements AbstractLogic<T> {
 .......
}

abstract class AbstractLogic<T> {
....
}

优化后：

class Component<T> extends BasicComponent<T> {
 ...
}
Class Adapter<T> extends BasicComponent<T> {
 ...
}
abstract class BasicComponent<T> {
 .....
}

同时我们对Context部分也做了相同的优化，上下文（Context）针对任何组件是相同的概念与实现。同时针对View接收Context保持了统一实现。原有Context部分： ComponentContext/LogicContext/ContextSys/Context/ViewService AdapterContext/LogicContext/ContextSys/Context/ViewService 多层级实现继承在调试和概念理解也是有一定难度，对于这一部分的重构和减少层级部分我们也做出了变化。?

fish_redux2.0:

class AdapterContext<T> extends LogicContext<T> {
}

class ComponentContext<T> extends LogicContext<T> {
}

abstract class LogicContext<T> extends ContextSys<T> with _ExtraMixin {
}

abstract class ContextSys<T> extends Context<T> implements ViewService {
}

abstract class Context<T> extends AutoDispose implements ExtraData {
}

abstract class ViewService implements ExtraData {
}

fish_redux3.0:

abstract class ComponentContext<T> {
}

class ComponentContextImp<T> extends ComponentContext<T> {
}

我们规范了Context只管理Component组件节点的上下文管理，对于虚拟组件，普通组件保持相同实现无差异化。Context目前负责Component的生命周期，消息发送，以及缓存等功能，同时保存了store已经BuildContext部分。对于代码实现上一眼就能明白Context的能力实现，十分清晰。?

3.扩展能力

扩展能力部分抽离，保持核心可扩展能力。View/Effect/Connector 等功能部件部分，我们做了一系列的扩展，方便使用等核心能力。考虑到对于这些功能为非核心功能部分，不同使用者存在不同看法，同时统一app落地存在不同使用的方式。因此我们针对这些能力移动到后续fish_redux的扩展包中。扩展能力部分的想法来自于Adapter的演进，Adpater的前身有许多功能性Adapter变种，DynamicFlowAdapter, StaticFlowAdapter等使用与不同列表的拉平功能。其核心能力归结于FlowAdapter的Dependents的描述，试想针对这一类的变种是会源源不断，不同场景实现也不相同。对于扩展包收拢该“实现”，基于fish_redux核心能力适应于不同场景的“变种功能”。扩展包的想象力与趣味性还是很足的。针对View/Effect/Connector/Adapter等我们已经有很好的构思，扩展包也在持续输出中。

总结

fish_redux2.0精简版本至3.0部分，整体代码量由3k+减少到目前的1k左右。在不断的优化核心能力部分，相信更加简便的实现和代码优化会不断的输出。我们列举了目前规划的Action，在近期我们会不断投入并且实现的部分。?

1.3.0 版本的release，和扩展能力包输出并且release。同时也会对2.0版本适配DartSDK 2.x的适配。2.虚拟组件如何更优雅的实现，生命周期如何更合理化，虚拟组件如何更巧妙的嵌入。3.Flutter侧应用框架，对于不同业务类型的业务容器的支持。（目前支持ListView容器）

同时定制更长远的计划，不断的像大家输出更好的fish_redux。3.x的目标提升框架的“生命力”，是为了让更多的开发者参与到fish_redux的使用和建设中，不断的完善改进，保持与Flutter的共同发展。所以在核心实现层的代码精简，扩展能力层的输出是让开发者从运用层面，实现部分都能进来讨论并且进入开发。只有这样子可持续的发展进步才能让更好的应用框架被开发者们使用，挖掘。我们也希望我们能在Github上做一些更多的讨论，共同在Flutter侧的Redux应用框架作出贡献。fish_redux3.0-beta版本很快会与各位见面。