CN107179925A - 热更新方法及装置 - Google Patents

Abstract

本申请实施例提供一种热更新方法及装置，根据第一压缩文件获取第一应用程序的第一类列表，第一类列表包含第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；根据第二压缩文件获取第二应用程序的第二类列表，第二类列表包含第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；根据第一映射关系与第二映射关系，确定修复类，修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；根据修复类更新第一应用程序。该过程中，通过对应用程序进行热更新，实现降低更新应用程序复杂度及成本的目的。

Description

热更新方法及装置

技术领域

本申请实施例涉及计算机技术，尤其涉及一种热更新方法及装置。

背景技术

随着互联网的发展，应用程序(Application，APP)等的种类和数量越来越多。开发人员通过开发各种APP来满足用户的需求。

APP被开发出来后，不可避免的需要更新。更新时，厂商到服务器发布新版本的APP，用新版本的APP覆盖旧版本的APP，用户卸载本地旧版本的APP，并到服务器下载新版本的APP，对厂商和用户来说，该更新过程及其复杂且成本太高。

因此，如何对APP进行更新，实为业界亟待解决的问题。

发明内容

本申请实施例提供一种热更新方法及装置，通过对应用程序进行热更新，实现降低更新应用程序复杂度及成本的目的。

第一方面，本申请实施例提供一种热更新方法，包括：

根据第一压缩文件获取第一应用程序的第一类列表，所述第一类列表包含所述第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；

根据第二压缩文件获取第二应用程序的第二类列表，所述第二类列表包含所述第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；

根据所述第一映射关系与所述第二映射关系，确定修复类，所述修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；

根据所述修复类更新所述第一应用程序。

在一种可行的设计中，所述根据所述修复类更新所述第一应用程序，包括：

将所述修复类封装成修复dex文件；

将所述修复dex文件放置在路径列表的首位，所述路径列表包含所述第一应用程序的第一类对应的dex文件。

在一种可行的设计中，所述将所述dex文件放置在路径列表的首位之后，还包括：

生成所述修复dex文件的属性；

将所述dex文件的属性写入第一文件，并用私钥加密所述第一文件；

将用私钥加密后的第一文件写入第二文件；

根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件。

在一种可行的设计中，所述根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件之后，还包括：

发布所述补丁文件，以使得客户端对所述补丁文件进行完整性校验和身份校验。

在一种可行的设计中，所述根据所述第一映射关系与所述第二映射关系，确定修复类之前，还包括：

采用映射mapping文件混淆所述第一类；

采用所述mapping文件混淆所述第二类，所述第一类的第一类名和所述第二类的第二类名相同。

在一种可行的设计中，所述采用映射mapping文件混淆所述第一类之前，还包括：

判断是否存在所述Mapping文件；

若不存在，则构建所述Mapping文件。

在一种可行的设计中，所述第一类属性为所述第一类的消息摘要算法MD5值，所述第二类属性为所述第二类的消息摘要算法MD5值。

第二方面，本申请实施例提供一种热更新装置，包括：

第一获取模块，用于根据第一压缩文件获取第一应用程序的第一类列表，所述第一类列表包含所述第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；

第二获取模块，用于根据第二压缩文件获取第二应用程序的第二类列表，所述第二类列表包含所述第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；

确定模块，用于根据所述第一映射关系与所述第二映射关系，确定修复类，所述修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；

修复模块，用于根据所述修复类更新所述第一应用程序。

在一种可行的设计中，所述修复模块，具体用于将所述修复类封装成修复dex文件；将所述修复dex文件放置在路径列表的首位，所述路径列表包含所述第一应用程序的第一类对应的dex文件。

在一种可行的设计中，上述的装置还包括：

加密模块，用于在所述修复模块将所述dex文件放置在路径列表的首位之后，生成所述修复dex文件的属性；将所述dex文件的属性写入第一文件，并用私钥加密所述第一文件；将用私钥加密后的第一文件写入第二文件；根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件。

在一种可行的设计中，上述的装置还包括：

发布模块，用于在所述加密模块根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件之后，发布所述补丁文件，以使得客户端对所述补丁文件进行完整性校验和身份校验。

在一种可行的设计中，上述的装置还包括：

混淆模块，用于在所述确定模块根据所述第一映射关系与所述第二映射关系，确定修复类之前，采用映射mapping文件混淆所述第一类；采用所述mapping文件混淆所述第二类，所述第一类的第一类名和所述第二类的第二类名相同。

在一种可行的设计中，所述混淆模块在采用映射mapping文件混淆所述第一类之前，还用于判断是否存在所述Mapping文件；若不存在，则构建所述Mapping文件。

在一种可行的设计中，所述第一类属性为所述第一类的消息摘要算法MD5值，所述第二类属性为所述第二类的消息摘要算法MD5值。

本申请实施例提供的热更新方法及装置，根据第一压缩文件获取第一应用程序的第一类列表，第一类列表包含第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；根据第二压缩文件获取第二应用程序的第二类列表，第二类列表包含第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；根据第一映射关系与第二映射关系，确定修复类，修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；根据修复类更新第一应用程序。该过程中，通过对应用程序进行热更新，实现降低更新应用程序复杂度及成本的目的。

附图说明

图1为本申请热更新方法实施例一的流程图；

图2为本申请热更新方法所适用的类加载的示意图；

图3为本申请热更新方法中dex文件的生成过程示意图；

图4为本申请热更新方法中修复dex文件的生成过程示意图；

图5A为本申请热更新方法中的加密过程示意图；

图5B为本申请热更新方法中的解密过程示意图；

图6为本申请热更新装置实施例一的结构示意图；

图7为本申请热更新装置实施例二的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。以下内容为结合附图及较佳实施例，对依据本申请申请的具体实施方式、结构、特征及其功效的详细说明。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

通常来说，移动互联网行业应用程序可分为两种，一种是基于本地操作系统，如iOS或Android操作系统运行的APP，称之为Native APP；一种是基于智能终端的浏览器运行的Web APP。对于Native APP来说，开发人员可以基于操作系统平台开发代码以进行APP的开发；或者，在APP内直接引入由前端开发人员提供的HTML5页面。APP被开发出来后，不可避免的需要更新。更新时，厂商到服务器发布新版本的APP，用新版本的APP覆盖旧版本的APP，用户卸载本地旧版本的APP，并到服务器下载新版本的APP，对厂商和用户来说，该更新过程及其复杂且成本太高。因此，如何对APP进行更新，实为业界亟待解决的问题

有鉴于此，本申请实施例提供一种热更新方法及装置，通过对应用程序进行热更新，实现降低更新应用程序复杂度及成本的目的。

图1为本申请热更新方法实施例一的流程图，包括：

101、根据第一压缩文件获取第一应用程序的第一类列表，所述第一类列表包含所述第一应用程序中的第一类的第一类名与第一类属性的第一映射关系。

本申请实施例中，一个应用程序包括多个类(class)，热更新的基础元素是类，即用修复类替换有问题(bug)的类，以下将待更新的应用程序称之为第一应用程序，将第一应用程序包含的类称之为第一类，将对第一应用程序包含的多个第一类进行压缩得到的文件称之为第一压缩文件，将第一类的名称称之为第一类名；将对第一应用程序中的第一类进行修复得到的应用程序称之为第二应用程序，将第二应用程序包含的类称之为第二类，将对第二应用程序包含的多个第二类进行压缩得到的文件称之为第二压缩文件，将第二类的名称称之为第二类名。

本步骤中，在根据第一应用程序获得第一压缩文件后，根据该第一压缩文件，获取第一类列表，第一类列表中包含第一应用程序中的第一类的第一类名与第一类属性的第一映射关系。其中，第一类属性例如为第一类的消息摘要算法((Message-Digest Algorithm，MD)5值。也就是说，第一应用程序中的每个第一类具有第一类名和相应的MD5值。

102、根据第二压缩文件获取第二应用程序的第二类列表，所述第二类列表包含所述第二应用程序中的第二类的第二类名与第二类属性的第二映射关系。

本步骤中，在根据第二应用程序获得第二压缩文件后，根据该第二压缩文件，获取第二类列表，第二类列表中包含第二应用程序中的第二类的第二类名与第二类属性的第二映射关系。其中，第二类属性例如为第二类的MD5值。也就是说，第二应用程序中的每个第二类具有第二类名和相应的MD5值。

103、根据所述第一映射关系与所述第二映射关系，确定修复类，所述修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类。

本步骤中，对第一类列表和第二类列表进行比对，确定出第一类名与第二类名相同，但第一类属性和第二类属性不同的类。例如，第一应用程序包含的第一类分别为A.class、B.class、C.class，第一类名分别为A、B、C，MD5值分别为a、b、c；第二应用程序包含的第二类分别为A1.class、B1.class、C1.class，第二类名分别为A1、B1、C1，MD5值分别为a1、b1、c1，若A＝A1，B＝B1，C≠C1，a≠a1，b≠b1，c≠c1，则修复类为A1.class、B1.class。其中，A1.class是对A.class进行修复得到的，B1.class是对B.class进行修复得到的。

104、根据所述修复类更新所述第一应用程序。

在得到修复类后，根据修复类对第一应用程序进行更新。例如，第一应用程序已被终端下载到本地，则服务器只需要将修复类进行处理并发送给终端，终端根据该修复类对第一应用程序进行更新，更新过程中，无需关闭第一应用程序，而是在线对第一应用程序进行更新，即实现热更新。

本申请实施例提供的热更新方法，根据第一压缩文件获取第一应用程序的第一类列表，第一类列表包含第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；根据第二压缩文件获取第二应用程序的第二类列表，第二类列表包含第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；根据第一映射关系与第二映射关系，确定修复类，修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；根据修复类更新第一应用程序。该过程中，通过对应用程序进行热更新，实现降低更新应用程序复杂度及成本的目的。

为了更清楚的描述本申请实施例所述的热更新方法，下面，先对类的加载过程进行详细描述。

具体的，基于类加载(ClassLoader)进行热更新，类加载将类的加载任务委托给路径列表(pathlist)，路径列表是Dexpathlist类型的。通过Dexpathlist类型的路径列表进行类加载时，循环遍历元素(Element)，从元素中确定出要加载的类。元素实质上是dex文件的一个封装，每一个dex文件对应一个Element，而每一个dex是根据至少一个类的压缩文件得到的。本申请实施例中，将修复类类封装成修复dex文件，将该修复dex文件放置在路径列表的首位，路径列表包括所述第一应用程序的第一类对应的dex文件。然后，进行类加载时，首先加载的是修复类。而且，同名的类只会被加载一次，当修复类和有bug的类的名称相同时，由于之前已经加载过修复类，因此不会再加载有bug的类。具体的，可参见图2，图2为本申请热更新方法所适用的类加载的示意图。

请参照图2，路径列表中有两个类，名称均为WB.class，而该两个类的属性不同，即MD5值不同，第一个WB.class被封装到class.dex中，第二个WB.class被封装到class1.dex中。由于加载时，对于同一个名称仅加载一次，因此，仅加载首位的WB.class，不加载第二个WB.class。

由上述可知：类被封装在dex文件中。下面，对如何生成dex文件进行详细说明。具体的，可参见图3，图3为本申请热更新方法中dex文件的生成过程示意图。

请参照图3，原始的代码文件，如“.Java文件”通过编译生成类文件，即“.class文件”，类文件经过打包得到压缩文件，即“.jar文件”，最后，dx命令将压缩文件生成能够被虚拟机，如Dalvik识别的dex文件。

图3展示了一个dex文件的生成过程。根据图3可知，对修复类执行如图3所示的各个步骤，即可得到修复dex文件。若通过手动执行图3所示的步骤，则生成修复dex文件的过程复杂、成本高。因此，本申请实施例中，智能的生成修复dex文件。

本申请实施例中，更新前，对所有的class(第一类)文件进行打包生成压缩文件，即生成第一压缩文件；更新后，对所有的class(第二类)文件打包生成第二压缩文件。根据第一压缩文件和第二压缩文件得到不同的dex文件。该过程中，第一压缩文件是所有第一类的压缩文件，第二压缩文件是所有第二类的压缩文件。基于此可知：可以根据第一压缩文件和第二压缩文件，确定出修复类，然后将修复类进行打包生成修复压缩文件并进一步的生成修复dex文件。具体的，可参见图4，图4为本申请热更新方法中修复dex文件的生成过程示意图。

请参照图4，在对第一应用程序生成dex文件之前，解压缩第一压缩文件，获得第一类列表，同理，在对第二应用程序生成dex文件之前，解压缩第二压缩文件，获得第二类列表，第一类列表包含第一应用程序中的第一类的第一类名与第一类属性的第一映射关系，第二类列表包含第二应用程序中的第二类的第二类名与第二类属性的第二映射关系。之后，根据第一映射关系与第二映射关系确定出修复类，即第一类名与第二类相同、第一类属性与第二类属性不同的类；然后，将修复类进行打包生成修复压缩文件并进一步的生成修复dex文件。

可选的，在本申请一示例中，根据所述第一映射关系与所述第二映射关系，确定修复类之前，还采用映射mapping文件混淆所述第一类；采用所述mapping文件混淆所述第二类，所述第一类的第一类名和所述第二类的第二类名相同。

具体的，两次混淆过程中，若同一个类采用不同的mapping文件混淆，则两次混淆的情况下生成混淆后的类是不同的。此时，即使后面一次混淆过程中类并未发生修改，则该类依旧被作为修复类，最终封装成修改dex文件。为了避免该问题的发生，本申请实施例中，对于类名相同的第一类和第二类，采用同一个mapping文件混淆第一类，若第二类为发生修改，采用该相同的mapping文件混淆第二类，则不会发生由于mapping文件不同导致的将第二类作为修复类的问题。若第二类发生修改，由于第二类的第二属性与第一类的第一属性不同，则认为第二类为修复类。

基于上述，混淆过程中，需要维护mapping文件。维护过程中，对于一个具体的类，需要用到mapping文件时，若文件传输协议(File Transfer Protocol，ftp)服务器上有mapping，则先从ftp服务器下载mapping文件，若没有，则生成mapping文件，混淆后上传到ftp服务器。

可选的，在本申请一示例中，将所述dex文件放置在路径列表的首位之后，还生成所述修复dex文件的属性；将所述dex文件的属性写入第一文件，并用私钥加密所述第一文件；将用私钥加密后的第一文件写入第二文件；根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件。进一步的，根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件之后，还发布所述补丁文件，以使得客户端对所述补丁文件进行完整性校验和身份校验。

具体的，由于Java语言本身容易被反编译的特征，若修复类被拦截，并返回一个不同安全的补丁文件，则会发生安全问题。为避免修复类对应的修复dex文件被第三方拦截且给客户返回不安全的补丁文件，需要客户端在收到补丁文件后自动舍弃该补丁文件。本申请实施例中，生成公钥和私钥，例如通过安卓安装包(AndroidPackage，APK)生成公钥和私钥，利用非对称加密算法对补丁文件进行身份校验和完整性校验。具体的，可参见图5A与图5B，图5A为本申请热更新方法中的加密过程示意图，图5B为本申请热更新方法中的解密过程示意图。

请参照图5A，加密过程中，基于修复类得到修复dex文件，按照二进制流生成修复dex文件的属性，如修复dex文件的MD5值，将修复dex文件和MD5值写入第一文件，该第一文件例如为sign.MF文件，采用私钥对第一文件进行加密得到，将加密后的内容写入第二文件，第二文件例如为sign.RSA。然后，根据修复dex文件、第一文件与第二文件生成补丁文件，该补丁文件为一个加密补丁文件。

请参照图5B，客户端在得到加密的补丁文件后，解压缩该补丁文件，得到修复dex文件、第一文件与第二文件，根据修复dex文件、第一文件与第二文件生成补丁文件进行完整性校验和身份校验。具体的，包括如下步骤：

201、获取补丁文件。

202、解压缩该补丁文件，得到修复dex文件、第一文件与第二文件。

203、比对基于修复dex文件生成的MD5值与第一文件中写入的MD5值进行比对，若一致，则执行204；若不一致，则执行206。

该步骤为完整性校验过程，该过程中，对基于修复dex文件生成的MD5值与第一文件中写入的MD5值进行比对，若两者一直，则证明该补丁文件是完整的，执行步骤204；若两者不一致，则证明该补丁文件是不完整的，执行。

204、用公钥解密第二文件，得到第一文件，比对公钥解密得到的第一文件和根据补丁文件得到的第一文件，若两者一致，则执行205；若不一致，则执行206。

205、采用该补丁文件对第一应用程序进行热更新。

206、舍弃补丁文件。

该步骤为身份校验过程，该过程中，比对根据公钥解密得到的第一文件和根据补丁文件得到的第一文件，若两者一直，则说明补丁文件的身份是合法的，身份校验通过，客户端认为该补丁文件为可靠的补丁文件，采用该补丁文件对第一应用程序进行热更新，若身份校验未通过，则提醒客户端自动舍弃该补丁文件。

根据图5B可知：只有在完整性校验和身份校验均通过的情况下，客户端才根据补丁文件对第一应用程序进行热更新，若完整性校验和身份校验中的任意一个不通过，则舍弃该补丁文件。

需要说明的是，虽然图5B中是先执行203再执行204，即先进行完整性校验再进行身份校验，然而，本申请实施例并不以此为限制，在其他可行的实现方式中，也可以先进行身份校验，再进行完整性校验。

图6为本申请热更新装置实施例一的结构示意图，包括：

第一获取模块11，用于根据第一压缩文件获取第一应用程序的第一类列表，所述第一类列表包含所述第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；

第二获取模块12，用于根据第二压缩文件获取第二应用程序的第二类列表，所述第二类列表包含所述第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；

确定模块13，用于根据所述第一映射关系与所述第二映射关系，确定修复类，所述修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；

修复模块14，用于根据所述修复类更新所述第一应用程序。

本申请实施例提供的热更新装置，根据第一压缩文件获取第一应用程序的第一类列表，第一类列表包含第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；根据第二压缩文件获取第二应用程序的第二类列表，第二类列表包含第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；根据第一映射关系与第二映射关系，确定修复类，修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；根据修复类更新第一应用程序。该过程中，通过对应用程序进行热更新，实现降低更新应用程序复杂度及成本的目的。

可选的，在本申请一实施例中，所述修复模块14，具体用于将所述修复类封装成修复dex文件；将所述修复dex文件放置在路径列表的首位，所述路径列表包含所述第一应用程序的第一类对应的dex文件。

图7为本申请热更新装置实施例二的结构示意图，请参照图7，本申请实施例提供的热更新装置，在上述图6的基础上，进一步的，还包括：

加密模块15，用于在所述修复模块14将所述dex文件放置在路径列表的首位之后，生成所述修复dex文件的属性；将所述dex文件的属性写入第一文件，并用私钥加密所述第一文件；将用私钥加密后的第一文件写入第二文件；根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件。

再请参照图7，上述的热更新装置还包括：

发布模块16，用于在所述加密模块15根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件之后，发布所述补丁文件，以使得客户端对所述补丁文件进行完整性校验和身份校验。

再请参照图7，上述的热更新装置还包括：

混淆模块17，用于在所述确定模块13根据所述第一映射关系与所述第二映射关系，确定修复类之前，采用映射mapping文件混淆所述第一类；采用所述mapping文件混淆所述第二类，所述第一类的第一类名和所述第二类的第二类名相同。

可选的，在本申请一实施例中，所述混淆模块17在采用映射mapping文件混淆所述第一类之前，还用于判断是否存在所述Mapping文件；若不存在，则构建所述Mapping文件。

可选的，在本申请一实施例中，所述第一类属性为所述第一类的消息摘要算法MD5值，所述第二类属性为所述第二类的消息摘要算法MD5值。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种热更新方法，其特征在于，包括：

根据第一压缩文件获取第一应用程序的第一类列表，所述第一类列表包含所述第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；

根据第二压缩文件获取第二应用程序的第二类列表，所述第二类列表包含所述第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；

根据所述第一映射关系与所述第二映射关系，确定修复类，所述修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；

根据所述修复类更新所述第一应用程序。

2.根据权利要求1所述的方法，其特征在于，所述根据所述修复类更新所述第一应用程序，包括：

将所述修复类封装成修复dex文件；

将所述修复dex文件放置在路径列表的首位，所述路径列表包含所述第一应用程序的第一类对应的dex文件。

3.根据权利要求2所述的方法，其特征在于，所述将所述dex文件放置在路径列表的首位之后，还包括：

生成所述修复dex文件的属性；

将所述dex文件的属性写入第一文件，并用私钥加密所述第一文件；

将用私钥加密后的第一文件写入第二文件；

根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件。

4.根据权利要求3所述的方法，其特征在于，所述根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件之后，还包括：

发布所述补丁文件，以使得客户端对所述补丁文件进行完整性校验和身份校验。

5.根据权利要求1～4任一项所述的方法，其特征在于，所述根据所述第一映射关系与所述第二映射关系，确定修复类之前，还包括：

采用映射mapping文件混淆所述第一类；

采用所述mapping文件混淆所述第二类，所述第一类的第一类名和所述第二类的第二类名相同。

6.根据权利要求5所述的方法，其特征在于，所述采用映射mapping文件混淆所述第一类之前，还包括：

判断是否存在所述Mapping文件；

若不存在，则构建所述Mapping文件。

7.根据权利要求1～4任一项所述的方法，其特征在于，所述第一类属性为所述第一类的消息摘要算法MD5值，所述第二类属性为所述第二类的消息摘要算法MD5值。

8.一种热更新装置，其特征在于，包括：

第一获取模块，用于根据第一压缩文件获取第一应用程序的第一类列表，所述第一类列表包含所述第一应用程序中的第一类的第一类名与第一类属性的第一映射关系；

第二获取模块，用于根据第二压缩文件获取第二应用程序的第二类列表，所述第二类列表包含所述第二应用程序中的第二类的第二类名与第二类属性的第二映射关系；

确定模块，用于根据所述第一映射关系与所述第二映射关系，确定修复类，所述修复类为第一类名与第二类相同、第一类属性与第二类属性不同的类；

修复模块，用于根据所述修复类更新所述第一应用程序。

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

所述修复模块，具体用于将所述修复类封装成修复dex文件；将所述修复dex文件放置在路径列表的首位，所述路径列表包含所述第一应用程序的第一类对应的dex文件。

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

加密模块，用于在所述修复模块将所述dex文件放置在路径列表的首位之后，生成所述修复dex文件的属性；将所述dex文件的属性写入第一文件，并用私钥加密所述第一文件；将用私钥加密后的第一文件写入第二文件；根据所述修复dex文件、所述第一文件与所述第二文件生成补丁文件。