研究了一段時間androidApp的框架丁屎，從MVC鲁沥，MVP呼股，MVVM，到各種設(shè)計模式的變種画恰，最后到android的Flux彭谁。都仔細(xì)思考了一下。
得出以下對架構(gòu)的認(rèn)識：
1.如果從一開始寫一個app允扇，要思考要設(shè)計缠局，但是不能過度，不要想太多考润，先寫再重構(gòu)狭园。當(dāng)然，如果經(jīng)驗足夠豐富糊治，那么將來要重構(gòu)的代碼就少點唱矛，經(jīng)驗不行，要重構(gòu)的代碼就多井辜。
但是绎谦，重構(gòu)是一定跑不了的。
2.完美的架構(gòu)是不存在的粥脚。
3.每個架構(gòu)的目的都是去解決軟件工程里代碼的維護(hù)窃肠，復(fù)用等工作。宗旨只有一個那就是代碼模塊化刷允，可維護(hù)性強冤留。從MVC到MVP，再到MVVM树灶，再到Flux搀菩，一直進(jìn)化其實都不完美。
4.每種架構(gòu)的進(jìn)化都是面向?qū)ο竽橇笤瓌t的組合破托。
5.每種架構(gòu)其實不針對android，其他語言或者其他終端的架構(gòu)都可以借鑒歧蒋，代碼的模塊化和可維護(hù)性是軟件工程里大家共同面對的問題土砂。
接下來從這些android架構(gòu)的進(jìn)化說起州既，解釋上面的觀點。
首先解釋第一點萝映，為什么從一開始想進(jìn)行完美的設(shè)計是不切實際的吴叶？
因為，架構(gòu)的設(shè)計序臂，其實是一個站在頂層的設(shè)計蚌卤，意味著你要熟悉每一個流程，從而進(jìn)行抽象奥秆，封裝逊彭，將底層的特性提取出來進(jìn)行規(guī)劃和重構(gòu)。從一開始寫代碼就要考慮完這些其實是不切實際的构订，因為沒有底層侮叮，何來的頂層架構(gòu)設(shè)計。就好像我們不能預(yù)測未來一樣悼瘾。
那么之所以出現(xiàn)架構(gòu)師這個職業(yè)囊榜，人家都是靠經(jīng)驗和自己一直磨練的抽象能力來對項目進(jìn)行整體把握，其中經(jīng)驗和抽象能力缺一不可亥宿。經(jīng)驗就代表著你現(xiàn)在做的項目他可能之前都把完整的流程走了一遍卸勺，他知道這個項目的每一個細(xì)節(jié)。抽象能力就是這個項目他雖然做過了烫扼，但是會不斷出現(xiàn)新的問題曙求，比如淘寶在用戶一萬的時候不可能完全徹底的知道一千萬一個億，比一百萬多好幾個數(shù)量級的時候這個app應(yīng)該怎么辦材蛛，這時候就需要抽象能力圆到。
當(dāng)然還是那句話，架構(gòu)師要說自己的架構(gòu)是完美的卑吭，那應(yīng)該是少之又少蜓堕，幾乎沒有的。只能說比一般工程師更懂架構(gòu)令境，設(shè)計的架構(gòu)更好晒旅，而不是最好。這里就好像掷邦，
一千個讀者眼里有一千個哈姆雷白胀。
接下來看MVC架構(gòu)：
MVC,MVP的進(jìn)化歷史這里不說了，有興趣可以去看抚岗。UI 架構(gòu)小史系列文章一共有三篇或杠。
這里只說每種模式的演化和具體實現(xiàn)。
這里是網(wǎng)上的一張圖宣蔚，類似的圖太多了向抢。
MVC的實現(xiàn)無非就是：
1.V：對應(yīng)我們的XML文件认境。
2.C：對應(yīng)的是Activity和fragment，相當(dāng)于一個橋梁挟鸠，里面有M的引用叉信，負(fù)責(zé)通知哪個M，該做什么艘希。
3..M：某個M收到通知硼身，發(fā)網(wǎng)絡(luò)請求做完某件事兒之后，利用回調(diào)通知View覆享。
問題來了佳遂，熟悉面向?qū)ο笤瓌t的同學(xué)可能看出來了
1.耦合性巨無比的高。view淹真，C讶迁，M之間互相持有引用，誰都離不開誰核蘸。(這里注意面向接口編程巍糯，依賴導(dǎo)致原則，即使持有也要持有interface的)
2.C的代碼很多客扎。想一下為什么C代碼這么多就知道C有兩個職責(zé)祟峦，
a：初始化view的東西♂阌悖控制view的生命周期宅楞。
b：復(fù)制響應(yīng)model的東西，用戶交互袱吆，view的更新都在這里面厌衙。
(注意：這里就為MVP埋下了伏筆)
既然C巨丑，那么MVP就來了绞绒。MVP是針對MVC出現(xiàn)的婶希，所以就會針對性的解決MVC的問題2。并且順手解決問題1蓬衡。
問題1的解決通過把View和Model之間的那條線去掉喻杈，降低了耦合性。
view現(xiàn)在完全不知道有個model存在了狰晚。
問題2的解決通過Presenter這個東西筒饰。presenter通過持有View和Model兩者的引用來作為橋梁，為view何model當(dāng)信使壁晒。通過把Activity或者fragment劃分到View里面瓷们，把交互層P提出來解決Activity的代碼臃腫問題。
具體的MVP結(jié)構(gòu)就是每一個view也就是activity至少對應(yīng)一個P的接口，一個M的接口换棚，還有一個P的實現(xiàn)類式镐，一個M的實現(xiàn)類。
以上可以看出來固蚤，另一個問題出現(xiàn)了，接口巨多歹茶，實現(xiàn)類巨多夕玩。。惊豺。燎孟。怎么辦呢。沒辦法尸昧。揩页。。烹俗。
只能通過不斷的模塊化爆侣，抽象對代碼進(jìn)行重構(gòu)。
之后呢幢妄，架構(gòu)繼續(xù)演變出現(xiàn)了茫茫多的MVP,MVC演化架構(gòu)兔仰，什么Passive View，什么TheMVP等蕉鸳。
之后就出現(xiàn)了MVVM的架構(gòu)乎赴，具體的我相信只有知道并且用過databinding的人就會有體會，MVVM對于重復(fù)做的不好潮尝，因為代碼和xml代碼混在一起榕吼，所以出現(xiàn)問題不好定位，維護(hù)性就降低了勉失，綁定一個model吧羹蚣，重用性就降低了。也不完美戴质。度宦。
其實我覺得架構(gòu)的實戰(zhàn)中，不管是M什么告匠，之間的界限并不是很明顯戈抄，有時候自己都不知道自己用的是什么變種。所以后专，大家總體還是要熟悉面向?qū)ο蟮哪菐状笤瓌t進(jìn)行划鸽，有時候真沒必要糾結(jié)這是什么架構(gòu)，解決問題才是關(guān)鍵。
由此驗證了裸诽，我開始說的觀點3嫂用，4。
解決問題才是關(guān)鍵丈冬，什么架構(gòu)不重要嘱函，所有架構(gòu)都不完美。
觀點5的證明需要大家關(guān)注facebook在前端UI提出來的flux思路埂蕊。AndroidFlux是Facebook的Flux架構(gòu)Android實現(xiàn)往弓。Flux是Facebook在14年提出的一種Web前端架構(gòu)，主要用來處理復(fù)雜的UI邏輯的一致性問題（當(dāng)時是為了解決Web頁面的消息通知問題）蓄氧。
具體的還是去看這篇文章
這里只寫我對flux的理解和總結(jié)函似。
flux的整體結(jié)構(gòu)如上圖。核心的思想就是數(shù)據(jù)流喉童。android編程就是拿數(shù)據(jù)撇寞，存數(shù)據(jù)，展示數(shù)據(jù)堂氯，最后加一個更新數(shù)據(jù)蔑担。
flux是view會通過actionCreater產(chǎn)生一個Action，這個Action經(jīng)過Dispatcher的發(fā)送祖灰，也就是Bus的post到達(dá)了對應(yīng)的store钟沛，store再經(jīng)過post把數(shù)據(jù)返回到view。簡單的說主要思想就是全局只有一個Dispatcher進(jìn)行Action的發(fā)送局扶，然后一個Activity(或Fragment)對應(yīng)一個Action恨统，一個store和一個ActionCreater。但是我們在實際開發(fā)的過程中這個映射關(guān)系是可以變得簡單的三妈，因為有一些action是不需要單獨出來的畜埋，可以寫成公共的減少類的數(shù)量。
現(xiàn)在的flux就像是一個孩子畴蒲，有了基本的雛形悠鞍。就好像，大家都知道她懷孕了但是具體的孩子還沒長全了模燥，也沒有一個固定的模板咖祭，需要你在開發(fā)的過程中用聰明和智慧在面向?qū)ο蟮幕A(chǔ)上進(jìn)行封裝和優(yōu)化，爭取搞一套成熟的東西出來作為大家開發(fā)android的規(guī)范蔫骂。我們都應(yīng)該朝著這個方向努力么翰。所以這個東西我個人認(rèn)為新手開發(fā)者不要使用，因為可能你的面向?qū)ο筮€欠火候辽旋，不足夠駕馭這個不成熟的東西浩嫌。
**
最后檐迟，港真，大家一定要充分理解面向?qū)ο蟮哪菐状笤瓌t真的太重要了码耐。
簡單的理解追迟，點這里
**
以下是本篇文章的參考
https://github.com/androidflux/AFlux-TodoList
http://developer.51cto.com/art/201508/489423.htm
http://www.reibang.com/p/4b755df66a97
http://www.reibang.com/p/9b411b21e800
http://www.cnblogs.com/wytiger/p/5305087.html
http://www.reibang.com/nb/2723599
http://www.reibang.com/p/896ce1a8e4ed
