CN113934460B

CN113934460B - 一种资源提供方法及装置

Info

Publication number: CN113934460B
Application number: CN202111189250.0A
Authority: CN
Inventors: 董涛; 李涛
Original assignee: Zhengzhou Apas Digital Cloud Information Technology Co ltd
Current assignee: Zhengzhou Apas Digital Cloud Information Technology Co ltd
Priority date: 2021-10-12
Filing date: 2021-10-12
Publication date: 2024-09-13
Anticipated expiration: 2041-10-12
Also published as: CN113934460A

Abstract

本申请公开了一种资源提供方法和装置，所述方法可获取资源提供方对外提供的多个基础SDK，一个基础SDK用于实现一种预设功能；基于至少一个资源需求方的业务需求，对所述多个基础SDK进行组合得到至少一个SDK组合，一个SDK组合用于实现一种业务需求下的至少一种预设功能；对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，一个合并SDK用于实现一种业务需求下的至少一种预设功能；向所述至少一个资源需求方提供所述至少一个合并SDK，以使目标资源需求方通过接入目标合并SDK实现自身业务所需的至少一种预设功能。该方法及装置可降低资源需求方接入SDK的门槛，减少接入时间，提高接入效率。

Description

一种资源提供方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源提供方法及装置。

背景技术

软件开发工具包(Software Development Kit，SDK)一般是特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。在具体应用中，资源提供方对外提供SDK，以供需求方接入使用。

目前，资源提供方对外提供SDK时，要么放到指定仓库(如maven仓库)，需求方到该指定仓库为需要使用的SDK一一添加依赖，以接入相应的SDK，要么放到官网，由使用方下载至本地，并手动一一添加依赖来接入相应的SDK。

不难发现，在目前的资源提供方案中，需求方需要接入多少SDK，就要添加多少次依赖，接入门槛高，接入时间长，接入效率低下。

发明内容

本申请实施例提供一种资源提供方法及装置，以提高SDK的接入效率。

第一方面，本申请实施例提供一种资源提供方法，包括：

获取资源提供方对外提供的多个基础SDK，其中，一个基础SDK用于实现一种预设功能；

基于至少一个资源需求方的业务需求，对所述多个基础SDK进行组合得到至少一个SDK组合，其中，一个SDK组合中包含至少一个基础SDK，且一个SDK组合中的至少一个基础SDK含有资源，一个SDK组合用于实现一种业务需求下的至少一种预设功能；

对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，其中，一个SDK组合对应得到一个合并SDK，一个合并SDK用于实现一种业务需求下的至少一种预设功能；

向所述至少一个资源需求方提供所述至少一个合并SDK，以使目标资源需求方通过接入目标合并SDK实现自身业务所需的至少一种预设功能，其中，所述目标资源需求方为所述至少一个资源需求方中的一个，所述目标合并SDK 为所述至少一个合并SDK中的一个。

第二方面，本申请实施例还提供一种资源提供装置，包括：

资源获取模块，用于获取资源提供方对外提供的多个基础SDK，其中，一个基础SDK用于实现一种预设功能；

资源组合模块，用于基于至少一个资源需求方的业务需求，对所述多个基础SDK进行组合得到至少一个SDK组合，其中，一个SDK组合中包含至少一个基础SDK，且一个SDK组合中的至少一个基础SDK含有资源，一个SDK 组合用于实现一种业务需求下的至少一种预设功能；

资源合并模块，用于对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，其中，一个SDK组合对应得到一个合并SDK，一个合并SDK用于实现一种业务需求下的至少一种预设功能；

资源提供模块，用于向所述至少一个资源需求方提供所述至少一个合并 SDK，以使目标资源需求方通过接入目标合并SDK实现自身业务所需的至少一种预设功能，其中，所述目标资源需求方为所述至少一个资源需求方中的一个，所述目标合并SDK为所述至少一个合并SDK中的一个。

第三方面，本申请实施例还提供了一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的方法的步骤。

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

本申请实施例采用的上述至少一个技术方案，由于可以按照资源需求方的业务需求，将资源提供方的至少一个基础SDK合并为一个SDK向资源需求方提供，而不是直接提供多个基础SDK，因此，可以降低资源需求方接入SDK 的接入门槛，减少接入时间，提高接入效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请一实施例提供的一种资源提供方法的流程示意图。

图2是本申请另一实施例提供的一种资源提供方法的流程示意图。

图3是图1或图2中的步骤102的一种详细流程示意图。

图4是图1或图2中的步骤103的一种详细流程示意图。

图5是本申请实施例提供的一种资源提供装置的结构示意图。

图6是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了解决相关技术中需求方需要接入SDK时，接入门槛高，接入时间长，接入效率低下的问题，本申请实施例提供了一种资源提供方法和装置，该方法和装置可由资源提供方实施，以向资源需求方以供资源，具体可以向资源需求方提供SDK。该方法和装置可由电子设备执行，如终端设备或服务器，或者，该方法可由安装在电子设备中的软件执行。其中，所述终端设备包括但不限于：智能手机、个人电脑(personal computer，PC)、笔记本电脑、平板电脑、电子阅读器、网络电视、可穿戴设备等智能终端设备中的任一种；该服务器包括但不限于：单台服务器、服务器集群、云端服务器或云端服务器集群等。

下面先对本申请实施例提供的一种资源提供方法进行说明。

如图1所示，本申请实施例提供的一种资源提供方法，可包括：

步骤101、获取资源提供方对外提供的多个基础SDK，其中，一个基础SDK 用于实现一种预设功能。

资源提供方可以是任何对外提供SDK的平台。一个基础SDK可以是资源提供方开发的用于实现一种预设功能的SDK，例如，用于网络通信的SDK、用于云控的SDK、用于发布广告的SDK、用于上报数据的SDK、用于账号管理的SDK、用于搜索的SDK、用于下载的SDK、用于打点的SDK，用于升级的SDK，用于推送消息的SDK，等等。

资源提供方对外提供的上述多个基础SDK可以是该资源提供方的全部或部分基础SDK，上述多个基础SDK的数量可以用n表示，n为大于0的整数。

可选地，可以为上述多个基础ID分别设置唯一标识(ID)，以对不同的基础SDK进行区分。

作为一个例子，可以按照上述多个基础SDK的数量为上述多个基础SDK 分别进行编号，并将基础SDK编号作为其唯一标识。例如，例如假设有6个基础SDK：SDK1、SDK2、SDK3、SDK4、SDK5，他们的唯一标识可以分别为：1、2、3、4、5、6。

作为另一个例子，如果基础SDK的唯一标识会被用于确定下述合并SDK 的唯一标识，那么为了避免组合后的唯一标识出现重复，上述多个基础SDK的唯一标识可以依次取为预设数值(例如2)的阶乘。例如，仍假设有6个基础 SDK：SDK1、SDK2、SDK3、SDK4、SDK5、SDK6，那么他们的唯一标识可以分别为：

SDK1:1

SDK2:2

SDK3:4

SDK4:8

SDK5:16

SDK6:32

可选地，资源提供方对外提供的各基础SDK中可以含有资源，也可以不含资源，这里的资源可以是图片、视频和文件等任何资源。

步骤102、基于至少一个资源需求方的业务需求，对所述多个基础SDK进行组合得到至少一个SDK组合，其中，一个SDK组合中包含至少一个基础 SDK，一个SDK组合用于实现一种业务需求下的至少一种预设功能。

可选地，一个SDK组合中的至少一个基础SDK含有资源。

一般而言，一个资源需求方对应一种业务需求，且该种业务需求可能需要接入多个基础SDK才能实现，例如，对于某一应用(Application，APP)开发公司，可能需要接入用于采集数据的打点基础SDK、用于网络通信的基础SDK、用于云控的基础SDK、用于发布广告的基础SDK以及用于上报数据的基础 SDK等，如果按照现有的一一接入方式，则接入门槛高、接入时间长、接入效率低下，如果对这些基础SDK进行合并后再提供给该资源需求方，则可以避免这些问题。因此，可以按照某一资源需求方的业务需求，将该资源需求方所需的全部基础SDK组合成一个SDK组合，并将该个SDK组合合并后提供给资源提供方，以避免这些问题。

对于一个资源提供方来说，常常是面向多个资源提供方提供资源的，而不同资源需求方的业务需求可能是不同的，因此，可针对不同的资源需求方的业务需求，分别对资源提供方提供的上述多个基础SDK进行组合，得到至少一个SDK组合，一般而言，针对一个资源需求方的一种业务需求，得到一个SDK 组合，由于一个SDK组合集成了其中包含的各基础SDK的全部功能，因此，一个SDK组合可用于实现一种业务需求下的至少一种预设功能。

可选地，也可以按照排列组合的方式，对上述多个基础SDK进行组合，获得所有可能的基础SDK组合，以供资源需求方根据自身的业务需求自由选择响应的SDK组合进行使用。例如，假设上述多个基础SDK的数量为n，那么可能的组合共有n！种。

在具体实现时，可以生成一个SDK组合列表，以存储不同的SDK组合，例如可生成如表1所示的SDK组合。

表1

序号	SDK组合
		1	SDK1，SDK2，SDK3
2	SDK1，SDK5，SDK6
		3	SDK1，SDK2，SDK3 SDK5，SDK6，
…	…

步骤103、对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，其中，一个SDK组合对应得到一个合并SDK。

由于一个合并SDK是对其对应的一个SDK组合中的基础SDK进行合并得到的，因此，与一个SDK组合的功能类似，一个合并SDK也可用于实现一种业务需求下的至少一种预设功能。

在此步骤中，可以对SDK组合列表中所存储的全部或部分SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK。对于一个SDK组合，合并时，一次合并两个SDK得到一个新的SDK，然后将新的SDK与该SDK组合中其余SDK中的一个SDK合并，再次得到一个新的SDK，如此类推，直到该 SDK组合中的SDK全部被合并；也可以先将该SDK组合中的SDK，两两合并，再将合并得到的SDK再进行两两合并，直到该SDK组合中的SDK全部被合并，具体的合并过程将在下文详细描述，此处暂不赘述。

可选地，还可以为所述至少一个合并SDK设置唯一标识(ID)，以便于资源需求方获取合并SDK时，能够找到自己想要的合并SDK，例如，以使目标资源需求方根据目标合并SDK的唯一标识获取所述目标合并SDK，其中，所述目标资源需求方为所述至少一个资源需求方中的一个，所述目标合并SDK 为所述至少一个合并SDK中的一个。当然，所述目标资源需求方也可以是所述至少一个资源需求方以外的资源需求方，只要其业务需求与目标合并SDK匹配即可。

作为一个例子，可以使用任何能够区分不同合并SDK的方式，为上述至少一个合并SDK设置唯一标识，也即，保证不同合并SDK的唯一标识不同。

作为另一个例子，对于所述至少一个合并SDK中的任一合并SDK，确定合并得到该合并SDK的全部基础SDK的唯一标识；基于所述全部基础SDK 的唯一标识，确定该合并SDK的唯一标识。

进一步地，当一个合并SDK中的全部基础SDK的唯一标识为数值型时，可以对该合并SDK中全部基础SDK的唯一标识进行求和，得到该合并SDK 的唯一标识。例如，当上述多个基础SDK的唯一标识为2的阶乘时，对于通过对SDK1和SDK2进行合并得到一个合并SDK来说，其唯一标识为：1+2＝3。

设置合并SDK的唯一标识的方式很多，此处不再列举。

步骤104、向所述至少一个资源需求方提供所述至少一个合并SDK，以使目标资源需求方通过接入目标合并SDK实现自身业务所需的至少一种预设功能，其中，所述目标资源需求方为所述至少一个资源需求方中的一个，所述目标合并SDK为所述至少一个合并SDK中的一个。

具体的，可以将所述至少一个合并SDK发布到预设服务器上，并针对所述至少一个合并SDK分别生成下载链接；分别建立所述至少一个合并SDK的唯一标识与下载链接的对应关系；向所述目标资源需求方提供所述对应关系，以使所述目标资源需求方基于所述对应关系查找目标合并SDK的下载链接，并下载所述目标合并SDK。

可选地，在向所述至少一个资源需求方提供所述至少一个合并SDK时，还可以向所述目标资源需求方提供所述至少一个合并SDK的唯一标识与所述至少一个合并SDK所能实现的功能的对应关系，以供目标资源需求方根据该对应关系选择与自身的业务需求匹配的目标合并SDK。

可选地，在向所述至少一个资源需求方提供所述至少一个合并SDK时，还可以向所述目标资源需求方提供合并得到所述目标合并SDK的基础SDK的唯一标识，以供所述目标资源需求方明确合并得到所述目标合并SDK的基础 SDK，进而明确目标合并SDK能实现哪些功能，并确认这些功能与自身的业务需求是否匹配。

本申请实施例提供的一种资源提供方法，由于可以按照资源需求方的业务需求，将资源提供方的至少一个基础SDK合并为一个SDK向资源需求方提供，而不是直接提供多个基础SDK，因此，可以降低资源需求方接入SDK的接入门槛，减少接入时间，提高接入效率。

如图2所示，本申请另一实施例提供的一种资源提供方法，可以包括：

步骤101、获取资源提供方对外提供的多个基础SDK。

其中，一个基础SDK用于实现一种预设功能。

可选地，一个SDK组合中的至少一个基础SDK含有资源。

步骤105、遍历所述至少一个SDK组合，确定每一SDK组合中否存在互斥SDK，若存在，将该组SDK从所述多组SDK删除，转入步骤106。

有些SDK之间不能共存，则需要建立互斥关系，例如SDK1和SDK4不能共存，则建立如下依赖关系：

SDK≠SDK4

互斥关系没有传递性。

在具体实现时，可以预先建立一个互斥关系列表，然后判断每一SDK组合中是否存在该互斥列表中的至少一种互斥关系，若存在，则将该SDK组合删除。

步骤106、判断对所述至少一个SDK组合的遍历是否结束，若结束，执行步骤107，若未结束，则执行步骤105以继续遍历。

步骤107、遍历所述至少一个SDK组合，确定每一SDK组合中否存在依赖SDK，若存在，将所述依赖SDK添加至该组SDK中。

有些SDK需要依赖其他SDK，因此需要建立好依赖关系，例如SDK1依赖SDK2，则建立如下依赖：

SDK1-->SDK2

一个SDK也可以依赖多个其他SDK：

SDK1-->SDK2,SDK3

依赖具有传递性，例如加入SDK3-->SDK5，则SDK1间接依赖SDK5。

在具体实现时，可以预先建立一个依赖关系列表，然后判断每一SDK组合中是否存在该互斥列表中的一种或多种依赖关系，若存在，则在该SDK组合中添加这些依赖关系中的依赖SDK。

步骤108、判断对所述至少一个SDK组合的遍历是否结束，若结束，执行步骤103，若未结束，则执行步骤107以继续遍历。

假设一共有n个基础SDK，则其可能的组合方式一共有n！种组合，从中删除存在SDK互斥关系的组合后，SDK的组合的数量将小于n！，对于存在依赖关系的SDK组合，还要添加所依赖的基础SDK至该SDK组合。

步骤103、对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，其中，一个SDK组合对应得到一个合并SDK，一个合并 SDK用于实现一种业务需求下的至少一种预设功能。

本申请实施例提供的一种资源提供方法，与图1所示的实施例提供的一种资源提供方法的不同之处在于，得到可能的SDK组合后，还需要从中删除存在互斥SDK的组合，以及在相应的SDK组合中添加存在依赖关系的SDK，以保证资源需求方将来下载相应的合并SDK以后能够正常使用。

图3示出了上述步骤103的一种详细流程示意图。如图3所示，上述步骤 103可包括：

步骤30、开始。

步骤31、遍历所述至少一个SDK组合，并对当前SDK组合执行第一指定步骤32。

其中，第一指定步骤32，包括：

步骤321、从所述当前SDK组合中取出第一个基础SDK。

步骤322、判断所述当前SDK组合中剩余的基础SDK数量是否为0；若为0，则执行步骤34，否则执行步骤323。

步骤323、从所述当前SDK组合中取出第二个基础SDK。

步骤314、对所述第一个基础SDK和所述第二个基础SDK进行合并，得到第一个合并SDK。

然后，可以循环执行第二指定步骤，直到所述当前SDK组合中剩余的基础SDK数量为0，并将第n-1个合并SDK确定为所述当前SDK组合的合并 SDK，n是未对所述当前SDK组合中的基础SDK进行并时的基础SDK总数。

其中，第二指定步骤302包括：

步骤3251、判断所述当前SDK组合中剩余的基础SDK数量是否为0；若为0，执行步骤34，否则执行步骤3252。

步骤3252、从所述当前SDK组合中取出第i个基础SDK。

其中，i＝3,4，…，n。

步骤3253、对所述第i个基础SDK和第j个合并SDK进行合并，得到第 j+1个合并SDK。

其中，j＝1,2，…，n-1。

步骤33、判断对所述至少一个SDK组合的遍历是否结束；若结束，执行步骤34，否则，返回步骤31继续进行遍历。

步骤34、结束。

其中，在一个SDK和另一个SDK具体进行合并时，对于不同类型的SDK，其合并方式有所不同，下面将被合并的两个SDK分别称为第一SDK和第二 SDK，将二者合并得到的SDK称为目标合并SDK为例进行说明。

可以理解，对于上述当前SDK组合，当所述第一个基础SDK为所述第一 SDK时，所述第二个基础SDK为所述第二SDK，所述第一个合并SDK为所述目标合并SDK；当所述第i个基础SDK为所述第一SDK为时，所述第j个合并SDK为所述第二SDK，所述第j+1个合并SDK为所述目标合并SDK。

一般而言，对于java而言，其SDK包含四种类型：含有资源的aar包、不含资源的aar包、jar包和zip包，因此，对应的合并方式可包括下述几种：

含有资源的aar包a(第一SDK)+含有资源的aar包b(第二SDK)；

含有资源的aar包a(第一SDK)+不含资源的aar包b(第二SDK)；

不含资源的aar包a(第一SDK)+不含资源的aar包b(第二SDK)；

含有资源的aar包a(第一SDK)+jar包b(第二SDK)；

不含资源的aar包a(第一SDK)+jar包b(第二SDK)；

jar包a(第一SDK)+jar包b(第二SDK)。

下面一一进行说明。

(1)含有资源的aar包a(第一SDK)+含有资源的aar包b(第二SDK)

如图4所示，对第一SDK和第二SDK进行合并，得到目标合并SDK，包括：

步骤400、开始。

步骤401、对第一SDK进行解压，得到第一资源文件和第一jar包。

也即，对aar包a进行解压。

步骤402、对第二SDK进行解压，得到第二资源文件和第二jar包。

也即，对aar包b进行解压。

可选地，将aar包b解压目录的libs目录下的文件、jni目录下的文件、assets 目录下的文件依次拷贝到aar包a解压目录对应的目录下。

可选地，从aar包a解压目录下的AndroidManifest.xml解析出包名package，例如，如下代码所示，解析出的包名为com.a：

<？xml version＝”1.0”encoding＝”utf-8”？>

从aar包b解压目录下的AndroidManifest.xml解析出包名package例如，如下代码所示，解析出的包名为com.b:

<？xml version＝”1.0”encoding＝”utf-8”？>

可选地，从aar包b解压目录下的R.txt(第二资源文件)解析所有资源名，并重命名，R.txt为资源索引文件，其格式为：

int资源类型资源名称0x0

例如：

int anim abc_fade_in 0x0

int anim btn_checkbox_to_checked_box_inner_merged_animation 0x0

int animator mtrl_fab_transformation_sheet_collapse_spec 0x0

int animator mtrl_fab_transformation_sheet_sepand_spec 0x0

int array subscribe_privilege_icon 0x0

int array user_report 0x0

int attr yearTodayStyle 0x0

int attr zOrderOnTop 0x0

其中，anim表示资源abc_fade_in为一个动画资源，array表示资源 subscribe_privilege_icon为一个资源数组，attr表示资源yearTodayStyle为一个属性，应理解，资源的类型并不限于这几种，这里仅仅是举例。

可选地，解析aar包b的R.txt(第二资源文件)建立资源名和类型的索引，例如：

abc_fade_in->anim

mtrl_fab_transformation_sheet_collapse_spec->animator

subscribe_privilege_icon->array

yearTodayStyle->attr

进一步地，对第二资源索引文件进行解析，得到所述第二资源索引文件中的资源名，并对所述第二资源索引文件中的资源名进行修改，以在所述第二资源索引文件中的资源名前添加所述第二SDK的包名。具体的，重命名所有资源名，为其加上包名前缀，例如：

abc_fade_in重命名为com_b_abc_fade_in

mtrl_fab_transformation_sheet_collapse_spec重命名为：

com_b_mtrl_fab_transformation_sheet_collapse_spec

subscribe_privilege_icon重命名为：

com_b_subscribe_privilege_icon

yearTodayStyle重命名为：

com_b_yearTodayStyle

可以理解，之所对第二资源文件中的资源进行重命名，是为了防止aar包与aar包b中存在同名资源，使得资源需求方在使用合并SDK时出现错误。

步骤403、将所述第一资源文件和所述第二资源文件进行合并，得到合并资源文件。

步骤404、将所述第一SDK的解压目录下的第一资源文件替换为所述合并资源文件。

将修改资源名后的R.txt(第二资源文件)和从aar包a(第一SDK)解压目录下的R.txt(第一资源文件)合并为一个R.txt(合并资源文件)，并用该合并资源文件，替换aar包a(第一SDK)解压目录下的R.txt(第一资源文件)。

步骤405、对所述第二jar包进行解压得到类文件，并将所述类文件转换为java文件。

步骤406、对所述java文件进行解析，并将所述java文件中的目标代码依照所述合并资源文件进行修改，所述目标代码包括与所述第二资源文件有关的代码。

步骤407、将修改后的所述java文件进行打包，得到第三jar包。

步骤408、将所述第三jar包拷贝到所述第一SDK的解压目录下。

步骤409、将所述第一SDK的当前解压目录下的文件进行打包，得到第一合并SDK的aar包。

对于步骤405至步骤409，举例来说，即解压classes.jar(第二jar包)，遍历解压后的目录，将遍历到的每一个class文件做如下处理：

1.使用工具jad将class文件转为java文件；

2.解析转换后的java文件：

2.1如果遇到“import com.b.R”类型的字符串，则将其替换为“import com.a.R”。

2.2如果遇到R.x.xx格式的字符串，则截取其第2段x(资源类型)和第3段xx(资源名)。

2.3将截取的第3段xx与上文中建立的中建立的资源名和类型的索引进行匹配，如果匹配到资源名，则获取匹配到的资源类型resType。

2.4如果resType与步骤2.2中的资源类型x匹配，则将xx加上包名前缀com.b，变成com_b_xx，并替换字符串R.x.xx为R.x.com_b_xx。

2.5在当前java文件解析完时，使用java命令

3.第二jar包中的所有class文件处理完成后，再将解压目录压缩成 classes.jar文件。

4.将处理好的classes.jar重命名为“包名”.jar，本例为com_b.jar，并将其拷贝到aar包a(第一SDK)解压目录的libs子目录下。

5.压缩aar包a为一个aar文件，即得到第一合并SDK。

步骤410、结束。

可以看出，通过图4所示的过程可完成含有资源的第一SDK和含有资源的第二SDK的合并，该合并方式的巧妙之处在于，一方面，通过修改第二SDK 的资源文件中的资源名(第二资源文件中的资源名，具体是在资源名前加上前缀：com_b)，可以避免将第二资源文件与第一资源文件合并时，出现第二SDK 与第一SDK的同名资源的误覆盖，进而防止将来使用合并后的SDK时出错；另一方面，通过修改第二SDK的jar包中与第二资源文件中的资源有关的代码，可以保证合并后的SDK能够正确调用原来属于第二SDK的资源。

(2)含有资源的aar包a(第一SDK)+不含资源的aar包b(第二SDK)

首先，对aar包a(第一SDK)和aar包b(第二SDK)分别进行解压。

其次，将aar包b(第二SDK)解压目录的classes.jar重命名为aar包.jar, 并拷贝到aar包a(第一SDK)解压目录的lib目录下。

之后，将aar包b(第二SDK)解压目录下的其余文件，如libs目录下的文件、jni目录下的文件以及assets目录下的文件，依次拷贝到aar包a(第一 SDK)解压目录的对应子目录下。

最后，压缩aar包a(第一SDK)生成合并aar文件，即得到第一合并SDK。

(3)不含资源的aar包a(第一SDK)+不含资源的aar包b(第二SDK)

首先，对aar包a(第一SDK)和aar包b(第二SDK)分别进行解压。

(4)含有资源的aar包a(第一SDK)+jar包b(第二SDK)

首先，对aar包a(第一SDK)进行解压。

然后，将jar包b(第二SDK)拷贝到aar包a(第一SDK)解压目录的lib 目录下。

(5)不含资源的aar包a(第一SDK)+jar包b(第二SDK)

首先，对aar包a(第一SDK)进行解压。

(6)jar包a(第一SDK)+jar包b(第二SDK)

首先，可建立一个名称为jar包a的文件夹，并在其中建立子目录libs。

然后，将jar包a重命名为classes.jar并拷贝到该目录。

其次，将jar包b拷贝到上述文件夹的libs子目录下。

最后，将该文件夹压缩成zip包，并修改后缀名为aar，得到第一合并SDK。

上面介绍了，不同类型的第一SDK和第二SDK的几种合并方式，在实际应用，可参照上述方式进行两个SDK的合并。

相应于上述方法实施例，本申请实施例还提供了一种资源提供装置，下面进行介绍。

如图5所示，本申请实施例提供的一种资源提供装500，装置500可以包括：资源获取模块501、资源组合模块502、资源合并模块503和资源提供模块504。

资源获取模块501，用于获取资源提供方对外提供的多个基础SDK，其中，一个基础SDK用于实现一种预设功能。

资源组合模块502，用于基于至少一个资源需求方的业务需求，对所述多个基础SDK进行组合得到至少一个SDK组合，其中，一个SDK组合中包含至少一个基础SDK，且一个SDK组合中的至少一个基础SDK含有资源，一个 SDK组合用于实现一种业务需求下的至少一种预设功能。

资源合并模块503，用于对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，其中，一个SDK组合对应得到一个合并SDK，一个合并SDK用于实现一种业务需求下的至少一种预设功能。

具体的，资源合并模块503可以对SDK组合列表中所存储的全部或部分 SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK。对于一个SDK 组合，合并时，一次合并两个SDK得到一个新的SDK，然后将新的SDK与该 SDK组合中其余SDK中的一个SDK合并，再次得到一个新的SDK，如此类推，直到该SDK组合中的SDK全部被合并；也可以先将该SDK组合中的SDK，两两合并，再将合并得到的SDK再进行两两合并，直到该SDK组合中的SDK 全部被合并。

作为一个例子，资源合并模块503，具体可用于：遍历所述至少一个SDK 组合，并对当前SDK组合执行第一指定步骤，直到遍历结束。

其中，所述第一指定步骤包括：从所述当前SDK组合中取出第一个基础 SDK；判断所述当前SDK组合中剩余的基础SDK数量是否为0；若为否，从所述当前SDK组合中取出第二个基础SDK；对所述第一个基础SDK和所述第二个基础SDK进行合并，得到第一个合并SDK后循环执行第二指定步骤，直到所述当前SDK组合中剩余的基础SDK数量为0，并将第n-1个合并SDK确定为所述当前SDK组合的合并SDK，n是未对所述当前SDK组合中的基础 SDK进行并时的基础SDK总数。

其中，所述第二指定步骤包括：判断所述当前SDK组合中剩余的基础SDK 数量是否为0；若为否，从所述当前SDK组合中取出第i个基础SDK，其中， i＝3,4，…，n；对所述第i个基础SDK和第j个合并SDK进行合并，得到第j+1 个合并SDK，其中，j＝1,2，…，n-1。

进一步地，当被合并的第一SDK和第二SDK为aar包，且所述第二SDK 和所述第二SDK中均含有资源时，对第一SDK和第二SDK进行合并，得到目标合并SDK，包括：

对所述第一SDK进行解压，得到第一资源文件和第一jar包；

对所述第二SDK进行解压，得到第二资源文件和第二jar包；

将所述第一资源文件和所述第二资源文件进行合并，得到合并资源文件，并将所述第一SDK的解压目录下的第一资源文件替换为所述合并资源文件；

对所述第二jar包进行解压得到类文件，并将所述类文件转换为java文件；

对所述java文件进行解析，并将所述java文件中的目标代码依照所述合并资源文件进行修改，所述目标代码包括与所述第二资源文件有关的代码；

将修改后的所述java文件进行打包，得到第三jar包；

将所述第三jar包拷贝到所述第一SDK的解压目录下；

将所述第一SDK的当前解压目录下的文件进行打包，得到目标合并SDK 的aar包，其中，所述第一SDK的当前解压目录下的文件包括：所述第一jar 包、所述第三jar包和所述合并资源文件；

其中，对于所述当前SDK组合，当所述第一个基础SDK为所述第一SDK 时，所述第二个基础SDK为所述第二SDK，所述第一个合并SDK为所述目标合并SDK；当所述第i个基础SDK为所述第一SDK为时，所述第j个合并SDK 为所述第二SDK，所述第j+1个合并SDK为所述目标合并SDK。

此外，两个SDK的其他合并方式请参照上文对方法实施例的说明，此处不再赘述。

资源提供模块504，用于向所述至少一个资源需求方提供所述至少一个合并SDK，以使目标资源需求方通过接入目标合并SDK实现自身业务所需的至少一种预设功能，其中，所述目标资源需求方为所述至少一个资源需求方中的一个，所述目标合并SDK为所述至少一个合并SDK中的一个。

具体的，资源提供模块504可用于：将所述至少一个合并SDK发布到预设服务器上，并针对所述至少一个合并SDK分别生成下载链接；分别建立所述至少一个合并SDK的唯一标识与下载链接的对应关系；向所述资源需求方提供所述对应关系，以使所述资源需求方基于所述对应关系查找目标合并SDK 的下载链接，并下载所述目标合并SDK。

可选地，图5所示的装置还可以包括：第一ID设置模块，用于上述多个基础ID分别设置唯一标识(ID)，以对不同的基础SDK进行区分。

进一步地，上述多个基础SDK的唯一标识可以依次取为预设数值(例如 2)的阶乘。

可选地，图5所示的装置还可以包括：第二ID设置模块，用于为所述至少一个合并SDK设置唯一标识(ID)，以便于资源需求方获取合并SDK时，能够找到自己想要的合并SDK。

进一步地，第二ID设置模块，可用于对于所述至少一个合并SDK中的任一合并SDK，确定合并得到该合并SDK的全部基础SDK的唯一标识；基于所述全部基础SDK的唯一标识，确定该合并SDK的唯一标识。

进一步地，当一个合并SDK中的全部基础SDK的唯一标识为数值型时，可以对该合并SDK中全部基础SDK的唯一标识进行求和，得到该合并SDK 的唯一标识。

可选地，图5所示的装置还可以包括：第一遍历模块，用于在组合得到所述至少一个SDK组合后，遍历所述至少一个SDK组合，确定每一SDK组合中否存在互斥SDK，若存在，将该组SDK从所述多组SDK删除。

可选地，图5所示的装置还可以包括：第二遍历模块，用于在组合得到所述至少一个SDK组合后，遍历所述至少一个SDK组合，确定每一SDK组合中否存在依赖SDK，若存在，将所述依赖SDK添加至该组SDK中。

本申请实施例提供的一种资源提供装置，由于可以按照资源需求方的业务需求，将资源提供方的至少一个基础SDK合并为一个SDK向资源需求方提供，而不是直接提供多个基础SDK，因此，可以降低资源需求方接入SDK的接入门槛，减少接入时间，提高接入效率。

需要说明的是，由于装置实施例执行的内容与方法实施例类似，因此，本文对装置实施例部分描述的较为简略，相关之处请参见方法实施例部分。

图6示出了是本申请实施例提供的一种电子设备的结构示意图。请参考图 6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成资源提供装置。处理器，执行存储器所存放的程序，并具体用于执行本申请实施例提供的资源提供方法。

上述如本申请图5所示实施例揭示的资源提供装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor， NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field －Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图5所示实施例中资源提供装置执行的方法，并具体用于执行本申请实施例提供的资源提供方法。

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

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

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

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

需要说明的是，本申请中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种资源提供方法，其特征在于，所述方法包括：

向所述至少一个资源需求方提供所述至少一个合并SDK，以使目标资源需求方通过接入目标合并SDK实现自身业务所需的至少一种预设功能，其中，所述目标资源需求方为所述至少一个资源需求方中的一个，所述目标合并SDK为所述至少一个合并SDK中的一个；

所述对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，包括：

遍历所述至少一个SDK组合，并对当前SDK组合执行第一指定步骤，直到遍历结束；

其中，所述第一指定步骤包括：

从所述当前SDK组合中取出第一个基础SDK；

判断所述当前SDK组合中剩余的基础SDK数量是否为0；

若为否，从所述当前SDK组合中取出第二个基础SDK；

对所述第一个基础SDK和所述第二个基础SDK进行合并，得到第一个合并SDK后循环执行第二指定步骤，直到所述当前SDK组合中剩余的基础SDK数量为0，并将第n-1个合并SDK确定为所述当前SDK组合的合并SDK，n是未对所述当前SDK组合中的基础SDK进行并时的基础SDK总数；

其中，所述第二指定步骤包括：

判断所述当前SDK组合中剩余的基础SDK数量是否为0；

若为否，从所述当前SDK组合中取出第i个基础SDK，其中，i＝3,4，…，n；

对所述第i个基础SDK和第j个合并SDK进行合并，得到第j+1个合并SDK，其中，j＝1,2，…，n-1；

当被合并的第一SDK和第二SDK为aar包，且所述第一SDK和所述第二SDK中均含有资源时，对第一SDK和第二SDK进行合并，得到第一合并SDK，包括：

对所述第一SDK进行解压，得到第一资源文件和第一jar包；

对所述第二SDK进行解压，得到第二资源文件和第二jar包；

将修改后的所述java文件进行打包，得到第三jar包；

将所述第三jar包拷贝到所述第一SDK的解压目录下；

将所述第一SDK的当前解压目录下的文件进行打包，得到第一合并SDK的aar包，其中，所述第一SDK的当前解压目录下的文件包括：所述第一jar包、所述第三jar包和所述合并资源文件；

其中，对于所述当前SDK组合，当所述第一个基础SDK为所述第一SDK时，所述第二个基础SDK为所述第二SDK，所述第一个合并SDK为所述第一合并SDK；当所述第i个基础SDK为所述第一SDK时，所述第j个合并SDK为所述第二SDK，所述第j+1个合并SDK为所述第一合并SDK。

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

为所述至少一个合并SDK分别设置唯一标识；

向所述目标资源需求方提供所述至少一个合并SDK的唯一标识与所述至少一个合并SDK所能实现的功能的对应关系，以使所述目标资源需求方根据所述对应关系选择与自身业务需求匹配的所述目标合并SDK。

3.根据权利要求2所述的方法，其特征在于，在所述为所述至少一个合并SDK分别设置唯一标识前，所述方法还包括：

为所述多个基础SDK设置唯一标识；

向所述目标资源需求方提供合并得到所述目标合并SDK的基础SDK的唯一标识，以供所述目标资源需求方明确合并得到所述目标合并SDK的基础SDK；

其中，所述为所述至少一个合并SDK分别设置唯一标识，包括：

对于所述至少一个合并SDK中的任一合并SDK，确定合并得到该合并SDK的全部基础SDK的唯一标识；

基于所述全部基础SDK的唯一标识，确定该合并SDK的唯一标识。

4.根据权利要求3所述的方法，其特征在于，所述全部基础SDK的唯一标识是数值型的，所述基于所述全部基础SDK的唯一标识，确定该合并SDK的唯一标识，包括：

对所述全部基础SDK的唯一标识进行求和，得到该合并SDK的唯一标识。

5.根据权利要求2-4任一项所述的方法，其特征在于，所述向所述至少一个资源需求方提供所述至少一个合并SDK，包括：

将所述至少一个合并SDK发布到预设服务器上，并针对所述至少一个合并SDK分别生成下载链接；

分别建立所述至少一个合并SDK的唯一标识与下载链接的对应关系；

向所述目标资源需求方提供所述对应关系，以使所述目标资源需求方基于所述对应关系查找所述目标合并SDK的下载链接，并下载所述目标合并SDK。

6.根据权利要求1所述的方法，其特征在于，在所述对所述多个基础SDK进行组合得到至少一个SDK组合后，在所述对所述至少一个SDK组合中的基础SDK分别进行合并前，所述方法还包括：

确定所述至少一个SDK组合中的每一个SDK组合中是否存在互斥SDK；

若存在，则从所述至少一个SDK组合中删除该个SDK组合。

7.根据权利要求1所述的方法，其特征在于，在所述对所述多个基础SDK进行组合得到至少一个SDK组合后，在所述对所述至少一个SDK组合中的基础SDK分别进行合并前，所述方法还包括：

确定所述至少一个SDK组合中的每一个SDK组合中是否存在依赖SDK；

若存在，将所述依赖SDK添加至该个SDK组合中。

8.一种资源提供装置，其特征在于，所述装置包括：

资源组合模块，用于基于至少一个资源需求方的业务需求，对所述多个基础SDK进行组合得到至少一个SDK组合，其中，一个SDK组合中包含至少一个基础SDK，且一个SDK组合中的至少一个基础SDK含有资源，一个SDK组合用于实现一种业务需求下的至少一种预设功能；

资源提供模块，用于向所述至少一个资源需求方提供所述至少一个合并SDK，以使目标资源需求方通过接入目标合并SDK实现自身业务所需的至少一种预设功能，其中，所述目标资源需求方为所述至少一个资源需求方中的一个，所述目标合并SDK为所述至少一个合并SDK中的一个；

所述资源合并模块中，对所述至少一个SDK组合中的基础SDK分别进行合并，得到至少一个合并SDK，包括：

其中，所述第一指定步骤包括：

从所述当前SDK组合中取出第一个基础SDK；

判断所述当前SDK组合中剩余的基础SDK数量是否为0；

若为否，从所述当前SDK组合中取出第二个基础SDK；

其中，所述第二指定步骤包括：

判断所述当前SDK组合中剩余的基础SDK数量是否为0；

对所述第一SDK进行解压，得到第一资源文件和第一jar包；

对所述第二SDK进行解压，得到第二资源文件和第二jar包；

将修改后的所述java文件进行打包，得到第三jar包；

将所述第三jar包拷贝到所述第一SDK的解压目录下；