包括产品的生产过程也是如此,那些踩过的坑,真是一把鼻涕一把泪,这个问题后面有时间专门写一篇。
今天,我们继续 升级过程中后续的阶段。
还记得我们之前的假设吗/p>
设备中正在执行的 版本的程序,包括这 个文件,它们位于文件系统中的 目录下:
main: 主程序;
config.ini: 配置文件(包括一个配置项:version=V1_0);
mylib.so: 实现了某个算法的动态库,被 main 程序调用;
现在,新的版本 优化了算法,压缩包名称是 ,其中包括文件:
main: 没有变化;
config.ini: 配置项修改了:version=V2_0;
mylib.so: 优化了算法,主要就是想升级这个动态库;
upgrade.sh: 一个脚本程序,新增的文件;
升级包 已经被下载到设备本地的文件系统中了,假设解压到目录 中。
现在需要做的事情就是:新版本程序,去替代 目录中的旧版本程序。
我们首先要明白一个问题:执行升级指令、下载压缩包,都是此刻正在执行的 程序来执行的。
如果把复制替换的操作也让 程序来执行的话,肯定是会出问题的:它不可能去复制一个新的 文件,来把自己替换掉!
这里隐藏这一个很重要的思想: 是放在升级包中的,它并没有固化在终端设备中。
这样的话,每次执行升级任务时,都可以根据本次的升级需要,来灵活的编写升级脚本。
关于这个问题,我们就继续来聊一下增量升级!
所谓的增量升级:就是升级时并不会把所有的文件全部进行替换,而只是替换那些需要更新的文件。
对于我们假设的升级场景,只需要做 件事情:
替换 mylib.so 库文件;
把配置文件 config.ini 中的版本字段修改为:version=V2_0;
同样的,所有的升级过程仍然是写在 这个升级脚本中:
停止(kill)当前正在执行的 V1.0 版本的程序;
把 /root/upgrade/mylib.so 文件复制到 /root/app 目录下;
使用 sed 命令来修改 config.ini 文件中的 version 字段;
PS:此时升级包中,只需要包含必要的文件就可以了,不需要把其他用不到的文件也放进去了。
另外,不知道是否有小伙伴对于 中的升级流程感兴趣,下次再专门写一篇 模组,如何与 后台通过 指令进行交互,以及固件的下载、升级流程。
推荐阅读
【1】C语言指针-从底层原理到花式技巧,用图文和代码帮你讲解透彻
【2】一步步分析-如何用C实现面向对象编程
【3】原来gdb的底层调试原理这么简单
【4】内联汇编很可怕吗完这篇文章,终结它!
【5】都说软件架构要分层、分模块,具体应该怎么做
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!