Flux Architecture on Android

关注

转载最新推荐文章于 2026-01-23 10:23:04 发布 621 阅读 AI 写同款· GEO 优化 ›

2016年Android开发技术栈与架构演进解析 Android开发技术栈在2016年迎来重要转折，Kotlin语言和React Native等跨平台方案开始崭露头角。从基础架构看，Gradle构建系统和Java 7仍是主流，而UI层则见证了Material Design组件和RecyclerView的普及。技术原理上，响应式编程通过RxJava实现优雅的异步处理，MVP模式则规范了视图与逻辑的分离。这些技术革新为移动应用开发带来了更高效的工程实践，特别是在性能优化方面，Glide等图片加载框架和Realm等数据库方案显著提升了应用流畅度。当前场景下，这些阅读详情

英文原文：http://lgvalle.xyz/2015/08/04/flux-architecture/

要为安卓应用找到一个好的架构不是一件容易的事情。谷歌似乎不太在乎这个事情，因此在设计模式上，除了Activity 生命周期管理之外，再也没有官方的推荐。

但是，为你的应用打造一个架构是非常重要的。不管你是否喜欢，任何应用最终都会有一个架构。因此你最好是成为一个架构的奠基人，而不是等着它出现。

今天: Clean Architecture

目前的趋势是采用Uncle Bob在2012年对web应用提出的建议： Clean Architecture。

但是我发现Clean Architecture对于绝大多数安卓应用来说都有点过度设计了。

通常移动应用要比web应用的生命短。移动端技术的发展太快，以至于今天发行的app可能在一年后已经完全过时。

移动应用所做的事情很少。绝大多数的用例都只是数据信息流的消费。从API获取数据，显示数据给用户，很少有输入与写入。

所以它的业务逻辑并不复杂。至少不如后端一样的复杂。虽然你要处理很多平台上的问题：内存，存储，暂停，恢复，网络，定位等等，但是这些都不是业务逻辑。所有app都有这些东西。

因此，绝大多数app似乎都无法从类似于复杂的分层或者工作执行优先级队列中获益。

他们也许只是需要一种组织代码的简单方式，能高效的一起工作，更容易的发现bug。

Flux 架构介绍

Flux 架构被Facebook使用来构建他们的客户端web应用。跟Clean Architecture一样，它不是为移动应用设计的，但是它的特性和简单可以让我们很好的在安卓项目中采用。

flux-graph-simple

要理解Flux，有两个关键的特点

数据流总是单向的

一个单向的数据流是 Flux 架构的核心，也是它简单易学的原因。就如下面讨论的，在进行应用测试的时候，它提供了非常大的帮助。
应用被分成三个主要部分：
- View: 应用的界面。这里创建响应用户操作的action。
- Dispatcher: 中心枢纽，传递所有的action，负责把它们运达每个Store。
- Store: 维护一个特定application domain的状态。它们根据当前状态响应action，执行业务逻辑，同时在完成的时候发出一个change事件。这个事件用于view更新其界面。

这三个部分都是通过Action来通信的：一个简单的基本对象，以类型来区分，包含了和操作相关的数据。

Flux Android 架构

在安卓开发中使用Flux设计规范的目的是建立一个在简单性与易扩展易测试之间都比较平衡的架构。

第一步是找到Flux元素和安卓app组件之间的映射。

其中两个元素非常容易找到与实现。

View: Activity o或者Fragment
Dispatcher: 一个事件总线（ event bus），在我的例子中将使用Otto，但是其它任何实现都应该是ok的。

Actions

Actions也不复杂。它们的实现和POJO一样简单，有两个主要属性：

Type: 一个String，定义了事件的类型。
Data: 一个map，装载了本次操作。

比如，一个显示用户详情的典型action如下：

 
        Bundle data = 
        new 
        Bundle(); 
       
        data.put(
        "USER_ID"
        , id); 
       
        Action action = 
        new 
        ViewAction(
        "SHOW_USER"
        , data);

Stores

这可能是Flux理论中最难的部分。

如果你之前使用过Clean Architecture，你可能难以接受。因为Stores承担了原本被分成多层的责任。

Stores包含了application的状态与它的业务逻辑。它们类似于rich data models但是可以管理多个对象的状态，而不仅仅是一个对象。

Stores响应Dispatcher发出的Action，执行业务逻辑并发送change事件。

Stores的唯一输出是这单一的事件：change。其它对Store内部状态感兴趣的组件必须监听这个事件，同时使用它获取需要的数据。

系统中不再需要任何其它组建去了解application的任何状态信息。

最后，stores必须对外公开一个获取application状态的接口。这样，view元素可以查询Stores然后相应的更新UI。

flux-graph-store

比如，在一个Pub Discovery App 中，SearchStore被用来跟踪被搜索的item，搜索结果以及搜索历史。在同一个应用中，一个ReviewedStore同样包含了浏览pub的列表以及必要的逻辑比如根据review排序。

但是有一个重要的概念需要记住：Stores并不是仓库。它们的职责不是从一个外部源（API或者数据库）获取数据，而是跟踪actions提供的数据。

那么，Flux application是如何获得数据的呢？

网络请求与异步调用

在第一幅Flux示意图中我有意跳过了一部分：网络调用。接下来的示意图完善第一幅图并添加了更多细节：

flux-graph-complete

异步网络调用是被一个Actions Creator触发的。一个Network 适配器完成相应API的异步调用并且返回结果给Actions Creator。

最终Actions Creator分发带有返回数据的相应类型的Action。

把所有网络工作和异步工作独立于Stores之外有两个主要的优点：

你的Stores是完全同步的：这让Store中的逻辑更容易跟踪。Bug也更容易跟踪。同时，因为所有的状态变化都是同步的，那么Store的测试变会的非常简单：启动actions然后等待期望的结果。
所有的action都是从一个Action Creator触发的：在一处单一的点创建与发起所有用户操作可以大大简化寻找错误的过程。忘掉在多个类中寻找某个操作的源头吧，所有的事情都是在这里发生的。同时，因为异步调用发生在这之前，所有来自于ActionCreator的东西都是同步的。这大大提高了代码的可跟踪与可测试性。

演示代码：To－Do应用

在这个例子中，你将看到一个使用Flux架构的典型的To-Do应用。

我让项目尽量简单，只演示这个架构如何能够产生组织良好的app。

对于实现的一些评价：

Dispatcher的实现是通过Otto Bus。但是几乎任何bus都是可以的。Flux架构本身在事件上有一定限制，我在这里没有采用。原本Flux的定义中，前一个事件没有完成之前就开始分发下一个事件是不允许的，会抛出一个异常。为了让项目简单，我没有采用。
有一个ActionsCreator类帮助创建Action，并把它们post给Dispatcher。这在Flux中时相当普遍的模式，可以让事情变的有序。
Actions类型只是String常量。也许这不是最好的实现，但是它快速并且有助于事情的简单化。

同样的还有Actions数据：它们只是以String类型为key，Object为值的HashMap。这会导致Stores中转换成实际数据的时候发生丑陋的类型转换。而且显然这也不是类型安全的，但这也是为了让我们的例子更好理解。