Jetpack Compose：不使用remember将MutableState设为实例变量的疑问

先看你给出的运行正常的代码：

class MainActivity : ComponentActivity() {

  private var text = mutableStateOf("Hello!")

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      AppTheme {
        Surface(modifier = Modifier.fillMaxSize(), color = MaterialTheme.colorScheme.background) {
          TextField(value = text.value, onValueChange = {
            text.value = it
          })

          Text(text = text.value)
        }
      }
    }
  }
}

针对你的两个疑问，解答如下：

1. 此场景下使用remember的必要性是什么？仅为了将状态隔离到对应的Composable中吗？ #

当然不只是为了隔离，核心原因和Compose的重组机制以及状态生命周期绑定有关：

• Compose的Composable函数会在状态变化时频繁重组，remember的核心作用是让状态在重组过程中保留，不会每次重组都重新初始化。你在Activity里声明的变量本身不会因为重组重置，但问题在于这个状态的生命周期是和Activity绑定的，而非和使用它的Composable绑定。
• 用remember可以把状态的生命周期和所属的Composable绑定：当这个Composable从界面上被移除（比如导航到其他页面），remember保存的状态会被自动回收，避免不必要的内存占用；而Activity里的状态会一直存在到Activity销毁，哪怕对应的Composable已经不在了。
• 另外，remember衍生的rememberSaveable，可以处理屏幕旋转这类配置变更场景，自动保存和恢复状态；而你当前的写法，一旦Activity因配置变更重建，text会被重新初始化为"Hello!"，之前输入的内容直接丢失。
• 从代码结构来说，把状态放在Composable内部（用remember），能让状态和使用它的UI逻辑更紧密，代码更模块化，后续维护、复用这个Composable也更方便。

2. 上述使用可变状态的方式存在哪些弊端？ #

这种把MutableState放在Activity成员变量里的写法，有不少明显的问题：

• 生命周期不匹配：状态的生命周期是Activity级别的，哪怕对应的Composable已经被销毁（比如跳转到其他页面），Activity还持有这个状态，造成内存浪费，甚至如果状态里持有Context相关对象，还可能引发内存泄漏。
• 配置变更丢失状态：当屏幕旋转、语言切换这类配置变更发生时，Activity会重建，你的text变量会被重新初始化，用户之前输入的内容直接丢失，而用rememberSaveable就能解决这个问题。
• 代码耦合度高：状态和Activity绑定，导致使用这个状态的Composable没法独立复用，也没法单独测试这个Composable的逻辑，必须依赖整个Activity环境。
• 扩展能力差：如果后续有多个Composable需要共享这个状态，或者需要把状态逻辑抽离，这种写法几乎没法扩展，远不如用ViewModel这类专门的状态容器灵活。
• 不符合Compose最佳实践：Compose提倡"状态上移/下移"的原则，状态应该尽量靠近使用它的UI组件，让状态的作用域更清晰，这种把状态放在Activity里的写法，会让状态的归属和管理变得混乱，不利于大型项目的维护。

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