Jetpack Compose 笔记(3) - 重组的性能风险

重组的性能问题

第一节就讲到,Compose 过程第一步是「组合」,当变量发生改变时,可能触发「重组」。所谓重组,就是要重新执行我们写的 Compose 代码,为此 Compose 对代码进行了包装。同时为了优化性能,包装一般是比较细粒度的。这是否意味着可以高枕无忧了呢?看下面的代码:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
var msg = Message("hello")
setContent {
    println("Recompose 1")
    Column {
        var num by remember { mutableStateOf(1) }
        println("Recompose 2")
        Heavy(msg)
        Text(text = "数字为 $num")
        Button(onClick = { num++ }) {
            Text(text = "Change Name")
            msg = Message("hello")
        }
    }
}

@Composable
fun Heavy(msg: Message) {
    println("Recompose heavy")
    Text(text = "很重的操作:${msg.v}")
}

data class Message(val v: String)

表面上看,TextColumn 包裹,似乎可以组成一个 Recompose Scope,所以 num 发生改变重组的时候,“Recompose 1” 应该不会打印。非也!Column 是内联函数,编译展开后根本不存在,自然也就没有包裹效果。所以整个 setContent 块是一个重组作用域。假设我们在 Column 外部执行了一些操作,或者创建了其他 Compose 组件,它们就会一并重新执行,带来额外开销。

智能优化

可靠类

根据上面的分析,Heavy() 毫无疑问会在重组时执行,但事实再一次反直觉:“Recompose heavy” 没有打印 😮!这就是 Compose 的智能优化了。

我们所写的代码,不是直接被编译为字节码执行。而是 由 Compose 先行加工,这个加工包含很多处理,其中之一是添加对参数的判断,若参数没有改变,那么就不再执行,以此增强性能。

注意:智能优化不是 Compose 相对于传统 View 的优势。 为了解决自动更新时范围过大的问题,智能优化应运而生。而传统 View 系统根本就没有自动更新功能,UI 的刷新是我们手动控制的,连问题本身都不存在,何谈解决方案的优势?

此处的「相等判断」,采用的是 Structural Equality,即 Kotlin 中的 ==,也就是 java 中的 equals()。因此虽然我们在点击事件中给 msg 分配了新的对象,也不会重新执行。

⚠️ 以上规则只对「可靠的」类生效!

不可靠类

对于不可靠类 Compose 不再判断,直接重组。

「不再判断」有两层含义:

  1. 结构性相等也会重新执行。
  2. 哪怕是同一个对象(引用相等),也会重新执行。

什么叫「不可靠的」?简单说就是可变的。我们把上面的代码改一下,非常简单,仅仅是把 Message 中的字段改成可变:

1
data class Message(var v: String)

小知识
data class 的字段一般来说定义为不可变,但允许写成可变的。

就那么一个看起来没有实质性修改的修改,依然保持内容是 “hello” 不变,点击按钮后竟然打印了 “Recompose heavy” 😮!

到这有同学也许和我一样奇怪,明明没有变,凭什么仅仅因为是可变的,就要重新执行一遍?那我们来考虑这样一个情况:msg1msg2 是两个不同的对象,它们的值都是 “hello”。一开始令 msg = msg1,点击按钮后令 msg = msg2。假设因为结构性相等此时不重新执行,目前来说,还没什么问题。但如果未来某时某地,执行了 msg2.v = "world",UI 刷新完毕后,显示的内容会更新吗?答:不会。此时 Heavy() 内部参考的对象是 msg1,而我们修改的是 msg2,所以这个改变不会反应到 UI 上,喜提 🐛 Bug 一枚。总结,如此设计的原因是:两个可变对象(不可靠对象)现在的值相等,不代表未来的值也相等。

@Stable

现在,我们知道了 Compose 自动优化的能力,也了解了它的局限。自然而然地,我们想,能不能打破这个局限?当然可以,而且很简单。只要给类加一个 @Stable 注解,Compose 就将其视为可靠的,无论真实情况如何。

需要强调的是,我们要解决的是问题,而不是提出问题的人 [doge],掩耳盗铃最终受伤的还是自己。从某种程度上说,@Stable 就是一种掩耳盗铃,除非,我们保证了它真的不会改变,或者说,即使改变了也会和曾经的对象同步。@Stable 是一种契约,就像 Kotlin 的 lateinit 一样。我们对编译器许下承诺换取了更为宽松的限制,也就意味着需要独自面对潜在的风险。 —— 不要滥用这个注解,除非你知道究竟是在干什么。

「With great power , there must also comes great resposibility」 —— Voltaire


除此之外,标记 @Stable 的类还得满足其他的要求,即一共有三个要求:

  1. 现在先等的两个类,需永远相等。(相等性恒定不变)
  2. public 属性改变时需要触发刷新。
  3. 它的 public 属性也得是 Stable 的。

尽管要成为可靠类需要满足三个条件,但编译器只有能力检测第二个。 日常开发中我们还是需要留意一下,以免不小心被作为可靠对象埋下祸根。

第二个要求看起来复杂,实现起来却简单:把属性包一层 mutableStateOf() 就行了。比如这样:

1
2
3
4
//@Stable
class Message(v: String) { 
    var v by mutableStateOf(v)
}

解释一下:

  1. 这不是 data class 也没有重写 equals(),它的相等性恒定不变。
  2. public 属性 v 能够触发刷新。
  3. 由于构造方法中写字段的语法不支持 by,因此把参数与字段分离了。这是 Compose 中常见的写法。
  4. 现在已经满足了条件 2,编译器会自动判定可靠,所以不需要 @Stable 注解了。

💡 Tips: 基本类型与 String 都是可靠的。因为它们根本就没有内部属性。

@Immutable

@Immutable 是比 stable 更 stable 的注解,它表示内部属性根本就不会变,哪怕语法上允许变也不会变。如今 @Immutable@Stable 的效果是一致的,它俩的区别更多是开发者自己备注用。

小结

为了提高重组时的性能,应该尽量使用可靠的对象。目前能想到的包括下面这些情况:

  • 使用 data class 时属性全部声明为不可变类型。
  • 使用普通类时,若包含可变属性则不要重写 equals(),可变的 public 属性用 MutableState 包裹一下。
  • 若系统无法自动判定出可靠,则添加注解。通常是在接口或抽象类处。
禁止转载到私域(公众号,非自己托管的博客等),其他情况请注明原作者与可点击跳转的来源链接。