CN107450936A - 一种移动应用的中间件升级方法及装置 - Google Patents

Abstract

本申请公开了一种移动应用的中间件升级方法及装置。一种移动应用的中间件升级方法包括：内容加载模块检查网络侧是否存在当前已安装中间件的更新版本；如果网络侧存在当前已安装中间件的更新版本，则获取所述更新版本的安装包，并利用所获取的安装包对已安装的中间件进行升级。本申请所提供的技术方案，可以有效降低应用程序与中间件的耦合度，进而令中间件可以自主拥有升级的控制权，无需依赖应用即可独立完成自动升级。

Description

一种移动应用的中间件升级方法及装置

技术领域

本申请涉及用户设备技术领域，尤其涉及一种移动应用的中间件升级方法及装置。

背景技术

中间件(middleware)是一种独立的系统软件或服务程序，在系统架构上位于操作系统(OS)和普通应用(App)之间，作用是为处于上层的应用提供运行与开发的环境。中间件属于可复用软件的范畴，在应用的开发过程中，通过直接调用中间件已实现的功能，可以有效提升应用的开发效率。

如果在一个应用的开发过程中用到了某个中间件，那么为了保证该应用能够在用户设备上正常运行，需要在用户设备上也安装相应的中间件。针对该问题，目前一种常用的做法是将中间件与应用程序共同打包提供给用户，并且在用户安装应用时，自动完成对中间件的安装。这种方式无需用户再去单独下载安装中间件，可以有效简化用户的操作，并且降低对用户技能的要求。

上述方案，实际上是将两个相对独立的组件绑定在同一安装包内进行发布，然而在有些情况下，中间件可能会有版本升级，如果要实现用户侧对中间件的自动更新，只能通过发布新版本安装包的形式向用户提供新版本的中间件。而如果应用程序部分并没有实际内容更新，这种更新方式实际会造成各类资源的浪费，例如开发方的打包、发布开销，用户下载的时间、流量开销等等。

发明内容

针对上述技术问题，本申请提供一种移动应用的中间件升级方法及装置，技术方案如下：

一种移动应用的中间件升级方法，安装于用户设备的中间件包括：基本功能内容及内容加载模块，所述方法包括：

内容加载模块检查网络侧是否存在当前已安装中间件的更新版本；

如果网络侧存在当前已安装中间件的更新版本，则获取所述更新版本的安装包，并利用所获取的安装包对已安装的中间件进行升级。

一种移动应用的中间件升级装置，该装置包括：存储模块及内容加载模块，

所述存储模块用于存储中间件基本内容；

所述内容加载模块用于检查网络侧是否存在当前已安装中间件的更新版本；如果网络侧存在当前已安装中间件的更新版本，则获取所述更新版本的安装包，并利用所获取的安装包对已安装的中间件进行升级。

本申请所提供的技术方案，提供了一种新的中间件架构：在原有基本功能内容的基础上，进一步增加了内容加载模块，使得传统的只能被应用程序所加载的中间件，变为具有独立行为能力的主体。通过这种方式，可以有效降低应用程序与中间件的耦合度，进而令中间件可以自主拥有升级的控制权，无需依赖应用即可独立完成自动升级。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是现有技术的应用安装包构成示意图；

图2是本申请的中间件架构示意图；

图3是本申请的移动应用的中间件升级方法的流程示意图；

图4是本申请的SDK架构示意图；

图5是本申请的Android应用SDK升级方法的流程示意图；

图6是本申请的移动应用的中间件升级装置的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

图1所示，为现有技术的应用安装包构成示意图，其中“应用本体内容”是由应用开发方进行开发的，而“中间件内容”则是由第三方提供。为了方便用户安装使用，开发方将“应用本体内容”及“中间件内容”两部分绑定在一起，共同打包在应用的安装包内提供给用户，用户使用该安装包进行安装的过程，实际包含了对“应用本体内容”和“中间件内容”两部分的安装。从这个角度将，也可以将“中间件”视为完整应用的一个组成部分。

在用户使用应用的过程中，如果需要调用中间件的功能，则由应用本体主动对中间件进行加载，在该过程中，中间件仅以加载对象的形式存在，本身并不具有独立自主的行为能力，因此版本升级也只能由应用本体来进行控制。

针对现有技术方案所存在的问题，本申请提供一种新的中间件架构，参见图2所示，安装于用户设备的中间件包括两部分：“基本功能内容”及“内容加载模块”，以下分别对两部分进行说明：

“基本功能内容”相当于现有的完整“中间件内容”，用于实现中间件的基本功能，并且同样是以加载对象的形式存在，本身并不具有独立自主的行为能力。

“内容加载模块”是本申请方案新增的部分，其作用是对“基本功能内容”进行加载。可以看出，在现有技术方案中，该功能是由应用本体侧实现的，本申请则将该功能从应用中剥离出来，封装在中间件内。相应地，在用户使用应用的过程中，如果需要调用中间件的功能，并不是由应用本体主动对中间件进行直接加载，而是由应用本体向中间件的内容加载模块发送加载请求，然后由内容加载模块自主对基本功能内容进行加载，并告知应用本地加载结果。可见，这种设计方式使得中间件变为具有独立行为能力的主体，进而也为中间件的自主升级提供了可行性。

基于上述中间件架构，本申请提供一种移动应用的中间件升级方法，参见图3所示，该方法可以包括以下步骤：

S101，内容加载模块检查网络侧是否存在当前已安装中间件的更新版本。

该步骤用于判断已安装的中间件是否存在更新版本，这里所说的更新版本可以是指广义上的完整中间件，即包括“基本功能内容”和/或“内容加载模块”在内的更新版本，也可以是特指“基本功能内容”部分的更新版本。具体的更新版本检查方法可以利用现有技术实现，本申请并不需要进行限定。

本步骤可以根据应用本体侧的某些行为触发执行，例如：在应用本体需要调用中间件功能时，向内容加载模块发送初始化加载请求，内容加载模块接收到移动应用侧发送的初始化加载请求后，开始执行版本检查操作。

当然，本步骤也可以采用多种其他方式触发执行，例如：由网络侧主动推送的更新消息触发执行(相当于可以直接确定存在更新版本)、由用户手动触发执行、或者由内容加载模块周期性执行，等等。

另外，根据实际的应用需求，“网络侧”具体可以是应用开发方的服务器、中间件提供方的服务器、或者各类应用市场的服务器等等，也可以是上述多种情况的结合，本申请对此也并不需要进行限定。

S102，如果网络侧存在当前已安装中间件的更新版本，则获取更新版本的安装包，并利用所获取的安装包对已安装的基本功能内容进行升级。

本步骤仍然由内容加载模块执行，如果通过检查发现在网络侧存在中间件的更新版本，则可以进一步触发下载、升级安装等后续操作，具体方式可以是全自动静默下载、提示用户手动确认是否下载升级等等。

如果在S101中，检查版本更新的操作是根据应用本体侧的初始化加载请求触发执行，则内容加载模块可以在对基本功能内容进行加载之前，先对中间件的版本进行检查，在中间件升级完成之后、或中间件升级失败之后、或确定不存在更新版本之后，再对基本功能内容进行加载。

为了进一步提升安全性，避免下载到存在问题(例如伪造、重新打包等)的中间件升级包，可以进一步为中间件添加验证信息，以验证中间件的有效性。例如，可以针对“基本功能内容”部分生成数字签名，内容加载模块在下载到更新版本的基本功能内容安装包后，利用该数字签名验证所下载安装包的有效性，如果验证通过，再进一步利用该安装包进行升级，如果验证不通过，则该安装包可能存在问题，可以忽略本次下载，继续加载设备中原有的基本功能内容。

可以理解的是，上述“验证信息”，也可以是针对整体中间件(包括“基本功能内容”与“内容加载模块”)的验证信息，对于整体中间件的验证可以由APP本体侧来实现。并且验证的方式也不仅限于数字签名，本领域技术人员可以根据实际需求灵活选择。

下面结合一个具体的实例，对本申请的技术方案进行说明：

在Android系统中，APP所使用的中间件一般指各类SDK(Software DevelopmentKit，软件开发工具包)，为了方便使用，一般都会在APK(Android Package，Android安装包)中集成SDK。根据现有技术的方案，对于一般用户来说，只能通过APP的整体更新来实现SDK的更新。一般而言，相对于整个APK而言，SDK只占其中很小一部分，如果仅为了更新SDK而发布新的APK版本，会造成很大浪费，而且Android系统本身也并不方便一般用户手动对SDK进行更新，而应用本申请方案，则可以有效解决上述问题。

首先，重新设计的SDK架构如图4所示：

安装在用户设备的上的中间件SDK由Content(基本功能内容)和SDK Launcher(内容加载模块)组成。

SDK Launcher负责加载Content实体，加载通过动态创建DexElement，插入到APP的DexClassloader中。

Content由jar包和jar包对应的数字签名文件sign组成，签名可以采用RSA方式，在客户端存储公钥以进行验签。

SDK的自动更新流程图如图5所示：

S201，APP本体向SDK发送初始化加载请求；

S202，SDK检查服务端是否存在新版本的jar包；

S203，如果服务端存在新版本jar包，则下载到本地；

S204，对所下载的jar包进行签名检查，如果签名符合，则利用所下载的jar包替换原有版本的jar包，否则丢弃所下载的jar包；

S205，对替换后的jar包进行加载，如果签名检查未通过，则仍然加载原有版本的jar包。

可见，应用本申请方案，降低了Android APP本体与SDK的耦合度，进而可以实现在Android系统SDK的独立且自动更新，在不需要发布APP新版本的情况下，也能够保证用户设备使用到最新版本的SDK。

可以理解的是，上述实施例仅用于示意性说明，不应理解为对本申请应用场景的限定。

相应于上述方法实施例，本申请还提供一种移动应用的中间件升级装置，参见图6所示，该装置可以包括：存储模块110及内容加载模块120，

存储模块110用于存储中间件基本内容；

内容加载模块120用于检查网络侧是否存在当前已安装中间件的更新版本；如果网络侧存在当前已安装中间件的更新版本，则获取更新版本的安装包，并利用所获取的安装包对已安装的中间件进行升级。

在本申请的一种具体实施方式中，内容加载模块120可以具体用于：接收到移动应用侧发送的初始化加载请求后，检查网络侧是否存在当前已安装中间件的更新版本。

在本申请的一种具体实施方式中，内容加载模块120还可以用于：内容加载模块在中间件升级完成之后、或中间件升级失败之后、或确定不存在更新版本之后，对基本功能内容进行加载。

在本申请的一种具体实施方式中，内容加载模块120可以具体用于：检查网络侧是否存在当前已安装基本功能内容的更新版本。

在本申请的一种具体实施方式中，安装于用户设备的中间件还可以包括：用于验证基本功能内容有效性的验证信息；相应地，内容加载模块120可以具体用于：获取更新版本的安装包后，利用验证信息验证所获取安装包的有效性，在验证通过的情况下，进一步利用所获取的安装包对已安装的基本功能内容进行升级。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种移动应用的中间件升级方法，其特征在于，安装于用户设备的中间件包括：基本功能内容及内容加载模块，所述方法包括：

内容加载模块检查网络侧是否存在当前已安装中间件的更新版本；

如果网络侧存在当前已安装中间件的更新版本，则获取所述更新版本的安装包，并利用所获取的安装包对已安装的中间件进行升级。

2.根据权利要求1所述的方法，其特征在于，所述内容加载模块检查网络侧是否存在当前已安装中间件的更新版本，包括：

内容加载模块接收到移动应用侧发送的初始化加载请求后，检查网络侧是否存在当前已安装中间件的更新版本。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

所述内容加载模块在中间件升级完成之后、或中间件升级失败之后、或确定不存在更新版本之后，对所述基本功能内容进行加载。

4.根据权利要求1所述的方法，其特征在于，所述检查网络侧是否存在当前已安装中间件的更新版本，包括：检查网络侧是否存在当前已安装基本功能内容的更新版本。

5.根据权利要求4所述的方法，其特征在于，所述安装于用户设备的中间件还包括：用于验证所述基本功能内容有效性的验证信息；

所述获取所述更新版本的安装包，并利用所获取的安装包对已安装的基本功能内容进行升级，包括：获取所述更新版本的安装包后，利用所述验证信息验证所获取安装包的有效性，在验证通过的情况下，进一步利用所获取的安装包对已安装的基本功能内容进行升级。

6.一种移动应用的中间件升级装置，其特征在于，该装置包括：存储模块及内容加载模块，

所述存储模块用于存储中间件基本内容；

所述内容加载模块用于检查网络侧是否存在当前已安装中间件的更新版本；如果网络侧存在当前已安装中间件的更新版本，则获取所述更新版本的安装包，并利用所获取的安装包对已安装的中间件进行升级。

7.根据权利要求6所述的装置，其特征在于，所述内容加载模块具体用于：

接收到移动应用侧发送的初始化加载请求后，检查网络侧是否存在当前已安装中间件的更新版本。

8.根据权利要求7所述的装置，其特征在于，所述内容加载模块还用于：

所述内容加载模块在中间件升级完成之后、或中间件升级失败之后、或确定不存在更新版本之后，对所述基本功能内容进行加载。

9.根据权利要求6所述的装置，其特征在于，所述内容加载模块具体用于：

检查网络侧是否存在当前已安装基本功能内容的更新版本。

10.根据权利要求9所述的装置，其特征在于，所述安装于用户设备的中间件还包括：用于验证所述基本功能内容有效性的验证信息；

所述内容加载模块具体用于：获取所述更新版本的安装包后，利用所述验证信息验证所获取安装包的有效性，在验证通过的情况下，进一步利用所获取的安装包对已安装的基本功能内容进行升级。