架構(gòu)的選擇
在遇到需要實現(xiàn)一個完整的項目時，就不得不考慮該如何整理代碼結(jié)構(gòu)缰揪，規(guī)劃模塊分層砸王，模塊中間如何交互等等問題推盛。在一開始的時間，我會嘗試套用各種各樣的架構(gòu)谦铃，不過最近回眸的時候耘成，發(fā)現(xiàn)這種做法是錯誤的。天下架構(gòu)千萬種，適合你的卻不多凿跳。
思考的起點件豌，最好從變與不變這個角度來觸發(fā)。首先了解哪些是變的控嗜，從這一點開始思考，將重心放在變的部分上面骡显，這樣的架構(gòu)才是合理的疆栏。
我舉一個例子，一個運營型很強(qiáng)的產(chǎn)品惫谤，經(jīng)常開展各種活動壁顶，活動樣式各不相同，邏輯復(fù)雜溜歪。變的地方若专，就在于靈活的活動上面。如果在客戶端上埋各種卡片樣式蝴猪，不僅會使得客戶端代碼復(fù)雜调衰，也無法滿足活動的動態(tài)能力。每當(dāng)上線一種新活動自阱，就需要更新客戶端版本嚎莉。反之，將變的地方放置在服務(wù)端沛豌，客戶端只做展示趋箩，不再需要知曉業(yè)務(wù)細(xì)節(jié)，這樣就會好很多加派〗腥罚客戶端提供基礎(chǔ)的展示能力，登錄芍锦、下載等等基礎(chǔ)操作竹勉，服務(wù)端通過雙方協(xié)定好的協(xié)議下發(fā)對應(yīng)的指令，就能靈活地展示卡片醉旦。
Android Clean 架構(gòu)
通常我們開發(fā)的APP饶米，變化最大的是業(yè)務(wù)需求。在這樣的產(chǎn)品上面车胡，每個迭代都有可能有新功能的加入檬输，老舊功能的修繕。
對于這種業(yè)務(wù)變化較為頻繁的應(yīng)用而言匈棘，就需要在客戶端本地做好基礎(chǔ)工作丧慈，架構(gòu)上要足夠通用，支持新業(yè)務(wù)加入。滿足這樣的架構(gòu)有很多逃默，這里比較推薦[Clean 架構(gòu)](https://github.com/android10/Android-CleanArchitecture)鹃愤。
關(guān)于 Clean 架構(gòu)的文章很多，我就不再這里具體展開了完域，大家有興趣的软吐，可以看以下的鏈接。
一種更清晰的Android架構(gòu)
Architecting Android…The clean way?
在這里還是強(qiáng)調(diào)下吟税，變化的是新的業(yè)務(wù)需求和老舊業(yè)務(wù)的調(diào)整凹耙，因而需要在這里提供擴(kuò)展性十足，魯棒性高的架構(gòu)肠仪。
事件驅(qū)動架構(gòu)
并不是所有情況都能用上面的框架來實現(xiàn)肖抱。同樣我用例子來說明，我們做一個播放器异旧。播放器的邏輯是非常復(fù)雜的意述，需要考慮很多方面的事情，例如播放狀態(tài)吮蛹、用戶操作荤崇、網(wǎng)絡(luò)情況等等，如果我們正向思考匹涮，那這個代碼就很難寫了天试。
變的是播放的各種狀態(tài)，用戶操作等然低，而我們要做的就是去相應(yīng)這些變化喜每，而非正向地操作這些變化。這里的架構(gòu)最好采用事件驅(qū)動模型雳攘，在實現(xiàn)中維護(hù)一個狀態(tài)機(jī)带兜，我們所需要做的事情是切換狀態(tài)，并相應(yīng)狀態(tài)變化吨灭，這樣寫起來就會有條理很多刚照。
例如播放的狀態(tài)，有 Idle喧兄、Preparing无畔、Playing、Paused吠冤、Stopped 等等浑彰，UI界面上響應(yīng)相應(yīng)的狀態(tài)并做出變化，例如播放按鈕在接受到 Paused -> Playing 的狀態(tài)變化后拯辙，將按鈕由播放變?yōu)?code>暫停郭变。
One Model
這種模式一般適用于非常靈活的情形颜价，例如我前面提及的第一個例子，在這種架構(gòu)下诉濒，客戶端作為展示平臺周伦，并不參與業(yè)務(wù)邏輯。這種架構(gòu)有很多種實現(xiàn)方式未荒，簡單的方式有 webview专挪，高階一點的有各種 Web Native Framework。
但在這里介紹另一種方式片排，純粹的 Native 方式狈蚤。客戶端自身作為一個渲染平臺划纽，指定自身可以支持的組件(Cards, Button, TextView etc.)，和相應(yīng)支持的功能(Download, Jump to Web, Open File etc.)锌畸∮铝樱客戶端此時與服務(wù)端定義好協(xié)議，當(dāng)服務(wù)器端根據(jù)協(xié)議下發(fā)指令時潭枣，客戶端需要解析它們比默，并展示相應(yīng)的組件，綁定上對應(yīng)的操作盆犁，這樣下來命咐，客戶端就成了一定程度上的瀏覽器了。
