应用更新方法和装置与流程

本发明涉及计算机应用技术领域，特别是涉及一种应用更新方法和装置。

背景技术：

为了使应用程序能够不断适应变化的市场，开发人员需要不断地进行应用程序的完善，即不断更新应用程序的版本。在应用交付频率越来越高的当下，新的应用版本研发出来后，工程人员经常需要花费巨大的成本和心血来完成频繁的应用更新的部署工作。

应用更新方式包括增量更新和全量更新两种方式。增量更新需要预先做增量部署，即部署提取的当前版本和即将部署版本之间的增量，更新时仅对增量部分进行更新。全量更新即做每个版本所包括的全部资源的部署，每个更新都是应用的重新安装和配置。对于增量部署而言，具有更新效率高的有点，但尤其是发布的版本数量较多时，需要部署增量包数量庞大，且由于增量包之间的强依存关系，后续的增量维护工作相当艰巨。对于全量部署而言，虽然资源维护成本低，由于单次下载和安装的数据量较大，更新效率低，内存占有量大。传统的应用更新方法不能兼顾资源维护成本和更新效率。

技术实现要素：

基于此，有必要针对上述的问题，提供一种资源维护成本低且资源更新效率更高的应用更新方法和装置。

一种应用更新方法，所述方法包括：

接收用户终端发送的应用版本更新请求，所述应用版本更新请求中携带用户版本标识；

若请求更新的应用对应的最新版本标识为增量版本标识，则查找所述用户版本标识与所述最新版本标识之间是否有历史全量版本标识，其中，所述历史全量版本标识为已部署全量资源包的应用版本标识；

若是，则获取所述历史全量版本标识对应的所述全量资源包，并获取预先部署的从所述历史全量版本标识到所述最新版本标识的增量资源包；

将获取的所述全量资源包和所述增量资源包发送至所述用户终端，以使所述终端经全量升级和增量升级将所述应用更新至最新版本。

在一个实施例中，所述方法还包括：

若所述用户版本标识与所述最新版本标识之间不包含有所述历史全量版本标识，则获取所述用户版本标识到最新应用版本标识之间的所述增量资源包；

将获取的所述增量资源包推送至所述终端，以使所述终端经增量升级将所述应用更新至最新版本。

在一个实施例中，在所述获取用户终端发送的应用版本更新请求，所述应用版本更新请求中携带用户版本标识的步骤之前，还包括：

获取待部署的应用版本的配置信息，若所述配置信息指示所述应用版本为全量版本，则部署所述应用版本对应的全量资源包；

若所述配置信息指示待部署所述应用版本为增量版本，则确定与待部署所述应用版本最接近的历史全量版本；

根据确定的所述历史全量版本部署所述应用版本对应的增量资源包，其中，所述增量资源包包括自所述历史全量版本到所述应用版本的增量资源包以及所述历史全量版本与所述应用版本之间的各中间应用版本到所述应用版本的增量资源包。

在一个实施例中，所述方法还包括：

将所述最新版本标识和所述最新版本标识对应的最接近的历史全量版本标识，以及所述最接近的历史全量版本标识到所述最新版本标识之间的应用版本标识推送至所述用户终端；

接收所述用户终端根据推送的版本标识选定的指定应用版本标识；

获取与所述指定应用版本标识对应的所述全量资源包和/或所述增量资源包，并将获取的所述全量资源包和/或所述增量资源包推送至所述终端。

在一个实施例中，所述将获取的所述全量资源包和所述增量资源包发送至所述用户终端，以使所述终端经全量升级和增量升级将所述应用更新至最新版本的步骤，包括：

使用预先约定的加密秘钥对获取的所述全量资源包和所述增量资源包进行加密处理；

将经加密处理的所述全量资源包和所述增量资源包推送至所述终端，以使所述终端经解密后进行应用版本的全量升级和增量升级。

一种应用更新装置，所述装置包括：

更新请求接收模块，用于接收用户终端发送的应用版本更新请求，所述应用版本更新请求中携带用户版本标识；

历史全量版本查找模块，用于若请求更新的应用对应的最新版本标识为增量版本标识，则查找所述用户版本标识与所述最新版本标识之间是否有历史全量版本标识，其中，所述历史全量版本标识为已部署全量资源包的应用版本标识；

资源包获取模块，用于若是，则获取所述历史全量版本标识对应的所述全量资源包，并获取预先部署的从所述历史全量版本标识到所述最新版本标识的增量资源包；

跨全量更新模块，用于将获取的所述全量资源包和所述增量资源包发送至所述用户终端，以使所述终端经全量升级和增量升级将所述应用更新至最新版本。

在一个实施例中，所述装置还包括：

增量更新模块，用于若所述用户版本标识与所述最新版本标识之间不包含有所述历史全量版本标识，则获取所述用户版本标识到最新应用版本标识之间的所述增量资源包；将获取的所述增量资源包推送至所述终端，以使所述终端经增量升级将所述应用更新至最新版本。

在一个实施例中，所述装置还包括：

全量资源包部署模块，用于获取待部署的应用版本的配置信息，若所述配置信息指示所述应用版本为全量版本，则部署所述应用版本对应的全量资源包；

增量资源包部署模块，用于若所述配置信息指示待部署所述应用版本为增量版本，则确定与待部署所述应用版本最接近的历史全量版本；根据确定的所述历史全量版本部署所述应用版本对应的增量资源包，其中，所述增量资源包包括自所述历史全量版本到所述应用版本的增量资源包以及所述历史全量版本与所述应用版本之间的各中间应用版本到所述应用版本的增量资源包。

在一个实施例中，所述装置还包括：

指定更新版本模块，用于将所述最新版本标识和所述最新版本标识对应的最接近的历史全量版本标识，以及所述最接近的历史全量版本标识到所述最新版本标识之间的所有应用版本标识推送至所述用户终端；接收所述用户终端根据推送的版本标识选定的指定应用版本标识；

指定更新版本更新模块，用于获取与所述指定应用版本标识对应的所述全量资源包和/或所述增量资源包，并将获取的所述全量资源包和/或所述增量资源包推送至所述终端。

在一个实施例中，所述跨全量更新模块，还用于使用预先约定的加密秘钥对获取的所述全量资源包和所述增量资源包进行加密处理；将经加密处理的所述全量资源包和所述增量资源包推送至所述终端，以使所述终端经解密后进行应用版本的全量升级和增量升级。

上述应用更新方法和装置，全量资源包穿插部署在增量资源包中，终端请求更新版本时，首先查找用户版本标识与最新版本标识中是否有历史全量版本标识；若有，则获取查找的历史全量版本标识对应的全量资源包，并获取历史全量版本到最新版本之间的资源包。将获取的全量资源包和增量资源包发送至用户终端，以使用户终端先全量更新至历史全量版本，然后再更新到最新版本，即“跨全量”更新。这种更新方式由于历史全量版本之前的版本的资源包均无需进行维护，相对比增量升级版本维护成本明显减少；相对比更新效率低的全量更新方式，“跨全量”更新方式将应用更新分割成两步更新，更新难度降低，更新效率更高。

附图说明

图1为一个实施例中应用更新方法的应用环境图；

图2为一个实施例中服务器的内部结构示意图；

图3为一个实施例中应用更新方法的流程图；

图4为增量更新和跨全量更新所对应的资源包部署原理图。

图5为一个实施例中资源包配置所涉及的流程图；

图6为一个实施例中设定版本跨度的“跨全量”资源包部署原理图；

图7为另一个实施例中应用更新方法的流程图；

图8为一个实施例中应用更新装置的结构框图；

图9为一个实施例中资源包部署所涉及的结构框图；

图10为另一个实施例中应用更新装置的结构框图；

图11为又一个实施例中应用更新装置的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，在一个实施例中，提供了一种应用更新方法的应用环境图，该应用环境图包括用户终端110和服务器120，用户终端110可通过网络与服务器120通信。用户终端可以是智能手机、平板电脑、笔记本电脑、台式计算机中的至少一种，但并不局限于此。服务器120用于存储全量资源包和增量资源包。服务器120在接收到用户终端发送的版本更新请求时，查找满足条件的资源包，并将查找到的资源包推送至用户终端，以使用户终端进行应用程序的更新。

如图2所示，在一个实施例中，提供了一种服务器120，该服务器120包括通过系统总线连接的处理器、存储介质、内存和网络接口。其中，该服务器120的存储介质存储有操作系统、数据库和一种应用更新装置，该装置用于实现一种应用更新方法。数据库用于存储数据。处理器用于提供计算和控制能力，支撑整个服务器120的运行。内存为存储介质中的应用更新装置的运行提供环境。网络接口用于与用户终端110建立网络连接。

如图3所示，在一个实施例中，提供了一种应用更新方法，该包括具体包括如下步骤：

步骤s202：获取用户终端发送的应用版本更新请求，其中，应用版本更新请求中携带用户版本标识。

应用页面上设置有版本更新按钮，通过触发版本更新按钮向服务器发送应用版本更新请求。这里的应用可以是独立的应用客户端，也可以是浏览器/服务器架构的web应用。

应用版本更新请求中携带的用户版本标识为用户终端当前安装应用的版本标识。例如，用户版本标识可以为v3.0。

步骤s204：若请求更新的应用对应的最新版本标识为增量版本标识，则查找所述用户版本标识与所述最新版本标识之间是否有历史全量版本标识，其中，所述历史全量版本标识为已部署全量资源包的应用版本标识。

具体的，服务器响应于用户终端的应用版本更新请求，查找请求版本更新的应用对应的最新版本标识，并判断最新版本标识是否为增量版本标识。具体的，服务器预先为交付的各应用版本配置相应的属性，包括增量属性和全量属性，其中，全量属性的版本标识穿插在增量属性的版本标识中。

举例来说，服务器对各版本做如下属性配置：v1.0为全量版本标识，v2.0-v5.0为增量版本标识，v6.0为增量版本标识，v7.0-v9.0为增量版本标识，v10.0为全量版本标识。也就是，全量版本标识穿插于增量版本标识中，可以是等跨度穿插，也可以是不规则跨度穿插，可根据实际情况做具体的配置。

若请求版本更新的应用对应的最新版本标识是增量版本标识，服务器查找在用户版本标识与最新版本标识之间的所有中间版本中是否有全量版本标识，这里的全量版本标识相对于最新版本标识而言为历史全量版本标识。若中间版本标识中有历史全量版本标识，则从存储数据库中获取该历史全量版本标识对应的全量资源包。这里的全量资源包指该全量版本标识对应的应用版本的完整的资源包，仅通过全量资源包即可安装全量版本标识对应的应用版本。

步骤s206：若在用户版本标识与最新版本标识之间查找到历史全量版本标识，则获取所述历史全量版本标识对应的所述全量资源包，并获取预先部署的从所述历史全量版本标识到所述最新版本标识的增量资源包。

服务器预先为全量版本标识部署全量资源包，为增量版本标识部署增量资源包，本实施例中，部署的增量资源包是以在先的全量资源包为基础的，即部署的是从在先的全量版本标识到增量版本标识之间的增量包。因此，为作为增量版本的最新版本部署的增量资源包为历史全量版本到最新版本之间的增量资源包。这里的增量数据包是从全量版本到最新版本增加的资源数据，可以是增加的代码，可执行文件等。

步骤s210：将获取的所述全量资源包和所述增量资源包发送至所述用户终端，以使所述终端经全量升级和增量升级将所述应用更新至最新版本。

服务器将获取的全量资源包和增量资源包推送至请求版本更新的用户终端。用户终端将全量资源包和增量资源包下载到本地，通过全量资源包将应用全量升级至对应的全量版本。然后，在全量版本的基础上，通过增量资源包将应用从全量版本增量升级到最新版本。

本实施例中，应用版本的更新为先将应用版本全量更新到中间的全量版本，在以全量版本为依托，增量更新到最新版本的“跨全量”应用版本更新。

相对比需要维护所有版本间的增量资源包的单纯的增量更新方式，本实施例中的“跨全量”更新方式，全量版本之前的版本的增量资源包均无需进行维护，极大的减轻的版本维护成本。相对比需要较大的流量消耗的全量更新方式，本实施例中的将应用更新有机分割成全量更新和增量更新两个步骤，下载和更新难度较少，更新效率低。

通过图4可以更加直观的看出：采用增量更新(a)，需要维护的增量包为11个。且传统的增量更新方式只适用于上下相邻两个版本之间的更新，如从v1.0到v2.0，从v2.0到v3.0…从v11.0到v12.0。

本实施例中的“跨全量”更新(b)，全量版本v7.0之前的版本请求更新，需要维护的资源包仅为两个，一个是v7.0全量包，一个是增量包1。对于全量版本到最新版本之间的中间版本(v8.0-11.0)版本之间的更新可采用(a)中的增量包更新，也可以采用如图(b)所示的跨版本的增量更新，这两种增量更新方式所产生的需要维护的增量包的数量是一样的。综上，“跨全量”更新需要维护的数据包为6个，与传统的增量更新有明显的减少。

另外，本实施例中的“跨全量”更新中带有全量更新，因此，具有全量更新的稳定性高，更新成功率高的优点；同时带有增量更新，因此，具有增量更新的更新效率高的优点。

在一个实施例中，如图5所示，在应用更新步骤(步骤s202-步骤s208)之前，还需要对更新所需要的更新资源进行相应部署。资源包的部署包括如下步骤：

步骤s302：获取待部署的应用版本的配置信息，若配置信息指示应用版本为全量版本，则部署应用版本对应的全量资源包。

在应用版本开发时，为每个开发的应用版本关联相应配置文件。配置文件中的配置信息指示该应用版本是全量版本还是增量版本。若待部署应用版本为全量版本，则部署该版本的全量资源包。若该全量版本为最新版本，则通过部署的该版本的全量资源包即可使应用版本全量更新到最新版本。

在一个实施例中，全量版本有规则的穿插在增量版本中。也就是，服务器预设版本跨度，处于版本跨度节点的应用版本配置为全量版本，处于跨度节点之间的版本配置为增量版本。举例来说，如图6所示，预设版本跨度为3，v1.0实质为全量版本，那么，v2.0、v3.0为增量版本，v4.0为全量版本，v5.0、v6.0为增量版本，v7.0为全量版本依次类推。

按照上述预设规律，无需为每个版本以配置文件的形式做具体的配置，只需获取版本标识，判断版本标识是否处于版本跨度节点即可判断待部署的应用版本是全量版本还是增量版本。

步骤s304：若配置信息指示待部署应用版本为增量版本，则确定与待部署应用版本最接近的历史全量版本。

具体的，若待部署应用版本的配置信息指示该应用版本为增量版本或者待部署应用版本标识未处于预设跨度节点，则需要为该应用版本部署增量资源包。

本实施例中，在进行增量资源包部署时，首先查找待部署的应用版本的历史应用版本中，与本次部署的应用版本最接近的历史全量版本。更具体为：获取本次部署的应用版本对应的所有历史版本的配置信息，根据历史版本的配置信息确定与本次部署的应用版本最接近且部署有全量资源包的历史全量版本。

举例来说，参考图6，v2.0、v3.0最接近的历史全量版本为v1.0；v5.0、v6.0最接近的历史全量版本为v4.0；v8.0、v9.0的历史全量版本为v7.0，依次类推。

步骤s306：根据确定的历史全量版本部署应用版本对应的增量资源包，其中，增量资源包包括自历史全量版本到应用版本的增量资源包以及历史全量版本和应用版本之间的各中间应用版本到应用版本的增量资源包。

部署的增量资源包包括从确定的历史全量版本到当前待部署应用版本之间所有历史版本(包括确定的历史全量版本)到当前待部署应用版本的增量资源包。继续参考图6，假设当前待部署的增量应用版本为v6.0，则v6.0对应的增量资源包包括v4.0-v6.0增量资源包和v5.0-v6.0的增量资源包。

进一步的，可将历史全量版本对应的全量资源包以及以该历史全量版本为基础的增量数据包作为一组资源包。例如，v4.0对应的全量数据包以及v4.0-v5.0、v4.0-v6.0和v5.0-v6.0对应的增量资源包为一组资源包。

随着新的应用版本的不断发布，当最新版本从一组资源包进入到下一组资源包时，可删除前一组资源包，或者停止对前一组资源包的维护。当最新版本从v6.0更新到v7.0时(即最新版本从组a进入到组b)，删除部署的组a对应的资源包。同样的，当最新版本从v10.0更新到v11.0时，删除组b对应的资源包。也就是，在同一时间仅维护一组资源包或者仅维护一组资源包中部分资源包。

本实施例中，通过对各应用版本的增量/全量属性的配置，为各应用版本配置增量资源包或者全量资源包，以使请求版本更新的用户终端可利用服务器部署的资源包将应用更新到最新版本。本实施例中同一时间需要维护的资源包最多仅为一组资源包，资源包维护成本低且可实现跨版本更新。

进一步的，将最新的资源包组标记为“激活”，将激活状态的资源包组之前的历史资源包组标记为“未激活”。进一步的，“0”表示“未激活”，“1”表示“激活”。同一时间标记为“1”的资源包组仅为一个。标记为“1”的资源包组中的资源包可以推送至用户终端，以使用户终端进行应用版本的更新。基于此，应用更新方法还可以采用如下步骤：

获取用户终端发送的应用版本更新请求，该应用版本更新请求中携带用户版本标识；查找最新版本标识所在的资源包组，获取查找的资源包组的全量资源包和相应的增量资源包；将获取的全量资源包和增量资源包发送至用户终端，以使终端通过全量升级和增量升级进行应用版本的更新。

参考图6，假设v9.0为最新版本，则最新版本所在资源包组为组b，组b中包括v7.0全量资源包，v7.0-v8.0、v7.0-v9.0、v8.0-v9.0的增量数据包。

若用户应用版本为v7.0之前的历史版本，则使用v7.0全量资源包和v7.0-v9.0增量数据包即可将应用版本更新到最新版本。

若用户应用版本为v7.0，则使用v7.0-v9.0增量数据包即可将应用版本更新到最新版本。

若用户应用版本为全量版本到最新版本之间的应用版本，如为v8.0，则使用v8.0-v9.0增量数据包即可将应用版本更新到最新版本。

也就是，若用户版本标识与最新版本标识之间不包含全量版本标识，则用户版本标识为最接近的历史全量版本与最新版本之间的中间应用版本标识，获取部署的中间应用版本标识对应的中间应用版本到最新应用版本之间的增量资源包；将获取的增量资源包推送至终端，以使终端进行应用版本的增量升级。

本实施例中，将用户应用版本划分为两个的阶段：激活资源包组前的历史应用版本、激活资源包组包含的中间应用版本(中间应用版本相对于最新版本而言，也是历史应用版本)。对于前一个阶段的应用版本采用“跨全量”更新的方式进行应用更新，对于后一阶段的应用版本则可直接根据部署的增量数据包，采用增量更新的方式进行应用更新。也就是，本实施例中，在保证较少的维护成本的基础上，对不同阶段的应用版本采用不同的更新方式，可使应用版本的更新更加简单合理。

在一个实施例中，如图7所示，提供了一种应用更新方法，具体包括如下步骤：

步骤s402：接收用户终端发送的应用版本更新请求，其中，应用版本更新请求中携带用户版本标识。

步骤s404：获取最新版本标识，查找最新版本标识对应的最接近的历史全量版本标识。

步骤s406：将最新版本标识和最接近的历史全量版本标识，以及最接近的历史全量版本标识到最新版本标识之间的应用版本标识推送至用户终端。

步骤s408：接收所述用户终端根据推送的版本标识选定的指定应用版本标识。

步骤s410：获取与指定应用版本标识对应的全量资源包和/或增量资源包，并将获取的全量资源包和/或增量资源包推送至终端。

具体的，若指定应用版本标识为最接近历史全量版本标识(图6中的v7.0)，则将最接近的历史全量版本对应的全量资源包推送至用户终端，用户终端通过该全量资源包全量更新至最接近的历史全量版本。

若指定应用版本为最新版本，且用户版本在历史全量版本之前，则按照步骤s204-s280进行“跨全量”更新。若指定应用版本为最新版本，且用户版本为历史全量版本和最新版本之间的中间版本，则获取用户版本与最新版本之间的增量资源包，进行增量更新。此处已有详细叙述，此处不再赘述。

若指定应用版本标识为历史全量版本和最新版本之间的中间版本，且用户版本为用户版本在历史全量版本之前，则获取历史全量版本对应的全量资源包和历史全量版本到指定应用版本之间的增量资源包，将获取的全量资源包和增量资源包发送至用户终端，以使终端通过全量升级和增量升级进行应用版本的更新。若指定应用版本标识为历史全量版本和最新版本之间的中间版本，且用户版本也为历史全量版本和最新版本之间的中间版本，则获取用户版本与指定更新版本之间的增量资源包，进行增量更新。

本实施例中，用户可指定想要更新到的应用版本，应用版本的更新更加灵活。由于本实施例中，最新版本所在资源包组为激活资源包组，因此，向用户终端推送的可供用户选择的应用版本标识为激活资源包组中的应用版本标识。

在另一个实施例中，也可以在同时时间内，将多个资源包组设置为激活资源包组，以使向用户终端推送的可供选择的应用版本标识的范围更广。

在一个实施例中，步骤s208：将获取的所述全量资源包和所述增量资源包发送至所述用户终端，以使所述终端经全量升级和增量升级将所述应用更新至最新版本，包括：

使用预先约定的加密秘钥对获取的全量资源包和增量资源包进行加密处理；将经加密处理的全量资源包和增量资源包推送至终端，以使终端经解密后进行应用版本的全量升级和增量升级。

在向终端推送全量资源包和增量资源包时，对推送的全量资源包和增量资源包进行加密处理。授权终端预先存储了解密密钥，可通过解密秘钥对资源包进行解密。加密处理避免了恶意修改，保证了数据的安全性和可靠性。

在一个实施例中，如图8所示，提供了一种应用更新装置，该装置包括：

更新请求接收模块502，用于接收用户终端发送的应用版本更新请求，所述应用版本更新请求中携带用户版本标识。

历史全量版本查找模块504，用于若请求更新的应用对应的最新版本标识为增量版本标识，则查找所述用户版本标识与所述最新版本标识之间是否有历史全量版本标识，其中，所述历史全量版本标识为已部署全量资源包的应用版本标识。

资源包获取模块506，用于若是，则获取所述历史全量版本标识对应的所述全量资源包，并获取预先部署的从所述历史全量版本标识到所述最新版本标识的增量资源包。

跨全量更新模块508，用于将获取的所述全量资源包和所述增量资源包发送至所述用户终端，以使所述终端经全量升级和增量升级将所述应用更新至最新版本。

在一个实施例中，如图9所示，应用更新装置还包括：

增量更新模块602，用于若所述用户版本标识与所述最新版本标识之间不包含有所述历史全量版本标识，则获取所述用户版本标识到最新应用版本标识之间的所述增量资源包；将获取的所述增量资源包推送至所述终端，以使所述终端经增量升级将所述应用更新至最新版本。

在一个实施例中，如图10所示，应用更新装置还包括：

全量资源包部署模块702，用于获取待部署的应用版本的配置信息，若配置信息指示应用版本为全量版本，则部署应用版本对应的全量资源包。

增量资源包部署模块704，用于若配置信息指示待部署应用版本为增量版本，则确定与待部署应用版本最接近的历史全量版本；根据确定的历史全量版本部署应用版本对应的增量资源包，其中，增量资源包包括自历史全量版本到应用版本的增量资源包以及历史全量版本与应用版本之间的各中间应用版本到应用版本的增量资源包。

在一个实施例中，如图11所示，应用更新装置还包括：

指定更新版本模块802，用于将最新版本标识和最新版本标识对应的最接近的历史全量版本标识，以及最接近的历史全量版本标识到最新版本标识之间的所有应用版本标识推送至用户终端；接收用户终端根据推送的应用版本标识选定的指定应用版本标识。

指定更新版本更新模块804，用于获取与指定应用版本标识对应的全量资源包和/或增量资源包，并将获取的全量资源包和/或增量资源包推送至终端。

在一个实施例中，跨全量更新模块508，还用于使用预先约定的加密秘钥对获取的全量资源包和增量资源包做加密处理；将经加密处理的全量资源包和增量资源包推送至终端，以使终端经解密后进行应用版本的全量升级和增量升级。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，程序可存储于一计算机可读取存储介质中，如本发明实施例中，该程序可存储于计算机系统的存储介质中，并被该计算机系统中的至少一个处理器执行，以实现包括如上述各方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(read-onlymemory，rom)或随机存储记忆体(randomaccessmemory，ram)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。