[[403134]]

各位看官好，上一篇文章我們聊了一下關于 OTA 升級過程中，新的軟件包是如何從開發者的電腦上，安全的下載到嵌入式設備中的。

這個流程似乎很簡單，不就是下載一個文件而已嘛，怎么還值得寫成一篇文章呢?

其實這不僅僅是下載文件這么簡單，這其中涉及到如何對眾多的終端設備進行批量升級的策略問題。

如果你親自在 AWS 的平臺上操刀一次，就知道這其中有很多細節問題是需要考慮的。

一失足成千古恨哪!一旦設備升級策略忽略了一個小細節，也許某一天就是我們的深淵!

包括產品的生產過程也是如此，那些踩過的坑，真是一把鼻涕一把淚，這個問題后面有時間專門寫一篇。

今天，我們繼續 OTA 升級過程中后續的階段。

還記得我們之前的假設嗎?

設備中正在執行的 V1 版本的程序，包括這 3 個文件，它們位于文件系統中的 /root/app 目錄下：

• main: 主程序;
• config.ini: 配置文件(包括一個配置項：version=V1_0);
• mylib.so: 實現了某個算法的動態庫，被 main 程序調用;

現在，新的版本 V2 優化了算法，壓縮包名稱是 app_V2.0.tgz，其中包括文件：

• main: 沒有變化;
• config.ini: 配置項修改了：version=V2_0;
• mylib.so: 優化了算法，主要就是想升級這個動態庫;
• upgrade.sh: 一個腳本程序，新增的文件;

升級包 app_V2.0.tgz 已經被下載到設備本地的文件系統中了，假設解壓到目錄 /root/upgrade 中。

現在需要做的事情就是：新版本程序，去替代 /root/app 目錄中的舊版本程序。

upgrade.sh 升級腳本

我們首先要明白一個問題：執行升級指令、下載壓縮包，都是此刻正在執行的 main 程序來執行的。

如果把復制替換的操作也讓 main 程序來執行的話，肯定是會出問題的：它不可能去復制一個新的 main 文件，來把自己替換掉!

寫過單片機程序的小伙伴肯定都知道：當新的固件下載到 flash 之后，一般都是重新啟動設備，然后由 bootloader 來執行具體的文件復制操作。

那么對于帶有文件系統的設備來說，也可以模仿類似的操作方式。

比如：當設備重新啟動后，當執行 /etc/rc.local 時，此時 main 應用程序還沒有啟動。

此時就可以在 rc.local 這個文件中去做升級操作。

但是這樣的方式，相當于是輕微的侵入了操作系統，總感覺這樣做不太好。

此刻， upgrade.sh 升級腳本開始登場了!

這個腳本文件的主要作用就是用來控制升級過程。

這里隱藏這一個很重要的思想：upgrade.sh 是放在升級包中的，它并沒有固化在終端設備中。

這樣的話，每次執行升級任務時，都可以根據本次的升級需要，來靈活的編寫升級腳本。

換句話說：只要能保證升級的通道沒有問題，那么升級的過程就完全由這個腳本文件來控制，你想怎么搞，就怎么搞!

完全升級

所謂的完全升級，就是把舊版本的程序全部丟棄，把升級包中的新程序全部復制過去。

此時，升級腳本文件 upgrade.sh 就完成下面這幾個主要工作：

1. 停止(kill)當前正在執行的 V1.0 版本的程序;
2. 刪除 /root/app 目錄下的所有舊文件;
3. 把升級包中所有的新版本文件 /root/upgrade/* 復制到 /root/app 目錄下;

這樣的完全升級方式是最無腦、最粗魯的。

當然，還有一些細節問題是需要考慮的。比如：如果復制文件過程中出現錯誤怎么辦?

還有一點，既然剛才提到了配置文件 config.ini，不知您是否會有這樣一個疑問：

如果配置信息被用戶修改了，那么升級之后，所有的配置信息又被恢復為默認值了，用戶的私人配置信息全丟了怎么辦?

關于這個問題，我們就繼續來聊一下增量升級!

增量升級

所謂的增量升級：就是升級時并不會把所有的文件全部進行替換，而只是替換那些需要更新的文件。

對于我們假設的升級場景，只需要做 2 件事情：

• 替換 mylib.so 庫文件;
• 把配置文件 config.ini 中的版本字段修改為：version=V2_0;

同樣的，所有的升級過程仍然是寫在 upgrade.sh 這個升級腳本中：

• 停止(kill)當前正在執行的 V1.0 版本的程序;
• 把 /root/upgrade/mylib.so 文件復制到 /root/app 目錄下;
• 使用 sed 命令來修改 config.ini 文件中的 version 字段;

PS：此時升級包中，只需要包含必要的文件就可以了，不需要把其他用不到的文件也放進去了。

從我描述的文字來看，似乎完全升級和增量升級差別不大。

這是因為這里的示例太簡單，如果是一個比較復雜的、有多個模塊相互配合的應用程序，增量升級的優勢就明顯了。

關于 OTA 升級過程，就先說這么多了，主要是以思想為主，畢竟每一個項目的需求場景是不一樣的，從大方向上明白 OTA 的升級過程就可以了。

本文轉載自微信公眾號「IOT物聯網小鎮」，可以通過以下二維碼關注。轉載本文請聯系IOT物聯網小鎮公眾號。