CN115801769B - 渠道包获取方法、电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种渠道包获取方法、电子设备及存储介质，涉及数据传输技术领域。所述方法包括：对渠道包的回源请求针对的渠道包的每个分片，确定分片是否与渠道包格式中预留的区域有重叠区间；若有重叠区间，则从对象存储服务下载分片，在分片内的重叠区间中写入对应渠道信息的内容后发送给内容分发网络；若无重叠区间，则通知内容分发网络重定向至对象存储服务下载分片；渠道包格式中预留的区域用于保存渠道信息，重定向下载的分片与写入渠道信息的内容的分片用于组成渠道包。依据本申请实施例，无需耗费大量的计算资源预先离线生成渠道包以及大量的存储资源存储渠道包，极大地节省了渠道包的下载成本。

Description

渠道包获取方法、电子设备及存储介质

技术领域

本申请涉及数据传输技术领域，尤其涉及一种渠道包获取方法、电子设备及存储介质。

背景技术

目前，渠道包普遍采用离线的文件操作方式生成。首先对源包进行解压，然后添加渠道信息并重新压缩，进而得到渠道包，在收到用户下载请求后再下发渠道包。这种方式需要耗费大量的计算资源进行文件操作，同时也需要大量的存储资源用来存储渠道包。在渠道数量级别较大的场景下，成本将不可承受。

发明内容

本申请实施例提供一种渠道包获取方法、电子设备及存储介质，以节省成本。

在第一方面，本申请实施例提供了一种渠道包获取方法，包括：

对渠道包的回源请求针对的所述渠道包的每个分片，确定所述分片是否与渠道包格式中预留的区域有重叠区间；若确定所述分片与所述区域有重叠区间，则从对象存储服务下载所述分片，在所述分片内的所述重叠区间中写入对应渠道信息的内容后发送给内容分发网络；若确定所述分片与所述区域无重叠区间，则通知所述内容分发网络重定向至所述对象存储服务下载所述分片；其中，所述渠道包格式中预留的区域用于保存渠道信息，所述重定向下载的分片与写入渠道信息的内容的分片用于组成所述渠道包。

在第二方面，本申请实施例提供了一种渠道包获取方法，包括：

向函数计算发送渠道包的回源请求，所述回源请求用于请求所述渠道包的每个分片；在所述函数计算确定有分片与渠道包格式中预留的区域有重叠空间的情况下，接收所述函数计算返回的写入渠道信息的内容的分片，所述渠道信息的内容为所述函数计算从对象存储服务下载分片后写入的；在所述函数计算确定有分片与渠道包格式中预留的区域无重叠空间的情况下，接收所述函数计算返回的重定向通知，根据所述重定向通知从所述对象存储服务下载分片；其中，所述渠道包格式中预留的区域用于保存渠道信息，根据所述重定向通知下载的分片与写入渠道信息的内容的分片用于组成所述渠道包。

在第三方面，本申请实施例提供了一种渠道包获取方法，包括：

在函数计算根据渠道包的回源请求确定所述渠道包的所有分片中有分片与渠道包格式中预留的区域有重叠空间的情况下，接收所述函数计算的分片请求，下发所述分片请求对应的分片给所述函数计算，以使所述函数计算在所述分片内的重叠区间中写入对应渠道信息的内容后发送给内容分发网络；在所述函数计算确定所述所有分片中有分片与渠道包格式中预留的区域无重叠空间且发送重定向通知给所述内容分发网络的情况下，接收所述内容分发网络的分片请求，下发所述分片请求对应的分片给所述内容分发网络；其中，所述渠道包格式中预留的区域用于保存渠道信息，根据所述重定向通知下发的分片与写入渠道信息的内容的分片用于组成所述渠道包。

在第四方面，本申请实施例提供了一种渠道包获取方法，包括：

向内容分发网络发送渠道包的获取请求，以请求所述渠道包的每个分片；在所述内容分发网络根据所述渠道包的回源请求从函数计算获得写入渠道信息的内容的分片的情况下，接收所述内容分发网络返回的写入渠道信息的内容的分片；在所述内容分发网络根据所述函数计算的重定向通知从对象存储服务下载分片的情况下，接收所述内容分发网络返回的重定向下载得到的分片；基于所述重定向下载的分片与写入渠道信息的内容的分片组成所述渠道包。

在第五方面，本申请实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，所述处理器在执行所述计算机程序时实现上述任一项所述的方法。

在第六方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法。

与现有技术相比，本申请具有如下优点：

根据渠道包的回源请求，在确定渠道包的所有分片中有分片与渠道包格式中预留的区域有重叠区间的情况下，从对象存储服务下载该分片，并在该分片内的重叠区间中写入对应渠道信息的内容，实现了渠道包实时下载过程中仅涉及渠道信息的分片为其写入渠道信息的内容。由于无需耗费大量的计算资源预先离线生成渠道包，也无需耗费大量的存储资源存储渠道包，因此，极大地节省了渠道包的下载成本，降低了渠道数量增加对资源消耗的影响，避免了资源浪费，可以适用于任意数量级别的渠道，容易实现，通用性高。

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

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请的一些实施方式，而不应将其视为是对本申请范围的限制。

图1为本申请提供的渠道包获取方法的应用场景示意图；

图2为本申请一实施例的渠道包获取方法的流程图；

图3是本申请另一实施例的V1签名方式的源包格式示意图；

图4是本申请另一实施例的V1签名方式的初始渠道包格式示意图；

图5是本申请另一实施例的V1签名方式的填充后的渠道包格式示意图；

图6是本申请另一实施例的V2签名方式的源包格式示意图；

图7是本申请另一实施例的V2签名方式的初始渠道包格式示意图；

图8是本申请另一实施例的V2签名方式的填充后的渠道包格式示意图；

图9是本申请另一实施例的渠道包获取方法的流程图；

图10是本申请另一实施例的渠道包获取方法的流程图；

图11是本申请另一实施例的V1签名方式的下载场景示意图；

图12是本申请另一实施例的V2签名方式的下载场景示意图；

图13是本申请另一实施例的CDN与FC及OSS的交互示意图；

图14为用来实现本申请实施例的电子设备的框图。

具体实施方式

在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的构思或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的，而非限制性的。

为便于理解本申请实施例的技术方案，以下对本申请实施例的相关技术进行说明。以下相关技术作为可选方案与本申请实施例的技术方案可以进行任意结合，其均属于本申请实施例的保护范围。

首先对本申请所涉及的名词进行解释。

CP（Content Provider，内容提供商）：是指提供服务内容的供应商，内容可以是文字、图像、音频和视频等各种媒体内容。

渠道：是指为用户提供应用程序下载和更新的服务。

源包：CP提供的应用程序包，如游戏的APK（Android application package，安卓应用程序包）。

渠道包：在源包中写入渠道信息后得到的包即称为渠道包。

V1签名：JAR（Java Archive，java归档）签名，通过在APK文件中添加META-INF目录来记录签名信息，需要修改数据区、中央目录和中央目录结尾记录。

V2签名：Android的一种签名方式，通过在数据区和中央目录之间插入一个APK签名分块来记录签名信息，能够保证原始APK数据的完整性。

V3签名：Android的一种签名方式，采用V2相同的签名分块格式，与V2签名的区别在于APK签名分块的大小必须是4096的倍数，以及增添了有关受支持的SDK（SoftwareDevelopment Kit，软件开发工具包）版本和prof-of-rotation结构的信息。

CDN（Content Delivery Network，内容分发网络）：通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决互联网拥挤的状况，提高用户访问网站的响应速度，使内容传输得更快、更稳定。

302：302 Found是HTTP（Hyper Text Transfer Protocol，超文本传输协议）中的一个状态码，表示请求的资源暂时驻留在不同的URL（Uniform Resource Locator，统一资源定位）下，因此可以通过发送新的URL来重定向到相应位置以进行资源下载，从而加快用户获取资源的速度。

FC（Function Compute，函数计算）：是一个事件驱动的全托管计算服务，提供计算资源，以弹性、可靠的方式运行代码，完成计算功能。

OSS（Object Storage Service，对象存储服务）：具有多种存储类型的云存储服务，适用于数据湖存储，数据迁移，企业数据管理和数据处理等多种场景，可对接多种计算分析平台，直接进行数据处理与分析。

图1为示例性的用于实现本申请实施例的渠道包获取方法的一个应用场景的示意图。客户端可以通过CDN发起请求来下载渠道包。OSS上存储有源包，也可以称为初始渠道包，即预留有用于保存渠道信息的区域的渠道包，该区域可以填充指定的初始值，适用于任何渠道。FC具有分析判断以及在源包中写入渠道信息的能力，根据CDN发来的请求可以确定当前请求的分片是否需要写入渠道信息。对于需要写入渠道信息的场景，FC从OSS下载分片后写入渠道信息再发送给CDN，对于无需写入渠道信息的场景，FC返回重定向地址给CDN，由CDN重定向到OSS下载分片。最后，无论哪种场景，CDN均将得到的分片返回给客户端，从而完成客户端渠道包的下载。其中，客户端的类型可以有多种，如计算机、手机、平板电脑或笔记本电脑等等。FC和OSS可以根据需要部署，均可以部署为一个或多个。图中仅以部署一个FC和一个OSS为例进行示意。上述方法可以应用于任何行业的安卓应用程序包分发场景，包括但不限于游戏分发平台等。

本申请实施例提供了一种渠道包获取方法，可以应用于FC上。如图2所示为本申请一实施例的渠道包获取方法流程图，该方法可以包括如下步骤S201至步骤S203。

在步骤S201，对渠道包的回源请求针对的渠道包的每个分片，确定该分片是否与渠道包格式中预留的区域有重叠区间。

本实施例中，渠道包的回源请求是指CDN根据客户端的渠道包下载请求发来的回源请求，用于CDN向FC请求渠道包的各个分片。在客户端下载渠道包的过程中，回源请求可以有多次，每次请求当前需要下载的分片，在完成所有分片的下载后，客户端能够得到完整的渠道包。

本实施例中，渠道包可以有多种存储格式，包括但不限于ZIP格式等。渠道包内的数据组成由其存储格式决定，本实施例仅涉及渠道信息，只要在渠道包格式内预留用于存储渠道信息的区域即可，其余组成部分保持不变。

本实施例中的重叠区间包括部分重叠或完全重叠的场景。部分重叠是指当前请求的分片与上述区域至少有一个最小存储单位是重叠的，如至少一个字节重叠等。完全重叠是指当前请求的分片全部落入上述区域内，或者上述区域完全落入当前请求的分片内。

在步骤S202，若确定该分片与上述区域有重叠区间，则从对象存储服务下载该分片，在该分片内的重叠区间中写入对应渠道信息的内容后发送给内容分发网络。

本实施例中，渠道信息是指能够表征渠道的属性的信息。不同的渠道可以具有不同的渠道信息，通过渠道信息可以识别出对应渠道的属性。CP提供的应用程序可以通过多个不同的渠道来推广，每一个渠道都有自己的渠道信息。本实施例中的渠道信息泛指与任一渠道对应的渠道信息。示例性地，可以预先设置渠道与渠道信息的对应关系，并存储该对应关系，以便后续直接通过查找该对应关系来获取需要的渠道信息。示例性地，可以预先生成渠道ID与渠道信息的对照表并存储该对照表，以便随时查找需要的渠道信息。

在步骤S203，若确定该分片与上述区域无重叠区间，则通知内容分发网络重定向至对象存储服务下载该分片。

本实施例中，重定向下载的分片与写入渠道信息的内容的分片用于组成上述渠道包。

本实施例中，OSS存储的渠道包中预留有用于保存渠道信息的区域，该区域的位置可以根据渠道包的签名方式来确定，对于不同的签名方式则位于不同的分块中。

本实施例中，确定当前请求的分片与上述区域有重叠区间的场景，表明当前请求的分片是需要写入渠道信息的，进而在下载分片后执行写入渠道信息的操作。与之相反，确定当前请求的分片与上述区域无重叠区间的场景，表明当前请求的分片无需写入渠道信息，因此无需执行写入渠道信息的操作。

本实施例中，在分片内的重叠区间中写入对应渠道信息的内容，是与重叠区间的长度有关的。重叠区间对应的内容可以是渠道信息的完整内容，或者也可以是部分内容，由重叠区间的位置决定。示例性地，渠道信息的完整内容占用8个字节，如果重叠区间为前4个字节，则对应写入前4个字节的内容，此时写入的就是部分渠道信息（即前半部分）。在下一次请求中，下载的分片重叠区间为后4个字节，则对应写入后4个字节的内容，此时写入的也是部分渠道信息（即后半部分）。经过两次分片下载后，才完成渠道信息所有内容的下载。

本实施例提供的上述方法，在确定渠道包的所有分片中有分片与渠道包格式中预留的区域有重叠区间的情况下，从对象存储服务下载分片并在重叠区间中写入对应渠道信息的内容，实现了渠道包实时下载过程中仅涉及渠道信息的分片为其写入渠道信息的内容。由于无需耗费大量的计算资源预先离线生成渠道包，也无需耗费大量的存储资源存储渠道包，因此，极大地节省了渠道包的下载成本，降低了渠道数量增加对资源消耗的影响，避免了资源浪费，可以适用于任意数量级别的渠道，容易实现，通用性高。

本申请实施例中渠道包的签名方式包括但不限于V1、V2或V3签名方式等。本申请实施例中的渠道包可以为包含渠道信息的安卓应用程序包APK，对应的应用程序不限定，如可以为游戏应用或其他应用等。

本申请实施例中，若渠道包的签名方式为V1签名方式，则渠道包中预留的用于保存渠道信息的区域可以位于中央目录结尾块中。在一种实施方式下，中央目录结尾块中的注释长度的值为上述区域的长度，中央目录结尾块中的注释内容的值为渠道信息。

本申请实施例中，若渠道包的签名方式为V2或V3签名方式，则渠道包中预留的用于保存渠道信息的区域可以位于应用程序包签名块中。在一种实施方式下，该区域可以位于应用程序包签名块中的填充魔数键值对之后，且为键值对格式，包括渠道信息键值对长度、渠道标识魔数ID和值。

本申请实施例中，不需要提前离线生成N个渠道包，只需要预先生成一个新的填充了4096个字节的初始渠道包，就可以开放给所有渠道的用户进行下载。用户在下载渠道包时，仅在请求的分片与渠道信息的区域有重叠区间的场景下，由FC下载初始渠道包后写入渠道信息得到渠道包，大概占比不到1%。其余的场景均无重叠区间，可以直接由CDN回源到OSS下载初始渠道包即可，大概占比99%。这种低比例的在线字节流的操作方式，与离线的文件操作方式相比，更加实时和高效。而且，由生成N个渠道包变成生成一个填充了4096字节的初始渠道包，大幅降低计算成本和存储成本，由N数量级降为1，极大地节省了资源。

本申请实施例中，无论是V1签名还是V2或V3签名，FC基于回源请求只需针对一次，最多两次分片下载请求，就可以完成渠道信息的实时在线写入，大幅节省成本，降低了实现的复杂度，方案简单，通用性高。

下面结合附图分别对上述各种签名方式下的渠道包格式进行说明。

图3是本申请另一实施例的V1签名方式的源包格式示意图。参见图3，OSS存储的源包包括三个部分：ZIP条目的内容（Content of ZIP entries）、ZIP中央目录（CentryDirectory）和ZIP中央目录结尾（End of Centry Directory）。其中，ZIP中央目录结尾包括：魔数值、当前磁盘编号、CD（Centry Directory，中央目录）开始位置的磁盘编号、磁盘上所记录的CD数量、CD目录结构总数、CD的大小、CD开始位置和注释长度。源包总大小7432883字节，其中7432882-7432883两个字节标识的注释长度值为0，即注释内容为空。

图4是本申请另一实施例的V1签名方式的初始渠道包格式示意图。参见图4，在OSS上预先生成初始渠道包，其中预留有用于保存渠道信息的区域。具体的，可以将注释内容作为预留的区域以用于保存渠道信息。注释长度的具体数值可以根据需要设置，本实施例不限定。为了方便与V2和V3签名方式统一，可以将注释长度设置为4096的整数倍，从而方便各种签名方式下渠道信息的写入，进而提升兼容性。图中以注释长度为4096个字节为例示意，其中7432882-7432883两个字节标识的注释长度值为4096。7432884-7436979包含的4096个字节全部用空值填充。也就是说，注释内容可以在初始时填充为零，仅标识该位置为渠道信息，但具体的渠道信息内容则无需离线写入，待下载过程中实时写入即可。

图5是本申请另一实施例的V1签名方式的填充后的渠道包格式示意图。参见图5，在FC实时从OSS下载当前分片后，可以将需要写入的渠道信息填充至注释内容中。如图所示，注释长度为4096个字节。注释内容写入长度为53个字节的渠道信息，后面4043个节点补零以完成所有注释内容的填充，保证字节对齐。此时，写入渠道信息后的源包就可以称为渠道包，其中包含了与对应渠道相关的渠道信息。图中渠道信息的长度为53个字节仅为示例，在实际应用中也可以为其他长度，具体不限定。

图6是本申请另一实施例的V2签名方式的源包格式示意图。参见图6，OSS存储的源包总大小为7439986个字节，包括四个部分：ZIP条目的内容、APK签名块（APK SigningBlock）、ZIP中央目录和ZIP中央目录结尾。其中，APK签名块包括：ASB块长度、ID-Value键值对和魔数，其中7393280-7393287和7397352-7397359的两个8字节标识APK 签名块的长度（4088字节）。7393288-7397351总共4064个字节的ID-Value键值对包括：V2签名魔数键值对和填充魔数键值对。ZIP中央目录结尾包括：魔数值、当前磁盘编号、CD开始位置的磁盘编号、磁盘上所记录的CD数量、CD目录结构总数、CD的大小、CD开始位置和注释长度。图中示意注释长度为0，即注释内容为空。

图7是本申请另一实施例的V2签名方式的初始渠道包格式示意图。参见图7，在OSS上预先生成初始渠道包，其中预留有用于保存渠道信息的区域。具体的，可以在APK签名块的ID-Value键值对中预留区域以用于保存渠道信息。预留区域的长度可以根据需要设置，如4096的整数倍，本实施例对此不做具体限定。图中以预留4096个字节的区域为例进行示意，该区域具体位于填充魔数键值对之后，仍然采用键值对格式以保证字节对齐。如图所示，渠道信息所属的键值对总长度为4096个字节。APK签名块的两个标识长度的大小由原来的4096变为8184，CD开始位置由7397376变为7401472，ID-Value键值对中新增加了4096个字节的数据，包括8个字节的value长度、4个字节的自定义填充参数即渠道信息的标识以及4084个字节的value。其中，渠道信息的标识可以填充为指定的初始值，即如图所示为自定义填充参数0x717777778，用以标识该键值对为渠道信息，具体的value值可以设置为空值，即渠道信息内容无需离线写入，待下载过程中实时写入即可。

图8是本申请另一实施例的V2签名方式的填充后的渠道包格式示意图。参见图8，在FC实时从OSS下载当前分片后，可以将需要写入的渠道信息填充至键值对中。如图所示，渠道信息键值对长度为4096个字节。其中，7397352-7397410之间的59个字节的键值对包括8个字节的value长度（值为51）、4个字节的渠道标识魔数ID（值为0x71777777）以及47个字节的value，该value的值用于写入渠道信息。7397411-7401447之间的4037个字节的键值对可以用于写入渠道填充数（如填充的值为0x717777778）。图中渠道信息键值对的长度为4096个字节仅为示例，在实际应用中也可以为4096的整数倍，具体不限定。

本申请另一实施例提供了一种渠道包获取方法，可以应用于FC上。如图9所示为本申请另一实施例的渠道包获取方法流程图，该方法可以包括如下步骤S901至步骤S905。

在步骤S901，根据渠道包的回源请求，将渠道包的每个分片分别作为当前请求的分片，确定当前请求的分片是否与渠道包格式中预留的区域有重叠区间。

在步骤S902，符合指定条件中的任一条件则确定当前请求的分片与上述区域有重叠区间。

本实施例中，上述指定条件包括：

当前请求的分片的起始位置位于区域的起始位置之前，且当前请求的分片的结束位置位于区域之间；或，

当前请求的分片的起始位置和结束位置均位于区域之间；或，

当前请求的分片的起始位置位于区域之间，且当前请求的分片的结束位置位于区域的结束位置之后；或，

当前请求的分片的起始位置位于区域的起始位置之前，且当前请求的分片的结束位置位于区域的结束位置之后。

在步骤S903，在确定当前请求的分片与上述区域有重叠区间的情况下，从对象存储服务下载该分片。

其中，对象存储服务存储的渠道包中预留有用于保存渠道信息的区域。

在步骤S904，根据回源请求针对的渠道确定相应的渠道信息。

在步骤S905，将渠道信息中存储位置与重叠区间对应的内容，写入该分片内的重叠区间中。

本实施例中，渠道信息中内容的存储位置是指字节的位置，渠道信息所有内容占用的总字节数就是渠道信息的长度。例如，渠道信息的长度为16个字节，其中第1个字节至第16个字节就是对应内容的存储位置。

上述与重叠区间对应的内容可以是渠道信息的完整内容，或者也可以是部分内容，由重叠区间的位置决定。例如，长度为16个字节的渠道信息，当前请求中，如果重叠区间为前8个字节，则将存储位置为前8个字节的内容写入重叠区间中，此时写入的就是部分渠道信息（即前半部分）。在下一次请求中，如果重叠区间为后8个字节，则将存储位置为后8个字节的内容写入重叠区间中，此时写入的也是部分渠道信息（即后半部分）。经过两次分片下载后，才完成渠道信息所有内容的下载。

本申请另一实施例提供了一种渠道包获取方法，可以应用于FC上。如图10所示为本申请另一实施例的渠道包获取方法流程图，该方法可以包括如下步骤S1001至步骤S1003。

在步骤S1001，对渠道包的回源请求针对的渠道包的每个分片，确定该分片是否与渠道包格式中预留的区域有重叠区间。

在步骤S1002，若该分片的结束位置位于该区域的起始位置之前，或者该分片的起始位置位于该区域的结束位置之后，则确定该分片与该区域无重叠区间。

在步骤S1003，通知内容分发网络重定向至对象存储服务下载该分片。

其中，渠道包格式中预留的区域用于保存渠道信息。

图11是本申请另一实施例的V1签名方式的下载场景示意图。参见图11，渠道信息位于注释内容中。图中包括六种下载场景，根据当前请求的分片的起始位置和结束位置，以及渠道信息在渠道包中所处区域的起始位置和结束位置，进行不同场景的区分。其中涉及基于302状态码的下载过程，也就是重定向到OSS下载初始渠道包的过程。为了描述方便，基于302状态码通过CDN重定向到OSS下载初始渠道包的场景，可以简称为可302下载场景，相反地，FC直接从OSS下载初始渠道包以写入渠道信息的场景，可以简称为不可302下载场景。下面具体说明如下：

下载场景1（可302下载场景）：分片的结束位置<区域的起始位置，此时无重叠区间，CDN可以基于FC的重定向通知直接到OSS下载当前请求的分片即数据A。

下载场景2（不可302下载场景）：分片的起始位置<区域的起始位置，并且区域的起始位置≤分片的结束位置≤区域的结束位置，此时存在重叠区间，CDN不可直接到OSS下载当前请求的分片。FC先从OSS下载分片的起始位置和结束位置之间的数据即初始渠道包A。然后获取区域的起始位置至分片的结束位置之间的数据B即部分渠道信息。将数据A中属于重叠区间的部分替换为数据B即得到写入渠道信息的分片。

下载场景3（不可302下载场景）：区域的起始位置≤分片的起始位置和结束位置≤区域的结束位置，此时存在重叠区间且重叠区间均为渠道信息，CDN不可直接到OSS下载当前请求的分片。这种场景下FC直接获取区域内属于重叠区间的部分即为当前请求的分片B。

下载场景4（不可302下载场景）：区域的起始位置≤分片的起始位置≤区域的结束位置，并且分片的结束位置>区域的结束位置，此时存在重叠区间，CDN不可直接到OSS下载当前请求的分片。FC先从OSS获取分片的起始位置至结束位置之间对的数据A。然后获取分片的起始位置至区域的结束位置之间的数据B即部分渠道信息。将数据A中属于重叠区间的部分替换为数据B即得到写入渠道信息的分片。

下载场景5（可302下载场景）：分片的结束位置＞区域的结束位置，此时无重叠区间，CDN可以基于重定向通知直接到OSS下载当前请求的分片即数据A。

下载场景6（不可302下载场景）：分片的起始位置＜区域的起始位置，并且分片的结束位置＞区域的结束位置，此时存在重叠区间且重叠区间均为渠道信息，CDN不可直接到OSS下载当前请求的分片。FC先从OSS获取分片的起始位置至结束位置之间对的数据A。然后获取区域的起始位置至区域的结束位置之间的数据B即完整渠道信息。将数据A中属于重叠区间的部分替换为数据B即得到写入渠道信息的分片。

图12是本申请另一实施例的V2签名方式的下载场景示意图。参见图12，渠道信息位于APK签名块中。图中包括六种下载场景，根据当前请求的分片的起始位置和结束位置，以及渠道信息在渠道包中所处区域的起始位置和结束位置，进行不同场景的区分。具体说明如下：

下载场景1（可302下载场景）：分片的结束位置<区域的起始位置，此时无重叠区间，CDN可以基于FC的重定向通知直接到OSS下载当前请求的分片即数据A。

下载场景2（不可302下载场景）：分片的起始位置<区域的起始位置，并且区域的起始位置≤分片的结束位置≤区域的结束位置，此时存在重叠区间，CDN不可直接到OSS下载当前请求的分片。FC先从OSS下载分片的起始位置和结束位置之间的数据即初始渠道包的数据A。然后获取区域的起始位置至分片的结束位置之间的数据B即部分渠道信息。将数据A中属于重叠区间的部分替换为数据B即得到写入渠道信息的分片。

下载场景3（不可302下载场景）：区域的起始位置≤分片的起始位置和结束位置≤区域的结束位置，此时存在重叠区间且重叠区间均为渠道信息，CDN不可直接到OSS下载当前请求的分片。这种场景下FC直接获取区域内属于重叠区间的部分即为当前请求的分片B。

下载场景4（不可302下载场景）：区域的起始位置≤分片的起始位置≤区域的结束位置，并且分片的结束位置>区域的结束位置，此时存在重叠区间，CDN不可直接到OSS下载当前请求的分片。FC先从OSS获取分片的起始位置至结束位置之间的数据A。然后获取分片的起始位置至区域的结束位置之间的数据B即部分渠道信息。将数据A中属于重叠区间的部分替换为数据B即得到写入渠道信息的分片。

下载场景5（可302下载场景）：分片的结束位置＞区域的结束位置，此时无重叠区间，CDN可以基于重定向通知直接到OSS下载当前请求的分片即数据A。

下载场景6（不可302下载场景）：分片的起始位置＜区域的起始位置，并且分片的结束位置＞区域的结束位置，此时存在重叠区间且重叠区间均为渠道信息，CDN不可直接到OSS下载当前请求的分片。FC先从OSS获取分片的起始位置至结束位置之间对的数据A。然后获取区域的起始位置至区域的结束位置之间的数据B即完整渠道信息。将数据A中属于重叠区间的部分替换为数据B即得到写入渠道信息的分片。

本申请实施例中，V3签名方式下的各种场景的分片下载流程与上述V2签名方式下的各种场景的分片下载流程相同，此处不再赘述。

图13是本申请另一实施例的CDN与FC及OSS的交互示意图。参见图13，客户端请求下载渠道包的流程具体如下：1、客户端发起请求下载渠道包。2、CDN根据客户端的请求，可以先判断本地缓存的分片中是否包括当前请求的分片。由于下载的操作通常为多次，CDN在多次下载的过程中，已经下载的分片会缓存在本地。因此，若当前命中缓存，则可以直接将本地的缓存返回给客户端，从而极大地提高了下载的效率。若当前未命中缓存，则向FC发送回源请求。3、FC根据回源请求判断当前请求的分片是否与渠道信息的区域存在重叠区间，如果是，则不可302下载，然后执行步骤4和5；如果否，则可302下载返回重定向地址给CDN，然后执行步骤6和7。4、FC向OSS发送下载请求。5、OSS响应该请求返回初始渠道包给FC，FC在初始渠道包中写入渠道信息后返回给CDN。6、CDN根据重定向地址向OSS请求初始渠道包。7、OSS根据该请求返回初始渠道包给CDN。8、CDN将步骤5中FC发来的分片或步骤7中从OSS下载的分片返回给客户端，从而完成当前下载流程。其中，当前请求的分片示例性地可以为512k分片，本实施例对此不做具体限定。

本申请实施例中，除了需要写入渠道信息的分片外，其余分片均可以由CDN 重定向到OSS下载，节省了FC资源和OSS存储资源。FC回源到OSS获取初始渠道包再写入渠道信息后返回给CDN，能够高效生成渠道包且渠道包的数量无限制。实现了最低的成本的渠道包下载，能够为用户提供实时、稳定、高速的渠道包下载解决能力。基于OSS、FC和CDN 基于302状态码重定向的能力，可以使整个渠道包99%以上的内容走CDN回源OSS的链路完成初始渠道包的下载，只有不到1%的内容走CDN回源FC以及FC回源OSS的链路，完成初始渠道包的下载和渠道信息的写入。上述方式，能够用最低的存储成本、最少的计算资源完成CP源包在任意渠道的推广，为高数量级别的渠道推广提供了有力的支持和保障。

本申请另一实施例提供了一种渠道包获取方法，可以应用于CDN上，该方法可以包括：

向FC发送渠道包的回源请求，回源请求用于请求渠道包的每个分片；

在FC确定有分片与渠道包格式中预留的区域有重叠空间的情况下，接收FC返回的写入渠道信息的内容的分片，渠道信息的内容为FC从OSS下载分片后写入的；

在FC确定有分片与渠道包格式中预留的区域无重叠空间的情况下，接收FC返回的重定向通知，根据重定向通知从OSS下载分片；

其中，渠道包格式中预留的区域用于保存渠道信息，根据重定向通知下载的分片与写入渠道信息的内容的分片用于组成渠道包。

本申请另一实施例提供了一种渠道包获取方法，可以应用于OSS上，该方法可以包括：

在FC根据渠道包的回源请求确定渠道包的所有分片中有分片与渠道包格式中预留的区域有重叠空间的情况下，接收FC的分片请求，下发分片请求对应的分片给FC，以使FC在分片内的重叠区间中写入对应渠道信息的内容后发送给CDN；

在FC确定所有分片中有分片与渠道包格式中预留的区域无重叠空间且发送重定向通知给CDN的情况下，接收CDN的分片请求，下发分片请求对应的分片给CDN；

其中，渠道包格式中预留的区域用于保存渠道信息，根据重定向通知下发的分片与写入渠道信息的内容的分片用于组成渠道包。

本申请另一实施例提供了一种渠道包获取方法，可以应用于客户端上，该方法可以包括：

向CDN发送渠道包的获取请求，以请求渠道包的每个分片；

在CDN根据渠道包的回源请求从FC获得写入渠道信息的内容的分片的情况下，接收CDN返回的写入渠道信息的内容的分片；

在CDN根据FC的重定向通知从OSS下载分片的情况下，接收CDN返回的重定向下载得到的分片；

基于重定向下载的分片与写入渠道信息的内容的分片组成渠道包。

图14为用来实现本申请实施例的电子设备的框图。如图14所示，该电子设备包括：存储器1410和处理器1420，存储器1410内存储有可在处理器1420上运行的计算机程序。处理器1420执行该计算机程序时实现上述实施例中的方法。存储器1410和处理器1420的数量可以为一个或多个。

该电子设备还包括：通信接口1430，用于与外界设备进行通信，进行数据交互传输。

如果存储器1410、处理器1420和通信接口1430独立实现，则存储器1410、处理器1420和通信接口1430可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构（Industry Standard Architecture，ISA）总线、外部设备互连（PeripheralComponent Interconnect，PCI）总线或扩展工业标准体系结构（Extended IndustryStandard Architecture，EISA）总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图14中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器1410、处理器1420及通信接口1430集成在一块芯片上，则存储器1410、处理器1420及通信接口1430可以通过内部接口完成相互间的通信。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现本申请实施例中提供的方法。

本申请实施例还提供了一种芯片，该芯片包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行本申请实施例提供的方法。

本申请实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行申请实施例提供的方法。

应理解的是，上述处理器可以是中央处理器（Central Processing Unit，CPU），还可以是其他通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（FieldProgrammable Gate Array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器（Advanced RISC Machines，ARM）架构的处理器。

进一步地，可选的，上述存储器可以包括只读存储器和随机访问存储器。该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以包括只读存储器（Read-Only Memory，ROM）、可编程只读存储器（Programmable ROM，PROM）、可擦除可编程只读存储器（Erasable PROM，EPROM）、电可擦除可编程只读存储器（Electrically EPROM，EEPROM）或闪存。易失性存储器可以包括随机访问存储器（Random Access Memory，RAM），其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM均可用。例如，静态随机访问存储器（Static RAM，SRAM）、动态随机访问存储器（Dynamic Random Access Memory，DRAM）、同步动态随机访问存储器（Synchronous DRAM，SDRAM）、双倍数据速率同步动态随机访问存储器（Double Data RateSDRAM，DDR SDRAM）、增强型同步动态随机访问存储器（Enhanced SDRAM，ESDRAM）、同步链接动态随机访问存储器（Sync link DRAM，SLDRAM）和直接内存总线随机访问存储器（DirectRambus RAM，DR RAM）。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生依照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中描述的或在此以其他方式描述的任何过程或方法可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中描述的或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备（如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统）使用，或结合这些指令执行系统、装置或设备而使用。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下（例如，用户明确同意，对用户切实通知，等），在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

以上所述，仅为本申请的示例性实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请记载的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (12)

1.一种渠道包获取方法，其特征在于，所述方法包括：

对渠道包的回源请求针对的所述渠道包的每个分片，确定所述分片是否与渠道包格式中预留的区域有重叠区间；

若确定所述分片与所述区域有重叠区间，则从对象存储服务下载所述分片，在所述分片内的所述重叠区间中写入对应渠道信息的内容后发送给内容分发网络；

若确定所述分片与所述区域无重叠区间，则通知所述内容分发网络重定向至所述对象存储服务下载所述分片；

其中，所述渠道包格式中预留的区域用于保存渠道信息，所述重定向下载的分片与写入渠道信息的内容的分片用于组成所述渠道包；

所述确定所述分片是否与渠道包格式中预留的区域有重叠区间，包括：

将每个分片分别作为当前请求的分片，若符合以下任一条件则确定当前请求的分片与所述区域有重叠区间：

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域之间；

当前请求的分片的起始位置和结束位置均位于所述区域之间；

当前请求的分片的起始位置位于所述区域之间，且当前请求的分片的结束位置位于所述区域的结束位置之后；

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域的结束位置之后。

2.根据权利要求1所述的方法，其特征在于，所述在所述分片内的所述重叠区间中写入对应渠道信息的内容，包括：

根据所述回源请求针对的渠道确定相应的渠道信息；

将所述渠道信息中存储位置与所述重叠区间对应的内容，写入所述分片内的所述重叠区间中。

3.根据权利要求1所述的方法，其特征在于，在所述渠道包的签名方式为V1签名方式的情况下，所述渠道包中预留的用于保存渠道信息的区域位于中央目录结尾块中。

4.根据权利要求3所述的方法，其特征在于，所述中央目录结尾块中的注释长度的值为所述区域的长度，所述中央目录结尾块中的注释内容的值为渠道信息。

5.根据权利要求1所述的方法，其特征在于，在所述渠道包的签名方式为V2或V3签名方式的情况下，所述渠道包中预留的用于保存渠道信息的区域位于应用程序包签名块中。

6.根据权利要求5所述的方法，其特征在于，所述区域位于所述应用程序包签名块中的填充魔数键值对之后，且为键值对格式，包括渠道信息键值对长度、渠道标识魔数ID和值。

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

将每个分片分别作为当前请求的分片，若当前请求的分片的结束位置位于所述区域的起始位置之前，或者当前请求的分片的起始位置位于所述区域的结束位置之后，则确定当前请求的分片与所述区域无重叠区间。

8.一种渠道包获取方法，其特征在于，所述方法包括：

向函数计算发送渠道包的回源请求，所述回源请求用于请求所述渠道包的每个分片；

在所述函数计算确定有分片与渠道包格式中预留的区域有重叠空间的情况下，接收所述函数计算返回的写入渠道信息的内容的分片，所述渠道信息的内容为所述函数计算从对象存储服务下载分片后写入的；

在所述函数计算确定有分片与渠道包格式中预留的区域无重叠空间的情况下，接收所述函数计算返回的重定向通知，根据所述重定向通知从所述对象存储服务下载分片；

其中，所述渠道包格式中预留的区域用于保存渠道信息，根据所述重定向通知下载的分片与写入渠道信息的内容的分片用于组成所述渠道包；

所述函数计算确定每个分片是否与渠道包格式中预留的区域有重叠区间，包括：

将每个分片分别作为当前请求的分片，若符合以下任一条件则确定当前请求的分片与所述区域有重叠区间：

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域之间；

当前请求的分片的起始位置和结束位置均位于所述区域之间；

当前请求的分片的起始位置位于所述区域之间，且当前请求的分片的结束位置位于所述区域的结束位置之后；

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域的结束位置之后。

9.一种渠道包获取方法，其特征在于，所述方法包括：

在函数计算根据渠道包的回源请求确定所述渠道包的所有分片中有分片与渠道包格式中预留的区域有重叠空间的情况下，接收所述函数计算的分片请求，下发所述分片请求对应的分片给所述函数计算，以使所述函数计算在所述分片内的重叠区间中写入对应渠道信息的内容后发送给内容分发网络；

在所述函数计算确定所述所有分片中有分片与渠道包格式中预留的区域无重叠空间且发送重定向通知给所述内容分发网络的情况下，接收所述内容分发网络的分片请求，下发所述分片请求对应的分片给所述内容分发网络；

其中，所述渠道包格式中预留的区域用于保存渠道信息，根据所述重定向通知下发的分片与写入渠道信息的内容的分片用于组成所述渠道包；

所述函数计算确定渠道包的每个分片是否与渠道包格式中预留的区域有重叠区间，包括：

将每个分片分别作为当前请求的分片，若符合以下任一条件则确定当前请求的分片与所述区域有重叠区间：

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域之间；

当前请求的分片的起始位置和结束位置均位于所述区域之间；

当前请求的分片的起始位置位于所述区域之间，且当前请求的分片的结束位置位于所述区域的结束位置之后；

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域的结束位置之后。

10.一种渠道包获取方法，其特征在于，所述方法包括：

向内容分发网络发送渠道包的获取请求，以请求所述渠道包的每个分片；

在所述内容分发网络根据所述渠道包的回源请求从函数计算获得写入渠道信息的内容的分片的情况下，接收所述内容分发网络返回的写入渠道信息的内容的分片，所述渠道信息的内容由所述函数计算确定有分片与渠道包格式中预留的区域有重叠空间的情况下写入；

在所述内容分发网络根据所述函数计算的重定向通知从对象存储服务下载分片的情况下，接收所述内容分发网络返回的重定向下载得到的分片；

基于所述重定向下载的分片与写入渠道信息的内容的分片组成所述渠道包；

其中，所述函数计算确定渠道包的每个分片是否与渠道包格式中预留的区域有重叠区间，包括：

将每个分片分别作为当前请求的分片，若符合以下任一条件则确定当前请求的分片与所述区域有重叠区间：

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域之间；

当前请求的分片的起始位置和结束位置均位于所述区域之间；

当前请求的分片的起始位置位于所述区域之间，且当前请求的分片的结束位置位于所述区域的结束位置之后；

当前请求的分片的起始位置位于所述区域的起始位置之前，且当前请求的分片的结束位置位于所述区域的结束位置之后。

11.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，所述处理器在执行所述计算机程序时实现权利要求1-10中任一项所述的方法。

12.一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-10中任一项所述的方法。

Images