应用更新方法和装置与流程

本发明涉及计算机领域，具体而言，涉及一种应用更新方法和装置。

背景技术：

目前，随着用户需求的不断增加，应用需要依据用户需求进行版本更新。现有技术中应用版本更新通常包括以下两种方式：

完整更新方式，通过应用市场或者应用内建的自更新功能下载新版本的完整安装包。

增量更新方式，应用市场通过收集客户端需要更新的应用的安装包信息，在应用市场的服务器端进行差分对比，向客户端提供增量更新包下载，并在客户端上将增量更新包与本地旧版本安装包融合成新版本安装包进行安装。

上述两种应用更新方式均需要一个新版本的安装包覆盖安装旧版本安装包以达到更新版本更新的目的。但是，上述两种应用更新方式存在以下缺点：

1、完整更新方式需要重新下载完整的安装包，对于体积较大的安装包需要耗费较长的下载时间和流量。而且，应用更新时需要中断用户当前操作，降低了应用更新效率，严重影响了用户的使用体验。

2、增量更新方式虽然通过差分对比可以减少需要下载的更新包的体积，但是，增量更新方式需要在客户端将增量更新包与本地旧版本安装包进行融合，会占用较多的客户端资源，其占用资源的多少由本地旧版本安装包大小、增量更新包大小和客户端性能决定。而且，增量更新方式也需要中断用户当前操作，进入安装界面进行应用的安装，严重降低了应用更 新效率。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种应用更新方法和装置，以至少解决相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题。

根据本发明实施例的一个方面，提供了一种应用更新方法，包括：应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；所述应用服务器将生成的所述补丁文件发送至应用客户端；所述应用客户端在被启动时检测是否存在所述应用的补丁文件；以及所述应用客户端在检测到存在所述补丁文件时，在所述应用客户端运行的过程中加载所述补丁文件，以便对所述应用客户端进行更新。

根据本发明实施例的一个方面，还提供了一种应用更新方法，包括：在应用客户端被启动时检测是否存在应用的补丁文件，其中，补丁文件为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

根据本发明实施例的另一方面，还提供了一种应用更新装置，包括：生成单元，用于应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；发送单元，用于应用服务器将生成的补丁文件发送至应用客户端；检测单元，用于应用客户端在被启动时检测是否存在补丁文件；以及第一加载单元，用于应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

根据本发明实施例的另一方面，还提供了一种应用更新装置，包括：检测单元，用于在应用客户端被启动时检测是否存在应用的补丁文件，其 中，补丁文件为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及第一加载单元，用于在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

在本发明实施例中，通过在应用客户端被启动时检测是否存在根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的补丁文件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，从而实现了提高应用客户端更新效率的技术效果，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的应用更新方法的硬件环境的示意图；

图2是根据本发明实施例的一种可选的应用更新方法的流程图；

图3是根据本发明实施例的补丁文件的生成过程的示意图；

图4是根据本发明实施例的补丁文件的加载过程的示意图；

图5是根据本发明实施例的对补丁文件进行安全校验的示意图；

图6是根据本发明实施例的一种优选的应用更新方法的流程图；

图7是根据本发明实施例的另一种可选的应用更新方法的流程图；

图8是根据本发明实施例的一种可选的应用更新装置的示意图；

图9是根据本发明实施例的另一种可选的应用更新装置的示意图；

图10是根据本发明实施例的另一种可选的应用更新装置的示意图；

图11是根据本发明实施例的另一种可选的应用更新装置的示意图；

图12是根据本发明实施例的另一种可选的应用更新装置的示意图；

图13是根据本发明实施例的另一种可选的应用更新装置的示意图；

图14是根据本发明实施例的另一种可选的应用更新装置的示意图；

图15是根据本发明实施例的一种可选的应用更新装置的示意图；

图16是根据本发明实施例的另一种可选的应用更新装置的示意图；

图17是根据本发明实施例的另一种可选的应用更新装置的示意图；

图18是根据本发明实施例的另一种可选的应用更新装置的示意图；

图19是根据本发明实施例的另一种可选的应用更新装置的示意图；

图20是根据本发明实施例的另一种可选的应用更新装置的示意图；以及

图21是根据本发明实施例的一种终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

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

实施例1

根据本发明实施例，提供了一种应用更新方法的方法实施例。

可选地，在本实施例中，上述应用更新方法可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。如图1所示，服务器102通过网络与终端104进行连接，上述网络包括但不限于：广域网、城域网或局域网，终端104并不限定于pc、手机、平板电脑等。本发明实施例的应用更新方法可以由服务器102和终端104共同执行。

图2是根据本发明实施例的一种可选的应用更新方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤s102，应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；

步骤s104，应用服务器将生成的补丁文件发送至应用客户端；

步骤s106，应用客户端在被启动时检测是否存在补丁文件；

步骤s108，应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

通过上述步骤s102至步骤s108，通过应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件并发送至应用客户端，应用客户端在应用客户端被启动时检测是否存在补丁文件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现 了提高应用更新效率的技术效果。

需要说明的是，由应用服务器和应用客户端可以组成应用更新系统，在该系统中应用服务器与应用客户端之间通信连接，包括有线连接和无线连接。应用服务器可以对应用提供数据支持和维护，应用客户端可以安装在任意形式的终端设备上，终端设备可以是手机终端、也可以是电脑终端等。本发明实施例对应用客户端的类型不做具体限定，比如，即时通信类应用等。

在步骤s102提供的技术方案中，当应用客户端存在更新版本文件时，应用服务器可以根据应用客户端的更新版本文件与当前版本文件生成补丁文件，可选地，具体生成过程可以包括以下步骤：

步骤s1022，应用服务器获取应用客户端的更新版本文件和当前版本文件；

步骤s1024，比对应用客户端的更新版本文件和当前版本文件，获取应用客户端的更新版本文件和当前版本文件之间存在差异的类文件；

步骤s1026，将类文件打包成补丁文件。

需要说明的是，应用客户端的当前版本文件可以为该应用客户端启动并正在运行的版本文件，更新版本文件可以为该应用客户端运行的当前版本文件的版本升级文件。比如，应用客户端启动并运行的当前版本文件为v1.0，则该应用客户端的更新版本文件可以为v2.0。还需要说明的是，更新版本文件可以为对当前版本文件中的一个或者多个类文件进行更新后得到的版本文件，则相应地更新版本文件与当前版本文件之间可以存在一个或者多个差异的类文件，本发明实施例可以将这些差异的类文件打包成补丁文件，利用该补丁文件可以对应用客户端进行更新。

在实际应用场景中，根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成文件补丁文件的具体过程可以如图3所示，需要说明的是，图3所示中的projectv1.0为应用客户端的当前版本文件， 其内包括有a.class、b.class、c.class、d.class等类文件。projectv2.0为应用客户端的更新版本文件，其内也包括有a.class、b.class、c.class、d.class等类文件，假设更新版本文件projectv2.0发生过修改的类文件为b.class、d.class，如图3所示虚线框所示。通过比对应用客户端的更新版本文件projectv2.0与当前版本文件projectv1.0之间存在差异的类文件，得到存在差异的类文件path内包括有b.class、d.class，则可以将这些类文件单独生成dex文件，并将其打包成补丁文件patch.jar。

在步骤s104提供的技术方案中，应用服务器在生成补丁文件之后可以将生成的补丁文件发送至应用客户端，以供应用客户端在启动过程中利用补丁文件对应用客户端进行更新。可选地，应用服务器还可以对生成的补丁文件进行本地缓存，以便于节省应用客户端的存储空间，当应用客户端需要利用补丁文件进行更新时可以从应用服务器缓存中请求补丁文件。还需要说明的是，应用服务器可以利用应用服务器与应用客户端之间的通信连接将生成的补丁文件发送至应用客户端，其中，应用服务器与应用客户端之间的通信连接可以为有线连接，也可以为无线连接。应用服务器利用通信连接向应用客户端发送补丁文件可以采用实时发送方式，也可以采用定时发送方式，具体地，实时发送方式可以为当应用服务器生成补丁文件后立即将生成的补丁文件发送至客户端；定时发送方式可以为当应用服务器生成补丁文件后可以按照预定的时间阈值将生成的补丁文件发送至客户端。需要说明的是，定时发送方式中的预定时间阈值很小，以保证不会对应用客户端更新造成延迟。为了保证应用客户端更新的实时性，本发明实施例中应用服务器优选地采用实时发送方式将生成的补丁文件发送至应用客户端。

在步骤s106提供的技术方案中，应用客户端在启动并运行当前版本文件的过程中，可以实时检测是否存在补丁文件，其中，补丁文件可以为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件，以便于在检测到存在补丁文件时利用该补丁文件对应用客户端进行更新。需要说明的是，应用客户端检测到的补丁文件可以是一个， 也可以是多个，应用客户端可以利用这些补丁文件可以对应用客户端进行更新。还需要说明的是，应用客户端在被启动时可以检测应用客户端本地是否存在补丁文件，应用客户端本地可以是应用客户端内存空间或者缓存空间。

在步骤s108提供的技术方案中，如果在应用客户端被启动时应用客户端检测到存在一个或者多个补丁文件时，应用客户端可以在应用客户端运行过程中加载这些补丁文件，以实现对应用客户端进行更新的目的。需要说明的是，应用客户端在运行当前版本文件的过程中，通过加载用于更新应用客户端的补丁文件，可以实现在运行当前版本过程中即可以完成对该应用客户端的更新，从而达到了在应用客户端运行过程中无需中断用户当前操作亦可以实现应用客户端进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现了提高应用更新效率的技术效果。

作为一种可选的实施例，步骤s108应用客户端在应用客户端运行的过程中加载补丁文件可以包括：步骤s1081，应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。

需要说明的是，应用客户端的当前版本文件中的相关文件可以包括但并不限于应用客户端运行过程所需的类文件，相关文件的个数可以是一个，也可以是多个。该可选实施例中补丁文件的第一类文件与相关文件的第二类文件可以具有相同名称，如图4所示，补丁文件patch.dex的第一类文件名称为foo.class，相关文件class.dex的第二类文件名称也为foo.class，即补丁文件patch.dex的第一类文件与相关文件class.dex的第二类文件具有相同名称，则此时应用客户端可以将补丁文件patch.dex排列在当前版本文件中的相关文件class.dex的前面，如图4所示图左为前面。当补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，应用客户端通 过将补丁文件排列在相关文件的前面，可以使得应用客户端运行过程中加载补丁文件时补丁文件的第一类文件被调用，而相关文件的第二类文件不被调用。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，应用客户端通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程进行更新的目的，进而达到了提高应用更新效率的效果。

在实际应用场景中，在应用客户端被启动时，应用客户端如果检测到存在有效的补丁文件，则可以通过dexclassloader的方式加载检测到的补丁文件。一个dexclassloader可以包含多个dex文件，每个dex文件是一个element，多个dex文件排列成一个有序的数组dexelements，当找类的时候，会按顺序遍历dex文件。如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类。因此只需要把需要更新的类打包到一个dex(例如图4所示的patch.dex)中去，然后把这个dex插入到elements的最前面，则可实现类的动态更新升级。

作为一种可选的实施例，在步骤s108之后，也即应用客户端在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括：步骤s1101，应用客户端在接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。

需要说明的是，应用客户端在应用客户端运行的过程中加载补丁文件之后，该应用客户端可以实时检测是否接收到调用具有相同名称的类文件的指令，在接收到调用具有相同名称的类文件的指令时，该应用客户端还可以检测具有相同名称的类文件的位置关系，当检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，如图4所示的情况，该应用客户端可以调用第一类文件，而不 调用第二类文件。

该可选实施例应用客户端通过在检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，调用第一类文件，而不调用第二类文件。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，该应用客户端通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，达到了提高应用更新效率的效果。

作为一种可选的实施例，应用客户端在未检测到补丁文件时，或者，应用客户端在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括以下步骤：

步骤s1102，应用客户端向应用服务器请求是否存在应用客户端最新的补丁文件；

步骤s1104，若存在最新的补丁文件，应用客户端则从应用服务器获取最新的补丁文件；

步骤s1106，应用客户端在被再次启动之后加载最新的补丁文件，以便对应用客户端进行更新。

需要说明的是，应用客户端在被启动时检测是否存在补丁文件可以为检测应用客户端的本地是否存在补丁文件，若本地不存在补丁文件，则该可选实施例可以向应用服务器请求该应用客户端的最新的补丁文件。或者，当应用客户端在被启动时检测到本地存在补丁文件，在应用客户端运行过程中加载检测到的补丁文件后，该应用客户端还可以向应用服务器请求该应用客户端的最新的版本文件，此处需要说明的是，应用客户端运行过程 中加载的该应用客户端本地的补丁文件可能不是最新版本的，也即在加载补丁文件过程中应用服务器可能又向应用客户端发布了该应用客户端的更新版本文件，则该应用客户端也可以向应用服务器请求该最新的补丁文件，以达到对应用客户端进行更新的目的。当应用服务器中存在最新的补丁文件时，该应用客户端可以从应用服务器中获取该最新的补丁文件，并在该应用客户端被再次启动之后，在运行过程中应用客户端可以加载该最新的补丁文件，以便对该应用客户端进行更新。

该可选实施例应用客户端通过从应用服务器中请求最新的补丁文件，并在应用客户端运行过程中加载该最新的补丁文件，能够保证使得应用客户端在运行过程中更新至最新版本，进而达到提高应用更新效率的效果。

作为一种可选的实施例，应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤s1071，应用客户端对补丁文件进行安全校验；步骤s108在应用客户端运行的过程中加载补丁文件可以包括：步骤s1082，在安全校验通过时，应用客户端在应用客户端运行的过程中加载补丁文件。

需要说明的是，应用客户端在检测到存在补丁文件之后，该应用客户端可以对该检测到的补丁文件进行安全校验，以保证应用客户端运行过程中加载的补丁文件为安全可靠的文件，进而能够提高应用客户端的安全性和可靠性。需要说明的是，该应用客户端对补丁文件进行安全校验的具体内容不做具体限定，其可以是包括但并不限于校验补丁文件是否包含疑似病毒文件等，此处不再一一举例说明。应用客户端在检测到存在补丁文件，且对补丁文件进行安全校验通过时，该应用客户端可以在应用客户端运行过程中加载该补丁文件，以便于实现对应用客户端进行更新的目的。

在实际应用场景中，由于补丁文件是以jar文件的形式下载并存储在客户端本地或者服务器中，存在可能被篡改从而达到破坏补丁文件的目的。因此，当应用客户端在检测到存在补丁文件，并在下载完成以及每次加载时，可以通过rsa签名+sha1校验的机制，来确保缓存的补丁文件中 的数据不被篡改。图5是根据本发明实施例的对补丁文件进行安全校验的示意图，如图5所示，应用服务器发布补丁文件并申请对补丁文件进行安全校验，具体地，可以首先对补丁文件patch.jar中的所有文件class.dex、version.txt等做sha1计算，生成verify.txt文件；然后使用私钥对verify.txt签名，生成verify.signature文件。应用客户端可以从应用服务器下载补丁文件patch.jar，并将其存储在客户端本地。在加载补丁文件patch.jar之前可以使用公钥校验verify.txt文件，并对补丁文件patch.jar中的所有文件做sha1校验，在校验通过的情况下，应用客户端加载该补丁文件patch.jar以进行更新。需要说明的是，sha1算法为现有技术中的成熟算法，本发明实施例对其不做具体限定，此处也不再赘述。

作为一种可选的实施例，应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤s1072，应用客户端判断补丁文件与当前版本文件是否匹配；步骤s108在应用客户端运行的过程中加载补丁文件包括：步骤s1083，在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。

需要说明的是，应用客户端在检测到存在补丁文件之后，该应用客户端可以判断检测到的补丁文件与当前版本文件是否匹配，需要说明的是，该应用客户端对检测补丁文件与当前版本文件是否匹配的内容不做具体限定，其可以为检测补丁文件是否为该应用当前版本文件的更新文件等，此处不再一一举例说明。该应用客户端通过判断补丁文件与当前版本文件是否匹配，能够保证应用客户端可以实现准确更新，避免应用客户端更新到错误版本。当补丁文件与当前版本文件匹配时，该应用客户端可以加载该补丁文件，以便于对应用客户端进行更新。该应用客户端通过在检测到存在补丁文件之后，判断该补丁文件是否与当前版本文件匹配，能够提高应用客户端更新的准确度，进而提高更新后的应用客户端的性能。

本发明还提供了一种优选实施例，图6是根据本发明实施例的一种优选的应用更新方法的流程图，如图6所示，该优选实施例可以包括以下步 骤：

步骤s601，应用客户端被启动。

步骤s602，检测应用客户端本地是否存在补丁文件。其中，若存在，则执行步骤s603；若不存在，则执行步骤s607。

步骤s603，判断本地存在的补丁文件与该应用客户端当前版本文件是否匹配。其中，若匹配，则执行步骤s604；若不匹配，则执行步骤s607。

步骤s604，对本地补丁文件进行安全校验。

步骤s605，判断安全校验是否通过。其中，若通过，则执行步骤s606；若不通过，则执行步骤s607。

步骤s606，加载本地的补丁文件。

步骤s607，完成应用客户端的初始化。

步骤s608，拉取通信协议从应用服务器获取远程的补丁文件。

步骤s609，判断远程的补丁文件是否与该应用客户端当前版本文件是否匹配。其中，若匹配，则执行步骤s610；若不匹配，则结束。

步骤s610，下载远程的补丁文件。

步骤s611，判断是否需要强制重启该应用客户端。其中，若需要强制启动，则执行步骤s612；若不需要强制重启，则执行步骤s615。

步骤s612，对远程的补丁文件进行安全校验。

步骤s613，判断安全校验是否通过。其中，若通过，则执行步骤s614；若不通过，则结束。

步骤s614，重启应用客户端，跳转执行步骤s601。

步骤s615，等待下次重启应用客户端。

上述步骤可以概括为：应用客户端应用每次启动时，会检测本地是否 存在有效的补丁文件(patch.jar)，如果没有，则按正常的流程完成初始化，此时应用客户端的版本为初始版本。在完成启动后，通过与应用服务器的通信协议获取应用客户端的更新信息，如果存在新版本信息，则下载相应的补丁文件，并可通过后台设置是否需要打断用户操作强制重启升级，还是等待下次重启的机会静默升级。当应用客户端被再次启动时(此时应用客户端当前版本号依旧为旧版本号)，会检测到本地存在新的补丁文件，在对补丁文件进行rsa+sha1安全性校验后，加载该补丁文件，版本号升级到新版本号，完成应用客户端的版本升级。

本发明实施例中的应用客户端可以为能够在android系统下运行的应用，也可以为在ios系统下运行的应用。而且，本发明实施例不仅适用于java类文件，还可以适用于xml资源文件、库文件等的升级。以android系统为例，本发明实施例基于androidmultidex分包方案，一般情况下android应用客户端都包含一个有java类编译而成的dex文件，multidex即将一个dex文件拆分成两个或者多个(例如classes.dex、classes1.dex...)，在android应用客户端启动的时候，会进行multidex的检查，并通过dexclassloader依次加载各个dex文件。

在本发明实施例中，利用androidmultidex分包原理，将需要动态更新的java类编译到一个单独的dex中并生成更新包，在android应用客户端启动的阶段，进行更新包的检测，如果存在更新包，则通过dexclassloader加载，以达到动态更新的目的，减少了应用客户端更新时间和流量消耗，极大地极高了更新效率。

需要说明的是，由于android虚拟机在应用客户端apk被安装的时候，会为类加上校验标签，从而导致两个相关联的类在不同的dex文件中就会报错。为了防止类被加上校验标签，达到通过dex文件动态更新应用客户端的目的，本发明实施例可以在项目编译后的所有javaclass文件的构造方法中插入以下几行代码：

if(antiverifyconfig.do_verify_classes){

antilazyload.foo()；}

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，提供了一种应用更新方法的方法实施例。

可选地，在本实施例中，上述应用更新方法也可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。本发明实施例的应用更新方法可以由服务器102来执行，也可以由终端104来执行，还可以是由服务器102和终端104共同执行。其中，终端104执行本发明实施例的应用更新方法也可以是由安装在其上的应用客户端来执行。

图7是根据本发明实施例的另一种可选的应用更新方法的流程图，如图7所示，该方法可以包括以下步骤：

步骤s202，在应用客户端被启动时检测是否存在应用客户端的补丁文件，其中，补丁文件为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；

步骤s204，在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

通过上述步骤s202至步骤s204，通过在应用客户端被启动时检测是否存在根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的补丁文件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现了提高应用更新效率的技术效果。

在步骤s202提供的技术方案中，本发明实施例对应用客户端的类型不做具体限定，其可以是安装在客户端或者服务器中的任意类型的应用客户端，比如，即时通信类应用客户端等。本发明实施例中应用客户端在被启动时运行的版本文件为当前版本文件，在应用客户端启动并运行当前版本文件的过程中，可以实时检测是否存在该应用客户端的补丁文件，其中，补丁文件可以为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件，需要说明的是，应用客户端的当前版本文件可以为该应用客户端启动并正在运行的版本文件，更新版本文件可以为该应用客户端运行的当前版本文件的版本升级文件。比如，应用客户端启动并运行的当前版本文件为v1.0，则该应用客户端的更新版本文件可以为v2.0。还需要说明的是，更新版本文件可以为对当前版本文件中的一个或者多个类文件进行更新后得到的版本文件，则相应地更新版本文件与当前版本文件之间可以存在一个或者多个差异的类文件，本发明实施例可以将这些差异的类文件生成一个或者多个补丁文件，利用这些补丁文件可以对应用客户端进行更新。需要说明的是，在应用客户端被启动时检测到的应用客户端的补丁文件可以是一个，也可以是多个。

在实际应用客户端场景中，根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成文件补丁文件的具体过程可以如图3所 示，需要说明的是，图3所示中的projectv1.0为应用客户端的当前版本文件，其内包括有a.class、b.class、c.class、d.class等类文件。projectv2.0为应用客户端的更新版本文件，其内也包括有a.class、b.class、c.class、d.class等类文件，假设更新版本文件projectv2.0发生过修改的类文件为b.class、d.class，如图3所示虚线框所示。通过比对应用客户端的更新版本文件projectv2.0与应用客户端的当前版本文件projectv1.0之间存在差异的类文件，得到存在差异的类文件path内包括有b.class、d.class，则可以将这些类文件单独生成dex文件，并将其打包成补丁文件patch.jar。

在步骤s204提供的技术方案中，如果在应用客户端被启动时检测到存在一个或者多个补丁文件时，本发明实施例可以在应用客户端运行过程中加载这些补丁文件，以实现对其进行更新的目的。需要说明的是，本发明实施例在运行当前版本文件的过程中，通过加载用于更新应用客户端的补丁文件，可以实现在运行当前版本过程中即可以完成对该应用客户端的更新，从而达到了在应用客户端运行过程中无需中断用户当前操作亦可以实现应用客户端进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现了提高应用客户端更新效率的技术效果。

作为一种可选的实施例，步骤s204在应用客户端运行的过程中加载补丁文件可以包括：步骤s2041，将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。

需要说明的是，应用客户端的当前版本文件中的相关文件可以包括但并不限于应用客户端运行过程所需的类文件，相关文件的个数可以是一个，也可以是多个。该可选实施例中补丁文件的第一类文件与相关文件的第二类文件可以具有相同名称，如图4所示，补丁文件patch.dex的第一类文件名称为foo.class，相关文件class.dex的第二类文件名称也为foo.class，即补丁文件patch.dex的第一类文件与相关文件class.dex的第二类文件具 有相同名称，则此时该可选实施例可以将补丁文件patch.dex排列在当前版本文件中的相关文件class.dex的前面，如图4所示图左为前面。当补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，该可选实施例通过将补丁文件排列在相关文件的前面，可以使得应用客户端运行过程中加载补丁文件时补丁文件的第一类文件被调用，而相关文件的第二类文件不被调用。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，该可选实施例通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程对应用客户端进行更新的目的，进而达到了提高应用更新效率的效果。

在实际应用场景中，在应用客户端被启动时，如果检测到存在有效的补丁文件，则可以通过dexclassloader的方式加载检测到的补丁文件。一个dexclassloader可以包含多个dex文件，每个dex文件是一个element，多个dex文件排列成一个有序的数组dexelements，当找类的时候，会按顺序遍历dex文件。如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类。因此只需要把需要更新的类打包到一个dex(例如图4所示的patch.dex)中去，然后把这个dex插入到elements的最前面，则可实现类的动态更新升级。

作为一种可选的实施例，在步骤s204之后，也即在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括：步骤s2061，在应用客户端接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。

需要说明的是，在应用客户端运行的过程中加载补丁文件之后，该应用客户端可以实时检测是否接收到调用具有相同名称的类文件的指令，在接收到调用具有相同名称的类文件的指令时，该应用客户端还可以检测具 有相同名称的类文件的位置关系，当检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，如图4所示的情况，该可选实施例可以调用第一类文件，而不调用第二类文件。

该可选实施例通过在检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，调用第一类文件，而不调用第二类文件。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，该可选实施例通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程对应用客户端进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，达到了提高应用更新效率的效果。

作为一种可选的实施例，在未检测到补丁文件时，或者，在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括以下步骤：

步骤s2062，向应用服务器请求是否存在应用客户端最新的补丁文件；

步骤s2064，若存在最新的补丁文件，则从应用服务器获取最新的补丁文件；

步骤s2066，在应用客户端被再次启动之后加载最新的补丁文件，以便对应用客户端进行更新。

需要说明的是，在应用客户端被启动时检测是否存在补丁文件可以为检测应用客户端本地是否补丁文件，若本地不存在补丁文件，则该可选实施例可以向应用服务器请求该应用客户端的最新的补丁文件，其中，应用服务器可以对该应用客户端进行支持和维护。或者，当应用客户端被启动时检测到本地存在补丁文件，在应用客户端过程中加载检测到的补丁文件 后，该应用客户端还可以向应用服务器请求该应用客户端的最新的版本文件，此处需要说明的是，应用客户端运行过程中加载的本地补丁文件可能不是最新版本的，也即在加载补丁文件过程中应用服务器可能又向应用客户端发布了该应用客户端的更新版本文件，则该可选实施例也可以向服务器请求该应用客户端的最新的补丁文件，以达到对应用客户端进行更新的目的。当应用服务器中存在最新的补丁文件时，该应用客户端可以从应用服务器中获取该最新的补丁文件，并在该应用客户端被再次启动之后，在该应用客户端的运行的过程中可以加载该最新的补丁文件，以便对该应用客户端进行更新。

该可选实施例通过从应用服务器中请求应用客户端的最新的补丁文件，并在应用客户端运行过程中加载该最新的补丁文件，能够保证使得应用客户端在运行过程中更新至最新版本，进而达到提高应用更新效率的效果。

作为一种可选的实施例，在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤s2031，应用客户端对补丁文件进行安全校验；步骤s204在应用客户端运行的过程中加载补丁文件可以包括：步骤s2042，在安全校验通过时，在应用客户端运行的过程中加载补丁文件。

需要说明的是，在检测到存在补丁文件之后，该应用客户端可以对该检测到的补丁文件进行安全校验，以保证应用客户端运行过程中加载的补丁文件为安全可靠的文件，进而能够提高应用客户端的安全性和可靠性。需要说明的是，该可选实施例对应用客户端对补丁文件进行安全校验的具体内容不做具体限定，其可以是包括但并不限于校验补丁文件是否包含疑似病毒文件等，此处不再一一举例说明。在检测到存在补丁文件，且对补丁文件进行安全校验通过时，该可选实施例可以在应用客户端运行过程中加载该补丁文件，以便于实现对应用客户端进行更新的目的。

在实际应用场景中，由于补丁文件是以jar文件的形式下载并存储在 应用客户端本地或者应用服务器中，存在可能被篡改从而达到破坏补丁文件的目的。因此，当客户端在检测到存在补丁文件，并在下载完成以及每次加载时，可以通过rsa签名+sha1校验的机制，来确保缓存的补丁文件中的数据不被篡改。如图5所示，应用服务器发布补丁文件并申请对补丁文件进行安全校验，具体地，可以首先对补丁文件patch.jar中的所有文件class.dex、version.txt等做sha1计算，生成verify.txt文件；然后使用私钥对verify.txt签名，生成verify.signature文件。应用客户端可以从应用服务器下载补丁文件patch.jar，并将其存储在本地。在加载补丁文件patch.jar之前可以使用公钥校验verify.txt文件，并对补丁文件patch.jar中的所有文件做sha1校验，在校验通过的情况下，应用客户端加载该补丁文件patch.jar，以实现对应用客户端进行更新。需要说明的是，sha1算法为现有技术中的成熟算法，本发明实施例对其不做具体限定，此处也不再赘述。

作为一种可选的实施例，在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤s2032，应用客户端判断补丁文件与当前版本文件是否匹配；步骤s204在应用客户端运行的过程中加载补丁文件包括：步骤s2043，在补丁文件与当前版本文件匹配时，加载补丁文件。

需要说明的是，在检测到存在补丁文件之后，该应用客户端可以判断检测到的补丁文件与当前版本文件是否匹配，需要说明的是，该可选实施例对应用客户端检测补丁文件与当前版本文件是否匹配的内容不做具体限定，其可以为检测补丁文件是否为该应用客户端当前版本文件的更新文件等，此处不再一一举例说明。该可选实施例通过判断补丁文件与当前版本文件是否匹配，能够保证应用客户端可以实现准确更新，避免应用客户端更新到错误版本。当补丁文件与当前版本文件匹配时，该可选实施例可以加载该补丁文件，以便于对应用客户端进行更新。该可选实施例通过在检测到存在补丁文件之后，判断该补丁文件是否与当前版本文件匹配，能够提高应用客户端更新的准确度，进而提高更新后的应用客户端的性能。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例3

根据本发明实施例，还提供了一种用于实施本发明实施例1中的应用更新方法的应用更新装置。图8是根据本发明实施例的一种可选的应用更新装置的示意图，如图8所示，该装置可以包括：

生成单元12，用于应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；发送单元14，用于应用服务器将生成的补丁文件发送至应用客户端；检测单元16，用于应用客户端在被启动时检测是否存在补丁文件；以及第一加载单元18，用于应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

需要说明的是，该实施例中的生成单元12可以用于执行本申请实施例1中的步骤s102，该实施例中的发送单元14可以用于执行本申请实施例1中的步骤s104，该实施例中的检测单元16可以用于执行本申请实施例1中的步骤s106，该实施例中的第一加载单元18可以用于执行本申请 实施例1中的步骤s108。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图9是根据本发明实施例的另一种可选的应用更新装置的示意图，如图9所示，生成单元12可以包括：获取模块122，用于应用服务器获取应用客户端的更新版本文件和当前版本文件；比对模块124，用于比对应用客户端的更新版本文件和当前版本文件，获取应用客户端的更新版本文件和当前版本文件之间存在差异的类文件；以及打包模块126，用于将类文件打包成补丁文件。

需要说明的是，该实施例中的获取模块122可以用于执行本申请实施例1中的步骤s1022，该实施例中的比对模块124可以用于执行本申请实施例1中的步骤s1024，该实施例中的打包模块126可以用于执行本申请实施例1中的步骤s1026。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图10是根据本发明实施例的另一种可选的应用更新装置的示意图，如图10所示，第一加载单元18可以包括：排列模块181，用于应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。

需要说明的是，该实施例中的排列模块181可以用于执行本申请实施例1中的步骤s1081。此处需要说明的是，该模块与对应的步骤所实现的 示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，该模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图11是根据本发明实施例的另一种可选的应用更新装置的示意图，如图11所示，该可选实施例还可以包括：调用单元1101，用于应用客户端在应用客户端运行的过程中加载补丁文件之后，应用客户端在接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。

需要说明的是，该实施例中的调用单元1101可以用于执行本申请实施例1中的步骤s1101。此处需要说明的是，该模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，该模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图12是根据本发明实施例的另一种可选的应用更新装置的示意图，如图12所示，该可选实施例还可以包括：请求单元1102，用于应用客户端在未检测到补丁文件时或者在应用客户端运行的过程中加载补丁文件之后，应用客户端向应用服务器请求是否存在应用最新的补丁文件；获取单元1104，用于若存在最新的补丁文件，应用客户端则从应用服务器获取最新的补丁文件；第二加载单元1106，用于应用客户端在应用客户端被再次启动之后加载最新的补丁文件，以便对应用客户端进行更新。

需要说明的是，该实施例中的请求单元1102可以用于执行本申请实施例1中的步骤s1102，该实施例中的获取单元1104可以用于执行本申请实施例1中的步骤s1104，该实施例中的第二加载单元1106可以用于执行本申请实施例1中的步骤s1106。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景 相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图13是根据本发明实施例的另一种可选的应用更新装置的示意图，如图13所示，该可选实施例还可以包括：校验单元171，用于应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，应用客户端对补丁文件进行安全校验；第一加载单元18包括：第一加载模块182，用于在安全校验通过时，应用客户端在应用客户端运行的过程中加载补丁文件。

需要说明的是，该实施例中的校验单元171可以用于执行本申请实施例1中的步骤s1071，该实施例中的第一加载模块182可以用于执行本申请实施例1中的步骤s1082。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图14是根据本发明实施例的另一种可选的应用更新装置的示意图，如图14所示，该可选实施例还可以包括：判断单元172，用于应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，应用客户端判断补丁文件与当前版本文件是否匹配；第一加载单元18包括：第二加载模块183，用于在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。

需要说明的是，该实施例中的判断单元172可以用于执行本申请实施例1中的步骤s1072，该实施例中的第二加载模块183可以用于执行本申请实施例1中的步骤s1083。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景 相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

通过上述模块，可以解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，进而达到提高应用更新效率的技术效果。

实施例4

根据本发明实施例，还提供了一种用于实施本发明实施例2中的应用更新方法的应用更新装置。图15是根据本发明实施例的一种可选的应用更新装置的示意图，如图15所示，该装置可以包括：

检测单元22，用于在应用被启动时检测是否存在应用的补丁文件，其中，补丁文件为根据应用的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及第一加载单元24，用于在检测到存在补丁文件时，在应用运行的过程中加载补丁文件，以便对应用进行更新。

需要说明的是，该实施例中的检测单元22可以用于执行本申请实施例1中的步骤s202，该实施例中的第一加载单元24可以用于执行本申请实施例1中的步骤s204。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图16是根据本发明实施例的另一种可选的应用更新装置的示意图，如图16所示，第一加载单元24可以包括：排列模块241，用于将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。

需要说明的是，该实施例中的排列模块241可以用于执行本申请实施例1中的步骤s2041。此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图17是根据本发明实施例的另一种可选的应用更新装置的示意图，如图17所示，该可选实施例还可以包括：调用单元261，用于在应用运行的过程中加载补丁文件之后，在应用接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。

需要说明的是，该实施例中的调用单元261可以用于执行本申请实施例1中的步骤s2061。此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图18是根据本发明实施例的另一种可选的应用更新装置的示意图，如图18所示，该可选实施例还可以包括：请求单元262，用于在未检测到补丁文件时或者在应用运行的过程中加载补丁文件之后，向服务器请求是否存在应用最新的补丁文件；获取单元264，用于在存在最新的补丁文件，则从服务器获取最新的补丁文件；第二加载单元266，用于在应用被再次启动之后加载最新的补丁文件，以便对应用进行更新。

需要说明的是，该实施例中的请求单元262可以用于执行本申请实施例1中的步骤s2062，该实施例中的获取单元264可以用于执行本申请实施例1中的步骤s2064，该实施例中的第二加载单元266可以用于执行本申请实施例1中的步骤s2066。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图19是根据本发明实施例的另一种可选的应用更新装置的示意图，如图19所示，该可选实施例还可以包括：校验单元231，用于在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，对补丁文件进行安全校验。其中，第一加载单元24可以包括：第一加载模块242，用于在安全校验通过时，在应用运行的过程中加载补丁文件。

需要说明的是，该实施例中的校验单元231可以用于执行本申请实施例1中的步骤s2031，该实施例中的第一加载模块242可以用于执行本申请实施例1中的步骤s2042。此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

作为一种可选的实施例，图20是根据本发明实施例的另一种可选的应用更新装置的示意图，如图20所示，该可选实施例还可以包括：判断单元232，用于在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，判断补丁文件与当前版本文件是否匹配。其中，第一加载单元24可以包括：第二加载模块243，用于在补丁文件与当前版本文件匹配时，加载补丁文件。

需要说明的是，该实施例中的判断单元232可以用于执行本申请实施例1中的步骤s2032，该实施例中的第二加载模块243可以用于执行本申请实施例1中的步骤s2043。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景 相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

通过上述模块，可以解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，进而达到提高应用更新效率的技术效果。

实施例5

根据本发明实施例，还提供了一种用于实施上述应用更新方法的服务器或终端。

图21是根据本发明实施例的一种终端的结构框图，如图21所示，该终端可以包括：一个或多个(图中仅示出一个)处理器201、存储器203、以及传输装置205(如上述实施例中的发送装置)，如图21所示，该终端还可以包括输入输出设备207。

其中，存储器203可用于存储软件程序以及模块，如本发明实施例中的应用更新方法和装置对应的程序指令/模块，处理器201通过运行存储在存储器203内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用更新方法。存储器203可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器203可进一步包括相对于处理器201远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置205用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置205包括一个网络适配器(networkinterfacecontroller，nic)，其可通过网线与其他网络设备与路由器相连从 而可与互联网或局域网进行通讯。在一个实例中，传输装置205为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器203用于存储应用程序。

处理器201可以通过传输装置205调用存储器203存储的应用程序，以执行下述步骤：应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；应用服务器将生成的补丁文件发送至应用客户端；应用客户端在应用客户端被启动时检测是否存在补丁文件；以及应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

处理器201还用于执行下述步骤：应用服务器获取应用的更新版本文件和当前版本文件；比对应用的更新版本文件和当前版本文件，获取应用的更新版本文件和当前版本文件之间存在差异的类文件；以及将类文件打包成补丁文件。

处理器201还用于执行下述步骤：应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。

处理器201还用于执行下述步骤：应用客户端在应用运行的过程中加载补丁文件之后，应用客户端在应用接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。

处理器201还用于执行下述步骤：应用客户端在未检测到补丁文件时或者在应用运行的过程中加载补丁文件之后，应用客户端向应用服务器请求是否存在应用最新的补丁文件；若存在最新的补丁文件，应用客户端则从应用服务器获取最新的补丁文件；应用客户端在应用被再次启动之后加载最新的补丁文件，以便对应用进行更新。

处理器201还用于执行下述步骤：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端对补丁文件进行安全校验；应用客户端在应用运行的过程中加载补丁文件包括：在安全校验通过时，应用客户端在应用运行的过程中加载补丁文件。

处理器201还用于执行下述步骤：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端判断补丁文件与当前版本文件是否匹配；应用客户端在应用运行的过程中加载补丁文件包括：在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。

采用本发明实施例，提供了一种应用更新的方案。通过在应用客户端被启动时检测是否存在根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的补丁文件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，从而实现了提高应用客户端更新效率的技术效果，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题。

可选地，本实施例中的具体示例可以参考上述实施例1至实施例4中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图21所示的结构仅为示意，终端可以是智能手机(如android手机、ios手机等)、平板电脑、掌上电脑以及移动互联网设备(mobileinternetdevices，mid)、pad等终端设备。图21其并不对上述电子装置的结构造成限定。例如，终端还可包括比图21中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图21所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器 (read-onlymemory，rom)、随机存取器(randomaccessmemory，ram)、磁盘或光盘等。

实施例6

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行应用更新方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

s1，应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；

s2，应用服务器将生成的补丁文件发送至应用客户端；

s3，应用客户端在应用客户端被启动时检测是否存在补丁文件；

s4，应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用服务器获取应用的更新版本文件和当前版本文件；比对应用的更新版本文件和当前版本文件，获取应用的更新版本文件和当前版本文件之间存在差异的类文件；以及将类文件打包成补丁文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在应用运行的过程中加载补丁文件之后，应用客户端在应用接收 到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在未检测到补丁文件时或者在应用运行的过程中加载补丁文件之后，应用客户端向应用服务器请求是否存在应用最新的补丁文件；若存在最新的补丁文件，应用客户端则从应用服务器获取最新的补丁文件；应用客户端在应用被再次启动之后加载最新的补丁文件，以便对应用进行更新。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端对补丁文件进行安全校验；应用客户端在应用运行的过程中加载补丁文件包括：在安全校验通过时，应用客户端在应用运行的过程中加载补丁文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端判断补丁文件与当前版本文件是否匹配；应用客户端在应用运行的过程中加载补丁文件包括：在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。

可选地，本实施例中的具体示例可以参考上述实施例1至实施例4中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。