研究了一段时间androidApp的框架，从MVC，MVP，MVVM，到各种设计模式的变种，最后到android的Flux。都仔细思考了一下。
得出以下对架构的认识：
1.如果从一开始写一个app，要思考要设计，但是不能过度，不要想太多，先写再重构。当然，如果经验足够丰富，那么将来要重构的代码就少点，经验不行，要重构的代码就多。
但是，重构是一定跑不了的。
2.完美的架构是不存在的。
3.每个架构的目的都是去解决软件工程里代码的维护，复用等工作。宗旨只有一个那就是代码模块化，可维护性强。从MVC到MVP，再到MVVM，再到Flux，一直进化其实都不完美。
4.每种架构的进化都是面向对象那六大原则的组合。
5.每种架构其实不针对android，其他语言或者其他终端的架构都可以借鉴，代码的模块化和可维护性是软件工程里大家共同面对的问题。
接下来从这些android架构的进化说起，解释上面的观点。
首先解释第一点，为什么从一开始想进行完美的设计是不切实际的？
因为，架构的设计，其实是一个站在顶层的设计，意味着你要熟悉每一个流程，从而进行抽象，封装，将底层的特性提取出来进行规划和重构。从一开始写代码就要考虑完这些其实是不切实际的，因为没有底层，何来的顶层架构设计。就好像我们不能预测未来一样。
那么之所以出现架构师这个职业，人家都是靠经验和自己一直磨练的抽象能力来对项目进行整体把握，其中经验和抽象能力缺一不可。经验就代表着你现在做的项目他可能之前都把完整的流程走了一遍，他知道这个项目的每一个细节。抽象能力就是这个项目他虽然做过了，但是会不断出现新的问题，比如淘宝在用户一万的时候不可能完全彻底的知道一千万一个亿，比一百万多好几个数量级的时候这个app应该怎么办，这时候就需要抽象能力。
当然还是那句话，架构师要说自己的架构是完美的，那应该是少之又少，几乎没有的。只能说比一般工程师更懂架构，设计的架构更好，而不是最好。这里就好像，
一千个读者眼里有一千个哈姆雷。
接下来看MVC架构：
MVC,MVP的进化历史这里不说了，有兴趣可以去看。UI 架构小史系列文章一共有三篇。
这里只说每种模式的演化和具体实现。
这里是网上的一张图，类似的图太多了。
MVC的实现无非就是：
1.V：对应我们的XML文件。
2.C：对应的是Activity和fragment，相当于一个桥梁，里面有M的引用，负责通知哪个M，该做什么。
3..M：某个M收到通知，发网络请求做完某件事儿之后，利用回调通知View。
问题来了，熟悉面向对象原则的同学可能看出来了
1.耦合性巨无比的高。view，C，M之间互相持有引用，谁都离不开谁。(这里注意面向接口编程，依赖导致原则，即使持有也要持有interface的)
2.C的代码很多。想一下为什么C代码这么多就知道C有两个职责，
a：初始化view的东西。控制view的生命周期。
b：复制响应model的东西，用户交互，view的更新都在这里面。
(注意：这里就为MVP埋下了伏笔)
既然C巨丑，那么MVP就来了。MVP是针对MVC出现的，所以就会针对性的解决MVC的问题2。并且顺手解决问题1。
问题1的解决通过把View和Model之间的那条线去掉，降低了耦合性。
view现在完全不知道有个model存在了。
问题2的解决通过Presenter这个东西。presenter通过持有View和Model两者的引用来作为桥梁，为view何model当信使。通过把Activity或者fragment划分到View里面，把交互层P提出来解决Activity的代码臃肿问题。
具体的MVP结构就是每一个view也就是activity至少对应一个P的接口，一个M的接口，还有一个P的实现类，一个M的实现类。
以上可以看出来，另一个问题出现了，接口巨多，实现类巨多。。。。怎么办呢。没办法。。。。
只能通过不断的模块化，抽象对代码进行重构。
之后呢，架构继续演变出现了茫茫多的MVP,MVC演化架构，什么Passive View，什么TheMVP等。
之后就出现了MVVM的架构，具体的我相信只有知道并且用过databinding的人就会有体会，MVVM对于重复做的不好，因为代码和xml代码混在一起，所以出现问题不好定位，维护性就降低了，绑定一个model吧，重用性就降低了。也不完美。。
其实我觉得架构的实战中，不管是M什么，之间的界限并不是很明显，有时候自己都不知道自己用的是什么变种。所以，大家总体还是要熟悉面向对象的那几大原则进行，有时候真没必要纠结这是什么架构，解决问题才是关键。
由此验证了，我开始说的观点3，4。
解决问题才是关键，什么架构不重要，所有架构都不完美。
观点5的证明需要大家关注facebook在前端UI提出来的flux思路。AndroidFlux是Facebook的Flux架构Android实现。Flux是Facebook在14年提出的一种Web前端架构，主要用来处理复杂的UI逻辑的一致性问题（当时是为了解决Web页面的消息通知问题）。
具体的还是去看这篇文章
这里只写我对flux的理解和总结。
flux的整体结构如上图。核心的思想就是数据流。android编程就是拿数据，存数据，展示数据，最后加一个更新数据。
flux是view会通过actionCreater产生一个Action，这个Action经过Dispatcher的发送，也就是Bus的post到达了对应的store，store再经过post把数据返回到view。简单的说主要思想就是全局只有一个Dispatcher进行Action的发送，然后一个Activity(或Fragment)对应一个Action，一个store和一个ActionCreater。但是我们在实际开发的过程中这个映射关系是可以变得简单的，因为有一些action是不需要单独出来的，可以写成公共的减少类的数量。
现在的flux就像是一个孩子，有了基本的雏形。就好像，大家都知道她怀孕了但是具体的孩子还没长全了，也没有一个固定的模板，需要你在开发的过程中用聪明和智慧在面向对象的基础上进行封装和优化，争取搞一套成熟的东西出来作为大家开发android的规范。我们都应该朝着这个方向努力。所以这个东西我个人认为新手开发者不要使用，因为可能你的面向对象还欠火候，不足够驾驭这个不成熟的东西。
**
最后，港真，大家一定要充分理解面向对象的那几大原则真的太重要了。
简单的理解，点这里
**
以下是本篇文章的参考
https://github.com/androidflux/AFlux-TodoList
http://developer.51cto.com/art/201508/489423.htm
//www.greatytc.com/p/4b755df66a97
//www.greatytc.com/p/9b411b21e800
http://www.cnblogs.com/wytiger/p/5305087.html
//www.greatytc.com/nb/2723599
//www.greatytc.com/p/896ce1a8e4ed
