Jetpack Compose | 聲明式 UI 編程的革命

1、建立 Jetpack Compose 項目

1.下載 AndroidStudio

下載地址 developer.android.google.cn/studio/prev… ，這裏下載的是 2020.3.1 版的AndroidStudio 。android

2.建立 Compose 項目

AndroidStudio 中選擇新建項目 New Project，web

你能夠看到預覽版的 Empty Compose Activity，選擇此欄能夠建立一個空的 Compose 項目。編程

而後填寫一下項目的基本信息，本項目是 ComposeUnit。markdown

3.運行項目

通過一系列的自動下載和構建後，點擊運行後，界面以下：app

2、初始 Jetpack Compose 項目結構

1.目錄結構

其實項目結構自己和普通的 AndroidStudio 項目並無什麼區別，都是根據 gradle 構建的 Android 項目。函數

在目錄結構上，最大的不一樣點是在 res 目錄下，你看不到 layout 佈局文件了。不由感嘆， Android 十幾代的風風雨雨，一直未能撼動 xml 佈局大人的尊位。現在 Compose 的到來，彷彿揭竿而起，宣佈着: 「大人，時代變了....." .工具

2. gradle 與相關依賴

默認建立的項目 gradle 版本爲 6.8.2。oop

com.android.tools.build 版本爲 gradle:7.0.0；org.jetbrains.kotlin 版本爲 1.4.30，官網說這個版本須要 1.4.21 及以上。佈局

根據這些 gradle 配置，不在預覽版的 AndroidStudio 中你也能夠玩 Compose。gradle

3.源碼結構

目前源碼中只有 MainActivity.kt 文件，以及 ui.theme 中的一些主題相關文件。下面就來看看源碼中進行了哪些操做吧。

3、初始 Jetpack Compose 項目源碼簡看

1. MainActivity.kt

在 Android 中，首先天然要看入口的 Acrivity。在AndroidManifest.xml 文件中能夠看出，入口的 Acrivity 爲 MainActivity。

首先要明白，是誰革了 xml 佈局大人 的命。在 Activity 中必需要設置 View 才能進行展示，這裏 AppCompatActivity 仍是曾經那個androidx.appcompat.app 包中的 AppCompatActivity，他是清白的。

接下來看到 setContent 方法，就已經叛變了。以下代碼，能夠看出他是 AppCompatActivity 的 拓展方法。若是你不瞭解 Kotlin，看到一堆的 {}，估計會抓狂。在源碼中能夠看出， setContent 方法的第二個入參是一個函數對象，Kotlin 語法規定：若是函數的最後一個入參是函數對象，則能夠寫在() 外側，若是() 中無參數，則 () 可省略。因此這裏能夠肯定後面的 ComposeUnitTheme 那一坨本質上是一個函數對象。

2. 應用主題 ComposeUnitTheme

以下是 ui.theme.Theme.kt 中的代碼，其中定義了一個 ComposeUnitTheme 的方法，看到方法和參數的命名也是醉了，居然開頭是大寫的，這也許是爲了更好地區分而違背命名規範吧。能夠看到 ComposeUnitTheme 方法中被 @Composable 註解，在 setContent 第二入參中也有 @Composable 註解。從這裏能夠看出一點端倪，也許在 Compose 中並無相似於 Flutter#Widget 的類，對標的是 @Composable 的註解方法。

private val DarkColorPalette = darkColors(
        primary = Purple200,
        primaryVariant = Purple700,
        secondary = Teal200
)

private val LightColorPalette = lightColors(
        primary = Purple500,
        primaryVariant = Purple700,
        secondary = Teal200
)

@Composable
fun ComposeUnitTheme(darkTheme: Boolean = isSystemInDarkTheme(), content: @Composable() () -> Unit) {
    val colors = if (darkTheme) {
        DarkColorPalette
    } else {
        LightColorPalette
    }

    MaterialTheme(
            colors = colors,
            typography = Typography,
            shapes = Shapes,
            content = content
    )
}
複製代碼

上面的 ComposeUnitTheme 中有兩個入參 darkTheme 和 被 @Composable 標識 的函數對象。以下，在調用時能夠傳入參數，就代表使用 darkTheme ，並且不難分析出 Surface 也是 被 @Composable 標識 的函數。

能夠跟進看一下，他是 androidx.compose.material 中提供的 @Composable 方法，它最後的入參還是 被 @Composable 標識 的函數對象。若是這裏把 content 改成 child ,估計你可能會會心一笑。

最後傳入的是 Greeting("toly") 這個 被 @Composable 標識 的函數。括號裏的入參會被 Text 接收。

也不難猜到 Text 自己也是一個 被 @Composable 標識 的函數。被定義在 androidx.compose.material 中。

因此如今我應該能夠把 被 @Composable 標識 的函數 ≈ 組件 了吧。官方會給一些內置的組件使用，如 Scaffold、Column 、Row、Image、Text 等，而自定義組件就至關於自定義一個 @Composable 註解 的方法。這樣和 Flutter 的用法比較一下，能夠感受這很 Flutter 。

3.關於預覽

Flutter 的一個很是方便的功能是熱重載，代碼中的改動，可以很方便的同步到設備中。Compose 貌似並無這樣的功能，不過在右側能夠打開預覽面板，在 DefaultPreview 註解下的組件能夠被預覽，預覽界面在更改時能夠同步。感受否則 Flutter 強大，但有這，也不錯，比不斷重啓要好。但 Flutter 不支持預覽，也挺尷尬，二者半斤八兩吧。

4、 Jetpack Compose 的革命

估計到這來，就開始有好事者來比較 Flutter 和 Compose 哪一個好，問該學哪一個。Flutter 會不會被 Compose 替代？張風捷特烈 都在看 Compose 了，Flutter 是否是要涼了？ Compose 有沒有將來，compose 的組件是基於 Kotlin 的方法，Java 會不會被 Kotlin 完全取代？我只想說：給爺滾！。

首先 Compose 和 Flutter 是同一革命陣營的戰友，要清楚他們革的是誰的命，革的是命令式的 UI 編程，革的是 xml 佈局大人 的命。有了 Flutter 的基礎，對 Compose 的上手會更快一些，理解上也會更深入，若是直接從命令式 UI 編程直接到 Compose ，你將經歷一種思想的轉變，這不管是去學 Flutter 仍是 Compose 都沒法避免的，思想這東西，別人是很難灌輸給你的。

其次二者的定位不一樣， Compose 目前而言，只是針對 Android 的聲明式 UI 工具包。而 Flutter 是跨平臺，現在能夠說在跨平臺中已經小有成就。 Compose 也許將來會朝着跨平臺發展，但 Flutter 近水樓臺先得月，通過兩年多的發展，已具有 天時、地利、人和 ，移動端的生態已經比較完善了。

對於 Compose 的將來發展，重點仍是看生態。但願 Compose 穩定版能夠早日到來，我就能夠揮淚高呼："再見了，xml 佈局大人"。到時 ComposeUnit 項目定當獻上，爲您佈道送行。Compose 有 Kotlin 加持，仍是聲明式 UI , 我仍是很感興趣的，固然在我內心 Flutter 是永遠滴神。至於問 Java OR Kotlin 的，都 2021 年了，您老還不會 Kotlin ?

最後想要說一句，既然是 革命，一定會有一批頑固派搖擺不定或進行阻擋。其實也理所應當，利益相關，誰也不想跳出本身的溫馨圈，去到另外一個不精通的地域去發展，或去涉足一個前途未卜的方向。也並非全部的 革命都會成功，不是全部的先驅都會留名。但變革必定會產生思想層面的影響。就像戊戌變法和百日維新，新的思想一旦萌發，舊的體系和制度終將沒落。