基于增量的应用更新和测试方法及系统、服务器及客户端与流程

本发明属于通信领域，尤其涉及一种基于增量的应用更新和测试方法、装置及系统、服务器及客户端。

背景技术：

目前，每次对发布的应用进行更新时，开发者都需要向应用市场提交一份该应用完整的安装包。对于用户来说，当用户需要对应用进行更新时，需要重新从应用市场上下载该安装包，然后对应用进行更新。实际上应用每次更新变更的往往只是部分内容，相对未发生变更的部分，用户每次下载安装包就会存在重新下载的问题。

现有的增量升级中，会将新版本应用的代码与旧版本应用的代码进行整体比较，通过整体比较后获取增量进行下发，而实际中应用运行时所需框架部分的代码在更新时一般不会发生变化，因此通过整体代码比较获取增量的方法，存在应用的更新效率较低。

技术实现要素：

本发明提供一种基于增量的应用更新和测试方法、装置及系统、服务器及客户端，用于现有通过整体代码比较获取增量的方法，存在应用的更新效率较低的问题。

为了实现上述目的，本发明提供了一种基于增量的应用更新方法，包括：

服务器将新版应用拆分成用于表示所述新版应用业务逻辑的第一业务部分和用于表示所述新版应用运行时所需框架的第一框架部分；

所述服务器获取客户端当前待更新的旧版应用的第二业务部分；

所述服务器获取所述第一业务部分与所述第二业务部分之间的第一增量；

所述服务器将所述第一增量发送给所述客户端；

所述客户端利用所述第一增量将所述旧版应用更新到所述新版应用。

为了实现上述目的，本发明提供了另一种基于增量的应用更新方法，包括：

将新版应用拆分成用于表示所述新版应用业务逻辑的第一业务部分和用于表示所述新版应用运行时所需框架的第一框架部分；

获取客户端当前待更新的旧版应用的第二业务部分；

获取所述第一业务部分与所述第二业务部分之间的第一增量；

将所述第一增量发送给所述客户端，以使所述客户端利用所述第一增量将所述旧版应用更新为所述新版应用。

为了实现上述目的，本发明提供了另一种基于增量的应用更新方法，包括：

接收服务器发送的第一增量，其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；所述第一业务部分用于表示所述新版应用业务逻辑的部分，所述第二业务部分用于表示所述旧版应用业务逻辑的部分；所述旧版应用为客户端当前待更新的应用；所述新版应用为所述客户端对旧版应用进行更新后对应的应用；

利用所述第一增量将所述旧版应用更新到所述新版应用。

为了实现上述目的，本发明提供了一种基于增量的应用测试方法，包括：

服务器按照预先配置的测试策略获取待测试的客户端；

所述服务器向所述客户端发送第一增量；

所述客户端利用所述第一增量将所述旧版应用更新到所述新版应用；

所述客户端对所述新版应用的使用数据进行采集，将采集到的所述使用数据发送给所述服务器；

所述服务器对所述使用数据进行分析，得到所述新版应用的测试结果；

其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；所述第一业务部分用于表示所述新版应用业务逻辑的部分，所述第二业务部分用于表示所述旧版应用业务逻辑的部分；所述旧版应用为客户端当前待更新的应用；所述新版应用为所述客户端对旧版应用进行更新后对应的应用。

为了实现上述目的，本发明提供了一种基于增量的应用测试方法，包括：

按照预先配置的测试策略获取待测试的客户端；

向所述客户端发送第一增量，以使所述客户端利用所述第一增量将所述旧版应用更新到所述新版应用；

接收所述客户端发送的使用数据，其中，所述使用数据是由所述客户端对所述新版应用的使用情况进行采集得到的；

对使用所述数据进行分析以得到所述新版应用的测试结果；

其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；所述第一业务部分用于表示所述新版应用业务逻辑的部分，所述第二业务部分用于表示所述旧版应用业务逻辑的部分；所述旧版应用为客户端当前待更新的应用；所述新版应用为所述客户端对旧版应用进行更新后对应的应用。

为了实现上述目的，本发明提供了一种基于增量的应用测试方法，包括：

接收服务器发送的第一增量；

利用所述第一增量将所述旧版应用更新到所述新版应用；

采集所述新版应用的使用数据发送给所述服务器，以使所述服务器对所述使用数据进行分析，得到所述新版应用的测试结果；

其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；所述第一业务部分用于表示所述新版应用业务逻辑的部分，所述第二业务部分用于表示所述旧版应用业务逻辑的部分；所述旧版应用为客户端当前待更新的应用；所述新版应用为所述客户端对旧版应用进行更新后对应的应用。

为了实现上述目的，本发明提供了一种服务器，包括：

拆分模块，用于将新版应用拆分成用于表示所述新版应用业务逻辑的第一业务部分和用于表示所述新版应用运行时所需框架的第一框架部分；

获取模块，用于获取客户端当前待更新的旧版应用的第二业务部分，以及获取所述第一业务部分与所述第二业务部分之间的第一增量；

发送模块，用于将所述第一增量发送给所述客户端，以使所述客户端利用所述第一增量将所述旧版应用更新为所述新版应用。

为了实现上述目的，本发明提供了一种客户端，包括：

接收模块，用于接收服务器发送的第一增量，其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；

更新模块，用于利用所述第一增量将所述旧版应用更新到所述新版应用；

所述第一业务部分用于表示所述新版应用业务逻辑的部分，所述第二业务部分用于表示所述旧版应用业务逻辑的部分；所述旧版应用为客户端当前待更新的应用；所述新版应用为所述客户端对旧版应用进行更新后对应的应用。

为了实现上述目的，本发明提供了一种基于增量的应用更新系统，包括：如上所述的服务器和如上所述的客户端。

为了实现上述目的，本发明提供了一种服务器，包括：

获取模块，用于按照预先配置的测试策略获取待测试的客户端；

发送模块，用于向所述客户端发送第一增量，以使所述客户端利用所述第一增量将所述旧版应用更新到所述新版应用；

接收模块，用于接收所述客户端发送的使用数据，其中，所述使用数据是由所述客户端对所述新版应用的使用情况进行采集得到的；

分析模块，用于对使用所述数据进行分析以得到所述新版应用的测试结果；

其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；所述第一业务部分用于表示所述新版应用业务逻辑的部分，所述第二业务部分用于表示所述旧版应用业务逻辑的部分；所述旧版应用为客户端当前待更新的应用；所述新版应用为所述客户端对旧版应用进行更新后对应的应用。

为了实现上述目的，本发明提供了一种客户端，包括：

接收模块，用于接收服务器发送的第一增量；

更新模块，用于利用所述第一增量将所述旧版应用更新到所述新版应用；

采集发送模块，用于采集所述新版应用的使用数据发送给所述服务器，以使所述服务器对所述使用数据进行分析，得到所述新版应用的测试结果；

其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；所述第一业务部分用于表示所述新版应用业务逻辑的部分，所述第二业务部分用于表示所述旧版应用业务逻辑的部分；所述旧版应用为客户端当前待更新的应用；所述新版应用为所述客户端对旧版应用进行更新后对应的应用。

为了实现上述目的，本发明提供了一种基于增量的应用测试系统，其特征在于，包括：如上所述的服务器和如上所述的客户端。

本发明提供的基于增量的应用更新和测试方法、装置及系统、服务器及客户端，通过服务器将新版应用拆分成用于表示新版应用业务逻辑的第一业务部分和用于表示新版应用运行时所需框架的第一框架部分，服务器获取客户端当前待更新的旧版应用的第二业务部分，服务器获取第一业务部分与第二业务部分之间的第一增量，服务器将第一增量发送给客户端，客户端利用第一增量将旧版应用更新到新版应用。本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

附图说明

图1为本发明实施例一提供的基于增量的应用更新方法的流程示意图；

图2为本发明实施例二提供的基于增量的应用更新方法的流程示意图；

图3为本发明实施例三提供的基于增量的应用更新方法的流程示意图；

图4为本发明实施例四提供的基于增量的应用更新方法的流程示意图；

图5为本发明实施例五提供的基于增量的应用更新方法的流程示意图；

图6为本发明实施例六提供的基于增量的应用测试方法的流程示意图；

图7为本发明实施例七提供的基于增量的应用测试方法的流程示意图；

图8为本发明实施例八提供的基于增量的应用测试方法的流程示意图；

图9为本发明实施例九提供的基于增量的应用更新/测试系统的结构示意图；

图10为本发明实施例十提供的基于增量的应用更新系统的结构示意图；

图11为本发明实施例十一提供的基于增量的应用测试系统的结构示意图；

图12为本发明实施例十二提供的基于增量的应用更新及测试系统的结构示意图；

图13为本发明实施例十三提供的服务器的结构示意图；

图14为本发明实施例十四提供的客户端的结构示意图；

图15为本发明实施例十五提供的服务器的结构示意图；

图16为本发明实施例十四提供的客户端的结构示意图。

具体实施方式

下面结合附图对本发明实施例提供的基于增量的应用更新和测试方法、装置及系统、服务器及客户端进行详细描述。

实施例一

如图1所示，其为本发明实施例一提供的基于增量的应用更新方法的流程示意图。该基于增量的应用更新方法包括以下步骤：

s101、服务器将新版应用拆分成用于表示业务逻辑对应的第一业务部分和新版应用运行时所需框架对应的第一框架部分。

目前，用户可以在客户端上按照自己的需求安装一些应用，按照的应用在实际应用中往往更新换代较快，需要用户不断地对安装的应用进行更新。或者当开发者对应用进行了更新之后，就会试图提交到应用市场，应用市场对应的服务器就可以主动提醒用户对应用进行更新。

一个应用一般包括应用的业务逻辑的部分和应用运行时所需框架的部分。本实施例中，将用于表示应用的业务逻辑的部分称为第一业务部分，用于表示应用运行时所需框架的部分称为第二框架部分。本实施例中，服务器首先需要将新版应用拆分成第一业务部分和第一框架部分。优选地，服务器可以根据新版应用中的用于区别第一框架部分的标识符，将新版应用拆分成第一业务部分和第一框架部分。

一般情况下，应用的真实的视觉界面以及应用的业务逻辑的代码都属于应用的业务部分。应用的基础代码以及运行所需的框架层代码都属于应用的框架部分。

s102、服务器获取客户端当前待更新的旧版应用的第二业务部分。

本实施例中，预先设置有一个版本数据库，在该版本数据库中可以存储应用各个版本拆分后的业务部分和框架部分。

具体地，按照版本信息如版本号与业务部分和框架部分以及存储位置建立映射关系，根据该映射关系将各个版本的业务部分和框架部分存储在版本数据库中相应位置上。

实际应用中，一个应用在更新换代的过程中，往往调整该应用的业务逻辑，而该应用运行时所需框架部分往往不会变化。在对某一个客户端上的应用进行更新时，服务器需要获取到客户端当前待更新的旧版应用的第二业务部分。具体地，服务器按照旧版应用的版本信息，可以在版本数据库中查询获取到该旧版应用的第二业务部分。

进一步地，当服务器将新版应用拆分成第一业务部分和第一框架部分后，可以按照该新版应用对应的版本信息，将第一业务部分和第一框架部分存储在版本数据库中。

本实施例中，服务器在获取客户端当前待更新的旧版应用的第二业务部分之前，服务器还需要获取到客户端上旧版应用的版本信息。优选地，客户端可以在向服务器发送用于对旧版应用进行更新的更新请求，在该更新请求中携带该客户端上旧版应用的版本信息。

可选地，预设设置有一个信息数据库中，在该信息数据库中存储有客户端的一些相关信息，而服务器可以定期对信息数据库中存储的客户端的相关信息进行更新。其中，相关信息可以包括客户端的设备信息、用户信息、版本信息、位置信息以及ip信息等。当服务器主动向客户端下发更新提醒时，可以根据选取的客户端的设备信息如设备标识，查询到该客户端上旧版应用的版本信息。

s103、服务器获取第一业务部分与第二业务部分之间的第一增量。

具体地，服务器基于计算机文件系统文件级别的二级制差量算法，对第一业务部分和第二业务部分进行文件差量分解得到第一增量。本实施例中，通过二级制差量算法计算得到的第一增量，将是一个不可执行或者不可被直接识别的二进制数据。

s104、服务器将第一增量发送给客户端。

在获取到第一增量后，服务器可以将第一增量发送给客户端，以便于客户端可以利用该第一增量对旧版更新进行更新。

s105、客户端利用第一增量将旧版应用更新到新版应用。

客户端接收服务器发送的第一增量，然后利用该第一增量将旧版应用更新到新版应用。具体地，客户端基于计算机文件系统文件级别的二级制差量算法，对第一增量和第二业务部分进行文件差量合并，以得到新版应用。由于一般情况下，应用运行时所需的框架部分往往不会发生变化，客户端将第一增量与旧版应用的第二业务部分进行文件差量合并后，就可以得到新版应用。

本实施例提供的基于增量的应用更新方法，通过服务器将新版应用拆分成用于表示新版应用业务逻辑的第一业务部分和用于表示新版应用运行时所需框架的第一框架部分，服务器获取客户端当前待更新的旧版应用的第二业务部分，服务器获取第一业务部分与第二业务部分之间的第一增量，服务器将第一增量发送给客户端，客户端利用第一增量将旧版应用更新到新版应用。本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

进一步地，在新版应用的第一框架部分与旧版应用的第二框架部分存在差异时，基于增量的应用更新方法还包括：

服务器可以根据客户端旧版应用的版本信息，获取该旧版应用的第二框架部分，然后服务器基于计算机文件系统文件级别的二级制差量算法，对第一框架部分和第二框架部分进行文件差量分解得到第二增量，在获取到第二增量后，将第二增量发送给客户端。客户端将第二增量与第二框架部分进行合并，以得到新版应用。本实施例中，当应用的业务逻辑以及运行时所框架均发生变化时，需要将第一增量与第二业务部分进行合并，以及将第二增量与第二框架部分进行合并，当合并完成后就可以从旧版应用更新到新版应用。

实施例二

如图2所示，其为本发明实施例二提供的基于增量的应用更新方法的流程示意图。本实施例中，该基于增量的应用更新方法由基于增量的应用更新系统执行，该基于增量的应用更新系统包括：管理中心(admin)、服务器和客户端。其中，管理中心和服务器属于相对于客户端来说的服务器端，客户端包括：操作系统和容器层。本实施例中，服务器可以为节点(node)服务器。

其中，操作系统为客户端上安装的操作系统，用于管理和控制客户端上的硬件与软件资源的计算机程序，是直接运行在“裸机”上的最基本的系统软件，任何其他软件都必须在操作系统的支持下才能运行。例如，客户端为手机或者ipad等移动终端时，操作系统可以为android或者ios等。容器层该容器层嫁接在客户端的操作系统如android或者ios等操作系统上，需要依赖于操作系统本身提供的网络通信能力与节点服务器进行通信，该容器层可以为跨平台开发平台(reactnative)框架提供一个运行时所需的执行环境。

该基于增量的应用更新方法包括以下步骤：

s200、客户端中预先配置应用的框架部分。

本实施例中，为了提高初次下载应用的速度，可以在客户端出厂时打包该应用的框架部分，从而使得用户在客户端上下载该应用时，只需要下载应用的业务部分，减少了初次下载应用的所需占用的流量。

s201、管理中心定时更新客户端的相关信息。

本实施例中，管理中心可以实时地对客户端的相关信息进行更新，将客户端的相关信息存储在信息数据库中。其中，相关信息可以包括客户端的设备信息、用户信息、版本信息、位置信息以及ip信息等。设备信息可以为设备标识，设备标识可以为国际移动用户识别码(internationalmobilesubscriberidentificationnumber，简称imsi)、国际移动设备标识(internationalmobileequipmentidentity，简称imei)以及自定义的设备标识等。

s202、节点服务器对新版应用进行编译转换成能够被客户端识别的结果文件。

实际应用中，研发人员在对新版应用进行研发时，采用了不同的语音编写该新版应用，在研发完成后，研发人员需要将该新版应用的源文件提交给应用市场对应的服务器端。本实施例中，为了保证该新版应用的源文件能够被客户端识别或者执行，需要节点服务器对研发人员所提交的新版应用进行编译转换成可以被客户端识别的结果文件。

s203、管理员配置管理中心的下发策略。

本实施例中，管理员可以配置管理中心的下发策略，其中下发策略可以根据不同的维度设置。其中不同的维度可以包括：设备维度、地理位置维度、时间维度、人群维度、曝光率维度、交易转换率维度以及版本维度等。例如，管理员可以根据人群维度为管理中心配置一个下发策略，如下发策略可以为：选择人群中年龄在25～35之间的女性用户作为下发新版应用的对象。

s204、管理中心根据下发策略获取客户端的设备标识列表下发给节点服务器。

具体地，管理中心可以根据配置好的下发策略，从所有客户端中选择出符合下发策略的客户端作为下发新版应用的对象。当选择出客户端后，管理中心可以将客户端的设备标识以一个列表的形式发送给节点服务器。

s205、节点服务器对结果文件进行拆分，得到新版应用的第一业务部分和第一框架部分。

本实施例中，结果文件中携带有特殊的标识符，该标识符可以用于区别新版应用的第一框架部分。节点服务器对结果文件进行搜索，以查找到用于区别第一框架部分的标识符，根据该标识符将新版应用拆分成第一业务部分和第一框架部分。具体地，节点服务器根据该标识符将第一框架部分抽离出来，剩余的部分就是新版应用的第一业务部分。

进一步地，节点服务器还可以新版应用拆分后得到的第一业务部分和第一框架部分，按照新版应用对应的版本信息如版本号，存储到版本数据库中。

s206、节点服务器计算新版应用与旧版应用之间的增量。

节点服务器可以根据管理中心发送的设备标识列表，从信息数据库获取到每个客户端上安装的旧版应用的版本信息。版本信息可以为应用的版本号。为了实现对客户端上旧版应用的更新，针对每个客户端，节点服务器需要从版本数据库中获取与版本号对应的第二业务部分和第二框架部分。

实际应用中，应用在更新时往往只更新业务逻辑的业务部分，应用运行时所需的框架部分并不会经常发生变化。因此，本实施例中，节点服务器计算新版应用的第一业务部分与旧版应用的第二业务部分之间的第一增量。而在第一框架部分和第二框架部分存在差异时，节点服务器还可以计算新版应用的第一框架部分与旧版应用的第二框架部分之间的第二增量。

以javascript编写的应用为例进行说明，新版应用的源文件是由研发人员基于facebook的前端框架(react)编写出来的脚本语言(javascript)代码文件。节点服务器为了使客户端的容器层中的reactnative框架能够识别出该源文件，需要对该新版应用的源文件进行编译转换成符合标准ecmascript6语法的javascript代码的结果文件。

节点服务器根据标识符将新版应用对应的javascript结果文件拆分成业务逻辑(business)javascript代码和运行时所需框架对应的基础(base)javascript代码，其中，business的javascript代码简称为businessjs代码，base)javascript代码简称为basejs。businessjs代码对应第一业务部分，basejs对应第一框架部分。

节点服务器可以将旧版应用作为新版应用的基线文件。其中，基线文件是指同一应用在同时分支时间线上不同时间点的版本状态。例如，应用在早期为a版本，a版本的代码经过逻辑更新产生了b版本的代码，在b这个时间点上，就可以计算出从a版本到b版本之间的差异，称之为差量(diff)即增量，此处将a版本应用的代码文件称之为基线文件，随着应用的不断机选迭代，可能生成该应用一串持续的基线文件和与基线文件对应的增量。

旧版应用作为新版应用的基线文件，该基线文件按包括：旧版应用的业务逻辑的基线文件和框架的基线文件，其中，业务逻辑的基线文件即旧版应用的第二业务部分对应的businessjavascript代码，框架的基线文件即旧版应用的第二框架部分对应的basejavascript代码，此处，将第二业务部分对应的businessjavascript代码记为businessjs0，以及将第二框架部分对应的basejavascript代码记为basejs0。

节点服务器在计算新版应用与旧版应用之间的增量时，可以基于计算机文件系统文件级别的二级制差量算法，对businessjs与businessjs0进行文件差量分解得到第一增量。相应地，节点服务器还可以基于计算机文件系统文件级别的二级制差量算法，对basejs与basejs0进行文件差量分解得到第二增量。

s207、节点服务器将计算出的增量下发给客户端中的操作系统。

节点服务器可以将计算出的增量，按照客户端的设备标识下发给对应的客户端中的操作系统。其中，计算出的增量至少包括第一增量，在实际应用中第一框架部分与第二框架部分存在差异，节点服务器可以计算出第二增量，并将该第二增量下发给操作系统。

s208、操作系统将增量发送给容器层。

本实施例中，预先在客户端中设置一个容器层，该容器层嫁接在客户端的操作系统如android或者ios等操作系统上。操作系统在接收到节点服务器下发的增量后，需要将增量发送给容器层，通过容器层对增量与旧版应用进行合并，以得到新版应用。

s209、容器层将增量与旧版应用进行合并，得到新版应用。

本实施例中，当新版应用只是对业务部分进行更新时，容器层则将第一增量与旧版应用的第二业务部分进行合并，就可以得到新版应用。当新版应用对业务部分和框架部分均进行更新时，容器层则需要将第一增量与与旧版应用的第二业务部分进行合并，以及将第二增量与旧版应用的第二框架部分进行合并，当两者合并完成后，就可以得到新版应用。容器层可以将第一增量对应的js文件与businessjs0合并，可以得到businessjs，将第二增量对应的js文件与basejs0合并，可以得到basejs，进而可以得到新版应用。

s210、容器层向操作系统发送用于对新版应用进行本地渲染的渲染指令。

具体地，容器层可以向操作系统中的框架层(framework)发送一个用于对新版应用进行本地渲染的指令，以使框架层根据指令对新版应用进行本地渲染。

s211、操作系统中的框架层执行渲染指令对新版应用进行本地渲染。

具体地，操作系统接收到渲染指令后，操作系统中的框架层就可以根据渲染指令动态化绘制用户界面(userinterface，简称ui)，即绘制应用中用户的可视操作界面。框架层在对新版应用进行渲染时，可以根据新版应用的业务逻辑对事件进行绑定，例如可以对ui点击事件的响应进行绑定，或者对页面内容的更新事件进行绑定，或者对滚动事件的监控等。进一步地，当完成事件绑定后，框架层就可以按照业务逻辑对事件静态的展示和对事件进行响应或者反馈。

s212、节点服务器与操作系统进行网络通信。

在对新版应用本地渲染完成后，节点服务器与操作系统可以进行网络通信，节点服务器与操作系统可以通过超文本传输协议(hypertexttransferprotocol，简称http)等形式的网络请求，完成数据及信息的交互与反馈。

由于与新版应用相关的原始数据和reactjs文件都存储在服务器端或者云端，节点服务器将原始数据和reactjs文件通过http等形式的网络请求下发给客户端中操作系统。在用户使用新版应用的过程中，操作系统可以通过http等形式的网络请求向节点服务器发送一些网络请求。

例如，以新版应用中的登陆页面作为一个应用场景进行说明：登录页面的相关数据就是原始数据，该登录页面本身由reactjs编写的js文件，该登录页面的原始数据代表当前用户是否登录的数据结构信息，节点服务器可以通过http等形式的网络请求将登录页面的原始数据以及该登录页面的js文件下发给客户端中容器层。当用户点击登陆按钮后，容器层可以向节点服务器发送尝试登陆的网络请求，可以在该网络请求中携带当前用户输入的账户和密码等信息。节点服务器可以进行验证后，在验证合法后，可以允许该用户登录新版应用。

s212、操作系统与容器层之间进行相互通信。

操作系统与容器层之间可以相互通信，操作系统可以将对事件的一些相关操作发送给容器层，通过该容器层对这些相关操作进行实现，以产生相关的响应或反馈，容器层可以将这些响应或者反馈发送给操作系统。

本实施例提供的基于增量的应用更新方法，通过服务器将新版应用拆分成用于表示新版应用业务逻辑的第一业务部分和用于表示新版应用运行时所需框架的第一框架部分，服务器获取客户端当前待更新的旧版应用的第二业务部分，服务器获取第一业务部分与第二业务部分之间的第一增量，服务器将第一增量发送给客户端，客户端利用第一增量将旧版应用更新到新版应用。本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

进一步地，在框架部分发生变化时，还可以下发框架部分的增量，以完成对旧版应用的更新，保证了更新后的新版应用的完整性。

本实施例中，容器层中设置有reactnativ框架，由于reactnative框架具有跨平台开发的特性，下发的第一增量或第二增量可以并直接执行，不需要进行安装等操作，从而可以随时加载不同的javascript文件，从而实现了对客户端的动态部署。

实施例三

如图3所示，其为本发明实施例三提供的基于增量的应用更新方法的流程示意图。本实施例中，执行该基于增量的应用更新方法的主体为服务器，该基于增量的应用更新方法包括以下步骤：

s301、将新版应用拆分成用于表示新版应用业务逻辑的第一业务部分和用于表示新版应用运行时所需框架的第一框架部分。

本实施例中，将用于表示应用的业务逻辑的部分称为第一业务部分，用于表示应用运行时所需框架的部分称为第二框架部分。本实施例中，服务器首先需要将新版应用拆分成第一业务部分和第一框架部分。优选地，服务器可以根据新版应用中所包括的用于区别第一框架部分的标识符，将新版应用拆分成第一业务部分和第一框架部分。

s302、获取客户端当前待更新的旧版应用的第二业务部分。

本实施例中，预先设置有一个版本数据库，在该版本数据库中可以存储应用各个版本拆分后的业务部分和框架部分。

具体地，按照版本信息如版本号与业务部分和框架部分以及存储位置建立映射关系，根据该映射关系将各个版本的业务部分和框架部分存储在版本数据库中相应位置上。

本实施例中，服务器在获取客户端当前待更新的旧版应用的第二业务部分之前，服务器还需要获取到客户端上旧版应用的版本信息。服务器在获取版本信息后，可以根据版本信息查询到与该版本信息对应的第二业务部分。

关于客户端上旧版应用的版本信息的获取过程，可参见上述实施例一s102中相关内容的记载，此处不再赘述。

s303、获取第一业务部分与第二业务部分之间的第一增量。

具体地，服务器基于计算机文件系统文件级别的二级制差量算法，对第一业务部分和第二业务部分进行文件差量分解得到第一增量。本实施例中，通过二级制差量算法计算得到的第一增量，将是一个不可执行或者不可被直接识别的二进制数据。

s304、将第一增量发送给客户端，以使客户端利用第一增量将旧版应用更新为新版应用。

在获取到第一增量后，服务器可以将第一增量发送给客户端，以便于客户端可以利用该第一增量对旧版更新进行更新。

本实施例提供的基于增量的应用更新方法，通过服务器将新版应用拆分成用于表示新版应用业务逻辑的第一业务部分和用于表示新版应用运行时所需框架的第一框架部分，服务器获取客户端当前待更新的旧版应用的第二业务部分，服务器获取第一业务部分与第二业务部分之间的第一增量，服务器将第一增量发送给客户端，以使客户端利用第一增量将旧版应用更新到新版应用。本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

实施例四

如图4所示，其为本发明实施例四提供的基于增量的应用更新方法的流程示意图。本实施例中，执行该基于增量的应用更新方法的主体为客户端，该基于增量的应用更新方法包括以下步骤：

s401、接收服务器发送的第一增量，其中，所述第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量。

其中，第一业务部分用于表示新版应用业务逻辑的部分，第二业务部分用于表示旧版应用业务逻辑的部分；旧版应用为客户端当前待更新的应用，而新版应用为该客户端对旧版应用进行更新后对应的应用。

目前，用户可以在客户端上按照自己的需求安装一些应用，按照的应用在实际应用中往往更新换代较快，需要用户不断地对安装的应用进行更新。或者当开发者对应用进行了更新之后，就会试图提交到应用市场，应用市场对应的服务器就可以主动提醒用户对应用进行更新。

实际应用中，一个应用在更新换代的过程中，往往调整该应用的业务逻辑，而该应用运行时所需框架部分往往不会变化。当对客户端上的某一应用进行更新时，客户端可以接收到服务器发送的第一增量，其中，第一增量为新版应用的第一业务部分与旧版应用的第二业务部分之间的增量。

优选地，客户端可以向服务器发送更新请求，服务器可以根据更新请求，获取到第一增量，然后发给客户端。可选地，客户端可以接收到服务器主动下发的用于对旧版应用进行更新的第一增量。

s402、利用第一增量将旧版应用更新到新版应用。

客户端在接收到第一增量后，可以利用该第一增量对旧版应用进行更新，以得到新版应用。具体地，客户端基于计算机文件系统文件级别的二级制差量算法，对第一增量和第二业务部分进行文件差量合并，以得到新版应用。由于一般情况下，应用运行时所需的框架部分往往不会发生变化，客户端将第一增量与旧版应用所对应的第二业务部分进行文件差量合并后，就可以得到新版应用。

本实施例提供的基于增量的应用更新方法，客户端通过接收服务器发送的第一增量，其中，第一增量为新版应用的第一业务部分与旧版应用的第二业务部分之间的增量，客户端利用第一增量将旧版应用更新到新版应用。本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

实施例五

如图5所示，其为本发明实施例五提供的基于增量的应用更新方法的流程示意图。该基于增量的应用更新方法包括以下步骤：

s501、服务器对新版应用的源文件进行编译转换成能够被客户端识别的结果文件。

关于对s501的介绍，可参见上述实施例二中相关内容的记载，此处不再赘述。

s502、服务器对新版应用拆分成第一业务部分和第一框架部分。

对新版应用的源文件进行编译转换成能够被客户端识别的结果文件，从结果文件中的查找用于区别第一框架部分的标识符，根据标识符将新版应用拆分成第一业务部分和所述第一框架部分。服务器根据该标识符将第一框架部分抽离出来，剩余的部分就是新版应用的第一业务部分。

s503、服务器按照新版应用对应的版本信息，将第一业务部分和第二框架部分存储在版本数据库中。

其中，版本数据库中存储有应用各个版本进行拆分后得到的业务部分和框架部分。

服务器还可以新版应用拆分后得到的第一业务部分和第一框架部分，按照新版应用对应的版本信息如版本号，存储到版本数据库中。

s504、服务器根据客户端的版本信息在版本数据库中，查询旧版应用的第二业务部分。

s505、服务器基于计算机文件系统文件级别的二级制差量算法，对第一业务部分和第二业务部分进行文件差量分解得到第一增量。

s506、服务器根据客户端的版本信息在版本数据库中，查询旧版应用的第二框架部分。

s507、服务器基于计算机文件系统文件级别的二级制差量算法，对第一框架部分和第二框架部分进行文件差量分解得到第二增量。

一般情况下，一个应用在更新换代的过程中，往往调整该应用的业务逻辑，而该应用运行时所需框架部分往往不会变化。而当第一框架部分与第二框架部分存在差异时，服务器需要根据客户端的版本信息在版本数据库中，查询旧版应用的第二框架部分，然后基于计算机文件系统文件级别的二级制差量算法，对第一框架部分和第二框架部分进行文件差量分解得到第二增量。

s508、服务器将第一增量和第二增量发送给客户端。

服务器在计算出第一增量和第二增量后，可以将第一增量和第二增量下发给客户端。可选地，客户端上可以设置有缓存设备，在接收第一增量和或第二增量的过程中，利用断点续传机制，对接收到的数据进行缓存。当客户端在接收第一增量和或第二增量的过程中出现故障后，当故障恢复后可以从断点处继续接收数据，不需要重头开始增量接收，节省时间，提升更新效率。

s509、客户端将第一增量和第二增量与旧版应用进行合并，得到新版应用。

s510、客户端对合并得到的新版应用的完整性以及合法性进行验证。

服务器在向客户端下发第一增量和第二增量的过程中，可以将新版应用消息摘要算法第五版(messagedigestalgorithm，简称md5)值一起下发给客户端，在客户端将第一增量和第二增量与旧版应用合并后，可以计算合并得到的新版应用的md5值，将下发的md5值与合并得到的新版应用的md5值进行比较，当两个md5值一致时，说明合并得到的新版应用是完整的。

进一步地，在确定出合并得到的新版应用完整后，客户端可以采用密钥技术，对向其下发第一增量和第二增量的服务器的合法性进行验证。当合法性验证通过后，执行s511即客户端就对合并得到的新版应用进行本地渲染。如果完整性或者合法性的验证未通过，则不能客户端不能对合并得到的新版应用进行本地渲染，可以向用户返回存在风险的提醒。

s511、当合并得到的新版应用的验证通过时，客户端对合并得到的新版应用进行本地化渲染。

具体地，基于客户端上的reactnative框架，向客户端的操作系统中的框架层发送用于对该新版应用进行本地渲染的指令，操作系统中的框架层在接收到渲染指令后，就可以对该新版应用进行渲染。关于对新版应用进行本地渲染的过程，可参见上述实施例中相关内容的记载，此处不再赘述。

本实施例提供的基于增量的应用更新方法，通过服务器将新版应用拆分成用于表示新版应用业务逻辑的第一业务部分和用于表示新版应用运行时所需框架的第一框架部分，服务器获取客户端当前待更新的旧版应用的第二业务部分，服务器获取第一业务部分与第二业务部分之间的第一增量，服务器将第一增量发送给客户端，客户端利用第一增量将旧版应用更新到新版应用。本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

进一步地，本实施例中，当应用的业务逻辑以及运行时所框架均发生变化时，可以将第一增量与第二业务部分进行合并，以及将第二增量与第二框架部分进行合并，当合并完成后就可以从旧版应用更新到新版应用。

本实施例中，容器层中设置有reactnativ框架，由于reactnative框架具有跨平台开发的特性，下发的第一增量或第二增量可以并直接执行，不需要进行安装等操作，从而可以随时加载不同的javascript文件，从而实现了对客户端的动态部署。

实施例六

如图6所示，其为本发明实施例六提供的基于增量的应用测试方法的流程示意图。该基于增量的应用测试方法包括以下步骤：

s601、服务器按照预先配置的测试策略获取待测试的客户端。

随着科技的进步，客户端的种类可谓日新月异，而且功能也越来越丰富。相应的，越来越多的应用也伴随着客户端功能的多样化应运而生。随着移动客户端业务的快速发展，应用的版本也是快速迭代。为了更好地提升应用的性能，本实施例中，服务器可以选取部分客户端作为测试对象，在选取的客户端上对新版应用进行测试。

具体地，管理员可以预先配置一个测试策略，服务器可以按照该预先配置的测试策略，选取符合测试策略的客户端作为待测试的客户端。其中，测试策略可以根据不同的维度设置。其中不同的维度可以包括：设备维度、地理位置维度、时间维度、人群维度、曝光率维度、交易转换率维度以及版本维度等。例如，管理员可以根据设备维度预先配置一个测试策略，如测试策略可以为：选择客户端中机型为a的客户端待测试的客户端。服务器根据该测试策略，就可以选取机型为a的客户端作为待测试的客户端。

本实施例中，在服务器按照该预先配置的测试策略之前，服务器可以获取各客户端的相关信息，其中，客户端的相关信息包括：设备信息、地理位置信息、时间信息、人群信息、曝光率信息、交易转换率信息以及版本信息等。服务器对所有客户端的相关信息进行数据挖掘，以生成至少一个测试策略，然后管理员可以从生成的测试策略中选择一个作为预先配置的测试策略。

s602、服务器向客户端发送第一增量。

其中，第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量。第一业务部分用于表示新版应用业务逻辑的部分，第二业务部分用于表示旧版应用业务逻辑的部分；旧版应用为客户端当前待更新的应用；新版应用为客户端对旧版应用进行更新后对应的应用。

为了对新版应用进行测试，当选取出待测试的客户端之后，需要将待测试的客户端上当前的旧版应用更新为新版应用。实际应用中，应用在更新时往往只更新业务逻辑的业务部分，应用运行时所需的框架部分并不会经常发生变化。因此，本实施例中，服务器获取新版应用的第一业务部分和旧版应用的第二业务部分之间的第一增量，然后将第一增量发送给客户端。关于服务器获取新版应用的第一业务部分和旧版应用的第二业务部分之间的第一增量的具体过程，可参见上述实施例一和二中相关内容的记载，此处不再赘述。

s603、客户端利用第一增量将旧版应用更新到新版应用。

关于客户端利用第一增量将旧版应用更新到新版应用的具体过程，可参见上述实施例一和二中相关内容的记载，此处不再赘述。

s604、客户端对新版应用的使用数据进行采集，将采集到的使用数据发送给服务器。

对于大多数应用来说，收集一些客户端侧的用户的使用数据有助于服务器侧的研发者或者管理员对用户的行为做出相应的分析，从而能够对比出新版应用的新功能的加入是不是能提高用户的活跃度或转化率。

为了对客户端上运行的新版应用进行测试，客户端可以对新版应用的使用数据进行采集，然后将采集到的使用数据发送给服务器进行分析，以得到该新版应用的测试结果。优选地，服务器在向客户端发送第一增量的同时，向客户端下发新版应用的埋点，利用埋点对客户端上新版应用的使用数据进行统计。其中，使用数据可以包括新版应用对应的用户的信息、设备信息、操作信息以及交互信息等。

实际应用中，使用数据中可能会包括用户恶意用模拟器模拟的设备信息，这些模拟器模拟的设备信息将会影响a/btest的准确性，再例如使用数据中可能携带一些恶意脚本等，为了提高a/btest的准确性，需要对使用数据中的“脏数据”进行识别和过滤，客户端可以将采集到的使用数据进行过滤，将过滤出后的使用数据发送给服务器进行分析。

s605、服务器对使用数据进行分析，得到新版应用的测试结果。

在获取到待测试的客户端返回的使用数据后，服务器可以对使用数据进行分析，得到该新版应用的测试结果。进一步地，服务器可以将测试结果返回给应用的研发人员，以为研发人员提供完善新版应用的依据。针对不同的测试策略，可以获取到不同的测试结果，研发人员就可以看到一个应用在不同目标上的改变，比如交易量，转化率方面的改变，可以帮助研发人员对不同实现方案进行快速的敏捷实验，进而产生更大规模的验证产品及商业方案。

本实施例提供的基于增量的应用测试方法，通过服务器按照预先配置的测试策略获取待测试的客户端，服务器向客户端发送第一增量，客户端利用第一增量将旧版应用更新到新版应用，客户端对新版应用的使用数据进行采集，将采集到的使用数据发送给服务器，服务器对使用数据进行分析，得到新版应用的测试结果。本实施例中，根据测试策略选取待测试的客户端，然后向待测试的客户端下发第一增量，以完成客户端上旧版应用的更新，在测试的特殊性，需要选取大量的待测试客户端，当通过下发第一增量的方式来完成待测试的客户端的更新，可以降低资源占用率。而且本实施例中，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

实施例七

如图7所示，其为本发明实施例七提供的基于增量的应用测试方法的流程示意图。本实施例中，执行主体为服务器，该基于增量的应用测试方法包括以下步骤：

s701、按照预先配置的测试策略获取待测试的客户端。

关于服务器按照预先配置的测试策略获取待测试的客户端的过程，可参见上述实施例六中相关内容的记载，此处不再赘述。

本实施例中，在服务器按照该预先配置的测试策略之前，服务器可以定期采集各客户端的相关信息，其中，客户端的相关信息包括：设备信息、地理位置信息、时间信息、人群信息、曝光率信息、交易转换率信息以及版本信息等。服务器对所有客户端的相关信息进行数据挖掘，以生成至少一个测试策略，然后管理员可以从生成的测试策略中选择一个作为预先配置的测试策略。

s702、向客户端发送第一增量，以使客户端利用第一增量将旧版应用更新到新版应用。

其中，第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；第一业务部分用于表示新版应用业务逻辑的部分，所述第二业务部分用于表示旧版应用业务逻辑的部分；旧版应用为客户端当前待更新的应用；新版应用为客户端对旧版应用进行更新后对应的应用。

关于服务器获取新版应用的第一业务部分和旧版应用的第二业务部分之间的第一增量的具体过程，以及客户端利用第一增量将旧版莹莹更新到新版应用的具体过程，可参见上述实施例中相关内容的记载，此处不再赘述。

s703、接收客户端发送的使用数据，其中，使用数据是由客户端对新版应用的使用情况进行采集得到的。

s704、对使用数据进行分析以得到新版应用的测试结果。

关于服务器对使用数据进行分析以得到新版应用的测试结果的过程，可参见上述实施例六中相关内容的记载，此处不再赘述。

进一步地，在第一框架部分与第二框架部分存在差异时，服务器根据客户端的版本信息在版本数据库中，查询旧版应用的第二框架部分，基于计算机文件系统文件级别的二级制差量算法，对第一框架部分和第二框架部分进行文件差量分解得到第二增量，将第二增量发送给客户端，以使客户端对旧版应用的第二框架部分进行更新。

本实施例中，根据测试策略选取待测试的客户端，然后向待测试的客户端下发第一增量，以完成客户端上旧版应用的更新，在测试的特殊性，需要选取大量的待测试客户端，当通过下发第一增量的方式来完成待测试的客户端的更新，可以降低资源占用率。而且本实施例中，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

实施例八

如图8所示，其为本发明实施例七提供的基于增量的应用测试方法的流程示意图。本实施例中，执行主体为客户端，该基于增量的应用测试方法包括以下步骤：

s801、接收服务器发送的第一增量。

其中，第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；第一业务部分用于表示新版应用业务逻辑的部分，第二业务部分用于表示旧版应用业务逻辑的部分；旧版应用为客户端当前待更新的应用；新版应用为客户端对旧版应用进行更新后对应的应用。

关于第一增量的获取过程，可参见上述实施例中相关内容的记载，此处不再赘述。

s802、利用第一增量将旧版应用更新到新版应用。

关于客户端利用第一增量将旧版应用更新到新版应用的过程，可参见上述实施例中相关内容的记载，此处不再赘述。

s803、采集新版应用的使用数据发送给服务器，以使服务器对使用数据进行分析，得到新版应用的测试结果。

关于s803的介绍，可参见上述实施例中相关内容的记载，此处不再赘述。

客户端将这些使用数据发送给服务器，服务器可以对这些使用数据进行数据挖掘，得到该新版应用的测试结果，以为研发人员完善新版应用的性能提供依据。

本实施中，在客户端接收服务器发送的第一增量之前，客户端需要向服务器上报客户端的相关信息，以使服务器根据所有客户端的相关信息生成至少一个测试策略。

进一步地，客户端还可以接收服务器下发的第二增量，其中，第二增量为新版应用的第一框架部分和旧版应用的第二框架部分之间的增量，然后基于计算机文件系统文件级别的二级制差量算法，对第二增量和第二框架部分进行文件差量合并，以得到新版应用。

本实施例中，根据测试策略选取待测试的客户端，然后向待测试的客户端下发第一增量，以完成客户端上旧版应用的更新，在测试的特殊性，需要选取大量的待测试客户端，当通过下发第一增量的方式来完成待测试的客户端的更新，可以降低资源占用率。而且本实施例中，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

实施例九

如图9所示，其为本发明实施例九提供的基于增量的应用更新/测试系统的结构示意图。

该基于增量的应用更新系统包括：服务器1和客户端2。

服务器1，用于将新版应用拆分成用于表示业务逻辑对应的第一业务部分和新版应用运行时所需框架对应的第一框架部分，获取客户端当前待更新的旧版应用的第二业务部分，以及获取所述第一业务部分与所述第二业务部分之间的第一增量，并将第一增量发送给客户端2。

客户端2，用于利用第一增量将旧版应用更新到新版应用。

进一步地，服务器1，具体用于基于计算机文件系统文件级别的二级制差量算法，对第一业务部分和第二业务部分进行文件差量分解得到第一增量。

进一步地，客户端2，具体用于基于计算机文件系统文件级别的二级制差量算法，对所述第一增量和第二业务部分进行文件差量合并，以得到新版应用。

进一步地，在第一框架部分与第二框架部分存在差异时，服务器端1，还用于获取所述客户端所述旧版应用的第二框架部分，以及基于计算机文件系统文件级别的二级制差量算法，对第一框架部分和第二框架部分进行文件差量分解得到第二增量。

在获取到第二增量后，服务器1，还用于将第二增量发送给客户端2，客户端2将第二增量与第二框架部分进行合并，以得到新版应用。本实施例中，当应用的业务逻辑以及运行时所框架均发生变化时，需要将第一增量与第二业务部分进行合并，以及将第二增量与第二框架部分进行合并，当合并完成后就可以从旧版应用更新到新版应用。

本实施例提供的基于增量的应用更新系统可用于执行图1～5所示的基于增量的应用更新方法的流程，其具体工作原理不再赘述，详见方法实施例的描述。

本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

本实施例提供的基于增量的应用更新系统，还可以作为基于增量的应用测试系统使用，用于执行基于增量的应用测试方法的流程。

具体地：

服务器1，用于按照预先配置的测试策略获取待测试的客户端，向客户端发送第一增量，以及接收客户端发送的使用数据，对使用数据进行分析，得到新版应用的测试结果，其中，所述使用数据是由客户端对新版的使用情况进行采集得到的。

客户端2，用于利用第一增量将旧版应用更新到新版应用，对新版应用的使用数据进行采集，将采集到的使用数据发送给服务器。

上述基于增量的应用测试系统，可用于执行图6～8所示的基于增量的应用更新方法的流程，其具体工作原理不再赘述，详见方法实施例的描述。

本实施例中，根据测试策略选取待测试的客户端，然后向待测试的客户端下发第一增量，以完成客户端上旧版应用的更新，在测试的特殊性，需要选取大量的待测试客户端，当通过下发第一增量的方式来完成待测试的客户端的更新，可以降低资源占用率。而且本实施例中，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

实施例十

如图10所示，其为实施例十提供的基于增量的应用更新系统的结构示意图。该基于增量的应用更新系统包括：服务器端3和客户端4。其中，服务器端3中包括：管理中心(admin)31、服务器32、信息数据库33以及版本数据库34。客户端4包括：操作系统41和容器层42。其中，操作系统41为客户端4的操作系统，用于管理和控制客户端上的硬件与软件资源的计算机程序，是直接运行在“裸机”上的最基本的系统软件，任何其他软件都必须在操作系统的支持下才能运行。例如，客户端4为手机或者ipad等移动终端时，操作系统可以为android或者ios等。容器层42用于为客户端上的跨平台开发平台(reactnative)框架提供一个运行时所需的执行环境。

管理员可以对管理中心31配置下发增量的下发策略，在需要对应用进行更新时，可以根据该下发策略向客户端下发新版应用与旧版应用之间的增量。而且管理中心31可以接收对信息数据库33进行更新的数据，其中，信息数据库33用于存储客户端4的相关信息，其中，相关信息可以包括客户端4的设备信息、用户信息、版本信息、位置信息以及ip信息等。

管理中心31可以根据管理员配置的下发策略，获取与该下发策略对应的客户端4，例如，当下发策略为用户的位置信息，可以根据该位置信息查询到属于该位置信息指示的范围内的客户端，然后根据选取的客户端4的设备信息如设备标识。管理中心31将客户端的设备标识一个列表的形式发给服务器32。服务器32从信息数据库33中查询到所选取的客户端4上旧版应用的版本信息。

实际应用中，研发人员在对新版应用进行研发时，采用了不同的语音编写该新版应用，在研发完成后，研发人员需要将该新版应用的源文件提交给应用市场对应的服务器端。本实施例中，为了保证该新版应用的源文件能够被客户端识别或者执行，需要服务器32对研发人员所提交的新版应用进行编译转换成可以被客户端识别的结果文件。

服务器32对结果文件进行拆分，得到新版应用的第一业务部分和第一框架部分。进一步地，服务器32还可以新版应用拆分后得到的第一业务部分和第一框架部分，按照新版应用对应的版本信息如版本号，存储到版本数据库34中。

服务器32可以根据管理中心31发送的设备标识列表，从信息数据库33获取到每个客户端上安装的旧版应用的版本信息。版本信息可以为应用的版本号。为了实现对客户端上旧版应用的更新，针对每个客户端，服务器32需要从版本数据库34中获取与版本号对应的第二业务部分和第二框架部分。

服务器32计算新版应用的第一业务部分与旧版应用的第二业务部分之间的第一增量。而在第一框架部分和第二框架部分存在差异时，服务器32还可以计算新版应用的第一框架部分与旧版应用的第二框架部分之间的第二增量。

服务器32可以将计算出的增量，按照客户端的设备标识下发给对应的客户端中的操作系统41。其中，计算出的增量至少包括第一增量，在实际应用中第一框架部分与第二框架部分存在差异，服务器32可以计算出第二增量，并将该第二增量下发给操作系统41。操作系统41在接收到服务器32下发的增量后，需要将增量发送给容器层42，通过容器层42中的reactnative的框架对增量与旧版应用进行合并，以得到新版应用。在合并得到新版应用后，容器层42可以向操作系统41中的框架层(framework)发送一个用于对新版应用进行本地渲染的指令，以使框架层根据指令对新版应用进行本地渲染。

本实施例提供的基于增量的应用更新系统可用于执行图1～5所示的基于增量的应用更新方法的流程，其具体工作原理不再赘述，详见方法实施例的描述。

本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。进一步地，在框架部分发生变化时，还可以下发框架部分的增量，以完成对旧版应用的更新，保证了更新后的新版应用的完整性。而且在容器层使用了reactnativ技术，不需要对应用的增量进行安装等操作，就可以被执行，从而可以随时加载不同的javascript文件，从而实现了对客户端的动态部署。

实施例十一

如图11所示，其为实施例十一提供的基于增量的应用测试系统的结构示意图。该基于增量的应用测试系统包括：服务器端5和待测试的客户端6。其中，服务器端5包括：策略选取平台51、a/b测试(a/btest)投放平台以及数据库53。本实施例中，该a/btest投放平台52用于可以执行上述实施例中服务器的功能，可以获取增量并下发给客户端6。客户端6包括：操作系统61、容器层62和数据采集装置模块63、数据安全过滤模块64以及数据上报模块65。

管理员可以在策略选取平台51上预先配置一个测试策略，a/btest投放平台52可以根据该测试策略获取待测试的客户端6。关于测试策略的介绍，可参见上述实施例中相关内容的记载，此处不再赘述。

为了对新版应用进行测试，当选取出待测试的客户端6之后，需要将待测试的客户端6上当前的旧版应用更新为新版应用。客户端6中的操作系统61和容器层62，用于根据接收到的增量对旧版应用进行更新。关于将待测试的客户端6上旧版应用更新为新版应用的过程，可参见上述实施例中所提供的基于增量的应用更新方法中的流程，此处不再赘述。

对于大多数应用来说，收集一些客户端6侧的用户的使用数据有助于服务器端5侧的研发者或者管理员对用户的行为做出相应的分析，从而能够对比出新版应用的新功能的加入是不是能提高用户的活跃度或转化率。

为了对客户端6上运行的新版应用进行测试，客户端6中的数据采集模块63可以通过新版应用中的埋点对用户的使用数据进行采集，然后将采集到的使用数据发送给数据安全过滤模块64中，通过该数据安全过滤系统对一些非法数据进行过滤。为了提高a/btest的准确性，需要数据安全过滤模块64对使用数据中的“脏数据”进行识别和过滤，然后通过数据上报模块65将过滤后的使用数据上报给服务器端5，服务器端5可以将使用数据存储在数据库53中。

在获取到待测试的客户端6返回的使用数据后，a/btest投放平台52可以对使用数据进行分析，得到该新版应用的测试结果。进一步地，a/btest投放平台52可以将测试结果返回给应用的研发人员，以为研发人员提供完善新版应用的依据。针对不同的测试策略，可以获取到不同的测试结果，研发人员就可以看到一个应用在不同目标上的改变，比如交易量，转化率方面的改变，可以帮助研发人员对不同实现方案进行快速的敏捷实验，进而产生更大规模的验证产品及商业方案。

本实施例中，根据测试策略选取待测试的客户端，然后向待测试的客户端下发第一增量，以完成客户端上旧版应用的更新，在测试的特殊性，需要选取大量的待测试客户端，当通过下发第一增量的方式来完成待测试的客户端的更新，可以降低资源占用率。而且本实施例中，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

实施例十二

如图12所示，其为实施例十二提供的基于增量的应用更新和测试系统的结构示意图。该基于增量的应用更新和测试系统包括：服务器端7和客户端8。

其中，服务器端7包括：ftp服务器71、节点服务器72、策略配置服务器73、版本数据库74和信息数据库75。

客户端8包括：操作系统81和容器层82。

本实施例中，为了提高应用更新或者应用a/btest的测试效率，可以在客户端8的容器层82中建立一个代理(proxy)821，通过该proxy821更有效地对客户端的上层业务调用者屏蔽部分细节逻辑，提高基于增量的应用更新和测试系统使用效率。

容器层82中除了包括proxy821和reactnative框架822。由于reactnative框架822具有跨平台开发的特性，下发的第一增量或第二增量可以并直接执行，不需要进行安装等操作。本实施例中，操作系统81可以为ios操作系统也可以为android操作系统。

服务器端7通过ftp服务器71与客户端8中的proxy821进行相互通信。节点服务器72可以获取新班应用与旧版应用之间的增量，关于增量获取的具体过程，可参见上述实施例中相关内容的记载，此处不再赘述。节点服务器72可以根据策略配置服务器73所配置的下发或者测试策略，然后通过该ftp服务器71向proxy821下发增量，以使客户端8对旧版应用进行更新。

版本数据库中74存储有应用各个版本拆分后的业务部分和框架部分，存在版本数据库中的各版本应用均新版应用基线文件。信息数据库75中可以设置有多个数据库，例如，设备信息数据库、用户信息数据库、位置信息数据库等。

proxy821中设置有缓存模块8211、合并模块8212、完整性验证模块8213、合法性验证模块8214以及通信模块8215。

缓存模块接收ftp服务器71下发的增量，当出现故障时，缓存模块8211可以缓存下发的增量，当故障恢复后，缓存模块8211可以继续从出现断点的位置继续接收ftp服务器71下发的增量。本实施例中，缓存模块8211可以利用手机本身的硬件环境，建立磁盘+内存的二级缓存机制。

proxy821中的合并模块8212从缓存模块8211中获取增量，然后与旧版应用进行合并，以得到新版应用，完整性验证模块8213在合并得到新版应用后，可以对合并得到的新版应用的完整性进行验证，在验证通过后，合法性验证模块8214可以对增量的来源的合法性进行验证，在合法性验证通过后，通信模块8215可以向reactnative框架822，向客户端8中的操作系统81中的框架层发送用于对该新版应用进行本地渲染的指令，操作系统81中的框架层在接收到渲染指令后，就可以对该新版应用进行渲染。

实际应用中，由于reactnative框架822为一个跨平台开发平台，因此，设置在客户端的proxy821可以跨平台使用，即能够运用在android操作系统，也可以运用在ios操作系统中。

本实施例中，可以在客户端8中打包携带一个框架部分和业务部分，这样可以减少初次下载时占用的流量。

本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

进一步地，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

实施例十三

如图13所示，其为实施例十三提供的服务器的结构示意图。该服务器包括：拆分模块91、获取模块92和发送模块93。

其中，拆分模块91，用于将新版应用拆分成用于表示新版应用业务逻辑的第一业务部分和用于表示新版应用运行时所需框架的第一框架部分。

获取模块92，用于获取客户端当前待更新的旧版应用的第二业务部分，以及获取第一业务部分与第二业务部分之间的第一增量；

发送模块93，用于将第一增量发送给客户端，以使客户端利用第一增量将旧版应用更新为新版应用。

本实施例提供服务器还可以包括：接收模块94、选择模块95、查询模块96和存储模块97。

接收模块94，用于接收客户端发送的用于对旧版应用进行更新的更新请求；其中，更新请求中携带客户端的标识。

选择模块95，用于按照预先配置的下发策略选择客户端；

查询模块96，根据客户端的标识，从信息数据库中查询客户端上旧版应用的版本信息，以及根据客户端的版本信息在版本数据库中，查询旧版应用的第二业务部分；其中，版本数据库中存储有应用各个版本进行拆分后得到的业务部分和框架部分。

进一步地，存储模块97，用于按照新版应用对应的版本信息，将第一业务部分和第二框架部分存储在版本数据库中。

获取模块92，具体用于基于计算机文件系统文件级别的二级制差量算法，对第一业务部分和第二业务部分进行文件差量分解得到第一增量。

进一步地，获取模块92，还用于在第一框架部分与第二框架部分存在差异时，根据客户端的版本信息在版本数据库中，查询旧版应用的第二框架部分，基于计算机文件系统文件级别的二级制差量算法，对第一框架部分和第二框架部分进行文件差量分解得到第二增量。

发送模块93，还用于将第二增量发送给客户端，以使客户端对旧版应用的第二框架部分进行更新。

进一步地，拆分模块91，具体用于对新版应用的源文件进行编译转换成符合能够被客户端识别的结果文件，从结果文件中的查找用于区别第一框架部分的标识符，根据标识符将新版应用拆分成第一业务部分和第一框架部分。

本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

实施例十四

如图14所示，其为实施例十四提供的客户端的结构示意图。该客户端包括：接收模块101和更新模块102。

其中，接收模块101，用于接收服务器发送的第一增量，其中，第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；

更新模块102，用于利用第一增量将旧版应用更新到新版应用；

第一业务部分用于表示新版应用业务逻辑的部分，第二业务部分用于表示旧版应用业务逻辑的部分；旧版应用为客户端当前待更新的应用；新版应用为客户端对旧版应用进行更新后对应的应用。

进一步地，更新模块102，具体用于基于计算机文件系统文件级别的二级制差量算法，对第一增量和第二业务部分进行文件差量合并，以得到新版应用。

接收模块101，还用于接收服务器下发的第二增量，其中，第二增量为新版应用的第一框架部分和旧版应用的第二框架部分之间的增量。

更新模块102，具体用于基于计算机文件系统文件级别的二级制差量算法，对第二增量和第二框架部分进行文件差量合并，以得到新版应用。

本实施例中，客户端还可以包括：验证模块103。

验证模块103，用于对合并得到的新版应用的完整性以及合法性进行验证。

更新模块102，用于当合并得到的新版应用的验证通过后，对合并得到的新版应用进行本地化渲染，以完成对旧版应用的更新。

更新模块102，具体用于向客户端的操作系统中的框架层发送用于对新版应用进行本地渲染的指令，以使框架层根据指令对新版应用进行本地渲染。

进一步，接收模块101在接收第一增量和/或第二增量的过程中，利用断点续传机制对接收到的数据进行缓存。

本实施例中，利用新版应用与旧版应用之间的业务部分的第一增量，对旧版应用进行更新，只需要对新旧应用的业务逻辑部分进行比较，不再对应用进行整体比较，提高了应用更新的效率。

实施例十五

如图15所示，其为实施例十五提供的服务器的结构示意图。该服务器包括：获取模块111、发送模块112、接收模块113和分析模块114。

其中，获取模块111，用于按照预先配置的测试策略获取待测试的客户端。

发送模块112，用于向客户端发送第一增量，以使客户端利用第一增量将旧版应用更新到新版应用。

接收模块113，用于接收客户端发送的使用数据，其中，使用数据是由客户端对新版应用的使用情况进行采集得到的。

分析模块114，用于对使用数据进行分析以得到新版应用的测试结果。

其中，第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；第一业务部分用于表示新版应用业务逻辑的部分，第二业务部分用于表示旧版应用业务逻辑的部分；旧版应用为客户端当前待更新的应用；新版应用为客户端对旧版应用进行更新后对应的应用。

进一步地，服务器可以包括：拆分模块115、查询模块116和增量获取模块117。

拆分模块115，用于将新版应用拆分成第一业务部分和第一框架部分。

查询模块116，用于根据客户端的标识，从信息数据库中查询旧版应用的版本信息，以及根据旧版应用的版本信息在版本数据库中，查询旧版应用的第二业务部分。

增量获取模块117，用于基于计算机文件系统文件级别的二级制差量算法，对第一业务部分和第二业务部分进行文件差量分解得到第一增量；

其中，版本数据库中存储有应用各个版本进行拆分后得到的业务部分和框架部分。

进一步地，在第一框架部分与第二框架部分存在差异时，查询模块116，还用于根据客户端的版本信息在版本数据库中，查询旧版应用的第二框架部分；

增量获取模块117，还用于基于计算机文件系统文件级别的二级制差量算法，对第一框架部分和第二框架部分进行文件差量分解得到第二增量。

发送模块112，还用于将第二增量发送给客户端，以使客户端对旧版应用的第二框架部分进行更新。

获取模块111，还用于获取各客户端的相关信息，对所有客户端的相关信息进行数据挖掘，以生成至少一个测试策略，从生成的测试策略中选择一个作为预先配置的测试策略。

本实施例中，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

实施例十六

如图16所示，其为实施例十六提供的客户端的结构示意图。该客户端包括：接收模块121、更新模块122和采集发送模块123。

接收模块121，用于接收服务器发送的第一增量。

更新模块122，用于利用第一增量将旧版应用更新到新版应用。

采集发送模块123，用于采集新版应用的使用数据发送给服务器，以使服务器对使用数据进行分析，得到新版应用的测试结果。

其中，第一增量为新版应用的第一业务部分和旧版应用的第二业务部分之间的增量；第一业务部分用于表示新版应用业务逻辑的部分，第二业务部分用于表示旧版应用业务逻辑的部分；旧版应用为客户端当前待更新的应用；新版应用为客户端对旧版应用进行更新后对应的应用。

采集发送模块123，还用于向服务器上报客户端的相关信息，以使服务器根据所有客户端的相关信息生成至少一个测试策略。

更新模块122，具体用于基于计算机文件系统文件级别的二级制差量算法，对第一增量和第二业务部分进行文件差量合并，以得到新版应用。

接收模块121，还用于接收服务器下发的第二增量，其中，第二增量为新版应用的第一框架部分和旧版应用的第二框架部分之间的增量。

更新模块122，具体用于基于计算机文件系统文件级别的二级制差量算法，对第二增量和第二框架部分进行文件差量合并，以得到新版应用。

本实施例中，根据不同测试策略将所有客户端分割为多组的客户端，然后对不同组的客户端进行测试，从而能够获取应用在不同组客户端的测试结果，提高了应用abtest的全面性，能够为应用性能的完善提供更加有利的依据，由于只需要性客户端下发业务部分的增量，减少了应用敏捷迭代、快速试错的成本，为应用在不同维度的快速部署提供了技术实现上的新突破。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。