第 1 章 多设备作用域问题背景
在物联网与多设备协同场景中，每个设备都是一个独立的运行时单元，拥有各自的资源、生命周期与依赖图。当应用需要跨设备共享状态、服务和数据时，传统的单进程依赖注入框架（如 Dagger / Hilt 的标准 @Singleton 作用域）不再适用。设备碎片化、依赖共享需求与生命周期不一致构成了作用域边界管理的核心矛盾。
1.1 三大核心问题
| 问题维度 | 具体表现 | 对作用域的影响 |
|---|---|---|
| 设备碎片化 | 硬件型号、操作系统版本、屏幕规格、网络能力各异 | 同一依赖在不同设备上的实现可能不同，作用域需按设备类型或物理身份隔离 |
| 依赖共享需求 | 多个设备需要共享认证令牌、传感器融合数据、控制指令队列 | 若作用域完全隔离则无法共享，若使用全局单例则破坏独立性 |
| 生命周期不一致 | 主设备常驻运行，子设备可能频繁休眠/唤醒/断连 | 依赖的创建与销毁需与设备连接生命周期对齐，而非与应用进程生命周期绑定 |
关键洞察：三个问题交织在一起，导致无法用单一作用域（如
@ActivityScoped 或 @ApplicationScoped）同时满足隔离性与共享性。必须引入可组合、可嵌套的多设备作用域边界。
1.2 作用域边界定义
在 Hilt 中，作用域边界通过自定义注解与组件绑定来声明。针对多设备场景，边界定义需覆盖三个层级：
- 物理设备身份：通过设备 ID 或连接会话标识符区分。
- 依赖生命周期：依赖的存活范围必须与设备连接或业务会话一致。
- 共享粒度：允许在部分设备子集（如同一房间内的设备组）间共享实例。
典型边界声明采用以下伪配置形式：
@DeviceScoped(deviceId = "sensor01")
public class SensorManager { … }
@GroupScoped(groupName = "living_room")
public class RoomStateAggregator { … }1.3 模块分层与组件职责
为管理多设备作用域，模块应分为三层：
- 底层设备抽象层：提供设备发现、连接管理、会话 ID 生成接口。
- 设备作用域组件层：注册 Hilt 自定义组件（如
@DeviceComponent），绑定设备级依赖。 - 业务共享层：通过 Hilt 的
@EntryPoint或自定义作用域桥接实现跨设备依赖注入。
1.4 数据流与控制流
数据流通常从设备传感器 → 设备本地作用域 → 组作用域聚合 → 主设备决策节点。控制流则涉及依赖的创建、替换和销毁。当子设备断开连接时，其作用域容器应被清除，相关依赖也随之释放。
| 流向 | 说明 | 作用域边界 |
|---|---|---|
| 传感器数据上报 | 每 100ms 推送一次 | 设备作用域内过滤，组作用域内聚合 |
| 控制指令下发 | 从主设备到子设备 | 需经过认证链路，作用域间通过消息总线传递 |
1.5 信任链路与选型权衡
多设备作用域间的依赖共享必须经过信任验证。Hilt 本身不提供跨进程认证，选型时需结合设备绑定密钥或会话令牌。权衡因素包括：
- 使用 Hilt 自定义组件 vs. 手动管理的依赖容器：Hilt 提供编译期验证但需要自定义组件注册。
- 作用域嵌套深度：过深的作用域链会增加依赖查找开销。
- 是否依赖
@AssistedInject：动态设备 ID 可借助 Factory 注入。
风险点提示：
- 作用域泄露：子设备断开后未及时销毁导致内存泄漏。
- 循环依赖：跨设备作用域间互相引用导致编译失败。
- 状态不一致：共享依赖在多个设备上出现缓存击穿。
1.6 落地步骤与验收标准
第 1 章暂不展开详细实施，但给出顶层路线图：
- 步骤 1：定义设备 ID 生成与生命周期回调。
- 步骤 2：创建自定义 Hilt 组件（如
@DeviceComponent）并绑定作用域。 - 步骤 3：实现设备连接 → 作用域创建 → 依赖注入的闭环。
- 验收标准：各设备实例独立，共享依赖在预期范围内一致；断开后资源回收率 ≥ 99.9%；注入路径编译通过。