软件开发工具包的插件化处理方法、装置及电子设备

技术领域

本申请涉及计算机技术中的云计算和芯片，尤其涉及一种软件开发工具包的插件化处理方法、调用方法、装置、电子设备、存储介质、程序产品、以及终端设备。

背景技术

随着移动应用技术的快速发展，为了推广产品及服务，会对第三方的开发者提供软件开发工具包(Software Development Kit，SDK)，插件化的SDK可以被应用程序(Application，App)调用。

在现有技术中，对SDK的插件化方法包括：对SDK内部实现部分功能模块插件化并动态加载。

然而，对SDK内部实现部分功能模块插件化的方法对技术能力要求较高，且可能存在通用性偏低和消耗成本偏高的问题。

发明内容

本申请提供了一种用于提高SDK插件化的软件开发工具包的插件化处理方法、调用方法、装置、电子设备、存储介质、程序产品、以及终端设备。

根据本申请的第一方面，提供了一种软件开发工具包的插件化处理方法，包括：

获取待处理的软件开发工具包SDK，并获取所述待处理的SDK的配置文件、以及所述待处理的SDK对外提供的调用接口的调用信息；

根据所述配置文件确定所述待处理的SDK的实现类，并根据所述实现类和所述待处理的SDK，生成部署于云端的SDK插件，其中，所述实现类表征实现所述配置文件中每一调用接口所指示的内容；

根据所述调用信息和所述待处理的SDK，生成静态SDK，并对所述静态SDK和预设的插件化框架进行打包处理，得到部署于客户端的客户端总成SDK；其中，所述SDK插件和所述客户端总成SDK组成了插件化的SDK。

根据本申请的第二方面，提供了一种插件化的软件开发工具包的调用方法，包括：

获取调用请求，其中，所述调用请求指示调用插件化的软件开发工具包SDK，所述插件化的SDK是基于权利要求1-10中任一项所述的方法所生成的，所述插件化的SDK中包括SDK插件和客户端总成SDK；

若根据所述调用请求确定本地不具有所述SDK插件，则运行所述客户端总成SDK中的静态SDK。

根据本申请的第三方面，提供了一种软件开发工具包的插件化处理装置，包括：

第一获取单元，用于获取待处理的软件开发工具包SDK，并获取所述待处理的SDK的配置文件、以及所述待处理的SDK对外提供的调用接口的调用信息；

确定单元，用于根据所述配置文件确定所述待处理的SDK的实现类；

第一生成单元，用于根据所述实现类和所述待处理的SDK，生成部署于云端的SDK插件，其中，所述实现类表征实现所述配置文件中每一调用接口所指示的内容；

第二生成单元，用于根据所述调用信息和所述待处理的SDK，生成静态SDK；

打包单元，对所述静态SDK和预设的插件化框架进行打包处理，得到部署于客户端的客户端总成SDK；其中，所述SDK插件和所述客户端总成SDK组成了插件化的SDK。

根据本申请的第四方面，提供了一种插件化的软件开发工具包的调用装置，包括：

第二获取单元，用于获取调用请求，其中，所述调用请求指示调用插件化的软件开发工具包SDK，所述插件化的SDK是基于权利要求1-10中任一项所述的方法所生成的，所述插件化的SDK中包括SDK插件和客户端总成SDK；

运行单元，用于若根据所述调用请求确定本地不具有所述SDK插件，则运行所述客户端总成SDK中的静态SDK。

根据本申请的第五方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面所述的方法；或者，

以使所述至少一个处理器能够执行第二方面所述的方法。

根据本申请的第六方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面所述的方法；或者，

所述计算机指令用于使所述计算机执行第二方面所述的方法。

根据本申请的第七方面，提供了一种计算机程序产品，所述程序产品包括：计算机程序，所述计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得电子设备执行第一方面或者第二方面所述的方法。

根据本申请的第八方面，提供了一种终端设备，包括如第五方面所述的电子设备。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请第一实施例的示意图；

图2是根据本申请第二实施例的示意图；

图3是根据本申请第三实施例的示意图；

图4是可以实现本申请实施例的插件化的软件开发工具包的调用方法的场景图；

图5是根据本申请第四实施例的示意图；

图6是根据本申请第五实施例的示意图；

图7是根据本申请第六实施例的示意图；

图8为本申请实施例的插件化的SDK的结构示意图；

图9是用来实现本申请实施例的软件开发工具包的插件化处理方法或者插件化的软件开发工具包的调用方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

软件开发工具包SDK一般是指为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具，为了便于应用程序App的调用，可以对SDK进行插件化处理，得到插件化的SDK。

在相关技术中，通常可以采用两种方法对SDK进行插件化处理。

其中，一种方式为：对SDK内部实现部分功能模块插件化并动态加载。

然而，采用该方法对SDK进行插件化处理，相对而言，需要基于功能对SDK内部实现进行分析，相对研发成本偏高，且要求具有较高的技术能力，且由于是针对部分功能模型的插件化处理，因此通用性相对偏低。

另一种方式为：对SDK整体进行插件化处理，并通过桥接的方式供App集成。

然而，采用该方法对SDK进行插件化处理，受到外部集成方式的限定，App只能通过调用桥接而调用插件化的SDK，且采用该方法得到的插件化的SDK无法提供其他集成方式。

为了解决上述问题中的至少一种，本申请的发明人经过创造性地劳动，得到了本申请的发明构思：基于实现类生成部署于云端的SDK插件，基于调用信息生成静态SDK，并基于静态SDK和插件化框架得到客户端总成SDK，从而实现对SDK的插件化处理，插件化的SDK包括SDK插件和客户端总成SDK。

基于上述发明构思，本申请提供一种软件开发工具包的插件化处理方法，应用于计算机技术领域中的云计算和芯片，以达到SDK插件化处理的通用性。

图1是根据本申请第一实施例的示意图，如图1所示，本申请实施例的软件开发工具包的插件化处理方法，包括：

S101：获取待处理的软件开发工具包SDK，并获取待处理的SDK的配置文件、以及待处理的SDK对外提供的调用接口的调用信息。

示例性地，本实施例的执行主体可以为软件开发工具包的插件化处理装置(下文简称处理装置)，处理装置可以为服务器(可以为云端服务器，也可以为本地服务器)，也可以为终端设备，也可以为处理器，也可以为芯片等，本实施例不做限定。

示例性地，配置文件可以理解为计算机文件，如可以为一些计算机程序配置参数和初始设置信息。

也就是说，在本实施例中，配置文件可以包括：SDK的计算机程序配置参数、SDK的初始化信息、用于实现SDK的功能的信息、以及SDK可以实现的功能的信息，等等。

调用信息可以理解为App通过调用接口对插件化的SDK进行调用时，与调用接口相关的信息，如怎样实现对插件化的SDK的调用的信息。

S102：根据配置文件确定待处理的SDK的实现类，并根据实现类和待处理的SDK，生成部署于云端的SDK插件。

其中，实现类表征实现配置文件中每一调用接口所指示的内容。

示例性地，该步骤可以理解为：处理装置基于配置文件，得到所有需要实现的调用接口(Interface)，并针对每一调用接口，生成与该每一调用接口对应的实现类。

S103：根据调用信息和待处理的SDK，生成静态SDK。

示例性地，处理装置可以基于调用信息对SDK进行编译等处理，得到静态SDK。

S104：对静态SDK和预设的插件化框架进行打包处理，得到部署于客户端的客户端总成SDK。

其中，SDK插件和客户端总成SDK组成了插件化的SDK。

需要说明地是，关于S102与S103之间的执行顺序，本实施例不做限定，也就是说，一个示例中，处理装置可以优先生成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插件化的技术门槛和研发成本，且降低了App集成插件化的SDK的集成难度和研发成本，实现了提高SDK的插件化的通用性的技术效果。

图2是根据本申请第二实施例的示意图，如图2所示，本申请实施例的软件开发工具包的插件化处理方法，包括：

S201：获取待处理的软件开发工具包SDK，并获取待处理的SDK的配置文件、以及待处理的SDK对外提供的调用接口的调用信息。

示例性地，关于S201地描述，可以参见S101，此处不再赘述。

S202：根据配置文件，确定实现配置文件中每一调用接口所指示的内容的实现逻辑。

其中，配置文件用于指示出待处理的SDK所需的各实现类，实现类表征实现配置文件中每一调用接口所指示的内容。

示例性地，在本实施例中，由于配置文件用于指示出待处理的SDK所需的各实现类，在若处理装置获取到配置文件，则可以基于配置文件确定待处理的SDK所需的各实现类，而实现类可以理解为实现配置文件中的每一调用接口所指示的内容，则处理装置可以基于配置文件确定每一调用接口所指示的内容。

相应地，处理装置若基于配置文件确定每一调用接口所指示的内容，则可以基于每一调用接口所指示的内容确定与每一调用接口所指示的内容对应的实现逻辑。

S203：根据各实现逻辑对待处理的SDK进行插入处理，生成与各实现逻辑各自对应的实现类。

在该步骤中，处理装置可以对待处理的SDK进行插入处理等，从而得到与每一实现逻辑各自对应的实现类。

值得说明地是，在本实施例中，处理装置通过基于配置文件确定各实现逻辑，并基于各实现逻辑进行插入等处理，得到每一实现逻辑各自对应的实现类，可以提高生成的实现类的准确性和可靠性的技术效果。

在一些实施例中，S203可以包括：针对每一调用接口所指示的内容的实现逻辑，将每一调用接口所指示的内容的实现逻辑插入至待处理的SDK，得到与每一调用接口所指示的内容的实现逻辑对应的实现类。

值得说明地是，在本实施例中，处理装置针对各个调用接口所指示的内容的实现逻辑，在待处理的SDK的基础上对各个调用接口所指示的内容的实现逻辑进行插入处理，从而得到各个调用接口各自对应的实现类，可以实现提高生成SDK的实现类的可靠性和准确性的技术效果。

在一些实施例中，在上述实施例中从插入处理的基础上，S203具体可以包括如下步骤

步骤1：确定每一调用接口所指示的内容的实现逻辑对应的字节码。

示例性地，处理装置可以基于任意调用接口所指示的内容的实现逻辑，确定与该任意调用接口所指示的内容的实现逻辑对应的字节码(如包含执行程序的二进制文件)。

步骤2：基于每一调用接口所指示的内容的实现逻辑对应的字节码对待处理的SDK进行字节码插桩处理，生成与每一调用接口所指示的内容的实现逻辑对应的实现类。

值得说明地是，在本实施例中，引入了处理装置基于字节码插桩技术生成相应的实现类的特征，通过基于字节码插桩技术生成实现类，可以避免相关技术中采用编写代码地方式造成的智能化偏低的问题，实现了插入处理的自动化和智能化，且便于后续调整和修改，提高了生成实现类的效率的技术效果。

在一些实施例中，步骤2可以包括如下子步骤：

子步骤1：根据配置文件确定每一调用接口所指示的内容的实现逻辑的字节码在待处理的SDK的插入位置。

基于上述分析可知，配置文件用于指示出待处理的SDK所需的各实现类，且实现类表征实现配置文件中每一调用接口所指示的内容，因此，处理装置可以基于配置文件对插入位置进行确定，以便得到准确性和可靠性较高的实现类。

子步骤2：采用预设插桩接口将每一调用接口所指示的内容的实现逻辑的字节码插入至与每一调用接口所指示的内容的实现逻辑的字节码在待处理的SDK的插入位置，生成与每一调用接口所指示的内容的实现逻辑对应的实现类。

其中，该步骤可以理解为，处理装置可以基于在确定出的插入位置插入字节码，从而得到实现类。

值得说明地是，在本实施例中，处理装置通过先确定插入位置，而后基于插入位置执行字节码插桩处理，从而生成实现类，可以提高生成的实现类的准确性和可靠性的技术效果。

S204：根据实现类和待处理的SDK，生成部署于云端的SDK插件。

其中，待处理的SDK中包括jar包，在一些实施例中，S204可以包括如下步骤：

步骤1：将实现类插入至jar包中，得到新的jar包。

步骤2：根据新的jar包和待处理的SDK，生成SDK插件。

值得说明地是，在本实施例中，通过将基于实现类和jar得到SDK插件，提高了生成的SDK插件的可靠性和完整性的技术效果。

在一些实施例中，待处理的SDK中包括动态连接库和进程文件，进程文件中包括资源文件，步骤2可以包括如下子步骤：

子步骤1：将新的jar包和资源文件打包成应用程序包。

子步骤2：将应用程序包、动态连接库、以及进程文件中除去资源文件以外的文件进行打包处理，得到SDK插件。

值得说明地是，在本实施例中，通过将新的jar和资源文件打包成应用程序包，并在此基础上，结合动态连接库、进程文件中除去资源文件以外的文件生成SDK插件，可以使得SDK插件的具有完整性和全面性，从而实现得到的插件化的SDK的准确性和可靠性的技术效果。

S205：在待处理的SDK对外提供的调用接口中插入调用信息，得到静态SDK。

值得说明地是，在本实施例中，通过在对外提供的调用接口中插入调用信息，可以使得生成的静态SDK具有较高的对外调用性能，提高得到的静态SDK的可靠性的技术效果。

在一些实施例中，S205可以包括如下步骤：

步骤1：确定调用信息对应的调用逻辑。

步骤2：在待处理的SDK对外提供的调用接口中插入调用逻辑，得到静态SDK。

值得说明地是，在本实施例中，通过确定调用逻辑，并对调用逻辑进行插入，得到静态SDK，可以使得静态SDK与调用信息之间的高度关联，从而提高静态SDK的准确性和可靠性的技术效果。

在一些实施例中，S205可以具体包括：确定调用逻辑对应的代理代码，并基于代理代码对待处理的SDK对外提供的调用接口进行字节码插桩处理，得到静态SDK。

同理，在本实施例中，通过字节码插桩技术生成静态SDK，可以提高生成静态SDK的智能化和自动化，且实现了节约编码资源，提高生成静态SDK的效率和可靠性的技术效果。

在一些实施例中，可以包括多个维度的调用逻辑，如包括八个维度的调用逻辑，即待处理的SDK对外提供的调用接口可以实现八种功能。

其中，八种功能可以分别为：SDK初始化功能；供外部静态调用的类及其静态功能；供外部实例化的类以及这些类的对应功能；需要外部获取其实例的类，获取该类实例的功能，以及这些实例需要使用的功能；需要用户实现的调用接口类和将这些调用接口传递给其他类的功能；枚举类，以及需要传递枚举值的功能；需要外部写入到布局(Layout)中的自定义视图(View)和视图群组(View Group)的功能；需要注册到Manifest中的组件的功能。

值得说明地是，上述八种功能只是用于示范性地说明插件化的SDK可能实现的功能，而不能理解为对功能地限定。

现针对上述八种功能，示范性地描述每一种功能对应的实现(即相应地调用逻辑)。示例性地，SDK初始化功能的实现如下：

初始化插件化框架，然后调用插件化框架方法检查当前是否有可用SDK插件，若是，则标记为SDK插件运行，若否，则标记为静态SDK运行。如果是SDK插件运行，则通过插件化框架调用SDK插件的同一实现类类名的同一方法，否则插入调用逻辑结束，开始执行该初始化方法的静态调用逻辑。

示例性地，供外部静态调用的类及其静态功能的实现如下：

判断本次是否为SDK插件化运行，若是，通过插件化框架调用SDK插件的同一实现类类名的同一方法，否则插入调用逻辑结束，开始执行该初始化方法的静态调用逻辑。

示例性地，供外部实例化的实现类以及这些实现类的对应功能的实现如下：

在实现类中插入一个基类(Object类)声明的全局变量(mInnerInstance)，用于保存SDK插件内的该实现类的实例。在该实现类的构造方法中，若本次为SDK插件化运行，则通过插件化框架调用SDK插件的同一实现类类名的同一参数类型的构造方法，获取到基类，并存放于全局变量。

在一些实施例中，若本次为SDK插件运行，通过插件化框架调用全局变量的同一方法，并将获取到的返回值返回。否则插入调用逻辑结束，开始执行该初始化方法的静态调用逻辑。

在一些实施例中，若本次为SDK插件运行，则在调用SDK插件同一实现类类名统一方法时，需要取出本实现类的全局变量作为参数，而不能直接使用SDK插件外的本实现类的实例。

示例性地，需要外部获取其实例的类，获取该类实例的功能，以及这些实例需要使用的功能的实现如下：

若是插件化运行，首先会反射调用SDK插件内同一实现类名的同一方法，获取到SDK插件内的该实现类的实例，此时可以实例化一个在外部定义的该实现类的实例，并将从SDK插件内获取到的实例赋值给全局变量，然后将外部定义的实现类的实例返回。

示例性地，需要用户实现的调用接口类和将这些调用接口传递给其他类的功能的实现如下：

外部App实现调用接口可以通过外部定义实现，这种调用接口的实例与SDK插件内的同名调用接口定义无法通用，则需要SDK插件插入时自动生成一个该调用接口的实现类，与外部共同实现。

SDK插件内部实现类可以具有一个基类的函数全局变量(mCallBackImpl)，同时提供一个参数为基类的构造方法，将传入的基类赋值给函数全局变量。该实现类的回调方法被调用时，反射调用函数全局变量的对应方法，以将回调传出给外部实现。

外部传递调用接口实现类实例的方法，若当前为插件化运行，应当反射创建一个SDK插件内实现类的实例并传入外部实现类，然后使用该SDK插件内实现类的实例调用插件内的传递调用接口实现类实例的方法。

示例性地，枚举类，以及需要传递枚举值的功能的实现如下：

插件化框架提供一个枚举值转换方法，可以将插件化框架外部定义的枚举值，转化为插件化框架内部定义的枚举值。该枚举值转化后为基类的对象，且可以不赋值给外部插件化框架。

在一些实施例中，若当前为插件化运行，该方法内部在调用插件方法，使用枚举值时，应先调用转化方法，将该外部枚举值转化为内部枚举值。反射调用需要声明类型时，可直接使用转化后的枚举值获取枚举类(Class)定义，或使用插件化框架的加载插件内的实现类的方法，加载与外部枚举同名的插件内的枚举类。

示例性地，需要外部写入到布局中的自定义视图和视图群组的功能的实现如下：

外部集成视图群组可以包括：通过布局文件集成和生成新的对象集成。

其中，通过布局文件集成可以采用参数为上下文(Context)，属性组(AttributeSet)的构造方法。

通过生成新的对象集成可以通过插件化框架调用SDK插件内统一视图群组的同一构造方法，在SDK插件内视图群组构造后，将其所有子群组(Children)复制到外部视图群组中，并替换这些子群组的父群组(Parent)为外部视图群组。

该实现类的其他公用方法被调用时，需要先将所有参数从外部复制到内部，反射调用内部同一方法，然后再将所有参数从内部复制到外部。此调用方式称为双向同步。

其中，SDK插件的上下文支持主要目的是让SDK插件可以通过上下文直接访问插件化的SDK的自身的资源文件，且与App的资源文件隔离。

上下文支持的方法包括三种，分别为：基础上下文(Base Context)、应用上下文(Application Context)、实时公共上下文(Context Wrapper)。

示例性地，关于基础上下文地理解如下：

基础上下文可以用于生成应用上下文，可以支持读取系统资源函数(getResources/get Assets)方法，且可以用于生成时尚未产生SDK插件的应用上下文对象。

示例性地，应用上下文地理解如下：

应用上下文是SDK插件实际使用的上下文，可以与宿主上下文隔离。例如，可以通过应用上下文获取主线程对象(Activity Thread)，然后获取成员变量(Instrumentation)，调用新应用程序(new Applicaiton)方法，通过基础上下文创建一个活跃的应用程序对象。此应用程序对象是插件实际使用的上下文，该应用程序的读取系统资源函数方法会调用到基础上下文的，因此可以访问SDK插件的资源，而读取系统资源函数方法会返回其自身，达到与宿主上下文的隔离。

其中，可以将上下文作为替换对象，执行字节码插桩技术。

示例性地，关于实时公共上下文地理解如下：

实时公共上下文访问SDK插件的资源。在实时公共上下文创建时，可以通过传入插件的应用程序，让应用程序在读取系统资源函数方法中返回，以防止SDK插件内获取到宿主的上下文。

示例性地，需要注册到Manifest中的组件的功能的实现如下：

Manifest中的组件包括：用于基于如交互完成任务的活动组件(Activity)，用于声明服务的组件(Service)，用于声明广播接收器的组件(Receiver)，用于声明内容提供者的组件(Content Provider)四种，具体地注册原理可以参见上述描述以及相关技术中的实现原理，此处不再赘述。但是，需要说明地是，在本实施例中，是基于字节码插桩技术实现，而非如相关技术中基于编码代码的方式实现。

S206：对静态SDK和预设的插件化框架进行打包处理，得到部署于客户端的客户端总成SDK。

其中，SDK插件和所述客户端总成SDK组成了插件化的SDK。

图3是根据本申请第三实施例的示意图，如图3所示，本申请实施例的插件化的软件开发工具包的调用方法，包括：

S301：获取调用请求。

其中，调用请求指示调用插件化的软件开发工具包SDK，插件化的SDK是基于第一实施例或者第二实施例所述的方法所生成的，插件化的SDK中包括SDK插件和客户端总成SDK。

示例性地，本实施例的执行主体可以为插件化的软件开发工具包的调用装置(下文简称调用装置)，调用装置可以与处理装置为相同的装置，也可以为与处理装置不同的装置，本实施例不做限定。

S302：若根据调用请求确定本地不具有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插件时，自动触发向云端发起更新请求，等等，此处不再一一列举。

示例性地，本实施例的插件化的软件开发工具包的调用方法可以适用于如图4所示的应用场景。

如图4所示，用户设备401可以部署有基于上述第一实施例或者第二实施例生成的客户端总成SDK，客户端静态SDK包括静态SDK和插件化框架。

云端402可以部署有基于上述第一实施例或者第二实施例生成的SDK插件。

用户403可以通过用户设备401运行插件化的SDK。例如，若插件化的SDK为地图的SDK，则用户403可以向用户设备401发起调用地图的SDK的请求。

其中，用户403可以通过语音或者触屏的方式向用户设备401发起调用地图的SDK的请求，本实施例不做限定。

相应地，用户设备401可以接收由用户403发起的调用地图的SDK的请求。

用户设备401判断本地是否存储有地图的SDK插件，如果没有，则运行本地存储的客户端总成SDK中的地图的静态SDK；如果有，则运行地图的SDK插件。

图5是根据本申请第四实施例的示意图，如图5所示，本申请实施例的软件开发工具包的插件化处理装置500，包括：

第一获取单元501，用于获取待处理的软件开发工具包SDK，并获取待处理的SDK的配置文件、以及待处理的SDK对外提供的调用接口的调用信息。

确定单元502，用于根据配置文件确定所述待处理的SDK的实现类。

第一生成单元503，用于根据实现类和待处理的SDK，生成部署于云端的SDK插件，其中，实现类表征实现配置文件中每一调用接口所指示的内容。

第二生成单元504，用于根据调用信息和待处理的SDK，生成静态SDK。

打包单元505，用于对静态SDK和预设的插件化框架进行打包处理，得到部署于客户端的客户端总成SDK。

其中，SDK插件和客户端总成SDK组成了插件化的SDK。

图6是根据本申请第五实施例的示意图，如图6所示，本申请实施例的软件开发工具包的插件化处理装置600，包括：

第一获取单元601，用于获取待处理的软件开发工具包SDK，并获取待处理的SDK的配置文件、以及待处理的SDK对外提供的调用接口的调用信息。

确定单元602，用于根据配置文件确定所述待处理的SDK的实现类。

结合图6可知，在一些实施例中，确定单元602包括：

第一确定子单元6021，用于根据配置文件，确定实现配置文件中每一调用接口所指示的内容的实现逻辑。

第一生成子单元6022，用于根据各实现逻辑对待处理的SDK进行插入处理，生成与各实现逻辑各自对应的实现类。

在一些实施例中，第一生成子单元6022用于，针对每一调用接口所指示的内容的实现逻辑，将每一调用接口所指示的内容的实现逻辑插入至待处理的SDK，得到与每一调用接口所指示的内容的实现逻辑对应的实现类。

在一些实施例中，第一生成子单元6022，包括：

确定模块，用于确定每一调用接口所指示的内容的实现逻辑对应的字节码。

插桩模块，用于基于每一调用接口所指示的内容的实现逻辑对应的字节码对待处理的SDK进行字节码插桩处理，生成与每一调用接口所指示的内容的实现逻辑对应的实现类。

在一些实施例中，插桩模块包括：

确定子模块，用于根据配置文件确定每一调用接口所指示的内容的实现逻辑的字节码在待处理的SDK的插入位置。

插入子模块，用于采用预设插桩接口将每一调用接口所指示的内容的实现逻辑的字节码插入至与每一调用接口所指示的内容的实现逻辑的字节码在待处理的SDK的插入位置，生成与每一调用接口所指示的内容的实现逻辑对应的实现类。

第一生成单元603，用于根据实现类和待处理的SDK，生成部署于云端的SDK插件，其中，实现类表征实现配置文件中每一调用接口所指示的内容。

结合图6可知，在一些实施例中，待处理的SDK中包括jar包；第一生成单元603，包括：

第一插入子单元6031，用于将实现类插入至jar包中，得到新的jar包。

第二生成子单元6032，用于根据新的jar包和待处理的SDK，生成SDK插件。

在一些实施例中，待处理的SDK中包括动态连接库和进程文件，进程文件中包括资源文件；第二生成子单元6032，包括：

第一打包模块，用于将新的jar包和资源文件打包成应用程序包。

第二打包模块，用于将应用程序包、动态连接库、以及进程文件中除去资源文件以外的文件进行打包处理，得到SDK插件。

在一些实施例中，第二生成子单元6032用于，在待处理的SDK对外提供的调用接口中插入调用信息，得到静态SDK。

第二生成单元604，用于根据调用信息和待处理的SDK，生成静态SDK。

结合图6可知，在一些实施例中，第二生成单元604，包括：

第二确定子单元6041，用于确定调用信息对应的调用逻辑。

第二插入子单元6042，用于在待处理的SDK对外提供的调用接口中插入调用逻辑，得到静态SDK。

在一些实施例中，第二生成单元604用于，确定调用逻辑对应的代理代码，并基于代理代码对所述待处理的SDK对外提供的调用接口进行字节码插桩处理，得到静态SDK。

打包单元605，用于对静态SDK和预设的插件化框架进行打包处理，得到部署于客户端的客户端总成SDK。

其中，SDK插件和客户端总成SDK组成了插件化的SDK。

图7是根据本申请第六实施例的示意图，如图7所示，本申请实施例的插件化的软件开发工具包的调用装置700，包括：

第二获取单元701，用于获取调用请求，其中，调用请求指示调用插件化的软件开发工具包SDK，插件化的SDK是基于第一实施例或者第二实施例所述的方法所生成的，插件化的SDK中包括SDK插件和客户端总成SDK。

运行单元702，用于若根据调用请求确定本地不具有SDK插件，则运行客户端总成SDK中的静态SDK。

在一些实施例中，运行单元702用于，若根据调用请求确定本地具有SDK插件，则运行SDK插件。

在一些实施例中，客户端总成SDK中还包括插件化框架，插件化框架用于完成静态SDK的初始化。

示例性地，图8为本申请实施例的插件化的SDK的结构示意图。

如图8所示，插件化的SDK包括：

部署于云端的SDK插件801和部署于客户端的客户端总成SDK802，其中，客户端总成SDK802包括：静态SDK8021和插件化框架8022。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

根据本申请的实施例，本申请还提供了一种计算机程序产品，程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。

图9示出了可以用来实施本申请的实施例的示例电子设备900的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图9所示，电子设备900包括计算单元901，其可以根据存储在只读存储器(ROM)902中的计算机程序或者从存储单元908加载到随机访问存储器(RAM)903中的计算机程序，来执行各种适当的动作和处理。在RAM 903中，还可存储设备900操作所需的各种程序和数据。计算单元901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

设备900中的多个部件连接至I/O接口905，包括：输入单元906，例如键盘、鼠标等；输出单元907，例如各种类型的显示器、扬声器等；存储单元908，例如磁盘、光盘等；以及通信单元909，例如网卡、调制解调器、无线通信收发机等。通信单元909允许设备900通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元901可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元901的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元901执行上文所描述的各个方法和处理，例如软件开发工具包的插件化处理方法或者插件化的软件开发工具包的调用方法。例如，在一些实施例中，软件开发工具包的插件化处理方法或者插件化的软件开发工具包的调用方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元908。在一些实施例中，计算机程序的部分或者全部可以经由ROM 902和/或通信单元909而被载入和/或安装到设备900上。当计算机程序加载到RAM 903并由计算单元901执行时，可以执行上文描述的软件开发工具包的插件化处理方法或者插件化的软件开发工具包的调用方法的一个或多个步骤。备选地，在其他实施例中，计算单元901可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行软件开发工具包的插件化处理方法或者插件化的软件开发工具包的调用方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

根据本申请实施例的另一个方面，本申请实施例还提供了一种终端设备，包括如上实施例所述的电子设备。

一个示例中，终端设备可以为用户设备，如终端设备可以为如图4中所示的手机，当然，终端设备还可以为其他用户设备，如台式电脑、笔记本电脑、以及掌上电脑等。

另一个示例中，终端设备也可以为服务器，且可以为本地服务器，也可以为云端服务器。

值得说明地是，上述示例只是用于示范性地说明，本实施例的终端设备可能的类型，而不能理解为对终端设备的限定。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。