Android Jetpack Compose之确定重组范围并优化重组

1.概述

前面的文章提到Compose的重组是智能的，Composable函数在进行重组时会尽可能的跳过不必要的重组，只对需要变化的UI进行重组。那Compose是如何认定UI需要变化呢？或者换句话说Compose是如何确定重组的范围呢。如果重组随意的发生，那么对UI的性能会是一个很不稳定的状态，时而好，时而坏。而且如果编写的UI代码有问题，那么重组将会带来状态的混乱，导致UI显示出错。所以弄清楚Compose重组的范围确定才能更好的避免重组的坑，并且可以针对具体的范围做优化，所以本文将介绍如何确定Compose重组的范围以及重组性能的优化。

2.确定Composable重组的范围

确定重组的范围有助于我们更好的理解ComposeUI的性能优化，下面我们先看一个例子：

    @Composable
    fun CounterDemo(){
    
    
        Log.d("zhongxj","范围1=>运行")
        var counter by remember {
    
     mutableStateOf(0) }
        Column {
    
    
            Log.d("zhongxj","范围2=>运行")
            Button(onClick = {
    
    
                Log.d("zhongxj","onButtonClick:点击按钮")
                counter ++
            }){
    
    
                Log.d("zhongxj","范围3=>运行")
                Text(text = "+")
            }

            Text(text = "$counter")
        }
    }

在上面的代码中，我们依然使用计数器的例子来验证重组的范围，我们在各个可能发生重组的地方都打上了Log,当点击Button时，计数器counter的状态更新会触发CounterDemo的重组，日志如下图所示：

从图中我们可以看到， Log.d("zhongxj","范围3=>运行") 这行Log并没有打，没有打这行log的原因需要我们了解Compose重组的底层原理：

在Compose中，经过Compose编译器处理后的Composable函数在对State进行读取的同时，能够自动建立关联，在运行过程中，当State变化时Compose会找到关联的代码块并将其标记为Invalid.在下一个渲染帧到来之前，Compose会触发重组并且执行invalid代码块，而Invalid代码块即为下一次重组的范围。能够被标记为Invalid的代码有2个两个要求，一是被标记为Invalid的代码必须时非inline且没有返回值的Composable函数，二是无返回值的Lambda。

那么为啥参与重组的代码块必须是非inline的无返回值函数呢？因为inline函数在编译期会在调用处展开，因此无法在下次重组时找到合适的调用入口，只能共享调用方的重组范围。而有返回值的函数由于返回值会影响调用方，所以必须联通调用方一起参与重组。因此inline的有返回值的函数不能作为Invalid代码块。

而了解了Compose的底层重组原理，我们就可以清楚的知道了只有受到State变化影响的代码块，才会参与到重组。不依赖State的代码则不参与重组，这就是重组的最小化原则。

基于重组最小化原则，我们可以分析下我们计数器例子中的输出结果，其实看了日志发现 Log.d("zhongxj","范围3=>运行")这行日志没有打，也就是说这行日志所在的代码块并没有参与重组，在范围2的作用域中，我们看到了这行代码Text(text = "$counter"),很明显这行代码依赖了counter状态，需要注意的是这行代码并不是读取counter值的意思，它的意思是在范围2的作用域中读取counter的值并传入Text，所以范围2是会参与重组的，日志就输出了Log.d("zhongxj","范围2=>运行"),这时有读者可能会发现，按照重组最小化原则，那么访问counter的最小范围应该是：范围2的作用域呀，为啥范围1的日志也会被打印呢？这里需要回想下咱们之前讲的：最小化范围的定义必须是非inline的composable函数或者lambda。而Column组件是一个inline声明的高阶函数：
所以content内部也会被展开在调用处，所以范围1和范围2就共享了重组的范围，所以输出了Log.d("zhongxj","范围1=>运行")日志，假设将Column换成非inline的Composable，那么Log.d("zhongxj","范围1=>运行")将不会输出，比如换成一个Card组件，读者可以自行试一下。

需要注意的是，Button虽然没有依赖counter，但是范围2的重组会触发Button的重新调用，所以 Log.d("zhongxj","onButtonClick:点击按钮") 也会输出，但是其content内部并没有依赖counter,所以范围3的日志： Log.d(“zhongxj”,“范围3=>运行”) 不会输出。

补充说明： Composable 函数观察State变化并触发重组是在被称为”快照“的系统中完成的，所谓”快照“就是将被访问的状态像拍照一样保存下来，当状态变化时，通知相关的Composable应用的最新状态。”快照“有利于对状态管理进行线程隔离，在多线程场景下的重组有重要的应用

3.优化重组的性能

经过前面的分析，我没了解到了Compose的重组是智能的，遵循范围最小化原则，重组中执行到的Composable只有在其参数发生变化时，才会参与本次重组。

Compose 在执行后会生成一棵视图树，每个Composable对应树上的一个节点，因此Composable 智能重组的本质其实是从树上寻找对应位置的节点并与之进行比较，如果节点未发生变化则不用更新。

另外需要注意的是，视图树的实际构建过程比较复杂，Composable执行过程中，先将生成的Composition状态存入SlotTable,然后框架基于SlotTable生成LayoutNode树，并完成最终的界面渲染。所以谨慎的说，Composable的比较逻辑是发生在SlotTable中的。

3.1 Composable 位置索引

在重组的过程中，Composition上的节点可以完成增、删、移动、更新等多种变化，Compose编译器会根据代码调用位置，为Composable生成索引key,并且存入Composition，Composable在执行过程中通过与Key的对比可以知道当前应该执行何种操作。例如下面的示例代码：

    Box {
    
    
            if (state) {
    
    
                val str = remember(Unit) {
    
     "call_site_1" }
                Text(text = str) // Text_of_call_site_1
            } else {
    
    
                val str = remember(Unit) {
    
     "call_site_2" }
                Text(text = str) // Text_of_call_site_2
            }
        }

如上面代码所示：Composable中遇到if/else等条件语句时，会插入startXXXGroup类似的代码，并且通过添加索引Key识别节点的增减，上面的代码中会根据state的不同显示不同的Text，编译器会为if和else分支分别建立索引，当state由true变为false时，Box发生重组，通过key的判断可知，else内的代码需要插入逻辑执行，而if内生成的节点需要被移除。

假设没有编译期的位置索引，而仅仅靠运行时比较，首先执行到 remember(Unit)时，由于缓存原因仍然会返回当前树上存放的str,即call_site_1,接着执行到Text_of_call_site_1，发现与当前树上的节点类型一样，参数str也没有变化，因此会判断为无须重组，那么文本就无法得到更新

所以，综上所述：Composable 在编译期建立索引是保证其重组能够智能且正确执行的基础。这个索引是根据Composable在静态代码中的被调用位置决定的。但是在某些场景中，Composable无法通过静态代码位置进行索引，这时我们需要手动添加索引，便于在重组中进行比较

3.2 通过Key添加索引信息

假设我们现在需要给一个电影列表，然后展示电影的大致信息，代码如下所示：

@Composable
    fun MoviesScreen(movies:List<Movie>){
    
    
        Column {
    
     
            for (movie in movies){
    
    
                // showMoveCardInfo 无法在编译期间进行索引，只能根据运行时的index进行索引
                showMoveCardInfo(movie)
            }
        }
    }

如上面的代码所示，基于Movie的名字展示电影的信息，此时无法基于代码中的位置进行索引,只能在运行时基于index进行索引。这样的话索引会根据item的数量发生变化，导致无法准确进行比较。在这种情况下，当重组发生时，新插入的数据会和以前的第一个数据比较，以前的第一个数据会和第二个数据比较，然后以前的第二个数据会被当作新数据插入。结果是所有的item都会发生重组，但是我们期望的行为是，只有新插入的数据需要重组，其他没有变化的数据不应该发生重组，所以我们可以使用key的方法为Composable在运行时手动添加一个索引，如下所示：

@Composable
    fun MoviesScreen(movies:List<Movie>){
    
    
        Column {
    
     
            for (movie in movies){
    
    
               key(movie.id){
    
     // 使用movie的唯一ID作为Composable的索引
                showMoveCardInfo(movie)
                }
            }
        }
    }

使用movie的ID传入Composable做为唯一索引，当插入新数据时，之前对象的索引没有被打乱，仍然可以发挥比较时的锚定作用，所以其他没有发生变化的item就可以不用参与重组

3.3 使用注解@Stable优化重组

Composable是基于参数的比较结果来决定是否重组，也就是说，只有当参与比较的参数对象是稳定的且equals返回true，才认为是相等的。Kotlin中常见的基本类型（Boolean、Int、Long、Float、Char) String,Lambda表达式都可以认为式稳定的，因为都是不可变类型。所以他们的参数比较的结果都式可信的。但是假如参数是可变类型，那么比较的结果将是不可信的。

data class Mutabledata(var data:String)

    @Composable
    fun MutableDemo(){
    
    
        var mutable = remember {
    
     Mutabledata("walt") }

        var state by remember {
    
     mutableStateOf(false) }
        if(state){
    
    
            mutable.data = "zxj"
        }

        Button(onClick = {
    
    state = true}){
    
    
           showText(mutable)
        }
    }
    @Composable
    fun ShowText(mutable:MutableData){
    
    
     Text(text = mutable.data) // 会随着state的变化而变化
    }

在上面的代码中，MutableData是一个不稳定的对象，因为它有一个Var类型的变量data,当点击按钮改变状态时，mutable会修改data,对于ShowText来说，参数mutable在状态改变前后都指向同一个对象，因此仅仅靠equals判断会认为参数没有发生变化，但实际上测试发现ShowText函数发生了重组，所以Mutabledata参数类型是不稳定的，equals结果不可信。

所以对于一些默认不被认为是稳定类型的，比如interface或者list等集合类，如果能够确保其在运行时的稳定，可以为其添加@State注解，编译器会将这些类型视为稳定类型，从而发挥只能重组的作用，提升性能。代码如下所示：

@Stable
interface UiState<T>{
    
    
    val value:T?
    val exception:Throwable?
    val hasError:Boolean
        get() = exception != null
}

注意： 被添加为@Statble的普通父类、密封类、接口等其派生子类也会被认为时稳定的