一、功能流程图
图 1：设备唤醒功能整体流程示意图
二、版本要求
为确保唤醒功能稳定性和完整性，需满足以下版本要求：
- 服务器版本：建议升级到
3.4.12.0及以上； - P2P SDK版本：建议升级到
3.4.0及以上。
三、Demo参考
SDK 提供完整的唤醒功能示例代码，可直接参考集成，Demo路径如下：
SDK/Sample/Linux/Sample_IOTCAPIs/IOTCAPIs_WakeUp
说明：Demo 包含保活配置、唤醒包处理、链路检测等核心逻辑，可基于该示例快速适配产品。
四、保活方式
设备需通过与服务器建立保活链路，确保服务器能正常下发唤醒指令。支持 TCP 和 UDP 两种方式，推荐双链路混合策略。
（一）各保活方式特性对比
不同保活方式的优缺点及适用场景如下：
- UDP 保活
- 优势：轻量化、功耗低、传输效率高；
- 劣势：无连接特性，无法直接感知设备掉线（服务器后续将新增回应开关）；
- 端口获取：通过 SDK 提供的 API 动态获取。
- TCP 保活
- 优势：面向连接，支持 TCP Keep-Alive 机制，可通过 Socket 状态直接判断设备是否掉线；
- 劣势：相对 UDP 功耗略高、连接建立成本稍大；
- 端口选择：支持
80、443、8000、8080、21047中的任意一个（建议优先选择 80/443，兼容性更强）。
- TCP+UDP 双链路混合（推荐）
- 优势：结合 TCP 掉线检测能力和 UDP 低功耗特性，可靠性最高；
- 适用场景：主流低功耗设备（如摄像头、传感器等），需兼顾唤醒成功率和功耗控制。
（二）保活关键配置
保活参数配置直接影响功耗和唤醒可靠性，建议按以下标准设置：
- 心跳包间隔40-60 秒
- 说明：间隔越短，设备在线状态更新越及时，唤醒响应越快，但功耗越高；需根据产品功耗预算平衡调整。
- TCP Keep-Alive 配置
- 需开启系统层 TCP Keep-Alive，建议配置：探测间隔 30s，探测次数 3 次（具体配置参考操作系统文档）；
- 作用：确保 TCP 链路长期有效，避免被路由器/防火墙断开连接。
五、保活建议
为提升唤醒成功率，需合理规划保活服务器数量，平衡可靠性与功耗：
- 建议最少向 2 台服务器 保活（从获取到的服务器列表中随机选取），支持以下组合：
- 组合1：2台 TCP 服务器；
- 组合2：2台 UDP 服务器；
- 组合3：1台 TCP + 1台 UDP 服务器（推荐，兼顾可靠性和功耗）。
- 保活服务器数量与唤醒成功率、功耗的关系：
- 服务器越多：唤醒成功率越高（避免单服务器故障导致唤醒失败），但设备功耗越高；
- 产品设计需权衡：低功耗场景（如电池供电设备）可选择 2 台服务器；高可靠性场景（如工业设备）可增加至 3-4 台。
六、低功耗设备对接流程
对接优化建议
- 链路故障处理：某链路连续3次断开或者心跳无响应，立即切换备用服务器，保障唤醒通道；
- 功耗测试：部署前测试不同心跳间隔功耗，选择产品最优值；
- 兼容性测试：在家庭WiFi、4G/5G、企业内网等环境中验证保活稳定性和唤醒成功率。
七、注意事项
技术细节
1. 唤醒包粘包处理：服务器下发的唤醒包可能存在多个包粘包的情况，设备端需按以下规则处理：
- 设备本地需保存唤醒包的标准长度（如 32 字节）；
- 收到数据后，仅取前 N 字节（N=本地保存的唤醒包长度）进行比对，忽略后续粘包数据；
- 示例：本地唤醒包长度为 32 字节，收到 64 字节数据时，仅比对前 32 字节是否匹配唤醒包格式。
2. 端口兼容性：TCP 保活端口需避开设备已占用的端口，建议在初始化时检测端口可用性，优先选择 80/443（大部分网络环境不会封禁）。
3. 链路恢复：若检测到某条保活链路断开（如 TCP Socket 报错、UDP 多次无响应），需在 30 秒内重新建立连接，避免影响唤醒可用性。
