Jetpack Compse 實戰 —— 全新的開發體驗

時間 2019-11-17

標籤 jetpack compse 實戰全新開發體驗简体版

原文原文鏈接

公衆號回覆 Compose 獲取安裝包java

項目地址： Wanandroid-Composeandroid

通過前段時間的 Android Dev Summit ，相信你已經大概瞭解了 Jetpack Compose 。若是你尚未據說過，能夠閱讀這篇文章 Jetpack Compose 最新進展。總而言之，Compose 是一個 顛覆性 的 聲明式 UI 框架 ，它的口號就是 消滅 xml 文件！git

儘管 Jetpack Compose 還只是預覽版，API 可能發生變化，缺少足夠的控件支持，甚至不是那麼穩定，但這阻止不了我這顆好奇的心。我在第一時間就上手擼了一款 Compose 版本 Wanandroid 應用，功能也比較簡單，僅僅包括首頁，廣告和最新項目，相似於 Android 原生頁面的 Viewpager + TabLayout 。下面的 gif 展現了應用的基本頁面：github

能夠看出來頁面並非那麼流暢，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

引用一張阮一峯老師的圖，大體是這麼個意思，可是也不必定就徹底都是單向依賴。框架

從荒蕪時代走過來，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 的詳細使用過程和其餘特性，更多信息我推薦下面兩篇文章：

最後

正如 Android 官網 Jetpack 介紹頁所說，Jetpack 能夠幫助開發者更輕鬆的編寫優質應用。的確，隨着應用架構的規範，咱們只須要把精力放在須要的代碼上，加速開發，消除樣板代碼，減小崩潰和內存泄露，構建高質量的強大應用。我想不出來有任何理由不使用 Jetpack 來構建你的應用。而 Compose 必將稱爲 Jetpack 中極其重要的一塊拼圖。

Jetpack Compse ，將來可期！

添加個人微信，加入技術交流羣。

公衆號後臺回覆「compose」，獲取最新安裝包。