应用程序补丁包获取方法、装置、计算机设备及存储介质与流程

本发明涉及信息科技领域，特别涉及一种应用程序补丁包获取方法、装置、计算机设备及存储介质。

背景技术

随着移动终端的快速发展，出现了越来越多的应用程序，这些应用程序需要不断地进行修复，例如，针对应用程序出现的bug进行完善或在应用程序中增加新的功能模块。一般地，安卓系统上运行的应用程序出现问题时，需要该应用程序的开发端的计算机设备将修复好的完整安装包推送至用户端的计算机设备，用户端的计算机设备接收到该安装包并完成对该应用程序的修复，但这种方式用户体验不好，因此，出现了一种基于热修复技术实现动态编译的方案，通过该热修复技术，开发商仅需针对安卓系统上的该应用程序出现的问题进行修复，得到补丁包，将该补丁包推送至用户端的计算机设备，用户端的计算机设备上的应用程序重启后，即完成修复。

目前，现有的基于热修复技术实现动态编译的方案为：开发商在开发端的计算机设备上注入application类的oncreate方法，用于作为该应用程序的入口，同时在开发端的计算机设备注册一个本地服务器，用于监听用户端的计算机设备的端口，开发端的计算机设备基于被修改的代码，生成代码补丁包，且用户端的计算机设备基于被修改的资源，对新全量资源的资源标识进行重新编写，生成资源补丁包，并将该代码补丁包和资源补丁包推送至用户端的计算机设备，用户端的计算机设备通过端口接收到该代码补丁包和资源补丁包，更新原有代码和原有资源，用户端的计算机设备重启后，自动完成对该应用程序的修复。

然而，基于上述方案，开发端的计算机设备生成代码补丁包的过程是从上到下沿着流水式的任务进行打包的，每个环节耗时都太长，最终导致整个代码补丁包的生成时间太长，且开发端的计算机设备生成资源补丁包时，需要对新全量资源的资源标识进行重新编写，效率低下。

技术实现要素：

本发明实施例提供了一种应用程序补丁包获取方法、装置、计算机设备及存储介质，能够解决生成代码补丁包的耗时太长，以及生成资源补丁包时，需要对新全量资源的资源标识进行重新编写，导致效率低下的问题。所述技术方案如下：

一方面，提供了一种应用程序补丁包获取方法，所述方法包括：

获取应用程序的更新代码文件和更新资源；

基于所述更新代码文件，生成代码补丁包；

基于更新资源和第一资源库，获取所述更新资源的资源标识，所述第一资源库用于存储所述应用程序的原有资源以及资源标识；

基于所述更新资源的资源标识、第一资源库、第一资源标识映射文件以及新全量资源，生成资源补丁包，所述第一资源标识映射文件为基于第一资源库获取到的用于固定资源标识的文件，所述新全量资源包括更新资源和原有资源。

一方面，提供了一种应用程序补丁包获取装置，所述装置包括：

获取模块，用于获取应用程序的更新代码文件和更新资源；

生成模块，用于基于所述更新代码文件，生成代码补丁包；

所述获取模块还用于基于更新资源和第一资源库，获取所述更新资源的资源标识，所述第一资源库用于存储所述应用程序的原有资源以及资源标识；

所述生成模块还用于基于所述更新资源的资源标识、第一资源库、第一资源标识映射文件以及新全量资源，生成资源补丁包，所述第一资源标识映射文件为基于第一资源库获取到的用于固定资源标识的文件，所述新全量资源包括更新资源和原有资源。

一方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如上述应用程序补丁包获取方法所执行的操作。

一方面，提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如上述应用程序补丁包获取方法所执行的操作。

一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如上述应用程序补丁包获取方法所执行的操作。

本发明实施例提供的技术方案带来的有益效果是：

本发明实施例在生成资源补丁包的过程中，通过固定第一资源库中的资源标识，获取更新资源的资源标识，并基于该更新资源的资源标识合成相应文件，避免了对第一资源库中的资源标识和更新资源标识的重新编写，大大提高了资源补丁包的生成效率。

附图说明

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

图1是本发明实施例提供的一种应用程序补丁包获取方法的实施环境图；

图2是本发明实施例提供的一种应用程序补丁包获取方法的流程图；

图3是本发明实施例提供的代码补丁包的加载示意图；

图4是本发明实施例提供的当应用程序的页面布局没有发生改动时，资源补丁包的生成过程示意图；

图5是本发明实施例提供的当应用程序的页面布局发生改动时，资源补丁包的生成过程示意图；

图6是本发明实施例提供的一种应用程序补丁包获取装置的结构示意图；

图7是本发明实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是本发明实施例提供的一种应用程序补丁包获取方法的实施环境图。该实施环境包括第一计算机设备101和第二计算机设备102，该第一计算机设备101是用户端的计算机设备，供用户使用，该第一计算机设备101上安装有多种应用程序，该第二计算机设备102既是开发端的计算机设备，供开发人员使用，又是应用服务器。该第一计算机设备101可以为智能手机、平板电脑或其他电子设备，该第二计算机设备102可以为台式电脑。开发人员可以通过该第二计算机设备102对应用程序进行修复，然后，该第二计算机设备102将更新后的该应用程序的安装包发送到该第一计算机设备101上。对于该第二计算机设备102来说，该第二计算机设备102还可以具有至少一种数据库，用以存储应用程序的用户信息、资源以及代码等等。

图2是本发明实施例提供的一种应用程序补丁包获取方法的流程图。参见图2，该实施例具体包括：

201、计算机设备获取应用程序的更新代码文件和更新资源。

在实际应用中，应用程序的开发编译过程中，需要不断地进行更新，例如，针对该应用程序出现的bug进行修复；或，在该应用程序添加新的功能模块等。针对上述问题，计算机设备对该应用程序的代码逻辑进行修改，以及增加或删除资源文件，例如图片等。

在本发明实施例中，计算机设备在该应用程序对应的项目工程中引入blink-plugin.jar，同时注入application类的oncreat方法以启动该项目工程的blink-plugin.jar，并配置该项目工程的环境目录，当计算机设备要对该应用程序的代码文件和资源进行改动时，直接在该项目工程的根目录命令中输入“blink”，即可启动blink-plugin.jar，用于对更新代码文件和更新资源进行编译。

202、计算机设备基于该更新代码文件生成对应的类文件。

在本发明实施例中，针对计算机设备获取到的更新代码文件，计算机设备通过编译器，例如javac(javacompiler，语言编程编译器)，将该更新代码文件编译成字节代码的class类文件。

203、计算机设备从类路径中调用该应用程序的依赖类文件，若类路径中没有该应用程序的依赖类文件，则生成该应用程序的依赖类文件，并存储在类路径中。

在实际应用中，当通过javac编译器将更新代码文件编译为类文件时，可能会有很多其他已经编译完成的类文件也被重复编译，出现这种情况的原因是该其他已经编译完成的类文件与更新代码文件被编译为的类文件之间存在依赖关系，每当有更新代码文件被编译成类文件时，其他已经编译完成的依赖类文件都会被重新编译。

因此，为了避免每次更新代码文件，该其他已经编译完成的依赖类文件被重新编译，造成计算机设备重复编译效率低下，本发明实施例将该其他已经编译完成的依赖类文件进行了缓存，计算机设备将该依赖类文件存储到类路径中，该类路径在javac编译器中通过选项classpath设置。

在本发明实施例中，当需要对该应用程序再次进行更新，则在通过javac编译器对更新代码文件进行编译时，会优先在该classpath类路径中搜索已经存储的依赖类文件，如果该javac编译器成功搜索到该依赖类文件，则直接调用该依赖类文件并将该更新代码文件编译成类文件；如果该javac编译器未搜索到该依赖类文件，则将该更新代码文件编译成类文件，将该依赖类文件进行重新编译并存储至classpath类路径中供后续调用。

204、计算机设备将该更新代码对应的类文件进行打包，生成该代码补丁包。

在本发明实施例中，将该更新代码文件编译成字节代码的class类文件后，为了使该更新代码文件在安卓系统中能够发挥作用，需要在计算机设备中通过dex命令将该class类文件打包成dex可执行文件，该dex可执行文件是安卓系统的一种可执行文件。进而，将该class类文件打包成dex可执行文件后，计算机设备通过打包工具，例如aapt(androidassetpackagingtool，安卓资源打包工具)将该dex可执行文件进行打包，生成该更新代码文件对应的代码补丁包。

基于步骤203，每次编译完成后，编译过的类文件及其依赖类文件都会被缓存在类路径中，因此，在下次生成该应用程序的补丁包时，只有该更新代码文件对应的类文件进行打包，这与将该应用程序的所有类文件一起进行打包相比，大大减少了打包时间。

需要说明的是，在只对代码进行更新，而资源没有更新的情况下，即需要打包的“res”文件夹为空白的情况下，需要建立一个配置文件，该配置文件中不包含任何资源。例如，建立一个空白的androidmanifest.xml文件，该androidmanifest.xml文件和“res”文件夹有相互依赖关系，该androidmanifest.xml文件是安卓系统的应用程序中必有的配置文件，该配置文件位于开发端的计算机设备中的整个项目工程的根目录，该配置文件用于存储该应用程序运行时所必要的配置信息等。将该空白的“res”文件夹、空白的androidmanifest.xml文件和更新代码文件一起进行打包，生成新的安装包。

205、计算机设备基于第一资源库中的最大资源标识和该更新资源的数量进行增量计算，得到该更新资源的资源标识。

在本发明实施例中，该资源包括但不限于：文字资源、图片资源、页面布局资源等，在安卓系统中，该资源存储在“res”文件夹中，第一资源库通过编译器自动收录该“res”文件夹中的所有资源，并根据这些资源建立对应的资源标识，例如，该“res”文件夹中每增加一个新资源，该第一资源库会自动收录该资源并生成该资源的资源标识。该第一资源库指的是存储有该应用程序的原有资源及资源标识的资源库，其中，一个资源标识用于对资源库中的一个资源进行唯一标记。

在本发明实施例中，第一资源库中的资源标识是按顺序依次递增的，因此，存在一个最大资源标识，根据某一类型的更新资源的数量，每增加一个资源，则在该最大资源标识的基础上+1，即可得到该更新资源的资源标识。例如，该第一资源库中某一类型资源的最大资源标识是0010，如果该类型的资源新增1个，则该更新资源的资源标识为0011,同理，如果该类型的资源新增n个，则该更新资源的资源标识分别为0011、0012、0013…0010+n。

需要说明的是，在相关技术中，在第一资源库中增加新的资源后，第一资源库中的所有资源标识则会进行重新编写，这会导致更新资源后的第一资源库与原来的第一资源库中的资源标识不一致，进而导致资源发生错乱，甚至是该应用程序运行错误，因此，为了避免上述情况，需要对第一资源库中的资源标识和更新资源的资源标识进行固定，使得后续资源标识不发生错乱。基于步骤205，本发明解决了，更新该应用程序的资源后，第一资源库中的资源标识没有发生改变，因此不会发生资源错乱的情况。

206、计算机设备基于该更新资源的资源标识和该第一资源库，合成第二资源库。

在本发明实施例中，基于步骤205，可以迅速地得到除页面布局资源之外的其他更新资源的资源标识，例如，更新的文字资源或图片资源的资源标识，因此，直接通过合成工具，例如blinkbuildcache.jar工具，将第一资源库中的该应用程序的原有资源、原有资源的资源标识、更新资源以及更新资源的资源标识，合成第二资源库，该第二资源库即包括所有的资源以及资源标识，上述过程避免了通过aapt工具对第一资源库中的所有资源标识重新编写，大大节省了时间。

207、当应用程序的页面布局没有发生改动时，计算机设备基于该更新资源的资源标识和第一部分资源标识映射文件，合成第二部分资源标识映射文件。

在本发明实施例中，资源标识映射文件用于确定资源和资源标识之间的对应关系，因此，也具有可以固定资源标识的功能，该第一部分资源标识映射文件为public.xml文件。基于步骤205，可以比较容易地得到更新资源的资源标识，因此，可以直接通过blinkbuildcache.jar工具的合成功能，将该第一部分资源标识映射文件和该更新资源的资源标识合成，得到第二部分资源标识映射文件。

需要说明的是，该第一部分资源标识映射文件不是基于第一资源库的全量资源获取到的资源标识映射文件，而是原有的资源标识文件，即原有的public.xml文件，该public.xml文件用于描述并记录第一资源库中原有资源的资源标识。某一类型的资源新增了一个，则在第一部分资源标识映射文件中加上一行该新增资源的资源标识，即得到第二部分资源标识映射文件。

208、计算机设备基于该第二资源库、该第二部分资源标识映射文件和该新全量资源生成该资源补丁包。

在本发明实施例中，该新全量资源包括更新资源和原有资源。计算机设备通过aapt工具对该第二资源库、该第二部分资源标识映射文件和该新全量资源进行编译，并打包成资源补丁包。

上述步骤206至208为应用程序的页面布局没有发生改动时，资源补丁包的生成过程，参见图4，该过程可以通过合成工具，将第一资源库和更新资源的资源标识合成第二资源库，将第一部分资源标识映射文件和更新资源的资源标识，合成第二部分资源标识映射文件，基于将该第二资源库、该第二部分资源标识映射文件和新全量资源，编译并打包成资源补丁包。通过上述过程，不需要基于第一资源库中的全量资源及资源标识分析出全量资源标识映射文件，仅需在第一部分资源标识映射文件的基础上，添加更新资源的资源标识，因此，大大节省了分析出全量资源标识映射文件的时间，提高了编译效率。

209、当应用程序的页面布局发生改动时，计算机设备基于该第一资源库，分析得到第一全量资源标识映射文件。

在本发明实施例中，blinkbuildcache.jar工具还具有识别更新资源的功能，在该页面布局发生改动时，例如，页面布局中增加新的版块，这会导致页面布局中增加新的版块的标识，如果仍使用步骤207的方法，则blinkbuildcache.jar工具只能识别更新的文字资源或图片资源等的资源标识，无法识别更新的页面布局资源，且步骤207中对应的public.xml文件中的更新资源的资源标识没有被定义，进而在后续运行过程中会出现报错的情况。

blinkbuildcache.jar工具还具有分析出第一全量资源标识的功能，基于上述情况，在该页面布局发生改动的情况下，本发明实施例获取该第一全量资源标识映射文件的具体过程如下：基于更新资源前的该第一资源库中的全量资源及资源标识，通过分析工具，例如blinkbuildcache.jar工具分析得到第一全量资源标识映射文件，该第一全量资源标识映射文件为第一全量public.xml文件和第一全量ids.xml文件，该public.xml文件用于描述原有资源的资源标识，该id.xml文件用于为该应用程序的相关资源提供唯一的资源标识。

210、计算机设备得到该第一全量资源标识映射文件后，基于该更新资源的资源标识和该第一全量资源标识映射文件，合成第二全量资源标识映射文件。

在本发明实施例中，计算机设备通过识别工具，例如check工具，识别到更新的页面布局资源，根据步骤205得到该更新的页面布局资源的资源标识，通过blinkbuildcache.jar工具，将该全量public.xml文件和该更新资源的资源标识合成，得到第二全量public.xml文件，同时，将该全量ids.xml文件和该更新资源的资源标识合成，得到第二全量ids.xml文件，该第二全量public.xml文件和该第二全量ids.xml文件即为该全量第二资源标识映射文件。

211、计算机设备基于该第二资源库、该第二全量资源标识映射文件和该新全量资源，生成该资源补丁包。

在本发明实施例中，基于步骤209至211，计算机设备通过aapt工具对获取到的该第二资源库、该第二全量public.xml文件、该第二全量ids.xml文件和该新全量资源进行编译，并打包成资源补丁包。

上述步骤209至211为应用程序的页面布局发生改动时，资源补丁包的生成过程，参见图5，该过程可以通过分析工具，基于更新资源前的第一资源库，分析出第一全量资源标识映射文件，通过合成工具，将第一资源库和更新资源的资源标识合成第二资源库，将第一全量资源标识映射文件和更新资源的资源标识，合成第二全量资源标识映射文件，基于该第二资源库、该第二全量资源标识映射文件和新全量资源，编译并打包成资源补丁包。通过上述过程，仅需基于更新资源的资源标识合成相应文件，避免了将新全量资源的资源标识全部重新编写，大大提高了编译效率。

在本发明实施例中，基于生成的代码补丁包和资源补丁包，打包成该应用程序的安装包，即apk文件，计算机设备将该安装包发送到应用服务器上，该应用服务器通过有线的方式，将该安装包推送到用户端的计算机设备。参加图3该用户端的计算机设备接收到该安装包后，，将该安装包插入到该应用程序对应的数组的第一个位置。当该应用程序重启时，通过安卓系统的类加载器顺序遍历该应用程序对应的数组中的dex可执行文件,由于该应用程序中出现问题的第一类文件的类名，与更新后的安装包中对应的第二类文件的类名相同，因此，当用户端的计算机设备加载到该第二类文件后，后续再检测到该第一类文件时，放弃加载该第一类文件,基于上述过程，实现对应用程序的更新。

本发明实施例在生成代码补丁包的过程中，对编译过的依赖类文件进行缓存，避免了后续生成该应用程序的其他代码补丁包时对该依赖类文件的重复编译，大大节省了时间。在生成资源补丁包的过程中，通过获取更新资源的资源标识，并基于该更新资源的资源标识合成相应文件，避免了对原有资源标识和更新资源标识的重新编写，大大提高了资源补丁包的生成效率，例如，在手机qq的更新过程中，对原有资源标识和更新资源标识进行重新编写需要16分钟，对代码进行修改并编译需要5分钟，本发明实施例仅需要24秒至40秒，整体编译打包的效率提高了7.5倍到40倍。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

图6是本发明实施例提供的一种应用程序补丁包获取装置的结构示意图。参见图6，该装置包括：

获取模块601，用于获取应用程序的更新代码文件和更新资源；

生成模块602，用于基于该更新代码文件，生成代码补丁包；

该获取模块601，还用于基于更新资源和第一资源库，获取该更新资源的资源标识，该第一资源库用于存储该应用程序的原有资源以及资源标识；

该生成模块602，还用于基于该更新资源的资源标识、第一资源库、第一资源标识映射文件以及新全量资源，生成资源补丁包，该第一资源标识映射文件为基于第一资源库获取到的用于固定资源标识的文件，该新全量资源包括更新资源和原有资源。

本发明实施例在生成资源补丁包的过程中，通过固定第一资源库中的资源标识，获取更新资源的资源标识，并基于该更新资源的资源标识合成相应文件，避免了对第一资源库中的资源标识和更新资源标识的重新编写，大大提高了资源补丁包的生成效率。

在一些实施例中，该生成模块602还用于：

基于该更新代码文件生成对应的类文件；

将该类文件存储到类路径中，并将该类文件进行打包，生成该代码补丁包；

当再次生成代码补丁包时，优先从该类路径中调用已存储的类文件。

在一些实施例中，该获取模块601还用于：

基于该第一资源库中的最大资源标识和该更新资源的数量进行增量计算，得到该更新资源的资源标识，一个资源标识用于对资源库中的一个资源进行唯一标记。

在一些实施例中，该生成模块602还用于：

当应用程序的页面布局没有发生改动时，基于该更新资源的资源标识和该第一资源库，合成第二资源库，该第二资源库用于存储该应用程序的原有资源、更新资源以及资源标识；

基于该更新资源的资源标识和第一部分资源标识映射文件，合成第二部分资源标识映射文件；

基于该第二资源库、该第二部分资源标识映射文件和该新全量资源生成该资源补丁包。

在一些实施例中，该生成模块602还用于：

当应用程序的页面布局发生改动时，基于该更新资源的资源标识和该第一资源库，合成该第二资源库；

基于该第一资源库分析得到第一全量资源标识映射文件，该第一全量资源标识映射文件为该第一资源库对应的全部资源标识映射文件；

基于该更新资源的资源标识和该第一全量资源标识映射文件，合成第二全量资源标识映射文件，该第二全量资源标识映射文件为第二资源库对应的全部资源标识映射文件；

基于该第二资源库、该第二全量资源标识映射文件和该新全量资源，生成该资源补丁包。

需要说明的是：上述实施例提供的应用程序补丁包获取装置在获取应用程序补丁包时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的应用程序补丁包获取装置与应用程序补丁包获取方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图7是本发明实施例提供的一种计算机设备的结构示意图，该计算机设备700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)701和一个或一个以上的存储器702，其中，该存储器702中存储有至少一条指令，该至少一条指令由该处理器701加载并执行以实现上述各个方法实施例提供的方法。当然，该计算机设备还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算机设备还可以包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括指令的存储器，上述指令可由终端中的处理器执行以完成上述实施例中的应用程序补丁包获取方法。例如，该计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，上述程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

上述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。