固件激活階段的核心是實(shí)現(xiàn)“無(wú)縫切換”與“安全回退”，依賴(lài)設(shè)備端Bootloader的雙分區(qū)管理能力。校驗(yàn)通過(guò)后，設(shè)備會(huì)更新OTA狀態(tài)區(qū)的“激活標(biāo)記”，指定下一次啟動(dòng)時(shí)加載空閑分區(qū)的新固件，隨后觸發(fā)設(shè)備重啟；重啟后，Bootloader首先讀取OTA狀態(tài)區(qū)，若激活標(biāo)記有效，則初始化新固件所在分區(qū)，驗(yàn)證固件的魔法數(shù)（如固定的0xAA55）與版本兼容性，確認(rèn)無(wú)誤后跳轉(zhuǎn)到新固件執(zhí)行；若新固件啟動(dòng)失敗（如啟動(dòng)后10秒內(nèi)未向Bootloader發(fā)送“啟動(dòng)成功”信號(hào)），Bootloader會(huì)自動(dòng)觸發(fā)回滾機(jī)制，清除激活標(biāo)記，重新加載原固件分區(qū)，確保設(shè)備不會(huì)因新固件故障而“變磚”。部分高端設(shè)備（如STM32H7、ESP32-S3）支持“無(wú)縫升級(jí)”，即在應(yīng)用固件運(yùn)行的同時(shí)，將新固件寫(xiě)入備用分區(qū)，寫(xiě)入完成后無(wú)需重啟，通過(guò)內(nèi)存映射切換直接加載新固件，適用于對(duì)停機(jī)時(shí)間敏感的場(chǎng)景（如醫(yī)療設(shè)備、工業(yè)生產(chǎn)線(xiàn)控制器）。

結(jié)果反饋階段是升級(jí)流程的收尾，設(shè)備需將最終的升級(jí)狀態(tài)（成功/失敗及原因）上報(bào)至云端，便于云端更新設(shè)備版本記錄與調(diào)整策略。若升級(jí)成功，設(shè)備發(fā)送“升級(jí)成功”請(qǐng)求，攜帶新固件版本與啟動(dòng)時(shí)間；云端收到后，將該設(shè)備的版本狀態(tài)更新為新版本，并停止向其推送舊版本升級(jí)指令。若升級(jí)失?。ㄈ缧ｒ?yàn)失敗、激活失?。?，設(shè)備需上報(bào)失敗原因（如“哈希不匹配”“固件啟動(dòng)超時(shí)”），云端記錄失敗信息，根據(jù)原因制定重試策略——例如因“網(wǎng)絡(luò)中斷”失敗的設(shè)備，可在1小時(shí)后重新觸發(fā)升級(jí)；因“固件損壞”失敗的設(shè)備，則需等待云端重新推送正確的固件。

HTTP固件升級(jí)的輕量化優(yōu)化是適配資源受限設(shè)備（如8位MCU、KB級(jí)RAM）的關(guān)鍵，需從協(xié)議棧、內(nèi)存占用、功耗控制三個(gè)維度展開(kāi)。協(xié)議棧層面，選擇專(zhuān)為嵌入式設(shè)計(jì)的輕量級(jí)HTTP Client庫(kù)（如uHTTPc、Mongoose的嵌入式版本），這類(lèi)庫(kù)通常僅保留HTTP/1.1的核心功能（如GET/POST請(qǐng)求、Range頭支持），去除冗余模塊（如Cookie、表單解析），代碼量可控制在10KB以?xún)?nèi)，RAM占用僅需2KB~5KB，遠(yuǎn)低于通用HTTP庫(kù)（如libcurl）。內(nèi)存優(yōu)化方面，除了采用“分塊下載-即時(shí)寫(xiě)入”策略減少RAM占用，還可通過(guò)“固件壓縮”進(jìn)一步降低傳輸與存儲(chǔ)壓力——云端將固件通過(guò)gzip或LZ77算法壓縮，設(shè)備下載后在Flash中直接存儲(chǔ)壓縮固件，激活前再通過(guò)硬件或軟件解壓（如STM32的硬件解壓模塊），壓縮率通?？蛇_(dá)30%~50%，例如1MB的固件壓縮后僅需600KB Flash空間，適配小容量Flash設(shè)備。功耗控制則需與設(shè)備的低功耗模式協(xié)同，例如在固件下載間隙（如等待云端分塊數(shù)據(jù)），讓網(wǎng)絡(luò)模塊（如ENC28J60）進(jìn)入睡眠模式，關(guān)閉未使用的外設(shè)（如UART、I2C），僅保留核心電路供電，將電流從幾十毫安降至微安級(jí)；對(duì)于電池供電設(shè)備（如NB-IoT水表），可選擇在設(shè)備空閑時(shí)段（如夜間用水低谷）執(zhí)行升級(jí)，避免升級(jí)過(guò)程與業(yè)務(wù)數(shù)據(jù)采集爭(zhēng)搶功耗資源。