详解Facebook移动架构中的Android Flux架构教程

      架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构(software architecture)是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构描述的对象是直接构成系统的抽象组件。而Flux是Facebook用来构建用户端的web应用的应用程序体系架构。它通过利用数据的单向流动为React的可复用的视图组件提供了补充。相比于形式化的框架它更像是一个架构思想，不需要太多新的代码你就可以马上使用Flux构建你的应用。

     如果要为Android应用找到一个好的架构，其实不是一件容易的事情。就算是谷歌，其也没那么在意这个事情，因此在设计模式上，除了Activity 生命周期管理之外，就再也没有官方的推荐。

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

　　 Clean Architecture

　　就目前来说，目采用Uncle Bob在2012年对web应用提出的建议： Clean Architecture。

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

　　一般情况下，移动应用要比web应用的生命短。移动端技术的发展实在是太快，以至于发行的app或许还没推广开就快要过气了。

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

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

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

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

　　Flux 架构介绍

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

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

　　数据流总是单向的一个单向的数据流，是Flux架构的核心，也是它简单易学的原因。如下讨论，在进行应用测试的时候，它提供了非常大的帮助。

　　应用被分成三个主要部分：

      Dispatcher: 中心枢纽，传递所有的action，负责把它们运达每个Store。　　

      View: 应用的界面。这里创建响应用户操作的action。

　　Store: 维护一个特定application domain的状态。它们根据当前状态响应action，执行业务逻辑，同时在完成的时候发出一个change事件。这个事件用于view更新其界面。

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

　　Flux Android 架构

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

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

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

　　View: Activity o或者Fragment

　　Dispatcher: 一个事件总线( event bus)，在我的例子中将使用Otto，但是其它任何实现都应该是ok的。

　　Actions

　　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。

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

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

　　那么，Flux application是怎样获得数据的呢?

　　网络请求与异步调用

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

　　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。

　　评价：

　　通过Otto Bus实现Dispatcher。但这几乎是在任何bus都是可以的。Flux架构本身在事件上有一定限制，只是在我这里没有采用。原本Flux的定义中，前一个事件没有完成之前就开始分发下一个事件是不允许的，会抛出一个异常。但我没有采用，因为这样能使项目简单点。

　　有一个ActionsCreator类帮助创建Action，并把它们post给Dispatcher。这在Flux中时相当普遍的模式，可以让事情变的有序。

　　Actions类型只是String常量。可能这不是最好的实现，但是它能快速并且有助于事情的简单化。

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

　　总结

　　在安卓应用中其实不存在最佳架构的说法。不过存在适合你当前app的最佳架构。这个架构可以让你和团队其他成员协作起来更轻松，按时完成项目，尽可能的保持高质量与较少的bug。

　　综上文，我总结一下，上文主要是通过Flux 架构介绍和Flux Android 架构来详解Facebook移动架构中的Android Flux架构，Flux 架构介绍主要是简单介绍应用的三部分测试，Flux Android 架构主要是介绍Actions、Stores、网络请求与异步调用、To-Do应用等等内容。