桥接模式概述：桥接设计模式在Android中的用途、Compose与传统View的交互本质、SDK生命周期对接难点
桥接模式（Bridge Pattern）是一种结构型设计模式，核心思想是将抽象部分与实现部分解耦，使二者可以独立变化。在 Android 开发中，该模式主要用于解决界面层与业务逻辑层之间的紧耦合问题，尤其在需要集成多个第三方 SDK 时，能够保持界面代码的稳定性和可测试性。
课程关键理解：桥接模式在 Compose + SDK 场景中充当“界面 - 生命周期 - 提供方”三层之间的绝缘层，让 Compose UI 无需关心 SDK 内部的生命周期回调，SDK 也无需感知是 Compose 还是传统 View 在管理界面。
1. 桥接模式在 Android 中的典型用途
- 分离 UI 与业务：Activity/Fragment 只需持有桥接对象，不直接调用 SDK 方法。
- 支持多种实现：同一个抽象接口可对接不同 SDK（如支付、地图、推送），只需更换具体桥接类。
- 独立扩展：新增 UI 交互方式（如从传统 View 迁移到 Compose）时，不需要修改 SDK 集成逻辑。
| 维度 | 传统 Android (View) | Jetpack Compose |
|---|---|---|
| 界面创建 | XML 布局 + findViewById | @Composable 函数声明式 |
| 生命周期 | Activity/Fragment 生命周期回调 | CompositionLocal、LifecycleOwner |
| SDK 对接方式 | 直接持有 SDK 实例，在 onResume/onPause 中调用 | 通过 AndroidView/remember 桥接到传统生命周期 |
| 桥接模式作用 | 将 SDK 接口封装成独立抽象，与 View 解耦 | 抽象同样适用，但生命周期联调更复杂 |
2. Compose 与传统 View 的交互本质
Compose UI 本身运行在 Composition 上下文中，不直接继承 Android 组件生命周期。当需要在 Compose 中集成传统 View（如 MapView、WebView 或播放器 SurfaceView）时，必须使用 AndroidView 或 AndroidComposeView 进行“桥接”。此时，桥接模式天然适合：将传统 View 的生命周期回调（onAttach、onDetach）抽象为接口，Compose 通过 DisposableEffect 与 LifecycleEventEffect 进行生命周期绑定。
本质关系：Compose 的 Side-effect（LaunchedEffect、DisposableEffect）承担了传统 LifecycleObserver 的角色，而桥接模式将 SDK 所需的初始化、暂停、恢复、销毁等操作封装成统一的抽象实现。
3. SDK 生命周期对接难点
- 生命周期不同步：Compose 的 Composition 可能随 recomposition 多次重建，而 SDK 通常期望稳定的 Activity/Fragment 生命周期。
- 上下文依赖：多数 SDK 需要 Activity 或 Application 上下文，Compose 中获取
LocalContext.current后还需确保类型安全。 - 回调线程：SDK 生命周期回调（如 onLocationChanged、onMessageReceived）常运行在非主线程，需桥接到 Compose 的协程作用域。
- 多实例冲突：当多个 Composable 同时使用同一 SDK 实例时，易出现重复初始化或资源泄漏。
注意：切忌直接在 Composable 函数体内调用 SDK 的
start()/stop() 方法，这会导致每次重组时重复执行。必须通过 remember 稳定桥接对象，并使用 DisposableEffect 执行清理。