Android蓝牙持久连接疑问：Fragment与Activity生命周期差异及最佳实践

Q1 为什么旋转屏幕时Fragment不会断开蓝牙连接，但Activity会？ #

这个差异的核心来自配置变更（屏幕旋转属于配置变更）下两个组件的生命周期行为不同：

• 官方示例中MainActivity仅在savedInstanceState == null（即Activity首次创建，不是配置变更后的重建）时才会创建新的BluetoothChatFragment实例。配置变更触发Activity销毁重建时，FragmentManager会自动恢复之前的BluetoothChatFragment实例，且该实例不会触发onDestroy生命周期（仅销毁视图层），因此mChatService.stop()不会被调用，蓝牙连接会被保留。
• 你自行实现的Activity版本中，每次屏幕旋转都会触发Activity的完全销毁流程：旧Activity实例会执行onDestroy，调用mChatService.stop()断开蓝牙连接；新的Activity实例重建后，mChatService被重置为null，会重新初始化蓝牙服务，因此表现为连接断开。

Q2 对应需求的最佳实践 #

你要实现的单Activity多Fragment共享蓝牙连接的场景，确实可以通过ViewModel + LiveData实现最优架构，具体设计方案如下：

• 组件职责划分
  • 定义和MainActivity生命周期绑定的BluetoothViewModel，在ViewModel内部直接封装整个BluetoothChatService的实例化、启动、停止、消息收发逻辑。ViewModel的生命周期独立于Activity的视图层，配置变更时不会被销毁，天然保证蓝牙连接实例全局唯一、不会被意外中断。
  • 仅在ViewModel的onCleared方法（仅当Activity真正销毁，比如用户主动退出应用时触发）中调用mChatService.stop()释放连接资源，避免配置变更时误断连接。
• 通信逻辑改造
  • 不需要保留原来的Handler实现，直接用LiveData承载所有需要通知到视图层的数据：比如连接状态、收到的消息、错误提示等。BluetoothChatService的状态变化、新消息回调直接给对应LiveData post值即可。
  • MainActivity观察连接状态的LiveData，收到更新后直接同步到ActionBar显示即可。
  • 所有业务Fragment直接获取MainActivity范围内的BluetoothViewModel实例，既可以观察LiveData接收数据，也可以调用ViewModel的公共方法发送蓝牙消息，实现全局共享同一个连接。

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