CN112035153B - 应用更新方法、装置、终端及存储介质 - Google Patents

Abstract

本发明实施例公开了一种应用更新方法、装置、终端及存储介质，属于计算机领域。方法包括：在应用的运行过程中，获取应用待更新的补丁文件，补丁文件包括第一类文件和第二函数的函数名，第一类文件中包括第一函数，第二函数为调用第一函数的函数；在应用下一次启动时，将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前；通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行，其中，第二类文件包括第二函数。只需将补丁文件插入到类加载器的类列表中，在确保应用更新成功的前提下，尽可能地减小系统资源以及内存的消耗，延长了终端的寿命。

Description

应用更新方法、装置、终端及存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种应用更新方法、装置、终端及存储介质。

背景技术

ART(Android Runtime，安卓运行环境)，是一种在Android(安卓)操作系统上的运行环境。在ART环境中采用了一种新的优化手段——内联(inlink)，通过将函数(method)直接嵌入到调用点来消除函数调用开销。换句话说，内联就是将函数A合并到调用该函数A的函数B中。但是当BUG(漏洞)类的函数为函数A时，直接加载补丁文件的话，函数B在调用时，依然会调用函数B中的函数A，而不会调用到补丁文件中，因此，无法解决应用存在的BUG。

目前，为了解决上述问题，终端从服务器中获取到补丁文件之后，会将获取到的补丁文件与应用的当前版本文件合成全量文件，在应用运行时，加载该全量文件。

但是，在获取到全量文件之后，还要对全量文件进行预编译，而对全量文件进行预编译会使终端性能开销较大，占用的内存空间也较大，并且，加载全量文件也会占用终端较大的内存空间，会影响终端的正常使用。

发明内容

本发明实施例提供了一种应用更新方法、装置、终端及存储介质，解决了相关技术存在的应用更新时，占用系统资源和内存较多的问题。所述技术方案如下：

一方面，提供了一种应用更新方法，所述方法包括：

在应用的运行过程中，获取应用待更新的补丁文件，所述补丁文件包括第一类文件和第二函数的函数名，所述第一类文件中包括第一函数，所述第二函数为调用所述第一函数的函数；

在所述应用下一次启动时，将所述补丁文件插入到类加载器的类列表中所述应用的原有版本的类文件之前；

通过所述类加载器对所述原有版本的类文件中第二类文件进行加载时，将所述第二函数的执行模式更新为解释执行，其中，所述第二类文件包括所述第二函数。

在一种可能实现方式中，所述第一类文件包括更新版本与所述原有版本之间的差异类的文件、所述差异类的子类的文件、引用所述差异类的父类的文件和引用所述子类的父类的文件。

在一种可能实现方式中，所述通过所述类加载器对所述原有版本的类文件中第二类文件进行加载时，将所述第二函数的执行模式更新为解释执行，包括下述任一步骤：

基于所述函数名，确定所述第二类文件，加载所述第二类文件，在加载所述第二类文件中的所述第二函数时，将所述第二函数的执行模式更新为所述解释执行；

当类加载器加载类文件中的函数时，基于所述函数名，确定所述函数是否为所述第二函数，若所述函数为所述第二函数，则将所述第二函数的执行模式更新为所述解释执行。

在一种可能实现方式中，在执行所述将所述补丁文件插入到类加载器的类列表中所述应用的原有版本的类文件之前的步骤之前，所述方法还包括：

基于所述第一类文件的类名，将类加载列表中与所述类名相同的类文件移除，所述类加载列表用于存储已预先加载的第三类文件；

清空缓存，所述缓存用于存储所述第三类文件中第三函数的函数字段。

在一种可能实现方式中，在所述将所述第二函数的执行模式更新为解释执行之后，所述方法还包括：

增加所述第二函数的热度，所述热度指示所述第二函数的被调用次数；

当所述热度达到热度阈值时，若所述第二函数被调用时，通过即时编译JIT对第二函数进行编译。

在一种可能实现方式中，所述增加所述第二函数的热度，包括：

获取所述第二函数中记录热度的函数字段；

将所述函数字段添加至热度增加列表中；

调用样本增加函数增加所述函数字段记录的热度。

再一方面，提供了一种应用更新装置，所述装置包括：

获取模块，用于在应用的运行过程中，获取应用待更新的补丁文件，所述补丁文件包括第一类文件和第二函数的函数名，所述第一类文件中包括第一函数，所述第二函数为调用所述第一函数的函数；

插入模块，用于在所述应用下一次启动时，将所述补丁文件插入到类加载器的类列表中所述应用的原有版本的类文件之前；

更新模块，用于通过所述类加载器对所述原有版本的类文件中第二类文件进行加载时，将所述第二函数的执行模式更新为解释执行，其中，所述第二类文件包括所述第二函数。

在一种可能实现方式中，所述第一类文件包括更新版本与所述原有版本之间的差异类的文件、所述差异类的子类的文件、引用所述差异类的父类的文件和引用所述子类的父类的文件。

在一种可能实现方式中，所述更新模块用于执行下述任一步骤：

基于所述函数名，确定所述第二类文件，加载所述第二类文件，在加载所述第二类文件中的所述第二函数时，将所述第二函数的执行模式更新为所述解释执行；

当类加载器加载类文件中的函数时，基于所述函数名，确定所述函数是否为所述第二函数，若所述函数为所述第二函数，则将所述第二函数的执行模式更新为所述解释执行。

在一种可能实现方式中，所述装置还包括：

移除模块，用于基于所述第一类文件的类名，将类加载列表中与所述类名相同的类文件移除，所述类加载列表用于存储已预先加载的第三类文件；

清空模块，用于清空缓存，所述缓存用于存储所述第三类文件中第三函数的函数字段。

在一种可能实现方式中，所述装置还包括：

热度增加模块，用于增加所述第二函数的热度，所述热度指示所述第二函数的被调用次数；

所述更新模块，用于当所述热度达到热度阈值时，若所述第二函数被调用时，通过即时编译JIT对第二函数进行编译。

在一种可能实现方式中，所述热度增加模块包括：

获取单元，用于获取所述第二函数中记录热度的函数字段；

添加单元，用于将所述函数字段添加至热度增加列表中；

热度增加单元，用于调用样本增加函数增加所述函数字段记录的热度。

再一方面，提供了一种终端，所述终端包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现所述的应用更新方法中所执行的操作。

再一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令，所述指令由一个或多个处理器加载并执行以实现如所述的应用更新方法中所执行的操作。

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

本发明实施例提供的方法、装置、终端及存储介质，在应用的运行过程中，获取应用待更新的补丁文件，在应用下一次启动时，将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前，通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行，其中，第二类文件包括第二函数。由于补丁文件中加入了第二函数的函数名，终端在加载第二函数时，通过将第二函数的执行模式更新为解释执行，不再使用预先编译好的oat文件，使得第二函数在调用第一函数时，不会调用BUG类文件中的第一函数，而是调用补丁文件中的第一函数，实现了应用更新时只需将补丁文件插入到类加载器的类列表中，无需将全量文件插入到类加载器的类列表中，节约了内存空间，并且只需对补丁文件进行预编译，减少了系统资源消耗，并且，编译后的文件占用内存空间也较小。在确保应用更新成功的前提下，尽可能地减小系统资源以及内存的消耗，延长了终端的寿命。

附图说明

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

图1是本发明实施例提供的一种补丁文件生成方法的流程图；

图2是本发明实施例提供的一种获取第二函数的方法名的流程图；

图3是本发明实施例提供的另一种补丁文件生成方法的流程图；

图4是本发明实施例提供的一种应用更新方法的流程图；

图5是本发明实施例提供的一种应用更新方法的流程图；

图6是本发明实施例提供的一种更新执行模式的流程图；

图7是本发明实施例提供的一种增加函数热度的流程图；

图8是本发明实施例提供的一种应用更新方法的流程图；

图9是本发明实施例提供的一种预加载函数的流程图；

图10是本发明实施例提供的一种清除预加载函数的流程图；

图11是本发明实施例提供的一种应用更新装置的结构示意图；

图12是本发明实施例提供的另一种应用更新装置的结构示意图；

图13是本发明实施例提供的一种终端的结构框图；

图14是本发明实施例提供的一种服务器的结构示意图。

具体实施方式

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

在对本发明实施例进行详细说明之前，首先对涉及到的概念进行如下解释：

类文件：类文件是用于承载类以及该类的相关代码的文件，它的形式可以为.class文件或者.dex文件。

本发明实施例涉及到三种类文件，分别是

1、第一类文件：第一类文件用于更新应用，由至少一个用于更新应用的类文件构成，是基于应用的更新版本和原有版本生成的，如包含更新版本与原有版本之间差异类的文件、包含差异类的子类的文件等。

2、第二类文件：第二类文件为原有版本中的一部分类文件，第二类文件中的函数会调用第一类文件中函数。

3、第三类文件：不同的类被调用的次数不同，热度指示类被调用的次数，当某个类的调用次数达到热度阈值时，该热为热类。第三类文件中包含至少一个热类的类文件。

其中，第一、第二和第三仅是表示三个文件本身的区别，其实际的文件格式没有区别。

函数：每个类均会定义至少一个函数，类文件中包括该类的函数，该函数以代码的形式存储在类文件中。

本发明实施例涉及到三种函数，分别是：

4、第一函数：每个类的文件中都包含至少一个函数，第一类文件中包含的所有函数统称为第一函数。

5、第二函数：第二函数为调用第一函数的至少一个上层函数，具体的，若第一函数被嵌入到第一上层函数中，则第二函数包括第一上层函数，若第一上层函数内嵌到第二上层函数中，则第二函数还包括第二上层函数。第二函数被包含在第二类文件中。

6、第三函数：不同的函数被调用的次数不同，热度指示函数被调用的次数，当某个类的调用次数达到热度阈值时，该函数为热函数，第三函数即为热函数，第三函数被包含在第三类文件中。

本发明实施例提供的应用更新方法可以应用在ART场景下，ART是一种在Android操作系统上的运行环境。ART引入了预先编译机制，通过dex2oat在应用运行以前将类文件中的Dalvik字节码预编译成机器码存储在本地，其中，编译后的机器码可以存在预编译(oat)文件中。

需要说明的是，在ART环境中是多种编译方式共存，即在ART环境中可以对类文件进行预编译，也可以通过解释器(interperter)对类文件进行解释处理，还可以通过JIT(Just-In-Time，即时)编译进行编译。

针对类文件中的每个函数，在ART环境中函数的执行模式分为两种，第一种是本地机器指令执行，第二种是解释执行。在ART环境下会通过预编译是将类文件进行编译得到oat文件，将编译后的oat文件存储在内存中，当类文件中的某个函数被加载时，若该函数对应的执行模式为本地机器指令执行时，直接从oat文件中获取编译后的该函数，每次使用时都无需再次进行编译。若该函数对应的执行模式为解释执行时，则需要通过解释器对函数进行解释，且每次加载该函数时，均需要通过解释器进行解释。另外，对于通过解释器进行解释的函数，当该函数的热度超过热度阈值时，会触发JIT对该函数进行编译，并将编译后的函数存储在本地缓存中，在应用的本次运行过程中，可以直接使用通过JIT编译后的函数。

为了实现应用的更新，实际上在开发侧需要进行补丁文件的生成，本实施例对补丁文件的生成进行介绍。图1是本发明实施例提供的一种补丁文件生成方法的流程图，该补丁文件生成方法的执行主体可以为计算机设备，参见图1，该方法包括：

101、获取第一类文件，第一类文件至少包括应用的更新版本与原有版本之间的差异类的文件，第一类文件中包括第一函数。

其中，原有版本为应用的旧版本，更新版本为应用的最新版本。差异类可以为更新版本中相较于原有版本被修改的类或者新增的类。针对每个类都可以对应一个类文件，该类文件中可以包括该类对应的函数。

其中，获取差异类的具体方法可以为：计算机设备通过编译器将应用的更新版本文件和原有版本文件编译为class类文件，经过对比更新版本的class类文件和原有版本的class类文件，得到存在差异的class类文件，通过dx工具将该差异类的class类文件转换成dex文件。其中class类文件与dex文件的区别在于，class类文件中存在冗余信息，dex文件则去掉了冗余信息，并且整合了整个类文件的信息。

需要说明的是，如果类文件中的函数存在被增减、类文件中的字段被增减、父类发生改变或者接口发生改变等情况，都有可能会导致类布局发生变化，此时需要将引用该差异类的父类或者该差异类引用的子类也放入补丁文件中。在一种可能实现方式中，若类布局发生改变，则获取差异类的子类的文件、引用差异类的父类的文件和引用子类的父类的文件，第一类文件包括差异类的文件、子类的文件、引用差异类的父类的文件和引用子类的父类的文件。

例如，基于更新版本文件和原有版本文件，找出被修改的类和新增加的类，基于被修改后的类和新增加的类，生成classes.dex，对于类布局发生改变的情况，将差异类的子类的文件加入到classes.dex，将引用差异类的父类的文件以及引用子类的父类的文件加入到classes.dex，其中，classes.dex为第一类文件。

102、获取调用第一函数的第二函数的函数名。

若第一函数被嵌入到上层函数中，则获取调用第一函数的上层函数的函数名，该上层函数为第二函数，具体的获取过程可以为：若第一函数被嵌入到第一上层函数中，则获取第一上层函数的函数名；若第一上层函数被嵌入到第二上层函数中，则获取第二上层函数的函数名；直至获取到的函数名对应的上层函数未被嵌入其他函数时，停止获取。

例如，如图2所示，函数1和函数2为第一函数，函数3调用函数1，若函数1被嵌入到函数3中，则获取函数3的函数名。函数4调用函数2，若函数2被嵌入到函数4中，则获取函数4的函数名，确定函数3和函数4是否被嵌入到其上层函数中，若被嵌入到其上层函数中，则继续获取其上层函数的函数名。

另外，可以生成一个函数文本文件，用于记录获取到的函数名。例如，创建一个methods.txt(函数文本文件)，每获取一个函数的函数名时，将该函数名添加到该methods.txt中。

需要说明的是，当第一函数被嵌入到第一上层函数时，即是第一函数被内联，ART环境中函数被内联的层级数是有限制的，可以基于内联的最高层级数，来获取第一函数的上层函数的函数名。例如，内联的最高层级数为4层，则至多向上回溯4层。

103、基于第一类文件和第二函数的函数名生成待更新的补丁文件。

生成补丁文件的具体方式可以为：在一种可能实现方式中，将第一类文件和函数文本文件打包成补丁文件。在另一种可能实现方式中，基于第一类文件，获取第一类文件中所有类的类名，将类名添加至类名文本文件中，将第一类文件、类名文本文件和函数文本文件打包成补丁文件。

例如，如图3所示，将第一类文件classes.dex、类名文本文件classes.txt和函数文本文件methods.txt打包为patch.jar补丁文件。

需要说明的是，在生成补丁文件之后，服务器向终端下发补丁文件之前，可以选择任一安装有该应用的终端下载该补丁文件，通过运行该应用验证应用的BUG是否被修复，当补丁文件能够修复BUG后，由服务器将补丁文件下发给其他终端。

本实施例提供的补丁文件生成方法，通过获取第一类文件，第一类文件至少包括应用的更新版本与原有版本之间的差异类的文件，第一类文件中包括第一函数，获取调用第一函数的第二函数的函数名，基于第一类文件和函数名生成待更新的补丁文件。由于在补丁文件中加入了第一类文件和第二函数的函数名，使得终端能够通过第一类文件能够替换BUG类文件，并通过第二函数的函数名，在加载第二函数时，将第二函数的执行模式更新为解释执行，这样，当第二函数调用第一函数时，能够确保调用的第一函数为第一类文件中的第一函数，而非BUG类文件中的第一函数，使得应用更新成功。相比现有技术中，需要将补丁文件与原有版本文件合成全量文件，加载全量文件来确保调用第一函数时，调用到补丁文件中的方案，本实施例只需加载补丁文件，节约了内存空间，并且只需对补丁文件进行预编译，减少了系统资源消耗，并且，编译后的文件占用内存空间也较小。在确保应用更新成功的前提下，尽可能地减小系统资源以及内存的消耗，延长了终端的寿命。

图4是本发明实施例提供的一种应用更新方法的流程图。本发明实施例对获取应用的补丁文件以及基于补丁文件更新应用的过程进行说明，执行主体为终端，该终端可以为手机、电脑等任一安装有应用的设备。参见图4，该方法包括：

401、在应用的运行过程中，终端获取应用待更新的补丁文件。

获取应用待更新的补丁文件的方式可以为终端主动获取或者服务器主动下发，其中服务器为与该应用关联的服务器。在一种可能实现方式中，在应用的运行过程中，终端向服务器请求是否存在应用待更新的补丁文件，若存在待更新的补丁文件，则终端从服务器获取该补丁文件。其中终端向服务器请求时，可以向服务器发送应用的当前版本号，服务器基于接收到的当前版本号与服务器中存储的最新版本号进行对比，判断是否存在应用待更新的补丁文件。当终端的当前版本号与应用的最新版本号相同时，则确定不存在应用待更新的补丁文件，当终端的当前版本号小于应用的最新版本号时，则确定存在应用待更新的补丁文件。

在另一种可能实现方式中，在应用的运行过程中，服务器向终端下发更新通知消息，该更新通知消息用于告知终端服务器上存在待更新的补丁文件，终端在获取该更新通知消息后，可以选择是否从服务器中获取该补丁文件。服务器在获取到开发人员所发布的待更新的补丁文件之后，可以主动向终端发送更新通知消息，以使终端能够尽快获取补丁文件，从而进行修复。

另外，在获取到补丁文件后，终端可以对补丁文件进行预编译，由于预编译会占用一部分的系统资源，因此，该预编译过程可以在终端的充电过程中或者其他不会影响终端进程时进行。

402、在应用下一次启动时，终端将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前。

在应用下一次启动时，终端可以检测本地是否存储有待更新的补丁文件，其中补丁文件中可以存储有版本号，基于终端应用原有版本的版本号和补丁文件的版本号，确定补丁文件的版本号是否大于原有版本的版本号，当补丁文件的版本号大于原有版本的版本号时，确定该补丁文件为待更新的补丁文件，将该补丁文件插入到类加载器的类列表中。在应用下一次启动时，自动对应用进行更新，实现了用户无感知的修复。

其中，类列表用于放置类文件，通过类加载器可以加载类列表中的类文件，当通过类加载器加载类文件时，会基于类名，按照类文件的先后排列顺序在类列表中进行查找，当查找到该类文件时，即对该类文件进行加载，不再查找后续的类文件。如果在不同的类文件中有相同的类存在，那么类加载器会加载排在前面的类文件中的类。因此将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前，可以保证补丁文件中的类文件被优先加载，从而实现BUG的修复。

其中，将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前的具体实现方式可以为：将补丁文件插入到类列表的首位，以保证补丁文件在原有版本的类文件之前；还可以为：确定原有版本的类文件在类列表中的位置，将补丁文件插入到原有版本的类文件之前。

例如，在应用被启动时，终端如果检测到存在待更新的补丁文件，则可以通过ClassLoader类加载器的方式加载待更新的patch.jar补丁文件。如图5中的第二步所示，具体方式可以为：类加载器(ClassLoader)中包含多个类文件(class.dex)，将补丁文件(patch.jar)插入到类加载器中多个类文件之前。

需要说明的是，在将补丁文件插入到类加载器的类列表中之后，基于补丁文件的版本号更新终端应用的版本号。

403、终端通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行，其中，第二类文件包括第二函数。

其中，将第二函数的执行模式更新为解释执行的步骤可以是以下两种执行时机，一种执行时机可以是在类加载器中插入补丁文件之后，将第二函数的执行模式统一更新为解释执行；又一种执行时机可以是在第二函数被加载时，将第二函数的执行模式更新为解释执行。

在一种可能实现方式中，基于第二函数的函数名，确定第二类文件，加载第二类文件，在加载第二类文件中的第二函数时，将第二函数的执行模式更新为解释执行。在将补丁文件插入到类加载器之后，基于补丁文件中的函数文本文件，可以获取到所有第二函数的函数名，由于类文件的文件头中记录着该类文件的所有信息，因此，基于函数名可以获取包含第二函数的所有类文件，该包含第二函数的类文件为第二类文件。通终端过主动加载第二类文件，来统一修改第二函数的执行模式，加快了应用的更新速度。

在另一种可能实现方式中，当类加载器加载类文件中的任一函数时，基于函数名，确定函数是否为第二函数，若函数为第二函数，则将第二函数的执行模式更新为解释执行。也即，只有在第二函数对应的类文件被加载时，才会触发将第二函数的执行模式更新为解释执行。通过这种延迟修改的方式，可以减少更新过程对终端系统的资源消耗，以实现用户无感知的对应用的修复。

另外，类文件中包括method_info(函数的结构体)，其中method_info中包括多个函数字段，可以用于记录函数的执行模式、函数的调用次数等。将第二函数的执行模式更新为解释执行的具体过程可以为：通过修改第二函数对应的类文件中结构体的函数字段记录的内容，使得该函数字段指示的执行模式更新为解释执行。

例如，该函数字段记录着参数x的值，x＝0时，该函数的执行模式为本地机器指令执行，x＝1时，该函数的执行模式为解释执行。通过更新x的赋值，可以实现函数的执行模式的更新。

如图6所示，示出了如何通过修改函数的执行模式，来避免内联带来的影响。具体的：当函数3调用函数1时，由于预编译生成oat文件，函数1被内联到函数3。当只是将补丁文件插入类加载器(ClassLoader)时，函数3在调用函数1时，会调用被内联到函数3中的函数1，而不会调用到第一类文件中的函数1。而通过将函数3的执行模式更新为解释执行，不再使用oat文件中编译后的函数，就可以实现函数3调用函数1时定位到补丁文件中，保证逻辑正确。

404、终端增加第二函数的热度，热度指示第二函数的被调用次数。

其中，类文件中的method_info函数的结构体中包括多个函数字段，可以用于记录函数的执行模式、函数的调用次数等。当第二函数被调用时，类文件的函数字段对应的调用次数就会加1，该调用次数为该函数的热度。

对于通过解释器解释的函数，当该函数的热度达到热度阈值时，会触发JIT对该函数进行编译，为了加快触发JIT对该函数进行编译，可以主动增加第二函数的函数热度。

在一种可能实现方式中，该步骤404可以包括：获取第二函数中记录热度的函数字段，将该函数字段添加至热度增加列表中；调用样本增加函数增加该函数字段记录的热度。具体的：对于methods.txt中记录的函数名，如果该函数名对应的第二函数在安装补丁文件之前，执行模式不是解释执行，则认为该第二函数为高频函数，将所有的高频函数中记录热度的函数字段放入热度增加列表中，调用样本增加函数(jit.AddSamples)来增加函数字段记录的热度，使得函数字段记录的热度达到热度阈值。例如，该热度为10000，代表该函数被调用的次数达到10000。

如图7所示，获取调用树，基于oat文件判断第二函数在安装补丁文件之前是否为解释执行，将在安装补丁文件之前，执行模式不是解释执行的第二函数筛选到高频函数列表中，在高频函数列表中可以只存储函数的函数名。在筛选完成之后，对于高频函数列表中的函数，调用jit.AddSamples增加该函数的热度。

405、当热度达到热度阈值时，若第二函数被调用时，终端通过即时编译JIT对第二函数进行编译。

触发即时编辑JIT对第二函数进行编译的具体过程可以为：在一种可能实现方式中，当第二函数被调用时，获取第二函数的热度，当第二函数的热度大于热度阈值时，触发即时编译JIT对第二函数进行编译。在另一种可能实现方式中，获取热度大于热度阈值的函数，将该函数的函数名记录在热函数列表中，当调用第二函数时，若该第二函数的执行模式为解释执行，且该第二函数的函数名在热函数列表中时，通过即时编译JIT对该第二函数进行编译。

在通过JIT即时编译对第二函数进行编译之后，可以将编译后的第二函数存储在本地缓存中，在应用的本次使用过程中，可以直接调用编译后的第二函数。

图5中步骤2-4示出了步骤301-305的过程。需要说明的是，步骤304-305为本实施的优化措施，本实施例可以包括步骤304-305也可以不包括步骤304-305，同样图5可以实施步骤4，也可以不实施步骤4。

本实施例提供的应用更新方法，在应用的运行过程中，获取应用待更新的补丁文件，在应用下一次启动时，将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前，通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行，其中，第二类文件包括第二函数。由于补丁文件中加入了第二函数的函数名，终端在加载第二函数时，通过将第二函数的执行模式更新为解释执行，不再使用预先编译好的oat文件，使得第二函数在调用第一函数时，不会调用BUG类文件中的第一函数，而是调用到补丁文件中的第一函数，实现了应用更新时只需将补丁文件插入到类加载器的类列表中，无需将全量文件插入到类加载器的类列表中，节约了内存空间，并且只需对补丁文件进行预编译，减少了系统资源消耗，并且，编译后的文件占用内存空间也较小。在确保应用更新成功的前提下，尽可能地减小系统资源以及内存的消耗，延长了终端的寿命。

并且，在将第二函数的执行模式更新为解释执行之后，还会通过调用样本增加函数来增加第二函数的函数热度，加快触发第二函数的JIT流程，通过JIT编译将函数代码编译成与本地平台相关的机器码，并进行优化，加快了执行效率。

上述图4至图7所示实施例，是基于终端获取补丁文件，以及将补丁文件插入到类加载器的过程进行说明，而在一种可能实施例中，应用在开启后会进行预加载过程，下面基于图8对应用在预加载的情况下，如何基于补丁文件更新应用的过程进行说明。图8是本发明实施例提供的一种应用更新方法的流程图。参见图8，该方法包括：

801、在应用的运行过程中，终端获取应用待更新的补丁文件。

其中，图5示出了步骤801-807的应用更新方法流程图。

另外，步骤801与步骤401类似，在此不再赘述。

802、在应用下一次启动时，基于第一类文件的类名，终端将类加载列表中与类名相同的类文件移除，类加载列表用于存储已预先加载的第三类文件。

预加载是ART运行下的一种优化手段，在应用启动后，对于一些经常使用的第三类文件，应用在启动后，会将这些类文件预先加载好，在后续的使用过程中无需对这些类文件进行加载，具体的将已预先加载的第三类文件存储在类加载列表中，将第三类文件中第三函数的函数字段存储在缓存中，该函数字段为函数的索引，用于指向被调用的函数。

另外，在某些类文件被加载到类加载列表后，则在对某个类文件进行查找时，会优先查找类加载列表，在类加载列表中未查找到该类文件时，才会在类加载器中的类列表中进行查找。若在应用启动后直接将补丁文件插入到类加载类表中，且被修复的类文件被预加载的情况下，终端应用会在类加载列表中调用到被修复的类文件，而不会调用到补丁文件中，从而无法加载补丁文件中的第一类文件，导致应用更新失败。

因此，在应用启动后，可以先将类加载列表中与第一类文件的类名相同的类文件移除，这样，在调用类文件时，可以避免调用到被修复的类文件，保证了补丁文件中的第一类文件被正确调用，并且当再次将类文件进行预加载时，还可将补丁文件中相应的类文件预加载到类加载列表中。

例如，如图9所示，在应用启动后，会加载类的文件(DexFile)，调用DexFile中的打开类文件函数(openDexFile)，openDexFile调用打开本地类文件函数(openDexFileNative)，通过打开类文件创建函数(OpenDexFilesFromOat)创建预编译文件对象(OatFileManager)，调用增加对象空间函数(AddImageSpace)，创建类线程(ClassLinker)，如果存在基础文件(base.art)，通过Classlinker对base.art文件中的类和函数进行加载，该base.art文件中记录了经常使用的第三类文件和第三类文件中的第三函数。加载base.art文件的具体过程为将加载后的第三类文件插入到类加载列表(ClassTable)中，将第三函数的函数字段添加到缓存(DexCache)中。类查找函数(FindClass)会优先在类加载列表(ClassTable)中查找类，未找到时才通过类加载器(ClassLoader)中的类列表中查找。

如图10所示，基于类名文本文件中记录的类名，将类加载列表中的具有相同类名的类文件移除，在移除之后，类查找函数(FindClass)在类加载列表(ClassTable)中无法查找到被修复的类文件，从而在类加载器(ClassLoader)中的类列表中查找到第一类文件，实现第一类文件的调用。

803、终端清空缓存，缓存用于存储第三类文件中第三函数的函数字段。

将缓存中的函数字段清空后，当终端调用第三函数时，终端会在DexCache中查找该函数的函数字段，若未查找到该函数字段的话，从类加载列表中的类文件中重新获取该函数字段，并在该函数字段所在的位置执行该函数字段对应的函数。

需要说明的是，当终端检测到缓存位置为空时，可以触发在类加载类表中的第三类文件中进行查找，通过查找获取到第三函数的函数字段，将函数字段存储在DexCache缓存中。

804、终端将补丁文件插入到类加载器的类列表中原有版本的类文件之前。

如图10所示，在将补丁文件插入类加载器的类列表中之后，可以基于类加载列表(ClassTable)中被移除的类文件的类名，获取类加载器的类列表中与被移除的类文件类名相同的类文件，加载该类文件，并将加载后的类文件添加至类加载列表(ClassTable)中。

805、终端通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行，其中，第二类文件包括第二函数。

806、终端增加第二函数的函数热度，热度指示第二函数的被调用次数。

807、当热度达到热度阈值时，若第二函数被调用时，终端通过即时编译JIT对第二函数进行编译。

其中，步骤804至807与步骤402至405类似，在此不再赘述。另外，步骤806-807为本实施的优化措施，本实施例可以包括步骤806-807也可以不包括步骤806-807。

本实施例提供的应用更新方法，通过获取第一类文件，第一类文件至少包括应用的更新版本与原有版本之间的差异类的文件，第一类文件中包括第一函数，在应用下一次启动时，基于第一类文件的类名，将类加载列表中与类名相同的类文件移除，类加载列表用于存储已预先加载的第三类文件，并且清空缓存，缓存用于存储第三类文件中第三函数的函数字段，之后，将补丁文件插入到类加载器的类列表中原有版本的类文件之前，通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行。本实施例考虑到了应用可能存在预加载的情况，并对预加载的BUG类文件进行清除，以及清空缓存，确保了补丁文件在加入到类加载器的类列表中之后，能够调用补丁文件中的第一类文件，而非BUG类文件。

并且，在将第二函数的执行模式更新为解释执行之后，还会通过调用样本增加函数来增加第二函数的函数热度，加快触发第二函数的即时编译JIT流程，通过即时编译JIT将函数代码编译成与本地平台相关的机器码，并进行优化，加快了执行效率。

图11是本发明实施例提供的一种应用更新装置的结构示意图。该参见图11，该装置包括：

获取模块1101，用于在应用的运行过程中，获取应用待更新的补丁文件，补丁文件包括第一类文件和第二函数的函数名，第一类文件中包括第一函数，第二函数为调用第一函数的函数；

插入模块1102，用于在应用下一次启动时，将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前；

更新模块1103，用于通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行，其中，第二类文件包括第二函数。

本发明实施例提供的装置，在应用的运行过程中，获取应用待更新的补丁文件，在应用下一次启动时，将补丁文件插入到类加载器的类列表中应用的原有版本的类文件之前，通过类加载器对原有版本的类文件中第二类文件进行加载时，将第二函数的执行模式更新为解释执行，其中，第二类文件包括第二函数。由于补丁文件中加入了第二函数的函数名，终端在加载第二函数时，通过将第二函数的执行模式更新为解释执行，使得第二函数在调用第一函数时，不会调用到BUG类文件中，而是调用到补丁文件中，实现了应用更新时只需将补丁文件插入到类加载器的类列表中，无需将全量文件插入到类加载器的类列表中，节约了内存空间，并且只需对补丁文件进行预编译，减少了系统资源消耗，并且，编译后的文件占用内存空间也较小。在确保应用更新成功的前提下，尽可能地减小系统资源以及内存的消耗，延长了终端的寿命。

在一种可能实现方式中，第一类文件包括更新版本与原有版本之间的差异类的文件、差异类的子类的文件、引用差异类的父类的文件和引用子类的父类的文件。

在一种可能实现方式中，更新模块1103用于执行下述任一步骤：

基于函数名，确定第二类文件，加载第二类文件，在加载第二类文件中的第二函数时，将第二函数的执行模式更新为解释执行；

当类加载器加载类文件中的函数时，基于函数名，确定函数是否为第二函数，若函数为第二函数，则将第二函数的执行模式更新为解释执行。

在一种可能实现方式中，如图12所示，装置还包括：

移除模块1104，用于基于第一类文件的类名，将类加载列表中与类名相同的类文件移除，类加载列表用于存储已预先加载的第三类文件；

清空模块1105，用于清空缓存，缓存用于存储第三类文件中第三函数的函数字段。

在一种可能实现方式中，如图12所示，装置还包括：

热度增加模块1106，用于增加第二函数的热度，热度指示第二函数的被调用次数；

编译模块1107，用于当热度达到热度阈值时，若第二函数被调用时，通过即时编译JIT对第二函数进行编译。

在一种可能实现方式中，如图12所示，热度增加模块1106包括：

获取单元11061，用于获取第二函数中记录热度的函数字段；

添加单元11062，用于将函数字段添加至热度增加列表中；

热度增加单元11063，用于调用样本增加函数来增加函数字段记录的热度。

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

图13是本发明实施例提供的一种终端的结构框图。该终端1300用于执行上述实施例中终端或智能设备执行的步骤，可以是便携式移动终端，比如：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端1300还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端1300包括有：处理器1301和存储器1302。

处理器1301可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1301可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1301也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1301可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1301还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1302可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1302还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1302中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1301所执行以实现本申请中方法实施例提供的应用更新方法。

在一些实施例中，终端1300还可选包括有：外围设备接口1303和至少一个外围设备。处理器1301、存储器1302和外围设备接口1303之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口1303相连。具体地，外围设备包括：射频电路1304、触摸显示屏1305、摄像头1306、音频电路1307、定位组件1308和电源1309中的至少一种。

外围设备接口1303可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器1301和存储器1302。在一些实施例中，处理器1301、存储器1302和外围设备接口1303被集成在同一芯片或电路板上；在一些其他实施例中，处理器1301、存储器1302和外围设备接口1303中的任意一个或两个可以在单独的芯片或电路板上实现，本发明实施例对此不加以限定。

射频电路1304用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路1304通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1304将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1304包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路1304可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路1304还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏1305用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1305是触摸显示屏时，显示屏1305还具有采集在显示屏1305的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1301进行处理。此时，显示屏1305还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1305可以为一个，设置终端1300的前面板；在另一些实施例中，显示屏1305可以为至少两个，分别设置在终端1300的不同表面或呈折叠设计；在再一些实施例中，显示屏1305可以是柔性显示屏，设置在终端1300的弯曲表面上或折叠面上。甚至，显示屏1305还可以设置成非矩形的不规则图形，也即异形屏。显示屏1305可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

摄像头组件1306用于采集图像或视频。可选地，摄像头组件1306包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1306还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路1307可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1301进行处理，或者输入至射频电路1304以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端1300的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1301或射频电路1304的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1307还可以包括耳机插孔。

定位组件1308用于定位终端1300的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件1308可以是基于美国的GPS(GlobalPositioning System，全球定位系统)、中国的北斗系统或俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源1309用于为终端1300中的各个组件进行供电。电源1309可以是交流电、直流电、一次性电池或可充电电池。当电源1309包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端1300还包括有一个或多个传感器1310。该一个或多个传感器1310包括但不限于：加速度传感器1311、陀螺仪传感器1312、压力传感器1313、指纹传感器1314、光学传感器1315以及接近传感器1316。

加速度传感器1311可以检测以终端1300建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1311可以用于检测重力加速度在三个坐标轴上的分量。处理器1301可以根据加速度传感器1311采集的重力加速度信号，控制触摸显示屏1305以横向视图或纵向视图进行用户界面的显示。加速度传感器1311还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器1312可以检测终端1300的机体方向及转动角度，陀螺仪传感器1312可以与加速度传感器1311协同采集用户对终端1300的3D动作。处理器1301根据陀螺仪传感器1312采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器1313可以设置在终端1300的侧边框和/或触摸显示屏1305的下层。当压力传感器1313设置在终端1300的侧边框时，可以检测用户对终端1300的握持信号，由处理器1301根据压力传感器1313采集的握持信号进行左右手识别或快捷操作。当压力传感器1313设置在触摸显示屏1305的下层时，由处理器1301根据用户对触摸显示屏1305的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器1314用于采集用户的指纹，由处理器1301根据指纹传感器1314采集到的指纹识别用户的身份，或者，由指纹传感器1314根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1301授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器1314可以被设置终端1300的正面、背面或侧面。当终端1300上设置有物理按键或厂商Logo时，指纹传感器1314可以与物理按键或厂商标志集成在一起。

光学传感器1315用于采集环境光强度。在一个实施例中，处理器1301可以根据光学传感器1315采集的环境光强度，控制触摸显示屏1305的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏1305的显示亮度；当环境光强度较低时，调低触摸显示屏1305的显示亮度。在另一个实施例中，处理器1301还可以根据光学传感器1315采集的环境光强度，动态调整摄像头组件1306的拍摄参数。

接近传感器1316，也称距离传感器，通常设置在终端1300的前面板。接近传感器1316用于采集用户与终端1300的正面之间的距离。在一个实施例中，当接近传感器1316检测到用户与终端1300的正面之间的距离逐渐变小时，由处理器1301控制触摸显示屏1305从亮屏状态切换为息屏状态；当接近传感器1316检测到用户与终端1300的正面之间的距离逐渐变大时，由处理器1301控制触摸显示屏1305从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图13中示出的结构并不构成对终端1300的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

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

服务器1400可以用于执行上述应用更新方法中服务器所执行的步骤。

本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有至少一条指令，该指令由处理器加载并执行以实现上述实施例的应用更新方法中所执行的操作。

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

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

Claims (8)

1.一种应用更新方法，其特征在于，所述方法包括：

在应用的运行过程中，获取所述应用待更新的补丁文件，所述补丁文件包括第一类文件和第二函数的函数名，所述第一类文件中包括第一函数，所述第二函数为调用所述第一函数的函数，所述第一类文件是基于所述应用的更新版本和原有版本生成的，用于更新所述应用的文件；

在所述应用下一次启动时，将所述补丁文件插入到类加载器的类列表中所述原有版本的类文件之前；

通过所述类加载器对所述原有版本的类文件中第二类文件进行加载时，将所述第二函数的执行模式更新为解释执行，其中，所述第二类文件包括所述第二函数；

所述通过所述类加载器对所述原有版本的类文件中第二类文件进行加载时，将所述第二函数的执行模式更新为解释执行，包括下述任一步骤：

基于所述函数名，确定所述第二类文件，加载所述第二类文件，在加载所述第二类文件中的所述第二函数时，将所述第二函数的执行模式更新为所述解释执行；

当所述类加载器加载类文件中的函数时，基于所述函数名，确定所述函数是否为所述第二函数，若所述函数为所述第二函数，则将所述第二函数的执行模式更新为所述解释执行。

2.根据权利要求1所述的方法，其特征在于，所述第一类文件包括所述更新版本与所述原有版本之间的差异类的文件、所述差异类的子类的文件、引用所述差异类的父类的文件和引用所述子类的父类的文件。

3.根据权利要求1所述的方法，其特征在于，在执行所述将所述补丁文件插入到类加载器的类列表中所述原有版本的类文件之前的步骤之前，所述方法还包括：

基于所述第一类文件的类名，将类加载列表中与所述类名相同的类文件移除，所述类加载列表用于存储已预先加载的第三类文件；

清空缓存，所述缓存用于存储所述第三类文件中第三函数的函数字段。

4.根据权利要求1所述的方法，其特征在于，在所述将所述第二函数的执行模式更新为解释执行之后，所述方法还包括：

增加所述第二函数的热度，所述热度指示所述第二函数的被调用次数；

当所述热度达到热度阈值时，若所述第二函数被调用时，通过即时编译JIT对所述第二函数进行编译。

5.根据权利要求4所述的方法，其特征在于，所述增加所述第二函数的热度，包括：

获取所述第二函数中记录热度的函数字段；

将所述函数字段添加至热度增加列表中；

调用样本增加函数增加所述函数字段记录的热度。

6.一种应用更新装置，其特征在于，所述装置包括：

获取模块，用于在应用的运行过程中，获取所述应用待更新的补丁文件，所述补丁文件包括第一类文件和第二函数的函数名，所述第一类文件中包括第一函数，所述第二函数为调用所述第一函数的函数，所述第一类文件是基于所述应用的更新版本和原有版本生成的，用于更新所述应用的文件；

插入模块，用于在所述应用下一次启动时，将所述补丁文件插入到类加载器的类列表中所述应用的原有版本的类文件之前；

更新模块，用于通过所述类加载器对所述原有版本的类文件中第二类文件进行加载时，将所述第二函数的执行模式更新为解释执行，其中，所述第二类文件包括所述第二函数；

所述更新模块用于执行下述任一步骤：

基于所述函数名，确定所述第二类文件，加载所述第二类文件，在加载所述第二类文件中的所述第二函数时，将所述第二函数的执行模式更新为所述解释执行；

当所述类加载器加载类文件中的函数时，基于所述函数名，确定所述函数是否为所述第二函数，若所述函数为所述第二函数，则将所述第二函数的执行模式更新为所述解释执行。

7.一种终端，其特征在于，所述终端包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如权利要求1至5任一权利要求所述的应用更新方法中所执行的操作。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如权利要求1至5任一权利要求所述的应用更新方法中所执行的操作。

Images