Twitter Compose Rules 最佳实践指南

Twitter Compose Rules 最佳实践指南

Jetpack Compose 作为现代 Android UI 开发工具包，其声明式编程模型带来了全新的开发范式。Twitter 团队开源的 Compose Rules 项目提供了一系列 Compose 开发的最佳实践规则，本文将深入解析这些规则背后的设计理念和实现原理。

状态管理规范

状态提升原则

Compose 基于单向数据流理念构建：数据/状态向下流动，事件向上触发。实现这一理念的核心是状态提升模式 - 将状态向上提升到可组合项的调用方，使大多数可组合函数保持无状态。

关键实践：

• 避免向下传递 ViewModel 或 DI 对象
• 避免向下传递 State<Foo> 或 MutableState<Bar> 实例
• 应该传递必要的数据和可选的回调 lambda

这种模式带来诸多优势，包括更简单的测试和更可预测的行为。

状态记忆化

使用 mutableStateOf 等状态构建器时，必须确保使用 remember 保留实例。否则每次重组都会创建新的状态实例，导致状态丢失。

// 正确做法
val count = remember { mutableStateOf(0) }

// 错误做法 - 重组时状态会重置
val count = mutableStateOf(0)

不可变注解的使用

Compose 编译器会推断值类的不可变性和稳定性，但有时推断可能不准确。使用 @Immutable 注解可以显式标记类为不可变，帮助编译器优化性能。

@Immutable
data class User(val name: String, val age: Int)

避免不稳定的集合

Kotlin 集合接口（如 List、Map）不能保证真正的不可变性。Compose 编译器无法确定其稳定性，可能导致不必要的重组。

解决方案：

1. 使用 Kotlinx 不可变集合：

val list: ImmutableList<String> = persistentListOf()

2. 包装集合并添加注解：

@Immutable
data class StringList(val items: List<String>)

可组合函数设计规范

避免可变类型参数

遵循"状态向下流动，事件向上触发"原则，不应将可变状态作为参数传递。状态突变应通过回调 lambda 显式建模。

反模式：

@Composable
fun Counter(count: MutableState<Int>) {
    Button(onClick = { count.value++ }) { /*...*/ }
}

推荐模式：

@Composable
fun Counter(count: Int, onCountChange: (Int) -> Unit) {
    Button(onClick = { onCountChange(count + 1) }) { /*...*/ }
}

单一职责原则

可组合函数应要么发射布局内容，要么返回值，但不能同时做两件事。控制回调和参数应通过函数参数提供。

单一内容发射

一个可组合函数应最多发射一个布局节点，保持内聚性。不应依赖调用方的布局上下文。

反模式：

@Composable
fun UserProfile() {
    Text("Name")  // 多个发射点
    Image(/*...*/)
}

推荐模式：

@Composable
fun UserProfile() {
    Column {
        Text("Name")
        Image(/*...*/)
    }
}

命名规范

1. CompositionLocal：以 Local 为前缀，如 LocalContext
2. 多预览注解：以 Previews 为后缀，如 DarkLightPreviews
3. 可组合函数：
   • 返回 Unit 的函数使用大写开头（视为声明式实体）
   • 返回值的函数使用小写开头（遵循 Kotlin 函数命名规范）

参数顺序规范

参数排序应遵循：

1. 必需参数在前
2. 可选参数在后
3. Modifier 作为第一个可选参数

@Composable
fun Button(
    text: String,          // 必需
    onClick: () -> Unit,   // 必需
    modifier: Modifier = Modifier,  // 第一个可选
    enabled: Boolean = true        // 其他可选
) { /*...*/ }

依赖管理规范

显式依赖注入

避免在可组合函数体内直接获取 ViewModel 或 DI 实例，应通过参数显式声明依赖。

反模式：

@Composable
fun MyScreen() {
    val vm = viewModel<MyViewModel>()  // 隐式依赖
}

推荐模式：

@Composable
fun MyScreen(
    vm: MyViewModel = viewModel()  // 显式依赖
) { /*...*/ }

CompositionLocal 谨慎使用

CompositionLocal 创建隐式依赖，应谨慎使用。确实需要时，应通过 allowlist 机制管理。

Modifier 使用规范

始终提供 Modifier 参数

公开组件应提供 Modifier 参数，允许调用方自定义组件样式和行为。

@Composable
fun FancyButton(
    onClick: () -> Unit,
    modifier: Modifier = Modifier  // 提供默认值
) {
    Button(
        onClick = onClick,
        modifier = modifier
            .background(/*...*/)
            .padding(/*...*/)
    ) { /*...*/ }
}

不要重用 Modifier

传递的 Modifier 应仅用于单个布局节点，避免多个组件共享同一 Modifier 实例。

反模式：

Column(modifier) {
    Text(modifier.clickable())  // 重用 modifier
    Image(modifier.size())      // 会导致意外行为
}

推荐模式：

Column(modifier) {
    Text(Modifier.clickable())  // 新建 Modifier
    Image(Modifier.size())      // 新建 Modifier
}

避免 Modifier 扩展工厂函数

使用 @Composable 构建 Modifier 扩展会导致不必要的重组。应使用 Modifier.composed 替代，将重组限制在 Modifier 实例级别。

反模式：

@Composable
fun Modifier.customModifier(): Modifier {
    val color = remember { /*...*/ }
    return this.then(/*...*/)
}

推荐模式：

fun Modifier.customModifier() = composed {
    val color = remember { /*...*/ }
    this.then(/*...*/)
}

总结

Twitter Compose Rules 提供了一套全面的 Compose 开发最佳实践，涵盖了状态管理、组件设计、依赖注入和 Modifier 使用等关键方面。遵循这些规范可以：

1. 提高代码的可维护性和可测试性
2. 优化重组性能
3. 确保组件行为的一致性和可预测性
4. 促进团队协作和代码一致性

这些规则不仅适用于 Twitter 内部项目，也为广大 Compose 开发者提供了宝贵的经验参考。