爲何還要在Activity中寫業務代碼？

通過一年的努力推進，公司研發部門同事終於走上了規範之路。對於舊項目的代碼維護真是苦不堪言，一個OTA升級項目的實現，僅用了三個類實現全部的功能，修個小bug,用了兩天在看整個項目代碼怎麼實現的...動一下就崩一下那種。

因此，能告訴我，爲何還要在Activity中寫業務代碼麼？

MVVM模式淺談

關於Android的MVVM開發框架，多是老生常談。與如停留在概念上講解，不如與實戰開發一塊兒來講說。與MVC、MVP等模式的設計理念是一致的，就是爲了解耦，方便後期維護和功能迭代。

MVVM模式在Android能夠解讀如下三個對象：

View: 這樣指的應該是Activity、Fragment等UI控制器以及相關具體的View，固然也包括xml佈局文件。主要負責界面的實現和與用戶的交互。

Model: 數據模型，能夠說，是應用對外數據交互的接口。在Model層關心的應該是數據。例如根據應用的不一樣環境或邏輯，從網絡或者本地獲取數據，爲ViewModel提供數據。

ViewModel：View與Model交互的橋樑，也是應用邏輯實現的地方。將曾經大量在View層實現的邏輯代碼轉移到自身，從而減小UI控制器代碼的臃腫。

採用MVVM模式在實際開發帶來的好處是什麼？

• 解耦 三個層各司其職，專心負責本身的工做，例如Model層只負責數據的獲取，爲內部提供數據資源。不用處理ViewModel層的業務邏輯。
• 整潔，清晰 解耦以後，應用功能的實現很是整潔，思路也很是清晰，在哪一個類該實現View,哪裏類應該實現數據請求一目瞭然，不存在代碼和邏輯相互嵌套等致使後期項目難以維護的問題。
• 協做 在人力充足狀況，能夠多人負責一個層或者一人負責一個層，而後爲另一個層提供接口。

不可避免的是，不管是MVC、MVP仍是咱們所說的MVVM模式，都會致使類和代碼的增長，但請相信，這值得去作。

實戰中總體框架思路

View層

View層只關心和UI相關的工做，咱們只在Activity、Fragment和xml佈局寫和UI相關代碼，以及和用戶的交互，例如監聽用戶的點擊View以後，應該通知ViewModel去處理相關業務邏輯，而不是在Activity中處理。

更但願的時候，經過數據驅動來改變View，而不是View通知ViewModel有相關交互。例如，經過Jetpack中DataBinding來實現雙向綁定。View的點擊事件直接傳遞到ViewModel層，ViewModel層處理相關邏輯。或者View層監聽ViewModel的LiveData變量，在數據發生變動時更改View。而不是View層爲ViewModel層提供View改變的接口。

下面是View層一些推薦文章：

ConstraintLayout

DataBinding

LiveData

ViewModel層

ViewModel擔任着View與Model交互的橋樑和業務邏輯的處理，具備舉足輕重的地位。這裏咱們推薦使用Jetpack的ViewModel,至於能帶來什麼好處，能夠看下文的連接。必定要記住，不要在ViewModel層去更新UI或者獲取數據，它只負責UI和數據邏輯的交互，但不負責View層 和Model層的工做。通常View層都會持有一個ViewModel實例，經過實例來操做數據，而操做結果經過改變LiveData的值，來作相關UI改變，例如更新數據展現。

Jetpack的ViewModel

Model層

Model層負責數據的獲取，轉爲實體對象，映射到ViewModel層。ViewModel層通常持有Model實例，操做Model提供的接口。對於網絡請求，通常推薦使用Retrofit，數據庫推薦Room。在Model實現的操做通常都是耗時的，Java開發配合RxJava,Kotlin開發使用協程，效果最佳。對實體對象的返回，常有回調函數和EventBus來處理。

下圖是以MVVM模式開發的用戶登陸：

終生願望：但願各位研發同志早日用上開發框架MVVM也好，MVP也罷。