MolerandKremeCN
09c352457d
Co-authored-by: KremeCN <3265494849@qq.com> Reviewed-on: #9 Co-authored-by: mxhsnd <2049295946@qq.com>
607 lines
19 KiB
Markdown
607 lines
19 KiB
Markdown
# 红外学习与发射控制设计
|
||
|
||
## 1. 背景与目标
|
||
|
||
本项目当前可用于真实验证的设备包括 ABox 主机、红外控制器、智能插座和温湿度计。本阶段由 moler 负责红外能力，范围聚焦于红外控制器的基础闭环：
|
||
|
||
1. 在登录成功后的现有页面提供一个临时入口；
|
||
2. 手动配置并记住一个 ABSDK 红外设备名；
|
||
3. 创建并命名多个红外按键；
|
||
4. 通过 ABSDK 发起红外学习；
|
||
5. 保存可重复使用的按键绑定；
|
||
6. 通过 ABSDK 发射已学习按键；
|
||
7. 支持 Fake 和真实 ABSDK 调试模式；
|
||
8. 为后续生活场景保留稳定按键引用。
|
||
|
||
首版前端只用于功能验证，沿用现有 Compose 和设计系统基础组件，不定义最终产品视觉风格。后续统一视觉改版只替换展示层，不改变红外领域、持久化、应用用例或硬件接口。
|
||
|
||
## 2. 已确认的 ABSDK 能力边界
|
||
|
||
ABSDK 0630 提供以下红外公开方法：
|
||
|
||
```java
|
||
ABRet sendIr(String irDevName, String irKey)
|
||
ABRet studyIrByIrDevName(String irDevName, String irKey)
|
||
ABRet downloadIrCodes(List<IrInfo> irInfos)
|
||
```
|
||
|
||
现有领域层已将其隔离为 `InfraredGateway`：
|
||
|
||
```kotlin
|
||
interface InfraredGateway {
|
||
suspend fun sendKey(
|
||
profileId: ProviderProfileId,
|
||
deviceName: DeviceName,
|
||
key: String,
|
||
): DomainResult<Unit>
|
||
|
||
suspend fun learnKey(
|
||
profileId: ProviderProfileId,
|
||
deviceName: DeviceName,
|
||
key: String,
|
||
): DomainResult<Unit>
|
||
|
||
suspend fun downloadCodes(
|
||
profileId: ProviderProfileId,
|
||
codes: List<InfraredCode>,
|
||
): DomainResult<List<InfraredCodeDownloadResult>>
|
||
}
|
||
```
|
||
|
||
本设计必须遵守以下事实：
|
||
|
||
- 学习接口只确认返回成功码和消息，没有已确认的原始红外码返回值；
|
||
- ABSDK 没有公开停止学习方法；
|
||
- ABSDK 没有公开获取学习结果或读取已学习原始码的方法；
|
||
- `downloadIrCodes()` 是把调用方已经拥有的红外码写入主机，不是读取学习结果；
|
||
- ABSDK 没有设备扫描或设备列表接口；
|
||
- 红外方法按 `irDevName + irKey` 寻址；
|
||
- SDK 调用为同步阻塞调用，现有 Bridge 在 `Dispatchers.IO` 上通过全局 `Mutex` 串行执行；
|
||
- SDK 使用固定明文 HTTP 目标，真实接入存在已知传输安全风险。
|
||
|
||
因此首版保存的是本地按键绑定，而不是原始红外波形或码值：
|
||
|
||
```text
|
||
ProviderProfileId + DeviceName + sdkKey + displayName + learning status
|
||
```
|
||
|
||
真实硬件闭环成立的判据是：
|
||
|
||
```text
|
||
learnKey(deviceName, sdkKey) 成功
|
||
↓
|
||
sendKey(deviceName, sdkKey)
|
||
↓
|
||
实体被控设备产生正确响应
|
||
```
|
||
|
||
## 3. 范围
|
||
|
||
### 3.1 本阶段包含
|
||
|
||
- 红外功能的领域模型和本地持久化端口；
|
||
- Room 数据库、DAO 和 Repository；
|
||
- 学习、重试、发射、删除和恢复应用用例；
|
||
- 红外 ViewModel 和简单 Compose 页面；
|
||
- 登录成功页面的临时红外入口；
|
||
- 手动输入并记住一个 `irDevName`；
|
||
- 单红外控制器、多按键；
|
||
- Fake/Real ABSDK 显式调试模式；
|
||
- 自动化测试；
|
||
- 真机验收清单；
|
||
- 面向未来生活场景的稳定按键引用。
|
||
|
||
### 3.2 本阶段不包含
|
||
|
||
- 最终 UI 视觉规范或复杂遥控器布局；
|
||
- 多个遥控器管理界面；
|
||
- ABSDK 不存在的设备扫描；
|
||
- 原始红外码读取或持久化；
|
||
- 红外码库导入 UI；
|
||
- 硬件停止学习；
|
||
- 完整生活场景模型、规则引擎或场景执行器；
|
||
- Release 中默认启用真实 ABSDK；
|
||
- 绕过或隐藏厂商明文 HTTP 风险；
|
||
- 删除 ABox 服务端已学习按键。
|
||
|
||
## 4. 架构
|
||
|
||
采用独立应用编排层，保持现有 `InfraredGateway` 作为纯硬件能力端口：
|
||
|
||
```text
|
||
登录成功页面
|
||
└─ 临时入口：红外控制
|
||
↓
|
||
InfraredControlScreen
|
||
↓
|
||
InfraredControlViewModel
|
||
↓
|
||
应用用例
|
||
├─ LearnInfraredKey
|
||
├─ RetryInfraredKeyLearning
|
||
├─ SendInfraredKey
|
||
├─ DeleteInfraredKey
|
||
├─ RecoverInterruptedInfraredLearning
|
||
└─ ObserveInfraredKeys
|
||
↙ ↘
|
||
InfraredKeyRepository InfraredGateway
|
||
↓ ├─ FakeInfraredGateway
|
||
RoomInfraredKeyRepository └─ AbsdkBridge
|
||
↓
|
||
ABSDK 0630
|
||
```
|
||
|
||
### 4.1 边界原则
|
||
|
||
- `InfraredGateway` 只负责学习、发射和码库下载，不负责 Room、页面状态或遥控器管理；
|
||
- 不修改 `learnKey()` 返回类型，不虚构 ABSDK 原始码结果；
|
||
- 不把 `ABSDK`、`ABRet`、`IrInfo` 或原始 Map 暴露给上层；
|
||
- ViewModel 不直接编排数据库和硬件之间的一致性，统一通过应用用例；
|
||
- Room Entity 不作为领域或 UI 公共模型；
|
||
- Fake 和真实 Bridge 必须共用相同的领域接口和用例；
|
||
- 所有真实 Gateway 接口必须指向同一个进程级 `AbsdkBridge` 实例，保持全局会话和互斥锁一致。
|
||
|
||
## 5. 数据模型
|
||
|
||
### 5.1 稳定标识
|
||
|
||
```kotlin
|
||
@JvmInline
|
||
value class InfraredKeyId(val value: String)
|
||
|
||
data class InfraredKeyRef(
|
||
val profileId: ProviderProfileId,
|
||
val keyId: InfraredKeyId,
|
||
)
|
||
```
|
||
|
||
`InfraredKeyRef` 是未来生活场景使用的最小稳定引用。场景不应保存显示名、设备名或厂商 Key。
|
||
|
||
### 5.2 学习状态
|
||
|
||
```kotlin
|
||
enum class InfraredKeyStatus {
|
||
LEARNING,
|
||
READY,
|
||
FAILED,
|
||
}
|
||
```
|
||
|
||
状态表示 App 对最近一次学习调用结果的本地记录，不代表设备主动上报的实时状态。
|
||
|
||
### 5.3 领域模型
|
||
|
||
```kotlin
|
||
data class SavedInfraredKey(
|
||
val id: InfraredKeyId,
|
||
val profileId: ProviderProfileId,
|
||
val deviceName: DeviceName,
|
||
val displayName: String,
|
||
val sdkKey: String,
|
||
val status: InfraredKeyStatus,
|
||
val lastErrorCode: String?,
|
||
val createdAtEpochMillis: Long,
|
||
val updatedAtEpochMillis: Long,
|
||
)
|
||
```
|
||
|
||
字段约束：
|
||
|
||
- `id` 在 App 内稳定，供页面、删除和未来生活场景引用；
|
||
- `profileId` 用于不同登录配置的数据隔离；
|
||
- `deviceName` 是传给 ABSDK 的真实红外设备名；
|
||
- `displayName` 是用户可见名称，可以修改；
|
||
- `sdkKey` 是传给 ABSDK 的稳定 Key，学习后不随显示名改变；
|
||
- `lastErrorCode` 仅保存脱敏厂商错误码，不保存密码、Token、原始 Map 或红外载荷；
|
||
- 时间字段由应用层时钟提供，测试中使用可控时钟。
|
||
|
||
### 5.4 SDK Key
|
||
|
||
App 自动生成 SDK Key，不允许用户直接编辑。格式应：
|
||
|
||
- 仅包含安全 ASCII 字符；
|
||
- 在同一 Provider 和红外设备下唯一；
|
||
- 重试学习时复用；
|
||
- 修改显示名时保持不变；
|
||
- 不直接使用中文、空格或特殊字符。
|
||
|
||
建议格式：
|
||
|
||
```text
|
||
app_ir_<normalized-infrared-key-id>
|
||
```
|
||
|
||
实际长度上限尚未由 ABSDK 文档确认，实现前需选择保守长度，并列入真机验证。
|
||
|
||
## 6. 本地持久化
|
||
|
||
采用 Room。Repository 边界至少支持：
|
||
|
||
```kotlin
|
||
interface InfraredKeyRepository {
|
||
fun observeKeys(
|
||
profileId: ProviderProfileId,
|
||
deviceName: DeviceName,
|
||
): Flow<DomainResult<List<SavedInfraredKey>>>
|
||
|
||
suspend fun getKey(
|
||
ref: InfraredKeyRef,
|
||
): DomainResult<SavedInfraredKey?>
|
||
|
||
suspend fun insertLearningKey(
|
||
key: SavedInfraredKey,
|
||
): DomainResult<Unit>
|
||
|
||
suspend fun updateStatus(
|
||
ref: InfraredKeyRef,
|
||
status: InfraredKeyStatus,
|
||
lastErrorCode: String?,
|
||
updatedAtEpochMillis: Long,
|
||
): DomainResult<Unit>
|
||
|
||
suspend fun renameKey(
|
||
ref: InfraredKeyRef,
|
||
displayName: String,
|
||
updatedAtEpochMillis: Long,
|
||
): DomainResult<Unit>
|
||
|
||
suspend fun deleteKey(
|
||
ref: InfraredKeyRef,
|
||
): DomainResult<Unit>
|
||
|
||
suspend fun findInterruptedLearning(
|
||
profileId: ProviderProfileId,
|
||
): DomainResult<List<SavedInfraredKey>>
|
||
}
|
||
```
|
||
|
||
具体签名可在实施计划中按项目既有风格调整，但必须保持职责和语义。
|
||
|
||
### 6.1 数据库约束
|
||
|
||
- 主键：`InfraredKeyId`；
|
||
- 索引：`ProviderProfileId + DeviceName`；
|
||
- 唯一约束：`ProviderProfileId + DeviceName + sdkKey`；
|
||
- 查询和删除必须包含 Provider 隔离；
|
||
- 不保存原始红外码；
|
||
- 不把 Room Entity 暴露给领域层；
|
||
- 首版预留 schema version 和迁移测试基础。
|
||
|
||
### 6.2 单设备策略
|
||
|
||
页面记住一个当前 `irDevName`，并只展示该设备下的按键。切换当前设备名不会迁移或重写旧按键；旧按键仍绑定学习时使用的设备名。
|
||
|
||
设备名可以保存到 Room 配置表或 DataStore。若采用 DataStore，只用于当前设备名和 debug 模式等轻量配置，不承载红外按键集合。
|
||
|
||
## 7. 学习流程
|
||
|
||
`LearnInfraredKey` 的流程：
|
||
|
||
1. 验证用户已登录且存在有效 `ProviderProfileId`；
|
||
2. 验证 `deviceName` 和 `displayName` 非空；
|
||
3. 生成稳定 `InfraredKeyId` 和 `sdkKey`；
|
||
4. 先写入状态为 `LEARNING` 的记录；
|
||
5. 在应用级协程作用域调用 `InfraredGateway.learnKey()`；
|
||
6. 成功时更新为 `READY` 并清空错误码；
|
||
7. 失败时更新为 `FAILED` 并保存脱敏错误码；
|
||
8. 如果状态更新失败，记录可恢复的本地数据错误，但不重新生成 SDK Key；
|
||
9. 页面通过 Room Flow 观察最终状态。
|
||
|
||
### 7.1 重试
|
||
|
||
重试必须：
|
||
|
||
- 使用原 `InfraredKeyId`；
|
||
- 使用原 `sdkKey`；
|
||
- 先将状态更新为 `LEARNING`；
|
||
- 再调用 ABSDK；
|
||
- 不创建重复按键记录。
|
||
|
||
### 7.2 页面离开
|
||
|
||
学习调用开始后，页面可以退出。任务继续在应用级作用域等待 SDK 返回，并更新 Room。ViewModel 销毁不应直接取消已经提交的学习编排。
|
||
|
||
这不是后台系统任务保证：如果进程被系统杀死，底层同步网络请求及设备状态无法可靠恢复。
|
||
|
||
### 7.3 进程恢复
|
||
|
||
App 启动或登录恢复后，查找遗留的 `LEARNING` 记录：
|
||
|
||
```text
|
||
LEARNING → FAILED
|
||
错误提示：上次学习结果未确认，请重新学习
|
||
```
|
||
|
||
不得自动标记为 `READY`，也不得自动发射来试探设备状态。
|
||
|
||
### 7.4 取消语义
|
||
|
||
ABSDK 没有停止学习 API。首版 UI 不提供或宣称“停止硬件学习”。用户可以离开页面，但学习调用仍等待成功、失败或 SDK 超时。
|
||
|
||
## 8. 发射流程
|
||
|
||
`SendInfraredKey` 的流程：
|
||
|
||
1. 使用 `InfraredKeyRef` 查询本地记录；
|
||
2. 记录不存在时返回领域错误；
|
||
3. 仅允许 `READY` 状态发射；
|
||
4. 取得记录中的 `profileId + deviceName + sdkKey`；
|
||
5. 调用 `InfraredGateway.sendKey()`；
|
||
6. 成功时向 UI 返回一次性成功事件；
|
||
7. 失败时保留按键 `READY` 状态，仅报告本次错误；
|
||
8. 不自动重试，避免重复操作电视、空调等实体设备。
|
||
|
||
未来生活场景通过稳定 `InfraredKeyRef` 调用同一发送用例或薄执行器：
|
||
|
||
```kotlin
|
||
interface InfraredActionExecutor {
|
||
suspend fun execute(ref: InfraredKeyRef): DomainResult<Unit>
|
||
}
|
||
```
|
||
|
||
本阶段只定义或保证稳定引用边界，不实现 Scene 模型、规则引擎或场景执行顺序。
|
||
|
||
## 9. 删除与重命名
|
||
|
||
### 9.1 删除
|
||
|
||
- `FAILED` 和 `READY` 记录可以删除；
|
||
- `LEARNING` 中不允许删除，避免后台结果写入已不存在的记录；
|
||
- 删除只移除本地引用；
|
||
- ABSDK 没有删除服务端红外 Key 的公开接口；
|
||
- UI 必须提示“ABox 服务端可能仍保留该按键”；
|
||
- 删除后未来场景引用解析失败，不再发射。
|
||
|
||
### 9.2 重命名
|
||
|
||
- 只修改 `displayName`；
|
||
- 不修改 `id`、`deviceName` 或 `sdkKey`；
|
||
- 重命名后学习和发射能力保持不变；
|
||
- 场景引用保持有效。
|
||
|
||
## 10. Android 前端
|
||
|
||
### 10.1 临时入口
|
||
|
||
在当前登录成功后的页面添加“红外控制”按钮，导航到独立 `InfraredControlScreen`。未来正式信息架构完成后只迁移入口。
|
||
|
||
### 10.2 页面内容
|
||
|
||
首版页面只包含：
|
||
|
||
- 返回按钮和标题；
|
||
- 当前数据源标识：Fake 或真实 ABox；
|
||
- 红外控制器设备名输入和保存；
|
||
- 已学习按键列表；
|
||
- 学习新按键按钮；
|
||
- 按键状态；
|
||
- READY 按键的发射按钮；
|
||
- FAILED 按键的重试按钮；
|
||
- 删除入口和确认提示；
|
||
- 基础错误反馈。
|
||
|
||
不加入复杂遥控器模板、图标系统、网格布局、品牌色或动画规范。
|
||
|
||
### 10.3 设备名
|
||
|
||
- ABSDK 没有设备扫描能力；
|
||
- 首次进入时手动填写 `irDevName`；
|
||
- 保存后本地记住；
|
||
- 没有设备名时禁止学习；
|
||
- 修改设备名前提示旧按键仍绑定旧设备；
|
||
- 列表只显示当前设备名下的按键。
|
||
|
||
### 10.4 学习交互
|
||
|
||
用户输入显示名称后开始学习。页面提示：
|
||
|
||
```text
|
||
请将实体遥控器对准红外控制器并按下目标按键。
|
||
```
|
||
|
||
按键显示 `LEARNING`、`READY` 或 `FAILED`。允许离开页面，但不显示“停止硬件学习”。
|
||
|
||
### 10.5 发射交互
|
||
|
||
- 只有 `READY` 按键可发射；
|
||
- 发射期间禁用该按键，防止重复点击；
|
||
- 成功显示短暂提示；
|
||
- 失败显示具体错误；
|
||
- 不自动重试；
|
||
- 单次失败不删除或降级按键状态。
|
||
|
||
### 10.6 删除提示
|
||
|
||
删除确认文案应明确：
|
||
|
||
```text
|
||
仅从本机列表移除，ABox 服务端可能仍保留该按键。
|
||
```
|
||
|
||
## 11. Debug Fake/Real 路由
|
||
|
||
Debug 构建提供显式运行模式：
|
||
|
||
- `FAKE`：页面开发、自动化测试和错误模拟；
|
||
- `REAL_ABSDK`：复用当前登录会话，调用真实 `AbsdkBridge`。
|
||
|
||
约束：
|
||
|
||
- 页面持续显示当前模式；
|
||
- 不允许在学习任务进行中切换模式；
|
||
- Fake 和 Real 共用同一 ViewModel、应用用例和 Room Repository；
|
||
- 模式和 Provider 数据必须隔离，避免 Fake 按键误用于真实设备；
|
||
- Fake 支持按 `ProviderProfileId + DeviceName + sdkKey` 配置成功或失败；
|
||
- 真实模式的所有 Gateway 接口绑定同一 `AbsdkBridge` 单例；
|
||
- 真实模式必须显式 opt in `CleartextAbsdkTransport`；
|
||
- Release 暂不启用真实 Bridge，除非项目明确批准传输安全方案。
|
||
|
||
真实 App 接入还必须补齐：
|
||
|
||
- `:absdk-bridge` 依赖；
|
||
- Hilt 绑定；
|
||
- `INTERNET` 权限；
|
||
- 经批准的明文网络配置；
|
||
- 登录会话与红外 Gateway 的同一 Bridge 实例；
|
||
- Token 失效后的页面返回登录流程。
|
||
|
||
## 12. 错误处理
|
||
|
||
继续使用现有 `DomainResult` 和 `DomainError`。不为首版扩充 sealed 类型，优先利用已有分类和 `externalCode`。
|
||
|
||
| 情况 | UI 反馈 | 本地状态 |
|
||
|---|---|---|
|
||
| Token 无效 | 登录已失效，返回登录 | 学习按键为 FAILED；发射按键仍为 READY |
|
||
| 红外设备不存在 | 检查设备名 | 学习按键为 FAILED |
|
||
| 红外设备离线 | 检查供电和网络 | 学习按键为 FAILED；发射按键仍为 READY |
|
||
| KEY/码值不存在 | 建议重新学习 | 发射按键仍为 READY，由用户决定重学 |
|
||
| 红外发射失败 | 显示失败，可手动重试 | READY |
|
||
| 网络超时 | 网络或 ABox 服务不可用 | 学习按键为 FAILED；发射按键仍为 READY |
|
||
| 本地保存失败 | 无法开始学习 | 不调用硬件学习 |
|
||
| 学习成功但最终状态写入失败 | 显示数据保存异常并保留恢复信息 | 不生成新 sdkKey |
|
||
| 未知错误 | 通用提示及脱敏错误码 | 按操作类型处理 |
|
||
|
||
日志不得包含：
|
||
|
||
- 用户密码；
|
||
- Token；
|
||
- 原始 SDK Map；
|
||
- 原始红外码或载荷；
|
||
- 可用于重放的敏感字段。
|
||
|
||
## 13. 自动化测试
|
||
|
||
### 13.1 应用用例
|
||
|
||
覆盖：
|
||
|
||
1. 学习前先保存 `LEARNING`；
|
||
2. 学习成功更新为 `READY`；
|
||
3. 学习失败更新为 `FAILED`；
|
||
4. 重试复用原 `sdkKey`；
|
||
5. 修改显示名不改变 `sdkKey`；
|
||
6. 只有 `READY` 可以发射；
|
||
7. 发射使用保存的 `deviceName + sdkKey`；
|
||
8. 不同 Provider 数据隔离；
|
||
9. 遗留 `LEARNING` 恢复为 `FAILED`；
|
||
10. 删除后稳定引用失效；
|
||
11. ViewModel 销毁后应用级学习任务仍可落库；
|
||
12. 发射失败不改变 READY；
|
||
13. 进行中的学习阻止运行模式切换。
|
||
|
||
### 13.2 Room
|
||
|
||
覆盖：
|
||
|
||
- 新增、观察、查询、重命名和删除；
|
||
- `ProviderProfileId + DeviceName` 过滤；
|
||
- `sdkKey` 唯一约束；
|
||
- Provider 隔离；
|
||
- 状态转换；
|
||
- 稳定 ID 跨重命名不变；
|
||
- 首版 schema 和迁移测试基础；
|
||
- 不存储原始红外载荷。
|
||
|
||
### 13.3 Fake
|
||
|
||
扩展现有 Fake，覆盖：
|
||
|
||
- 按 Provider、设备和 Key 脚本化结果；
|
||
- 调用参数与顺序；
|
||
- 连续响应；
|
||
- 成功、离线、超时和通用失败；
|
||
- 不同 Provider 互不影响。
|
||
|
||
### 13.4 Bridge
|
||
|
||
保留现有覆盖并补充：
|
||
|
||
- 学习参数和调用顺序；
|
||
- 发射参数和调用顺序；
|
||
- 红外错误码 `20201` 至 `20206` 的映射；
|
||
- 学习、发射与其他设备调用的全局串行；
|
||
- Token 失效清理会话；
|
||
- SDK 空值和异常防御；
|
||
- 不改变 `downloadCodes()` 的部分成功语义。
|
||
|
||
### 13.5 ViewModel 与 Compose
|
||
|
||
只验证功能，不验证最终视觉：
|
||
|
||
- 无设备名不能学习；
|
||
- 保存和恢复设备名；
|
||
- 创建学习任务；
|
||
- 显示学习中、成功和失败；
|
||
- 重试学习；
|
||
- 点击发射并防重复点击；
|
||
- 删除确认；
|
||
- Fake/Real 模式标识；
|
||
- 登录失效引导；
|
||
- 基本中文和英文资源。
|
||
|
||
## 14. 真机验收
|
||
|
||
第一轮使用现有 ABox 主机和红外控制器：
|
||
|
||
1. 登录真实账号；
|
||
2. 输入后台提供的准确 `irDevName`；
|
||
3. 创建唯一按键，例如“测试电源”；
|
||
4. 调用学习并记录耗时、返回码和消息；
|
||
5. 学习成功后立即发射；
|
||
6. 验证实体电器是否响应；
|
||
7. 用同一按键重复发射；
|
||
8. 重新学习同一 `sdkKey`，验证覆盖或报错行为；
|
||
9. 红外控制器断电后验证离线错误；
|
||
10. 不按实体遥控器，验证实际超时行为；
|
||
11. 页面退出后验证后台结果落库；
|
||
12. 进程被杀后验证遗留 LEARNING 恢复；
|
||
13. Token 失效后验证返回登录；
|
||
14. 记录 SDK 是否存在未文档化 `dicDatas`，但不将内容写入生产日志。
|
||
|
||
### 14.1 必须验证的未知项
|
||
|
||
- 学习调用是立即返回还是阻塞到捕获完成；
|
||
- 学习成功是否自动绑定 `sdkKey`；
|
||
- 同一 `sdkKey` 重学是否覆盖；
|
||
- 无信号时实际超时时间；
|
||
- 页面离开后底层调用是否可完成；
|
||
- 设备名格式、大小写和特殊字符规则；
|
||
- 服务端是否永久保留已学习 Key；
|
||
- SDK 是否返回未文档化数据；
|
||
- `sdkKey` 的长度限制；
|
||
- 真实模式所需初始化信息和调用顺序。
|
||
|
||
这些未知项不得通过业务层假设隐藏。真机结果应更新协议文档和后续设计。
|
||
|
||
## 15. 验收标准
|
||
|
||
本阶段完成需要满足：
|
||
|
||
- 登录成功页面可以进入简单红外页面；
|
||
- 可以手动配置并恢复一个红外设备名；
|
||
- 可以创建多个命名按键；
|
||
- 学习调用前已持久化 LEARNING；
|
||
- 学习成功或失败能正确落库；
|
||
- READY 按键可以调用发射；
|
||
- 显示名修改不影响发射；
|
||
- Fake 模式可以覆盖主要状态和错误；
|
||
- Real 模式明确标识并调用真实 Bridge；
|
||
- 页面退出后学习任务仍可更新状态；
|
||
- 进程中断后遗留学习状态可以保守恢复；
|
||
- 自动化测试通过；
|
||
- 真机至少完成一次“学习成功 → 发射 → 实体响应”；
|
||
- 未确认硬件语义被记录，不伪装为已支持；
|
||
- 未来生活场景可以通过稳定 `InfraredKeyRef` 引用按键。
|
||
|
||
## 16. 后续工作
|
||
|
||
本设计完成后再分别规划：
|
||
|
||
1. 多遥控器和房间组织；
|
||
2. 统一产品视觉和正式导航入口；
|
||
3. 红外码库导入；
|
||
4. 生活场景编排；
|
||
5. Scene 顺序执行和单项结果；
|
||
6. 厂商明文 HTTP 的正式安全方案；
|
||
7. 真机验证后对学习语义、超时和错误模型的修订。
|