CN107391107A - 一种应用程序的修复方法和装置 - Google Patents

Abstract

本发明提供了一种应用程序的修复方法和装置，该方法包括：获取目标应用程序的补丁包信息，补丁包信息包括：应用程序的版本号；判断补丁包信息中应用程序的版本号与已安装的目标应用程序的版本号是否相同；若相同，则根据补丁包信息和本地补丁包信息，判断本地是否存储与补丁包信息对应的补丁包；若确定本地未存储有与补丁包信息对应的补丁包，则根据补丁包信息下载补丁包；当目标应用程序重启时，对下载的补丁包进行加载以对目标应用程序进行修复。本发明利用补丁包信息来判断是否需要下载对应的补丁包，进而利用该补丁包进行问题修复，缩短了修复周期、降低了修复成本并简化了修复步骤。

Description

一种应用程序的修复方法和装置

技术领域

本发明涉及应用程序修复技术领域，特别是涉及一种应用程序的修复方法和装置。

背景技术

在当今这个移动互联网突飞猛进的时代，为了满足并发掘用户对移动终端的使用需求，需要使开发的移动应用程序(App，application)具备更完善的功能、并能够给用户更好的使用体验。因此，移动互联网应用的开发、优化、测试、修复、发布、升级，再到用户体验的反馈，以及再次进行优化、测试、修复、发布...整个过程的周期也在缩短。

但是，对于已发布上线的App来说，即便只是新增一个非核心的小功能或者修复一些紧急漏洞(bug)，也只能按部就班地走完如图1所示的传统开发流程：对于一款对于已发布上线的App，经过用户反馈发现该App存在问题，那么开发人员需要对该款app进行问题修复或者新增一个小功能进行功能开发(具体体现为，对原始app中的部分代码进行修改或新增代码，得到新的代码文件)；然后，将新的代码文件进行编译，将编译后的结果打包成apk并签名；接着，对该apk进行功能测试，如果测试不通过则继续进行上述流程，如果测试通过则可以向各个应用市场和渠道发布该新版本app；接着用户可以在客户端对该app升级安装(即app覆盖安装)；用户使用后，可以将用户体验反馈至开发者，循环进行上述修复过程，从而再提供一个新版本app。

从上述描述可以看出，在传统的应用程序修复方案中，如需优化其一些功能，或者修改一些紧急的BUG，都需要进行重复的开发流程。举例来说，例如某银行的一款手机银行APP，V1.0版本刚上线投入用于使用之后，发现了一个比较严重的问题，可能给用户的财产带来风险。此时的解决方法是，研发人员解决问题并重新打包，提交给测试人员测试，再重新发布新版本V1.1，然后用户在客户端通过升级提示进而更新客户端的该手机银行App，最后才达到问题修复的目的。

由此可见，在传统的应用程序的修复方案中，整个修复流程的生命周期长，投入的人力、资金量大，对于已上线发布的应用而言，如需修改任何问题，哪怕仅仅是一行代码，也要走以上全部流程，要以付出巨大的成本作换包和重新发布等操作，最终以高版本升级更新的方式对用户终端设备侧的软件进行覆盖安装，才能解决其所存在的问题。而如果用户选择不更新当前版本，则无法解决问题。

因此，传统的应用程序的修复方案普遍存在着修复周期长、修复成本高以及修复步骤繁琐的问题。

发明内容

本发明提供了一种应用程序的修复方法和装置，以解决传统的应用程序的修复方案所存在的修复周期长、修复成本高以及修复步骤繁琐的问题。

为了解决上述问题，根据本发明的一个方面，本发明公开了一种应用程序的修复方法，应用于移动终端，包括：

获取目标应用程序的补丁包信息，所述补丁包信息包括：应用程序的版本号；

判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号是否相同；

若相同，则根据所述补丁包信息和本地补丁包信息，判断本地是否存储与所述补丁包信息对应的补丁包；

若确定本地未存储有与所述补丁包信息对应的补丁包，则根据所述补丁包信息下载所述补丁包；

当所述目标应用程序重启时，对下载的所述补丁包进行加载以对所述目标应用程序进行修复。

根据本发明的另一方面，本发明还公开了一种应用程序的修复装置，应用于移动终端，包括：

获取模块，用于获取目标应用程序的补丁包信息，所述补丁包信息包括：应用程序的版本号；

第一判断模块，用于判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号是否相同；

第二判断模块，用于若所述第一判断模块判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号相同，则根据所述补丁包信息和本地补丁包信息，判断本地是否存储与所述补丁包信息对应的补丁包；

下载模块，用于若所述第二判断模块确定本地未存储有与所述补丁包信息对应的补丁包，则根据所述补丁包信息下载所述补丁包；

修复模块，用于当所述目标应用程序重启时，对下载的所述补丁包进行加载以对所述目标应用程序进行修复。

与现有技术相比，本发明包括以下优点：

这样，本发明实施例通过获取目标应用程序的补丁包信息，并依据该补丁包信息的版本号来判断该补丁包信息对应的补丁包是否适用于移动终端侧所安装相应版本号的目标应用程序，在确定适用时，才会根据所获取的补丁包信息以及本地补丁包信息来判断是否需要下载对应的补丁包，进而利用该补丁包进行问题修复，避免了直接下载补丁包以及下载更新后的新版本应用程序所带来的软件问题修复周期长、修复成本高以及修复步骤繁琐的问题，缩短了修复周期、降低了修复成本并简化了修复步骤。

附图说明

图1是现有技术的一种应用程序的修复方法的步骤流程图；

图2是本发明的一种应用程序的修复方法实施例的步骤流程图；

图3本发明的一种应用程序的修复***实施例的架构图；

图4是本发明的另一种应用程序的修复***实施例的架构图；

图5是本发明的一种应用程序的修复装置实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图2，示出了本发明的一种应用程序的修复方法实施例的步骤流程图，应用于移动终端。

其中，在移动终端侧可以安装很多应用程序，那么当某款应用程序的部分功能存在缺陷或者需要增添一些新的功能时，可以采用本发明实施例的修复方法来对用户的移动终端侧的已安装app进行程序修复，避免开发端对该款app进行重新发布以及用户侧对新版本的app进行重新下载并覆盖安装所导致的app修复周期长、修复成本高以及修复步骤繁琐的问题。

本发明实施例的方法具体可以包括如下步骤：

步骤201，获取目标应用程序的补丁包信息，所述补丁包信息包括：应用程序的版本号；

其中，当发布的某款app存在bug或者增添新功能而需要修复时，开发端可以开发对该款app的补丁包，但是，app可能具有多个版本，因此，开发端可以针对不同版本的app开发不同的补丁包，而补丁包的补丁包信息中则包含有应用程序的版本号，即该补丁包所针对的应用程序的版本号。那么开发端可以将某款app的补丁包的补丁包信息下发。

移动终端侧就可以获取已安装的该款app的补丁包信息，其中，补丁包信息可以是针对某个版本的app的补丁包的一些策略信息。

步骤202，判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号是否相同；

其中，由于同一款app可能具有针对不同版本该app的多个补丁包，因此，移动终端侧需要判断所获取到的补丁包信息中的应用程序的版本号是否与该移动终端所安装的该款app的版本号相一致；

例如appA具有1.0版本、2.0版本，而移动终端用户侧安装的是1.0版本的appA，因此，该移动终端用户只需要利用针对1.0版本的appA的补丁包信息进行1.0版本的appA的问题修复，而不需要利用针对2.0版本的appA的补丁包信息进行问题修复。

若相同，则步骤203，根据所述补丁包信息和本地补丁包信息，判断本地是否存储与所述补丁包信息对应的补丁包；

其中，如果所获取的某个app的补丁包信息所针对的软件版本是与移动终端侧已安装的该app的版本相同，则可以根据该补丁包信息和本地补丁包信息来判断本地是否存储有与该补丁包信息对应的补丁包。

其中，可能移动终端侧已经下载了该款app的1.0版本的补丁包，因此，为了避免补丁包的重复下载，浪费存储资源，需要进行此步骤的判断。

若确定本地未存储有与所述补丁包信息对应的补丁包，则步骤204，根据所述补丁包信息下载所述补丁包；

其中，如果经过判断发现本地没有存储该补丁包信息对应的补丁包，则可以根据该补丁包信息来下载该补丁包。

步骤205，当所述目标应用程序重启时，对下载的所述补丁包进行加载以对所述目标应用程序进行修复。

其中，当移动终端侧的该目标应用程序(例如1.0版本的appA)重新启动时，本发明实施例的方法就可以对该补丁包进行加载从而对该1.0版本的appA进行问题修复。

这样，本发明实施例通过获取目标应用程序的补丁包信息，并依据该补丁包信息的版本号来判断该补丁包信息对应的补丁包是否适用于移动终端侧所安装相应版本号的目标应用程序，在确定适用时，才会根据所获取的补丁包信息以及本地补丁包信息来判断是否需要下载对应的补丁包，进而利用该补丁包进行问题修复，避免了直接下载补丁包以及下载更新后的新版本应用程序所带来的软件问题修复周期长、修复成本高以及修复步骤繁琐的问题，缩短了修复周期、降低了修复成本并简化了修复步骤。

可选地，在本申请的一个实施例中，所述补丁包信息包括：补丁包的第一加密信息，那么在执行步骤203时，可以通过判断所述本地补丁包信息中是否存在加密信息与所述第一加密信息相同的补丁包信息；若存在，则确定本地存储有与所述补丁包信息对应的补丁包；若不存在，则确定本地未存储有与所述补丁包信息对应的补丁包。

具体而言，在移动终端侧获取到的补丁包信息中可以包含对应补丁包的加密信息，并将该加密信息作为本地存储有相应补丁包的标识信息，因此，如果经过判断本地存储的补丁包信息中存在相应的加密信息，则可以确定本地已经存储有相应的补丁包，相反，则本地不存储有相应的补丁包。

这样，通过以补丁包的加密信息作为补丁包信息的一部分，那么在获取到补丁包信息后，可以基于该加密信息(例如MD5值)来确定本地是否存储有相应的补丁包，能够避免补丁包的重复下载。

可选地，在另一个实施例中，在步骤204之后，根据本发明实施例的方法还包括：将下载的所述补丁包进行本地存储；将获取的所述目标应用程序的所述补丁包信息存储至本地补丁包信息；在所述本地补丁包信息中将所述补丁包信息的状态设置为未修复。

具体而言，可以将下载的补丁包存储至移动终端的本地存储目录中，并将所获取到的上述补丁包信息存储至本地补丁包信息中，其中，本地补丁包信息中每个补丁包是一条记录，每条记录中包含相应补丁包的各个策略信息，例如，补丁包对应的app版本、补丁包大小、补丁包的下载地址、补丁包的加密信息、补丁包的修复状态等。此外，虽然该补丁包已经进行了本地存储，但还没有采用该补丁包进行问题修复，因此，还需要将本地补丁包信息中相应记录的状态参数设置为未修复。

这样，本发明实施例通过每次下载一个补丁包后，就将该补丁包的策略信息存储至本地补丁包信息中，其中，该本地补丁包信息可以是数据库中的一个信息表，使得补丁包信息能够反映已存储的补丁包的一些策略信息，利于借助于本地补丁包信息来了解补丁包的状态。

此外，在另一个实施例中，在执行步骤205中的对下载的所述补丁包进行加载以对所述目标应用程序进行修复的步骤之前，根据本发明实施例的方法还包括：

当所述目标应用程序重启时，从所述本地补丁包信息中查找与已安装的所述目标应用程序的版本号相同、且状态为未修复的目标补丁包信息；

在本地存储的补丁包中读取与所述目标补丁包信息对应的目标补丁包；

对所述目标补丁包进行解密。

具体而言，当该目标应用程序(例如1.0版本的appA)重新启动时，本发明实施例的方法可以在本地补丁包信息(例如多条记录)中查找1.0版本的appA至少一条记录，然后再这至少一条记录中查找状态为未修复的目标记录(即目标补丁包信息)；其中，由于每条记录都有补丁包的唯一标识，因此，可以基于该目标记录的唯一标识来在本地存储的补丁包中读取标识与该唯一标识相同的目标补丁包，最后，对读取到的目标补丁包进行解密。

其中，由于同一个版本的app可能存在多个补丁包，而同一款的app在不同版本又可能存在多个补丁包，因此，这里通过从所述本地补丁包信息中查找与已安装的所述目标应用程序的版本号相同、且状态为未修复的目标补丁包信息，能够将某个版本号的app的所有补丁包进行批量处理(例如批量读取和解密等)，便于后续的批量修复。

此外，由于移动终端侧下载的补丁包是预先经过加密的，因此，在读取到目标补丁包后，需要进行解密，才能够进行后续的打补丁操作。这样，加密传输的补丁包可以保证补丁包的传输安全性。

另外，在一个实施例中，在对该目标补丁包解密后，可以对该目标补丁包进行哈希运算，从而得到目标补丁包的摘要信息，对应于上述加密信息(例如MD5值)，这里为了确保移动终端所下载的目标补丁包是对应于所获取的补丁包信息的，可以将运算得到的MD5值与获取到的补丁包信息中的MD5值进行对比，如果相同，则说明目标补丁包通过了完整性校验，即，所下载的目标补丁包是准确的。

相应的，在另一个实施例中，在执行步骤205中的所述对下载的所述补丁包进行加载以对所述应用程序进行修复的步骤时，可以通过以下方式来实现：

读取解密后的所述目标补丁包中的目标dex文件；

将所述目标dex文件注入类加载器；

在所述类加载器中对所述目标dex文件进行加载，得到新增和/或已修改的类文件，其中，所述类加载器中与所述已修改的类文件的类名称相同的原始类文件被所述已修改的类文件替换；

在所述本地补丁包信息中将所述补丁包信息的状态设置为已修复。

其中，由于本发明实施例的应用程序的修复方法时基于安卓(Android)***的Dex分包技术的，即，在某个app的代码中找到需要问题修复的类文件进行修改测试后，将编译好的修复后的类文件打包到一个dex文件中，从而生成针对待修复问题的补丁包。因此，这里需要读取目标补丁包中的目标dex文件，并将其注入到类加载器中，然后，在类加载器中对所述目标dex文件进行加载，得到新增和/或已修改的类文件，其中，所述类加载器中与所述已修改的类文件的类名称相同的原始类文件被所述已修改的类文件替换；同时将本地补丁包信息中目标记录的状态设置为已修复。

这样，本发明实施例能够通过新增类文件或修改类文件来实现对安卓***的移动终端的应用程序的热修复，操作简单，提升了修复效率。

对应于上述修复方法，图3示出了本发明一个实施例的应用程序的修复***的架构图。

对于已经上线发布的APP，当有功能改动或者问题修复时，就可以采用图3所示的架构图流程进行修复。

首先，开发与测试团队发现了该已经上线发布的app的问题后，可以在需要问题修复的Java文件中进行修改测试，然后将测试通过的Java文件编译成class文件，最后将类(class)文件打包到一个dex中，生成针对待修复问题的补丁包；

然后，开发与测试团队将该补丁包上传到web管理平台；

接着，web管理平台将接收到的补丁包再上传到服务器，同时将该补丁包的策略信息配置到服务器；

然后，服务器就可以存储该补丁包，并根据web管理平台在服务器上配置的对应该补丁包的策略信息生成补丁策略，最后，将补丁策略下发至安卓***的移动终端的app侧；

最后，Android***的移动终端APP侧可以接收补丁策略，并根据接收的补丁策略来下载补丁包(即补丁文件)，并在该app重新启动时，将该补丁包中的dex文件动态的注入到***的类加载器(ClassLoader)中，dex文件得到加载，得到修复的类文件，其中，如果该修复的类文件为针对问题类文件而修复的同名类文件，则该修复的类文件可以将类加载器中同名的有问题的类文件替换；而如果该修复的类文件为新增的类文件，则可以直接追加到类加载器中进行加载。这样，就能及时修复app的问题，以及完善APP的功能，保障了已发布app的实时可用性、有效性，也大大降低了维护成本、缩短了维护周期。

其中，对于上述流程中的补丁策略的下发时机，可以是服务器侧定期向移动终端侧下发，也可以是移动终端侧周期性的向服务器获取，本发明对此并不做具体限制。

在实际应用中，社交软件比较流行内部自嵌一些使用的小应用、小程序，例如通讯录同步功能、运动记录功能、记事本功能等，但是这些小应用、小程序并非是APP的核心功能，也非需要升级更新的主要功能，那么在需要增添新的小功能和/或已上线发布的app存在bug的情况下，就可以采用本发明实施例的修复方法来对Android***的移动终端的app进行快速热修复。使得广大的使用者，在不需要更新升级的情况下就可以使用app最新的功能和/或修复app当前存在bug。

那么参照图4，以某上线的网络社交软件在存在多个版本的情况下添加一个新的内部应用功能(例如：通讯录同步功能)为例，来对本发明实施例的上述方法进行详细阐述：

本实施例中涉及以下终端：Android***的移动终端、服务器、WEB管理平台以及开发和测试终端；其中，Android***的移动终端面向所有用户，服务器做后台支持，WEB管理平台由管理员使用。

(1)在app上线后，开发或测试人员发现app的严重BUG需要修复，或者需求人员想增加一个小功能，这时，开发人员仅需在当前发布的版本之上，修改有问题的类文件，将改动的类文件分包，生成独立的dex文件。

本例中，具体而言可以对通讯录同步功能作需求分析，然后，研发人员进行通讯录同步的功能开发，将通讯录同步功能所添加和改动的编译后的类文件(class文件)分包，生成独立的dex文件(可以由Dalvik虚拟机执行的文件)。

其中，对于dex分包技术：对于开发完整的app文件，可以开发程序得到Java文件，然后再对Java文件编译产生class文件，接着，dex工具会把class文件处理成dex文件，最后把资源文件(例如图片数据等)和dex文件等打包成apk文件。正常打包签名的APK只有一个.dex文件。dex分包技术的原理是在编译的时候，将目标类文件编译到单独的dex文件中，以供类加载器的动态加载使用。

而本例中，由于不涉及开发完整的app，只涉及部分类文件的生成，因此，生成dex文件的过程截止到dex工具会把class文件处理成dex文件，不包括将资源文件(例如图片数据等)和dex文件等打包成apk文件的步骤。

(2)测试人员在当前发布的app版本基础上，测试步骤(1)中的dex包(即，进行通讯录同步功能的测试)；测试不通过则回归测试，测试通过则以该dex包作为当前版本新功能的补丁包，由管理员通过WEB管理平台上传至服务器；此外，WEB管理平台还会将该补丁包的一些属性信息(包括补丁包对应的app版本、补丁包大小等信息)配置到服务器。

(3)服务器可以加密存储该接收到的补丁包文件，得到加密后的补丁包文件，并采用相应的加密算法生成该补丁包文件的哈希值(即，上述方法实施例中的加密信息)，例如生成该补丁包文件的MD5值；然后，服务器就可以根据该补丁包的配置信息(即上述属性信息)以及该MD5值和加密后的补丁包在服务器上的存储地址，生成通讯录同步功能的策略信息，并将策略信息(包括补丁包对应的app版本、补丁包大小、补丁包在服务器上的下载地址、MD5值等信息)下发到移动终端侧；

(4)Android***客户端APP接收服务器下发的补丁包的策略信息；然后，读取本地数据库(DB)的补丁表中是否有该app相同版本号的补丁信息，如果没有上述补丁信息，则从服务器下载该补丁包并存储(其中，补丁包的下载地址可以参照策略信息中的下载地址)；如果有上述补丁信息，则判断DB补丁表(包括多条补丁记录，每条补丁记录对应一个补丁包)中该相同版本号的补丁记录中是否有MD5值与策略信息中的MD5值相同的补丁记录，如果没有该补丁记录，则从服务器下载该补丁包并存储；如果有上述补丁记录，则忽略该补丁包，不作处理。

这样，移动终端侧在接收服务器下发的通讯录同步的补丁包的策略信息后，就可以通过策略信息中版本号和MD5值的校验，来判断本地是否存储有该策略信息对应的补丁包，判断通过则下载该补丁包。

(5)Android***的移动终端侧，该APP重新启动时，本发明实施例就可以在本地存储目录中读取已下载的移动终端已安装的当前版本号的、且状态为未修复的补丁包(这里经过加密处理通讯录同步功能的补丁包)；然后，解密该补丁包，并读取解密补丁包中的dex文件(这里叫做目标dex文件，为了区分于该app发布时的dex文件)，并动态的将目标dex文件注入安卓***的ClassLoader，ClassLoader对目标dex文件进行加载，得到目标类文件，ClassLoader就会将ClassLoader中有问题的同名类文件替换为该目标类文件，此时新增的类文件会在类加载器中添加，而修改的类文件则会在类加载器中覆盖，到此，通讯录同步小功能添加完成。

其中，对于类加载器动态加载dex技术：在app重启的时候，类加载器会加载APP原有的dex文件(即，上述打包签名APK时生成的唯一的.dex文件)中的类文件，此时，类加载器再读取补丁包中的独立的目标dex文件，然后，通过反射获取PathClassLoader中的DexPathList中的Element数组(已加载了原有的dex文件)，以及DexClassLoader中的DexPathList中的Element数组(将补丁包中的目标dex文件加载进去)，然后，将两个Element数组合并，再将合并后的Element数组赋值给PathClassLoader的Element数组，到此，动态注入补丁包dex完毕，新增的类文件会在类加载器中添加，而修改的类文件则会在类加载器中覆盖被覆盖，app继续运行(具有了新增的通讯录同步功能)，同时，在替换了类文件后，还可以在本地的数据库补丁表中将该补丁包对应的补丁记录的状态设置为已修复。

由此可见，本发明实施例的Android***的移动终端快速热修复的技术方案可以快速、准确、高效地修复已发布APP尚存的严重BUG，免去了重新发布APP，降低了app的更新升级成本；并且，能够在用户毫无感知的情况下默默的修复问题或新增功能，避免了由于用户未及时更新升级而造成BUG未及时修复的严重后果；提升了用户体验。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

与上述本发明实施例所提供的方法和***相对应，参照图5，示出了本发明一种应用程序的修复装置实施例的结构框图，应用于移动终端，具体可以包括如下模块：

获取模块51，用于获取目标应用程序的补丁包信息，所述补丁包信息包括：应用程序的版本号；

第一判断模块52，用于判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号是否相同；

第二判断模块53，用于若所述第一判断模块52判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号相同，则根据所述补丁包信息和本地补丁包信息，判断本地是否存储与所述补丁包信息对应的补丁包；

下载模块54，用于若所述第二判断模块53确定本地未存储有与所述补丁包信息对应的补丁包，则根据所述补丁包信息下载所述补丁包；

修复模块55，用于当所述目标应用程序重启时，对下载的所述补丁包进行加载以对所述目标应用程序进行修复。

在本发明的一个可选实现方式中，所述补丁包信息包括：补丁包的第一加密信息，所述第二判断模块53包括：

判断子模块，用于判断所述本地补丁包信息中是否存在加密信息与所述第一加密信息相同的补丁包信息；

第一确定子模块，用于若所述判断子模块判断所述本地补丁包信息中存在加密信息与所述第一加密信息相同的补丁包信息，则确定本地存储有与所述补丁包信息对应的补丁包；

第二确定子模块，用于若所述判断子模块判断所述本地补丁包信息中不存在加密信息与所述第一加密信息相同的补丁包信息，则确定本地未存储有与所述补丁包信息对应的补丁包。

在本发明的一个可选实现方式中，所述装置还包括：

第一存储模块，用于将下载的所述补丁包进行本地存储；

第二存储模块，用于将获取的所述目标应用程序的所述补丁包信息存储至本地补丁包信息；

设置模块，用于在所述本地补丁包信息中将所述补丁包信息的状态设置为未修复。

在本发明的一个可选实现方式中，所述装置还包括：

查找模块，用于当所述目标应用程序重启时，从所述本地补丁包信息中查找与已安装的所述目标应用程序的版本号相同、且状态为未修复的目标补丁包信息；

读取模块，用于在本地存储的补丁包中读取与所述目标补丁包信息对应的目标补丁包；

解密模块，用于对所述目标补丁包进行解密。

在本发明的一个可选实现方式中，所述修复模块55包括：

读取子模块，用于读取解密后的所述目标补丁包中的目标dex文件；

注入子模块，用于将所述目标dex文件注入类加载器；

加载子模块，用于在所述类加载器中对所述目标dex文件进行加载，得到新增和/或已修改的类文件，其中，所述类加载器中与所述已修改的类文件的类名称相同的原始类文件被所述已修改的类文件替换；

设置子模块，用于在所述本地补丁包信息中将所述补丁包信息的状态设置为已修复。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种应用程序的修复方法和一种应用程序的修复装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种应用程序的修复方法，其特征在于，应用于移动终端，包括：

获取目标应用程序的补丁包信息，所述补丁包信息包括：应用程序的版本号；

判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号是否相同；

若相同，则根据所述补丁包信息和本地补丁包信息，判断本地是否存储与所述补丁包信息对应的补丁包；

若确定本地未存储有与所述补丁包信息对应的补丁包，则根据所述补丁包信息下载所述补丁包；

当所述目标应用程序重启时，对下载的所述补丁包进行加载以对所述目标应用程序进行修复。

2.根据权利要求1所述的方法，其特征在于，所述补丁包信息包括：补丁包的第一加密信息，所述根据所述补丁包信息和本地补丁包信息，判断本地是否存储与所述补丁包信息对应的补丁包，包括：

判断所述本地补丁包信息中是否存在加密信息与所述第一加密信息相同的补丁包信息；

若存在，则确定本地存储有与所述补丁包信息对应的补丁包；

若不存在，则确定本地未存储有与所述补丁包信息对应的补丁包。

3.根据权利要求1所述的方法，其特征在于，所述若确定本地未存储有与所述补丁包信息对应的补丁包，则根据所述补丁包信息下载所述补丁包之后，所述方法还包括：

将下载的所述补丁包进行本地存储；

将获取的所述目标应用程序的所述补丁包信息存储至本地补丁包信息；

在所述本地补丁包信息中将所述补丁包信息的状态设置为未修复。

4.根据权利要求3所述的方法，其特征在于，所述对下载的所述补丁包进行加载以对所述目标应用程序进行修复之前，所述方法还包括：

当所述目标应用程序重启时，从所述本地补丁包信息中查找与已安装的所述目标应用程序的版本号相同、且状态为未修复的目标补丁包信息；

在本地存储的补丁包中读取与所述目标补丁包信息对应的目标补丁包；

对所述目标补丁包进行解密。

5.根据权利要求4所述的方法，其特征在于，所述对下载的所述补丁包进行加载以对所述目标应用程序进行修复，包括：

读取解密后的所述目标补丁包中的目标dex文件；

将所述目标dex文件注入类加载器；

在所述类加载器中对所述目标dex文件进行加载，得到新增和/或已修改的类文件，其中，所述类加载器中与所述已修改的类文件的类名称相同的原始类文件被所述已修改的类文件替换；

在所述本地补丁包信息中将所述补丁包信息的状态设置为已修复。

6.一种应用程序的修复装置，其特征在于，应用于移动终端，包括：

获取模块，用于获取目标应用程序的补丁包信息，所述补丁包信息包括：应用程序的版本号；

第一判断模块，用于判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号是否相同；

第二判断模块，用于若所述第一判断模块判断所述补丁包信息中应用程序的版本号与已安装的所述目标应用程序的版本号相同，则根据所述补丁包信息和本地补丁包信息，判断本地是否存储与所述补丁包信息对应的补丁包；

下载模块，用于若所述第二判断模块确定本地未存储有与所述补丁包信息对应的补丁包，则根据所述补丁包信息下载所述补丁包；

修复模块，用于当所述目标应用程序重启时，对下载的所述补丁包进行加载以对所述目标应用程序进行修复。

7.根据权利要求6所述的装置，其特征在于，所述补丁包信息包括：补丁包的第一加密信息，所述第二判断模块包括：

判断子模块，用于判断所述本地补丁包信息中是否存在加密信息与所述第一加密信息相同的补丁包信息；

第一确定子模块，用于若所述判断子模块判断所述本地补丁包信息中存在加密信息与所述第一加密信息相同的补丁包信息，则确定本地存储有与所述补丁包信息对应的补丁包；

第二确定子模块，用于若所述判断子模块判断所述本地补丁包信息中不存在加密信息与所述第一加密信息相同的补丁包信息，则确定本地未存储有与所述补丁包信息对应的补丁包。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第一存储模块，用于将下载的所述补丁包进行本地存储；

第二存储模块，用于将获取的所述目标应用程序的所述补丁包信息存储至本地补丁包信息；

设置模块，用于在所述本地补丁包信息中将所述补丁包信息的状态设置为未修复。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

查找模块，用于当所述目标应用程序重启时，从所述本地补丁包信息中查找与已安装的所述目标应用程序的版本号相同、且状态为未修复的目标补丁包信息；

读取模块，用于在本地存储的补丁包中读取与所述目标补丁包信息对应的目标补丁包；

解密模块，用于对所述目标补丁包进行解密。

10.根据权利要求9所述的装置，其特征在于，所述修复模块包括：

读取子模块，用于读取解密后的所述目标补丁包中的目标dex文件；

注入子模块，用于将所述目标dex文件注入类加载器；

加载子模块，用于在所述类加载器中对所述目标dex文件进行加载，得到新增和/或已修改的类文件，其中，所述类加载器中与所述已修改的类文件的类名称相同的原始类文件被所述已修改的类文件替换；

设置子模块，用于在所述本地补丁包信息中将所述补丁包信息的状态设置为已修复。