公衆号回複
Compose
擷取安裝包
項目位址: Wanandroid-Compose
經過前段時間的 Android Dev Summit ,相信你已經大概了解了 Jetpack Compose 。如果你還沒有聽說過,可以閱讀這篇文章 Jetpack Compose 最新進展 。總而言之,Compose 是一個 颠覆性 的 聲明式 UI 架構 ,它的口号就是 消滅 xml 檔案 !
盡管 Jetpack Compose 還隻是預覽版,API 可能發生變化,缺乏足夠的控件支援,甚至不是那麼穩定,但這阻止不了我這顆好奇的心。我在第一時間就上手撸了一款 Compose 版本 Wanandroid 應用,功能也比較簡單,僅僅包括首頁,廣告和最新項目,類似于 Android 原生頁面的
Viewpager + TabLayout
。下面的 gif 展示了應用的基本頁面:
可以看出來頁面并不是那麼流暢,View 的複用應該是個問題,甚至我也沒發現應該怎麼做下拉重新整理。那麼,Compose 給我們帶來了什麼呢?在解答這個問題之前,我想先來說說 Android 應用架構問題。
荒蕪年代 —— MVC
在我剛入行的時候,可以說是 Android 開發的黃金時代,也可以說是開發者的荒蕪時代。一方面,毫不誇張的說,基本會寫 xml 都能謀得一份工作。另一方面,對于開發者來說,遠遠沒有現在的規範的開發架構。沒記錯的話,我當年的主力開發架構是
xUtils 2
,一個類庫大包幹,從 布局和 ID 綁定,網絡請求,到圖檔展示,ORM 操作,一應俱全。當時的 布局和 ID 綁定還是運作時反射,而不是編譯期注解。很長一段時間以來,Android 連一個官方的網絡庫都沒有。
在架構方面,很多人都是一個 Activity 撸到死,我真的見過上千行zouguolai的 MainActivity 。并且覺得這就是 MVC 架構,實體類 Entity 就是
Model
層,
Activity/Fragment
就是
Controller
層,布局檔案就是
View
層。
但這當真是
MVC
嗎?其實并不是。不管是
MVC
,
MVP
,還是
MVVM
,都應該遵循一個最起碼的原則,表現層和業務層分離 ,也就是 Android 官網給出的 應用架構指南 中強調的 分離關注點 。
Activity/Fragment
既要承擔視圖層的任務,展示和更新 UI,又要處理業務層邏輯,擷取資料等。這并不符合架構設計的基本原則。
正确的 MVC 模式中,Model 層不僅包含實體類 Entity,更重要的作用是處理業務邏輯。View 層負責處理視圖邏輯。而 Controller 就是 Model 和 View 之間的橋梁。橋怎麼建,其實并沒有标準,根據你自己的需求就可以了。
引用一張阮一峰老師的圖,大緻是這麼個意思,但是也不一定就完全都是單向依賴。
從荒蕪時代走過來,MVC 總算有點分層的味道在裡面了,分離了視圖層和業務層。但是 View 層和 Model 層的依賴關系,造成代碼耦合,終将導緻 Activity 日益臃腫。那麼有沒有辦法将 View 層和 Model 層徹底分離,做到視圖層和模型層完全分離呢? MVP 就應運而生了。
青銅年代 —— MVP
依舊是阮一峰老師的圖檔:
相較于 MVC ,MVP 用
Presenter 層
代替了
Controller 層
,且
View 層
和
Model 層
完全分離,依靠 Presenter 進行通信 。
想象一個擷取使用者資訊的場景。
IView
接口中定義了一系列視圖層接口 ,View 層(Activity)實作
IView
接口中相應視圖邏輯。 View 層通過持有的 Presenter 處理業務邏輯,即請求使用者資訊。一般情況下,Presenter 也不直接處理業務邏輯,而是通過 Model 層,例如資料倉庫 Repository, 來擷取資料,避免 Presenter 重蹈覆轍,日漸臃腫。同時,Presenter 層也是持有 VIew 的,擷取使用者資訊之後再轉發給 View 。
總結一下,MVP 中 View 和 Model 完全解耦,通過 Presenter 通信。View 和 Presenter 共同處理視圖層邏輯,Model 層負責業務邏輯。
在 Github 上 Android 官方的架構示例 architecture-samples 中 MVP 作為主分支堅挺了很久。我最初也是根據這個官方示例改造了自己的 MVP 架構,并且使用了很長時間。但是 MVP 作為一款面向接口程式設計的架構,随着業務的複雜程度不斷加大,有種遍地都是接口的既視感,實在顯得有點繁瑣。
另外一點,Presenter 的職責邊界不夠清晰,它除了承擔調用 Model 層擷取業務邏輯之外,還要控制 View 層處理 UI。用下面一段代碼表示一下:
class LoginPresenter(private val mView: LoginContract.View) : LoginContract.Presenter {
......
override fun login(userName: String, passWord: String) {
CoroutineScope(Dispatchers.Main).launch {
val result = WanRetrofitClient.service.login(userName, passWord).await()
with(result) {
if (errorCode == -1) mView.loginError(errorMsg) else mView.login(data)
}
}
}
}
一旦 View 層發生任何變化,Presenter 層也要做出相應改動。雖然 View 和 Model 之間解耦了,但是 View 和 Presenter 卻耦合了。理想情況下,Presenter 層應該僅負責資料的擷取,View 層自動觀察資料的變化。于是,MVVM 來了。
黃金時代 —— MVVM
Google 官圖鎮樓 。
MVP 風光早已不在, Android 官方的架構示例 architecture-samples 的主分支已經切換到 MVVM 。在 Android 的 MVVM 架構中,ViewModel 是重中之重,它一方面通過資料倉庫 Repository 擷取資料,另一方面根據擷取的資料更新 View 層的 Activity/Fragment。等等,這句話怎麼聽着這麼耳熟,Presenter 不也是幹了這些事嗎?的确,它們幹的事情都差不多,但是實作上完全不一樣。
以我的開源項目 Wanandroid 中的
LoginViewModel
為例:
class LoginViewModel(val repository: LoginRepository) : BaseViewModel() {
private val _uiState = MutableLiveData<LoginUiModel>()
val uiState: LiveData<LoginUiModel>
get() = _uiState
fun loginDataChanged(userName: String, passWord: String) {
emitUiState(enableLoginButton = isInputValid(userName, passWord))
}
// ViewModel 隻處理視圖邏輯,資料倉庫 Repository 負責業務邏輯
fun login(userName: String, passWord: String) {
viewModelScope.launch(Dispatchers.Default) {
if (userName.isBlank() || passWord.isBlank()) return@launch
withContext(Dispatchers.Main) { showLoading() }
val result = repository.login(userName, passWord)
withContext(Dispatchers.Main) {
if (result is Result.Success) {
emitUiState(showSuccess = result.data,enableLoginButton = true)
} else if (result is Result.Error) {
emitUiState(showError = result.exception.message,enableLoginButton = true)
}
}
}
}
private fun showLoading() {
emitUiState(true)
}
private fun emitUiState(
showProgress: Boolean = false,
showError: String? = null,
showSuccess: User? = null,
enableLoginButton: Boolean = false,
needLogin: Boolean = false
) {
val uiModel = LoginUiModel(showProgress, showError, showSuccess, enableLoginButton,needLogin)
_uiState.value = uiModel
}
data class LoginUiModel(
val showProgress: Boolean,
val showError: String?,
val showSuccess: User?,
val enableLoginButton: Boolean,
val needLogin:Boolean
)
}
可以看到,ViewModel 中是沒有 View 的引用的,View 通過可觀察的 LIveData 來觀察資料變化,基于觀察者模式做到和 ViewModel 完全解耦。
資料驅動視圖 ,這是 Jetpack MVVM 推崇的一個重要原則。其基本資料流如下所示 :
- 資料層 Repository 負責從不同資料源擷取和整合資料,基本負責所有的業務邏輯
- ViewModel 持有 Repository,擷取資料并驅動 View 層更新
- View 持有 ViewModel,觀察 LiveData 攜帶的資料,資料驅動 UI
曾經和一些開發者讨論過這樣一個問題,** 不使用 DataBinding 還算是 MVVM 嗎 ?** 我認為 MVVM 的核心從來不在于 DataBinding 。DataBinding 隻是可以幫助我們将 資料驅動視圖 做到極緻,順便還可以雙向綁定。
要說到對 Jetpack MVVM 中最不滿意的一塊,那非 DataBinding 莫屬了。在我狹隘的認為 DataBinding 就是一個在 xml 裡面寫邏輯代碼的反人類的庫時,我是堅決反對在任何項目中引入它的。固執己見的時候就容易走進誤區,在閱讀 KunminX 的 重學安卓:從 被反對 到 真香 的 Jetpack DataBinding! 之後,正如這篇文章名字一樣,真香。
香的确是香,一切能讓我早下班的都是好東西。在我的某次送出日志上,我寫下了 消滅 Adapter 幾個字,那時我剛用 DataBinding 消滅了大部分 RecyclerView 的 Adapter 。可是在送出之後,我的良心惴惴不安,我追究還是在 xml 檔案裡寫邏輯代碼了,難道這真的不反人類嗎?
未來可期 —— Jetpack Compose
現在你應該可以了解我對 Jetpack Compose 的執念了。抛去其他特性,在我看來,它完美的解決了 資料驅動視圖 的問題,我再也不需要使用 DataBinding 了。
簡單代碼展示一下 Compose 的用法。下面的代碼描繪的是首頁 Tab 下的文章清單。
@Composable
fun MainTab(articleUiModel: ArticleViewModel.ArticleUiModel?) {
VerticalScroller {
FlexColumn {
inflexible {
HeightSpacer(height = 16.dp)
}
flexible(1f) {
articleUiModel?.showSuccess?.datas?.forEach {
ArticleItem(article = it)
}
articleUiModel?.showError?.let { toast(App.CONTEXT, it) }
wenjian
articleUiModel?.showLoading?.let { Progress() }
}
}
}
}
這種寫法叫做 聲明式程式設計 ,會用 Flutter 的同學應該很熟悉。方法參數
ArticleUiModel
就是資料實體類,直接根據資料 ArticleUiModel 建構 UI 。說的大白話一點,就是給你長方形的長和寬了,讓你畫個長方形出來。最後加上
@Compose
注解,就是一個可用的 UI 元件了。仔細看代碼,裡面還用了兩個 UI 元件 ,
ArticleItem
和
Progress
,代碼就不貼出來了。分别是文章清單的 item 項目 和加載進度條。
那麼,資料如何更新呢?最簡單的方式是使用
@Model
注解。
@Model
data class ArticleUiModel(){
......
}
對,就是這麼簡單。
@Model
注解會自動把你的資料類變成可觀察對象,隻要 ArticleUIModel 發生變化,UI 就會自動更新。
但是我在實際開發中結合 LiveData 使用時,好像表現的不是那麼正常。後來在 Medium 上無意中看到了解決方案,針對 LiveData 做了特殊處理 :
// general purpose observe effect. this will likely be provided by LiveData. effect API for
// compose will also simplify soon.
fun <T> observe(data: LiveData<T>) = effectOf<T?> {
val result = +state<T?> { data.value }
val observer = +memo { Observer<T> { result.value = it } }
+onCommit(data) {
data.observeForever(observer)
onDispose { data.removeObserver(observer) }
}
result.value
}wenjian
在 Activity/Fragment 中觀測 LiveData 即可:
class MainActivity : BaseVMActivity<ArticleViewModel>() {
override fun initView() {
setContent {
+observe(mViewModel.uiState)
WanandroidApp(mViewModel)
}
}
override fun initData() {
mViewModel.getHomeArticleList()
}
}
這樣 View 層就可以自動觀察 LiveData 所包含的值了。
沒有 xml,沒有 DataBinding,一切看起來稱心如意多了。但就是 UI 體驗有那麼一點糟心,你可以在公衆号背景回複 Compose 安裝體驗一下。由于還是早期的預覽版,這也是可以了解的。我相信,等到釋出 Release 版本的時候,一定足以完全代替原聲的 View 體系。
本文并沒有詳細介紹 Jetpack Compose 的詳細使用過程和其他特性,更多資訊我推薦下面兩篇文章:
- Jetpack Compose 最新進展
- Jetpack Compose 新的嘗試
最後
正如 Android 官網 Jetpack 介紹頁所說,Jetpack 可以幫助開發者更輕松的編寫優質應用。的确,随着應用架構的規範,我們隻需要把精力放在需要的代碼上,加速開發,消除樣闆代碼,減少崩潰和記憶體洩露,建構高品質的強大應用。我想不出來有任何理由不使用 Jetpack 來建構你的應用。而 Compose 必将稱為 Jetpack 中極其重要的一塊拼圖。
Jetpack Compse ,未來可期 !
添加我的微信,加入技術交流群。
公衆号背景回複 “compose”, 擷取最新安裝包。