前言
Compose 正式版在七月份的尾巴如期而至,我也寫了一份 Compose 版本的專案,Demo其實比較簡單,

地址:github.com/mCyp/Hoo,
這已經是它的第三個版本:
- 第一版:Kotlin + Jetpack
- 第二版:Flutter
- 第三版:Compose + Jetpack
還記得去年 Compose 推出的時候,我就在團隊內部分享了一次 Compose,當時為了展示一個 Preview 的功能,差點卡到下不了臺,

其實寫代碼的時候速度還可以,但是投屏時屬實有些尷尬,
一、技術堆疊使用
Hoo 功能雖小,但五臟俱全,

整個專案的技術堆疊就是 Compose + Jetpack,由于 Google 大力推行 Android Jetpack,使得我們以后開發 Android 的技術堆疊越來越清晰,以后的趨勢可能是掌握好 Jetpack 就可以幫助我們輕松的開發應用,
在使用 Compose 的時候,發現 Lottie 對 Compose 的支持速度還挺快,于是毫不猶豫的使用了 Lottie,
效果還不錯~
二、入門必看
官方檔案的地址: 官方入門
官方的Sample: Github Samples

這是我在官網截的圖,從圖中來看,入門教程支持中文,目錄結構也比較清晰,中文開發者入門還是比較輕松的,
‘漁’有了,很多人還有諸如以下的疑惑:
- 為什么要用 Compose 代替 Android 原有的 View 結構?
- 什么是宣告式編程?
- Compose開發有什么優缺點?
我來為大家一一解答,
1. xml構建UI之痛
首先,我們得明確一點,傳統的 Android View 結構是基于面向物件,
從我們開始寫安卓開始,我就使用 xml 構建 UI,等進入 Activity 或者 Fragment 的生命周期,系統再幫我們決議 xml 檔案,一層層的搭建 Android View 結構樹,等到使用的時候,會有兩個問題:
第一,findViewById 這種方式查詢 View 比較低效,每次都需要通過遍歷 Android View 樹獲取指定的View,
第二,對于自定義View來說,我們可能需要管理一大堆的 get 和 set 方法,來管理 View 的各種狀態,在一些場景下,手動管理各種 View 的 add 和 remove 也比較麻煩,所以,一些初中級的 Android 開發談起自定義View總是眉頭緊皺,
既然苦于 Android 既有 View 結構久矣,那 Google 自然就做了順水推舟的事,Compose 也就應運而生,
2. 什么是宣告式編程?
過去幾年,我們在 Android 領域總是聽到關于 宣告式UI 的動態,先有大哥 Flutter,后有 Compose 小弟,為什么整 Android 行業都開始向 宣告式UI 轉變了呢?
也許從代碼中找到一些答案,比如我們要去構建一個如下界面,并要求,點擊第一個 Button,移除第二個 Button:

1.傳統寫法
構建xml布局:
<LinearLayout>
<ImageView/>
<TextView/>
<Button/>
<Button/>
</LinearLayout>
之后在 Activity 中創建各種 View 物件,通過命令式寫法操作這些物件去設定圖片,文字和點擊事件等,當點擊第一個 Button,我們還需要獲取外層的 LinearLayout 物件,動態的 remove 第二個子 Button,
2.Compose寫法
Compose 是一種宣告式UI,你需要把界面描述出來,即使界面結構發生變化,你也不需要操縱原來的View,你需要做的是描述狀態發生變化后的界面是什么樣子的,以代碼為例:
@Composable
fun WelcomePage(){
val state = remember{ mutableStateOf(true)} // ... 獲取資料
Column(){
Image(...)
Text(...)
Button(...) // 點擊的時候設定state
if(state.value){
Button(...)
}
}
}
上面的代碼中,很清晰的告訴我們,這是一個 Column,對應著原來的 LinearLayout,里面有 Image、Text 和 Button,當狀態 state 的值是 true 的時候,會展示另外一個 Button,狀態 state 的修改是通過第一個 Button 的點擊事件設定的,這里我沒有寫出來,
Compose 中的重組意味著重建,當 State 發生變化時,描述UI的 @Compose 方法會發生重組,用一張圖來描述添加 View 的情況:

當然,整個界面重組畢竟是個很高昂的操作,對應著時間、計算能力和電池的消耗,Compose 當然做了優化,只會對必要 @Compose 方法進行重組,比如,上述的 state 發生變化的時候,只會重建 ViewGroup 和 Text2,
三、為什么要選擇Compose?
宣告式 UI 的大哥 Flutter 已經出道很久了,再學習 Compose 還有意義嗎,Flutter 還是 Compose?
我先拋出我的結論:
- 如果你想運用到實際的生產環境中,Flutter 肯定是更好的選擇,因為更多的人幫你踩過了坑,
- 如果你想
Kotlin一把梭,只是學習嘗鮮,結合Android Jetpack,Compose可以很好的作為你的技術儲備,
簡單的聊聊 Compose 中還不錯的地方,
1. Android開發習慣的繼承
相信很多同學都有這樣的習慣:
- 使用 Kotlin 開發
- 必須協程
- 復雜的布局會使用
ConstraintLayout - ...
是的,這些東西我們依然在 Compose 中運用,從而降低我們的上手難度,
2. Android Jetpack 的支持
在 Compose 剛剛發布的時候,Android Jetpack 中的很多其他庫都第一時間給予了 Compose 支持,從而豐富了 Compose 的開發生態,
目前,能夠直接在 Compose 上使用的 Jetpack 庫有:
- Navigation
- Paging
- ViewModel
- LiveData
- hilt
- lifecycle
理論上來講,Android Jetpack 上跟 UI 不相關的庫 Compose 應該都是支持的,在我寫的 Hoo 中,就使用了Paging、Navigation、ViewModel 和 LiveData等 Android Jetpack 庫,再有協程和 Kotlin 的加持,整個開發程序中輕松不少!
3. 更少的代碼
Compose 可以使我們更加專注于 UI 的開發,宣告式UI 可以顯著的減少方法數和包體積,在谷歌官方的 《Jetpack Compose 使用前后對比》 一文說道:
Tivi應用在使用了 Compose 后,我們發現 APK 大小縮減了 41%,方法數減少了 17%
其實這些都是可以預見的,比如更加簡單的影片和觸摸事件的 Api,
4. Preview
Compose支持代碼的Preview,如圖:

Compose 代碼寫完后,可以直接在右邊預覽,但是更新速度差點意思,不如 Flutter 的熱多載方便,
5. 其他
其他的一些點可能就跟 Flutter 有點像了,
-
Compose 的主題原生支持黑夜模式,開發者定制主題的時候提供兩套顏色即可,想起之前,起點讀書支持黑夜模式可是花了很大的功夫,
-
通過
Scaffold,可以輕松集成很多Material組件,比如Topbar、FloatingActionButton和BottomNavigationBar等,這些都可以幫助我們節省出不少的時間, -
另外,在 Compose 中不能輕松實作效果的時候,借助于
AndroidView,可以去呼叫Android原生View,
四、吐槽
當然了,Compose 目前還有一些槽點,
1. 生態不豐富
Compose 作為剛出來的 UI 框架,雖然 Android Jetpack 第一時間給予了支持,但生態不豐富這一點是毋庸置疑的,
一些非基礎的常用UI,Google 給出了一些解決方案,比如 【accompanist】,它可以幫助你解區域分常用的庫,
如果沒有你想要的輪子,你只能選擇自己造或者參考 Android 原生控制元件,不過這從側面也說明了一些機會,當你覺得缺少什么的時候,寫出好的開源庫的機會來臨了~
2. 學習資源少
在學習 Flutter 的時候,遇到某種效果,可能谷歌一下,就有答案了,
但在現階段的 Compose 中,大概率要自己動手~
3. 導航
作為官方指定的導航 - Navigation,在非 Compose 代碼中集成是支持頁面之間的過渡影片的,在 Compose 中目前還是不支持的(現在看了一下,有支持的庫了),
Navigation 檔案中說明是可以記錄頁面狀態的,但就實際使用而言,有的頁面記錄狀態還是有問題的,比如,純粹使用 Paging + LazyColumn,當頁面切換時,會記錄當前頁面位置,當加上 Header 就不行了,
當然了,也有可能是我的使用姿勢問題,
最后
第一次寫 Compose 專案,難免會有小問題,歡迎指正,感謝~
轉載請註明出處,本文鏈接:https://www.uj5u.com/yidong/294501.html
標籤:其他
上一篇:Flutter版聚合廣告插件
