在第一篇，我們曾提到Android測試的其中一個困難點在於Activity經常有著過多的邏輯。這個單元分別介紹了在MVP(Model View Presenter)、MVVM(Model View ViewModel)這兩種架構。這兩種架構都是為了簡化view與商業邏輯資料處理互相溝通的邏輯，讓不同的元件拆得更乾淨，減少彼此的耦合。在這個單元的小結就來整理一下兩個架構的差異。

MVP VS MVVM

MVP已經把Activity一部分的責任放到Presenter處理。Presenter與View的溝通透過ViewInterface的callback去通知View。如果兩者間的行為過於複雜，View與Presenter中間的接口越來越多，View的實現的方法會越來越多。同時對於UI的輸入與數據的變化，仍要手動處理。也因此View與Presenter還是有一定的耦合度，一但當View裡的某個UI元素要改變，中間的Interface就必須修改。

MVVM
MVVM的View與ViewModel則是透過用觀察者模式，當LIfeCycle的狀態改變，LiveData會通知觀察者，以便更新UI。測試就更方便了，ViewModel與View的關系並沒有耦合。

數據驅動

MVVM的另一個特色就是數據驅動，傳統方法要再Activity取得UI元件再更新UI。而MVVM當ViewModel變化時，直接通知UI更新。讓viewmodwl只關心數據，不需要與UI 交互。

可測試性

在寫Presenter測試時，你必須去驗證與View的互動當你寫驗證是否有呼叫View的Interface，其實你的測試已經包含一部分View的行為。ViewModel則專注在邏輯與數據(LiveData)。

其他差異：

• Presenter 擁有View的參考，而ViewModel沒有。
• Presenter與View通常是一對一的關係。
• ViewModel與View可以是一對多的關係。
• ViewModel不需知道View是否在監聽。

MVVM 與 MVP 的選擇
綜合以上的比較與優缺點，個人會選擇用MVVM的架構，在可測試性、維護性，MVVM都比MVP來得較好。

關於Android的架構，官方還有許多的資源可以參考。LiveData、 ViewModel這些都是屬於 Android Architecture Components的一部分。甚至是Android Jetpack都很值得一看，對於提升可測試性也是有幫助的。

參考：
https://developer.android.com/topic/libraries/architecture
https://developer.android.com/jetpack/#architecture-components

第三單元「Android 的架構」就到這裡結束，下個單元開始介紹「在Android實踐TDD」。