Jetpack Compose布局優(yōu)化實踐
01、前言
我們內(nèi)部團隊使用 Jetpack Compose 開發(fā)項目已近一年，經(jīng)歷了簡單布局到復(fù)雜布局的應(yīng)用，對 Compose 的使用越來越成熟，構(gòu)造了很多易用的基礎(chǔ)組合，提升了項目的開發(fā)效率，與此同時 Compose 布局的一些性能問題也慢慢凸顯出來，因此專門對 Compose 布局優(yōu)化進行了調(diào)研工作，旨在減少重組提高性能，規(guī)避負面效應(yīng)，提高應(yīng)用穩(wěn)定性。結(jié)合具體場景來具體分析。
02、使用 remember 減少計算
我們構(gòu)造一個客戶列表，代碼如下：
@Composable
fun ClientList(list: MutableList<ClientInfo>, modifier: Modifier) {
LazyColumn(modifier = modifier) {
items(list) {
ClientItem(it)
}
}
}接著增加一個需求，將客戶列表按照年齡排序，我們改動一下代碼：
@Composable
fun ClientList(list: MutableList<ClientInfo>, modifier: Modifier) {
LazyColumn(modifier = modifier) {
items(list.sortedBy { it.age }) {
ClientItem(it)
}
}
}上面代碼能夠正確運行，只不過會有一點問題，就是每次重組都會對 list 執(zhí)行排序操作。眾所周知在 Compose 中可組合項可能會非常頻繁的重組，也就意味著排序操作可能會非常頻繁的執(zhí)行，這顯然是不行的，因為排序可能會占用較多的資源，導(dǎo)致布局卡頓。最理想的狀態(tài)應(yīng)該是數(shù)據(jù)變動或者排序規(guī)則變動才會觸發(fā)排序，達到這種狀態(tài)我們可以使用 remember或者將排序操作放到 ViewModel 當(dāng)中：
@Composable
fun ClientList(list: MutableList<ClientInfo>, modifier: Modifier) {
// 通過remember方法，將list的排序結(jié)果緩存起來，當(dāng)list發(fā)生變化時，才會重新排序
val sortList = remember(key1 = list) {
list.sortedBy { it.age }
}
LazyColumn(modifier = modifier) {
items(sortList) {
ClientItem(it)
}
}
}在開發(fā)過程中應(yīng)該謹記一條規(guī)則：重組可能會頻繁的執(zhí)行，因此盡量避免在組合內(nèi)寫一些會引起副作用的代碼。
03、Lazy布局使用key
在項目開發(fā)中列表布局占多數(shù)，在 Compose 中實現(xiàn)列表使用延時布局它包含了 LazyColumn、LazyRow等布局，比如上一節(jié)使用 LazyColumn實現(xiàn)了一個客戶列表。
接上繼續(xù)以客戶列表布局為例，如果對客戶列表進行增加或者刪除，列表布局是如何重組的呢？為了探究這個問題，稍微改下代碼，增加一個添加客戶的按鈕：
Column {
Row(modifier = Modifier.fillMaxWidth()) {
Text(text = "添加新客戶", modifier = Modifier.clickable {
Log.d("compose demo", "添加新客戶")
//手動插入一條數(shù)據(jù)
list.add(5, ClientInfo("新添加客戶", 5))
})
}
ClientList(...)
}然后在 LazyColumn作用域以及ClientItem中加上日志信息：
@Composable
fun ClientList(list: SnapshotStateList<ClientInfo>, modifier: Modifier) {
LazyColumn(modifier = modifier) {
Log.d("compose demo", "LazyColumn update")
itemsIndexed(list) { _, item ->
ClientItem(item)
}
}
}
@Composable
fun ClientItem(info: ClientInfo) {
Log.d("compose demo", "item name=${info.name} 重組")
Text(text = "${info.name} ${info.age}", modifier = Modifier.height(44.dp))
}接下來運行一次，并點擊添加新客戶按鈕，控制臺輸出如下：
com.czx.demo D 添加新客戶
com.czx.demo D LazyColumn update
com.czx.demo D item name = 添加新客戶 重組
com.czx.demo D item name = name ---- 5 重組
com.czx.demo D item name = name ---- 6 重組
com.czx.demo D item name = name ---- 7 重組
com.czx.demo D item name = name ---- 8 重組
com.czx.demo D item name = name ---- 9 重組
com.czx.demo D item name = name ---- 10 重組
com.czx.demo D item name = name ---- 11 重組
com.czx.demo D item name = name ---- 12 重組
com.czx.demo D item name = name ---- 13 重組
com.czx.demo D item name = name ---- 14 重組我們發(fā)現(xiàn)除了新添加的客戶項之外，在此位置之后的所有可見的客戶項都觸發(fā)了不必要的重組。如果想讓列表只重組新增項，那么這里就要使用 key參數(shù)來避免這些不必要的重組，key參數(shù)是一個任意類型的值，用于標(biāo)識布局，并確保 Compose 框架在重新計算布局時正確地處理它們。改動代碼加上key參數(shù)：
@Composable
fun ClientList(list: SnapshotStateList<ClientInfo>, modifier: Modifier) {
LazyColumn(modifier = modifier) {
Log.d("compose demo", "LazyColumn update")
//key參數(shù)指定
itemsIndexed(list, key = { _, item -> item.id }) { _, item ->
ClientItem(item)
}
}
}需要注意的是 key參數(shù)要保證唯一性這樣才能確保 Compose 框架能夠正確地計算和更新列表項，加上 key參數(shù)代碼運行后臺輸出如下：
com.czx.demo D 添加新客戶
com.czx.demo D LazyColumn update
com.czx.demo D item name = 添加新客戶 重組之前的不必要重組沒有了，只重組了添加項，符合預(yù)期。
Tips: 這里一定要保證 key參數(shù)的唯一性，否則會出現(xiàn)不必要的重組，影響性能。
04、使用derivedStateOf限制重組
繼續(xù)使用上面的客戶列表，新增一個需求當(dāng)?shù)谝粋€可見項大于0的時候，展示回到頂部的按鈕，按照需求我們對代碼做如下改動：
1.增加listState來監(jiān)聽列表狀態(tài)：
val listState = rememberLazyListState()2.通過listState獲取當(dāng)前可見項，判斷是否展示回到頂部 button ：
val showButton = listState.firstVisibleItemIndex > 03.回到頂部按鈕顯隱：
if (showButton){
ScrollToTopButton()
}再將列表包裹一層布局整體代碼如下：
Box {
val listState = rememberLazyListState()
ClientList(...)
val showButton = listState.firstVisibleItemIndex > 0
if (showButton){
Log.d("compose demo", "button 重組")
ScrollToTopButton()
}
}運行代碼并上下滑動列表，控制臺輸出：
com.czx.demo D item name = name ---- 17 重組
com.czx.demo D item name = name ---- 18 重組
com.czx.demo D item button 重組
com.czx.demo D item button 重組可以看到觸發(fā)了多次重組，雖然 showButton只關(guān)心 firstVisibleItemIndex是否是從 0 變?yōu)榉?0 ，但是這種寫法當(dāng) firstVisibleItemIndex大于 0 時會一直被觸發(fā)，從而引起了不必要的重組。要想規(guī)避這種情況可以使用 derivedStateOf()函數(shù)來處理頻繁變更的數(shù)據(jù)：
val showButton by remember {
derivedStateOf {
listState.firstVisibleItemIndex > 0
}
}控制臺輸出：
com.czx.demo D item name = name ---- 17 重組
com.czx.demo D item name = name ---- 18 重組
com.czx.demo D item button 重組
com.czx.demo D item name = name ---- 19 重組
com.czx.demo D item name = name ---- 20 重組
com.czx.demo D item name = name ---- 21 重組
com.czx.demo D item name = name ---- 22 重組連續(xù)滑動只會觸發(fā)一次重組。
05、延遲讀取
Compose 有三個階段 組合、布局和繪制 ，可以通過盡可能的跳過三個步驟中的一個或者多個來提高性能。
06、場景一
val color by animateColorBetween(Color.Red, Color.Blue)
Box(modifier = Modifier.fillMaxSize().background(color))代碼能夠運行并且滿足我們的要求，如果足夠細心可以發(fā)現(xiàn)這里隱藏著一個優(yōu)化點，上面提到 Compose 的三個階段組合、布局和繪制，對于示例代碼而言，僅僅是改變背景顏色，不需要重組和布局，那么我們對代碼進行優(yōu)化。
val color by animateColorBetween(Color.Red, Color.Blue)
Box(modifier = Modifier.fillMaxSize().drawBehind {
drawRect(color = color)
})我們使用了 drawBehind()函數(shù)，該函數(shù)發(fā)生在繪制時期，由于僅改變背景顏色，所以這里改變方框的背景顏色使用 drawRect達到一樣的效果，這樣繪制就成了唯一重復(fù)執(zhí)行的階段，進而提高性能。
07、場景二
@Composable
fun SnackDetail() {
//...
Box(Modifier.fillMaxSize()) { // Recomposition Scope Start
val scroll = rememberScrollState(0)
// ...
Title(snack, scroll.value) //1.狀態(tài)讀取
// ...
} //Recomposition Scope End
}
@Composable
private fun Title(snack: Snack, scroll: Int) {
//...
val offset = with(LocalDensity.current) { scroll.toDp() }
Column(
modifier = Modifier
.offset(y = offset) //2.狀態(tài)使用
) {
//...
}
}對 scroll.value的讀取會使 Box()發(fā)生重組，但是 scroll的使用卻不是在 Box()中，這種讀取與使用位置不一致的情況，往往會有性能優(yōu)化的空間。對于這種情況我們將讓讀取和使用位置一致:
@Composable
fun SnackDetail() {
// ...
Box(Modifier.fillMaxSize()) { // Recomposition Scope Start
val scroll = rememberScrollState(0)
// ...
Title(snack) { scroll.value }
// ...
}
// Recomposition Scope end
}
@Composable
private fun Title(snack: Snack, scrollProvider: () -> Int) {
// ...
val offset = with(LocalDensity.current) { scrollProvider().toDp() }
Column(
modifier = Modifier
.offset(y = offset) // 狀態(tài)讀取+使用
) {
// ...
}
}這樣當(dāng) scroll.value()變化時不會觸發(fā)重組，也就是在滑動中唯二執(zhí)行的階段只有布局和繪制。
08、避免向后寫入
Compose中有個核心 假設(shè)：您永遠不會向已被讀取的狀態(tài)寫入數(shù)據(jù)。如果破壞了這個假設(shè)也就是向后寫入，可能會造成一些不必要的重組。
舉個例子：
@Composable
fun BadComposable() {
var count by remember { mutableStateOf(0) }
// Causes recomposition on click
Button(onClick = { count++ }, Modifier.wrapContentSize()) {
Text("Recompose")
}
Text("$count") //1
count++ // Backwards write, writing to state after it has been read
}點擊按鈕后會 count++執(zhí)行，注釋1處讀取了 count因此會觸發(fā)重組，但是同時末尾處的 count++也會執(zhí)行，最終導(dǎo)致之前狀態(tài)過期，注釋 1 繼續(xù)讀取，然后陷入循環(huán)，count++一直執(zhí)行，每一幀都在重組。這會造成嚴(yán)重的性能問題，所以應(yīng)該避免在組合中進行狀態(tài)寫入，盡量在響應(yīng)事件中寫入狀態(tài)。
07、發(fā)布模式&R8優(yōu)化
Compose并不是 Android 系統(tǒng)庫，而是作為獨立的庫進行引入。這樣做的好處就是可以兼容舊的安卓版本以及頻繁的更新功能，但是也會產(chǎn)生性能上的開銷，導(dǎo)致首次啟動或者首次使用一個庫功能時變得比較慢。
下圖是冷啟動耗時對比(單位：ms)：
圖片
可以看到發(fā)布模式 +R8+Profile 下的冷啟動耗時是最短的。發(fā)布模式一般默認開啟了 R8 優(yōu)化，具體優(yōu)化細節(jié)，這里不做展開。另外值得一提的是Profile，它是 Compose 官方定義的基準(zhǔn)配置文件，專門用來提高性能。
基準(zhǔn)配置文件中定義關(guān)鍵用戶歷程所需的類和方法，并與應(yīng)用的 APK 一起分發(fā)。在應(yīng)用安裝期間，ART 會預(yù)先編譯該關(guān)鍵代碼，以確保在應(yīng)用啟動時可供使用。要定義一個良好的基準(zhǔn)配置文件并不容易，因而此 Compose 隨帶了一個默認的基準(zhǔn)配置文件。您無需執(zhí)行任何操作即可直接使用該配置文件。但是，如果選擇定義自己的配置文件，則可能會生成一個無法實際提升應(yīng)用性能的配置文件。
10、總結(jié)
以上結(jié)合代碼示例介紹了 Jetpack Compose中的布局優(yōu)化手段，總結(jié)下來就是在應(yīng)用開發(fā)中，應(yīng)盡量減少不必要的重組來提高性能。因此我們需要合理的使用 remember、 Lazy布局的key, derivedStateOf等手段，來遵循最佳性能實踐。
11、引用
本文轉(zhuǎn)載自微信公眾號「 搜狐技術(shù)產(chǎn)品」，作者「 蔡志學(xué)」，可以通過以下二維碼關(guān)注。
轉(zhuǎn)載本文請聯(lián)系「 搜狐技術(shù)產(chǎn)品」公眾號。
