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

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

背景技术：

目前应用接入第三方sdk(softwaredevelopmentkit，软件开发工具包)的主要方式是应用直接硬编码静态加载第三方sdk。而静态加载第三方sdk是在应用发布时，将应用本身的逻辑和第三方sdk的代码、资源合并在一个apk(androidpackage，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为开发平台的智能移动终端。androidsdk(softwaredevelopmentkit，软件开发工具包)采用了java语言。一般sdk都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。软件开发工具包广义上指辅助开发某一类软件的相关文档、范例和工具的集合。

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

将第三方sdk进行封装形成插件sdk，一个插件sdk封装了一个第三方sdk或者某种特定功能，二者一一对应，即插件sdk是在第三方sdk提供的代码和资源的基础上，按照接入的需要进行封装，最后以apk(androidpackage，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(即android4.0以下)时，直接将指定 目录扩展附加到类加载器pathclassloader的mpaths、mfiles、mzips和mdexs数组成员中来实现代码整合。

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

在本实施例中，api即androidframework是android系统版本的唯一标识。14为当前手机终端的android系统apilevel，系统代号为ice_cream_sandwich，代指android4.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即androidframework是android系统版本的唯一标识。14为当前手机终端的android系统apilevel，系统代号为ice_cream_sandwich，代指android4.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(integrateddevelopmentenvironment，集成开发环境)中建立一个空的android工程，根据接口sdk中定义的接口约定去封装第三方sdk的相关功能。如第三方sdk中需要在androidapplication中添加逻辑，则继承接口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频繁升级导致频繁升级客户端的问题。而且有效减小了应用程序包的大小，同时提高了应用的安全性。

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

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