Android Kotlin中启动Activity时Lambda回调偶发未初始化异常排查

1. 全局静态变量的竞态与脏数据问题 #

companion object中的callback是全局静态变量，不存在自动重置机制：

• 当多次调用play()方法（比如快速连续触发），后一次的赋值会直接覆盖前一次的回调。如果前一个启动的MainActivity还未执行onResume，就可能被后一次的异常流程（比如启动Activity失败未完成赋值）影响，导致前一个Activity执行onResume时读取到未初始化的callback。
• MainActivity因配置变更（如旋转屏幕）销毁重建后，静态变量的旧值可能已经失效或被其他流程修改，重建后的Activity读取时就会触发异常。

2. 启动流程与赋值的时序不一致 #

Android的Activity启动是异步调度的：

• 调用play()后，系统需要时间完成Activity的创建、入栈等操作，如果play()里的callback赋值被线程调度延迟，或者系统资源紧张导致Activity启动流程被插队，就会出现MainActivity的onResume先于callback赋值完成的情况。
• 极端场景下，系统可能因内存不足回收了未走到onResume的MainActivity，后续恢复时静态callback已经被其他操作覆盖或清空，触发未初始化异常。

3. 线程安全隐患 #

如果play()被多线程调用，静态变量callback的赋值操作并非原子性的：

• 多线程并发赋值时，可能出现赋值未完成就被onResume读取的情况，此时变量处于未初始化的中间状态，直接触发异常。

临时修复建议 #

• 在onResume中先判断callback状态，避免直接调用：

  override fun onResume() {
      if (::callback.isInitialized) {
          callback.invoke()
          // 执行后清空，避免脏数据影响后续调用
          callback = {}
      }
  }
  

• 给play()的赋值操作加同步锁，保证原子性：

  fun play(callback: () -> Unit) {
      synchronized(this) {
          this.callback = callback
      }
      // 启动MainActivity的逻辑
  }
  

长期优化方案 #

• 抛弃静态变量传递回调的方式，改用Intent传递实现Parcelable接口的回调封装类（Lambda无法直接序列化，需转为接口实现）。
• 结合ActivityResultAPI+ViewModel实现跨组件回调，利用组件生命周期绑定的特性，避免全局静态变量带来的状态污染问题。

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