CN107122200A - 加载插件sdk的方法、系统及客户端 - Google Patents

Abstract

本发明涉及一种加载插件SDK的方法和系统及客户端。该加载插件SDK的方法，包括以下步骤：获取当前应用的至少一个更新的插件SDK；当重新启动当前应用时，对每个所述更新的插件SDK执行动态加载的步骤；动态加载的步骤包括：将更新的插件SDK的代码与当前应用的代码合并；将更新的插件SDK的本地库与当前应用的本地库合并；将更新的插件SDK的资源与当前应用的资源合并。上述的加载插件SDK的方法和系统及客户端，能够实现功能软件开发与应用的解耦，使得应用更加高效和安全。

Description

加载插件SDK的方法、系统及客户端

技术领域

本发明涉及智能终端技术领域，特别是涉及一种加载插件SDK的方法、系统及客户端。

背景技术

目前应用接入第三方SDK(Software Development Kit，软件开发工具包)的主要方式是应用直接硬编码静态加载第三方SDK。而静态加载第三方SDK是在应用发布时，将应用本身的逻辑和第三方SDK的代码、资源合并在一个apk(Android Package，Android安装包)发布到应用市场。一旦发布，这个apk将无法修改，apk封装的第三方SDK也无法修改，如果第三方SDK出现bug(问题)时，或者，当第三方SDK升级时，需要将应用原始工程与更新的第三方SDK重新融合形成新的apk再发布。这种方式中，功能软件开发与应用的耦合性较高，操作较为复杂，使得无法及时修复bug。并且，当第三方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的方法、系统和客户端，客户端(宿主apk)在重新启动应用时动态加载更新的插件SDK，即将插件SDK的代码、本地库和资源分别对应地与当前应用的代码、本地库和资源合并。通过这种动态加载的方式，使得插件SDK和应用程序包解耦，使得可以独立开发插件SDK，解决了由于第三方SDK频繁升级导致频繁升级客户端的问题，而且有效减小了应用程序包的大小，同时提高了应用的安全性。

附图说明

图1为一些实施例中的加载插件SDK的方法的流程图；

图2为一些实施例中的获取更新的插件SDK的过程示意图；

图3为一些实施例中的统一接口SDK的示意图；

图4为一些实施例中的加载插件SDK的系统的结构框图。

具体实施方式

在本发明的实施例中，所述的客户端为以Android为开发平台的智能移动终端。Android SDK(Software Development Kit，软件开发工具包)采用了Java语言。一般SDK都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。软件开发工具包广义上指辅助开发某一类软件的相关文档、范例和工具的集合。

在Android平台而言，Android SDK是指由非CP(content provider，内容提供商，例如应用程序开发商)方提供的具有某种特定功能(比如登录、支付、推送、分享等等)的开发包，CP方可以通过编码和整合文件资源等方式集成第三方SDK，从而具备第三方SDK提供的某种功能和/或使用场景。通常情况下，Android SDK采用Java语言编写。第三方SDK类型很多，一般从开发角度看，根据插件SDK提供的功能进行分类，当前市场主流的类型包括但不限于登录、支付、分享、推送、广告、统计等。

将第三方SDK进行封装形成插件SDK，一个插件SDK封装了一个第三方SDK或者某种特定功能，二者一一对应，即插件SDK是在第三方SDK提供的代码和资源的基础上，按照接入的需要进行封装，最后以apk(Android Package，Android安装包)的形式发布。需要说明的是，在一些实施例中，插件SDK可以为独立的.apk文件和.dex文件或者具有dalvik字节码的jar包。

在客户端的使用过程中，由于第三方SDK频繁升级或者服务器对特定渠道或者个人定制app的强制推送插件SDK，使得客户端需要频繁升级。但是目前的静态加载第三方SDK的方式是将应用程序本身的逻辑和第三方SDK的代码和资源合并在一个apk发布到应用市场。一旦发布，这个apk将无法修改，apk封装的第三方SDK也无法修改，如果第三方SDK出现bug(问题)将无法及时修复，并且，采用这种方式频繁升级客户端，操作复杂，维护不便。因此本发明提出一种加载插件SDK的方法，该方法能够动态加载各种类型的第三方SDK，实现了插件SDK和应用程序包解耦，使得第三方SDK频繁升级导致的频繁升级客户端的操作变得简单、方便，同时减小应用程序包的大小，动态扩展其他功能，从而提高用户体验。

在一些实施例中，如图1所示，提出一种加载插件SDK的方法，该方法包括以下步骤：

步骤102，获取当前应用的至少一个更新的插件SDK。

在一些实施例中，插件SDK可以为独立的.apk文件和.dex文件或者具有dalvik字节码的jar包。插件SDK封装了第三方SDK或者某种特定功能。当前应用可更新的第三方SDK可能有一个或多个，一个第三方SDK或者某种特定功能封装在一个插件SDK中。

更新的插件SDK存储于服务器中。

在一些实施例中，步骤102获取当前应用的至少一个更新的插件SDK具体包括：

向服务器发送更新当前应用的插件SDK的请求，并接收服务器下发的包含至少一个更新的插件SDK的SDK更新包；

将SDK更新包解压，获取至少一个更新的插件SDK。

如图2所示，获取当前应用的至少一个更新的插件SDK的步骤的具体实现过程如下：

S1，获取当前应用的应用标识及当前应用接入的第一SDK版本列表信息映射，并向服务器发送更新当前应用的插件SDK的请求。

在本实施例中，所述请求中包含客户端获取需要更新插件SDK的当前应用的应用标识。所述的应用标识可以为当前应用的名称、图标等。当前应用接入的第一SDK版本列表信息映射即为当前应用接入的SDK版本信息映射1。

服务器接收客户端发送的应用标识及其接入的SDK版本信息映射1，将应用标识及其接入的SDK版本信息映射1与服务器存储的该应用标识对应的第二SDK版本信息映射，即最新的SDK版本信息映射2进行对比，若存在版本更新，则将SDK版本信息映射2以Json字符串格式写入SDK列表配置文本(SDKListConfig.txt)，然后将SDK列表配置文本压缩进SDK更新包(SDKUpdate.zip)中。同时比较SDK版本信息映射1和SDK版本信息映射2，将新增的SDK和需更新的SDK对应的apk压缩进SDK更新包，并将SDKUpdate.zip下发给客户端。

S2，接收服务器下发的SDK更新包，并将SDK更新包进行解压，获取更新的插件SDK对应的解压文件，并根据解压文件获取SDK列表配置文本，并从SDK列表配置文本中读取第二SDK版本信息映射。

在本实施例中，客户端接收服务器下发的SDK更新包，即服务器存储的与当前应用对应的最近更新的SDKUpdate.zip包。

在本实施例中，根据解压当前应用对应的最近更新的SDKUpdate.zip包获取到的SDK列表配置文本(SDKListConfig.txt)，并从SDKListConfig.txt中读取第二SDK版本信息映射，即最近更新的SDK版本信息映射2。

S3，将第一SDK版本信息映射与第二SDK版本信息映射做比对，获取SDK表，其中，SDK表包含于第一SDK版本信息映射且不包含于第二SDK版本信息映射。

在本实施例中，将SDK版本信息映射2与客户端保存的当前应用接入的SDK版本信息映射1做比对，得到SDK版本信息映射1包含而SDK版本信息映射2不包含的SDK表。

S4，根据SDK表，删除客户端的本地缓存目录中存放插件SDK的安装目录下对应的SDK更新包，并将解压文件中的SDK更新包复制到安装目录。

根据所述SDK表删除本地缓存目录中存放插件SDK的apk的目录下对应的apk。将更新的插件SDK的SDKUpdate.zip包解压得到的所有插件SDK的SDK更新包(apk)文件复制到客户端的本地缓存目录中存放插件SDK的apks目录，如二者重复则直接替换。

另外，在一些实施例中，获取当前应用的至少一个更新的插件SDK的步骤具体为接收服务器推送的插件SDK。

本实施例中的服务器推送的插件SDK是指服务器对特定渠道或者个人定制用(app)强制推送的插件SDK。对于一些因外界因素必须更新的第三方SDK，将该第三方SDK插件化形成插件SDK后，服务器可以强制推送该插件SDK给客户端进行动态加载，避免业务的频繁变更而频繁、繁琐地升级客户端。

动态加载服务器强制推送的插件SDK的过程与本发明一些实施例的动态加载更新的插件SDK的步骤相同，具体可参见相应部分的实施例的描述，这里不再赘述。

步骤104，当重新启动当前应用时，对每个更新的插件SDK执行动态加载的步骤。

Android系统的应用程序是以.apk文件的形式发布，里面包含了java代码、资源、本地库lib等等。Android中的资源是指非代码部分，即外部文件。例如，assets中保存的一般是原生的文件，例如MP3文件，Android程序不能直接访问，必须通过资源管理器(AssetManager类)以二进制流的形式来读取。res中的资源可以通过R资源类直接访问。R资源类是自动生成的，在该类中根据不同的资源类型生成了相应的内部类，该类包含了系统中使用到的所有资源文件的标识。

Android系统中应用程序启动时，系统会以默认的类加载器PathClassLoader加载SDK更新包(apk)中的代码、资源和本地库(存储在客户端的对应于当前应用的代码库)等。通常情况下，应用程序启动的类加载器PathClassLoader只会加载应用程序的SDK更新包本身包含的java代码、资源和本地库(包括.lib文件)。因此要实现动态加载插件SDK或者jar(jar里面可以只是java代码dex，也可以包含资源等)，则需要将插件SDK中的代码、资源和本地库与宿主apk(当前应用)中的代码、资源和本地库合并到一起，使得插件SDK和应用程序无缝衔接，使得二者使用同一个上下文(应用程序的执行环境)。

动态加载更新的插件SDK的步骤包括：

步骤124，将更新的插件SDK的代码与当前应用的代码合并。

通过扩展系统的类加载器中的数组成员变量，便可将更新的插件SDK的代码与当前应用的代码合并。

具体的，在Android平台API小于14(即Android 4.0以下)时，直接将指定目录扩展附加到类加载器PathClassloader的mPaths、mFiles、mZips和mDexs数组成员中来实现代码整合。

当API大于或者等于14时，Android中所有的java代码均由类加载器加载，这里默认由类加载器PathClassloader来加载。扩展了类加载器PathClassloader后，就可以实现插件SDK的代码和当前应用的代码合并。例如，扩展系统的类加载器PathClassloader中的DexPathList对象的elements数组成员。

在本实施例中，API即Android Framework是Android系统版本的唯一标识。14为当前手机终端的Android系统API Level，系统代号为ICE_CREAM_SANDWICH，代指Android 4.0，4.0.1，4.0.2。

步骤144，将更新的插件SDK的本地库与当前应用的本地库合并。

在一些实施例中，将更新的插件SDK的本地库与当前应用的本地库合并的步骤包括：

通过反射类加载器，将更新的插件SDK的本地库lib路径添加到当前应用的本地库的加载路径中。

具体的，当API大于或者等于14时，将指定目录(例如/data/data/packages/Plugin/libs)扩展附加到系统类加载器PathClassloader中的DexPathList对象的nativeLibraryDirectories数据成员上，nativeLibraryDirectories成员主要用来标记存储本地库的加载目录。通过反射调用，将更新的插件SDK中的本地库(lib)中的so库路径添加到pathList对象中的nativeLibraryDirectories数据成员，扩充系统类加载器加载本地库的路径。

当API小于14时，则将指定目录扩展附加到类加载器PathClassloader的libraryPathElements的列表成员中来实现动态链接库的整合。在本实施例中，API即Android Framework是Android系统版本的唯一标识。14为当前手机终端的Android系统API Level，系统代号为ICE_CREAM_SANDWICH，代指Android 4.0,4.0.1,4.0.2。

步骤164，将更新的插件SDK的资源与当前应用的资源合并。

在一些实施例中，将更新的插件SDK的资源与当前应用的资源合并的步骤包括：

通过反射调用应用程序资源管理器的成员函数将解压文件中SDK更新包的资源加载到当前应用的资源对象中。

在本实施例中，即对插件SDK的资源进行整合，Android系统中对于资源(Resource)的管理，其实质是通过应用程序资源管理器(AssetManager)进行管理的。因此通过反射调用AssetManager的addAssetPath方法将一个apk的资源加载到Resources对象中，然后通过这个Resources便可以访问插件SDK的资源。

通过上述实施例描述的方式，可以实现动态加载更新的插件SDK。本发明实施例的加载插件SDK方法，将宿主apk(应用程序本身)与插件SDK中的逻辑独立开来，实现功能开发与宿主应用程序的解耦，各个插件SDK可以划分给不同的开发人员开发，并行进行。同时减小了应用程序安装包的大小。另外，由于Android应用程序大部分是通过java程序编写的，反编译java代码通常较易实现。如果将核心的逻辑放在应用程序(宿主apk)中，那么根据宿主apk，便可反编译并获取其代码逻辑。采用插件化的方式，将重要的某些功能放入插件SDK中，插件SDK存放在服务器的时候可以加密的，需要加载时再解密进行加载，这种方式较难通过反编译的方法获取到这部分的代码和资源。因此本发明实施例的加载插件SDK方法，还可以提高应用程序的安全性。

采用上述加载插件SDK的方法，能够实现第三方SDK的动态接入，即便第三方SDK频繁升级，也能方便快捷地相应升级客户端。并且，这种动态接入方式不改变任何第三方SDK的功能、特性、参数等，对于最终用户而言是完全透明无感知的，从而提高开发效率，提升应用品质。

需要说明的是，上述实施例中“步骤124”至“步骤164”，只是仅为描述实施例而设置的，并不能成为执行顺序的限定。事实上，三者是并发、同时执行的。

另外，在一些实施例中，该方法还包括：当当前应用待加载的更新的插件SDK中封装的第三方SDK为预定第三方SDK时，则采用静态加载的方式加载当前应用的更新的插件SDK。

对于某些预定的第三方SDK，例如移动MM，其包含的本地库so文件只能放在应用程序(宿主apk)中才能正常加载，通过动态加载的方式将会报错。对于这类比较特殊的第三方SDK，则仍然采用原有的静态加载的方式加载。

上述实施例中，当所获取的当前应用的更新的插件SDK包括非预定的第三方SDK和预定的第三方SDK时，非预订的第三方SDK采用上述动态加载的方式进行加载，预订的第三方SDK采用传统的静态加载的方式进行加载，以保证加载不会报错。

通过上述实施例的动静态结合方式加载插件SDK，能够解决由于第三方SDK频繁升级导致频繁升级客户端的问题。

在一些实施例中，在步骤104之前，该方法还包括：

为每个更新的插件SDK配置统一接口SDK，通过统一接口SDK调用更新的插件SDK。

统一接口SDK对各种第三方SDK进行了抽象，提供一种通用的接入各种类型第三方SDK的方法，屏蔽了各种第三方SDK的类型差异和接口差异。

例如图3所示，一个应用程序需更新的插件SDK(第三方SDK或者某种功能)可能有一个或多个(如SDK1，…，SDKN)，其对应的功能包括但不限于登录、支付、分享、推送、广告、统计等。以支付功能为例，当前市场上存在多种类型的支付，例如微信支付、支付宝支付、银联支付等等。每个厂商的接口名称和接口的参数，以及对支付结果的处理均存在较大差异。如果只是应用本身直接接入，那么各种接口都得处理，采用统一接口SDK，便可以提供一个统一支付接口。例如pay(...)及其结果处理机制，这样应用开发就更加高效，将应用程序本身的逻辑和接入第三方SDK的逻辑隔离开来。

上述加载插件SDK的方法，在获取当前应用的至少一个更新的插件SDK的步骤之前，将第三方SDK进行封装形成插件SDK并储存于服务器中。具体地，将第三方SDK封装形成插件SDK的方法如下：

首先在Android开发IDE(Integrated Development Environment，集成开发环境)中建立一个空的Android工程，根据接口SDK中定义的接口约定去封装第三方SDK的相关功能。如第三方SDK中需要在Android Application中添加逻辑，则继承接口SDK中定义的Application，实现其中的attachBaseContext和onCreate方法，宿主apk的Application定义为接口SDK中定义的Application，并在其内部逻辑中调用插件SDK中的Application的方法。

可以理解，插件SDK不仅仅局限于封装第三方SDK，也可以封装单独的某种功能模块，例如网络管理模块，该模块包括下载管理或者HTTP通信的工具类，可以将这个模块封装成一个插件SDK，同时会提供入口类的名称。

将第三方SDK或某种特定功能的模块插件化，使应用程序实现插件化、插拔式结构，有利于后期功能维护，并能够动态扩展功能。例如，对于频繁需要更新的模块，插件化就不需要每次迭代更新版本而仅实现模块更新即可。

在另一些实施例中，如图4所示，提出一种加载插件SDK的系统400，该系统400包括：获取模块402、加载模块404。

获取模块402用于获取当前应用的至少一个更新的插件SDK。

加载模块404用于当重新启动当前应用时，动态加载每个更新的插件SDK。加载模块404包括：代码合并模块424、本地库合并模块444和资源合并模块464。

代码合并模块424用于将更新的插件SDK的代码与当前应用的代码合并。本地库合并模块444用于将更新的插件SDK的本地库与当前应用的本地库合并。资源合并模块464用于将更新的插件SDK的资源与当前应用的资源合并。

在一些实施例中，代码合并模块424还用于扩展类加载器中的数组成员变量，将更新的插件SDK的代码与当前应用的代码合并。

在一些实施例中，本地库合并模块444还用于：通过反射类加载器，将更新的插件SDK的本地库路径添加到当前应用的本地库的加载路径中。

在一些实施例中，资源合并模块464还用于：通过反射调用应用程序资源管理器的成员函数将更新的插件SDK的资源加载到当前应用的资源对象中。

在一些实施例中，系统400还包括：接口模块406。接口模块406用于为每个更新的插件SDK配置统一接口SDK，通过统一接口SDK调用每个更新的插件SDK。

在一些实施例中，系统400还包括：插件管理模块408。插件管理模块408用于向服务器发送更新当前应用的插件SDK的请求，并接收服务器下发的包含至少一个更新的插件SDK的SDK更新包；将SDK更新包解压，获取至少一个更新插件SDK；或者接收服务器推送的插件SDK。

具体地，插件管理模块408通过网络将携带当前应用中已接入的插件SDK的应用标识发送至服务器，请求更新当前应用的插件SDK。由服务器判断当前应用接入的插件SDK是否有更新。若服务器发现当前应用接入的插件SDK有更新时，则下发更新后的SDK更新包。插件管理模块408接收更新后的SDK更新包，并将更新后的SDK更新包进行解压，获取更新的插件SDK和插件SDK的更新配置。另外，插件管理模块408还可以接收服务器推送的插件SDK，此处的插件SDK是指服务器强制推送的插件SDK。

本实施例的加载插件SDK的系统400用于实现前述的加载插件SDK的方法，因此加载插件SDK的系统400中的具体实施可参见前文中加载插件SDK的方法的实施例部分，例如，获取模块402、加载模块404分别用于实现上述加载插件SDK的方法中步骤102和104，所以，其具体实现方式可参照前文中有关步骤102和104的各个实施例的描述，在此不再累述。

在一些实施例中，还提出一种客户端，该客户端包括上述实施例描述的加载插件SDK的系统400。其具体实现方式可参照前文中有关加载插件SDK的系统400的各个实施例的描述，在此不再累述。

上述实施例的加载插件SDK的方法、系统及客户端，通过主动查询或者接收到服务器的强制推送的更新的插件SDK后，将更新的插件SDK加载到客户端的应用目录中，客户端(宿主apk)在重新启动应用时动态加载更新的插件SDK，即将插件SDK的代码、本地库和资源分别对应地与当前应用的代码、本地库和资源合并。通过这种动态加载的方式动态加入第三方SDK或某种特定功能，使得插件SDK和应用解耦，实现功能软件开发和应用解耦，使得可以独立开发插件SDK，解决了由于第三方SDK频繁升级导致频繁升级客户端的问题。而且有效减小了应用程序包的大小，同时提高了应用的安全性。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (13)

1.一种加载插件SDK的方法，其特征在于，包括以下步骤：

获取当前应用的至少一个更新的插件SDK；

当重新启动所述当前应用时，对每个所述更新的插件SDK执行动态加载的步骤；

所述动态加载的步骤包括：

将所述更新的插件SDK的代码与所述当前应用的代码合并；

将所述更新的插件SDK的本地库与所述当前应用的本地库合并；

将所述更新的插件SDK的资源与所述当前应用的资源合并。

2.根据权利要求1所述的方法，其特征在于，所述将所述更新的插件SDK的资源与所述当前应用的资源合并的步骤包括：

通过反射调用应用程序资源管理器的成员函数将所述更新的插件SDK的资源加载到所述当前应用的资源对象中。

3.根据权利要求1所述的方法，其特征在于，所述将所述更新的插件SDK的本地库与所述当前应用的本地库合并的步骤包括：

通过反射类加载器，将所述更新的插件SDK的本地库路径添加到当前应用的本地库的加载路径中。

4.根据权利要求1所述的方法，其特征在于，将所述更新的插件SDK的代码与所述当前应用的代码合并的步骤包括：

扩展类加载器中的数组成员变量，将所述更新的插件SDK的代码与所述当前应用的代码合并。

5.根据权利要求1所述的方法，其特征在于，在对每个所述更新的插件SDK执行动态加载的步骤之前，所述方法还包括：

为每个所述更新的插件SDK配置统一接口SDK，通过所述统一接口SDK调用所述更新的插件SDK。

6.根据权利要求1所述的方法，其特征在于，所述获取当前应用的至少一个更新的插件SDK的步骤包括：

向服务器发送更新所述当前应用的插件SDK的请求，并接收所述服务器下发的包含所述至少一个更新的插件SDK的SDK更新包；

将所述SDK更新包解压，获取所述至少一个更新的插件SDK；或者

接收服务器推送的插件SDK。

7.一种加载插件SDK的系统，其特征在于，包括：

获取模块，用于获取当前应用的至少一个更新的插件SDK；

加载模块，用于当重新启动所述当前应用时，动态加载每个所述更新的插件SDK，所述加载模块包括：

代码合并模块，用于将所述更新的插件SDK的代码与所述当前应用的代码合并；

本地库合并模块，用于将所述更新的插件SDK的本地库与所述当前应用的本地库合并；

资源合并模块，用于将所述更新的插件SDK的资源与所述当前应用的资源合并。

8.根据权利要求7所述的系统，其特征在于，所述资源合并模块还用于：通过反射调用应用程序资源管理器的成员函数将所述更新的插件SDK的资源加载到所述当前应用的资源对象中。

9.根据权利要求7所述的系统，其特征在于，所述本地库合并模块还用于：通过反射类加载器，将所述更新的插件SDK的本地库路径添加到当前应用的本地库的加载路径中。

10.根据权利要求7所述的系统，其特征在于，所述代码合并模块还用于扩展类加载器中的数组成员变量，将所述更新的插件SDK的代码与当前应用的代码合并。

11.根据权利要求7所述的系统，其特征在于，所述系统还包括：

接口模块，用于为每个所述更新的插件SDK配置统一接口SDK，通过所述统一接口SDK调用每个所述更新的插件SDK。

12.根据权利要求7所述的系统，其特征在于，所述系统还包括：

插件管理模块，用于向服务器发送更新所述当前应用的插件SDK的请求，并接收所述服务器下发的包含所述至少一个更新的插件SDK的SDK更新包；将所述SDK更新包解压，获取所述至少一个更新的插件SDK；或者接收服务器推送的插件SDK。

13.一种客户端，其特征在于，包括如权利要求7至12任意一项所述的加载插件SDK的系统。