今天講架構，有講錯的地方還請指正，直接開始：
MVP架構：
V 是指View、任何跟使用者互動的介面，
因此Activity或是Fragment等等跟View的區塊，
在此架構下都會被歸類為View而View在提供一個Interface，
給Presenter去操作View的變化。
M 是指Model或Module，依專案的執行情況，
可以是只要負責承接資料的Model，又或是一個固定流程的Module。
P 則是指Presenter，由此切開View跟Model的關連，
他們的連繫都交給Presenter去負責，例如：
btn_next的按鈕按下去後，View去呼叫presenter的ButtonNextClick事件，
因此View並不會知道presenter裡面有做什麼事情。
以MyPresenter來說，onButtonNextClick這個事件，
去呼叫了myView Interface 去執行一個nextPage的事件，
但presenter本身也就因此不干涉View層的畫面變化。
這個架構的好處是：
每個角色有清楚的定位，不會因為整個程式的架構混雜在一起，
因而不好寫測試或是改功能，你可以很清楚的知道整個程式執行到哪。
缺點則是：
隨著專案的進展，畫面複雜度的提高，View提供的Interface 要越來越多，
例如一個畫面可能有兩三個Fragment或是交雜的情況，
那麼這時候對應這些View的Presenter，
是要同時去改變這幾個View的Interface or
delegate 給對應Activity的View Interface
然後再由這個Activity的 Interface去傳遞給不同的Fragment的View Component
去執行對應的舉動？
例如：
這個Activity有左右兩個Fragment(篇幅關係省略Fragment init跟顯示)，
這兩個Fragment都可以被presenter操作，但…
MyPresenter想操作左右Fragment的時候，
應該是宣告一個LeftFView給Fragment implements呢？
還是統一deleget給MyView，再由Activity
去傳遞給指定的View做畫面變化呢？
implement MyPresenter的LeftFragment
又或是像RightFragment依樣，
宣告一個public 功能給Activity 去控制？
當然只要團隊統一做法即可，但如果專案的複雜度的增加，
以及越來越多的Interface，就會帶給開發者不少的負擔，
不過MVP的架構是相對清晰的，可以很清楚的知道每段程式的執行跟變化。
以上是MVP的架構。
MVVM(AAC)架構：
V 一樣是View，指的是與使用者的互動畫面等等的。
M 是指Model，在這個架構下的Model很明確的被封裝成資料。
VM 則是指ViewModel，ViewModel負責的事情是將View跟Model連繫起來，
用Observer的方式去定義每個View，然後將其需要觀察的資料Subscribe起來。
因此當資料改動的時候，View會依據其Subscribe的資料去做對應的改動，
這個架構相對MVP來說，每一個部分都會有反轉依賴(DI)的概念才能實作，
誠如筆者上篇說的，如果不是因為Google的推動，筆者其實不會推薦使用這個架構，
這個架構如果沒有AAC的底層輔助Library去做掉這些Observe跟Subscribe，
只是徒增程式開發的繁瑣程度跟難度而已。
不過昨是今非，現在要筆者來推薦，
筆者會主張MVVM架構已經是相當成熟及方便開發的架構了。
因此可以的話，請務必逐步改成此架構。
綜上所述，
希望可以藉由這兩天的文章，分享目前流行的Android開發架構，
感謝各位今天的觀看。
本文同步刊登在Medium上，連結在此。
iThome鐵人賽
看影片追技術