为Android应用程序找到一个好的架构并不是一件容易的事。Google似乎不太关心这个事情，所以在设计模式方面，除了Activity生命周期管理，官方没有推荐。但是，为您的应用程序创建架构非常重要。不管喜欢与否，任何应用程序最终都会有一个架构。所以你肯定会成为一个架构的奠基人，而不是坐等它出现。今天：CleanArchitecture目前的趋势是采用UncleBob在2012年对Web应用程序的提议：CleanArchitecture。但我发现CleanArchitecture对于大多数Android应用来说有点过度设计。通常移动应用程序的生命周期比Web应用程序短。移动技术发展如此之快，以至于今天发布的应用程序可能在一年后就完全过时了。移动应用程序做的很少。绝大多数用例只是数据流消费。从API获取数据，向用户显示数据，只需很少的打字和书写。所以它的业务逻辑并不复杂。至少不像后端那么复杂。虽然你要处理很多平台问题：内存、存储、suspend、resume、网络、定位等等，但是这些都不是业务逻辑。所有的应用程序都有这些东西。因此，大多数应用程序似乎并没有从复杂的层次结构或工作执行的优先级队列中获益。他们可能只需要一种简单的方法来组织代码、高效协作并更轻松地发现错误。Flux架构简介Facebook使用Flux架构来构建其客户端Web应用程序。与CleanArchitecture一样，它不是为移动应用程序设计的，但它的特性和简单性使我们能够在Android项目中很好地采用它。要理解Flux，有两个关键特性数据流总是单向的单向数据流是Flux架构的核心，也是它易于学习的原因。如下所述，它在测试应用程序时有很大帮助。该应用程序分为三个主要部分：视图：应用程序的界面。响应用户操作的操作是在此处创建的。Dispatcher：中央枢纽，传输所有动作，并负责将它们传输到每个Store。存储：维护特定应用程序域的状态。它们根据当前状态响应操作，执行业务逻辑，并在完成时发出更改事件。视图使用此事件来更新其界面。这三部分通过Action进行通信：一个简单的基础对象，以类型区分，包含与操作相关的数据。FluxAndroidArchitecture在Android开发中使用Flux设计规范的目的是建立一个在简单性、可扩展性和测试之间相对平衡的架构。第一步是找到Flux元素和Android应用程序组件之间的映射。其中两个元素很容易找到和实施。View：Activityo或FragmentDispatcher：一个事件总线（eventbus），在我的例子中会使用Otto，但任何其他实现应该都可以。ActionsActions也不复杂。它们的实现和POJO一样简单，有两个主要属性：类型：定义事件类型的字符串。数据：加载此操作的地图。例如，显示用户详细信息的典型操作如下：Bundledata=newBundle();data.put("USER_ID",id);Actionaction=newViewAction("SHOW_USER",data);Stores这可能是最难的部分通量理论。如果你以前用过CleanArchitecture，你可能很难接受。因为Stores承担了被分成多层的责任Stores包含应用程序的状态及其业务逻辑。它们类似于丰富的数据模型，但可以管理多个对象的状态，而不仅仅是一个。Stores响应Dispatcher发送的Actions，执行业务逻辑并发送更改事件。Stores的唯一输出是这个单一事件：更改。其他对Store内部状态感兴趣的组件必须侦听此事件并使用它来获取所需的数据。系统中的任何其他组件都不需要知道应用程序的任何状态信息。***，stores必须对外暴露获取应用状态的接口。这样，视图元素可以查询Stores并相应地更新UI。例如，在PubDiscoveryApp中，SearchStore用于跟踪搜索的项目、搜索结果和搜索历史。在同一应用程序中，ReviewedStore还包含浏览过的酒吧列表和必要的逻辑，例如按评论排序。但是要记住一个重要的概念：商店不是仓库。他们的职责不是从外部源（API或数据库）获取数据，而是跟踪操作提供的数据。那么，FluxApplication是如何获取数据的呢？网络请求和异步调用在第一个Flux图中，我有意跳过了一部分：网络调用。下图完善了第一个图并添加了更多细节：异步网络调用由ActionsCreator触发。NetworkAdapter完成相应API的异步调用，并将结果返回给ActionsCreator。最后，ActionsCreator使用返回的数据分发相应类型的Action。将所有网络工作和异步工作与Stores分开有两个主要优点：您的Stores是完全同步的：这使得Stores中的逻辑更容易跟踪。错误也更容易追踪。此外，由于所有状态更改都是同步的，因此测试Store变得非常简单：开始操作并等待所需的结果。所有操作均由ActionCreator触发：在单个点创建和启动所有用户操作大大简化了查找错误的过程。忘记在多个类中寻找操作的来源，一切都发生在这里。此外，ActionCreator中的所有内容都是同步的，因为异步调用发生在之前。这大大提高了代码的可追溯性和可测试性。演示代码：To-Do应用程序在这个例子中，您将看到一个典型的To-Do应用程序使用Flux架构。我使项目尽可能简单，只是为了演示此架构如何生成组织良好的应用程序。关于实现的一些评论：Dispatcher是通过OttoBus实现的。但几乎任何公共汽车都可以。Flux架构本身对事件有一定的限制，我这里没有用到。在Flux的原始定义中，不允许在上一个事件完成之前开始派发下一个事件，会抛出异常。为了保持项目简单，我没有使用它。有一个ActionsCreator类可以帮助创建Actions并将它们发布到Dispatcher。这是Flux中一种相当常见的模式，可以使事情井井有条。动作类型只是字符串常量。也许这不是最好的实现，但它速度很快并且有助于使事情变得简单。Actions数据也是如此：它们只是以String类型为键，以Object为值的HashMap。在转换为实际数据时，这可能会导致Stores中出现丑陋的类型转换。显然这也不是类型安全的，但这是为了我们的例子。总结一下Android应用中没有***架构的事实。但是，有适合您当前应用程序的最佳框架。这种结构可以让你更容易与其他团队成员协作，按时完成项目，尽可能保持高质量和更少的错误。我相信Flux对上述功能有很好的支持。源代码https://github.com/lgvalle/android-flux-todo-app进一步阅读：FacebookFlux概述测试Flux应用程序Flux架构逐步异步请求和FluxFlux和Android感谢特别感谢我们的同事MicheleBertoli采取是时候投稿了我在校对这篇文章的同时介绍了Flux。
