本文为现代化 Android 开发系列文章第六篇。

完整目录为：

如果一直关注 Compose 的发展的话，可以明显感受到 2022 年和 2023 年的 Compose 使用讨论的声音已经完全不一样了, 2022 年还多是观望，2023 年就有很多团队开始采纳 Compose 来进行开发了。不过也有很多同学接触了下 Compose，然后就放弃了。要么使用起来贼特么不顺手，要么就是感觉性能不行，卡。其实，问题只是大家的思维没有转换过来，还不会写 Compose。

为何要选择 `Compose`

很多 Android 开发都会问：View 已经这么成熟了，为何我要引入 Compose？

历史也总是惊人的相似，React 横空出世时，很多前端同学也会问：jQuery 已经如此强大了，为何要引入 JSX、Virtual DOM？

争论总是无效的，时间会慢慢证明谁才会成为真正的主宰。

现在的前端同学，可能连 jQuery 是什么都不知道了。其作为曾经前端的主宰，何其强大，却也经受不住来自 React 的降维打击。回看这端历史，那我们选择 Compose 就显得很自然了。

另一个大趋势是 Kotlin 跨平台的逐渐兴起与成熟，也会推动 Compose 成为 Fultter 之外的选择，而且可以不用学习那除了写 Flutter 就完全没用的 Dart 语言。

但是，我也不推荐大家随随便便就把 Compose 接入的项目中。因为，国内的开发现状就是那样，迭代速度要求快，但是也要追求稳定。而接入 Compose 到使用 Compose 快速迭代，也是有一个痛苦的过程的，搞不好就要背锅，现在这环境，背锅可能就代表被裁了。

所以目前 Compose 依旧只能作为简历亮点而非必备点。可是如果你不学，万一被要求是必备点，那该怎么办？

所以即使你不喜欢 Compose 这一套，那为了饭碗，该掌握的还是得掌握，毕竟市场饱和，我们是被挑选的哪一方。

`Compose` 的思想

声明式 `UI`

Compose 的思想与 React、View、Fultter、SwiftUI 都是一脉相传，那就是数据驱动 UI 与声明式 UI。以前的 View 体系，我们称它为命令 UI。

命令式 UI 是我们拿到 View 的句柄，然后通过执行命令，主动更新它的的颜色、文字等等

声明式 UI 则是我们构建一个状态机，描述各个状态下 UI 是个什么样子的。

那些写 Compose 怎么都不顺手的童鞋，就是总想拿 View 的句柄，但又拿不到，所以就很痛苦，但如果转换到状态机的思维上，去定义各种情景的状态，那写起来就非常舒服了。

Compose 从 View 体系进化的点就是它贴近于真实的 UI 世界。因为每个界面就是一个复杂的状态机，以往我们命令式的操作，我们依旧要定义一套状态系统，某种状态更新为某种 UI，有时候处理得不好，还会出现状态错乱的问题。 Compose 则强制我们要思考 UI 的状态机该是怎样子的。

Virtual DOM

在 Compose 的世界中，是没有介绍 Virtual DOM 这一概念的，但我觉得理解 Virtual DOM 能够帮助我们更好的理解 Compose。 Virtual DOM 的诞生，一个原因是因为 DOM/View 节点实在是太重了，所以我们不能在数据变更时删除这个节点再重新创建，我们也不没有办法通过 diff 的方式去追踪到底发生了哪些变更。但大佬们的思维就比较活跃，因为开发过程中关注的一个 DOM/ View 的属性是很少的，所以就创造了一个轻量级的数据结构来表示一个 DOM/View 节点，由于数据结构比较轻量，那么销毁创建就可以随意点。每次更新状态，我可以用新状态去创造一个新的 Virtual DOM Tree，然后与旧的 Virtual DOM Tree 进行 diff，然后将 diff 的结果更新到 DOM / View 上去， React Native 就是把前端的 DOM 变成移动端的 View，因而开启了 UI 跨平台动态化的大门。

那这和 Compose 有什么关系呢？我们可以认为，Compose 的函数让我们来生成 Virtual DOM 树，Compose 内部叫 SlotTable，框架用了全新的内部结构来代表 DOM 节点。每次我们状态的变更，就会触发 Composable 函数重新执行以生成新的 Virtual DOM，这个过程叫做 Recomposition。

所以重点来了，发生状态更新后，框架会首先去重新生成 Virtual DOM 树，交给底层去比对变更，最终渲染输出。如果我们频繁的变更状态，那就会频繁的触发 Recomposition，如果每次还是重新生成一个巨大的 Virtual DOM 树，那框架内部的 diff 就会非常耗时，那么性能问题随之就来了，这是很多同学用 Compose 写出的代码卡顿的原因。

Compose 性能最佳实践

如果我们有了 Virtual DOM 这一层认识，那么就能够想到该怎样去保持 Compose 的高性能了，那就是

减少 Composable 函数自身的计算
减小状态变更的频次
减小状态变更的造成 Recomposition 的范围以减小 diff 更新量
减小 Recomposition 时的变更量以减小 diff 更新量

减少 `Composable` 函数自身的计算

这个很好理解，如果 Recomposition 发生了，那么整个函数就会重新执行，如果有复杂的计算逻辑，那就会造成函数本身的消耗很大，而解决措施也简单，就是通过 remember 缓存计算结果

@Composable
func Test(){
    val ret = remember(arg1, arg2) { // 通过参数判断是否要重新计算
        // 复杂的计算逻辑
    }
}

减少状态变更的频次

这个主要是减少无效的状态变更，如果有多个状态，其每个状态下的执行结果是一样的，那这些状态间的变更就没有意义了，应该统一成唯一的状态。

其实官方在 mutableStateOf 的入参 policy 上已经定制了几种判断状态值是否变更的策略：

StructuralEqualityPolicy: 通过值判等（==）的来看其是否发生变更
ReferentialEqualityPolicy: 必须是同一个对象（===）才算未发生变更
NeverEqualPolicy : 总是触发状态变更

默认为 StructuralEqualityPolicy，也符合一般情况的要求。

除此之外，我们减小状态变更频率的手段就是 derivedStateOf。它的用途主要是我们就是将多个状态值收归为统一的状态值，例如：

列表是否滚动到了顶部，我们拿到的 scorllY 是很频繁变更的值，但我们关注的只是 scorllY == 0
根据内容为空判定发送按钮是否可点击，我们关注的是 input.isNotBlank()
多个输入的联合校验
...

我们以发送按钮为例：

@Composable
func Test(){
    val input = remember {
        mutabtleStateOf('')
    }
    val canSend = remember {
        derivedStateOf { input.value.isNotBlank() }
    }

    // 使用 canSend
    SendButton(canSend)
    // 其它很多代码
}

这样子，我们可以多次更新 input 的值，但是只有当 canSend 发生变更时才会触发 Test 的 Recomposition。

减小状态变更的造成 `Recomposition` 的范围

Recomposition 是以函数为作用范围的，所以某个状态触发了 Recomposition，那么这个函数就会重新执行一次。但需要注意的是，不是状态定义的函数执行Recomposition，而是状态读取的函数会触发 Recomposition。

还是以上面的输入的例子为例。如果我在 Test 函数执行期内读取了 input.value，那么 input 变更时就会触发 Test 函数的重组。注意的是函数执行期内读取，而不是函数代码里写了 input.value。上面 canSend 的 derivedStateOf 虽然也有调用 input.value，但因为它是以 lambda 的形式存在，不是会在执行 Test 函数时就执行，所以不会因为 input.value 变更就造成 Test 的 Recomposition。

但如果我在函数体内使用 input.value，例如：

@Composable
func Test(){
    val input = remember {
        mutabtleStateOf('')
    }
    val canSend = remember {
        derivedStateOf { input.value.isNotBlank() }
    }
    Text(input.value)
    SendButton(canSend)
    OtherCode(arg1, arg2)
    OtherCode1(arg1, arg2)
}

那就会因为 input 的变更而造成 Test 的重组， canSend 使用 derivedStateOf 也就是做无用功了。更严重的是可能有很多其它与 input 无关的代码也会再次执行。

所以我们需要把状态变更触发 Recomposition 的代码用一个子组件来承载：

@Composable
func InputText(input: () -> String){
    Text(input())
}

@Composable
func Test(){
    val input = remember {
        mutabtleStateOf('')
    }
    val canSend = remember {
        derivedStateOf { input.value.isNotBlank() }
    }
    InputText {
        input.value
    }
    SendButton(canSend)
    OtherCode(arg1, arg2)
    OtherCode1(arg1, arg2)
}

我们重新创建了一个 InputText 函数，然后通过 lambda 的形式传递 input，因而现在 input 变更造成的 Recomposition 就局限于 InputText 了，而其它的无关代码就不会被执行，这样范围就大大缩减了。

减小 `Recomposition` 时的变更量

加入我们的函数 Recomposition 的范围已经没办法缩减了，例如上面 canSend 变更触发 Test 的 Recomposition，这造成 OtherCode 组件的重新执行好像无法避免了。其实官方也想到了这种情况，所以它框架还会判断 OtherCode 的参数是否发生了变更，依此来判断 OtherCode 函数是否需要重新执行。如果参数没有变更，那么就可以开心的跳过它，那么 Recomposition 的变更量就大幅减小了。

那么怎么判断参数没有发生变更呢？如果是基础类型和data class 等的数据结果还好，可以通过值判等的形式看其是否变更。但如果是列表或者自定义的数据结构就麻烦了。因为框架无法知道其内部是否发生了变更。

以 a: List<T> 为例，虽然重组时我拿到的是同一个对象 a, 但其实现类可能是 ArraryList<T>, 并且可能调用 add/remove 等方法变更了数据结构。所以在保证正确性优先的情况下，框架只得重新调用整个函数。

@Composable
fun SubTest(a: List<String>){
    //...
}

@Composable
fun Test(){
    val input = remember {
        mutabtleStateOf('')
    }
    val a = remember {
        mutableStateOf(ArrayList<String>())
    }
    // 因为读取了 input.value， 所以每次 input 变更，都会早成 Test 的 Recomposition
    Test(input.value)
    // 而因为 a 是个 List，所以每次 SubTest 也会执行 Recomposition
    SubTest(a)
}

那要怎么规避这个问题呢？那就是使用 kotlinx-collections-immutable 提供的 ImmutableList 等数据结构，如此就可以帮助框架正确的判断数据是否发生了变更。

@Composable
fun SubTest(a: PersistentList<String>){
    //...
}

@Composable
fun Test(){
    val input = remember {
        mutabtleStateOf('')
    }
    val a = remember {
        mutableStateOf(persistentListOf<String>())
    }
    // 因为读取了 input.value， 所以每次 input 变更，都会早成 Test 的 Recomposition
    Test(input.value)
    // 而因为 a 是个 List，所以每次 SubTest 也会执行 Recomposition
    SubTest(a)
}

而如果是我们自己定义的数据结构，如果是非 data class，那就要我们主动加上 @Stable 注解，告诉框架这个数据结构是不会发生变更，或者其变更我们都会用状态机去处理的。特别需要注意的是使用 java 作为实体类而给 compose 使用的情况，那就是非常不友好了。

对于列表而言，我们往往需要用 for 循环或者 LazyColumn 之类的方式使用:

@Composable
fun SubTest(list: PersistentList<ItemData>){
    for(item in list){
        Item(item)
    }
}

这个写法，如果 list 不会变更，那也没什么问题，可是如果列表发生了变更，例如原本是 12345, 我删了一项变成 1345。

那么在 Recomposition 的时候，框架在比对变更时，发现从第二项开始就全不同了，那么剩下的 Item 就得全部重新重组一次了，这也是非常耗费性能的，所以框架提供了 key 的功能，通过它，框架可以检测列表的 Item 移动的情况。

@Composable
fun SubTest(list: PersistentList<ItemData>){
    for(item in list){
        key(item.id){
            Item(item)
        } 
    }
}

不过需要注意的是 key 需要具有唯一性。 LazyColumn 的 item 也有 key 的功能，其作用类似，其还有 contentType 的传参，其作用和 RecyclerView 的多 itemType 类似，也是一个可以使用的优化措施。

最后

Compose 业务上能做的优化大体上就是这些了。总之我们就是我们要保持组件的颗粒度尽可能的小，容易变动的要独立出来，非常稳定的也要独立出来，尽量使用 Immutable 的数据结构。如此之后， Compose 的流畅度还是非常不错的。

如果还觉得卡，那多半是因为你使用的是 Debug 包，Compose 会在 Debug 包加很多调试信息，会很影响其流畅度的。切换到 Release 包，可能丝滑感就出来了。

现代化 Android 开发：Jetpack Compose 最佳实践

为何要选择 `Compose`

`Compose` 的思想

声明式 `UI`

Virtual DOM

Compose 性能最佳实践

减少 `Composable` 函数自身的计算

减少状态变更的频次

减小状态变更的造成 `Recomposition` 的范围

减小 `Recomposition` 时的变更量

最后

热门文章

最新文章

相关课程

相关电子书

现代化 Android 开发：Jetpack Compose 最佳实践

为何要选择 Compose

Compose 的思想

声明式 UI

Virtual DOM

Compose 性能最佳实践

减少 Composable 函数自身的计算

减少状态变更的频次

减小状态变更的造成 Recomposition 的范围

减小 Recomposition 时的变更量

最后

热门文章

最新文章

相关课程

相关电子书

为何要选择 `Compose`

`Compose` 的思想

声明式 `UI`

减少 `Composable` 函数自身的计算

减小状态变更的造成 `Recomposition` 的范围

减小 `Recomposition` 时的变更量