CN112433747B - 一种适用于软件开发工具包sdk的差分升级方法及系统 - Google Patents

Abstract

本发明涉及在线升级技术领域，公开了一种适用于软件开发工具包SDK的差分升级方法及系统，可通过对软件开发工具包SDK进行的组件化、插件化及增量更新，将SDK的在线升级拆分为按功能组件进行的插件式加载处理，进而可以在第三方库引用发生冲突时，允许颗粒度更低的插件加载升级失败而非整体性的在线升级失败，并通过在云端发布平台进行的插件差分处理和在工具应用终端进行的插件还原处理，还可以降低传送升级包的体积和所需传输的流量，简化打包流程，缩短在应用终端获取升级包后所需的升级完成时间，从而可特别适用于SDK的在线升级场景，便于实际应用和推广。

Description

一种适用于软件开发工具包SDK的差分升级方法及系统

技术领域

本发明属于在线升级技术领域，具体地涉及一种适用于软件开发工具包SDK的差分升级方法及系统。

背景技术

在安卓系统应用软件的开发过程中，对软件应用程序APP进行组件化或插件化，可以有效降低代码模块的耦合度，使代码架构更加清晰，同时还可以有效减少编译时间。组件化开发是指将一个APP分成多个代码模块，每个代码模块就是一个组件（Module），开发的过程中可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并成一个安卓应用程序包apk（全称：Android application package，是安卓系统使用的一种应用程序包文件格式，用于分发和安装移动应用及中间件）。而插件化开发与组件化开发略有不同，其是将整个APP拆分成很多功能模块，这些功能模块包括一个宿主和多个插件，每个功能模块都是一个apk，最终打包的时候将宿主apk和插件apk分开或者联合打包。

软件开发工具包SDK（即Software Development Kit 的缩写）是一个覆盖面相当广泛的名词，可以这么说：辅助开发某一类软件的相关文档、范例和工具的集合都可以称之SDK，其开发出来的目的就是为了减少程序员的开发工作量。例如有公司开发出某种软件的某一功能，就可以把它封装成SDK（比如数据分析SDK就是能够实现数据分析功能的SDK），以便出售给其他公司做开发用；而其他公司如果想要给软件开发出某种功能，但又不想从头开始搞开发，就可以直接付钱省事地在软件中使该软件开发工具包。

与软件应用程序APP一样，软件开发工具包SDK在首次发布后也存在升级更新的需求。目前针对软件应用程序APP，开源的组件化框架有arouter和cc等，升级更新的框架有andfix和Tinker等，虽然这些框架在APP的开发过程及升级过程中应用非常广泛，但是在针对软件开发工具包SDK的在线升级场景中却不太适用，主要原因如下：（1）在SDK中常常需要引用第三方的库，但是可能跟APP的引用发生冲突，导致在线升级容易整体性失败；（2）由于第三方框架本身存在业务场景多和代码量大的特点，导致会增大SDK升级包的体积，所需传输流量要求多；（3）引用打包复杂，使得在应用终端获取升级包后所需的升级完成时间较长。由此对于软件开发工具包SDK来说，需要一套有针对性的、更轻量级的和升级完成时间更短的在线升级方法及系统。

发明内容

为了解决现有软件开发工具包SDK在线升级过程所存在的易整体性失败、所需传输流量要求多和升级完成时间较长的问题，本发明目的在于提供一种适用于软件开发工具包SDK的差分升级方法及系统。

第一方面，本发明提供了一种适用于软件开发工具包SDK的差分升级方法，包括有用于在工具开发终端上执行的新包发布方法、用于在云端发布平台执行的差分处理方法和用于在工具应用终端上执行的更新加载方法；

所述用于在工具开发终端上执行的新包发布方法，包括：

获取待发布的组件化软件开发工具包SDK，其中，所述组件化软件开发工具包SDK包含有至少一个功能组件；

将所述至少一个功能组件中的各个功能打包成一一对应的补丁插件；

将得到的至少一个补丁插件上传至所述云端发布平台；

所述用于在云端发布平台执行的差分处理方法，包括：

接收来自所述工具开发终端的所述至少一个补丁插件；

针对所述至少一个补丁插件中的各个补丁插件，根据对应的历史补丁插件生成补丁插件差分包；

将得到的至少一个补丁插件差分包推送至所述工具应用终端；

所述用于在工具应用终端上执行的更新加载方法，包括：

接收来自所述云端发布平台的所述至少一个补丁插件差分包；

针对所述至少一个补丁插件差分包中的各个补丁插件差分包，根据对应的历史补丁插件还原得到对应的新补丁插件；

对所述新补丁插件进行封装包的解封，并将得到待加载的dex文件和so文件拷贝至待加载目录中。

基于上述发明内容，可通过对软件开发工具包SDK进行的组件化、插件化及增量更新，将SDK的在线升级拆分为按功能组件进行的插件式加载处理，进而可以在第三方库引用发生冲突时，允许颗粒度更低的插件加载升级失败而非整体性的在线升级失败，并通过在云端发布平台进行的插件差分处理和在工具应用终端进行的插件还原处理，还可以降低传送升级包的体积和所需传输的流量，简化打包流程，缩短在应用终端获取升级包后所需的升级完成时间，从而可特别适用于SDK的在线升级场景，便于实际应用和推广。

在一种可能设计中，将所述至少一个功能组件中的各个功能组件打包成一一对应的补丁插件，包括：

获取所述功能组件的文件包，其中，所述文件包为aar包或jar包；

对所述文件包进行解压，并将解压得到的内容重新打包为dex文件；

对所述dex文件和so文件进行封装，得到封装包；

在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。

在一种可能设计中，在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件，包括：

使用gzip压缩算法对所述封装包进行压缩处理，得到新封装包；

在所述新封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。

在一种可能设计中，在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件，包括：

使用加密算法对所述封装包进行加密处理，得到新封装包；

在所述新封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。

在一种可能设计中，所述组件协议头包含有组件标识信息、组件版本信息、加密指示信息、压缩指示信息和第三数据长度信息，其中，所述组件标识信息用于标记所述功能组件，所述组件版本信息用于记录所述功能组件的当前版本号，所述加密指示信息用于表示是否对所述封装包进行了加密处理，所述压缩指示信息用于表示是否对所述封装包进行了压缩处理，所述第三数据长度信息用于指示所述封装包的数据长度。

在一种可能设计中，针对所述至少一个补丁插件中的各个补丁插件，根据对应的历史补丁插件生成补丁插件差分包，包括：

从所述补丁插件的组件协议头中获取第一组件版本信息，以及从所述历史补丁插件的组件协议头中获取第二组件版本信息；

判断所述第一组件版本信息是否新于所述第二组件版本信息；

若是，根据所述补丁插件与所述历史补丁插件的数据差异，生成所述补丁插件差分包。

在一种可能设计中，针对所述至少一个补丁插件差分包中的各个补丁插件差分包，根据对应的历史补丁插件还原得到对应的新补丁插件，包括：

初始化组件链接器Modulelinker；

通过所述组件链接器Modulelinker来检查是否存在新的补丁插件；

若存在新的补丁插件，则通过所述组件链接器Modulelinker来检查所述新的补丁插件是否已被加载过；

若是，则通过所述组件链接器Modulelinker来检测是否存在旧的补丁插件；

若存在，则通过所述组件链接器Modulelinker来根据所述旧的补丁插件和所述补丁插件差分包，还原得到最新的所述新补丁插件。

在一种可能设计中，在将得到待加载的dex文件和so文件拷贝至待加载目录中之后，所述更新加载方法还包括：

获取处理器的处理器CPU类型，其中，所述处理器用于运行基于所述组件化软件开发工具包SDK的软件应用程序APP；

设置待加载的dex文件和对应所述CPU类型的so文件为类文件；

创建类加载器，并启动所述类加载器，将所述类文件加载到jvm虚拟机中,以便运行所述软件应用程序APP。

在一种可能设计中，获取处理器的处理器CPU类型，包括：

判断所述软件应用程序APP是否设置有CPU类型；

若是，则根据预设的架构获取所述CPU类型，否则根据系统原则获取所述CPU类型。

第二方面，本发明提供了一种适用于软件开发工具包SDK的差分升级系统，包括有依次通信连接的工具开发终端、云端发布平台和工具应用终端；

所述工具开发终端，用于执行在如第一方面或第一方面中任意一种可能设计的所述差分升级方法中的新包发布方法；

所述云端发布平台，用于执行在如第一方面或第一方面中任意一种可能设计的所述差分升级方法中的差分处理方法；

所述工具应用终端，用于执行在如第一方面或第一方面中任意一种可能设计的所述差分升级方法中的更新加载方法。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明提供的适用于软件开发工具包SDK的差分升级方法的流程示意图。

图2是本发明提供的dex文件的数据头结构示意图。

图3是本发明提供的so文件的数据头结构示意图。

图4是本发明提供的组件协议头的结构示意图。

图5是本发明提供的适用于软件开发工具包SDK的差分升级系统的结构示意图。

具体实施方式

下面结合附图及具体实施例来对本发明作进一步阐述。在此需要说明的是，对于这些实施例方式的说明虽然是用于帮助理解本发明，但并不构成对本发明的限定。本文公开的特定结构和功能细节仅用于描述本发明的示例实施例。然而，可用很多备选的形式来体现本发明，并且不应当理解为本发明限制在本文阐述的实施例中。

应当理解，尽管本文可能使用术语第一、第二等等来描述各种单元，但是这些单元不应当受到这些术语的限制。这些术语仅用于区分一个单元和另一个单元。例如可以将第一单元称作第二单元,并且类似地可以将第二单元称作第一单元，同时不脱离本发明的示例实施例的范围。

应当理解，对于本文中可能出现的术语“和/或”，其仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，单独存在B，同时存在A和B三种情况；对于本文中可能出现的术语“/和”，其是描述另一种关联对象关系，表示可以存在两种关系，例如，A/和B，可以表示：单独存在A，单独存在A和B两种情况；另外，对于本文中可能出现的字符“/”，一般表示前后关联对象是一种“或”关系。

应当理解，在本文中若将单元称作与另一个单元“连接”、“相连”或“耦合”时，它可以与另一个单元直相连接或耦合，或中间单元可以存在。相対地，在本文中若将单元称作与另一个单元“直接相连”或“直接耦合”时，表示不存在中间单元。另外，应当以类似方式来解释用于描述单元之间的关系的其他单词（例如，“在……之间”对“直接在……之间”,“相邻”对“直接相邻”等等）。

应当理解，本文使用的术语仅用于描述特定实施例，并不意在限制本发明的示例实施例。若本文所使用的，单数形式“一”、“一个”以及“该”意在包括复数形式，除非上下文明确指示相反意思。还应当理解，若术语“包括”、“包括了”、“包含”和/或“包含了”在本文中被使用时,指定所声明的特征、整数、步骤、操作、单元和/或组件的存在性,并且不排除一个或多个其他特征、数量、步骤、操作、单元、组件和/或他们的组合存在性或增加。

应当理解，还应当注意到在一些备选可能设计中，所出现的功能/动作可能与附图出现的顺序不同。例如,取决于所涉及的功能/动作,实际上可以实质上并发地执行,或者有时可以以相反的顺序来执行连续示出的两个图。

应当理解，在下面的描述中提供了特定的细节,以便于对示例实施例的完全理解。然而,本领域普通技术人员应当理解可以在没有这些特定细节的情况下实现示例实施例。例如可以在框图中示出系统，以避免用不必要的细节来使得示例不清楚。在其他实例中，可以不以非必要的细节来示出众所周知的过程、结构和技术，以避免使得示例实施例不清楚。

如图1～3所示，本实施例第一方面提供的所述适用于软件开发工具包SDK的差分升级方法，包括但不限于有用于在工具开发终端（即由SDK开发人员所持有的电子设备）上执行的新包发布方法、用于在云端发布平台（即专用于升级包发布的云服务器）执行的差分处理方法和用于在工具应用终端（即安装有基于SDK的软件应用程序APP的电子设备）上执行的更新加载方法。

所述用于在工具开发终端上执行的新包发布方法，可以但不限于包括有如下步骤S101～S103。

S101.获取待发布的组件化软件开发工具包SDK，其中，所述组件化软件开发工具包SDK包含有至少一个功能组件。

在所述步骤S101中，所述组件化软件开发工具包SDK的组件划分逻辑是由SDK开发人员根据工具项目本身的模块化，划分通过注解标注各模块的接口来实现功能模块组件化（即在开发阶段动态生成模块的ID标识和源码信息， 然后在APP运行时通过ID标识找到对应模块的接口，进行各模块间的相互调用），如此可以降低代码耦合度，使得多开发人员在开发同一个工具项目时只需要根据功能关注自己的业务逻辑，进而在同功能多组件的场景下可以做到自由切换， 无需关注各模块的依赖关系。此外，所述组件化软件开发工具包SDK的获取方式由开发人员使用所述工具开发终端（例如智能手机、平板电脑或笔记本电脑等电子设备）进行常规输入得到。

S102.将所述至少一个功能组件中的各个功能组件打包成一一对应的补丁插件；

在所述步骤S102中，优选的，将所述至少一个功能组件中的各个功能组件打包成一一对应的补丁插件，包括但不限于有如下步骤S1021～S1024。

S1021.获取所述功能组件的文件包，其中，所述文件包为aar包或jar包。

在所述步骤S1021中，所述aar包（即Android Archive包的缩写形式，是一个Android库项目的二进制归档文件）或jar包（即Java Archive包的缩写形式，其是一种软件包文件格式，通常用于聚合大量的Java类文件、相关的元数据和资源文件到一个文件，以便开发Java平台应用软件或库）为编码后所得到的常用文件包，用于记录对应功能组件的模块ID标识和模块源码信息。

S1022.对所述文件包进行解压，并将解压得到的内容重新打包为dex文件。

在所述步骤S1022中，所述dex文件是安卓系统中Dalvik虚拟机的可执行文件, 相当于Windows系统中的exe文件。如图2所示，所述dex文件的数据头包含但不限于有第一数据类型信息、第一数据名称长度信息和第一数据长度信息，其中，所述第一数据类型信息用于标记是否为dex文件（可举例用1表示），所述第一数据名称长度信息用于表示dex文件的名称长度，所述第一数据长度信息用于表示dex文件的数据长度。此外，进行解压及重新打包的具体方式均为现有常规方式。

S1023.对所述dex文件和so文件进行封装，得到封装包。

在所述步骤S1023中，所述so文件具体为二进制文件，用于针对不同的处理器CPU架构定义如何运行在相应的系统平台上：从使用的指令集、内存对齐到可用的系统函数库。在安卓系统中，CPU架构包括有armeabi、armeabi-v7a、x86、mips、arm64-v8a、mips64和x86_64等。如图3所示，所述so文件的数据头包含但不限于有第二数据类型信息、CPU架构信息、第二数据名称长度信息和第二数据长度信息，其中，所述第一数据类型信息用于标记是否为so文件（可举例用2表示），所述第二数据名称长度信息用于表示so文件的名称长度，所述第二数据长度信息用于表示so文件的数据长度。此外，进行封装的具体方式为现有常用方式。

S1024.在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。

在所述步骤S1024中，具体的，如图4所示，所述组件协议头包含但不限于有组件标识信息、组件版本信息、加密指示信息、压缩指示信息和第三数据长度信息，其中，所述组件标识信息用于标记所述功能组件，所述组件版本信息用于记录所述功能组件的当前版本号，所述加密指示信息用于表示是否对所述封装包进行了加密处理，所述压缩指示信息用于表示是否对所述封装包进行了压缩处理，所述第三数据长度信息用于指示所述封装包的数据长度。此外，进行添加的具体方式为现有常用方式。

在所述步骤S1024中，优选的，在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件，包括但不限于有如下步骤：使用gzip压缩算法（GNUzip的缩写，它是一个GNU自由软件的文件压缩程序，由Jean-loupGailly和MarkAdler一起开发，并在1993年2月发布了版本1.0）对所述封装包进行压缩处理，得到新封装包；在所述新封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。通过前述压缩处理，可减少后续从所述工具开发终端向所述云端发布平台传送所述补丁插件所需的流量。此外，进行压缩的具体方式为现有常用方式，并在进行压缩处理后，需在所述压缩指示信息中表示对所述封装包进行了压缩处理。

在所述步骤S1024中，优选的，在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件，包括但不限于有如下步骤：使用加密算法对所述封装包进行加密处理，得到新封装包；在所述新封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。通过前述加密处理，可提升后续补丁插件及补丁插件差分包的数据传输安全性。此外，进行加密的具体方式为现有常用方式，并在进行加密处理后，需在所述加密指示信息中表示对所述封装包进行了加密处理。

S103.将得到的至少一个补丁插件上传至所述云端发布平台。

在所述步骤S103中，优选的，可将涉及版本更新的补丁插件上传至所述云端发布平台，以便减少从所述工具开发终端向所述云端发布平台传送所述补丁插件所需的流量。

所述用于在云端发布平台执行的差分处理方法，可以但不限于包括有如下步骤S201～S203。

S201.接收来自所述工具开发终端的所述至少一个补丁插件。

S202.针对所述至少一个补丁插件中的各个补丁插件，根据对应的历史补丁插件生成补丁插件差分包。

在所述步骤S202中，优选的，针对所述至少一个补丁插件中的各个补丁插件，根据对应的历史补丁插件生成补丁插件差分包，包括但不限于有如下步骤S2021～S2023。

S2021.从所述补丁插件的组件协议头中获取第一组件版本信息，以及从所述历史补丁插件的组件协议头中获取第二组件版本信息。

在所述步骤S2021中，所述第一组件版本信息和所述第二组件版本信息具体可用版本号表示。

S2022.判断所述第一组件版本信息是否新于所述第二组件版本信息。

在所述步骤S2022中，具体判断方式可为比较版本号的大小，若所述第一组件版本信息的版本号高于所述第二组件版本信息的版本号，则判定所述第一组件版本信息新于所述第二组件版本信息。

S2023.若是，根据所述补丁插件与所述历史补丁插件的数据差异，生成所述补丁插件差分包。

在所述步骤S2022中，所述补丁插件差分包用于记录所述补丁插件与所述历史补丁插件的数据差异，其生成的具体方式为现有常用方式。

S203.将得到的至少一个补丁插件差分包推送至所述工具应用终端。

所述用于在工具应用终端上执行的更新加载方法，可以但不限于包括有如下步骤S301～S303。

S301.接收来自所述云端发布平台的所述至少一个补丁插件差分包。

S302.针对所述至少一个补丁插件差分包中的各个补丁插件差分包，根据对应的历史补丁插件还原得到对应的新补丁插件。

在所述步骤S302中，优选的，针对所述至少一个补丁插件差分包中的各个补丁插件差分包，根据对应的历史补丁插件还原得到对应的新补丁插件，包括但不限于有如下步骤S3021～S3023。

S3021.初始化组件链接器Modulelinker。

在所述步骤S3021中，所述组件链接器Modulelinker是一种可基于现有链接器Linker进行常规开发所得的程序，可针对组件/模块Modulelinker的且将一个或多个由编译器或汇编器生成的目标文件外加库链接为一个可执行文件。在所述步骤S3021之前，为了使用所述组件链接器Modulelinker，可按照如下步骤进行环境配置：首先针对基于所述组件化软件开发工具包SDK的软件应用程序APP，在主工程的build.gradle下增加两个配置：（a）将includeCompileClasspath设为true，允许编译类路径中包含注释处理器;（b）分别指定目标文件和源文件的java版本号；其次新建一个公共模块module并添加modulelinker的maven引用，其中，注解器必须有annotationProcessor的声明；最后在gradle.properties文件中配置注解器生成源码所在的模块module和包路径，并且设置android.enableD8.desugaring属性为true。

在完成前述的配置后，即可使各模块间可以先依赖所述公共模块，然后通过Modulelinker的注解先对想要调用的类和方法做常规注解，并通过生成的模块标识ID进行直接调用，由此不但可以通过modulelinker对想要的实例进行直接调用，解决在SDK实际开发过程中因为多协议多功能模块而使用适配器模式所遇到的代码层级调用问题（目前使用适配器模式对方法的调用参数设置以及回调接口设置都需要对整个链路增加接口，相当于是一个管道的方式一层一层往下传递；而目前的解决办法是通过增加通用接口的方式，这种方式实质上还是一个管道，至少会存在如下两个问题：一是在调用方法或者参数设置的过程中需要关注每一个环节的逻辑不然会调用失败；二是调用链路必须完全畅通，不然需要做中间变量缓存引用，假设A类要给D类设置一个参数，而这个参数又是在D类真正使用的时候才会用到，假设中间如果B类或者C类没有创建，那么这个参数就需要在中间某一个环节的对象上加一个该参数的变量做引用存储，必须等到实际D类被使用的时候才能通过通用接口再次设置），还可以在内存管理上也做到优化，即如果一个被加载的module在没有被GCROOT（像静态变量或者线程等）直接引用的情况下，可以直接通过modulelinker删除，使得在下一次GC回收的时候就可以被直接释放（因为modulelinker内部的数据不依赖任何实体类）。

S3022.通过所述组件链接器Modulelinker来检查是否存在新的补丁插件。

在所述步骤S3022中，检查是否存在新的补丁插件的具体方式为现有常用方式。

S3023.若存在新的补丁插件，则通过所述组件链接器Modulelinker来检查所述新的补丁插件是否已被加载过。

在所述步骤S3023中，检查所述新的补丁插件是否已被加载过的具体方式为现有常用方式。

S3024.若是，则通过所述组件链接器Modulelinker来检测是否存在旧的补丁插件。

在所述步骤S3024中，检测是否存在旧的补丁插件的具体方式为现有常用方式。此外，若否，可直接对所述新的补丁插件进行封装包的解封，得到待加载的dex文件和so文件，并将这些文件拷贝至待加载目录中。

S3025.若存在，则通过所述组件链接器Modulelinker来根据所述旧的补丁插件和所述补丁插件差分包，还原得到最新的所述新补丁插件。

在所述步骤S3025中，进行还原的具体方式为现有常用方式。此外，若不存在，则也对所述新的补丁插件进行封装包的解封，得到待加载的dex文件和so文件，并将这些文件拷贝至待加载目录中。

S303.对所述新补丁插件进行封装包的解封，并将得到待加载的dex文件和so文件拷贝至待加载目录中。

在所述步骤S303中，进行解封（包括针对压缩和/或加密处理的解封）及拷贝的具体方式为现有常规方式。此外，在将得到待加载的dex文件和so文件拷贝至待加载目录中之后，所述更新加载方法还包括但不限于有如下步骤S3041～S3043。

S3041.获取处理器的处理器CPU类型，其中，所述处理器用于运行基于所述组件化软件开发工具包SDK的软件应用程序APP。

在所述步骤S3041中，具体的，获取处理器的处理器CPU类型，包括但不限于有如下步骤：判断所述软件应用程序APP是否设置有CPU类型；若是，则根据预设的架构获取所述CPU类型，否则根据系统原则获取所述CPU类型。

S3042.设置待加载的dex文件和对应所述CPU类型的so文件为类文件。

S3043.创建类加载器，并启动所述类加载器，将所述类文件加载到jvm虚拟机中,以便运行所述软件应用程序APP。

由此基于前述步骤S101～S103、S201～S203和S301～S303所描述的差分升级方案，可通过对软件开发工具包SDK进行的组件化、插件化及增量更新，将SDK的在线升级拆分为按功能组件进行的插件式加载处理，进而可以在第三方库引用发生冲突时，允许颗粒度更低的插件加载升级失败而非整体性的在线升级失败，并通过在云端发布平台进行的插件差分处理和在工具应用终端进行的插件还原处理，还可以降低传送升级包的体积和所需传输的流量，简化打包流程，缩短在应用终端获取升级包后所需的升级完成时间，从而可特别适用于SDK的在线升级场景，便于实际应用和推广。

如图5所示，本实施例第二方面提供了一种实现第一方面或第一方面中任意一种可能设计所述适用于软件开发工具包SDK的差分升级方法的系统，包括有依次通信连接的工具开发终端、云端发布平台和工具应用终端；所述工具开发终端，用于执行在如第一方面或第一方面中任意一种可能设计的所述差分升级方法中的新包发布方法；所述云端发布平台，用于执行在如第一方面或第一方面中任意一种可能设计的所述差分升级方法中的差分处理方法；所述工具应用终端，用于执行在如第一方面或第一方面中任意一种可能设计的所述差分升级方法中的更新加载方法。

以上所描述的实施例仅仅是示意性的，若涉及到作为分离部件说明的单元，其可以是或者也可以不是物理上分开的；若涉及到作为单元显示的部件，其可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。而这些修改或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。

最后应说明的是，本发明不局限于上述可选的实施方式，任何人在本发明的启示下都可得出其他各种形式的产品。上述具体实施方式不应理解成对本发明的保护范围的限制，本发明的保护范围应当以权利要求书中界定的为准，并且说明书可以用于解释权利要求书。

Claims (9)

1.一种适用于软件开发工具包SDK的差分升级方法，其特征在于，包括有用于在工具开发终端上执行的新包发布方法、用于在云端发布平台执行的差分处理方法和用于在工具应用终端上执行的更新加载方法；

所述用于在工具开发终端上执行的新包发布方法，包括：

获取待发布的组件化软件开发工具包SDK，其中，所述组件化软件开发工具包SDK包含有至少一个功能组件；

将所述至少一个功能组件中的各个功能打包成一一对应的补丁插件；

将得到的至少一个补丁插件上传至所述云端发布平台；

所述用于在云端发布平台执行的差分处理方法，包括：

接收来自所述工具开发终端的所述至少一个补丁插件；

针对所述至少一个补丁插件中的各个补丁插件，根据对应的历史补丁插件生成补丁插件差分包；

将得到的至少一个补丁插件差分包推送至所述工具应用终端；

所述用于在工具应用终端上执行的更新加载方法，包括：

接收来自所述云端发布平台的所述至少一个补丁插件差分包；

针对所述至少一个补丁插件差分包中的各个补丁插件差分包，根据对应的历史补丁插件还原得到对应的新补丁插件，其中，包括：针对基于所述组件化软件开发工具包SDK的软件应用程序APP，在主工程的build.gradle下增加两个配置：(a)将includeCompileClasspath设为true，允许编译类路径中包含注释处理器；(b)分别指定目标文件和源文件的java版本号；新建一个公共模块module并添加组件链接器Modulelinker的maven引用，其中，注解器必须有annotationProcessor的声明；在gradle.properties文件中配置注解器生成源码所在的模块module和包路径，并且设置android.enableD8.desugaring属性为true；初始化所述组件链接器Modulelinker；通过所述组件链接器Modulelinker来检查是否存在新的补丁插件；若存在新的补丁插件，则通过所述组件链接器Modulelinker来检查所述新的补丁插件是否已被加载过；若是，则通过所述组件链接器Modulelinker来检测是否存在旧的补丁插件；若存在，则通过所述组件链接器Modulelinker来根据所述旧的补丁插件和所述补丁插件差分包，还原得到最新的所述新补丁插件；

对所述新补丁插件进行封装包的解封，并将得到待加载的dex文件和so文件拷贝至待加载目录中。

2.如权利要求1所述的差分升级方法，其特征在于，将所述至少一个功能组件中的各个功能组件打包成一一对应的补丁插件，包括：

获取所述功能组件的文件包，其中，所述文件包为aar包或jar包；

对所述文件包进行解压，并将解压得到的内容重新打包为dex文件；

对所述dex文件和so文件进行封装，得到封装包；

在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。

3.如权利要求2所述的差分升级方法，其特征在于，在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件，包括：

使用gzip压缩算法对所述封装包进行压缩处理，得到新封装包；

在所述新封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。

4.如权利要求2所述的差分升级方法，其特征在于，在所述封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件，包括：

使用加密算法对所述封装包进行加密处理，得到新封装包；

在所述新封装包的数据头前添加与所述功能组件对应的组件协议头，得到与所述功能组件一一对应的所述补丁插件。

5.如权利要求2所述的差分升级方法，其特征在于，所述组件协议头包含有组件标识信息、组件版本信息、加密指示信息、压缩指示信息和第三数据长度信息，其中，所述组件标识信息用于标记所述功能组件，所述组件版本信息用于记录所述功能组件的当前版本号，所述加密指示信息用于表示是否对所述封装包进行了加密处理，所述压缩指示信息用于表示是否对所述封装包进行了压缩处理，所述第三数据长度信息用于指示所述封装包的数据长度。

6.如权利要求1所述的差分升级方法，其特征在于，针对所述至少一个补丁插件中的各个补丁插件，根据对应的历史补丁插件生成补丁插件差分包，包括：

从所述补丁插件的组件协议头中获取第一组件版本信息，以及从所述历史补丁插件的组件协议头中获取第二组件版本信息；

判断所述第一组件版本信息是否新于所述第二组件版本信息；

若是，根据所述补丁插件与所述历史补丁插件的数据差异，生成所述补丁插件差分包。

7.如权利要求1所述的差分升级方法，其特征在于，在将得到待加载的dex文件和so文件拷贝至待加载目录中之后，所述更新加载方法还包括：

获取处理器的处理器CPU类型，其中，所述处理器用于运行基于所述组件化软件开发工具包SDK的软件应用程序APP；

设置待加载的dex文件和对应所述CPU类型的so文件为类文件；

创建类加载器，并启动所述类加载器，将所述类文件加载到jvm虚拟机中,以便运行所述软件应用程序APP。

8.如权利要求7所述的差分升级方法，其特征在于，获取处理器的处理器CPU类型，包括：

判断所述软件应用程序APP是否设置有CPU类型；

若是，则根据预设的架构获取所述CPU类型，否则根据系统原则获取所述CPU类型。

9.一种适用于软件开发工具包SDK的差分升级系统，其特征在于,包括有依次通信连接的工具开发终端、云端发布平台和工具应用终端；

所述工具开发终端，用于执行在如权利要求1～8任意一项所述差分升级方法中的新包发布方法；

所述云端发布平台，用于执行在如权利要求1～8任意一项所述差分升级方法中的差分处理方法；

所述工具应用终端，用于执行在如权利要求1～8任意一项所述差分升级方法中的更新加载方法。

Images