跳到主要內容

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


公眾號回復 Compose 獲取安裝包


項目地址：



經過前段時間的 Android Dev Summit ，相信你已經大概了解了 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 官方的架構示例 中 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 官方的架構示例 的主分支已經切換到 MVVM 。在 Android 的 MVVM 架構中，ViewModel 是重中之重，它一方面通過數據倉庫 Repository 獲取數據，另一方面根據獲取的數據更新 View 層的 Activity/Fragment。等等，這句話怎麼聽着這麼耳熟，Presenter 不也是幹了這些事嗎？的確，它們乾的事情都差不多，但是實現上完全不一樣。


以我的開源項目 中的 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 的 之後，正如這篇文章名字一樣，真香。


香的確是香，一切能讓我早下班的都是好東西。在我的某次提交日誌上，我寫下了 消滅 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"， 獲取最新安裝包。


本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?



※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象



※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!



※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化



※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益


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

留言

張貼留言

這個網誌中的熱門文章

有了四步解題法模板，再也不害怕動態規劃！（看不懂算我輸）

導言 動態規劃問題一直是算法面試當中的重點和難點，並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到，這篇文章的目的主要是解釋清楚 什麼是動態規劃 ，還有就是面對一道動態規劃問題，一般的 思考步驟 以及其中的注意事項等等，最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃，或者僅僅只有耳聞，或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 "，如果更準確些，其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中，大家經常會遇到一些系統配置的問題，配置不對，系統就會報錯，這個時候一般都會去 Google 或者是查閱相關的文檔，花了一定的時間將配置修改好。 過了一段時間，去到另一個系統，遇到類似的問題，這個時候已經記不清之前修改過的配置文件長什麼樣，這個時候有兩種方案，一種方案還是去 Google 或者查閱文檔，另一種方案是借鑒之前修改過的配置，第一種做法其實是萬金油，因為你遇到的任何問題其實都可以去 Google，去查閱相關文件找答案，但是這會花費一定的時間，相比之下，第二種方案肯定會更加地節約時間，但是這個方案是有條件的，條件如下： 之前的問題和當前的問題有着關聯性，換句話說，之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中，可以看到的是，上面這兩個條件均滿足，大可去到之前配置過的文件中，將配置拷貝過來，然後做些細微的調整即可解決當前問題，節約了大量的時間。 不知道你是否從這些描述中發現，對於一個動態規劃問題，我們只需要從兩個方面考慮，那就是 找出問題之間的聯繫 ，以及 記錄答案 ，這裏的難點其實是找出問題之間的聯繫，記錄答案只是順帶的事情，利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話，接    動態規劃 算法是通過拆分問題，定義問題狀態和狀態之間的關係，使得問題能夠以遞推（或者說分治）的方式去解決。它的幾個重要概念如下所述。    階段： 對於一個完整的問題過程，適當的切分為若干個相互聯繫的子問題，每次在求解一個子問題...
張貼留言
閱讀完整內容

計算機本地文件快要滅絕了

　　 編者按： 文件是数字世界的基石，是我們基本的工作單位。但是，隨着互聯網的雲化、平台化、服務化，文件日益變得可有可無。這樣一種改變究竟好不好呢？喜歡懷舊的 Simon Pitt 開始回顧各種文件的好處，哪怕這讓他顯得不合時宜。原文發表在 medium 上，標題是：Computer Files Are Going Extinct 　　我喜歡文件。我喜歡對文件重命名、移動、排序，改變它們在文件夾中的显示方式，去備份文件，將之上傳到互聯網，恢復它們，對其進行複製，甚至還可以對文件進行碎片整理。作為信息存儲方式的一種隱喻，在我看來文件是很出色的。我喜歡把文件當作一個工作單位。如果我要寫篇文章，文章會放在文件裏面。如果我要生成圖像，圖像會保存進文件裏面。 　　 謳歌 files.doc 　　文件是擬物化的。這是個很花哨的詞，只是用來表示文件是反映現實物品的一個数字概念。比方說，Word 文檔就像一張紙，躺在你的辦公桌上（desktop）。JPEG 就像一幅畫，等等。它們每個都有一個小圖標，圖標的樣子看起來像它們所代表的現實物品。一堆紙，一個畫框，一個馬尼拉文件夾。真的挺很迷人的。 　　我喜歡文件的一點是，不管裏面有什麼，跟文件的交互方式總是一致的。我上面提到的那些東西——複製、排序、碎片整理——我可以對任何文件進行那些處理。文件可能是圖像、遊戲的一部分、也可能是我最喜歡的餐具清單。碎片整理程序不在乎它是什麼。它不會去判斷內容。 　　自從我開始在 Windows 95 裏面創建文件以來，我就一直都很喜歡文件。但是我注意到我們已經開始慢慢地遠離把文件當作基本工作單位的做法。 Windows95。我的計算機 　　 services.mp3 的興起 　　十幾歲的時候，我開始痴迷於收集和管理数字音樂：我收藏 MP3 文件。一大堆的 128 kbps MP3 文件。如果你足夠幸運，有自己的 CD 刻錄機的話，就可以將它們刻錄到 CD 上，然後在朋友之間傳遞。一張 CD 可以容納 700 MB。這相當於將近 500 張軟盤！ 　　我會仔細端詳我的收藏，然後煞費苦心地給它們添加上 IDv1 和 IDv2 音樂標籤。隨着時間的流逝，大家開始開發可以在雲端自動獲取曲目列表的工具，這樣你就可以檢查和驗證 MP3 的質量。有時候我甚至會去聽那些該死的東西，儘管...
張貼留言
閱讀完整內容

純電動 Mini Cooper SE 將成為中國國產車，年產 16 萬輛

BMW 集團與中國長城汽車合資，將於江蘇建立新廠，專門投入生產 MINI Cooper SE 和部分長城品牌電動車，預計於 2022 年完工並投入生產，每年將可生產 16 萬輛電動車。 靈動可愛的 Mini Cooper，在許多車迷心中都有著特殊的地位，今年 7 月發表了首款純電動版本的 Mini Cooper SE 之後，獲得熱烈迴響，預訂數量已接近 8 萬台，顯示大家對於純電 Mini 的熱愛，因為油電版的 Mini Cooper Countryman 的全球總銷售量也才 3 萬出頭。 Mini Cooper SE 之前公布了官方定價，最低從 27,900 歐元起算，美國售價約 29,900 美元。相比現有的三門款，只貴了一成左右。然而，三年後，中國消費者將有機會買到最便宜的電動 Mini。 電動 Mini Cooper SE 最低價是 27,900 歐元，扣掉全額補助最低可以到 24,400 歐元。 BMW 集團與中國長城汽車集團於 2018 年宣布，將組建合資公司光束汽車，投入在中國的電動車生產計畫，而現在他們正式宣布啟動計畫，於江蘇張家港打造一個新工廠，全部投入電動車的製造，包括了 Mini Cooper SE 和其他長城汽車旗下的電動車。 目前的電動 Mini 只在英國牛津工廠製造，不難想像當產能轉移到中國後，Mini Cooper SE 的價格將有機會進一步調降，來競爭全球最大的電動車市場。這座屬於合資公司光束汽車的新工廠，採用一個新的產銷模式，由 BMW 和長城共同合作開發、設計、製造新產品，但是銷售通路完全沿用原本的品牌渠道。 換句話說，2020 年到 2022 年銷售的電動 Mini，將會是英國製造，而 2022 年後就會有中國製造版本開賣，考量到 Mini 在中國每年約有 30 萬輛的銷售額，同時油電版的 Coutryman 銷量更佔了全球將近五分之一，無怪乎 BMW 會想在最接近主要市場的地方蓋工廠囉。 外型完美復刻油車版 最後，簡單介紹一下 Mini Cooper SE 這台車。Mini 在電動化的路上，盡力保持著跟經典造型一致的設計，畢竟大家愛的就是它的設計。電動版的 Mini 車頭、車身跟車屁股都多了一個黃色的插頭標誌，車頭的氣壩則變成封閉式設計，除此之外，幾乎看不出來差別，連馬達...
張貼留言
閱讀完整內容