CN106155739A - 一种插件控量方法、服务器、客户端及控量平台 - Google Patents

Abstract

本发明公开一种插件控量方法、服务器、客户端及控量平台，该方法包括：服务器接收客户端发送的用于请求更新插件的检查更新请求，检查更新请求中携带有插件的插件数据；服务器基于检查更新请求，向控量平台发送请求配置信息，并基于请求配置信息，接收控量平台发送的配置文件和与配置文件对应的配置条件；服务器根据所述插件数据和配置条件，判断插件是否与配置文件匹配；当插件与配置文件匹配时，服务器发送配置文件至客户端，以使客户端能基于配置文件升级插件。本申请提供的方法和设备可以解决现有技术中插件难以灵活控量的技术问题。提供了一种能实现插件灵活控量的方法及设备。

Description

一种插件控量方法、服务器、客户端及控量平台

技术领域

本发明涉及互联网领域，尤其涉及一种插件控量方法、服务器、客户端及控量平台。

背景技术

随着应用的不断迭代，应用的体积不断增大，而应用新功能的添加，往往通过发布补丁版本来强制用户进行升级，结果频繁的更新升级，反而容易降低用户使用黏性。

为了解决升级频繁的问题，当前主要采取插件的方式：将主应用分拆，部分功能在插件中实现，需要用时不用安装，只需进行插件下载，如果有新功能的添加，也不需要更新应用，只要预留插件管理，通过添加插件的方式动态更新应用，当该新功能需要改进或扩展时，也只需要更新插件即可，无需频繁安装或卸载。

当前，插件的更新升级通常都是以配置文件的方式进行，即不同的主应用版本请求对应的插件配置文件，配置文件中包含插件的升级信息，客户端获得配置文件后，对配置文件的内部识别版本versionCode和接口版本iVersion进行简单比对后，再执行升级。

然而，当多个主应用版本对应同一配置文件时，客户端使用配置文件更新插件时，会将配置文件对应的其他版本也一起更新，影响版本范围较广，难做到灵活控量。

可见，现有技术中对插件的管理，存在难以灵活控量的技术问题。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的对象的数据的展示方法及相应的对象的数据的展示设备。

第一方面，本发明实施例提供了一种插件控量方法，包括：

服务器接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

所述服务器基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件；

所述服务器根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

当所述插件与所述配置文件匹配时，所述服务器发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

可选的，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

可选的，当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断所述插件是否与所述配置文件匹配，包括：判断所述主应用渠道号是否属于所述主应用渠道区间；当所述主应用渠道号属于所述主应用渠道区间时，判断所述系统版本是否属于所述系统版本区间；当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；当所述主应用版本属于所述主应用版本区间时，根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比；当所述客户端符合所述放量百分比时，判断所述插件版本是否属于所述插件版本区间。

可选的，当与所述插件匹配的配置文件的数量大于1时，所述服务器发送所述配置文件至所述客户端，包括：所述服务器从与所述插件匹配的配置文件中确定出插件版本最高的最高配置文件；所述服务器发送所述最高配置文件至所述客户端。

第二方面，本发明实施例提供一种插件控量方法，包括：

客户端发送用于请求更新插件的检查更新请求至服务器，所述检查更新请求中携带有所述插件的插件数据；

所述客户端基于所述检查更新请求，接收所述服务器返回的配置文件，其中，所述配置文件为所述服务器基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

所述客户端基于所述配置文件升级所述插件。

可选的，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

可选的，当所述配置文件包括用于升级的安装包的下载地址时，所述客户端基于所述配置文件升级所述插件，包括：所述客户端基于所述下载地址，下载所述安装包；所述客户端根据所述安装包升级所述插件。

第三方面，本发明实施例提供一种插件控量方法，包括：

控量平台接收服务器发送的请求配置信息；

所述控量平台基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器，以使所述服务器能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

第四方面，本发明实施例提供一种服务器，包括：

第一接收模块，用于接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

收发模块，用于基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件；

判断模块，用于根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

第一发送模块，用于当所述插件与所述配置文件匹配时，发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

可选的，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

可选的，当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断模块包括：渠道判断单元，用于判断所述主应用渠道号是否属于所述主应用渠道区间；系统判断单元，用于当所述主应用渠道号属于所述主应用渠道区间时，判断所述系统版本是否属于所述系统版本区间；应用判断单元，用于当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；百分比判断单元，用于当所述主应用版本属于所述主应用版本区间时，根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比；插件判断单元，用于当所述客户端符合所述放量百分比时，判断所述插件版本是否属于所述插件版本区间。

可选的，当与所述插件匹配的配置文件的数量大于1时，所述第一发送模块包括：确定单元，用于从与所述插件匹配的配置文件中确定出插件版本最高的最高配置文件；发送单元，用于发送所述最高配置文件至所述客户端。

第五方面，本发明实施例提供一种客户端，包括：

第二发送模块，用于发送用于请求更新插件的检查更新请求至服务器，所述检查更新请求中携带有所述插件的插件数据；

第二接收模块，用于基于所述检查更新请求，接收所述服务器返回的配置文件，其中，所述配置文件为所述服务器基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

升级模块，用于基于所述配置文件升级所述插件。

可选的，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

可选的，当所述配置文件包括用于升级的安装包的下载地址时，所述升级模块包括：下载单元，用于基于所述下载地址，下载所述安装包；升级单元，用于根据所述安装包升级所述插件。

第六方面，本发明实施例提供一种控量平台，包括：

第三接收模块，用于接收服务器发送的请求配置信息；

第三发送模块，用于基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器，以使所述服务器能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

本申请实施例中提供的技术方案，至少具有如下技术效果或优点：

本申请实施例提供的方法、服务器、客户端及控量平台，在服务器端通过配置条件匹配筛选出配置文件，再将配置文件发送至客户端以升级客户端的插件，通过可灵活设置的配置条件，筛选匹配出符合需求的配置文件，增加了插件控量的灵活性，有效解决了线上版本多时插件的控量升级问题，为线上版本的稳定和开发版本的灵活控量提供保障。进一步，在服务器端进行配置文件筛选，减少了客户端需要存储的配置文件，提高了客户端的后台管理和配置效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例中用于实施本发明插件控量方法的系统的结构图；

图2为本发明实施例中服务器端插件控量方法的流程图；

图3为本发明实施例中控制插件升级的交互流程图；

图4为本发明实施例中客户端插件控量方法的流程图；

图5为本发明实施例中控量平台端插件控量方法的流程图；

图6为本发明实施例中服务器的结构图；

图7为本发明实施例中客户端的结构图；

图8为本发明实施例中控量平台的结构图。

具体实施方式

本申请实施例中的技术方案，总体思路如下：

服务器接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据，服务器基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件，然后，所述服务器根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配，当所述插件与所述配置文件匹配时，所述服务器发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

即在服务器端通过配置条件匹配筛选出配置文件，再将配置文件发送至客户端以升级客户端的插件，通过可灵活设置的配置条件，筛选匹配出符合需求的配置文件，增加了插件控量的灵活性，有效解决了线上版本多时插件的控量升级问题，为线上版本的稳定和开发版本的灵活控量提供保障。另外，在服务器端进行配置文件筛选，减少了客户端需要存储的配置文件，提高了客户端的后台管理和配置效率。

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

在介绍本发明实施例之前，先介绍本发明实施例中插件控量方法所对应的系统，如图1所示，图1为一种用于实施本发明插件控量方法的系统，该系统包括：客户端101、服务器102和控量平台103，其中，所述服务器102可以如图1所示，与N个客户端101实现通信连接，N为自然数，其中，客户端101、服务器102和控量平台103之间的通信方式可以是有线通信，也可以是无线通信，本申请并不限定。

实施例一

本实施例提供一种插件控量方法，请参考图2，图2为本申请实施例中插件控量方法的流程图，如图2所示，该方法包括：

步骤S201，服务器102接收客户端101发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

步骤S202，所述服务器102基于所述检查更新请求，向控量平台103发送请求配置信息，并基于所述请求配置信息，接收所述控量平台103发送的配置文件和与所述配置文件对应的配置条件；

步骤S203，所述服务器102根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

步骤S204，当所述插件与所述配置文件匹配时，所述服务器102发送所述配置文件至所述客户端101，以使所述客户端101能基于所述配置文件升级所述插件。

在本申请实施例中，所述客户端101具体可以是智能手机，也可以是平板电脑，还可以是智能穿戴设备，本申请并不限定。

下面，结合图2详细介绍本申请实施例提供的方法的具体实现步骤：

首先，执行步骤S101，服务器102接收客户端101发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据。

在本申请实施例中，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端101的系统版本和所述客户端101的用户唯一标识。

具体来讲，由于插件往往没有独立运行的入口，需要从主应用中打开，故用于表征插件的插件数据，不仅可以包括所述插件的插件名称和插件版本，还可以包括所述插件对应的主应用版本和主应用渠道号。进一步，客户端101上安装的系统不同对插件的开发和升级的要求也不同，故所述插件数据还可以包括所述系统版本。另外，为了便于服务器102与客户端101通信，所述插件数据还可以包括所述用户唯一标识。

在具体实施过程中，所述客户端101的系统版本为所述客户端101上安装的系统的版本，比如，Android系统的4.4版、Android系统的5.0版或Windows98等。所述客户端101的用户唯一标识是能够唯一识别客户端101的标识，比如，客户端101的WIFI(WirelessFidelity，无线局域网)地址、MAC(Media Access Control，媒体访问控制)地址或安装的系统的序列号等。

接下来，执行步骤S202，所述服务器102基于所述检查更新请求，向控量平台103发送请求配置信息，并基于所述请求配置信息，接收所述控量平台103发送的配置文件和与所述配置文件对应的配置条件。

需要说明的是，在所述服务器102向控量平台103发送请求配置信息之前，所述服务器102可以解析所述检查更新请求，以获取所述检查更新请求携带的所述插件数据。当然，在具体实施过程中，也可以是在所述服务器102向控量平台103发送请求配置信息之后，所述服务器102解析所述检查更新请求，以获取所述插件数据，在此不作限制。

在本申请实施例中，所述配置文件包括用于升级的安装包的下载地址，以便于客户端101从所述下载地址下载所述安装包，所述配置文件中还可以包括插件的接口版本或插件安装包的大小等插件信息，以便于客户端101为插件的升级安装作预留空间等准备，当然，所述配置文件中还可以直接包括需要下载的插件升级文件，以便于客户端101能直接对需要升级的插件进行升级。

在本申请实施例中，所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

其中，所述放量百分比是一种筛选维度，用于控制升级的客户端的比例，以实现新版插件的逐件上量，避免大量客户端同一时段均升级为新版插件，以不利于新版插件的问题控制。例如，放量百分比为10，那100个检查更新请求里只会有10个可以通过该条件的筛选。对放量百分比的控制是根据每个客户端的用户唯一标识筛选的，每个用户唯一标识为一个对象，当放量百分比为A时，控制100个对象中只有A个对象可以通过筛选。

在具体实施过程中，服务器102向控量平台103发送请求配置信息，以获取配置文件和配置条件的方式可以有多种，下面列举三种为例：

第一种，获取预设时间段内新推出的所有配置文件及对应的配置条件。

即服务器102向控量平台103发送请求配置信息后，基于所述请求配置信息，接收所述控量平台103发送的需升级配置文件组和对应的配置条件。

其中，所述需升级配置文件组为：预设时间段内所有需要升级的插件对应配置文件。

例如，服务器102向控量平台103发送请求配置信息后，会获取到近2个月内新推出的所有配置文件及对应的配置条件。

需要说明的是，为了便于灵活控量，所述需升级配置文件组也包括在所述预设时间段内，配置文件没有改变但对应的配置条件发生了改变的配置文件，以实现对老版本插件的控制。

第二种，获取与特定主应用版本号匹配的配置文件及对应的配置条件。

即在服务器102向控量平台103发送请求配置信息之前，服务器102先解析出所述插件数据，以获取需升级插件的主应用版本号；然后服务器102再向控量平台103发送携带所述主应用版本号的请求配置信息，并基于所述请求配置信息，接收所述控量平台103发送的与所述主应用版本号匹配的全部配置文件组和对应的配置条件。

例如，需升级插件的主应用版本号为01203，则服务器102向控量平台103发送的请求配置信息携带有01203的版本号，故获取到与01203的版本号匹配的所有配置文件及对应的配置条件。

当然，在具体实施过程中，所述请求配置信息也可以携带客户端101的系统版本以获得与所述系统版本匹配的配置文件及对应的配置条件，在此不作限制。

第三种，获取服务器102未获取过的配置文件及对应的配置条件。

即服务器102向控量平台103发送请求配置信息后，控量平台103会根据所述请求配置信息及之前与所述服务器102通信的历史通信记录，确定出不曾向所述服务器102发送过的最新配置文件及对应的配置条件，并将所述最新配置文件及对应的配置条件发送至所述服务器102。

例如，服务器102在第一时刻向所述控量平台103发送请求配置信息，获得了配置文件包a及对应的配置条件后，服务器103又在第二时刻向所述控量平台103发送请求配置信息，则获得所述第一时刻至所述第二时刻间新推出的最新配置文件及对应的配置条件。

需要说明的是，为了便于灵活控量，所述新推出的最新配置文件也包括在所述第一时刻至所述第二时刻间，配置文件没有改变但对应的配置条件发生了改变的配置文件，以实现对老版本插件的控制。

当然，在具体实施过程中，所述服务器102向控量平台103发送请求配置信息，以获取配置文件和配置条件不限于以上几种获取方法，基于不同的需求可以确定出不同的获取方法，对此本发明实施例不再详细列举，并且不作限制。

还需要说明的是，在具体实施过程中，所述服务器101与所述控量平台103可以是不同的电子设备，也可以是同一个电子设备，在此不作限制。

当所述服务器101与所述控量平台103是同一个电子设备时，所述向控量平台103发送请求配置信息，并基于所述请求配置信息，接收所述控量平台103发送的配置文件和与所述配置文件对应的配置条件具体可以为：

服务器101的处理器向内部的存储器发送一个请求配置信息，并基于所述请求配置信息，从所述存储器中读取到所述配置文件和所述配置条件。

接下来，执行步骤S203，所述服务器102根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配。

具体来讲，判断所述插件是否与所述配置文件匹配，主要是判断所述插件数据是否符合所述配置条件的要求，在具体实施过程中，所述配置条件可以设置为范围区间，比如，插件版本为1.0-4.5；所述配置条件还可以设置为多个值的区间，比如，主应用渠道号为1005、2043、1789或5403；所述配置条件还可以设置为定值，比如，匹配渠道为A渠道，在此不作限制。

在具体实施过程中，判断所述插件是否与所述配置文件匹配的方法可以有多种，下面列举两种为例：

第一种，对所有配置条件均进行判断。

即根据所述插件数据和所述配置条件，判断所述插件数据是否满足每项配置条件，当其满足每项配置条件时才确定所述插件与所述配置文件匹配。

例如：

当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断所述插件是否与所述配置文件匹配，具体为：

判断所述主应用渠道号是否属于所述主应用渠道区间，获得第一判断结果；并判断所述系统版本是否属于所述系统版本区间，获得第二判断结果；并判断所述主应用版本是否属于所述主应用版本区间，获得第三判断结果；并根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比，获得第四判断结果；并判断所述插件版本是否属于所述插件版本区间，获得第五判断结果；

当所述第一判断结果、所述第二判断结果、所述第三判断结果、所述第四判断结果和所述第五判断结果均为是时，才确定所述插件与所述配置文件匹配。

需要说明的是，上述每项判断不分先后主次。

第二种，按优先级进行匹配。

即按照预设的优先级，逐次判断所述插件数据是否满足每项配置条件，当其满足前一项配置条件时才进行下一项配置条件的判断，当其满足每项配置条件时才确定所述插件与所述配置文件匹配。

较优的，可以设置优先级由前到后的顺序为：匹配主应用渠道区间、匹配客户端的系统版本区间、匹配主应用版本区间、匹配放量百分比和匹配插件版本区间。

例如，所述配置条件包括所述优先级中的所有需匹配项时，按所述优先级逐一判断：

当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断所述插件是否与所述配置文件匹配，包括：

判断所述主应用渠道号是否属于所述主应用渠道区间；

当所述主应用渠道号属于所述主应用渠道区间时，判断所述系统版本是否属于所述系统版本区间；

当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；

当所述主应用版本属于所述主应用版本区间时，根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比；

当所述客户端符合所述放量百分比时，判断所述插件版本是否属于所述插件版本区间；

当所有判断结果均为是时，才确定所述插件与所述配置文件匹配。

再例如，所述配置条件包括所述优先级中的部分需匹配项时，按所述优先级顺序，间隔判断：

当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述客户端的系统版本；所述配置条件包括：主应用版本区间、插件版本区间、客户端的系统版本区间时，所述判断所述插件是否与所述配置文件匹配，包括：

判断所述系统版本是否属于所述系统版本区间；

当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；

当所述主应用版本属于所述主应用版本区间时，判断所述插件版本是否属于所述插件版本区间；

当所有判断结果均为是时，才确定所述插件与所述配置文件匹配。

当然，在具体实施过程中，所述判断所述插件是否与所述配置文件匹配不限于以上几种判断方法，基于不同的需求可以确定出不同的判断方法，对此本发明实施例不再详细列举，并且不作限制。

再下来，执行步骤S204，当所述插件与所述配置文件匹配时，所述服务器102发送所述配置文件至所述客户端101，以使所述客户端101能基于所述配置文件升级所述插件。

在本申请实施例中，当步骤S203中判断出的与所述插件匹配的配置文件的数量大于1时，所述服务器102发送所述配置文件至所述客户端101，包括：

所述服务器102从与所述插件匹配的配置文件中确定出插件版本最高的最高配置文件；

所述服务器102发送所述最高配置文件至所述客户端101，以避免出现发送多个配置文件至客户端101导致升级混乱的情况。

在具体实施过程中，所述服务器102在发送所述配置文件至客户端101时，还携带发送了所述配置文件对应的配置条件，以使所述客户端能升级符合所述配置条件的插件，实现准确控量。

具体来讲，通过可灵活设置的配置条件，筛选出符合需求的配置文件，增加了插件控量的灵活性，有效解决了线上版本多时插件的控量升级问题。进一步，将原有的在客户端101进行配置文件的简单本地比对，改为在服务器端102通过预设的配置条件匹配筛选出合适的配置文件，再将配置文件发送至客户端101以升级客户端的插件，减少了客户端101需要存储的配置文件，提高了客户端的后台管理和配置效率。

在介绍了本实施例提供的方法的详细流程后，为了便于理解本实施例提供的方法的交互过程，下面，将结合图3来介绍本申请提供方法的一交互实例：

步骤S301，客户端101检测所述插件的状态，判断是否需要升级，如果需要升级则执行步骤S302；

步骤S302，客户端101生成和发送所述插件对应的检查更新请求至服务器102；

步骤S303，服务器102解析所述检查更新请求，获得所述检查更新请求中携带的所述插件数据；

步骤S304，服务器102基于所述检查更新请求，向控量平台103发送请求配置信息；

步骤S305，控量平台103基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至服务器102；所述配置文件和与所述配置文件为控量平台103预先制备的；

步骤S306，服务器102根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配，当所述插件与所述配置文件匹配时，执行步骤S307；

步骤S307，服务器102发送所述配置文件至所述客户端101；

步骤S308，客户端101基于所述配置文件升级所述插件。

基于同一发明构思，从图1所示系统中的所述客户端101的角度，本发明提供了另一实施例，详见实施例二。

实施例二

本实施例提供了一种插件控量方法，如图4所示，所述方法包括：

步骤S401，客户端101发送用于请求更新插件的检查更新请求至服务器102，所述检查更新请求中携带有所述插件的插件数据；

步骤S402，所述客户端101基于所述检查更新请求，接收所述服务器102返回的配置文件，其中，所述配置文件为所述服务器102基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

步骤S403，所述客户端101基于所述配置文件升级所述插件。

下面，结合图4详细介绍本申请实施例提供的方法的具体实现步骤：

首先，执行步骤S401，客户端101发送用于请求更新插件的检查更新请求至服务器102，所述检查更新请求中携带有所述插件的插件数据。

所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

在实施例一中，已对插件数据进行说明，在此不再累述。

具体来讲，触发客户端101发送检查更新请求至服务器102的方式可以有多种，下面列举三种为例：

第一种，用户手动触发。

即客户端101接收到用户作用于需升级插件的触发操作；并基于所述触发操作，生成和发送所述检查更新请求至服务器102。

在具体实施过程中，所述触发操作可以是用户点击插件上的设置选项，再选择升级选项的操作，也可以是用户在管理软件中点击升级所有应用的操作，在此不作限制。

第二种，定时发送检查更新请求。

即客户端101按照插件中预设的时间段，先定期检测所述插件的状态，判断是否需要升级，如果需要则生成和发送所述插件对应的检查更新请求至服务器102。

所述预设的时间段可以是一个月或10天，在此不作限制。

第三种，接收到服务器升级通知后，发送检查更新请求。

即当插件需要升级时，服务器102发送可升级通知至客户端101，当用户打开所述插件或所述插件的主应用时，会弹出升级提示，用户根据所述升级提示选择确认升级后，客户端101生成和发送所述插件对应的检查更新请求至服务器102。

当然，在具体实施过程中，触发客户端101发送检查更新请求至服务器102不限于以上几种触发方法，基于不同的需求可以确定出不同的触发方法，对此本发明实施例不再详细列举，并且不作限制。

接下来，执行步骤S402，所述客户端101基于所述检查更新请求，接收所述服务器102返回的配置文件，其中，所述配置文件为所述服务器102基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

具体来讲，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

在实施例一中，已对配置文件和配置条件进行说明，在此不再累述。

再下来，执行步骤S403，所述客户端101基于所述配置文件升级所述插件。

在具体实施过程中，当所述配置文件包括用于升级的安装包的下载地址时，所述客户端101基于所述配置文件升级所述插件，包括：所述客户端101基于所述下载地址，下载所述安装包，再根据所述安装包升级所述插件。

当所述配置文件中直接包括所述安装包文件时，所述客户端101可以直接根据所述安装包文件升级所述插件。

具体来讲，基于所述配置文件升级所述插件为：按照所述配置文件对应的配置条件，升级符合所述配置条件要求的插件，即通过配置条件的设置避免配置文件更改后，影响的主应用或插件的版本范围过广，实现准确控量。

基于同一发明构思，从图1所示系统中的所述控量平台103的角度，本发明提供了另一实施例，详见实施例三。

实施例三

本实施例提供了一种插件控量方法，如图5所示，所述方法包括：

步骤S501，控量平台103接收服务器102发送的请求配置信息；

步骤S502，所述控量平台103基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器102，以使所述服务器102能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

下面，结合图5详细介绍本申请实施例提供的方法的具体实现步骤：

首先，执行步骤S501，控量平台103接收服务器102发送的请求配置信息；

在实施例一中已对所述控量平台103接收服务器102发送的请求配置信息的方法进行详细说明，在此不再累述。

然后，执行步骤S502，所述控量平台103基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器102，以使所述服务器102能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

在本申请实施例中，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

在具体实施过程中，所述配置条件的设置可以有多种实现方式，列举两种为例：

第一种，在编写配置文件时一并设置配置条件。

即在研发人员制作所述配置文件时，将所述配置条件一并绑定制作，以使得配置文件在制备时就具备针对性，能利于对新版本的控量。

第二种，后期再制作配置文件。

即对老版本配置文件，或需要更改的配置文件，根据控量需求，在后期制作配置条件，并将配置条件与所述配置文件绑定或注入所述配置文件，以实现对老版本插件的灵活控量。

具体来讲，本申请可以根据具体的需要来灵活设置新老版本插件的配置文件对应的配置条件，以实现对大量插件的灵活控量，进一步，由于只需要加入配置条件就可控量新老版本插件，不需要采取应用版本升级的方式来支持对新老版本插件的大范围扩展，节约了应用版本升级成本。

基于同一发明构思，本发明实施例还提供了实施例一中方法对应的设备，见实施例四。

实施例四

本实施例提供了一种服务器102，如图6所示，所述服务器102包括：

第一接收模块601，用于接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

收发模块602，用于基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件；

判断模块603，用于根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

第一发送模块604，用于当所述插件与所述配置文件匹配时，发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

可选的，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

可选的，当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断模块603包括：渠道判断单元，用于判断所述主应用渠道号是否属于所述主应用渠道区间；系统判断单元，用于当所述主应用渠道号属于所述主应用渠道区间时，判断所述系统版本是否属于所述系统版本区间；应用判断单元，用于当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；百分比判断单元，用于当所述主应用版本属于所述主应用版本区间时，根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比；插件判断单元，用于当所述客户端符合所述放量百分比时，判断所述插件版本是否属于所述插件版本区间。

可选的，当与所述插件匹配的配置文件的数量大于1时，所述第一发送模块604包括：确定单元，用于从与所述插件匹配的配置文件中确定出插件版本最高的最高配置文件；发送单元，用于发送所述最高配置文件至所述客户端。

由于本发明实施例四所介绍的服务器，为实施本发明实施例一的插件控量方法所采用的电子设备，故而基于本发明实施例一所介绍的方法，本领域所属人员能够了解该设备的具体结构及变形，故而在此不再赘述。凡是本发明实施例一的方法所采用的设备都属于本发明所欲保护的范围。

基于同一发明构思，本发明实施例还提供了实施例二中方法对应的设备，见实施例五。

实施例五

本实施例提供了一种客户端101，如图7所示，所述客户端101包括：

第二发送模块701，用于发送用于请求更新插件的检查更新请求至服务器，所述检查更新请求中携带有所述插件的插件数据；

第二接收模块702，用于基于所述检查更新请求，接收所述服务器返回的配置文件，其中，所述配置文件为所述服务器基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

升级模块703，用于基于所述配置文件升级所述插件。

可选的，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

可选的，当所述配置文件包括用于升级的安装包的下载地址时，所述升级模块包括：下载单元，用于基于所述下载地址，下载所述安装包；升级单元，用于根据所述安装包升级所述插件。

由于本发明实施例五所介绍的客户端，为实施本发明实施例二的插件控量方法所采用的电子设备，故而基于本发明实施例二所介绍的方法，本领域所属人员能够了解该设备的具体结构及变形，故而在此不再赘述。凡是本发明实施例二的方法所采用的设备都属于本发明所欲保护的范围。

基于同一发明构思，本发明实施例还提供了实施例三中方法对应的设备，见实施例六。

实施例六

本实施例提供一种控量平台103，如图8所示，所述控量平台103包括：

第三接收模块801，用于接收服务器发送的请求配置信息；

第三发送模块802，用于基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器，以使所述服务器能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

可选的，所述配置文件包括用于升级的安装包的下载地址；所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

由于本发明实施例六所介绍的控量平台，为实施本发明实施例三的插件控量方法所采用的电子设备，故而基于本发明实施例三所介绍的方法，本领域所属人员能够了解该设备的具体结构及变形，故而在此不再赘述。凡是本发明实施例三的方法所采用的设备都属于本发明所欲保护的范围。

本申请实施例中提供的技术方案，至少具有如下技术效果或优点：

本申请实施例提供的方法、服务器、客户端及控量平台，在服务器端通过配置条件匹配筛选出配置文件，再将配置文件发送至客户端以升级客户端的插件，通过可灵活设置的配置条件，筛选匹配出符合需求的配置文件，增加了插件控量的灵活性，有效解决了线上版本多时插件的控量升级问题，为线上版本的稳定和开发版本的灵活控量提供保障。进一步，在服务器端进行配置文件筛选，减少了客户端需要存储的配置文件，提高了客户端的后台管理和配置效率。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的网关、代理服务器、系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了，A1、一种插件控量方法，包括：

服务器接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

所述服务器基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件；

所述服务器根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

当所述插件与所述配置文件匹配时，所述服务器发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

A2、根据A1所述的方法，其特征在于，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

A3、根据A1所述的方法，其特征在于：

所述配置文件包括用于升级的安装包的下载地址；

所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

A4、根据A1所述的方法，其特征在于，当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断所述插件是否与所述配置文件匹配，包括：

判断所述主应用渠道号是否属于所述主应用渠道区间；

当所述主应用渠道号属于所述主应用渠道区间时，判断所述系统版本是否属于所述系统版本区间；

当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；

当所述主应用版本属于所述主应用版本区间时，根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比；

当所述客户端符合所述放量百分比时，判断所述插件版本是否属于所述插件版本区间。

A5、根据A1所述的方法，其特征在于，当与所述插件匹配的配置文件的数量大于1时，所述服务器发送所述配置文件至所述客户端，包括：

所述服务器从与所述插件匹配的配置文件中确定出插件版本最高的最高配置文件；

所述服务器发送所述最高配置文件至所述客户端。

B6、一种插件控量方法，包括：

客户端发送用于请求更新插件的检查更新请求至服务器，所述检查更新请求中携带有所述插件的插件数据；

所述客户端基于所述检查更新请求，接收所述服务器返回的配置文件，其中，所述配置文件为所述服务器基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

所述客户端基于所述配置文件升级所述插件。

B7、根据B6所述的方法，其特征在于，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

B8、根据B6所述的方法，其特征在于：

所述配置文件包括用于升级的安装包的下载地址；

所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

B9、根据B6所述的方法，其特征在于，当所述配置文件包括用于升级的安装包的下载地址时，所述客户端基于所述配置文件升级所述插件，包括：

所述客户端基于所述下载地址，下载所述安装包；

所述客户端根据所述安装包升级所述插件。

C10、一种插件控量方法，包括：

控量平台接收服务器发送的请求配置信息；

所述控量平台基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器，以使所述服务器能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

C11、根据C10所述的方法，其特征在于：

所述配置文件包括用于升级的安装包的下载地址；

所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

D12、一种服务器，包括：

第一接收模块，用于接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

收发模块，用于基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件；

判断模块，用于根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

第一发送模块，用于当所述插件与所述配置文件匹配时，发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

D13、根据D12所述的服务器，其特征在于，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

D14、根据D12所述的服务器，其特征在于：

所述配置文件包括用于升级的安装包的下载地址；

所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

D15、根据D12所述的服务器，其特征在于，当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断模块包括：

渠道判断单元，用于判断所述主应用渠道号是否属于所述主应用渠道区间；

系统判断单元，用于当所述主应用渠道号属于所述主应用渠道区间时，判断所述系统版本是否属于所述系统版本区间；

应用判断单元，用于当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；

百分比判断单元，用于当所述主应用版本属于所述主应用版本区间时，根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比；

插件判断单元，用于当所述客户端符合所述放量百分比时，判断所述插件版本是否属于所述插件版本区间。

D16、根据D12所述的服务器，其特征在于，当与所述插件匹配的配置文件的数量大于1时，所述第一发送模块包括：

确定单元，用于从与所述插件匹配的配置文件中确定出插件版本最高的最高配置文件；

发送单元，用于发送所述最高配置文件至所述客户端。

E17、一种客户端，包括：

第二发送模块，用于发送用于请求更新插件的检查更新请求至服务器，所述检查更新请求中携带有所述插件的插件数据；

第二接收模块，用于基于所述检查更新请求，接收所述服务器返回的配置文件，其中，所述配置文件为所述服务器基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

升级模块，用于基于所述配置文件升级所述插件。

E18、根据E17所述的客户端，其特征在于，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

E19、根据E17所述的客户端，其特征在于：

所述配置文件包括用于升级的安装包的下载地址；

所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

E20、根据E17所述的客户端，其特征在于，当所述配置文件包括用于升级的安装包的下载地址时，所述升级模块包括：

下载单元，用于基于所述下载地址，下载所述安装包；

升级单元，用于根据所述安装包升级所述插件。

F21、一种控量平台，包括：

第三接收模块，用于接收服务器发送的请求配置信息；

第三发送模块，用于基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器，以使所述服务器能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

F22、根据F21所述的控量平台，其特征在于：

所述配置文件包括用于升级的安装包的下载地址；

所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

Claims (10)

1.一种插件控量方法，其特征在于，包括：

服务器接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

所述服务器基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件；

所述服务器根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

当所述插件与所述配置文件匹配时，所述服务器发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

2.如权利要求1所述的方法，其特征在于，所述插件数据包括以下一种或多种的组合：所述插件的插件名称、所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识。

3.如权利要求1所述的方法，其特征在于：

所述配置文件包括用于升级的安装包的下载地址；

所述配置条件包括以下一种或多种的组合：主应用版本区间、插件版本区间、主应用渠道、客户端的系统版本和放量百分比。

4.如权利要求1所述的方法，其特征在于，当所述插件数据包括：所述插件的插件版本、所述插件的主应用版本、所述插件的主应用渠道号、所述客户端的系统版本和所述客户端的用户唯一标识；所述配置条件包括：主应用版本区间、插件版本区间、主应用渠道区间、客户端的系统版本区间和放量百分比时，所述判断所述插件是否与所述配置文件匹配，包括：

判断所述主应用渠道号是否属于所述主应用渠道区间；

当所述主应用渠道号属于所述主应用渠道区间时，判断所述系统版本是否属于所述系统版本区间；

当所述系统版本属于所述系统版本区间时，判断所述主应用版本是否属于所述主应用版本区间；

当所述主应用版本属于所述主应用版本区间时，根据所述用户唯一标识，判断所述客户端是否符合所述放量百分比；

当所述客户端符合所述放量百分比时，判断所述插件版本是否属于所述插件版本区间。

5.如权利要求1所述的方法，其特征在于，当与所述插件匹配的配置文件的数量大于1时，所述服务器发送所述配置文件至所述客户端，包括：

所述服务器从与所述插件匹配的配置文件中确定出插件版本最高的最高配置文件；

所述服务器发送所述最高配置文件至所述客户端。

6.一种插件控量方法，其特征在于，包括：

客户端发送用于请求更新插件的检查更新请求至服务器，所述检查更新请求中携带有所述插件的插件数据；

所述客户端基于所述检查更新请求，接收所述服务器返回的配置文件，其中，所述配置文件为所述服务器基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

所述客户端基于所述配置文件升级所述插件。

7.一种插件控量方法，其特征在于，包括：

控量平台接收服务器发送的请求配置信息；

所述控量平台基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器，以使所述服务器能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。

8.一种服务器，其特征在于，包括：

第一接收模块，用于接收客户端发送的用于请求更新插件的检查更新请求，所述检查更新请求中携带有所述插件的插件数据；

收发模块，用于基于所述检查更新请求，向控量平台发送请求配置信息，并基于所述请求配置信息，接收所述控量平台发送的配置文件和与所述配置文件对应的配置条件；

判断模块，用于根据所述插件数据和所述配置条件，判断所述插件是否与所述配置文件匹配；

第一发送模块，用于当所述插件与所述配置文件匹配时，发送所述配置文件至所述客户端，以使所述客户端能基于所述配置文件升级所述插件。

9.一种客户端，其特征在于，包括：

第二发送模块，用于发送用于请求更新插件的检查更新请求至服务器，所述检查更新请求中携带有所述插件的插件数据；

第二接收模块，用于基于所述检查更新请求，接收所述服务器返回的配置文件，其中，所述配置文件为所述服务器基于所述插件数据和所述配置文件对应的配置条件，确定出的与所述插件匹配的配置文件；

升级模块，用于基于所述配置文件升级所述插件。

10.一种控量平台，其特征在于，包括：

第三接收模块，用于接收服务器发送的请求配置信息；

第三发送模块，用于基于所述请求配置信息，发送配置文件和与所述配置文件对应的配置条件至所述服务器，以使所述服务器能根据所述配置条件，判断需要升级的插件是否与所述配置文件匹配。