Android架構發展進化詳解
一.MVC架構
1.概述
MVC架構是第一個應用於Android開發的成熟架構，由Model、View、Controller三部分組成：
- Model：負責數據的存儲及相關邏輯。
- View：負責界面展示。
- Controller：負責業務邏輯。
MVC架構將代碼邏輯分成瞭數據邏輯、渲染邏輯、業務邏輯三部分，三部分邏輯分別封裝在Model層、View層、Controller層。理想條件下，三者呈單向調用，如下圖所示：
但實際上，由於Android中負責頁面展示的組件(Activity或Fragment)同時承擔瞭View層和Controller層兩部分的職責，導致MVC架構在實際使用中退化。退化後的MVC架構如下圖所示：
在一些業務場景中，由於View層與Controller層的邏輯耦合在一起，使得二者可以相互調用，進一步衍生出調用關系更加復雜的MVC架構，如下圖所示：
此時的MVC架構僅保持瞭Model層的獨立，而View層和Controller層沒有得到有效的隔離。
2.例子
點擊按鈕從網絡獲取用戶信息，經過解析後展示到界面上。
1）Model層
data class UserInfo(
var name: String,
var age: Int,
var height: Int,
var weight: Int
)
interface NetResponse<T> {
fun onSuccess(data: T)
fun onError(e: Throwable)
}
class NetModel {
fun getUserInfo(callback: NetResponse<UserInfo>) {
// 模擬網絡獲取
val dataStr = getStringFromNet()
val info = dataStr.parseJson<UserInfo>()
return callback.onSuccess(info)
}
}
2）Controller層
class MainActivity : AppCompatActivity() {
private val netModel = NetModel()
// Controller調用Model
private fun getUserInfo(callback: (UserInfo) -> Unit) {
netModel.getUserInfo(object : NetResponse<UserInfo> {
override fun onSuccess(data: UserInfo) {
callback.invoke(data)
}
override fun onError(e: Throwable) {
callback.invoke(getNetErrorData())
}
})
}
private fun getNetErrorData(): UserInfo {
return UserInfo(name = "", age = 0, height = 0, weight = 0)
}
}
3）View層
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
btnNet?.setOnClickListener {
// View調用Controller
getUserInfo {
tvName?.text = it.name
tvAge?.text = it.age.toString()
tvHeight?.text = it.height.toString()
tvWeight?.text = it.weight.toString()
}
}
}
}
在MVC架構中，Controller實際上就是對Model代碼的封裝，如果在btnNet的點擊回調中調用getUserInfo方法，則是View調用Controller。如果在點擊回調中直接調用netModel的getUserInfo方法，那就變成瞭View調用Model。
二.MVP架構
1.概述
MVP架構是MVC架構的升級版，由Model、View、Presenter三部分組成：
- Model：負責數據的存儲及相關邏輯。
- View：負責界面展示。
- Presenter：負責業務邏輯。
MVP架構也將代碼邏輯分成瞭數據邏輯、渲染邏輯、業務邏輯三部分。與MVC架構不同的是，在MVP架構中，負責業務邏輯的Controller層升級為Presenter層。Presenter層不再像Controller層一樣耦合在View層中，而是作為獨立的類與View層和Model層進行雙向的通信，三者調用關系如下圖所示：
MVP架構有效的將View層與Model層隔離，同時，由於Presenter層僅持有View層和Model層的接口，因此對於Presenter層邏輯的測試變得更加的方便。而由於所有的邏輯代碼都集中到Presenter層中，因此Presenter層變得比原本的Controller層更臃腫。
2.例子
點擊按鈕從網絡獲取用戶信息，經過解析後展示到界面上。
1）Model層
data class UserInfo(
var name: String,
var age: Int,
var height: Int,
var weight: Int
)
interface NetResponse<T> {
fun onSuccess(data: T)
fun onError(e: Throwable)
}
class NetModel {
fun getUserInfo(callback: NetResponse<UserInfo>) {
// 模擬網絡獲取
val dataStr = getStringFromNet()
val info = dataStr.parseJson<UserInfo>()
return callback.onSuccess(info)
}
}
2）Presenter層
class Presenter(private val view: IView) {
private val model = NetModel()
fun getUserInfo() {
model.getUserInfo(object : NetResponse<UserInfo> {
override fun onSuccess(data: UserInfo) {
view.setName(data.name)
view.setAge(data.age)
view.setHeight(data.height)
view.setWeight(data.weight)
}
override fun onError(e: Throwable) {
val data = getNetErrorData()
view.setName(data.name)
view.setAge(data.age)
view.setHeight(data.height)
view.setWeight(data.weight)
}
})
}
private fun getNetErrorData(): UserInfo {
return UserInfo(name = "", age = 0, height = 0, weight = 0)
}
}
3）View層
interface IView {
fun setName(name: String)
fun setAge(age: Int)
fun setHeight(height: Int)
fun setWeight(weight: Int)
}
class MainActivity : AppCompatActivity(), IView {
private val presenter = Presenter(this)
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
btnNet?.setOnClickListener {
presenter.getUserInfo()
}
}
override fun setName(name: String) {
tvName?.text = name
}
override fun setAge(age: Int) {
tvAge?.text = age.toString()
}
override fun setHeight(height: Int) {
tvHeight?.text = height.toString()
}
override fun setWeight(weight: Int) {
tvWeight?.text = weight.toString()
}
}
三.MVVM架構
1.概述
MVVM架構最早由微軟提出，並在微軟的桌面客戶端UI框架WPF中實現，由Model、View、ViewModel三部分組成：
- Model：負責數據的存儲及相關邏輯。
- View：負責界面展示。
- ViewModel：負責業務邏輯。
MVVM架構是MVP架構的簡化版，它同樣的解決瞭View層與Model層的隔離問題。不同於MVP架構中的View層與Presenter層之間的雙向通信，MVVM架構采用瞭一種View層與ViewModel層綁定的方式，當ViewModel層中的UI數據或屬性發生變化時，View層的UI會跟隨一起變化，這樣原本Presenter層中操作View層接口的邏輯通過綁定的方式被簡化，層級變得更加輕量，簡化後的Presenter層與View層之間隻存在數據驅動的關系，Presenter層被簡化成瞭ViewModel層。三個層級的調用關系如下圖所示：
在MVVM架構的早期發展中， 開發者們使用谷歌官方的DataBinding框架實現數據與視圖的綁定，但DataBinding框架使用復雜，且每當有一處代碼需要修改，就會聯動修改多處代碼。後來，谷歌官方推薦使用Jetpack組件集中的LiveData+ViewModel。通過使用LiveData+ViewModel，大大減少瞭在使用MVVM架構中模版代碼的編寫。再後來，為瞭更好的在協程中使用MVVM架構，以及更方便的編寫流式代碼，谷歌官方推薦使用StateFlow。
MVVM架構既做到瞭View層與Model層的隔離，又保證瞭ViewModel層的簡潔不臃腫。View層與ViewModel層的交互完全依賴數據驅動，方便層級的邏輯復用與測試以及多人的協作開發。但同時，由於MVVM架構比MVC架構和MVP架構更抽象，因此在使用時需要編寫更多的模版代碼。當UI界面復雜時，由於每個UI需要有不同的數據，因此會造成數據過於分散不易維護。
2.例子
點擊按鈕從網絡獲取用戶信息，經過解析後展示到界面上。
1）Model層
data class UserInfo(
var name: String,
var age: Int,
var height: Int,
var weight: Int
)
interface NetResponse<T> {
fun onSuccess(data: T)
fun onError(e: Throwable)
}
class NetModel {
fun getUserInfo(callback: NetResponse<UserInfo>) {
// 模擬網絡獲取
val dataStr = getStringFromNet()
val info = dataStr.parseJson<UserInfo>()
return callback.onSuccess(info)
}
}
2）ViewModel層
class NetViewModel : ViewModel() {
private val model = NetModel()
private val name = MutableLiveData<String>("")
private val age = MutableLiveData<Int>(0)
private val height = MutableLiveData<Int>(0)
private val weight = MutableLiveData<Int>(0)
fun getUserInfo() {
model.getUserInfo(object : NetResponse<UserInfo> {
override fun onSuccess(data: UserInfo) {
name.postValue(data.name)
age.postValue(data.age)
height.postValue(data.height)
weight.postValue(data.weight)
}
override fun onError(e: Throwable) {
val data = getNetErrorData()
name.postValue(data.name)
age.postValue(data.age)
height.postValue(data.height)
weight.postValue(data.weight)
}
})
}
private fun getNetErrorData(): UserInfo {
return UserInfo(name = "", age = 0, height = 0, weight = 0)
}
fun name(): LiveData<String> = name
fun age(): LiveData<Int> = age
fun height(): LiveData<Int> = height
fun weight(): LiveData<Int> = weight
}
3）View層
class MainActivity : AppCompatActivity() {
private lateinit var viewModel: NetViewModel
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
viewModel = ViewModelProvider(this).get(NetViewModel::class.java)
viewModel.name().observe(this, Observer<String> {
tvName?.text = it
})
viewModel.age().observe(this, Observer<Int> {
tvAge?.text = it.toString()
})
viewModel.height().observe(this, Observer<Int> {
tvHeight?.text = it.toString()
})
viewModel.weight().observe(this, Observer<Int> {
tvWeight?.text = it.toString()
})
btnNet?.setOnClickListener {
viewModel.getUserInfo()
}
}
}
四.Clean架構
1.概述
Clean架構由Robert.C.Martin(Bob大叔)提出，最基礎的Clean架構由Entities(實體層)、Use Cases(用例層)、Interface Adapters(接口適配層)、Frameworks & Drivers(框架驅動層)四部分組成：
- Entities：用於封裝企業業務規則，指業務的核心數據模型和接口，一般情況下不會發生變化，隻有當業務規則改變才會改變實體層。
- Use Cases：用於封裝軟件應用的業務規則，包含實現整個應用所需全部功能的用例，通過調用各種實體的規則實現用例的功能。用例層的改變不會影響實體層，同時外部UI與數據庫的改變也不會影響到用例層。
- Interface Adapters：用於將外部數據轉換為實體層與用例層需要的數據結構或將實體層與用例層返回的數據轉換為外部需要的數據結構。Clean-MVP中Presenter就是在這一層。
- Frameworks & Drivers：由一些框架與工具組成，如數據庫、UI框架等。這層更多的是用於編寫技術細節，而不需要考慮業務邏輯。
Clean架構通過規范層級間的單向依賴關系，從而形成一層包裹一層的層級結構。如下圖所示：
Clean架構的層級並不是固定的。根據不同的業務特點，Clean架構也可有更多的層級(最少四層)。由此可見，Clean架構並非傳統意義上的架構，它更像是一種理念。Clean架構可以與MVC架構、MVP架構、MVVM架構結合形成Clean-MVC架構、Clean-MVP架構、Clean-MVVM架構。谷歌官方借鑒Clean的理念推出Clean-MVVM架構。
Clean架構具有單向依賴、層級分明、數據驅動的優點。因此在Clean架構中，各個層級的代碼邏輯更容易被測試，缺陷與問題更容易被定位，代碼的可讀性得到顯著提升。Clean架構的結構十分復雜。它被稱為洋蔥架構，不僅是因為它層層包裹的結構，也是因為當你意識到需要寫多層模版代碼時，Clean架構會讓你哭泣。同時，Clean架構還存在用例層代碼復用率低、急劇增加的用例導致類膨脹的問題。
2.例子
點擊按鈕從網絡獲取用戶信息，經過解析後展示到界面上。
1）Entities層
data class UserInfo(
var name: String,
var age: Int,
var height: Int,
var weight: Int
)
2）Use Cases層
interface UseCase<T, R> {
fun execute(param: T, callback: R)
}
interface UseCaseCallback<T> {
fun success(data: T)
fun fail(e: Throwable)
}
class GetUserInfoUseCase : UseCase<Unit, UseCaseCallback<UserInfo>> {
private val repository = NetRepository()
override fun execute(param: Unit, callback: UseCaseCallback<UserInfo>) {
repository.getUserInfo(object : NetResponse<UserInfo> {
override fun onSuccess(data: UserInfo) {
callback.success(data)
}
override fun onError(e: Throwable) {
callback.fail(e)
}
})
}
}
3）Interface Adapters層
interface NetResponse<T> {
fun onSuccess(data: T)
fun onError(e: Throwable)
}
class NetRepository {
fun getUserInfo(callback: NetResponse<UserInfo>) {
// 模擬網絡獲取
val dataStr = getStringFromNet()
val info = dataStr.parseJson<UserInfo>()
return callback.onSuccess(info)
}
}
interface IView {
fun setName(name: String)
fun setAge(age: String)
fun setHeight(height: String)
fun setWeight(weight: String)
}
class Presenter(private val view: IView) : UseCaseCallback<UserInfo> {
private val getUserInfoUseCase = GetUserInfoUseCase()
fun getUserInfo() =
getUserInfoUseCase.execute(Unit, this)
override fun success(data: UserInfo) {
view.setName(data.name)
view.setAge(data.age.toString())
view.setHeight(data.height.toString())
view.setWeight(data.weight.toString())
}
override fun fail(e: Throwable) {
val data = getNetErrorData()
view.setName(data.name)
view.setAge(data.age.toString())
view.setHeight(data.height.toString())
view.setWeight(data.weight.toString())
}
private fun getNetErrorData(): UserInfo {
return UserInfo(name = "", age = 0, height = 0, weight = 0)
}
}
4）Frameworks & Drivers層
class MainActivity : AppCompatActivity(), IView {
private val presenter = Presenter(this)
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
btnNet?.setOnClickListener {
presenter.getUserInfo()
}
}
override fun setName(name: String) {
tvName?.text = name
}
override fun setAge(age: String) {
tvAge?.text = age
}
override fun setHeight(height: String) {
tvHeight?.text = height
}
override fun setWeight(weight: String) {
tvWeight?.text = weight
}
}
五.MVI架構
1.概述
MVI架構是MVVM架構的升級版，由Model、View、Intent三部分組成：
- Model：負責存儲視圖的數據和狀態。
- View：負責界面的展示。
- Intent：負責封裝與發送用戶的操作。
MVI架構在MVVM架構的基礎上強調數據的單向流動與狀態的集中管理，保證數據的唯一性。在MVVM架構中三者的調用關系如下圖所示：
在MVVM架構中，View會調用ViewModel執行具體的邏輯操作。而在MVI架構中，用戶對View層的交互會被抽象成Intent。當交互發生時，View會發送對應的Intent到ViewModel中處理，通過Intent隔離View對ViewModel的調用。如下圖所示：
在MVVM架構中，ViewModel內部對View的數據與屬性的維護是分散的，具體表現為每個View都會有一個Data。而在MVI架構中，這些Data將會被整合在一起，形成統一的State，如下圖所示：
在MVI架構中，Model層指的就是State。通過引入State，可以更加方便ViewModel的管理。同時隔離ViewModel對View的調用，如下圖所示：
這樣，原本在MVVM架構中由於雙向綁定引起的代碼耦合問題，在MVI架構中通過引入Intent與State得以解決。同時，架構整體的數據流向更加清晰，如下圖所示：
在MVI架構中，通過狀態集中管理減少瞭模版代碼。通過數據單向流動保證瞭數據流向的一致性，開發者可以更方便的對狀態進行跟蹤與調試。MVI也存在著一些問題，由於狀態集中管理，當頁面功能復雜時，State易膨脹。每次更新狀態時，都需要更新整體的狀態，對內存有一定開銷，而且不支持局部刷新。
2.例子
點擊按鈕從網絡獲取用戶信息，經過解析後展示到界面上。
1）Model層
data class PageState(
val response: PageResponse = PageResponse.Default,
val userInfo: UserInfo = UserInfo()
)
sealed class PageResponse {
class Success<T>(data: T) : PageResponse()
class Fail(e: Throwable) : PageResponse()
object Loading : PageResponse()
object Default : PageResponse()
}
data class UserInfo(
val name: String = "",
val age: Int = 0,
val height: Int = 0,
val weight: Int = 0
)
2）Intent層
sealed class UserIntent {
object GetUserInfo : UserIntent()
object Default : UserIntent()
}
3）ViewModel層
class NetViewModel : ViewModel() {
private val model = NetRepository()
private val state = MutableStateFlow(PageState())
private val intent = MutableStateFlow<UserIntent>(UserIntent.Default)
init {
handleUserIntent()
}
fun state() =
state.asStateFlow()
fun sendIntent(userIntent: UserIntent) =
viewModelScope.launch { intent.emit(userIntent) }
private fun handleUserIntent() =
intent.onEach {
when (it) {
is UserIntent.GetUserInfo -> getUserInfo()
else -> {}
}
}.launchIn(viewModelScope)
private fun getUserInfo() {
state.value = state.value.copy(response = PageResponse.Loading)
model.getUserInfo(object : NetResponse<UserInfo> {
override fun onSuccess(data: UserInfo) {
state.value =
state.value.copy(response = PageResponse.Success(data), userInfo = data)
}
override fun onError(e: Throwable) {
state.value =
state.value.copy(response = PageResponse.Fail(e), userInfo = getNetErrorData())
}
})
}
private fun getNetErrorData(): UserInfo {
return UserInfo(name = "", age = 0, height = 0, weight = 0)
}
}
interface NetResponse<T> {
fun onSuccess(data: T)
fun onError(e: Throwable)
}
class NetRepository {
fun getUserInfo(callback: NetResponse<UserInfo>) {
// 模擬網絡獲取
val dataStr = getStringFromNet()
val info = dataStr.parseJson<UserInfo>()
return callback.onSuccess(info)
}
}
4）View層
class MainActivity : AppCompatActivity() {
private lateinit var viewModel: NetViewModel
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
viewModel = ViewModelProvider(this).get(NetViewModel::class.java)
viewModel.state().onEach {
when (it.response) {
is PageResponse.Success<*> -> {
tvName?.text = it.response
tvAge?.text = it.userInfo.age.toString()
tvHeight?.text = it.userInfo.height.toString()
tvWeight?.text = it.userInfo.weight.toString()
}
else -> {}
}
}.launchIn(lifecycleScope)
btnNet?.setOnClickListener {
viewModel.sendIntent(UserIntent.GetUserInfo)
}
}
}
六.總結
1.從MVC架構到MVI架構
開發者們在早期就意識到數據邏輯、業務邏輯、渲染邏輯要分離，因此引入瞭MVC架構。但由於Android頁面組件的特殊性，導致在實際使用中MVC架構的數據邏輯、業務邏輯與渲染邏輯並沒有完美分離，因此產生瞭MVP架構。MVP架構雖然解決瞭渲染邏輯與數據邏輯的隔離問題，但由於Presenter層需要與View層和Model層雙向通信，導致承載業務邏輯的Presenter層過於臃腫，因此引入瞭MVVM架構。MVVM架構通過綁定的通信方式，解決瞭業務邏輯層由於層級間通信而過於臃腫的問題。隨著時間推移，綁定框架也在不斷發展：從DataBinding到LiveData，再從LiveData到StateFlow。由於當界面UI復雜時，MVVM架構的數據過於分散不易維護，因此產生瞭MVI架構。MVI架構引入瞭虛擬的“用戶層”，框架的數據流動從“用戶層”開始，到“用戶層”結束，單方向流動。
2.從clean code到clean coder
縱觀Android架構的發展歷程，數據邏輯、業務邏輯與渲染邏輯的分離關註點正在從代碼逐漸轉移到用戶，這是一種由“物”向“人”的轉變。
這種轉變在Clean架構也中有所體現。Clean架構的提出者Bob大叔早年間一直致力於保持代碼的整潔與條理清晰，於是出版瞭《Clean Code》。後來，經過探索研究發現，想要保持代碼的“幹凈”，最重要的還是要提升開發者的自身素質，於是誕生瞭《 The Clean Coder》。Clean架構通過復雜細致的分層設計，規范每個層級的功能，通過依賴關系保證瞭代碼的整潔。但每層內代碼的整潔，仍然需要開發者通過代碼素養來保證。隻有保持每一層代碼的整潔，整體代碼才能整潔。
3.MVI架構之後
谷歌官方最早推薦開發者使用MVVM架構，在MVI架構推出後，轉而推薦使用MVI架構。那麼，在MVI架構之後的下一個主流框架又將是什麼呢？這一點恐怕無人知曉。但通過分析可以發現，谷歌官方推薦使用MVI架構，本質上是在推薦狀態集中管理和單向數據流動的開發思想，而這一開發思想正好是響應式編程的基礎。因此可以合理預測下一個主流架構可能就是某個響應式框架。谷歌官方這幾年也一直在開發響應式開發框架Compose，但Compose框架在未來能否取代MVI框架仍然是個未知數。
到此這篇關於Android架構發展進化詳解的文章就介紹到這瞭,更多相關Android架構內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！
推薦閱讀：
- Android內存泄漏的原因及解決技巧
- Vue基礎之MVVM,模板語法和數據綁定
- 詳細聊聊Vue.js中的MVVM
- Android實現MVVM架構數據刷新詳解流程
- Android中RecyclerView實現商品分類功能