Jetpack Compose What and Why, 6個問題

1.這個技術出現的背景, 初衷, 要達到什么樣的目標或是要解決什么樣的問題.

Jetpack Compose是什么?
它是一個宣告式的UI工具包(declarative UI toolkit for Android).

它的主要目的就是改變之前命令式地(imperatively)寫UI的方法, 改成宣告式(declarative)的.

命令式

Android之前的寫法就叫命令式: view hierarchy是一個UI widgets構成的tree, 當app的狀態改變時, UI需要更新. 通常的做法是通過findViewById()等手段找到要更新的節點, 通過setText(), addChild(), setImageBitmap()等方法更新控制元件的內部狀態. 每個控制元件都有自己的內部狀態, 并且暴露getter/setter, 允許程式邏輯和控制元件互動.

命令式為什么不好呢:

這樣手動地更新view會增加犯錯的可能性. 如果某一資料在多個地方被渲染, 那么很可能就忘了更新其中的某個view.
很容易創建非法狀態, 比如兩個更新以不期望的方式沖突了. (比如: 一個要更新值, 另一個要移除節點.)
維護的復雜度隨著需要更新的view個數而增加.

宣告式

所以, 在過去的幾年里, 業界一直在探索并且開始轉向一種宣告式的UI模型. 目的就是簡化構建和更新UI.

Jetpack Compose是一個宣告式的UI framework. 該技術的原理是從頭開始重新生成整個螢屏, 然后僅應用必要的更改. 這種方法避免了手動更新stateful view的復雜度.

在Compose的宣告式解決方案里, widgets相對來說是stateless的, 不暴露getter/setter.
實際上, widgets根本不是以物件的形式來暴露的.
當更新UI的時候, 實際上是傳不同的引數呼叫了composable方法. 當資料改變時, composable負責把當前的應用狀態轉化為UI.

2.這個技術的優勢和劣勢分別是什么, 或者說, 這個技術的trade-off是什么.

Compose的優勢:

目前Google投入了大量的資源(學習資源, 社區挑戰賽, IDE和編譯器支持, 推出desktop版本等)來推廣Compose, 我們有理由相信Google官方會繼續發力, Compose會成為Android未來的UI標準開發形式.
Compose的宣告式寫法和Flutter, SwiftUI, React契合, 在支持多個平臺的團隊里, 有利于架構思想的統一.
宣告式UI, 寫起來更快, 不容易出錯.
因為所有的代碼都是Kotlin寫的(真100%kotlin), 利用了Kotlin的強型別安全, 編譯器會提示很多錯誤.
修復和更新了一些舊的API: (Buggy Android Views: Picker, Spinner, EditText, 有一些edge cases. 因為要更改舊的總是很難, 不如創建一個新的. )
基于組合的Composable, 比基于繼承的View體系, 更加靈活, 易于復用. 比如可以通過組合來達到復用多個源, 不再受單繼承限制.
以Button為例, 在傳統的UI里, 它是單繼承體系下的一個類: Button -> TextView -> View.
而在Compose的世界里, 它只是一個@Composable的方法, 里面包含了其他composable, surface, row等.
舉例: list->detail兩個界面, 可以通過提取方法引數來達到兩個界面的composable復用.
支持和View-based UI系統的互相呼叫. 這樣有兩個優點: 有利于已有專案app的混用和逐步遷移; 當Compose滿足不了需求的時候可以用傳統View作為第二選擇.
和Jetpack系列的其他庫都能完美結合. (ViewModel, Kotlin Flow, Coroutines, Paging, Hilt, Navigation...)

劣勢:

需要用Canary版本的Android Studio, 目前(2021.5)IDE還是存在一些問題的.
Gradle也要升級到最新版(7.0.0-alpha15), 不是很穩定, 還有一些問題.
版本更新頻繁. Compose alpha版本的一些API已經變了. -> 但是目前已經beta, 最新的Google I/0說7月就會有穩定版發布.
相比Android View, 社區支持不夠多. -> 但是Google已經投入了大量的資源來推廣, 社區支持正在飛速增長.
雖然Google封裝了material的compose庫, 但還是有一部分View控制元件沒有辦法提供, 比如WebView, MapView等.

3.這個技術使用的場景.

Jetpack Compose的使用場景是取代原來的Android View寫法(xml, 在代碼里實體化View物件再添加到View hierarchy里等),
Jetpack Compose用全新的方式來寫UI, 即將成為Google Android標準寫法.

注意這里的改變除了UI寫法的改變, 還是一種狀態管理思想的轉變.
宣告式, 單向資料流, 單個資料源.
Android內部的模式近年來一直追求的無外乎就是資料和View的分離, View的無知與自動更新, 清晰的邏輯管理和分離, 可測驗性等等.

除了與View強相關的這一層(ViewModel)外, 其他的業務邏輯, 資料互動等被影響不大, 所以即便app決定逐漸遷移到Compose, 也只用管View繪制以及和View相鄰的這一層.

4.技術的組成部分和關鍵點.

Jetpack compose的總體特點:

宣告式UI. f(state)=UI.
Built on Kotlin.
Unbundled: 不是和系統系結的, 而是和Jetpack中的庫一樣, 版本獨立, 可以自己更新維護版本, 也保證了多個系統上的行為一致.
Built for interop. 可以和已有View互相呼叫, 適用于現有專案的逐漸遷移.
內置控制元件和theming, 支持material design.

Composable functions

Compose的使用方法:
定義一系列的composable functions: 接收資料, 發射UI元素.

@Composable
fun Greeting(names: String) {
    Text("Hello $name")
}

Composable方法的特點:

所有的方法都必須有@Composable注解.
方法引數是資料.
通過呼叫其他composable方法來發射UI元素.
方法不回傳值, 因為它們在描述螢屏狀態, 而不是構建UI widgets.
方法要快, 具有冪等性(呼叫多少次結果都一樣), 沒有副作用. (fast, idempotent, and side-effect free.) 這就要求方法不會修改外部屬性或者全域變數, 也沒有Random的呼叫等.

還有一個小區別就是不同于普通的kotlin方法命名規范, composable方法名的首字母要大寫, 因為它此時代表的是一種widget.

Recomposition

Compose framework會很機智地選出有變化, 需要重新繪制的部分.

在Compose中, 如果呼叫composable function, 傳入了新資料, 會使得方法被recomposed: 這個方法發射的widgets會根據需要進行重新繪制.

因為重新繪制整個UI tree會花銷比較大, 所以實際上composable function只有input改變的才會被重新繪制, 對于那些引數沒有變化的方法和lambda, 其實是skip掉的, 這樣才能提高recompose的效率.

所以, 永遠不要依賴于執行composable function的side-effects, 因為recomposition有可能會被skip掉.

side-effects包括:

更新共享物件.
更新ViewModel中的observable.
更新shared preferences.

由于composable functions有可能會被逐幀執行(比如影片期間), 所以它應該足夠的快, 如果需要耗時的操作, 可以考慮后臺的coroutine.

5.技術的底層原理和關鍵實作.

Compose的幾個特點:

Composable functions可以以任何順序執行.
Composable functions可以并行執行.
Recomposition會盡可能地skip多的composable functions. 如果真的需要side-effects, 考慮用callback.
Recomposition是樂觀的, 它認為在本次重繪期間不會有新的狀態改變, 如果有新的狀態改變, 它可能會取消當前繪制, 以新的引數重新開始繪制.
Composable function有可能會被執行得很頻繁(比如影片), 所以避免耗時操作.

關于Compose的底層原理, 目前還沒找到一個官方的檔案或者架構圖.
因為可能大家都還在學習怎么使用, 這項技術的底層實作細節還沒有被熱烈討論起來.
這里有個問題: https://stackoverflow.com/questions/58558163/how-does-jetpack-compose-work-under-the-hood

從使用者的角度揣測一下Compose的原理:
雖然Composable使用了注解@Composable, 但是卻沒有添加注解處理器(kapt), 所以并不是依靠注解在編譯期生成代碼.

在添加依賴的時候需要在build.gradle里添加:

    composeOptions {
        kotlinCompilerExtensionVersion compose_version
    }

所以它和kotlin的編譯器有關系.

這個視頻: Understanding Compose (Android Dev Summit '19)在17:18開始講實作原理.

@Composable更像是一個語言的關鍵字. 可以類比suspend, 有以下幾個共同點:

改變了方法的型別.
強制了方法的呼叫背景關系.

部分更新

用了定制化的Kotlin編譯器插件, 資料改變時, 受資料影響的composable的方法會被重新呼叫.

6.已有的實作和它之間的對比.

Android View和Jetpack Compose的對比.

Android View和Jetpack Compose的相似點:

都是Android UI的寫法.

Jetpack Compose改進了View系統的哪些地方:

不再需要擔心深層嵌套. Compose UI不允許多遍的測量(multi-pass measurement), 改善了效率.

Flutter和Jetpack Compose的對比.

Jetpack Compose和Flutter的相似點:

宣告式UI, UI = f(state).
都有web和desktop版本.
官方都提供了一些material的控制元件和資源, 比如都有個Scaffold, 提供腳手架.
都可以和原生混用, 雖然程度不一樣, Compose的混用粒度更細一點.
都可以一邊改UI一邊預覽.

Jetpack Compose比Flutter好的地方:

基于Kotlin, 相比于Flutter的dart來說, 對Android開發者更友好一些.
接著上一點, 因為Compose只改了UI, 所以其他部分的代碼庫仍然是Android原生代碼的邏輯, 趁手的第三方庫比較多. 而Flutter, 就得利用其它package來做json決議, 資料庫等等.
Flutter的stateful widget改狀態必須要在setState里, 使用上不是很方便, 容易出錯.
Jetpack Compose的Recomposition看上去更智能一些, 完全自動, 不像Flutter一樣需要開發者自己設定一些flag來表明哪個部分不需要重繪.
安裝包體積應該有優勢? 因為Flutter SDK包含了自己的影像引擎, 而Compose是沒有native層面的東西的.

Flutter比Jetpack Compose好的地方:

Flutter還支持iOS.
Flutter相比Jetpack Compose稍微成熟一些(Flutter出來的早一些), 是經過一些app的實際上線驗證的.
Flutter是有自己的圖形引擎Skia的, 繪制會更有效率? (沒有驗證, 純猜測)

Reference

Thinking in Compose
Using Jetpack libraries in Compose | Session -> 這個講狀態管理和其他Jetpack庫結合的視頻很棒.

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/286129.html

標籤：Android

上一篇：詳講自定義影片的實作

下一篇：解決安卓11下apk安裝失敗的問題