Android架構發(fā)展進化詳解
一.MVC架構
1.概述
MVC架構是第一個應用于Android開發(fā)的成熟架構,由Model、View、Controller三部分組成:
- Model:負責數據的存儲及相關邏輯。
- View:負責界面展示。
- Controller:負責業(yè)務邏輯。
MVC架構將代碼邏輯分成了數據邏輯、渲染邏輯、業(yè)務邏輯三部分,三部分邏輯分別封裝在Model層、View層、Controller層。理想條件下,三者呈單向調用,如下圖所示:
但實際上,由于Android中負責頁面展示的組件(Activity或Fragment)同時承擔了View層和Controller層兩部分的職責,導致MVC架構在實際使用中退化。退化后的MVC架構如下圖所示:
在一些業(yè)務場景中,由于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:負責業(yè)務邏輯。
MVP架構也將代碼邏輯分成了數據邏輯、渲染邏輯、業(yè)務邏輯三部分。與MVC架構不同的是,在MVP架構中,負責業(yè)務邏輯的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:負責業(yè)務邏輯。
MVVM架構是MVP架構的簡化版,它同樣的解決了View層與Model層的隔離問題。不同于MVP架構中的View層與Presenter層之間的雙向通信,MVVM架構采用了一種View層與ViewModel層綁定的方式,當ViewModel層中的UI數據或屬性發(fā)生變化時,View層的UI會跟隨一起變化,這樣原本Presenter層中操作View層接口的邏輯通過綁定的方式被簡化,層級變得更加輕量,簡化后的Presenter層與View層之間只存在數據驅動的關系,Presenter層被簡化成了ViewModel層。三個層級的調用關系如下圖所示:
在MVVM架構的早期發(fā)展中, 開發(fā)者們使用谷歌官方的DataBinding框架實現數據與視圖的綁定,但DataBinding框架使用復雜,且每當有一處代碼需要修改,就會聯動修改多處代碼。后來,谷歌官方推薦使用Jetpack組件集中的LiveData+ViewModel。通過使用LiveData+ViewModel,大大減少了在使用MVVM架構中模版代碼的編寫。再后來,為了更好的在協程中使用MVVM架構,以及更方便的編寫流式代碼,谷歌官方推薦使用StateFlow。
MVVM架構既做到了View層與Model層的隔離,又保證了ViewModel層的簡潔不臃腫。View層與ViewModel層的交互完全依賴數據驅動,方便層級的邏輯復用與測試以及多人的協作開發(fā)。但同時,由于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:用于封裝企業(yè)業(yè)務規(guī)則,指業(yè)務的核心數據模型和接口,一般情況下不會發(fā)生變化,只有當業(yè)務規(guī)則改變才會改變實體層。
- Use Cases:用于封裝軟件應用的業(yè)務規(guī)則,包含實現整個應用所需全部功能的用例,通過調用各種實體的規(guī)則實現用例的功能。用例層的改變不會影響實體層,同時外部UI與數據庫的改變也不會影響到用例層。
- Interface Adapters:用于將外部數據轉換為實體層與用例層需要的數據結構或將實體層與用例層返回的數據轉換為外部需要的數據結構。Clean-MVP中Presenter就是在這一層。
- Frameworks & Drivers:由一些框架與工具組成,如數據庫、UI框架等。這層更多的是用于編寫技術細節(jié),而不需要考慮業(yè)務邏輯。
Clean架構通過規(guī)范層級間的單向依賴關系,從而形成一層包裹一層的層級結構。如下圖所示:
Clean架構的層級并不是固定的。根據不同的業(yè)務特點,Clean架構也可有更多的層級(最少四層)。由此可見,Clean架構并非傳統(tǒng)意義上的架構,它更像是一種理念。Clean架構可以與MVC架構、MVP架構、MVVM架構結合形成Clean-MVC架構、Clean-MVP架構、Clean-MVVM架構。谷歌官方借鑒Clean的理念推出Clean-MVVM架構。
Clean架構具有單向依賴、層級分明、數據驅動的優(yōu)點。因此在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:負責存儲視圖的數據和狀態(tài)。
- View:負責界面的展示。
- Intent:負責封裝與發(fā)送用戶的操作。
MVI架構在MVVM架構的基礎上強調數據的單向流動與狀態(tài)的集中管理,保證數據的唯一性。在MVVM架構中三者的調用關系如下圖所示:
在MVVM架構中,View會調用ViewModel執(zhí)行具體的邏輯操作。而在MVI架構中,用戶對View層的交互會被抽象成Intent。當交互發(fā)生時,View會發(fā)送對應的Intent到ViewModel中處理,通過Intent隔離View對ViewModel的調用。如下圖所示:
在MVVM架構中,ViewModel內部對View的數據與屬性的維護是分散的,具體表現為每個View都會有一個Data。而在MVI架構中,這些Data將會被整合在一起,形成統(tǒng)一的State,如下圖所示:
在MVI架構中,Model層指的就是State。通過引入State,可以更加方便ViewModel的管理。同時隔離ViewModel對View的調用,如下圖所示:
這樣,原本在MVVM架構中由于雙向綁定引起的代碼耦合問題,在MVI架構中通過引入Intent與State得以解決。同時,架構整體的數據流向更加清晰,如下圖所示:
在MVI架構中,通過狀態(tài)集中管理減少了模版代碼。通過數據單向流動保證了數據流向的一致性,開發(fā)者可以更方便的對狀態(tài)進行跟蹤與調試。MVI也存在著一些問題,由于狀態(tài)集中管理,當頁面功能復雜時,State易膨脹。每次更新狀態(tài)時,都需要更新整體的狀態(tài),對內存有一定開銷,而且不支持局部刷新。
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架構
開發(fā)者們在早期就意識到數據邏輯、業(yè)務邏輯、渲染邏輯要分離,因此引入了MVC架構。但由于Android頁面組件的特殊性,導致在實際使用中MVC架構的數據邏輯、業(yè)務邏輯與渲染邏輯并沒有完美分離,因此產生了MVP架構。MVP架構雖然解決了渲染邏輯與數據邏輯的隔離問題,但由于Presenter層需要與View層和Model層雙向通信,導致承載業(yè)務邏輯的Presenter層過于臃腫,因此引入了MVVM架構。MVVM架構通過綁定的通信方式,解決了業(yè)務邏輯層由于層級間通信而過于臃腫的問題。隨著時間推移,綁定框架也在不斷發(fā)展:從DataBinding到LiveData,再從LiveData到StateFlow。由于當界面UI復雜時,MVVM架構的數據過于分散不易維護,因此產生了MVI架構。MVI架構引入了虛擬的“用戶層”,框架的數據流動從“用戶層”開始,到“用戶層”結束,單方向流動。
2.從clean code到clean coder
縱觀Android架構的發(fā)展歷程,數據邏輯、業(yè)務邏輯與渲染邏輯的分離關注點正在從代碼逐漸轉移到用戶,這是一種由“物”向“人”的轉變。
這種轉變在Clean架構也中有所體現。Clean架構的提出者Bob大叔早年間一直致力于保持代碼的整潔與條理清晰,于是出版了《Clean Code》。后來,經過探索研究發(fā)現,想要保持代碼的“干凈”,最重要的還是要提升開發(fā)者的自身素質,于是誕生了《 The Clean Coder》。Clean架構通過復雜細致的分層設計,規(guī)范每個層級的功能,通過依賴關系保證了代碼的整潔。但每層內代碼的整潔,仍然需要開發(fā)者通過代碼素養(yǎng)來保證。只有保持每一層代碼的整潔,整體代碼才能整潔。
3.MVI架構之后
谷歌官方最早推薦開發(fā)者使用MVVM架構,在MVI架構推出后,轉而推薦使用MVI架構。那么,在MVI架構之后的下一個主流框架又將是什么呢?這一點恐怕無人知曉。但通過分析可以發(fā)現,谷歌官方推薦使用MVI架構,本質上是在推薦狀態(tài)集中管理和單向數據流動的開發(fā)思想,而這一開發(fā)思想正好是響應式編程的基礎。因此可以合理預測下一個主流架構可能就是某個響應式框架。谷歌官方這幾年也一直在開發(fā)響應式開發(fā)框架Compose,但Compose框架在未來能否取代MVI框架仍然是個未知數。
到此這篇關于Android架構發(fā)展進化詳解的文章就介紹到這了,更多相關Android架構內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
Android中src和background的區(qū)別詳解
這篇文章主要介紹了Android中src和background的區(qū)別詳解的相關資料,需要的朋友可以參考下2016-09-09將Eclipse工程轉Android Studio工程的步驟與注意事項
這篇文章主要給大家介紹了將Eclipse工程轉Android Studio工程的方法步驟,并給大家分享了其中的一些注意事項,文中將實現的步驟一步步介紹的非常詳細,需要的朋友們可以參考借鑒,下面隨著小編來一起學習學習吧。2017-11-11Android編程使用內容提供者方式(ContentProvider)進行存儲的方法
這篇文章主要介紹了Android編程使用內容提供者方式進行存儲的方法,涉及Android內容提供者的創(chuàng)建,配置及針對數據的增刪改查等操作技巧,需要的朋友可以參考下2016-01-01基于Android 監(jiān)聽ContentProvider 中數據變化的相關介紹
本篇文章小編為大家介紹,基于Android 監(jiān)聽ContentProvider 中數據變化的相關介紹。需要的朋友參考下2013-04-04Android實現類似IOS右滑返回的效果(原因分析及解決辦法)
這篇文章主要介紹了Android實現類似IOS右滑返回的效果,非常不錯,具有參考借鑒價值,需要的朋友參考下2017-03-03Android tabLayout+recyclerView實現錨點定位的示例
這篇文章主要介紹了Android tabLayout+recyclerView實現錨點定位的示例,小編覺得挺不錯的,現在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2018-08-08