該篇內(nèi)容 come from here
架構(gòu)
根據(jù)維基百科解釋：軟件架構(gòu)是指軟件系統(tǒng)的高級結(jié)構(gòu)以及創(chuàng)建這種結(jié)構(gòu)和系統(tǒng)的學(xué)科犀概，我們都知道什么是建筑學(xué)立哑。
簡單說，決定并實(shí)施特定的代碼架構(gòu)或設(shè)計(jì)模式就是解決開發(fā)人員不時(shí)而遇的問題姻灶。
問題
一些常見的問題铛绰，如代碼緊耦合，即使代碼的一部分發(fā)生細(xì)小變化产喉，也會(huì)導(dǎo)致代碼的其他部分發(fā)生變化或者錯(cuò)誤捂掰。可重用性降低最終導(dǎo)致復(fù)制粘貼代碼行曾沈。顯得不那么友好这嚣。
如何解決
Android本身被編寫為MVC，其中Activity或多或少地負(fù)責(zé)所有事情晦譬。對于足夠簡單的應(yīng)用疤苹，但隨著復(fù)雜性的增加，問題的數(shù)量和水平也會(huì)提高敛腌。
目前有許多不同的架構(gòu)方法卧土，如MVP惫皱，F(xiàn)LUX，MVI尤莺，MVVM等旅敷，已被證明在解決上述問題方面富有成效。只要代碼可維護(hù)颤霎，我們就可以使用任何方法媳谁，我們能夠快速適應(yīng)變化，一切運(yùn)行良好友酱，簡而言之就是開發(fā)人員的快樂生活晴音。
終極目標(biāo)
以大局觀看，最終目標(biāo)是以這種分布式方式構(gòu)建實(shí)體缔杉，將Android相關(guān)的東西保存在一個(gè)地方锤躁，并分離出所有其他不需要運(yùn)行的android實(shí)體，然后進(jìn)一步拆分非-Android依賴片或详，從而實(shí)現(xiàn)代碼模塊化系羞，可擴(kuò)展性，易于維護(hù)霸琴，測試友好性等...
問題：為什么選擇MVVM椒振？
關(guān)于架構(gòu)模式無數(shù)的討論和文章，我們可以同意這一點(diǎn)梧乘，上面討論的最受歡迎和廣泛采用的是MVP~Model - View - Presenter澎迎。圍繞這個(gè)有很多作品，甚至我很欣賞它宋下。它是一個(gè)成熟的模式嗡善，在某種程度上它實(shí)際上解決了這個(gè)問題，總有一個(gè)但是～你懂的～未完学歧。
We can agree that nothing is perfect and there is always a scope for betterment.
我們同意沒有任何事物是完美的罩引，并且有辦法做到更好。
MVP已經(jīng)成熟枝笨，令人驚嘆的是Google引入了Android架構(gòu)組件袁铐，其中包括ViewModel而不是Presenter，因此證明了Google支持MVVM横浑。
MVP肯定有些不對勁!!
一個(gè)簡單的MVP看起來像這樣：
簡單的MVVM看起來像這樣：
以上顯示的是兩者的簡化表示剔桨。您看得出來差別嗎？讓我們從MVP仍然面臨的問題開始徙融，以及我們?nèi)绾卫肕VVM來克服這些問題洒缀。
緊耦合
對于每個(gè)Activity或者Fragment而言（視圖），我們需要一個(gè)Presenter。這是一個(gè)硬約束規(guī)則树绩。 Presenter保存對Activity和Fragment的引用保留對presenter的引用萨脑。 1：1的關(guān)系，這就是最大問題所在饺饭。
隨著視圖復(fù)雜性的增加渤早，這種關(guān)系的維護(hù)和處理也會(huì)增加。
這最終會(huì)導(dǎo)致我們之前遇到的同樣問題瘫俊，因?yàn)樵O(shè)計(jì)的快速變化鹊杖，我們實(shí)際上需要修改整個(gè)關(guān)系。
從我們的最終目標(biāo)“以分布式方式構(gòu)建事物”中挑選一個(gè)聲明扛芽，為了實(shí)現(xiàn)它并避免這種緊密關(guān)系骂蓖，ViewModels被引入。
ViewModels是簡單類胸哥，它們與邏輯/模型層交互涯竟，只暴露狀態(tài)/數(shù)據(jù)，實(shí)際上不知道該數(shù)據(jù)將由誰或如何使用空厌。只有View（Activity）保存對ViewModel的引用，反之亦然银酬，這解決了我們的緊耦合問題嘲更。單個(gè)視圖可以保存對多個(gè)ViewModel的引用。
即使對于復(fù)雜的視圖揩瞪，我們實(shí)際上可以在同一層次結(jié)構(gòu)中具有不同的ViewModel
可測性
由于Presenters很難綁定視圖赋朦，因此編寫單元測試變得有點(diǎn)困難，因?yàn)閂iew具有依賴性李破。
ViewModels的單元測試更加友好宠哄，因?yàn)樗鼈冎皇潜┞稜顟B(tài)，因此可以獨(dú)立測試而無需測試數(shù)據(jù)的消耗方式嗤攻，簡而言之毛嫉，ViewModels不依賴于View。
這是兩個(gè)主要的選擇妇菱，使選擇明確承粤。可能有更多或可能沒有闯团。以下評論等待中!!
最終決策
這些架構(gòu)模式在不斷發(fā)展辛臊，MVVM具備所有能力，或者我們可以說有可能變得強(qiáng)大房交，有用但實(shí)現(xiàn)驚人彻舰。 MVP已經(jīng)發(fā)展到一定程度，但沒有什么是完美的。
我也同意MVVM有一個(gè)輕微的學(xué)習(xí)曲線刃唤，但最終它幫助我們克服了一些缺點(diǎn)隔心。
不確定未來，但截至目前“一個(gè)適合所有解決方案~Silver Bullet”是不存在的透揣，單個(gè)模式可能不足以滿足要求济炎。有人可能不喜歡MVVM，這純粹取決于他們的判斷力辐真。只要我們能夠?qū)崿F(xiàn)最終目標(biāo)须尚，其他任何事情都不重要。
PS：這些是我個(gè)人的經(jīng)歷侍咱，想法和為什么我們喜歡MVVM用于我們的項(xiàng)目耐床。這里的目的不是比較和找出差異。我所嘗試的只是分享我對MVP的經(jīng)驗(yàn)以及MVVM可以克服的一些缺點(diǎn)楔脯。
如果有興趣撩轰，我還準(zhǔn)備了一個(gè)示例項(xiàng)目（樣板代碼設(shè)置，鏈接如下）昧廷，它使用Kotlin堪嫂，Android Architectural Components，RxJava木柬，Dagger 2實(shí)現(xiàn)MVVM皆串。我們將非常感謝您的反饋和建議。
連接地址
那就是這篇文章眉枕。如果你喜歡這個(gè)恶复，并認(rèn)為我在這里做得很好，那么請不要忘記拍手速挑。您的欣賞是有價(jià)值的谤牡，讓我保持積極性。
快樂的編碼姥宝，Cheers!!
