CN116737254A - 类加载方法、装置、设备及介质 - Google Patents

Abstract

本公开提供了一种类加载方法、装置、设备及介质，该方法包括：当接收到携带待加载类名的类加载请求后，首先，调用第一路径类加载器在第一镜像文件中查找待加载类名；其中，第一路径类加载器为系统内置类加载器，第一路径类加载器关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件；然后，如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。由此可知，在需要加载大量的自定义类的动态化场景下，提高了类加载效率，进一步保证了Android平台下类加载的性能。

Description

类加载方法、装置、设备及介质

技术领域

本公开涉及计算机领域，尤其涉及一种类加载方法、装置、设备及介质。

背景技术

对于在Android平台下运行的应用程序，其运行过程中会涉及到大量类Class的加载。其中，自定义类是应用程序运行过程中需要动态加载的数量较多的类。

在需要加载大量的自定义类的动态化场景，应用程序运行过程中，为了保证自定义类能够在合适的时机被加载，需要定义新的类加载器，并利用新定义的类加载器加载自定义类。但是，新定义的类加载器由于违反了Android平台下的类加载器的限制，因此不能调用新定义的类加载器从镜像文件中查找自定义类，只能通过调用其父级加载器优先从系统类的文件中加载自定义类，在未加载成功的情况下，才能从自定义类的文件中加载自定义类。显然，在需要加载大量的自定义类的动态化场景下，类加载方式繁琐且类加载效率较低，影响了Android平台下类加载的性能。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种类加载方法、装置、设备及介质。

第一方面，本公开提供了一种类加载方法，该方法包括：

当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找待加载类名；其中，第一路径类加载器为系统内置类加载器，第一路径类加载器关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件；

如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。

第二方面，本公开提供了一种类加载装置，该装置包括：

待加载类名查找模块，用于当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找所述待加载类名；其中，所述第一路径类加载器为系统内置类加载器，所述第一路径类加载器关联有第一可执行文件的路径，所述第一可执行文件中包括自定义类，所述第一镜像文件为所述第一可执行文件对应的镜像文件；

类加载模块，用于如果确定在所述第一镜像文件中未查找到所述待加载类名，则调用所述第一路径类加载器的父级加载器，并由所述父级加载器调用所述第一路径类加载器中的类加载函数，对所述待加载类名对应的类进行加载。

第三方面，本公开提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备实现上述的方法。

第四方面，本公开提供了一种设备，包括：存储器，处理器，及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现上述的方法。

第五方面，本公开提供了一种计算机程序产品，所述计算机程序产品包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现上述的方法。

本公开实施例提供的技术方案与现有技术相比至少具有如下优点：

本公开实施例提供了一种类加载方法、装置、设备及介质，当接收到携带待加载类名的类加载请求后，首先，调用第一路径类加载器在第一镜像文件中查找待加载类名，然后，如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。由于第一路径类加载器为系统内置类加载器，第一路径类加载器关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件，因此，第一路径类加载器可以直接在第一镜像文件中查找自定义类，相比于现有方案中在调用父级加载器加载系统类失败之后，才能加载自定义的方案来说，显然简化了自定义类的查找流程；另外，如果从镜像文件中未查找到该类名，还可以利用父级加载器返回至第一路径类加载器继续进行加载，这样，保证了类加载过程的完善性和可靠性。综上，在需要加载大量的自定义类的动态化场景下，提高了类加载效率，进一步保证了Android平台下类加载的性能。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1为现有技术提供的一种类加载方法的原理示意图；

图2为现有技术提供的另一种类加载方法的原理示意图；

图3为本公开实施例提供的一种类加载方法的流程示意图；

图4为本公开实施例提供的另一种类加载方法的流程示意图；

图5为本公开实施例提供的一种类加载方法的原理示意图；

图6为本公开实施例提供的另一种类加载方法的原理示意图；

图7为本公开实施例提供的又一种类加载方法的流程示意图；

图8为本公开实施例提供的一种类加载装置的结构示意图；

图9为本公开实施例提供的一种类加载设备的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

Android平台下的类加载过程可以通过ART(Android runtime，Android 5及以上版本)虚拟机实现。在应用程序运行过程中，ART虚拟机使用镜像文件(后缀名为.art，Android应用的镜像文件默认为base.art)加快应用程序的启动速度。其中，镜像文件包含应用程序包列出的一些字符串和类的虚拟机内部表示。具体的，在进行类加载时，ART虚拟机中的类加载器会优先从镜像文件中查找类是否存在，如果存在，则不会去预先定义的可执行文件的路径下加载类，由于镜像文件的类查找效率大于可执行文件的类查找效率，因此，从镜像文件中查找类能够节约类查找时间，从而加快应用程序的启动速度。

需要说明的是，为了保证镜像文件能够被正确使用，ART虚拟机限定了类加载器的类名必须为路径类加载器(PathClassLoader)或启动类加载器(BootClassLoader)，也就是说，ART虚拟机中的PathClassLoader和BootClassLoader能够从镜像文件中查找类，其他类加载器无法访问镜像文件。并且，ART虚拟机中的类加载器可以依据预先设置的双亲委托的类加载器模型进行类加载。

为了便于理解ART虚拟机限制且利用双亲委托的类加载器模型进行类加载，图1示出了现有技术提供的一种类加载方法的原理示意图。

如图1所示，ART虚拟机利用路径类加载器(PathClassLoader)和启动类加载器(BootClassLoader)进行类加载，其中，启动类加载器是路径类加载器的父级加载器。具体的，图1所示的类加载过程包括如下步骤：

步骤11、给定待加载类名(ClassName)，ART虚拟机会优先调用路径类加载器；

步骤12、由路径类加载器调用类加载函数(PathClassLoader.loadClass())，该类加载函数进一步调用镜像文件查找函数(PathClassLoader.findLoadedClass())，表示从路径类加载器所对应的镜像文件中查找待加载类名对应的类，如果查找到待加载类名对应的类，则将该类作为目标类(TargetClass)并返回目标类，否则，调用启动类加载器(BootClassLoader)继续进行类加载；

步骤13、由启动类加载器调用类加载函数(BootClassLoader.loadClass())，该类加载函数进一步调用镜像文件查找函数(BootClassLoader.findLoadedClass())，从启动类加载器所对应的镜像文件中查找待加载类名对应的类，如果查找到待加载类名对应的类，则直接返回目标类，否则，由启动类加载器调用路径查找函数(BootClassLoader.findClass())，从启动类加载器所对应的可执行文件的路径下查找待加载类名对应的类；其中，Android虚拟机的可执行文件是Dex文件；

步骤14、如果从启动类加载器所对应的可执行文件的路径下查找到待加载类名对应的类，则直接返回目标类，否则，调用路径类加载器，由路径类加载器调用路径查找函数(PathClassLoader.findClass())，从路径类加载器所对应的可执行文件的路径下查找待加载类名对应的类；

步骤15、如果从路径类加载器所对应的可执行文件的路径下查找到路径类加载器，则直接返回目标类，否则生成异常信息(ClassNotFoundException)，表示没有查找到ClassName对应的Class。

在实际应用中，图1所示的类加载方法通常适用于加载系统类。然而，对于在Android平台下运行的应用程序，无论是基于插件化方案运行还是热修复方案运行，其运行过程中需要动态加载数量较多的自定义类，因此，需要定义新的类加载器来加载自定义类。对于需要加载大量的自定义类的动态化场景，相关技术中将新定义的类加载器与图1所示的类加载器模型结合，以改变图1中的类加载器的顺序，形成能够加载自定义类的类加载器模型。具体的，可以通过表1所示的代码定义新的类加载器：

表1：新定义的类加载器的代码

为了便于理解相关技术中自定义类的加载方法，图2示出了现有技术提供的另一种类加载方法的原理示意图。

如图2所示，ART虚拟机利用路径类加载器、启动类加载器以及新定义的类加载器(CustomClassLoader)进行类加载，其中，启动类加载器是新定义的类加载器的父级加载器。具体的，图2所示的类加载过程包括如下步骤：

步骤21、给定待加载类名，ART虚拟机会优先调用自定义类加载器；

步骤22、由自定义类加载器调用类加载函数(CustomClassLoader.loadClass())，类加载函数继续调用镜像文件查找函数(CustomClassLoader.findLoadedClass())，由于该自定义类加载器不能从镜像文件中查找类，使得该镜像文件查找函数不会从所对应的文件中查找待加载类名对应的类，则调用启动类加载器继续进行类加载；

步骤23、由启动类加载器调用类加载函数(BootClassLoader.loadClass())，该类加载函数进一步调用镜像文件查找函数(BootClassLoader.findLoadedClass())，从启动类加载器所对应的镜像文件中查找待加载类名对应的类，如果查找到待加载类名对应的类，则直接返回目标类，否则，由启动类加载器调用路径查找函数(BootClassLoader.findClass())，从启动类加载器所对应的可执行文件的路径下查找待加载类名对应的类；其中，Android虚拟机的可执行文件是Dex文件；

步骤24、如果从启动类加载器所对应的可执行文件的路径下查找到待加载类名对应的类，则直接返回目标类，否则，调用自定义类加载器，由该自定义类加载器调用路径查找函数(CustomClassLoader.findClass())，从自定义类加载器所对应的可执行文件的路径下查找待加载类名对应的类；

步骤25、如果自定义类加载器所对应的可执行文件的路径下查找到待加载类名对应的类，则直接返回目标类，否则，调用路径类加载器继续进行类加载；需要说明的是，路径类加载器也对应父级加载器，父级加载器可以是启动类加载器(图中未示出)，并且，调用路径类加载器进行类加载的具体过程可以参见上述步骤11-15，在此不做赘述。

通过上述分析可知，上述自定义类加载器由于违反了Android平台下的类加载器的限制，因此不能像启动类加载器和路径类加载器一样从镜像文件中查找自定义类，而自定义类的加载是应用程序运行过程中的高频操作，显然，上述类加载方式不能保证Android平台下类加载的性能。

为了解决上述问题，本公开实施例提供了一种能够提高类加载效率的类加载方法、装置、设备及介质。

下面，首先结合图3至图7对本公开实施例提供的类加载方法进行说明。

图3示出了本公开实施例提供的一种类加载方法的流程示意图。

在本公开一些实施例中，图3所示的类加载方法可以由电子设备执行。该电子设备可以包括但不限于诸如智能手机、可穿戴设备等运行Android系统的移动终端。

如图3所示，该类加载方法可以包括如下步骤。

S310、当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找待加载类名。

在本公开实施例中，电子设备在运行应用程序的过程中，可以获取应用程序的类加载请求，根据类加载请求携带的待加载类名，调用第一路径类加载器，由第一路径类加载器在第一镜像文件中查找待加载类名。

在本公开实施例中，待加载类名可以是任意的需要进行加载的类名。

可选地，待加载类名可以是自定义类名或者系统类名。

在本公开实施例中，类加载请求可以是由应用程序发送的进行类加载的请求信息。

在本公开实施例中，第一路径类加载器可以是系统内置类加载器，具体可以是PathClassLoader。

其中，第一路径类加载器可以关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件。其中，第一可执行文件可以是一种Dex文件，具体可以是自定义类的源文件，第一镜像文件具体可以是自定义类的备份文件。在类加载过程中，镜像文件的类查找效率大于可执行文件的类查找效率。

具体的，若待加载类名是自定义类，第一路径类加载器能够符合Android平台下的类加载器的限制，则可以调用第一路径类加载器中的类查找函数，直接在第一镜像文件中查找待加载类名。进一步的，如果确定在第一镜像文件中查找到待加载类名，则从第一镜像文件中加载待加载类名对应的类，也就是说，若确定第一镜像文件中存在待加载类名，则可以直接从第一镜像文件中加载待加载类名对应的类，从而完成类加载过程。

由此，在本公开实施例中，对于需要加载大量的自定义类的动态化场景，可以调用第一路径类加载器直接从镜像文件中查找自定义类，如果查找到，则直接从镜像文件中加载类，相比于现有方案中在调用父级加载器加载系统类失败之后，才能加载自定义的方案来说，显然简化了自定义类的查找流程，因此，这种类加载方式简单且类加载效率较高。

S320、如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。

在本公开实施例中，若电子设备通过调用第一路径类加载器在第一镜像文件中未查找到待加载类名，则会基于双亲机制，调用其父级加载器，由父级加载器调用第一路径类加载器中的类加载函数，并由类加载函数继续进行类加载。

在本公开实施例中，父级加载器可以是基于双亲机制定义的第一路径类加载器所继承的类加载器。

在本公开实施例中，类加载函数可以是从预先定义的从第一路径类加载器所对应的非镜像文件中查找类的函数。

在一些实施例中，若父级加载器预先未定义可执行文件和镜像文件，则父级加载器直接调用第一路径类加载器的类加载函数，返回到第一路径类加载器基于类加载函数继续进行类加载。

在另一些实施例中，若父级加载器预先定义可执行文件和/或镜像文件，则父级加载器可以先在其镜像文件和/或可执行文件中查找待加载类名，并在未查找到待加载类名的情况下，继续调用第一路径类加载器中的类加载函数，返回到第一路径类加载器基于类加载函数继续进行类加载。

通过上述分析可知，对于接收到的类加载请求，可以先从镜像文件中查找类加载请求所携带的待加载类名，如果从镜像文件中未查找到该类名，还可以利用父级加载器返回至第一路径类加载器继续对待加载类名对应的类进行加载，这样，使得类加载过程更加完善和全面，保证类加载过程的可靠性。

在本公开实施例中，当接收到携带待加载类名的类加载请求后，首先，调用第一路径类加载器在第一镜像文件中查找待加载类名，然后，如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。由于第一路径类加载器为系统内置类加载器，第一路径类加载器关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件，因此，第一路径类加载器可以直接在第一镜像文件中查找自定义类，相比于现有方案中在调用父级加载器加载系统类失败之后，才能加载自定义的方案来说，显然简化了自定义类的查找流程；另外，如果从镜像文件中未查找到该类名，还可以利用父级加载器返回至第一路径类加载器继续进行加载，这样，保证了类加载过程的完善性和可靠性。综上，在需要加载大量的自定义类的动态化场景下，提高了类加载效率，进一步保证了Android平台下类加载的性能。

在本公开另一种实施方式中，对于父级加载器调用第一路径类加载器中的类加载函数过程，可以采用不同的方式，从第一路径类加载器所对应的第一可执行文件中，加载待加载类名对应的类。

图4示出了本公开实施例提供的另一种类加载方法的流程示意图。

如图4所示，该类加载方法可以包括如下步骤。

S410、当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找待加载类名。

其中，S410与S310相似，在此不做赘述。

S420、如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，基于第一可执行文件的路径对待加载类名对应的类进行加载。

在本公开实施例中，电子设备在调用父级加载器之后，父级加载器可以通过调用类加载函数，从第一可执行文件的路径下读取是否存在待加载类名，若存在，则从第一可执行文件的路径下加载待加载类名对应的类。

在一些实施例中，S420具体可以包括如下步骤。

S4201、由父级加载器通过预设类转发函数调用第一路径类加载器中的类加载函数，基于第一可执行文件的路径对待加载类名对应的类进行加载。

其中，预设类转发函数可以是预先定义的使得父级加载器能够调用类加载函数的转发函数。

具体的，父级加载器可以是转发类加载器(DispatchClassLoader)，则预设类转发函数可以包括Dispatch ClassLoader.loadClass()。具体的，可以通过表2所示的代码定义DispatchClassLoader：

表2：定义DispatchClassLoader的代码

为了便于理解S410和S420的具体实现过程，图5示出了本公开实施例提供的一种类加载方法的原理示意图。

具体的，图5所示的类加载过程包括如下步骤：

步骤51、给定待加载类名，电子设备通过ART虚拟机会优先调用第一路径类加载器(PathClassLoader)；

步骤52、由第一路径类加载器调用类加载函数(PathClassLoader.loadClass())，由于第一路径类加载器能够从镜像文件中直接查找类，使得该类加载函数能够进一步调用镜像文件查找函数(PathClassLoader.findLoadedClass())，表示从第一路径类加载器所对应的镜像文件中查找待加载类名对应的类，如果查找到待加载类名对应的类，则返回目标类，否则，调用转发类加载器(DispatchClassLoader)继续进行类加载；

步骤53、由转发类加载器调用类加载函数(DispatchClassLoader.loadClass())，该类加载函数依次调用第一转发函数(DispatchClassLoader.findLoadedClass())和第二转发函数(DispatchClassLoader.findClass())，以及继续调用第一路径类加载器中的路径查找函数(PathClassLoader.findClass())，则实现由父级加载器通过预设类转发函数调用第一路径类加载器中的类加载函数；

步骤54、基于第一路径类加载器中的路径查找函数，从第一可执行文件的路径下查找待加载类名对应的类，如果查找到待加载类名对应的类，则直接返回目标类，否则，继续调用右侧的第二路径类加载器(PathClassLoader)，或者，继续调用第二路径类加载器和启动类加载器(BootClassLoader)继续进行类加载。

由此，在本公开实施例中，若需要加载自定义类且父级加载器是转发类加载器，则可以直接调用第一路径类加载器中的类加载函数，从第一可执行文件的路径下进行类加载，无需先利用父级加载器查找系统类之后再返回从自定义类的文件中加载自定义类。显然，简化了自定义类的加载过程，也保证的类加载过程的完善性。

在另一些实施例中，在S420之前，该方法还可以包括如下步骤。

S411、调用父级加载器从第二镜像文件中查找待加载类名；其中，父级加载器关联有第二可执行文件的路径，第二可执行文件中包括系统类，第二镜像文件为第二可执行文件对应的镜像文件；

S412、如果确定父级加载器从第二镜像文件中未查找到待加载类名，则调用父级加载器基于第二可执行文件的路径查找待加载类名；

相应的，S420具体可以包括如下步骤。

S4202、在确定父级加载器基于第二可执行文件的路径未查找到待加载类名时，由父级加载器调用第一路径类加载器中的类加载函数，基于第一可执行文件的路径对待加载类名对应的类进行加载。

其中，父级加载器可以是BootClassLoader。

其中，第二可执行文件可以是一种Dex文件，具体可以是系统类的源文件，第二镜像文件具体可以是系统类的备份文件。

为了便于理解S410和S420的具体实现过程，图6示出了本公开实施例提供的另一种类加载方法的原理示意图。

具体的，图6所示的类加载过程包括如下步骤：

步骤61、给定待加载类名，电子设备通过ART虚拟机会优先调用第一路径类加载器(PathClassLoader)；

步骤62、由第一路径类加载器调用类加载函数(PathClassLoader.loadClass())，由于第一路径类加载器能够从镜像文件中直接查找类，使得该类加载函数能够进一步调用镜像文件查找函数(PathClassLoader.findLoadedClass())，表示从第一路径类加载器所对应的镜像文件中查找待加载类名对应的类，如果查找到待加载类名对应的类，则返回目标类，否则，调用第一启动类加载器(BootClassLoader)继续进行类加载；

步骤63、由第一启动类加载器调用类加载函数(BootClassLoader.loadClass())，该类加载函数进一步调用镜像文件查找函数(BootClassLoader.findLoadedClass())，从启动类加载器所对应的第二镜像文件中查找待加载类名对应的类，如果查找到待加载类名对应的类，则直接返回目标类，否则，由第一启动类加载器调用路径查找函数(BootClassLoader.findClass())，从第一启动类加载器所对应的第二可执行文件的路径下查找待加载类名对应的类，若查找到，则直接返回目标类，否则，调用第一路径类加载器继续进行类加载；

步骤64、基于第一路径类加载器中的路径查找函数(PathClassLoader.findClass())，从第一可执行文件的路径下查找待加载类名对应的类，如果查找到待加载类名对应的类，则直接返回目标类，否则，继续调用第二路径类加载器(PathClassLoader)，或者，继续调用第二路径类加载器和第二启动类加载器(BootClassLoader)进行类加载。

由此，在本公开实施例中，若需要加载自定义类且父级加载器是启动类加载器，则可以先从启动类加载器中查找系统类，在未查找到系统类的情况下，则调用第一路径类加载器中的类加载函数，从第一可执行文件的路径下加载自定义类，这种类查找方式也能够实现类加载过程。

综上，在本公开实施例中，若需要加载自定义类，可以利用父级加载器直接调用第一路径类加载器，从第一可执行文件的路径下加载自定义类；或者，可以先利用父级加载器查找系统类，在未查找到系统类时，继续调用第一路径类加载器，从第一可执行文件的路径下加载自定义类。上述两种类加载方式均可以实现，因此，提高了类加载方式的多样性和灵活性。

在本公开又一种实施方式中，如果确定类加载函数对待加载类名对应的类加载失败，还可以继续调用第二路径类加载器，或者，调用第二路径类加载器和启动类加载器，继续进行类加载。

图7示出了本公开实施例提供的又一种类加载方法的流程示意图。

如图7所示，该类加载方法可以包括如下步骤。

S710、当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找待加载类名。

S720、如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。

其中，S710～S720与S310～S320相似，在此不做赘述。

S730、如果确定类加载函数对待加载类名对应的类加载失败，则调用第二路径类加载器，或者调用第二路径类加载器和启动类加载器，对待加载类名对应的类进行加载。

需要说明的是，第二路径类加载器关联有第三可执行文件的路径和第三可执行文件的路径所对应的第三镜像文件，第三可执行文件中包括系统类，第三镜像文件为第三可执行文件对应的镜像文件。并且，启动类加载器是第二路径类加载器的父级加载器，启动类加载器关联有第四可执行文件的路径和第四可执行文件的路径所对应的第四镜像文件，第四可执行文件中包括系统类，第四镜像文件为第四可执行文件对应的镜像文件。

需要说明的是，S730具体可以加载系统类。

具体的，若确定类加载函数对待加载类名对应的类加载失败，电子设备可以只调用第二路径类加载器从所对应的第三镜像文件中加载待加载类名对应的类；或者，通过第二路径类加载器调用启动类加载器，从启动类加载器所对应的第四镜像文件中加载待加载类名对应的类；或者，通过第二路径类加载器调用启动类加载器，从启动类加载器所对应的第三可执行文件的路径下加载待加载类名对应的类；或者，通过第二路径类加载器调用启动类加载器，继续返回至第二路径类加载器，从第二路径类加载器所对应的第三可执行文件的路径下加载待加载类名对应的类。

其中，S730具体的类加载过程可以参照图1所描述的类加载过程，在此不做赘述。

由此，在本公开实施例中，如果确定类加载函数对待加载类名对应的类加载失败，还可以继续调用第二路径类加载器，或者，调用第二路径类加载器和启动类加载器，继续进行类加载，以实现对系统类进行加载，因此完善了类加载过程。

本公开实施例还提供了一种用于实现上述的类加载装置，下面结合图8进行说明。在本公开实施例中，该类加载装置可以为电子设备。该电子设备可以包括但不限于诸如智能手机、可穿戴设备等运行Android系统的移动终端。

图8示出了本公开实施例提供的一种类加载装置的结构示意图。

如图8所示，类加载装置800可以包括：待加载类名查找模块810和类加载模块820。

待加载类名查找模块810，用于当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找待加载类名；其中，第一路径类加载器为系统内置类加载器，第一路径类加载器关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件；

类加载模块820，用于如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。

在本公开实施例中，当接收到携带待加载类名的类加载请求后，首先，调用第一路径类加载器在第一镜像文件中查找待加载类名，然后，如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。由于第一路径类加载器为系统内置类加载器，第一路径类加载器关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件，因此，第一路径类加载器可以直接在第一镜像文件中查找自定义类，相比于现有方案中在调用父级加载器加载系统类失败之后，才能加载自定义的方案来说，显然简化了自定义类的查找流程；另外，如果从镜像文件中未查找到该类名，还可以利用父级加载器返回至第一路径类加载器继续进行加载，这样，保证了类加载过程的完善性和可靠性。综上，在需要加载大量的自定义类的动态化场景下，提高了类加载效率，进一步保证了Android平台下类加载的性能。

在本公开一些实施例中，类加载模块还用于，如果确定在第一镜像文件中查找到待加载类名，则从第一镜像文件中加载待加载类名对应的类。

在本公开一些实施例中，类加载模块具体用于，由父级加载器调用第一路径类加载器中的类加载函数，基于第一可执行文件的路径对待加载类名对应的类进行加载。

在本公开一些实施例中，类加载模块具体用于，由父级加载器通过预设类转发函数调用第一路径类加载器中的类加载函数，基于第一可执行文件的路径对待加载类名对应的类进行加载。

在本公开一些实施例中，该装置还包括：

第一查找模块，可以用于调用父级加载器从第二镜像文件中查找待加载类名；其中，父级加载器关联有第二可执行文件的路径，第二可执行文件中包括系统类，第二镜像文件为第二可执行文件对应的镜像文件；

第二查找模块，可以用于如果确定父级加载器从第二镜像文件中未查找到待加载类名，则调用父级加载器基于第二可执行文件的路径查找待加载类名；

相应的，类加载模块具体用于，在确定父级加载器基于第二可执行文件的路径未查找到待加载类名时，由父级加载器调用第一路径类加载器中的类加载函数，基于第一可执行文件的路径对待加载类名对应的类进行加载。

在本公开一些实施例中，类加载模块还用于，如果确定类加载函数对待加载类名对应的类加载失败，则调用第二路径类加载器，或者调用第二路径类加载器和启动类加载器，对待加载类名对应的类进行加载。

需要说明的是，图8所示的类加载装置800可以执行图3至图7所示的方法实施例中的各个步骤，并且实现图3至图7所示的方法实施例中的各个过程和效果，在此不做赘述。

本公开实施例还提供了一种类加载设备，该类加载设备可以包括处理器和存储器，存储器可以用于存储可执行指令。其中，处理器可以用于从存储器中读取可执行指令，并执行可执行指令以实现上述实施例中的类加载方法。

图9示出了本公开实施例提供的一种类加载设备的结构示意图。下面具体参考图9，其示出了适于用来实现本公开实施例中的类加载设备900的结构示意图。

本公开实施例中的类加载设备900可以为电子设备。该电子设备可以包括但不限于诸如智能手机、可穿戴设备等运行Android系统的移动终端。

需要说明的是，图9示出的类加载设备900仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，该类加载设备900可以包括处理装置(例如中央处理器、图形处理器等)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储装置908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有类加载设备900操作所需的各种程序和数据。处理装置901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

通常，以下装置可以连接至I/O接口905：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置906；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置907；包括例如磁带、硬盘等的存储装置908；以及通信装置909。通信装置909可以允许类加载设备900与其他设备进行无线或有线通信以交换数据。虽然图9示出了具有各种装置的类加载设备900，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

本公开实施例还提供了一种计算机可读存储介质，该存储介质存储有计算机程序，当计算机程序被处理器执行时，使得处理器实现上述实施例中的类加载方法。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置909从网络上被下载和安装，或者从存储装置908被安装，或者从ROM 902被安装。在该计算机程序被处理装置901执行时，执行本公开实施例的类加载方法中限定的上述功能。

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

在一些实施方式中，客户端、服务器可以利用诸如HTTP之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。

上述计算机可读介质可以是上述类加载设备中所包含的；也可以是单独存在，而未装配入该类加载设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该类加载设备执行时，使得该类加载设备执行：

当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找待加载类名；其中，第一路径类加载器为系统内置类加载器，第一路径类加载器关联有第一可执行文件的路径，第一可执行文件中包括自定义类，第一镜像文件为第一可执行文件对应的镜像文件；

如果确定在第一镜像文件中未查找到待加载类名，则调用第一路径类加载器的父级加载器，并由父级加载器调用第一路径类加载器中的类加载函数，对待加载类名对应的类进行加载。

在本公开实施例中，可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

本公开实施例还提供了一种计算机程序产品，所述计算机程序产品包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现本公开实施例所述的类加载方法。

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

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种类加载方法，其特征在于，所述方法包括：

当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找所述待加载类名；其中，所述第一路径类加载器为系统内置类加载器，所述第一路径类加载器关联有第一可执行文件的路径，所述第一可执行文件中包括自定义类，所述第一镜像文件为所述第一可执行文件对应的镜像文件；

如果确定在所述第一镜像文件中未查找到所述待加载类名，则调用所述第一路径类加载器的父级加载器，并由所述父级加载器调用所述第一路径类加载器中的类加载函数，对所述待加载类名对应的类进行加载。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

如果确定在所述第一镜像文件中查找到所述待加载类名，则从所述第一镜像文件中加载所述待加载类名对应的类。

3.根据权利要求1所述的方法，其特征在于，所述由所述父级加载器调用所述第一路径类加载器中的类加载函数，对所述待加载类名对应的类进行加载，包括：

由所述父级加载器调用所述第一路径类加载器中的类加载函数，基于所述第一可执行文件的路径对所述待加载类名对应的类进行加载。

4.根据权利要求3所述的方法，其特征在于，所述由所述父级加载器调用所述第一路径类加载器中的类加载函数，基于所述第一可执行文件的路径对所述待加载类名对应的类进行加载，包括：

由所述父级加载器通过预设类转发函数调用所述第一路径类加载器中的类加载函数，基于所述第一可执行文件的路径对所述待加载类名对应的类进行加载。

5.根据权利要求3所述的方法，其特征在于，所述由所述父级加载器调用所述第一路径类加载器中的类加载函数，基于所述第一可执行文件的路径对所述待加载类名对应的类进行加载之前，还包括：

调用所述父级加载器从第二镜像文件中查找所述待加载类名；其中，所述父级加载器关联有第二可执行文件的路径，所述第二可执行文件中包括系统类，所述第二镜像文件为所述第二可执行文件对应的镜像文件；

如果确定所述父级加载器从第二镜像文件中未查找到所述待加载类名，则调用所述父级加载器基于所述第二可执行文件的路径查找所述待加载类名；

相应的，所述由所述父级加载器调用所述第一路径类加载器中的类加载函数，基于所述第一可执行文件的路径对所述待加载类名对应的类进行加载，包括：

在确定所述父级加载器基于所述第二可执行文件的路径未查找到所述待加载类名时，由所述父级加载器调用所述第一路径类加载器中的类加载函数，基于所述第一可执行文件的路径对所述待加载类名对应的类进行加载。

6.根据权利要求1所述的方法，其特征在于，所述由所述父级加载器调用所述路径类加载器中的类加载函数，对所述待加载类名对应的类进行加载之后，还包括：

如果确定所述类加载函数对所述待加载类名对应的类加载失败，则调用第二路径类加载器，或者调用所述第二路径类加载器和启动类加载器，对所述待加载类名对应的类进行加载。

7.一种类加载装置，其特征在于，所述装置包括：

待加载类名查找模块，用于当接收到携带待加载类名的类加载请求后，调用第一路径类加载器在第一镜像文件中查找所述待加载类名；其中，所述第一路径类加载器为系统内置类加载器，所述第一路径类加载器关联有第一可执行文件的路径，所述第一可执行文件中包括自定义类，所述第一镜像文件为所述第一可执行文件对应的镜像文件；

类加载模块，用于如果确定在所述第一镜像文件中未查找到所述待加载类名，则调用所述第一路径类加载器的父级加载器，并由所述父级加载器调用所述第一路径类加载器中的类加载函数，对所述待加载类名对应的类进行加载。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备实现如权利要求1-6任一项所述的方法。

9.一种设备，其特征在于，包括：存储器，处理器，及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现如权利要求1-6任一项所述的方法。

10.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现如权利要求1-6任一项所述的方法。