0.缘起

Flutter中每个Widget的构造方法都会有一个Key，除了标识Widget，在更新或者移动Widget中也有重要作用。Key或类似的机制，在众多GUI框架中都有影子。为解决某些特定问题，在这些框架中，能看到相似的思路，一些限制或者不同，也跟所用的语言、底层的渲染机制相关。
这里以Flutter为主线，介绍Key的同时，横向比较其他GUI框架。

1.Flutter中的Key

Flutter中每个Widget的构造方法都有一个Key，主要为了标识Widget及对应的Element，很多情况下我们并不传这个值。
根据继承关系，Key有LocalKey和GlobalKey两种， 而LocalKey又有ValueKey、ObjectKey、UniqueKey三种子类。

1.1我们使用Key可以解决什么问题？

假如一组StatefulWidget，各自维护自身的State，数据层可能只是一些纯展示类的属性，如文字、图片样式，当我们试图改变数据列表中的顺序，以期待Widget也遵照数据层发生改变时，结果可能并不如预期。
举例，一个简单的Counter计数器，State内维护自身被点击的次数。

class Counter extends StatefulWidget {
    final String label;
  
    const Counter({super.key, required this.label});
  
    @override
    State<Counter> createState() => _CounterState();
  }
  
  class _CounterState extends State<Counter> {
    int _count = 0;
  
    @override
    Widget build(BuildContext context) {
      return GestureDetector(
        onTap: () => setState(() {
          _count++;
        }),
        child: Container(
          margin: const EdgeInsets.all(8),
          color: Colors.blue[200],
          width: 100,
          height: 100,
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              Text(widget.label),
              Text(
                '$_count',
                style: const TextStyle(fontSize: 32),
              ),
            ],
          ),
        ),
      );
    }
  }
  

在页面中摆出3个计数器，分别用['first', 'second', 'third']来标识。在点击FloatingActionButton后，尝试切换顺序为['second', 'third', 'first']

class _MyHomePageState extends State<MyHomePage> {
  List labels = ['first', 'second', 'third'];

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: AppBar(
          title: Text(widget.title),
        ),
        body: Center(
          child: Row(
            mainAxisAlignment: MainAxisAlignment.center,
            children: labels.map((label) => Counter(label: label)).toList(),
          ),
        ),
        floatingActionButton: FloatingActionButton(
          onPressed: () => setState(() {
            labels = ['second', 'third', 'first'];
          }),
          tooltip: 'Increment',
          child: const Icon(Icons.add),
        ));
  }
}

在初始状态下，我们分别点击几次计数器，下面的数字为点击的次数。

当我们点击点击FloatingActionButton后，尝试切换顺序为['second', 'third', 'first']时，发现只是label顺序改变，计数器的数量并没有发生变化。

这里出现了直观的预想与实际代码表现的不一致，原因是Flutter并不会根据label的差异识别是否是相同计数器。这里做一下小的修改，修改Counter的构造函数。

Counter({required this.label}) : super(key: ValueKey(label));

直接将label包装为一个ValueKey。这时再次尝试之前的操作，发现排列确实如预期了。

这个小例子展示了Key的作用，Flutter中判断Widget是否是同一个，依据的是runtimeType和key是否相同。对于有动态刷新和移动等需求的，需要指定唯一Key。

1.2Flutter不同Key的作用

LocalKey和GlobalKey，最终要的差异是LocalKey只比较同级Widget，不去比较父级和子级的Widget。如果需求是修改了Widget Tree的结构，再使用LocalKey就可能状态丢失，因为Flutter在同级中，找不到相同Key，认为Widget被删除了，这种需求需要使用的是GlobalKey。

LocalKey

LocalKey中，三种子类，ValueKey、ObjectKey、UniqueKey。ValueKey和ObjectKey差异在依据什么判断相同。
ValueKey依照判断值相等做判断，Dart语言还是一门强类型语言，判断相等的考虑因素，跟Java中equals方法还挺像。

const ValueKey(this.value)

final T value;

@override
bool operator ==(Object other) {
  if (other.runtimeType != runtimeType)
    return false;
  return other is ValueKey<T>
      && other.value == value;
}

ObjectKey中判断相同的依据除了值相当，还要求对象是同一个。

const ObjectKey(this.value);

final Object? value;

@override
bool operator ==(Object other) {
  if (other.runtimeType != runtimeType)
    return false;
  return other is ObjectKey
      && identical(other.value, value);
}

UniqueKey就直接是object hash了，每次生成的都是唯一的。

class UniqueKey extends LocalKey {
  UniqueKey();

  @override
  String toString() => '[#${shortHash(this)}]';
}

GlobalKey

GlobalKey的使用要比LocalKey更消耗性能，Flutter推荐大家尽量使用LocalKey。GlobalKey目前有两种常见用法：

• 用于Widget Tree有变化的场景，因为LocalKey只比较同级Widget。
• 作为一个跨越Widget的引用，在其他地方能够使用。

在GlobalKey中，有一些很方便的属性。

• currentContext: 可以找到包括renderBox在内的各种element有关的东西
• currentWidget: 可以得到widget的属性
• currentState: 可以得到state里面的变量
  比如有些框架借助GlobalKey拿到ScaffoldMessenger，简化SnackBar操作。

2.Key机制在不同GUI框架的身影

通过上述分析，Flutter的Key大概有两种用法，一种是不同Widget标识，用于判断是否是同一个Widget以达到更新或Widget结构修改，避免状态错误或者丢失。另一种是作为一种全局的Widget引用，可以任何地方拿到Widget或State。

2.1 标识是否为相同Widget

讨论是否为相同Widget这个作用，需要再往背景挖一挖，那就是声明式UI。
在声明式UI之前，都是命令式的操作方式，如dom中的getElementById，如Android中的findViewById。这些都是通过标识拿到dom或者view，此时并没有判断Widget相同的需求。
主流GUI框架都在向着声明式UI发展，在UI= f(State)的思路之下，框架必然要面对的一个问题是，State或者说数据如何映射成为Widget。Flutter中各式各样的Widget有众多属性，同一个界面中很有可能Widget有着相同的属性，如Text中有相同的文字，Image中有相同的图片，State中甚至可能还有相同的状态。开发者感性以为的Widget及状态变化，通过数据传给框架之后，可能会出现误判，此时就需要Key来标识Widget，框架寻找新旧数据的变化，映射为控件树的变化。
这个过程可以抽象为通过新旧数据diff出变化的控件，再标脏渲染。
再深入就是如何高效的diff，如何避免频繁操作RenderObject或真实Dom，如何方便写出没有副作用的渲染函数，这些是声明式UI都要面临的问题，但不是今天讨论的主题。

2.1.1 React

React开发中，或多或少会遇到这样的警告。

Warning: Each child in an array or iterator should have a unique "key" prop.

React的创新之处，在于使用虚拟dom的diff，减少真实dom操作的消耗。key的作用就是用于diff算法中同级节点的对比策略。Flutter中的LocalKey和React中的key作用一致。React中key用于虚拟dom的diff，Flutter中key用于Widget的diff。Flutter中的Widget是非常轻量、消耗低的。

2.1.2 Compose

Compose在渲染列表中，也有可以指定Key的API，在使用LazyColumn或者LazyRow，可以传入一个生成Key的lambda表达式，这里返回类型是Any。

<T : Any?> LazyListScope.items(
    items: List<T>,
    noinline key: ((item) -> Any)?,
    noinline contentType: (item) -> Any,
    crossinline itemContent: @Composable LazyItemScope.(item) -> Unit
)

这里的Key也不需要全局唯一，在组合内唯一即可。
Compose列表中的Key还比较简单，在整个Compositioin做diff触发 Composable 函数更新要复杂的多。Compose处理的diff的树是SlotTable，实际渲染是LayoutNode，与Flutter中的Widget、RenderObject有相似的作用。SlotTable也有Key，但这个Key是编译器帮我们生成的。在编译期，会对我们的Composable函数插入很多Composer的方法。
比如一个计数器:

@Composable
fun Counter() {
 var count by remember { mutableStateOf(0) }
 Button(
   text="Count: $count",
   onPress={ count += 1 }
 )
}

编译后会增加很多composer方法， 也会将composer对象传递到函数体中所有的composable调用处。

fun Counter($composer: Composer) {
 $composer.start(123)
 var count by remember($composer) { mutableStateOf(0) }
 Button(
   $composer,
   text="Count: $count",
   onPress={ count += 1 },
 )
 $composer.end()
}

看Composer#start()中的部分源码可以看到也有类似Key的判断。

//Composer.kt
private fun start(key: Int, objectKey: Any?, isNode: Boolean, data: Any?) {
    //...
    if (pending == null) {
        val slotKey = reader.groupKey
        if (slotKey == key && objectKey == reader.groupObjectKey) {
            // 通过 key 的比较，确定 group 节点没有变化，进行数据比较
            startReaderGroup(isNode, data)
        } else {
            // group 节点发生了变化，创建 pending 进行后续处理
            pending = Pending(
                reader.extractKeys(),
                nodeIndex
            )
        }
    }
    //...
}

第一个参数即是根据代码分析生成的group唯一key。

2.1.3 传统Android UI

作为命令式GUI框架，通过Key判断是否是同一个控件并更新，场景不是那么直观。在RecyclerView中，有那么点数据驱动渲染的感觉。RecyclerView通过Adapter，将数据映射为不同的ViewHolder，触发创建或者更新，对判断为同一item而位置变化的场景，还可以设置item的移动和增删动画。在新的ListAdapter工具中，API只暴露一个submitList方法更新全量数据方法，已经具备数据驱动UI的样子。

public void submitList(@Nullable List<T> list)

RecyclerView判断是否相同有两种不同维度。
一种维度是判断是否为相同类型viewType，可以只更新数据而无需重新创建View，这在创建销毁View非常昂贵的体系中，能够带来不小的性能提升。有些麻烦的是viewType已经规定好了int类型，对于复杂或者非常动态的item场景，计算生成viewType比较麻烦。
另一种维度是判断是否为相同item，通过DiffUtil工具的 areItemsTheSame()和 areContentsTheSame()方法帮助RecyclerView计算哪些position发生了变化。这些机制的设计，使用起来要比Flutter中的key复杂的多。

object FlowerDiffCallback : DiffUtil.ItemCallback<Flower>() {
   override fun areItemsTheSame(oldItem: Flower, newItem: Flower): Boolean {
      return oldItem.id == newItem.id
   }

   override fun areContentsTheSame(oldItem: Flower, newItem: Flower): Boolean {
      return oldItem == newItem
   }
}

在传统Android UI之上，要提一下facebook的Litho库，也是一个声明式UI库，从React借鉴了很多概念。从这个库中能看到大家对传统UI改造的努力，里面有大量的优化手段，如异步加载、拍平布局、更新粒度的复用，但感觉生不逢时。Litho出现的时候，应该还没有kotlin和Compose，Litho最初用Java和注解处理器，创建了一套声明式UI，也是因为没有Compiler IR这种大杀器，API风格和实际使用手感稍显复杂，但响应式的理念是贯彻的最彻底的，因为Litho生成的都是static静态方法，很难出现副作用。在Android逐渐推广Compose的过程中，Litho未来很难有一席之地，但其中优化手段，已经被很多大厂吸收。Litho还在不断迭代，期待有新的变化。
在Litho中，列表更新同样有类似Flutter Key的机制。对于可更新的列表，也要求有能够唯一标识的id，如在LazyListScope中的方法，如果child方法不传id，会根据position生成一个，在children方法中，则需要根据item返回一个id。

fun child(
    component: Component?, 
    id: Any? = null, 
    isSticky: Boolean = false, 
    onNearViewport: OnNearCallback? = null
)
fun <T> children(
    items: Iterable<T>, 
    id: (T) -> Any, 
    componentFunction: ComponentCreationScope.(T) -> Component?
)

2.2全局引用

Flutter中的GlobalKey可以让开发者在其他地方获取到控件进行状态更新，用法显得不那么声明式，完全时命令式的风格，但有些情况还是很方便。
类似Android中findViewById，DOM中getElementById。Flutter通过GlobalKey能获取State、Widget、RenderObject，获取数据或者渲染参数如控件宽高。
在React中，全局引用的控件似乎并没有对应的场景，稍微有点神似的概念是ref，能在React中能脱离数据流props，命令式的操作子组件和DOM。
ref如果进行DOM增删等操作，会脱离React管控，所以一直有不要滥用ref的说法。现在React推荐使用forwardRef和useImperativeHandle，forwardRef的跨层传递和合并转发也有那么一点点破坏单向数据流的原则。