大约11年左右的时候我开始写RESTful的App，之前虽然写过几个App但是大都是工具型的，工具型的App如果没有特殊的技术要求（比如图片处理、视频处理）都比较简单。RESTful的App可以算是一类典型，存储、网络、UI三块都会用到，在实现这些App的过程中，App“架构”也升级换代了几次，下面例数过去曾经用过的“架构”或许可以作为参考。
给“架构”加上引号的原因是在大多数情况下，我曾经实现的那些App并没有使用某些框架或方案，所以算不上一套完整的架构，而只是架构App的思路。
最早，所谓的“MVC”
这个阶段的App大概是这种结构，所有的业务逻辑放在Activity中处理，包含简单的UI逻辑（比如显示一个对话框）、异步网络请求(比如启动一个AysncTask做网络请求)、存储逻辑(比如在onCreate()中读取文件，在onDestroy()中保存文件)。这个时候对“MVC”架构并没有深入的了解，仅仅从字面有意义上认为App应该分为Model-View-Controller三层，而对于Android平台，想当然的认为View是属于XML布局文件的，Controller是属于Activity的，Model需要自己的实现，于是产生了这种架构。很明显，这种“架构”在可扩展性、灵活性甚至功能性上都是有问题的。
写出这种架构得益于两个原因：
- 开发经验少，基本上所有的知识都是从官方文档和示例工程中学来的，而示例一般都会故意写的简单。
- 早期做Android的同学少，关于架构也没有去讨论，知识匮乏。
直到现在为止依然有很多同学打着“MVC”的旗号，写着这种不伦不类的代码。究其原因，一是因为早期的MVC早已不再适用，而后来的各种夹带私货的MVC变种经常用“MVC架构“来做宣传，后学者受到误导之后反而对MVC无法形成一个清晰的认识。
再后来，学习Google官方的架构
architecture from google
这种方案首先做了分层处理，把复杂的网络请求和存储逻辑从Activity中分离出来，放在独立的 Service 里面处理，分层良好，单向的数据流使程序逻辑容易分析。这种架构已经可以开发一些简单的App了，它规范了Android-App的分层结构。但是对于复杂的业务逻辑、复杂的UI状态、适用新的库或UI组件却有些捉襟见肘。
太过依赖于Android的自带组件，比如Service、ContentProvider 的设计，这种设计是典型的Google风格的App，扩展第三方库会变得不方便。最近的一个例子是Google新出的RecyclerView已经不支持CursorAdapter了，而且Service的使用在新的流行的网络库面前也变得鸡肋。
如何处理复杂的业务逻辑，同时保证UI的一致性，这种架构没有讨论，事实上处理起来并不容易。
Flux
当Facebook的工程师第一次提出Flux的时候，有提到他们使用MVC出现的问题，那一次简直说出了我的心声。架构清晰、具体、容易操作，这样的好处是在多人协作的情况下有统一的标准，不易走偏，同时清晰的架构更有利于快速迭代快速出成品，这对于现在整个浮躁的大环境而言再好不过。
基于 Clean 架构的Android实践也有很多人用过，但是使用Clean架构的App一个明显的缺点是代码量大而且复杂，同时Clean架构并没有规范App分层的依据（怎么分层、如何分层依赖于开发实现）这同样会导致代码风格的不一致。更具体的说，Clean架构是一种非常抽象的架构，它是一种思想，而不是具体的架构。
FluxFlux架构对分层、模块、数据流都有明确的定义，这对快速开发有很大帮助。另外，这种架构是Facebook正在维护的架构，你可以方便的找到”活人“去更彻底的了解它，而这是其他各种MV-X架构所没有的优势。
经过几番比较，到目前为止项目中使用的都是Flux架构。相信以后Flux在移动开发中会更加普及吧。