大家好，在上一篇我们讲到了OTA升级过程中如何从开发者电脑上安全下载新的软件包。下载到嵌入式设备。这个过程看起来很简单。不就是下载文件吗？为什么值得写一篇文章？其实这不仅仅是下载一个文件那么简单，它涉及到如何批量升级众多终端设备的战略问题。如果你亲自在AWS平台上工作过一次，你就会知道有很多细节需要考虑。一错再错，万古仇恨！一旦装备升级攻略忽略了一个小细节，说不定哪天就是我们的万丈深渊！产品的生产过程也是如此。那些踩过的坑，真是鼻涕泪泪。有时间专门写一篇。今天我们继续OTA升级过程的下一阶段。还记得我们之前的假设吗？V1版本的设备中正在执行的程序包括这3个文件，它们位于文件系统中的/root/app目录下：main：主程序；config.ini：配置文件（包括A配置项：version=V1_0）；mylib.so：实现某种算法的动态库，被主程序调用；现在新版本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升级脚本我们首先要明白一个问题：升级命令的执行和压缩包的下载都是由当前正在执行的主程序执行的。如果复制和替换的操作也由主程序执行，肯定会出现问题：不可能复制一个新的主文件来替换自己！写过MCU程序的朋友一定知道：当新固件下载到flash后，一般会重启设备，然后由bootloader进行具体的文件复制操作。那么对于有文件系统的设备，也可以模仿类似的操作方法。例如：设备重启时，执行/etc/rc.local时，主应用还没有启动。此时就可以在rc.local文件中进行升级操作了。但是这种方式相当于对操作系统进行了轻微的侵入，总觉得这样做不太好。这时开始出现upgrade.sh升级脚本！这个脚本文件的主要作用是控制升级过程。这里隐藏了一个很重要的思想：upgrade.sh放在升级包中，并没有固化在终端设备中。这样每次执行升级任务时，都可以根据本次升级的需要灵活编写升级脚本。也就是说：只要升级通道没有问题，升级过程完全由这个脚本文件控制。你想做什么，就可以做什么！完全升级所谓完全升级就是丢弃所有旧版本的程序，复制升级包中的所有新程序。至此，升级脚本文件upgrade.sh完成了以下主要任务：停止（kill）当前正在执行的V1.0版本程序；删除/root/app目录下的所有旧文件；将新版本文件/root/upgrade/*复制到/root/app目录下；如此完备的升级方式，是最无脑、最粗暴的。当然，还有一些细节需要考虑。例如：在复制文件的过程中出现错误怎么办？还有一点，由于配置文件config。信息已重新恢复为默认值。用户的私有配置信息全部丢失怎么办？关于这个问题，我们继续说说增量升级吧！所有文件都被替换，但只替换那些需要更新的文件。对于我们假设的升级场景，我们只需要做2件事：替换mylib.so库文件；修改配置文件config.ini中的version字段为：version=V2_0；同样，所有的升级过程仍然写在upgrade.sh中，在这个升级脚本中：停止（kill）当前正在执行的V1.0程序；将/root/upgrade/mylib.so文件复制到/root/app目录下；使用sed命令修改config.ini文件中的version字段；PS：此时升级包中只需要包含必要的文件，其他不用的文件不需要放入。从我描述的文字来看，似乎完全升级和增量升级没有太大区别。这是因为这里的例子太简单了。如果是比较复杂的应用，多个模块相互配合，增量升级的优势就很明显了。关于OTA升级过程，先说这么多，主要是思路。毕竟每个项目的需求场景都不一样。从一个大方向了解OTA升级过程就够了。本文转载自微信公众号“IOT物联网小镇”，可通过以下二维码关注。转载本文请联系物联小镇公众号。
