OTA (空中升级) 最佳实践
在嵌入式设备的全生命周期管理中，OTA（Over-The-Air）空中升级是保障设备稳定性、修复漏洞和发布新功能的关键机制。
本文档将详细介绍 DejaOS 的 OTA 设计哲学、实现策略以及如何处理升级过程中的异常情况。
核心设计哲学：应用驱动
DejaOS 的设计初衷是将系统资源最大化地让渡给业务应用。由于嵌入式设备的 CPU 和内存资源相对有限，DejaOS 并未内置 一个消耗资源的系统级后台 OTA 服务。
所有的 OTA 逻辑——包括更新检查、下载、校验、安装和失败处理——都由开发者的业务应用本身负责。
这种设计模式带来了极高的灵活性：
- 您可以根据业务需求定制更新策略（如：仅在空闲时段更新）。
- 您可以完全控制 UI 交互（如：显示自定 义的进度条或提示）。
- 您可以集成任意的后台协议（HTTP, MQTT, WebSocket 等）。
为了简化开发，DejaOS 提供了封装好的 dxOta 组件，您可以直接使用或作为参考实现。
关于 OTA 升级的基本流程说明，请参考 应用程序打包、安装和升级。
标准更新流程
无论是计划性更新还是按需更新，一个健壮的 OTA 流程通常包含以下四个步骤：
+----------+ +------------+ +----------+
| 设备应用 | | 后台服务器 | | 文件系统 |
+----------+ +------------+ +----------+
| | |
| 1. 检查更新 (上报版本) | |
|------------------------------>| |
| | |
| 2. 返回新版本信息 (URL, MD5) | |
|<------------------------------| |
| | |
| (判断需要更新) | |
| | |
| 3. 下载固件包 (.dpk) | |
|------------------------------>| |
| | |
| 4. 返回文件流 | |
|<------------------------------| |
| | |
| 5. 保存临时文件 | |
|-------------------------------------------------------------->|
| | |
| 6. 校验 MD5 | |
| | |
| [校验通过] | |
| | | |
| +-------------------------------------------------->| 7a. 移动到安装目录
| | | |
| +------------------>| 8a. 重启设备 (触发系统安装) |
| | |
| [校验失败] | |
| | | |
| +-------------------------------------------------->| 7b. 删除临时文件
| | | |
| +------------------>| 8b. 上报校验失败 |
| | |
1. 检查更新
应用携带当前版本号向服务器发起请求。
2. 下载固件
应用根据服务器返回的 URL 下载 .dpk 格式的固件包。
3. 完整性校验 (关键)
这是防止设备“变砖”的第一道防线。 下载完成后，应用必须在本地计算文件的 MD5 值，并与服务器提供的 MD5 值进行比对。
- 匹配：说明文件完整，可以进行安装。
- 不匹配：说明文件下载不完整或已损坏。此时必 须放弃更新，删除临时文件，并可选择上报错误。
4. 安装与重启
校验通过后，将固件包放置在系统指定的更新目录，然后调用系统重启接口。DejaOS 的引导程序会在启动时自动解压并覆盖旧应用。
常见更新策略
1. 计划性更新 (后台静默检查)
适用于大多数常规业务场景。
- 实现方式：在应用内启动一个定时器（setInterval 轮询）。
- 策略：例如每天凌晨 2:00 触发一次检查流程。
- 逻辑：
- 应用定时通过 HTTP(S) 访问后台。
- 后台根据版本号判断是否需要升级。
- 如下载成功并校验通过，则在业务空闲期重启设备。
2. 按需更新 (实时推送)
适用于紧急修复或特定设备的定向升级。
- 实现方式：利用 MQTT 长连接或扫描二维码。
- 策略：
- MQTT: 后台向特定
Topic发布升级指令，设备收到消息后立即启动下载流程。 - 二维码: 运维人员现场扫描包含升级信息的二维码，触发应用内的升级逻辑。
- MQTT: 后台向特定
进度监控与文件限制
进度跟踪
虽然 dxOTA 组件封装了大部分逻辑，但您依然可以通过底层的 dxHttpClient 实现精细的进度监控。
- 利用
onProgress回调获取下载进度。 - 结合关键事件（“开始下载”、“校验成功”、“准备重启”），通过 MQTT 或 HTTP 实时向后台上报状态。
文件大小限制
DejaOS 系统本身对 OTA 包大小没有硬性限制，主要受限于硬件规格：
- Flash 空间：必须有足够空间同时存放当前应用、下载的安装包以及解压后的临时文件。
- RAM 空间：解压过程需要消耗内存。
- 经验值：小屏设备应用通常 < 5MB，大屏设备应用通常 < 50MB。
故障恢复机制
DejaOS 采用“无缝替换”机制，没有传统操作系统的双分区自动回滚功能，但提供了多重保障机制。
1. 校验阶段的保障
如前所述，MD5 校验失败会直接终止更新，旧版本应用不受任何影响，设备继续正常运行。
2. 安装阶段的保障
文件覆盖过程是原子性的。除非升级过程中强行断电，否则失败的概率极低。
3. 灾难恢复：安全模式 (Safe Mode)
这是应对应用级故障（例如：新版本代码逻辑错误导致启动即崩溃，设备无法联网）的最终手段。
- 什么是安全模式：一个独立于业务应用的微型系统管理界面，内置于 DejaOS 固件中。
- 运行机制：安全模式不是系统常驻的后台应用。它仅在设备重启时短暂启动（若未触发则直接进入业务应用）。退出安全模式后，系统会自动加载并运行您的业务应用。
- 如何进入：
- 设备启动（重新上电）。
- 在启动的最初 2 秒 内（此时屏幕通常显示灰色背景），长按屏幕。
- 系统将进入安全模式界面（密码保护）。
- 如何恢复：
- 在安全模式界面中配置网络（Wi-Fi 或 有线）。
- 界面会显示设备的 IP 地址。
- 通过局域网内的电脑浏览器访问该 IP。
- 在网页端输入正确的固件包 URL，手动执行应用安装。
安全模式 是手动的、用于灾难恢复的“最后一道保险”，确保设备在应用彻底崩溃的情况下，依然可以通过网络被修复，而无需返厂。