一种渠道安装包的处理方法和装置与流程

本发明涉及数据处理技术领域，特别是涉及一种渠道安装包的处理方法和一种渠道安装包的处理装置。

背景技术：

目前国内安卓应用分布市场的现状，当需要发布一个app(application，应用程序)时，一般需要生成多个渠道包以上传到不同的应用市场，这些渠道包需要包含不同的渠道信息，另外，不同的推广渠道/平台还会存在不同的计费合作模式，在app和后台交互或者数据上报时，都会带上各自的渠道计费信息，使得app发布者可以统计到每个分发市场的用户下载次数、用户转化率等关键数据，因此，发布一个app可能会产生成千上万的渠道包。

那么，在cdn(contentdeliverynetwork，内容分发网络)的静态场景下，由于携带有不同渠道信息的渠道包相当于独立的文件，在用户对不同渠道包进行下载时，均需要从cdn的边缘节点经由中间节点最终传回cdn源站(即cdn发布侧)，需要频繁回源拉取源文件，增加用户对多渠道安装包的下载资源成本。

技术实现要素：

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种渠道安装包的处理方法和相应的一种渠道安装包的处理装置。

为了解决上述问题，本发明实施例公开了一种渠道安装包的处理方法，应用于内容分发网络，所述内容分发网络包括内容分发源站和内容分发节点，所述方法包括：

通过所述内容分发源站获取所需发布的第一渠道安装包，对所述第一渠道安装包进行切分，得到第一渠道信息和不包含所述第一渠道信息的可复用信息；

通过所述内容分发源站向所述内容分发节点分发所述不包含所述第一渠道信息的可复用信息和第一渠道信息；

通过所述内容分发节点响应针对第二渠道安装包的下载请求，获取所述第二渠道安装包的第二渠道信息和所述不包含第一渠道信息的可复用信息，并根据所述第二渠道信息和所述不包含第一渠道信息的可复用信息得到目标渠道安装包。

可选地，所述对所述第一渠道安装包进行切分，包括：

确定所述可复用信息在所述第一渠道安装包的切分位置，根据所述切分位置切分所述第一渠道安装包；

所述确定所述可复用信息在所述第一渠道安装包的切分位置，包括：

计算所述第一渠道信息所在的第一渠道安装包的文件偏移量；

采用所述文件偏移量计算得到针对所述第一渠道安装包的切分点；

按照所述切换点对所述第一渠道安装包进行切分。

可选地，在通过所述内容分发源站获取所需发布的第一渠道安装包之前，所述方法还包括：

通过所述内容分发源站获取所需发布的母包安装包和多个渠道信息；所述多个渠道信息包括第一渠道信息和第二渠道信息；

将所述第一渠道信息和第二渠道信息分别注入到所述母包安装包的末尾，得到用于发布至不同渠道的第一渠道安装包和第二渠道安装包。

可选地，所述内容分发节点包括反向代理服务进程和缓存服务进程；

所述通过所述内容分发节点响应针对第二渠道安装包的下载请求，获取所述第二渠道安装包的第二渠道信息和所述不包含第一渠道信息的可复用信息，包括：

通过所述反向代理服务进程对所述下载请求的url进行分片替换；

通过所述缓存服务进程响应分片替换后的url得到第二渠道信息和可复用信息。

可选地，所述方法还包括：

通过所述反向代理服务进程接收所述缓存服务进程基于分片替换后的url的响应消息；

通过所述反向代理服务进程获取所述下载请求的url的响应头消息，将所述基于分片替换后的url的响应消息中的响应头消息替换为所述下载请求的url的响应头消息。

可选地，所述反向代理服务进程具有缓存列表；所述通过所述反向代理服务进程对所述下载请求的url进行分片替换，包括：

通过所述反向代理服务进程查询所述缓存列表中是否存在针对所述第二渠道安装包的url信息；

若所述缓存列表中存在针对所述第二渠道安装包的url信息，则判断所述下载请求是否为分片下载请求；

若所述下载请求为分片下载请求，则根据所述分片下载请求对所述下载请求的url进行分片替换。

可选地，所述针对所述第二渠道安装包的url信息包括切分点；所述分片下载请求包括请求起始点和请求结束点；

所述根据所述分片下载请求对所述下载请求的url进行分片替换，包括：

若所述分片下载请求的请求起始点的位置处于所述切分点之后，则保持针对所述第二渠道安装包的下载请求的url；

和/或，若所述分片下载请求的请求结束点的位置处于所述切分点之前，则将所述下载请求的url替换为母包安装包的url；

和/或，若所述切分点的位置处于所述分片下载请求的请求起始点和请求结束点之间，则将所述分片下载请求的请求起始点与所述切分点的url替换为母包安装包的url，以及保持所述切分点与所述分片下载请求的请求结束点的针对所述第二渠道安装包的下载请求的url。

可选地，所述方法还包括：

若所述缓存列表中不存在针对所述第二渠道安装包的url信息，则生成并向缓存服务进程发送针对第二渠道安装包的头部响应信息的头部请求；

若所述缓存服务进程具有针对所述第二渠道安装包的url信息的缓存，则通过所述缓存服务进程响应所述头部请求，向所述反向代理服务进程发送所述第二渠道安装包的头部响应信息；其中，所述第二渠道安装包的头部响应信息包括所述第二渠道安装包的url信息；

若所述缓存服务进程不具有针对所述第二渠道安装包的url信息的缓存，则通过所述反向代理服务进程向上一内容分发节点发送所述针对第二渠道安装包的头部响应信息的头部请求，直至所述反向代理服务进程接收到所述第二渠道安装包的头部响应信息为止。

本发明实施例还公开了一种渠道安装包的处理装置，应用于内容分发网络，所述内容分发网络包括内容分发源站和内容分发节点，所述装置包括：

渠道安装包切分模块，位于所述内容分发源站，用于获取所需发布的第一渠道安装包，对所述第一渠道安装包进行切分，得到第一渠道信息和不包含所述第一渠道信息的可复用信息；

渠道安装包分发模块，位于所述内容分发源站，用于向所述内容分发节点分发所述不包含所述第一渠道信息的可复用信息和第一渠道信息；

渠道安装包下载模块，位于所述内容分发节点，用于响应针对第二渠道安装包的下载请求，获取所述第二渠道安装包的第二渠道信息和所述不包含第一渠道信息的可复用信息，并根据所述第二渠道信息和所述不包含第一渠道信息的可复用信息得到目标渠道安装包。

可选地，所述渠道安装包切分模块包括：

渠道安装包切分子模块，用于确定所述可复用信息在所述第一渠道安装包的切分位置，根据所述切分位置切分所述第一渠道安装包。

可选地，所述切分位置确定子模块包括：

文件偏移量计算单元，用于计算所述第一渠道信息所在的第一渠道安装包的文件偏移量；

切分点计算单元，用于采用所述文件偏移量计算得到针对所述第一渠道安装包的切分点；

渠道安装包切分单元，用于按照所述切换点对所述第一渠道安装包进行切分。

可选地，在通过所述内容分发源站获取所需发布的第一渠道安装包之前，所述装置还包括：

母包安装包获取模块，位于所述内容分发源站，用于获取所需发布的母包安装包和多个渠道信息；所述多个渠道信息包括第一渠道信息和第二渠道信息；

渠道安装包生成模块，用于将所述第一渠道信息和第二渠道信息分别注入到所述母包安装包的末尾，得到用于发布至不同渠道的第一渠道安装包和第二渠道安装包。

可选地，所述内容分发节点包括反向代理服务进程和缓存服务进程；所述渠道安装包下载模块包括：

url分片替换子模块，用于通过所述反向代理服务进程对所述下载请求的url进行分片替换；

渠道信息获取模块，用于通过所述缓存服务进程响应分片替换后的url得到第二渠道信息和可复用信息。

可选地，所述渠道安装包下载模块还包括：

响应消息接收子模块，用于通过所述反向代理服务进程接收所述缓存服务进程基于分片替换后的url的响应消息；

响应消息替换子模块，用于通过所述反向代理服务进程获取所述下载请求的url的响应头消息，将所述基于分片替换后的url的响应消息中的响应头消息替换为所述下载请求的url的响应头消息。

可选地，所述反向代理服务进程具有缓存列表；所述分片替换子模块包括：

url信息查询单元，用于通过所述反向代理服务进程查询所述缓存列表中是否存在针对所述第二渠道安装包的url信息；

下载请求判断单元，用于若所述缓存列表中存在针对所述第二渠道安装包的url信息，则判断所述下载请求是否为分片下载请求；

url分片替换单元，用于若所述下载请求为分片下载请求，则根据所述分片下载请求对所述下载请求的url进行分片替换。

可选地，所述针对所述第二渠道安装包的url信息包括切分点；所述分片下载请求包括请求起始点和请求结束点；所述url分片替换单元包括如：

第一url分片替换子单元，用于若所述分片下载请求的请求起始点的位置处于所述切分点之后，则保持针对所述第二渠道安装包的下载请求的url；

第二url分片替换子单元，用于若所述分片下载请求的请求结束点的位置处于所述切分点之前，则将所述下载请求的url替换为母包安装包的url；

第三url分片替换子单元，用于若所述切分点的位置处于所述分片下载请求的请求起始点和请求结束点之间，则将所述分片下载请求的请求起始点与所述切分点的url替换为母包安装包的url，以及保持所述切分点与所述分片下载请求的请求结束点的针对所述第二渠道安装包的下载请求的url。

可选地，所述分片替换子模块还包括：

第一头部请求发送单元，用于若所述缓存列表中不存在针对所述第二渠道安装包的url信息，则生成并向缓存服务进程发送针对第二渠道安装包的头部响应信息的头部请求；

头部响应信息发送单元，用于若所述缓存服务进程具有针对所述第二渠道安装包的url信息的缓存，则通过所述缓存服务进程响应所述头部请求，向所述反向代理服务进程发送所述第二渠道安装包的头部响应信息；其中，所述第二渠道安装包的头部响应信息包括所述第二渠道安装包的url信息；

第二头部请求发送单元，用于若所述缓存服务进程不具有针对所述第二渠道安装包的url信息的缓存，则通过所述反向代理服务进程向上一内容分发节点发送所述针对第二渠道安装包的头部响应信息的头部请求，直至所述反向代理服务进程接收到所述第二渠道安装包的头部响应信息为止。

本发明实施例还公开了一种电子设备，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现任一项所述渠道安装包的处理方法的步骤。

本发明实施例还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现任一项所述渠道安装包的处理方法的步骤。

本发明实施例包括以下优点：

在本发明实施例中，在内容分发网络的场景下，通过内容分发源站对所需发布的第一渠道安装包进行切分得到第一渠道信息和不包含第一渠道信息的可复用信息，并向内容分发节点进行分发切分后的第一渠道安装包，当内容分发节点接收到对第二渠道安装包的下载请求时，响应下载请求对第二渠道信息进行获取，并根据第二渠道信息和可复用信息得到目标渠道安装包。通过对渠道安装包的差分处理，将渠道包文件切分成小片，复用不包含渠道信息的文件分片，在cdn场景下降低文件回源的概率；以及，对cdn节点所进行的改造，针对同一母包对应的所有渠道包复用相同的文件块，在本地只存储不同渠道包的差分文件块，节省多渠道安装包发布时的存储资源成本，并且在减少文件的回源概率的同时，使得能够在对多渠道安装包发布与下载时降低带宽资源与时间资源的成本。

附图说明

图1是现有技术中发布渠道安装包的流程示意图；

图2是现有技术中下载渠道安装包的流程示意图；

图3是内容分发网络(即cdn)的架构示意图；

图4是cdn内部的进程关系示意图；

图5是本发明的一种渠道安装包的处理方法实施例的步骤流程图；

图6是本发明的另一种渠道安装包的处理方法实施例的步骤流程图；

图7是本发明实施例中对渠道安装包进行发布的流程示意图；

图8是本发明的又一种渠道安装包的处理方法实施例的步骤流程图；

图9是本发明实施例中对渠道安装包进行切片下载的流程示意图；

图10是本发明的一种渠道安装包的处理装置实施例的结构框图；

图11是本发明实施例的一种计算机可读存储介质的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

游戏合作平台可以是一种整合了数百款游戏，提供接入支持、支付渠道、运营推广等服务的开放平台，此开放平台与渠道合作者(例如游戏发布平台)之间可以存在多种合作模式，例如cps(costpersales，指的是以实际销售额来换算广告金额，即按照收益进行分成)、cpm(costpermile，每千人成本，为一种展示付费广告形式)、cpc(costperclick，每点击成本，为一种点击付费广告形式，即按点击付费)等，不同的合作模式需要在游戏的apk安装包(androidpackage，是安卓手机操作系统的安装包文件，其相当于一个压缩包(zip))注入渠道信息，以便用于后续的商家与平台企业件的分成结算。

对于cdn的应用场景而言，如图1所示，针对注入渠道信息的安装包进行发布，可以对apk安装包(可以称为母包)注入不同渠道信息(例如渠道信息a、渠道信息b、渠道信息c)，被注入了不同渠道信息的apk安装包相当于相互独立的文件，即渠道包a、渠道包b与渠道包c相互独立，这些相互独立的文件可以由游戏发布者或接入者经由游戏发布平台发布到各个cdn厂商，例如海外cdn、国内cdn、企业cdn等。其中，游戏发布平台可以是企业内部的一个文件发布系统，其可以用于处理对不同版本的游戏外放操作。

一般情况下，cdn节点具有分片回源特性，该特性可以表现为在cdn业务节点的大文件下载过程中，cdn节点的ats缓存服务器将大文件分统一分割成为几mb的固定大小的小文件块(block)进行存储。

具体的，对所发布的渠道包的下载过程可以如图2所示，针对所述有的用户请求的渠道包，cdn节点均会回源到中间节点直至源站，进行渠道文件的拉取，例如用户c在对渠道包c进行下载的过程中，可以向边缘节点ats(apachetrafficserver，为一种高性能的web代理缓存服务器，其广泛用于cdn场景中)发送针对渠道包c的httpget下载请求，进而由边缘节点回源至中间节点ats，若中间节点ats未存储有渠道包c，则由中间节点回源至源站完成对渠道包c的拉取。

基于上述现有技术中发布和下载渠道安装包的过程，可能存在如下缺点：

(1)同一apk安装包(母包)注入了渠道信息后形成千上万的渠道包，所形成的千上万的渠道包在发布到cdn之后是绝对相互独立的，cdn厂商无法感知到这些渠道包体的内在联系；

(2)在cdn的静态业务场景中，所形成的千上万的渠道包很难有效的在cdn节点进行预热，导致一次有效的用户下载的成本非常大，表现为在cdn内部，源站的存储、边缘节点的存储、cdn节点回源带宽、游戏发布平台到cdn厂商的带宽等都会造成较多的浪费。

其中，在带宽成本的浪费上，不同的渠道包的下载，都会从边缘节点经由中间节点最终穿回源站，产生三段带宽成本，且由于渠道包的下载热点不集中，容易被cdn缓存服务器ats的lru算法(leastrecentlyused，为一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰)所淘汰，导致需要频繁回源拉取源文件；在存储成本的浪费上，对于边缘节点、中间节点而言，在ats的缓存逻辑中，不同渠道包会占用大量的磁盘存储空间，从而影响其他文件的存储，造成整个cdn节点的缓存命中率降低，对于源站而言，假设一个app的大小为1gb，如果在发布时需要发布1000个渠道包，那么源站的存储成本相应为1gb的1000倍，造成源站的存储空间的大量浪费；在发布时间成本的浪费上，app发布者需要将所有不同的渠道包发布到合作的cdn厂商，那么发布1000个1g的渠道包，在发布效率上会有很差的体验。

(3)在用户对渠道安装包的发布体验上，由于带宽存在瓶颈，当带宽严重不足时，可能会影响到其他业务，且由于无法对所有渠道包提前预热，用户在cdn节点下载渠道安装包时，当首个用户被调度到相应的cdn节点时，即便用户侧的网络状况良好，也可能会存在明显的下载卡顿的体验，这样的现象可能造成潜在用户流失的后果。

基于上述现有技术中发布和下载渠道安装包所存在的缺点，本发明的核心思想之一是由于渠道包包含大量重复文件，提出对多渠道安装包进行差分处理的技术构思，可以将这些渠道包在cdn的发布、分发、存储等多个环节进行差分处理，具体表现为将渠道包文件切分成小片，复用不包含渠道信息的文件分片，使得能够对整个发布、存储、节点缓存命中率进行指数级的优化提升，一方面可以极大的提高用户的发布打包体验，另一方面节约了大量的存储资源、带宽资源，即针对同一母包对应的所有渠道包复用相同的文件块，在本地只保存不同渠道包的差分文件块，提升cdn节点的存储效率，降低文件回源的概率。

在本发明实施例中，为了本领域技术人员更加了解本发明所提出的渠道安装包处理的应用场景，下面对cdn进行说明：

参照图3，示出了内容分发网络(即cdn)的架构示意图，cdn可以包括多个cdn节点，具体可以包括边缘节点、中间节点和源站，其中，源站可以将文件数据等存储至s3(simplestorageservice，对象存储服务器)。

在cdn节点中，每台服务器的主要业务进程可以包括nginx(反向代理服务器，其广泛用于cdn场景中)反向代理服务进程和ats(web代理缓存服务器)缓存服务进程。具体的，cdn内部的进程关系可以如图4所示，假设cdn节点机房包括服务器a、服务器b以及服务器c，每个服务器中可以各自具有反向代理服务进程以及缓存服务进程，且反向代理服务进程可以对不同服务器中的缓存服务进程进行访问。

其中，nginx反向代理服务进程主要可以用于处理各种用户的http请求，例如tls(transportlayersecurity，安全传输层协议)卸载、文件格式化分片、防盗链等复杂业务需求，而ats缓存服务进程可以主要负责文件的多级缓存，文件的缓存可以分为内存缓存和磁盘缓存。

参照图5，示出了本发明的一种渠道安装包的处理方法实施例的步骤流程图，应用于内容分发网络，所述内容分发网络包括内容分发源站和内容分发节点，具体可以包括如下步骤：

步骤501，通过内容分发源站获取所需发布的第一渠道安装包，对第一渠道安装包进行切分，得到第一渠道信息和不包含第一渠道信息的可复用信息；

在本发明实施例中，对于渠道安装包的cdn应用可以包括在cdn场景下对渠道安装包的发布过程以及在cdn场景下对渠道安装包的下载过程。

在cdn场景下对渠道安装包的发布过程，渠道包包含了大量重复文件，为了节省渠道安装包在cdn中的带宽资源以及存储资源，可以站在cdn发布侧，即内容分发源站，对所要发布的渠道安装包进行差分处理，具体可以表现为将渠道包文件切分成小片，实现复用不包含渠道信息的文件分片。

在本发明的一种实施例中，对第一渠道安装包的差分处理，可以表现为对第一渠道安装包进行切分得到相应的第一渠道信息和不包含第一渠道信息的可复用信息。

在实际应用中，首先可以确定可复用信息在第一渠道安装包的切分位置，然后可以根据所确定的切分位置切分第一渠道安装包。

具体的，对于切分位置的确定，可以计算第一渠道信息所在的第一渠道安装包的文件偏移量，然后采用文件偏移量计算得到针对第一渠道安装包的切分点，并按照切换点对第一渠道安装包进行切分。

步骤502，通过内容分发源站向所述内容分发节点分发不包含第一渠道信息的可复用信息和第一渠道信息；

在对第一渠道安装包进行切分之后，可以通过内容分发源站向内容分发节点发布所切分得到的不包含第一渠道信息的可复用信息和第一渠道信息，其中，不包含第一渠道信息的可复用信息可以指的是母包的文件部分，内容分发源站对渠道包进行了切片存储，且所有渠道包可以复用母包的文件部分，在对进行切分后的第一渠道安装包分发之后，内容分发源站可以对渠道安装包的第一渠道信息进行缓存，丢弃掉切分得到的可复用信息，即对第一渠道安装包进行切分存储，以达到节约指数级的存储空间的目的。

步骤503，通过内容分发节点响应针对第二渠道安装包的下载请求，获取第二渠道安装包的第二渠道信息和不包含第一渠道信息的可复用信息，并根据第二渠道信息和不包含第一渠道信息的可复用信息得到目标渠道安装包。

对于cdn场景下渠道安装包的下载过程，主要可以通过内容分发节点响应客户端所发送的下载请求实现，此内容分发节点可以指的是cdn边缘节点。

在本发明的一种实施例中，内容分发源站在对渠道安装包进行发布时对渠道安装包进行切分发布或切分存储，内容分发节点在响应针对第二渠道安装包的下载请求的过程中，同样可以基于切分下载的方式实现，以在减少文件的回源概率的同时，降低下载渠道安装包时的带宽资源与时间资源的成本。

具体的，所有渠道包可以复用母包的文件部分，此时可以无需获取不包含第二渠道信息的信息，直接复用不包含第一渠道信息的可复用信息即可，即可以对第二渠道安装包的第二渠道信息和不包含第一渠道信息的可复用信息进行获取，并根据所获取的第二渠道信息和可复用信息得到目标渠道安装包。

其中，渠道安装包为逻辑上的安装包，只有重新组装出来才有意义，那么所得到的目标渠道安装包可以是基于第二渠道信息和可复用信息重组得到的。针对目标渠道安装包的重组时机，可以是在边缘节点(即某个cdn节点)进行重组，也可以在内容分发源站进行重组，对此，本发明实施例不加以限制。

需要说明的是，本发明实施例中所提到的第一渠道安装包和第二渠道安装包在本质上是相同的，即并无特指也无先后顺序的区分，其中第一渠道安装包是基于对渠道安装包的分发角度，可以指的是源站的渠道包处理阶段进行定义的，而第二渠道安装包是基于对渠道安装包的下载角度，可以指的是边缘节点针对渠道包的分发阶段进行定义的，在实际应用中，所下载的第二渠道安装包与所分发的第一渠道安装包在本质上可以是相同的渠道安装包，且第一渠道安装包的分发过程同样也暗含了第二渠道安装包的分发过程，即客户端所请求下载的第二渠道安装包是已被内容分发源站进行切分与分发的渠道安装包。

在本发明实施例中，在内容分发网络的场景下，通过内容分发源站对所需发布的第一渠道安装包进行切分得到第一渠道信息和不包含第一渠道信息的可复用信息，并向内容分发节点进行分发切分后的第一渠道安装包，当内容分发节点接收到对第二渠道安装包的下载请求时，响应下载请求对第二渠道信息进行获取，并根据第二渠道信息和可复用信息得到目标渠道安装包。通过对渠道安装包的差分处理，将渠道包文件切分成小片，复用不包含渠道信息的文件分片，在cdn场景下降低文件回源的概率；以及，对cdn节点所进行的改造，针对同一母包对应的所有渠道包复用相同的文件块，在本地只存储不同渠道包的差分文件块，节省多渠道安装包发布时的存储资源成本，并且在减少文件的回源概率的同时，使得能够在对多渠道安装包发布与下载时降低带宽资源与时间资源的成本。

参照图6，示出了本发明的另一种渠道安装包的处理方法实施例的步骤流程图，侧重于渠道安装包的分布过程，主要是站在cdn发布侧，即应用于cdn源站，具体可以包括如下步骤：

步骤601，通过内容发布源站获取所需发布的母包安装包和多个渠道信息；

在本发明实施例中，对渠道安装包的分布过程主要可以表现为cdn源站对渠道包文件的切分打包操作。

具体的，在通过内容分发源站获取所需发布的渠道安装包之前，可以对渠道包进行差分打包。

在本发明的一种实施例中，针对某个母包安装包的发布，一般需要生成多个不同的渠道安装包以上传到不同的应用市场，在对多个不同的渠道安装包的生成过程中，可以获取所需发布的母包安装包与多个渠道信息以得到用于发布至不同渠道的多个渠道安装包。

步骤602，将多个渠道信息分别注入到母包安装包的末尾，得到用于发布至不同渠道的多个渠道安装包；

在实际应用中，母包安装包可以相当于zip压缩文件，其实质上可以由三个部分组成，包括内容块、中央目录和eocd(endofcentraldirectory，位于zip压缩包的结尾的一组数据字段之一，主要用于记录中央目录大小、偏移量和zip注释信息等)组成，此时可以将具体的渠道信息注入到zip文件的末尾，得到携带由不同渠道信息的不同渠道安装包。

其中，关于渠道信息的获取，可以是发布者向内容分发源站(可以指的的发布平台)发布的json文件，该文件内部的字段是cdn厂商规定好的规范，发布者需要遵循该规范进行渠道包的发布操作，否则会被视为一个正常的文件被发布，而被视为正常发布的文件则无法作为渠道信息进行使用。在具体实现中，cdn厂商可以预先定义固定的json格式的文件，其可以包含以下文件描述信息：母包名、渠道包名、渠道信息以及打包方式等，cdn可以根据事先约定的格式解析json文件，并按照用户在json中指定的字段，将母包打包成相应格式的渠道包。

具体的，目前可以支持支持v1签名和v2签名两种方式的安卓打包方案。

对于v1签名的打包逻辑，可以表现为检查本地是否存在母包apk，如果不存在，则从s3拉取对应的母包apk，添加渠道信息到母包的meta-inf/appchannel文件中；对于v2签名的打包逻辑，可以表现为检查本地是否存在母包apk，如果不存在，则从s3拉取对应的母包apk，找到母包apk的eocd块以及apk签名块，根据以上信息计算得到向包体添加内容的文件偏移量、id-values、渠道信息并添加，然后根据id-values计算新的签名块长度，生成新的签名块，在修改eocd的偏移量后将文件剩余的部分重写完整。

作为一种示例，第一渠道信息和第二渠道信息，将所述第一渠道信息和第二渠道信息分别注入到所述母包安装包的末尾，得到用于发布至不同渠道的第一渠道安装包和第二渠道安装包。需要说明的是，本发明实施例中所提到的第一渠道安装包和第二渠道安装包在本质上是相同的，即并无特指也无先后顺序的区分。

步骤603，对多个渠道安装包进行切分，得到渠道信息和不包含渠道信息的可复用信息；

在将具体的渠道信息注入到母包安装包的末尾得到多个渠道安装包之后，可以确定母包中所包含的可复用部分的位置，根据所确定的位置对所生成的多个渠道包进行切分，得到渠道安装包相对应的渠道信息和不包含渠道信息的可复用信息。

其中，与渠道安装包相对应的渠道信息可以指的是meta信息，不包含渠道信息的可复用信息可以指的是母包的可复用部分，对于某个渠道安装包而言，可以复用信息可以占总文件的99％左右，而meta信息占总文件的1％左右，此时cdn源站还可以对文件进行切片后存储，即可以通过对渠道安装包的切片存储以及所有渠道包复用母包的文件部分，在s3存储方面，存储母包的可复用部分以及各个渠道包的meta信息，节约指数级的存储空间。

在实际应用中，对母包安装包的末尾注入渠道信息后得到的渠道安装包，同样可以相当于zip压缩文件，其实质上同样可以由三个部分组成，包括内容块、中央目录和eocd，在对渠道安装包进行切分时，前半部分可以为内容块，后半部分可以为中央目录和eocd文件块，其中，前半部分的内容块可以作为基于相同母包安装包生成的所有渠道安装包的可复用部分，即为不包含渠道信息的可复用部分。

在具体实现中，针对母包中所包含的可复用部分，即内容块位置的确定，可以通过计算文件偏移量offset实现，所计算的文件偏移量可以指的是最后一个子文件的文件偏移量offset，具体的，可以计算渠道包的meta信息所在渠道包的最后一个子文件在整个包体的文件偏移量offset，并在最后一个子文件的偏移量处按照一个文件块进行对齐处理，即按照文件块大小1mb向上取整，得到渠道包的切分点，即渠道包的切分点可以基于最后一个子文件的文件偏移量与文件块大小确定。

步骤604，将渠道信息存储至本地，丢弃不包含渠道信息的可复用信息。

在按照所述切分点对所述渠道包切分为两部分之后，可以对切分后的渠道安装包进行差分存储至s3，具体可以将meta信息部分存储至s3，丢弃文件的可复用部分，完成对切分后的渠道安装包的分布流程。

在实际应用中，渠道包其实是一个逻辑上的安装包，只有重新组装出来才有意义，在一种优选的实施例中，cdn源站可以将该渠道包的渠道信息、对应的母包名称、切分点、md5、打包方式等信息存储入数据库，便于后续外部节点的回源访问时，对渠道包的重组。

参照图7，示出了本发明实施例中对渠道安装包进行发布的流程示意图，具体的，apk发布者可以使用通用的发布平台正常发布母包到cdn厂商，发布者通过发布平台正常发布一个json文件，cdn可以根据约定好的格式解析json文件，按照用户在json中指定的字段，将母包打包成相应格式的渠道安装包，然后可以计算得到渠道包的meta信息在渠道安装包的切分点，将渠道安装包切分为两部分，将meta信息部分存储至s3，完成对渠道安装包的发布。

作为一种示例，假设某个安卓游戏apk(即母包安装包)的平均安装包大小为1gb，当同一版本的安装包需要在某直播平台的多个主播展示首页上时，即可能需要对应存在有1024个渠道包，若按照现有技术中将注入渠道信息后所生成的多个渠道安装包分别进行存储时，s3所需要的存储空间为1tb，而在对所生成的多个渠道安装包进行差分存储时，只需要在存储母包安装包的基础上另外存储各个渠道安装包的meta信息，所要存储的meta信息可以基于json格式文件所生成的渠道包里获取，假设每个渠道安装包的meta信息的大小为1.5mb，每个json文件的大小为50kb，那么进行差分存储时s3总共所需的存储空间约为1gb+1.5mb*1024+50kb*1024＝2.505gb，可以节约99.75％的存储空间。

在时延方面，假设按照以上数据继续进行估算，当大小为1gb的安装包从用户侧(例如游戏发布者或接入者)由游戏发布平台通过公网服务发布到外部的各个cdn厂商，假设在网络状况良好的情况下最大传输速率为40mb/s，若按照现有技术中将注入渠道信息后所生成的多个渠道安装包分别进行分布的方式，总共所发布的安装包大小约为1tb，传输1tb的数据包耗时约为1024*1024(mb)/40(mb/s)＝7.28h，即大概需要7个多小时，而对所生成的多个渠道安装包进行差分存储进而差分分布时，所需要耗时约为2.505*1024(mb)/40(mb/s)＝64.128s，即仅需要1分钟的时延即可完成多个渠道安装包的发布，而且对于cdn厂商来说，边缘节点的存储成本、回源带宽成本也会有大幅的降低，由于渠道安装包的分片在cdn边缘节点的复用，可以极大提升用户在首次下载的体验。

在本发明实施例中，提出对多渠道安装包进行差分处理的技术构思，可以将这些渠道包在cdn的发布、分发、存储等多个环节进行差分处理，具体表现为将渠道包文件切分成小片，复用不包含渠道信息的文件分片，使得能够对整个发布、存储、节点缓存命中率进行指数级的优化提升，有效帮助用户降低存储成本、发布时延，提高用户体验。

参照图8，示出了本发明的又一种渠道安装包的处理方法实施例的步骤流程图，侧重于渠道安装包的下载过程，应用于cdn节点，具体可以包括如下步骤：

步骤801，通过反向代理服务进程对下载请求的url进行分片替换；

在本发明实施例中，对渠道安装包的分布过程主要可以表现为cdn节点对渠道包文件的切分替换操作。其中，cdn节点可以包括nginx反向代理服务进程和ats缓存服务进程，nginx反向代理服务进程主要可以用于处理各种用户的http请求，ats缓存服务进程可以主要负责文件的多级缓存。

在本发明的一种实施例中，对于cdn场景下渠道安装包的下载过程，主要可以通过内容分发节点响应客户端所发送的下载请求实现。内容分发源站在对渠道安装包进行发布时对渠道安装包进行切分发布或切分存储，内容分发节点在响应针对第二渠道安装包的下载请求的过程中，同样可以基于切分下载的方式实现，以在减少文件的回源概率的同时，降低下载渠道安装包时的带宽资源与时间资源的成本。

其中，基于切分下载的方式可以表现为对用户请求中url的分片替换。

具体的，对于cdn厂商来说，可以通过在cdn源站自定义的一些http的头部来实现某些扩展功能，例如指定切分点http头(x-split-point)，与母包名关联信息http头(x-parent-file)等，同时在cdn节点即可感知并存储渠道包的一些关键信息。

当用户向cdn节点发起对某个渠道包的下载请求时，cdn节点会利用httprange请求将用户请求中的url进行分片替换，以此避免母包中可复用部分的回源下载，保证在实际上需要回源的仅为meta信息部分，即渠道信息。

具体的，反向代理服务进程可以具有缓存列表，当cdn边缘节点在接收到客户端发送的针对第二渠道安装包的下载请求之后，可以通过反向代理服务进程查询缓存列表中是否存在针对第二渠道安装包的url信息，在一种情况下，若缓存列表中存在针对第二渠道安装包的url信息，则判断下载请求是否为分片下载请求；若下载请求为分片下载请求，可以则根据分片下载请求对下载请求的url进行分片替换。

在另一种情况下，若缓存列表中不存在针对第二渠道安装包的url信息，则可以生成并向缓存服务进程发送针对第二渠道安装包的头部响应信息的头部请求；若缓存服务进程具有针对第二渠道安装包的url信息的缓存，则通过缓存服务进程响应所述头部请求，向反向代理服务进程发送第二渠道安装包的头部响应信息；第二渠道安装包的头部响应信息可以包括第二渠道安装包的url信息，若缓存服务进程不具有针对第二渠道安装包的url信息的缓存，则通过反向代理服务进程向上一内容分发节点发送针对第二渠道安装包的头部响应信息的头部请求，直至反向代理服务进程接收到第二渠道安装包的头部响应信息为止。

在这种情况下，边缘节点的反向代理服务进程的上一内容分发节点可以包括中间节点，那么此时边缘节点的反向代理服务进程可以向中间节点的ats缓存发送针对第二渠道安装包的头部响应信息的头部请求，若中间节点的ats缓存，则中间节点的反向代理服务进程可以向其上一内容分发节点请求针对第二渠道安装包的头部响应信息，而中间节点的上一内容分发节点，即相对于边缘节点的上上一内容分发节点可以包括源站，即此时可以通过源站对应的ats缓存将相关url信息返回。

其中，所发送的针对第二渠道安装包的头部响应信息的头部请求，可以指的是基于http协议的head请求，head请求可以用于请求http头包含的元消息，其主要作用是能够基于响应中的信息(例如content-length等)来更新之前缓存的实体，在本发明实施例中，head请求所请求的响应消息可以为第二渠道安装包的url信息，而基于响应信息更新的缓存实体可以指的是用户原先的http下载请求。

在实际应用中，cdn边缘节点在接收到用户的http下载请求后，查询本地内存缓存(即缓存列表)中是否包含该url的三个主要信息：切分点split-point，母包文件parent-file，文件长度content-length；如果nginx内存缓存中不存在以上信息，则向上游ats发起httphead请求，如果上游ats的缓存中存在该文件，则响应文件信息，否则ats继续向上级cdn节点发起httphead请求，直到得到响应(最终请求可能穿回源站)，nginx从上游ats的响应头中提取url的切分点、母包、文件长度信息后，并将其更新写入到nginx的内存缓存中，以便于后续的对该url的http请求查询。

在提取到url的相关信息后，可以根据分片下载请求对下载请求的url进行分片替换。

具体的，参照图9，示出了本发明实施例中对渠道安装包进行切片下载的流程示意图，针对第二渠道安装包的url信息可以包括切分点，此时可以根据切分点，向上游ats缓存服务器发起http请求，如果客户端http请求为分片下载请求，即range请求。分片下载请求可以具有请求范围，该请求范围由请求起始点和请求结束点确定，作为一种示例，可以假设range范围的请求起始点为“range_start”，range范围的结束点为“range_end”。

当在基于range请求对http请求的url进行替换时，可以表现为对分片下载请求的请求范围与切分点位置的比较。

在第一种情况下，若分片下载请求的请求起始点的位置处于切分点之后，即range_start>split_point(文件切分点)，此时nginx可以直接向上游ats发起同样的httprange请求，以向上游ats请求渠道安装包的渠道信息，即此时可以保持针对第二渠道安装包的下载请求的url，并不对url进行替换。

在第二种情况下，若分片下载请求的请求结束点的位置处于切分点之前，即range_end<split_point(文件切分点)，此时nginx可以将url替换为母包的url后，向上游ats发起对该母包url的range请求，即将下载请求的url替换为母包安装包的url，其中，上游ats可以作为nginx后端的上游服务，且ats负责对母包的存储，当nginx需要替换时，向上游ats所发起的range请求用于请求ats向磁盘查找所需替换的母包。

在第三种情况下，若切分点的位置处于分片下载请求的请求起始点和请求结束点之间，即range_start<split_point<range_end，则可以将分片下载请求的请求起始点与切分点的url替换为母包安装包的url，以及保持切分点与分片下载请求的请求结束点的针对第二渠道安装包的下载请求的url，具体的，nginx可以分别向上游ats发起两个httprange请求，第一个为range范围为range_start～(split_point-1)的对母包url的http请求,第二个位range范围为split_point～range_end的对原url(即请求下载第二渠道安装包)的http请求。

以上三种情况都是客户端请求为httprange请求的情况下，对分片下载请求的请求范围与切分点位置的比较，那么当客户端请求为非httprange请求时，可以出现第四种情况，其可以类似上述第三种情况，nginx可以分别向上游ats发起两个http请求，第一个range请求为0～(split_point-1)的对母包url的http请求,第二个位range范围为split_point～content_length的对原url的http请求，并将给客户端的http响应状态码由206替换为200。其中，内容分发节点向客户端返回的206的响应状态码表示内容分发节点可以正常响应httprange请求，若响应状态码为200，则表示内容分发节点不能处理range请求，此时在返回200的状态码的同时还可以向客户端返回整个资源文件。

步骤802，通过缓存服务进程响应分片替换后的url得到第二渠道信息和可复用信息；

在基于range请求对http请求的url进行替换后，在基于对渠道安装包的分片下载请求以及url切分替换的过程中，其实际响应得到的渠道信息和可复用信息进行重组拼接的渠道安装包，nginx可以进行http响应头的替换，即如果向上游ats发起的是range请求，则需要将content-range、content-length替换为实际的内容，以便将响应头信息伪造成实际请求的第二渠道安装包的实际url范围和实际长度，完成对重组拼接的渠道安装包的响应。

具体的，可以通过反向代理服务进程接收缓存服务进程基于分片替换后的url的响应消息，然后通过反向代理服务进程获取下载请求的url的响应头消息，将基于分片替换后的url的响应消息中的响应头消息替换为下载请求的url的响应头消息，最终将完整的http响应返回给用户。

步骤803，对第二渠道信息和可复用信息进行重组，得到目标渠道安装包。

渠道安装包为逻辑上的安装包，只有重新组装出来才有意义，那么所得到的目标渠道安装包可以是对母包的可复用部分与回源的meta信息部分进行重组得到的，即基于第二渠道信息和可复用信息重组得到的。针对目标渠道安装包的重组时机，可以是在边缘节点(即某个cdn节点)进行重组，也可以在内容分发源站进行重组，对此，本发明实施例不加以限制。

在本发明实施例中，对cdn节点所进行的改造，针对同一母包对应的所有渠道包复用相同的文件块，在本地只存储不同渠道包的差分文件块，节省多渠道安装包发布时的存储资源成本，并且在减少文件的回源概率的同时，使得能够在对多渠道安装包发布与下载时降低带宽资源与时间资源的成本。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

参照图10，示出了本发明的一种渠道安装包的处理装置实施例的结构框图，应用于内容分发网络，所述内容分发网络包括内容分发源站和内容分发节点，具体可以包括如下模块：

渠道安装包切分模块1001，位于所述内容分发源站，用于获取所需发布的第一渠道安装包，对所述第一渠道安装包进行切分，得到第一渠道信息和不包含所述第一渠道信息的可复用信息；

渠道安装包分发模块1002，位于所述内容分发源站，用于向所述内容分发节点分发所述不包含所述第一渠道信息的可复用信息和第一渠道信息；

渠道安装包下载模块1003，位于所述内容分发节点，用于响应针对第二渠道安装包的下载请求，获取所述第二渠道安装包的第二渠道信息和所述不包含第一渠道信息的可复用信息，并根据所述第二渠道信息和所述不包含第一渠道信息的可复用信息得到目标渠道安装包。

在本发明的一种实施例中，渠道安装包切分模块1001可以包括如下子模块：

渠道安装包切分子模块，用于确定所述可复用信息在所述第一渠道安装包的切分位置，根据所述切分位置切分所述第一渠道安装包。

在本发明的一种实施例中，切分位置确定子模块可以包括如下单元：

文件偏移量计算单元，用于计算所述第一渠道信息所在的第一渠道安装包的文件偏移量；

切分点计算单元，用于采用所述文件偏移量计算得到针对所述第一渠道安装包的切分点；

渠道安装包切分单元，用于按照所述切换点对所述第一渠道安装包进行切分。

在本发明的一种实施例中，在通过所述内容分发源站获取所需发布的第一渠道安装包之前，所述装置还可以包括如下模块：

母包安装包获取模块，位于所述内容分发源站，用于获取所需发布的母包安装包和多个渠道信息；所述多个渠道信息包括第一渠道信息和第二渠道信息；

渠道安装包生成模块，用于将所述第一渠道信息和第二渠道信息分别注入到所述母包安装包的末尾，得到用于发布至不同渠道的第一渠道安装包和第二渠道安装包。

在本发明的一种实施例中，所述内容分发节点包括反向代理服务进程和缓存服务进程；渠道安装包下载模块1003可以包括如下子模块：

url分片替换子模块，用于通过所述反向代理服务进程对所述下载请求的url进行分片替换；

渠道信息获取模块，用于通过所述缓存服务进程响应分片替换后的url得到第二渠道信息和可复用信息。

在本发明的一种实施例中，渠道安装包下载模块1003还可以包括如下子模块：

响应消息接收子模块，用于通过所述反向代理服务进程接收所述缓存服务进程基于分片替换后的url的响应消息；

响应消息替换子模块，用于通过所述反向代理服务进程获取所述下载请求的url的响应头消息，将所述基于分片替换后的url的响应消息中的响应头消息替换为所述下载请求的url的响应头消息。

在本发明的一种实施例中，所述反向代理服务进程具有缓存列表；分片替换子模块可以包括如下单元：

url信息查询单元，用于通过所述反向代理服务进程查询所述缓存列表中是否存在针对所述第二渠道安装包的url信息；

下载请求判断单元，用于若所述缓存列表中存在针对所述第二渠道安装包的url信息，则判断所述下载请求是否为分片下载请求；

url分片替换单元，用于若所述下载请求为分片下载请求，则根据所述分片下载请求对所述下载请求的url进行分片替换。

在本发明的一种实施例中，所述针对所述第二渠道安装包的url信息包括切分点；所述分片下载请求包括请求起始点和请求结束点；url分片替换单元可以包括如下子单元：

第一url分片替换子单元，用于若所述分片下载请求的请求起始点的位置处于所述切分点之后，则保持针对所述第二渠道安装包的下载请求的url；

第二url分片替换子单元，用于若所述分片下载请求的请求结束点的位置处于所述切分点之前，则将所述下载请求的url替换为母包安装包的url；

第三url分片替换子单元，用于若所述切分点的位置处于所述分片下载请求的请求起始点和请求结束点之间，则将所述分片下载请求的请求起始点与所述切分点的url替换为母包安装包的url，以及保持所述切分点与所述分片下载请求的请求结束点的针对所述第二渠道安装包的下载请求的url。

在本发明的一种实施例中，分片替换子模块还可以包括如下单元：

第一头部请求发送单元，用于若所述缓存列表中不存在针对所述第二渠道安装包的url信息，则生成并向缓存服务进程发送针对第二渠道安装包的头部响应信息的头部请求；

头部响应信息发送单元，用于若所述缓存服务进程具有针对所述第二渠道安装包的url信息的缓存，则通过所述缓存服务进程响应所述头部请求，向所述反向代理服务进程发送所述第二渠道安装包的头部响应信息；其中，所述第二渠道安装包的头部响应信息包括所述第二渠道安装包的url信息；

第二头部请求发送单元，用于若所述缓存服务进程不具有针对所述第二渠道安装包的url信息的缓存，则通过所述反向代理服务进程向上一内容分发节点发送所述针对第二渠道安装包的头部响应信息的头部请求，直至所述反向代理服务进程接收到所述第二渠道安装包的头部响应信息为止。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本发明实施例还提供了一种电子设备，包括：

包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述渠道安装包的处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现上述渠道安装包的处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

参照图11，示出了本发明实施例的一种计算机可读存储介质的结构框图，该计算机可读存储介质1101上可以存储计算机程序，其中，计算机程序可以被处理器执行时实现上述渠道安装包的处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种渠道安装包的处理方法和一种渠道安装包的处理装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。