CN110471689A - 一种应用程序升级方法及装置 - Google Patents

Abstract

本申请涉及计算机软件技术领域，提供一种应用程序升级方法及装置。其中，应用程序升级方法包括：从服务器获取升级包，升级包中包括升级文件以及本次升级的规则文件，本次升级的规则文件中包括升级文件的描述信息以及本次升级后需要保活的目标应用程序；根据升级文件的描述信息安装升级文件；运行目标应用程序，并监测目标应用程序的存活状态。一方面，该方法通过监测到的存活状态能够及时发现目标应用程序出现的异常状况。另一方面，该方法在升级完成后可以立即对目标应用程序进行保活，执行方式简单高效，拓展了升级操作的功能。此外，该方法只需要对规则文件进行适当配置就可以实现应用升级，升级包制作也很简单。

Description

一种应用程序升级方法及装置

技术领域

本发明涉及计算机软件技术领域，具体而言，涉及一种应用程序升级方法及装置。

背景技术

根据具体的业务需求，操作系统中安装的一些应用程序需要长时间运行，目前传统的升级工具虽然能够完成应用程序的升级，但并不关心升级后这些应用程序的运行状况如何，从而一旦某些应用程序出现运行异常，可能导致设备瘫痪等严重问题。

发明内容

本申请实施例的目的在于提供一种应用程序升级方法及装置，通过在升级包中的规则文件中指定升级后需要保活的目标应用程序，使得在升级完成后可以对目标应用程序的存活状态进行监测，以便及时发现目标应用运行过程中的异常状况，从而可以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种应用程序升级方法，应用于一电子设备，所述方法包括：从服务器获取升级包，所述升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括所述升级文件的描述信息以及本次升级后需要保活的目标应用程序；根据所述升级文件的描述信息安装所述升级文件；运行所述目标应用程序，并监测所述目标应用程序的存活状态。

在上述方法中，从服务器获取的升级包中除了包括升级文件外，还包括本次升级的规则文件，本次升级的规则文件中既包括升级文件的描述信息，又指定了本次升级后需要保活的目标应用程序，其中，升级文件的描述信息用于升级文件的安装，而目标应用程序则在升级包安装完成后被启动运行，并进行存活状态的监测。

从而，一旦目标应用程序在运行过程中出现了导致其不再存活的异常状况，监测者能够通过判断其存活状态及时发现这些异常状况，并可以采取相应的处理措施，避免出现设备瘫痪等严重问题，维持设备的稳定运行。其中，应用程序存活表明其正常运行，应用程序不再存活表明其未正常运行：例如异常终止、陷入死循环、僵尸进程(应用程序不再运行但资源未释放)等。

同时，上述方法在升级完成后可以立即根据本次升级的规则文件的内容对目标应用程序进行保活，没有其他中间环节，执行方式简单高效，还拓展了升级操作的功能。

此外，上述方法在升级时只依赖升级包中的规则文件，从而，只需要对规则文件进行适当地配置就可以轻松实现应用升级，其升级包制作也非常简单，不像一些现有技术中的升级过程需要单独建立脚本文件，升级包制作比较复杂。

在第一方面的一些实现方式中，所述描述信息包括所述升级文件的版本信息以及安装目录信息，所述根据所述升级文件的描述信息安装所述升级文件，包括：将本次升级的规则文件中的版本信息与所述电子设备本地保存的上次升级的规则文件中的版本信息进行比较；若两个版本信息不同，则将所述升级文件安装至本次升级的规则文件中的安装目录信息所指定的目录下。

通过对比版本信息，就能够快速确定哪些升级文件确实需要安装并将需要安装的升级文件安装到本次升级的规则文件中的安装目录信息所指定的目录下，这一安装方式简单高效。

在第一方面的一些实现方式中，所述描述信息还包括在所述升级文件安装前要执行的操作信息和/或在所述升级文件安装后要执行的操作信息。

升级文件安装前要执行的操作，例如创建安装目录；升级文件安装后要执行的操作，例如使安装的某个配置文件生效。在描述信息中包含这两项信息或者其中之一可以使得安装过程更具灵活性，满足实际的安装需求。

在第一方面的一些实现方式中，所述方法还包括：在所述电子设备启动时，根据所述电子设备本地保存的最近一次升级的规则文件确定需要保活的目标应用程序；运行所述目标应用程序，并监测所述目标应用程序的存活状态。

除了在升级完成后需要对目标应用程序进行保活，若电子设备在运行过程中进行了重新启动，启动后也要对目标应用程序进行保活，确保目标应用程序在电子设备工作期间始终运行并处于受监测的状态。

在第一方面的一些实现方式中，所述升级文件包括：应用程序的程序文件和/或应用程序依赖的文件。

应用程序的程序文件可以是一些可执行的文件，例如代码编译产生的文件；应用程序依赖的文件可以是一些不可执行的，但会被可执行文件所使用的文件，例如资源文件、配置文件等。

在第一方面的一些实现方式中，所述目标应用程序的程序文件的描述信息和其他升级文件的描述信息分别设置在本次升级的规则文件中不同的段落。

将目标应用程序的程序文件的描述信息单独放置在规则文件中的一个段落，方便升级结束后查找目标应用程序，以便将其启动并监测其存活状态。

在第一方面的一些实现方式中，所述监测所述目标应用程序的存活状态，包括：接收所述目标应用程序定期发送的心跳信息，并记录所述心跳信息的接收时间；定期扫描纪录的接收时间，并在判断所述接收时间距离当前时间的间隔未超过预设时长时，确定所述应用程序仍然存活，以及在判断所述接收时间距离当前时间的间隔超过预设时长时，确定所述应用程序不再存活。

正常情况下，目标应用程序定期发送的心跳信息，这个时间间隔通常比预设时长短很多，因此记录的接收时间会很快更新，如果某个目标应用程序对应的接收时间长时间未更新(超过了预设时长)，表明该目标应用程序的运行已经出现异常，无法再按期发送心跳信息，进而可以采取相应的处理措施。在接收心跳信息时，若有多个目标应用程序，可以通过设置ID对其进行区分。

此外，采用心跳的方式进行保活，相较于一些采用检查进程控制符(ProcessIdentifier，PID)的方式，对于目标应用程序陷入循环或者成为僵尸进程的情况也能够及时发现，对于目标应用程序的监测更加精确。

在第一方面的一些实现方式中，所述心跳信息通过用户数据报协议(UserDatagram Protocol，UDP)报文的方式发送。

采用UDP比采用传输控制协议(Transmission Control Protocol，TCP)的实现方式更简单、效率更高，因为发送心跳信息的目的只是告知对方自身仍然存活，并且心跳信息会定期不断地发送，对信息传递的可靠性要求不高。此外，UDP作为一种广泛使用的协议，相较于其他一些进程间的通信方式也更加通用。

在第一方面的一些实现方式中，所述从服务器获取升级包，包括：接收所述服务器发送的升级指令，所述升级指令中携带有升级包的地址；根据所述地址从所述服务器上拉取所述升级包。

用户可以访问服务器(例如，服务器提供的页面)做出升级操作，服务器响应用户做出的升级操作生成升级指令并下发给电子设备，由电子设备执行升级，用户不需要自己输入指令升级，升级过程对普通用户友好。

在第一方面的一些实现方式中，所述升级指令中还携带有校验信息，在所述从服务器获取升级包之后，以及在所述根据所述升级文件的描述信息安装所述升级文件之前，所述方法还包括：利用所述校验信息校验所述升级包中的升级文件的完整性。

升级包在传输过程中可能发生损坏等问题，在升级前先利用校验信息校验升级包中的升级文件的完整性，有利于避免升级过程失败。一旦校验未通过，则可以采取重新下载升级包等措施。

第二方面，本申请实施例提供一种应用程序升级方法，应用于一电子设备，所述电子设备上运行有升级保活服务，所述方法包括：所述升级保活服务从服务器获取升级包，所述升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括所述升级文件的描述信息以及本次升级后需要保活的目标应用程序；所述升级保活服务根据所述升级文件的描述信息安装所述升级文件；所述升级保活服务运行所述目标应用程序，并监测所述目标应用程序的存活状态。

上述方法的步骤和第一方面提供的应用程序升级方法类似，其部分有益效果可以参考前文描述。此外，该方法的步骤均由电子设备上运行的一个升级保活服务来执行，即该服务既能够升级应用程序又能够对升级后的应用程序进行保活，相当于拓展了传统升级程序的功能，无需设置单独的程序来进行目标应用程序的保活，节省了从升级到保活的中间环节，提高了执行效率。

第三方面，本申请实施例提供一种应用程序升级装置，配置于一电子设备，所述装置包括：升级包获取模块，用于从服务器获取升级包，所述升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括所述升级文件的描述信息以及本次升级完成后需要保活的目标应用程序；升级文件安装模块，用于根据所述升级文件的描述信息安装所述升级文件；保活模块，用于运行所述目标应用程序，并监测所述目标应用程序的存活状态。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行前两方面或前两方面的任意一种可能的实现方式提供的方法的步骤。

第五方面，本申请实施例提供一种电子设备，包括存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行前两方面或前两方面的任意一种可能的实现方式提供的方法的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的应用程序升级方法的应用场景的示意图；

图2示出了本申请实施例提供的一种电子设备的结构框图；

图3示出了本申请实施例提供的一种应用程序升级方法的流程图；

图4示出了本申请实施例提供的一种应用程序保活方法的原理图；

图5示出了本申请实施例提供的一种应用程序升级装置的功能模块图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

图1示出了本申请实施例提供的应用程序升级方法的应用场景的示意图。参照图1，该应用场景中包括可相互通信的电子设备100以及服务器200。

其中，电子设备100的操作系统(如Linux、Windows、MacOS、Android、iOS等)上安装有应用程序，这些应用程序中的全部或部分需要升级。

同时，这些应用程序中的全部或部分出于业务需求需要长期运行：例如，某些应用程序是操作系统中的监控程序，不能轻易中断监控；又例如，该电子设备100部署在偏远地区，平时无人对其进行维护，因此其中的一些应用程序需要长期运行。为尽可能保证这些应用程序长期稳定运行，需要对其运行状态进行监控，监控的手段之一是保活。对应用程序进行保活即监测应用程序的存活状态，存活状态可以分为两种：存活和不再存活。其中，应用程序存活表明其正常运行，而应用程序不再存活表明其未正常运行：例如异常终止、陷入死循环、僵尸进程(应用程序不再运行但资源未释放)等。保活的目的在于通过获取到的存活状态及时发现存未正常运行的应用程序，以便采取相应的措施，例如告警、错误排查、重新启动应用程序等等。为方便起见，下文将电子设备安装的应用程序中需要进行保活的应用程序简称为目标应用程序。

服务器200上保存有应用程序的升级包，升级包中包括有升级文件，可用于应用程序的升级。通过一个升级包可以同时对电子设备上安装的一个或多个应用程序进行升级。触发升级行为可以有不同的方式，例如用户可以通过浏览器访问服务器200提供的管理页面并做出升级操作，或者，用户可以通过在某些客户端软件(可与服务器200通信)上输入命令的方式进行升级，等等。至于用户具体在哪里触发升级行为，则不限定，例如可以是在用户自己使用的终端设备上，或者是在上述电子设备100上。在一些情况下，用户难以直接接触电子设备100(例如，电子设备100部署在偏远地区)，则用户可以采用前一种方式触发升级行为。具体的升级过程将在后文阐述。

图2示出了电子设备100的一种可能的结构。参照图2，电子设备100包括：处理器110、存储器120以及通信接口130，这些组件通过通信总线140和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，存储器120包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器110以及其他可能的组件可对存储器120进行访问，读和/或写其中的数据。

处理器110包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器110可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通信接口130包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口130可以是以太网接口；可以是移动通信网络接口，例如3G、4G、5G网络的接口；还是可以是具有数据收发功能的其他类型的接口。

在存储器120中可以存储一个或多个计算机程序指令，处理器110可以读取并运行这些计算机程序指令，以实现本申请实施例提供的应用程序升级方法的步骤以及其他期望的功能。

可以理解，图2所示的结构仅为示意，电子设备100还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。图2中所示的各组件可以采用硬件、软件或其组合实现。

于本申请实施例中，电子设备100可以是，但不限于专用设备、台式机、笔记本电脑、平板电脑、智能手机、智能穿戴设备、车载设备等实体设备，或者虚拟机等虚拟设备。服务器200可以是一台服务器，也可以是多台服务器的组合或者服务器的集群，可以是普通的服务器，也可以是云服务器。

图3示出了本申请实施例提供的一种应用程序升级方法的流程图。该方法可以由，但不限于由上述电子设备100执行。参照图3，该方法包括：

步骤S300：电子设备从服务器获取升级包。

步骤S300有多种实现方式，例如服务器可以主动下发升级包，又例如，在用户触发升级行为后(触发方式见对图1的阐述)，服务器可以将相应的升级指令下发至电子设备，升级指令中携带有升级包的地址，从而电子设备可以根据地址从服务器上拉取升级包。需要指出，下发升级指令的服务器和存放升级包的服务器可以是同一个服务器，也可以不是同一个服务器。

在一些实现方式中，升级指令中可以携带校验信息，电子设备获取到升级包之后，可以利用校验信息校验升级包中的升级文件的完整性，只有在校验成功后才执行后续的升级操作，若校验失败，则可以采取输出提示信息、重新获取升级包等处理措施。由于升级包在从服务器到电子设备的传输过程中可能发生损坏等问题，所以安装升级文件之前先利用校验信息进行文件完整性的校验，有利于避免升级失败或者升级异常。

下面给出一个服务器下发的升级指令的例子：

其中各字段含义如下：

update：表明这是一个升级指令；

id：要升级到的版本；

md5：升级文件的md5值(即上述校验信息的一种实现方式)，采用md5算法计算；

url：升级包的下载地址。

升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括升级文件的描述信息以及本次升级后需要保活的目标应用程序。其中，升级文件的描述信息用于升级文件的安装(见步骤S310)，而目标应用程序则在升级包安装完成后被启动运行，并进行存活状态的监测(见步骤S320)。下面结合一个具体规则文件的例子进行介绍：

最开始的version是本次升级包的版本，后面的部分是规则文件的具体内容。升级包中的升级文件可以分为两类：应用程序的程序文件以及应用程序依赖的文件，当然每次的升级包中不一定要同时包括这两类文件，也可能只包括其中的一类文件。其中，应用程序的程序文件可以是一些可执行的文件，例如代码编译产生的文件；应用程序依赖的文件可以是一些不可执行的，但会被可执行文件所使用的文件，例如资源文件、配置文件等。

在规则文件中，可以划分不同的段落，将升级文件按照某种规则进行归类，方便管理。例如，上面的例子中包括program和config两个段落，其中program段落用于写入目标应用程序的程序文件的描述信息，config段落用于写入目标应用程序依赖的文件的描述信息、其他应用程序(除目标应用程序以外的应用程序)的程序文件的描述信息以及其他应用程序依赖的文件的描述信息。在上面的例子中，mainsys是一个目标应用程序的名字，mainsys紧跟的花括号内是该目标应用程序的程序文件(可能是一个或多个文件)的描述信息；temp.txt是一个应用程序依赖的配置文件的名字，temp.txt紧跟的花括号内是该配置文件的描述信息。

上述段落设置的好处是便于在升级结束后直接从program段落查找目标应用程序，以便将其启动并监测其存活状态(具体见步骤S132)。当然，段落的划分以及段落中写入的内容也可以采取其他的实现方式，例如，在另一种实现方式中，所有应用程序(包括目标应用程序以及其他应用程序)的程序文件的描述信息都可以写入program段落，但在描述信息中增加相应的字段来区分哪些是目标应用程序的程序文件的描述信息，哪些是其他应用程序的程序文件的描述信息。

进一步的，升级文件的描述信息中可以包括升级文件的版本信息以及安装目录信息。例如，mainsys的subversion字段是目标文件的版本信息，dir字段是该目标应用程序的程序文件的安装目录信息；又例如，temp.txt的version字段是该配置文件的版本信息，dir字段是该配置文件的安装目录信息。具体如何使用升级文件的版本信息以及安装目录信息进行升级文件的安装在步骤S310中介绍。

进一步的，升级文件的描述信息还可以包括在升级文件安装前要执行的操作信息和/或在升级文件安装后要执行的操作信息。例如，temp.txt的before_cmd字段是该配置文件安装前要执行的操作信息，after_cmd字段是该配置文件安装后要执行的操作信息，这两项中的任意一项也可以置为空值，表明该配置文件在安装前和/或安装后并不需要执行什么特殊的操作。设置这两个字段主要是为了满足实际的安装需求：例如，安装temp.txt之前，需要先创建一个安装目录，则可以在before_cmd字段写入创建目录相关的操作信息；又例如，安装temp.txt之后，需要将该配置文件生效，则可以在after_cmd字段写入配置文件生效相关的操作信息。

下面再介绍一下一些尚未提到的字段：

mainsys的id字段：该目标应用程序的ID，用于区分不同的目标应用程序，可能在步骤S132中被使用。

temp.txt的type字段：该配置文件的类型，其取值可以是普通文件、可执行文件、压缩包等，例子中的file表示普通文件。

temp.txt的desc字段：该配置文件的描述，内容可以自由指定。

可以理解的，上述例子中的段落、字段名称仅为示例，并且在其他一些实现方式中也可能包括比例子中更多或更少的字段，因此该例子不应视为对本申请保护范围的限制。

步骤S310：电子设备根据升级文件的描述信息安装升级文件。

根据描述信息的内容可以采取不同的方式安装升级文件。例如，在上面的例子中，升级文件的描述信息包括升级文件的版本信息以及安装目录信息，则步骤S310可以这样实现：

步骤A：将本次升级的规则文件中的版本信息与电子设备本地保存的上次升级的规则文件中的版本信息进行比较。

上次升级的规则文件是在上次升级时通过解析升级包获得的，文件结构和本次升级的规则文件是相同的，但升级文件的版本信息以及安装目录信息可能不同。在步骤A中将对应文件的版本信息进行比较，若两个版本信息相同，表明该文件无需升级，可以不进行进一步处理；若两个版本信息不同，表明该文件需要升级，执行步骤B。

在一些情况中，某个文件是本次升级新添加的，上次升级的规则文件中并未保存其版本信息，则可以直接安装该文件。特别地，初始时(电子设备尚未进行过任何升级时)，电子设备上可以保存一个默认的规则文件，以便电子设备第一次升级时步骤A能够正常执行。

步骤B：若两个版本信息不同，则将升级文件安装至本次升级的规则文件中的安装目录信息所指定的目录下。

安装的具体方式可以是从升级包中获取要安装的文件，然后将其移动到本次升级的规则文件中的安装目录信息所指定的目录下，如果目录中有同名的文件，可以将其覆盖掉。对于本次升级的规则文件中进行了描述的升级文件都按照上述步骤A和B依次进行处理，即可以完成本次升级。

例如，对于temp.txt的安装，将本次升级的规则文件中temp.txt的版本信息(temp.txt下的version字段，其值为1.0.1)与上次升级的规则文件中temp.txt的版本信息(假设是1.0.0)进行比较，二者不同，则将本次获取的升级包中的temp.txt安装到temp.txt下的dir字段所指定的目录下，即/root/start-1.0.1/config。

进一步的，在执行步骤A之前，还可以先检查版本信息以及安装目录信息是否合法，例如，若本次升级的规则文件中temp.txt下的dir字段为空，则无法正常安装，此时无需执行后续的步骤A和B。

进一步的，在执行步骤B之前，还可以读取temp.txt下的type字段的内容，确定安装的方式，例如，普通文件可以直接安装，压缩包可以先解压缩后再安装。

此外，在执行步骤B之前，还可以读取temp.txt下的before_cmd字段，确定在安装之前是否要执行某些操作，以及，还可以读取temp.txt下的after_cmd字段，确定在安装之后是否要执行某些操作(after_cmd字段也可以在安装之后再读取)。

升级完成后，可以将本次升级的规则文件在电子设备上保存，在下次升级时该文件的身份将变成上次升级的规则文件。保存的方式既可以是替换掉上次升级的规则文件，也可以是将上次升级的规则文件修改为与本次升级的规则文件一致，也可以是仍然保留上次升级的规则文件，只是使其无效化，不再用于升级。

在上面步骤S310的实现方式中，通过对比版本信息，就能够快速确定哪些升级文件确实需要安装，这一安装方式简单高效。

步骤S320：电子设备运行目标应用程序，并监测目标应用程序的存活状态。

安装完成后，电子设备可以根据本次升级的规则文件中指定的目标应用程序，将这些目标应用程序启动起来(即使目标应用程序在升级前就已经存在，在升级时也会将其关闭，因此升级完成后需要重新启动)。在上面的例子中，可以从program段落获取mainsys的描述信息，描述信息的dir字段记录了mainsys的程序文件的安装目录，从而可以启动mainsys。

监测目标应用程序的存活状态，可以通过以，但不限于以下的方式：

步骤C：接收目标应用程序定期发送的心跳信息，并记录心跳信息的接收时间。

心跳信息的具体形式、所包含的具体内容也不限，只要能够表征目标应用程序仍然在正常运行即可。例如，参考图4，在一些实现方式中，电子设备上可以启动一个UDP服务器400，每个目标应用程序410作为一个UDP客户端定期向UDP服务器400发送UDP报文，该UDP报文即为一种形式的心跳信息。作为对比的，基于UDP实现心跳信息的发送比基于TCP的实现方式更简单、效率更高，因为发送心跳信息的目的只是告知电子设备目标应用程序仍然存活，并且心跳信息会定期不断地发送，对信息传递的可靠性要求不高。此外，UDP作为一种广泛使用的协议，相较于其他一些进程间的通信方式也更加通用。

为实现发送心跳信息的功能，目标应用程序应当实现该功能。或者，可以从外部将具有心跳信息发送功能的程序片段注入到目标应用程序中，使得目标应用程序具有发送心跳信息的功能。

进一步的，由于可能同时存在多个目标应用程序需要保活，为了区分收到的心跳信息，以便准确记录针对每个目标应用程序的接收时间，心跳信息中可以携带目标应用程序的ID，该ID可以写入本次升级的规则文件中，以便电子设备获知ID和目标应用程序的对应关系。例如，在之前的例子中，mainsys的描述信息中的id字段就记录了mainsys对应的ID。

步骤D：定期扫描纪录的接收时间，并在判断接收时间距离当前时间的间隔未超过预设时长时，确定应用程序仍然存活，以及在判断接收时间距离当前时间的间隔超过预设时长时，确定应用程序不再存活。

目标应用程序正常运行的情况下，会以较短的时间间隔(可以比预设时长短很多)发送心跳信息，因此记录的接收时间会很快更新，如果某个目标应用程序对应的接收时间长时间未更新(超过了预设时长)，表明该目标应用程序的运行已经出现异常，无法再按期发送心跳信息，从而可以确定其不再存活，进而采取告警、错误排查、重新启动应用程序等处理措施。

举例说明，目标应用程序每隔1秒发送一次心跳信息，电子设备每隔30秒扫描一次记录的所有目标应用程序的心跳信息的接收时间，预设时长为1分钟，若当前时间为22:38:25，某个目标应用程序被记录的接收时间为22:37:18，和当前时间相差1分零7秒，已经超过了1分钟，则表明该目标应用程序已经不再存活。

在上面的实现方式中采用心跳的方式进行保活，相较于一些采用检查目标应用程序的PID的方式，对于目标应用程序陷入循环或者成为僵尸进程的情况也能够及时发现，对于目标应用程序的监测更加精确。

综上所述，在本申请实施例提供的应用程序升级方法中，从服务器获取的升级包中除了包括升级文件外，还包括本次升级的规则文件，本次升级的规则文件中既包括升级文件的描述信息，又指定了本次升级后需要保活的目标应用程序，其中，升级文件的描述信息用于升级文件的安装，而目标应用程序则在升级包安装完成后被启动运行，并进行存活状态的监测。从而，一旦目标应用程序在运行过程中出现了导致其不再存活的异常状况，电子设备能够通过判断其存活状态及时发现这些异常状况，并可以采取相应的处理措施，避免出现设备瘫痪等严重问题，维持设备的稳定运行。

另一方面，上述方法在升级完成后可以立即根据本次升级的规则文件的内容对目标应用程序进行保活，没有其他中间环节，执行方式简单高效，还拓展了升级操作的功能。

此外，上述方法在升级时只依赖升级包中的规则文件，从而，只需要对规则文件进行适当地配置就可以轻松实现应用升级，其升级包制作、维护也非常简单，不像一些现有技术中的升级工具(例如，Linux下的apt-get、yum)，其升级过程需要单独建立脚本文件，升级包制作比较复杂。

进一步的，上面只提到了升级后对目标应用程序进行保活的情况。实践中，若电子设备在运行过程中进行了重新启动，启动后也需要对目标应用程序进行保活，确保目标应用程序在电子设备工作期间始终运行并处于受监测的状态。具体的做法是：在电子设备启动时，首先根据电子设备本地保存的最近一次升级的规则文件确定需要保活的目标应用程序，然后运行目标应用程序，并监测目标应用程序的存活状态。不难看出，在电子设备启动时进行保活，和在电子设备升级完成后进行保活是类似的，主要是步骤执行的时机不同，这里不再进详细阐述。

上面在介绍本申请实施例提供的应用程序升级方法时，步骤的执行主体都指明或者默认为电子设备，具体可以由电子设备上运行的一项或多项服务来执行。在一种实现方式中，这些步骤都由一项服务执行，不妨称之为升级保活服务，即升级保活服务执行可以执行以下的步骤(含以下步骤的各种实现方式)：从服务器获取升级包；根据本次升级的规则文件中关于升级文件的描述信息安装升级包中的升级文件；运行本次升级的规则文件中指定的目标应用程序，并监测这些目标应用程序的存活状态。

由于这些步骤之前已经介绍，升级保活服务并没有提供新的功能，这些步骤所产生的有益效果可以参考前文描述。需要指出的是，应用程序升级方法的步骤都由升级保活服务来执行时，即该服务既能够升级应用程序又能够对升级后的应用程序进行保活，从而拓展了传统升级程序的功能，并且也无需设置单独的程序来进行目标应用程序的保活，进而节省了从升级到保活的中间环节，提高了执行效率。

图5示出了本申请实施例提供的应用程序升级装置500的功能模块图，该装置配置于电子设备。参照图5，应用程序升级装置500包括：升级包获取模块510，用于从服务器获取升级包，所述升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括所述升级文件的描述信息以及本次升级完成后需要保活的目标应用程序；升级文件安装模块520，用于根据所述升级文件的描述信息安装所述升级文件；保活模块530，用于运行所述目标应用程序，并监测所述目标应用程序的存活状态。

在应用程序升级装置500的一些实现方式中，所述描述信息包括所述升级文件的版本信息以及安装目录信息，升级文件安装模块520根据所述升级文件的描述信息安装所述升级文件，包括：将本次升级的规则文件中的版本信息与所述电子设备本地保存的上次升级的规则文件中的版本信息进行比较；若两个版本信息不同，则将所述升级文件安装至本次升级的规则文件中的安装目录信息所指定的目录下。

在应用程序升级装置500的一些实现方式中，所述描述信息还包括在所述升级文件安装前要执行的操作信息和/或在所述升级文件安装后要执行的操作信息。

在应用程序升级装置500的一些实现方式中，所述装置还包括：目标应用程序确定模块，用于在所述电子设备启动时，根据所述电子设备本地保存的最近一次升级的规则文件确定需要保活的目标应用程序；保活模块530还用于运行所述目标应用程序，并监测所述目标应用程序的存活状态。

在应用程序升级装置500的一些实现方式中，所述升级文件包括：应用程序的程序文件和/或应用程序依赖的文件。

在应用程序升级装置500的一些实现方式中，所述目标应用程序的程序文件的描述信息和其他升级文件的描述信息分别设置在本次升级的规则文件中不同的段落。

在应用程序升级装置500的一些实现方式中，保活模块530监测所述目标应用程序的存活状态，包括：接收所述目标应用程序定期发送的心跳信息，并记录所述心跳信息的接收时间；定期扫描纪录的接收时间，并在判断所述接收时间距离当前时间的间隔未超过预设时长时，确定所述应用程序仍然存活，以及在判断所述接收时间距离当前时间的间隔超过预设时长时，确定所述应用程序不再存活。

在应用程序升级装置500的一些实现方式中，所述心跳信息通过UDP报文的方式发送。

在应用程序升级装置500的一些实现方式中，升级包获取模块510从服务器获取升级包，包括：接收所述服务器发送的升级指令，所述升级指令中携带有升级包的地址；根据所述地址从所述服务器上拉取所述升级包。

在应用程序升级装置500的一些实现方式中，所述升级指令中还携带有校验信息，所述装置还包括：校验模块，用于在升级包获取模块510从服务器获取升级包之后，以及在升级文件安装模块520根据所述升级文件的描述信息安装所述升级文件之前，利用所述校验信息校验所述升级包中的升级文件的完整性。

本申请实施例提供的应用程序升级装置500，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的应用程序升级方法的步骤。例如，计算机可读存储介质可以实现为图2中电子设备100中的存储器120。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种应用程序升级方法，其特征在于，应用于一电子设备，所述方法包括：

从服务器获取升级包，所述升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括所述升级文件的描述信息以及本次升级后需要保活的目标应用程序；

根据所述升级文件的描述信息安装所述升级文件；

运行所述目标应用程序，并监测所述目标应用程序的存活状态。

2.根据权利要求1所述的应用程序升级方法，其特征在于，所述描述信息包括所述升级文件的版本信息以及安装目录信息，所述根据所述升级文件的描述信息安装所述升级文件，包括：

将本次升级的规则文件中的版本信息与所述电子设备本地保存的上次升级的规则文件中的版本信息进行比较；

若两个版本信息不同，则将所述升级文件安装至本次升级的规则文件中的安装目录信息所指定的目录下。

3.根据权利要求2所述的应用程序升级方法，其特征在于，所述描述信息还包括在所述升级文件安装前要执行的操作信息和/或在所述升级文件安装后要执行的操作信息。

4.根据权利要求1所述的升级方法，其特征在于，所述方法还包括：

在所述电子设备启动时，根据所述电子设备本地保存的最近一次升级的规则文件确定需要保活的目标应用程序；

运行所述目标应用程序，并监测所述目标应用程序的存活状态。

5.根据权利要求1所述的应用程序升级方法，其特征在于，所述升级文件包括：应用程序的程序文件和/或应用程序依赖的文件。

6.根据权利要求5所述应用程序升级方法，其特征在于，所述目标应用程序的程序文件的描述信息和其他升级文件的描述信息分别设置在本次升级的规则文件中不同的段落。

7.根据权利要求1-6中任一项所述的应用程序升级方法，其特征在于，所述监测所述目标应用程序的存活状态，包括：

接收所述目标应用程序定期发送的心跳信息，并记录所述心跳信息的接收时间；

定期扫描纪录的接收时间，并在判断所述接收时间距离当前时间的间隔未超过预设时长时，确定所述应用程序仍然存活，以及在判断所述接收时间距离当前时间的间隔超过预设时长时，确定所述应用程序不再存活。

8.根据权利要求7所述的应用程序升级方法，其特征在于，所述心跳信息通过UDP报文的方式发送。

9.一种应用程序升级方法，其特征在于，应用于一电子设备，所述电子设备上运行有升级保活服务，所述方法包括：

所述升级保活服务从服务器获取升级包，所述升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括所述升级文件的描述信息以及本次升级后需要保活的目标应用程序；

所述升级保活服务根据所述升级文件的描述信息安装所述升级文件；

所述升级保活服务运行所述目标应用程序，并监测所述目标应用程序的存活状态。

10.一种应用程序升级装置，其特征在于，配置于一电子设备，所述装置包括：

升级包获取模块，用于从服务器获取升级包，所述升级包中包括升级文件以及本次升级的规则文件，其中，本次升级的规则文件中包括所述升级文件的描述信息以及本次升级完成后需要保活的目标应用程序；

升级文件安装模块，用于根据所述升级文件的描述信息安装所述升级文件；

保活模块，用于运行所述目标应用程序，并监测所述目标应用程序的存活状态。