Jetpack Compose中使用带@Composable方法的类替代函数是否为良好实践？

用类封装Composable组件不属于Jetpack Compose的推荐良好实践，绝大多数场景下优先使用函数式组件实现。

Compose从设计之初就遵循声明式UI的函数式范式，函数式组件天然适配Compose的重组机制：只要组件的输入参数发生变化，就会自动触发重组，不需要开发者手动管理实例的生命周期，也不会出现类实例意外留存导致的内存泄漏、状态残留等问题。

你给出的第一种类实现写法，存在几个很难规避的问题：

• 你需要手动管理类实例的创建和留存：如果重组时每次都新建Component实例，会带来不必要的性能开销；如果用remember持有实例，又额外增加了维护成本。
• 类内部的自定义属性如果没有接入Compose的状态体系（比如没有用mutableStateOf包裹），很容易出现属性更新后不触发UI重组的问题，排查成本很高。
• 不符合Compose生态的通用开发约定，其他开发者接手代码时需要额外的理解成本，也无法直接复用官方提供的各类组合式API、修饰符扩展能力。

如果你的组件需要封装大量和UI无关的业务逻辑，且这部分逻辑需要独立于UI生命周期存在，可以把这部分逻辑单独抽成普通业务类，用remember或者ViewModel持有实例，再作为参数传入函数式组件即可，不需要把@Composable渲染方法放到类内部。

类实现的写法（不推荐） #

使用时你还需要额外处理实例留存：

@Composable
fun ParentScreen() {
    // 手动remember留存实例，否则每次重组都会新建对象
    val component = remember { Component() }
    component.render()
}

函数式组件的写法（推荐） #

直接调用即可，参数变化自动触发重组，符合Compose设计逻辑：

@Composable
fun ParentScreen() {
    Component(doSomething = { /* 执行业务逻辑 */ })
}

内容的提问来源于stack exchange，提问作者Omar Khaled