CN112068903B - 应用程序的加载方法、应用程序的加载装置、介质与设备 - Google Patents

Abstract

本公开提供一种应用程序的加载方法、应用程序的加载装置、计算机可读存储介质与电子设备，涉及计算机技术领域。该应用程序的加载方法包括：利用基础类加载器加载目标应用程序中的宿主；利用第一自定义类加载器加载所述目标应用程序中与软件开发工具包SDK关联的插件，并通过加载所述插件调用SDK接口；利用第二自定义类加载器调用与所述SDK接口连接的中间接口，并通过所述中间接口加载SDK实现类，以实现所述插件；所述第二自定义类加载器为所述基础类加载器和所述第一自定义类加载器的父类加载器。本公开可以通过应用程序的加载过程，实现应用程序热更新。

Description

应用程序的加载方法、应用程序的加载装置、介质与设备

技术领域

本公开涉及计算机技术领域，尤其涉及一种应用程序的加载方法、应用程序的加载装置、计算机可读存储介质与电子设备。

背景技术

随着终端设备中应用技术的快速发展，为了产品及服务的推广，安卓项目开发过程中，往往会在应用程序中集成业务SDK(Software Development Kit，软件开发工具包)。SDK中包括各种开发服务，可以为应用程序开发者提供开发功能，通常随着应用程序一起编译、发布。在实际应用中，业务SDK可能会出现一些问题需要进行修复，但是，修复问题后的业务SDK只能通过重新发布应用程序的新版本来实现，过程复杂、效率较低，且应用程序的更新过程，用户有感知，影响用户对应用程序的正常使用。基于此，现有技术提出采用类加载器动态加载业务SDK插件的方法，实现应用程序的更新。但是这种方式仍然存在一些问题，由于宿主和插件中存在相同的类，在加载时可能会出现无法准确加载类的问题，影响应用程序的正常更新。

因此，如何对应用程序进行加载，以对应用程序进行有效热更新是现有技术亟待解决的问题。

发明内容

本公开提供了一种应用程序的加载方法、应用程序的加载装置、计算机可读存储介质与电子设备，进而至少在一定程度上改善现有技术中不能有效对应用程序进行热更新。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的第一方面，提供一种应用程序的加载方法，包括：利用基础类加载器加载目标应用程序中的宿主；利用第一自定义类加载器加载所述目标应用程序中与软件开发工具包SDK关联的插件，并通过加载所述插件调用SDK接口；利用第二自定义类加载器调用与所述SDK接口连接的中间接口，并通过所述中间接口加载SDK实现类，以实现所述插件；所述第二自定义类加载器为所述基础类加载器和所述第一自定义类加载器的父类加载器。

根据本公开的第二方面，提供一种应用程序的加载装置，包括：宿主加载模块，用于利用基础类加载器加载目标应用程序中的宿主；接口调用模块，用于利用第一自定义类加载器加载所述目标应用程序中与软件开发工具包SDK关联的插件，并通过加载所述插件调用SDK接口；插件实现模块，用于利用第二自定义类加载器调用与所述SDK接口连接的中间接口，并通过所述中间接口加载SDK实现类，以实现所述插件；所述第二自定义类加载器为所述基础类加载器和所述第一自定义类加载器的父类加载器。

根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述应用程序的加载方法。

根据本公开的第四方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述应用程序的加载方法。

本公开的技术方案具有以下有益效果：

根据上述应用程序的加载方法、应用程序的加载装置、计算机可读存储介质与电子设备，利用基础类加载器加载目标应用程序中的宿主；利用第一自定义类加载器加载目标应用程序中与软件开发工具包SDK关联的插件，并通过加载插件调用SDK接口；利用第二自定义类加载器调用与SDK接口连接的中间接口，并通过中间接口加载SDK实现类，以实现插件；第二自定义类加载器为基础类加载器和第一自定义类加载器的父类加载器。一方面，本示例性实施例提出一种新的应用程序的加载过程，SDK接口与SDK实现分离，二者之间通过中间接口连接，在利用第一自定义类加载器加载SDK关联的插件，调用SDK接口时，可以通过第二自定义类加载器调用中间接口，加载SDK实现类以实现插件，在该过程中，插件和宿主解耦，基础类加载器与第一自定义加载器的加载过程分离，避免了出现类加载错误的问题，使得SDK可以正常有效的进行热更新；另一方面，本示例性实施例可以在应用程序正常加载时，对SDK功能进行热更新，无需发布应用程序的新版本，加载过程用户无感知，能够给用户提供良好的使用体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本示例性实施方式的一种系统架构的示意图；

图2示出相关技术中类加载器的逻辑示意图；

图3示出本示例性实施方式的一种应用程序的加载方法的流程图；

图4示出现有技术中SDK在应用程序的应用程序包中的集成示意图；

图5示出本示例性实施方式中SDK在应用程序的应用程序包中的集成示意图；

图6示出本示例性实施方式中一种类加载器的逻辑示意图；

图7示出本示例性实施方式中另一种类加载器的逻辑示意图；

图8示出本示例性实施方式中四大组件进行热更新的流程图；

图9示出本示例性实施方式中四大组件中活动组件启动时序过程的流程图；

图10示出本示例性实施方式中再一种类加载器的逻辑示意图；

图11示出本示例性实施方式中插件调用示意图；

图12示出本示例性实施方式中动态链接库类型选择的流程图；

图13示出本示例性实施方式的一种应用程序的加载装置的结构框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本公开的示例性实施方式提供一种用于实现应用程序的加载方法的电子设备。该电子设备至少包括处理器和存储器，存储器用于存储处理器的可执行指令，处理器配置为经由执行可执行指令来执行应用程序的加载方法。

电子设备可以以各种形式来实施，例如可以包括手机、平板电脑、笔记本电脑、个人数字助理(Personal Digital Assistant，PDA)、导航装置、可穿戴设备、无人机等移动设备，以及台式电脑、智能电视等固定设备。

下面以图1中的移动终端100为例，对电子设备的构造进行示例性说明。本领域技术人员应当理解，除了特别用于移动目的的部件之外，图1中的构造也能够应用于固定类型的设备。在另一些实施方式中，移动终端100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或软件和硬件的组合实现。各部件间的接口连接关系只是示意性示出，并不构成对移动终端100的结构限定。在另一些实施方式中，移动终端100也可以采用与图1不同的接口连接方式，或多种接口连接方式的组合。

如图1所示，移动终端100具体可以包括：处理器110、内部存储器121、外部存储器接口122、USB接口130、充电管理模块140、电源管理模块141、电池142、天线1、天线2、移动通信模块150、无线通信模块160、音频模块170、扬声器171、受话器172、麦克风173、耳机接口174、传感器模块180、显示屏幕190、摄像模组191、指示器192、马达193、按键194以及用户标识模块(Subscriber Identification Module，SIM)卡接口195等。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(Application Processor，AP)、调制解调处理器、图形处理器(Graphics ProcessingUnit，GPU)、图像信号处理器(Image Signal Processor，ISP)、控制器、编码器、解码器、数字信号处理器(Digital Signal Processor，DSP)、基带处理器和/或神经网络处理器(Neural-Network Processing Unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。编码器可以对图像或视频数据进行编码(即压缩)，形成码流数据；解码器可以对图像或视频的码流数据进行解码(即解压缩)，以还原出图像或视频数据。

在一些实施方式中，处理器110可以包括一个或多个接口。接口可以包括集成电路(Inter-Integrated Circuit，I2C)接口、集成电路内置音频(Inter-Integrated CircuitSound，I2S)接口、脉冲编码调制(Pulse Code Modulation，PCM)接口、通用异步收发传输器(Universal Asynchronous Receiver/Transmitter，UART)接口、移动产业处理器接口(Mobile Industry Processor Interface，MIPI)、通用输入输出(General-PurposeInput/Output，GPIO)接口、用户标识模块(Subscriber Identity Module，SIM)接口和/或通用串行总线(Universal Serial Bus，USB)接口等。通过不同的接口和移动终端100的其他部件形成连接。

USB接口130是符合USB标准规范的接口，具体可以是MiniUSB接口，MicroUSB接口，USBTypeC接口等。USB接口130可以用于连接充电器为移动终端100充电，也可以连接耳机，通过耳机播放音频，还可以用于移动终端100连接其他电子设备，例如连接电脑、外围设备等。

充电管理模块140用于从充电器接收充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为设备供电。

电源管理模块141用于连接电池142、充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为移动终端100的各个部分供电，还可以用于监测电池的状态。

移动终端100的无线通信功能可以通过天线1、天线2、移动通信模块150、无线通信模块160、调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。移动终端100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。移动通信模块150可以提供应用在移动终端100上的包括2G/3G/4G/5G等无线通信的解决方案。

无线通信模块160可以提供应用在移动终端100上的包括无线局域网(WirelessLocal Area Networks，WLAN)(如无线保真(Wireless Fidelity，Wi-Fi)网络)、蓝牙(Bluetooth，BT)、全球导航卫星系统(Global Navigation Satellite System，GNSS)、调频(Frequency Modulation，FM)、近距离无线通信技术(Near Field Communication，NFC)、红外技术(Infrared，IR)等无线通信解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施方式中，移动终端100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得移动终端100可以通过无线通信技术与网络以及其他设备通信。无线通信技术可以包括全球移动通讯系统(Global System for Mobile communications，GSM)，通用分组无线服务(General Packet Radio Service，GPRS)，码分多址接入(CodeDivision Multiple Access，CDMA)，宽带码分多址(Wideband Code Division MultipleAccess，WCDMA)，时分码分多址(Time Division-Synchronous Code Division MultipleAccess，TD-SCDMA)，长期演进(Long Term Evolution，LTE)，新空口(New Radio，NR)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。

移动终端100通过GPU、显示屏幕190及应用处理器等实现显示功能。GPU用于执行数学和几何计算，以实现图形渲染，并连接显示屏幕190和应用处理器。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。移动终端100可以包括一个或多个显示屏幕190，用于显示图像，视频等。

移动终端100可以通过ISP、摄像模组191、编码器、解码器、GPU、显示屏幕190及应用处理器等实现拍摄功能。

摄像模组191用于捕获静态图像或视频，通过感光元件采集光信号，转换为电信号。ISP用于处理摄像模组191反馈的数据，将电信号转换成数字图像信号。

外部存储器接口122可以用于连接外部存储卡，例如Micro SD卡，实现扩展移动终端100的存储能力。

内部存储器121可以用于存储计算机可执行程序代码，可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储移动终端100使用过程中所创建的数据(比如图像，视频)等。处理器110通过运行存储在内部存储器121的指令和/或存储在设置于处理器中的存储器的指令，执行移动终端100的各种功能应用以及数据处理。

移动终端100可以通过音频模块170、扬声器171、受话器172、麦克风173、耳机接口174及应用处理器等实现音频功能。例如音乐播放、录音等。音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。扬声器171，用于将音频电信号转换为声音信号。受话器172，用于将音频电信号转换成声音信号。麦克风173，用于将声音信号转换为电信号。耳机接口174用于连接有线耳机。

传感器模块180可以包括触摸传感器1801、压力传感器1802、陀螺仪传感器1803、气压传感器1804等。触摸传感器1801用于感应外部输入的触摸事件，其可以设置于显示屏幕190的下方，使显示屏幕190成为触控屏，也可以设置于其他位置，例如设置为独立于显示屏幕190的触控板，还可以设置于移动终端100的配套外接设备，例如外接触控板、触摸式遥控器等，使用户通过外接设备实现触控交互。压力传感器1802用于感受压力信号，可以将压力信号转换成电信号，用于实现压力触控等功能。陀螺仪传感器1803可以用于确定移动终端100的运动姿态，可用于拍摄防抖、导航、体感游戏等场景。气压传感器1804用于测量气压，可通过计算海拔高度，辅助定位和导航。此外，根据实际需要，还可以在传感器模块180中设置其他功能的传感器，例如深度传感器、加速度传感器、距离传感器等。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

马达193可以产生振动提示，例如来电、闹钟、接收信息等的振动提示，也可以用于触摸振动反馈等。

按键194包括开机键，音量键等。按键194可以是机械按键。也可以是触摸式按键。移动终端100可以接收按键输入，产生与移动终端100的用户设置以及功能控制有关的键信号输入。

移动终端100可以支持一个或多个SIM卡接口195，用于连接SIM卡，使移动终端100通过SIM卡和网络交互，实现通话以及数据通信等功能。

图2示出了相关技术中一种加载应用程序时，对SDK进行热更新的原理示意图，具体过程可以包括：从服务器端获取下发的业务SDK插件，通过PluginClassLoader(插件类加载器)210、PathClassLoader(路径类加载器)220以及BootClassLoader(根类加载器)230等类加载器进行加载过程，其中，PluginClassLoader210可以是一种自定义的DexClassLoader(扩展类加载器)，进一步，通过反射调用相关实现逻辑类。在PluginClassLoader加载SDK插件中的类时，根据“双亲委派”机制，会向上一父类加载器(例如PathClassLoader，或者BaseDexClassLoader等)确定该类是否被加载过，若没有被加载过，则可以进行新的SDK插件的类的加载过程，但是由于在父类加载器PathClassLoader中存在与PluginClassLoader中需要加载的类相同的类，该类会由PathClassLoader进行加载过程，而PathClassLoader中的类是未被更新的类，因此，会导致PluginClassLoader不能正常加载新的SDK的类，进而可能引起程序崩溃，无法正常执行SDK的热更新过程。

基于上述问题，本示例性实施例提出一种新的应用程序加载方法，下面对本公开示例性实施方式的应用程序的加载方法和应用程序的加载装置进行具体说明。

图3示出了本示例性实施方式中一种应用程序的加载方法的流程，包括以下步骤S310～S330：

步骤S310，利用基础类加载器加载目标应用程序中的宿主。

其中，基础类加载器可以是指安卓操作系统中的类加载器PathClassLoader，即默认类加载器。PathClassLoader可以用于加载已经安装到系统中的Apk(Androidapplication package，安卓应用程序包)文件。目标应用程序是指需要进行热更新的应用程序，其可以是终端设备中安装的任意类型的应用程序。宿主可以是指目标应用程序的主程序，也可以是指目标应用程序本身，在宿主中可以继承对应的SDK。在本示例性实施例中，首先，可以利用PathClassLoader加载目标应用程序中的宿主，即加载目标应用程序的Apk。

步骤S320，利用第一自定义类加载器加载目标应用程序中与软件开发工具包SDK关联的插件，并通过加载插件调用SDK接口。

其中，第一自定义类加载器可以是编程人员自定义的类加载器DexClassLoader，例如，第一自定义类加载器可以是PluginClassLoader，用于加载与SDK关联的插件。目标应用程序中与SDK关联的插件可以是指用于对目标应用程序中的SDK进行热修复的插件文件。在本示例性实施例中，与SDK关联的插件可以由目标应用程序的补丁文件生成，也可以通过用于加载补丁文件以更新目标应用程序的文件加载方法生成，还可以通过编程人员根据目标应用程序的问题需求进行编译生成等等。与SDK关联的插件可以通过与网络连接的服务器获取，具体的，应用服务器可以将与SDK关联的热修复插件通过配置的下发渠道下发至已经安装目标应用程序的客户端，由目标应用程序的客户端接收该插件。在实际应用中，客户端可以自动检测应用程序的版本是否需要进行更新，若是，则可以向服务器发起插件获取请求，接收目标应用程序的服务器响应于该获取请求而下发的热修复插件；客户端也可以周期性向服务器发起插件获取请求，以获取响应于该获取请求而下发的热修复插件等等。

在一示例性实施例中，在上述步骤S310和步骤S320之前，应用程序的加载方法还可以包括：

更新SDK实现类，以在加载SDK实现类时，加载更新后的SDK实现类，实现目标应用程序的热更新。

在本示例性实施例中，应用程序的加载过程可以对SDK实现类进行热修复，在利用基础类加载器加载目标应用程序中的宿主，和利用第一自定义类加载器加载目标应用程序中与SDK关联的插件之前，对SDK进行更新，即使得后续可以加载新的SDK实现类，从而实现目标应用程序的热更新。

在步骤S320中，可以通过第一自定义类加载器加载目标应用程序中与SDK关联的插件时，并通过加载插件调用SDK接口，具体的，调用SDK接口可以通过执行步骤S330进行。

步骤S330，利用第二自定义类加载器调用与SDK接口连接的中间接口，并通过中间接口加载SDK实现类，以实现插件；第二自定义类加载器为基础类加载器和第一自定义类加载器的父类加载器。

在本示例性实施例中，SDK在应用程序Apk的集成方式与现有技术的集成方式不同，图4示出了现有技术中SDK在应用程序的Apk中集成的示意图，SDK420在应用程序Apk中集成时，SDK接口与SDK实现共同集成在APK 410中，在应用程序的加载过程中，进行SDK插件的加载时，通常采用如图2所示的类加载器的逻辑进行加载，因此，会存在类加载错误的问题，导致不能正常进行应用程序的热更新。而本示例性实施例可以将SDK接口和SDK实现进行分离，如图5所示，在应用程序的Apk 510中仅设置SDK API 520(SDK ApplicationProgramming Interface，SDK应用程序接口)，即SDK接口，并通过Inter API(Inter应用程序接口)530，即步骤S330中的中间接口，与SDK lmpl(SDK实现)540互相连接，以通过InterAPI进行SDK接口和SDK实现之间的互相访问。

第二自定义类加载器可以是指编程人员自定义的类加载器DexClassLoader，例如，第二自定义类加载器可以是InterAPIClassLoader，用于调用Inter API，并通过InterAPI加载SDK实现类，以实现SDK插件。具体的，目标应用程序中SDK的加载逻辑如图6所示，PathClassLoader 610用于加载目标应用程序中的宿主，PluginClassLoader 620用于加载SDK插件，InterAPIClassLoader 630为PathClassLoader 610和PluginClassLoader 620的父类加载器，在进行SDK插件加载时，根据“双亲委派”机制，PathClassLoader 610和PluginClassLoader 620会向上一级父类加载器查找所要加载的类是否已经被加载过，如果父类加载器已经加载过，则他们就无需再加载了，直到达到BootClassLoader 640。在本示例性实施例中，由于设置了中间接口Inter API，将SDK接口和SDK接口进行了分离，在类的加载过程中，PathClassLoader 610和PluginClassLoader 620仅通过InterAPIClassLoader 630关联，PathClassLoader 610可以正常加载目标应用程序中的宿主，PluginClassLoader 620可以加载目标应用程序中与SDK关联的插件，并通过加载插件调用SDK接口。其中，在调用SDK接口时，可以通过InterAPIClassLoader 630调用与SDK接口连接的中间接口Inter API，并通过Inter API加载SDK实现类，以实现插件。在该过程中，由于PathClassLoader 610和PluginClassLoader 620之间不存在直接关联，代码隔离，宿主和插件解耦，因此，可以避免出现现有技术中不能正确加载SDK插件的类的情况，也就能够正常有效的进行目标应用程序的加载，实现其热更新的过程。

综上，本示例性实施方式中，利用基础类加载器加载目标应用程序中的宿主；利用第一自定义类加载器加载目标应用程序中与软件开发工具包SDK关联的插件，并通过加载插件调用SDK接口；利用第二自定义类加载器调用与SDK接口连接的中间接口，并通过中间接口加载SDK实现类，以实现插件；第二自定义类加载器为基础类加载器和第一自定义类加载器的父类加载器。一方面，本示例性实施例提出一种新的应用程序的加载过程，SDK接口与SDK实现分离，二者之间通过中间接口连接，在利用第一自定义类加载器加载SDK关联的插件，调用SDK接口时，可以通过第二自定义类加载器调用中间接口，加载SDK实现类以实现插件，在该过程中，插件和宿主解耦，基础类加载器与第一自定义加载器的加载过程分离，避免了出现类加载错误的问题，使得SDK可以正常有效的进行热更新；另一方面，本示例性实施例可以在应用程序正常加载时，对SDK功能进行热更新，无需发布应用程序的新版本，加载过程用户无感知，能够给用户提供良好的使用体验。

在一示例性实施例中，应用程序的加载方法还可以包括以下步骤：

利用第三自定义类加载器加载插件中四大组件的代理组件，并通过代理组件实现四大组件；第三自定义类加载器为第二自定义类加载器的父类加载器。

进一步的，在一示例性实施例中，应用程序的加载方法还可以包括：

更新代理组件，以在加载代理组件时，加载更新后的代理组件，并实现四大组件的更新。

在安卓项目开发中通常会包括四大组件，分别是Activity(活动)，用于表现功能；Service(服务)，后台运行服务；Broadcast Receive(广播接受者)，用于接收广播；ContentProvider(内容提供者)，支持多个应用中存储和读取数据，相当于数据库。现有技术在进行SDK热更新时，是通过四大组件的代理组件加载SDK的插件的四大组件的方式，对四大组件进行更新的，而四大组件的代理组件却不能进行更新。基于此，本示例性实施例通过第三自定义类加载器进行四大组件的代理组件的加载，以实现四大组件代理组件的更新。其中，第三自定义类加载器是指编程人员自定义的类加载器DexClassLoader，例如，第三自定义类加载器可以是RuntimeClassLoader。四大组件的代理组件进行热更新时，类加载器的加载逻辑如图7所示，PathClassLoader 710用于加载目标应用程序中的宿主，PluginClassLoader 720用于加载SDK插件，调用SDK接口，并通过InterAPIClassLoader730调用与SDK接口相连接的中间接口InterAPI，以基于中间接口InterAPI加载SDK实现。RuntimeClassLoader 740为InterAPIClassLoader 730的父类加载器，用于加载插件中四大组件的代理组件，并通过代理组件实现四大组件，加载过程直到达到BootClassLoader750。其中，宿主可以通过RuntimeClassLoader查找四大组件的代理组件，以对四大组件的代理组件进行热更新。

在本示例性实施例中，如图8所示，四大组件进行热更新的过程具体包括以下步骤：

步骤S810，预先在目标应用程序Apk中的SDK接口中预埋四大组件的代理组件；

步骤S820，通过RuntimeClassLoader加载四大组件的代理组件，并将RuntimeClassLoader设置为PathClassLoader父层级上的类加载器；

步骤S830，将SDK插件启动四大组件方法修改为启动四大组件的代理组件，并将SDK插件的组件信息保存在Intent(意图)中；

步骤S840，当宿主加载四大组件的代理组件时，从RuntimeClassLoader中进行查找；

步骤S850，在成功创建代理组件之后，通过反射创建SDK插件组件的实例，并在代理组件的相关方法中修改插件组件的逻辑。

其中，Intent是指消息传递对象，使用它可以向其他安卓组件请求操作，Intent的基本用途主要可以包括：启动Activity、启动Service、传递广播等。

在一示例性实施例中，四大组件中的Activity、Service可以通过代理组件启动，其中以Activity为例，进行具体说明，如图9所示，Activity的启动时序过程可以包括以下步骤：

步骤S910，通过SDK插件启动ProxyActivity(活动的代理组件)，并将PluginActivity(插件活动)信息存入Intent中；

步骤S920，代理组件对ProxyActivity进行校验，确定是否进行注册；

步骤S930，若校验通过，启动ProxyActivity；

步骤S940，在目标应用程序中创建ProxyActivity；

并执行步骤S950，通过SDK插件反射创建PluginActivity实例；

最后，执行步骤S960，在ProxyActivity的方法中执行PluginActivity的对应逻辑。

另外，四大组件中的，Broadcast Receive，不支持静态广播，动态广播无需处理；

四大组件中的，ContentProvider、FileProvider，可以提前在SDK接口中注册组件信息，有两种方案可以让宿主找到组件

其一：将ContentProvider、FileProvider(文件提供者)相关代码通过RuntimeClassLoader加载，宿主查找时ContentProvider、FileProvider相关类时从RuntimeClassLoader中查找；

其二：重写RuntimeClassLoader的类加载器方法，查找ContentProvider、FileProvider相关类时从PluginClassLoader中查找。

在一示例性实施例中，上述目标应用程序可以包括多个插件，分别与不同的SDK相关联，即可以具有多个SDK插件，则上述应用程序的加载方法还可以包括：

分别设置每个插件的第一自定义类加载器和第二自定义类加载器。

其中，第一自定义类加载器可以是PluginClassLoader，第二类加载器可以是InterAPIClassLoader。在本示例性实施例中，为了使每个SDK都能进行四大组件的更新，还可以为每个插件设置第三类自定义类加载器，即RuntimeClassLoader。图10示出了当目标应用程序包括多个SDK插件加载应用程序时，类加载器的逻辑示意图，以两个SDK插件为例，每个SDK插件都有自己的InterAPIClassLoader、RuntimeClassLoader、PluginClassLoader。其中，RuntimeClassLoader 1 1070、InterAPIClassLoader 1 1060、PluginClassLoader 1 1050，对应加载第一SKD插件，RuntimeClassLoader 2 1040、InterAPIClassLoader 2 1030、PluginClassLoader 2 1020，对应加载第二SKD插件，其类加载逻辑与图7类似，由PathClassLoader 1010加载目标应用程序中的宿主，由每个SDK插件对应的InterAPIClassLoader、RuntimeClassLoader、PluginClassLoader分别加载SDK实现类、以及四大组件等，加载过程直到达到BootClassLoader1080，基于此，本示例性实施例可以实现加载过程中，插件与插件、插件与宿主之间代码隔离，互不影响，以使每个SDK插件进行正常的热更新过程。

在一示例性实施例中，插件的调用关系图，如图11所示，首先，由SDK接口1110调用中间接口Inter API 1120的相关接口；进一步，SDK接口1110通过反射创建Plugin 1130(即SDK实现)中的实例，并让Inter API 1120持有，以使SDK接口1110间接的使用Plugin 1130；在Plugin 1130中启动四大组件的代理组件，并通过PathClassLoader从RuntimeClassLoader 1140中加载四大组件代理组件的相关类；最后，当四大组件的代理组件创建成功后，即可以通过反射创建插件中的Plugin组件。

在一示例性实施例中，上述每个插件可以具有其各自的动态链接库，且不同的动态链接库可以位于不同的路径。

其中，动态链接库即So库，是指程序函数库，其中包括已经编译完成的，可以用于供其他程序进行使用的代码和数据。

在一示例性实施例中，应用程序的加载方法还可以包括以下步骤：

利用第一自定义类加载器加载插件的动态链接库。

进一步的，应用程序的加载方法还可以包括：

更新动态链接库，以在加载动态链接库时，加载更新后的动态链接库。

现有技术中在对SDK插件进行热更新时，往往不能对So库进行更新，而本示例性实施例可以通过指定PluginClassLoader的So库路径，使每个SDK插件加载自己的So库，以完成热更新，互不影响。

在进行So库更新时，考虑到安卓系统从5.0开始支持64bit CPU(64位的中央处理器)，于是系统可以包括zygote和zygote64两个进程，以分别创建32位和64位的应用进程，而zygote64位的进程只能加载64位的So库(arm64-v8a)，zygote进程只能加载32位的So库(armeabi-v7a、armeabi)，因此，需要对So库类型进行判断和选择。如图12所示，本示例性实施例可以采用以下步骤对So类型进行确定：

步骤S1210，判断安卓系统的版本是否小于6.0；

如果不小于6.0，则执行步骤S1220，确定当前为64位的应用进程；

如果小于6.0，则执行步骤S1230，判断安卓系统的版本是否小于5.0；

如果不小于5.0，则执行步骤S1240，确定应用程序加载的libarth.So库路径中不包含Lib64；

步骤S1250，通过Build.SUPPORTED_ABIS返回目标值；

并执行步骤S1260，根据目标值确定应用进程；

如果SDK的版本是否小于5.0，则执行步骤S1270，确定当前为32位的应用进程。

其中，在步骤S1260中，目标值是指可以反映应用进程类型的标识，即可以根据该标识确定当前为32位的应用进程还是64位的应用进程，例如通过表示“1”表示确定为32位的应用进程，通过“0”表示64位的应用进程等。

在一示例性实施例中，应用程序的加载方法还可以包括以下步骤：

利用预先创建的插件的资源管理器，加载插件的资源。

在一示例性实施例中，应用程序的加载方法还可以包括：

更新资源，以在加载资源时，加载更新后的资源。

通常在SDK中，除了包括代码、四大组件和So库等内容，还会包括资源，为了实现SDK插件资源的热更新，本示例性实施例可以为每个插件单独创建AssetMananger(资源管理器)；然后为插件创建Context(内容)(或PluginContext(插件内容))，并重写其加载资源方法，使用插件的AssetMananger加载资源。在对资源进行热更新时，可以先对资源进行更新，然后通过对目标应用程序执行加载过程，实现SDK中资源的热更新。

在本示例性实施例中，不同资源的加载，可以采用不同的加载方式，例如，插件加载插件中资源时，可以使用PluginContext加载；插件加载宿主中资源时，可以使用ApplicationContext加载；宿主加载插件资源时，可以使用PluginContext加载等。

通过上述说明，本示例性实施例的应用程序加载过程，可以实现SDK热更新的过程，一方面，可以在SDK出现线上Bug(问题)时，无需重新集成发布新版本，就能进行热更新过程；另一方面，还可以对四大组件以及代理组件、So库以及资源等进行及时的热更新；再一方面，更新过程可以支持多个SDK同时插件化，互相隔离不影响，具有更好的兼容性。

本公开的示例性实施方式还提供一种应用程序的加载装置。如图13所示，该应用程序的加载装置1300可以包括：宿主加载模块1310，用于利用基础类加载器加载目标应用程序中的宿主；接口调用模块1320，用于利用第一自定义类加载器加载目标应用程序中与软件开发工具包SDK关联的插件，并通过加载插件调用SDK接口；插件实现模块1330，用于利用第二自定义类加载器调用与SDK接口连接的中间接口，并通过中间接口加载SDK实现类，以实现插件；第二自定义类加载器为基础类加载器和第一自定义类加载器的父类加载器。

在一示例性实施例中，应用程序的加载装置还包括：SDK实现更新模块，用于在加载目标应用程序的宿主和插件之前，更新SDK实现类，以在加载SDK实现类时，加载更新后的SDK实现类，实现目标应用程序的热更新。

在一示例性实施例中，应用程序的加载装置还包括：代理组件加载模块，用于利用第三自定义类加载器加载插件中四大组件的代理组件，并通过代理组件实现四大组件；第三自定义类加载器为第二自定义类加载器的父类加载器。

在一示例性实施例中，应用程序的加载装置还包括：代理组件更新模块，用于更新代理组件，以在加载代理组件时，加载更新后的代理组件，并实现四大组件的更新。

在一示例性实施例中，应用程序的加载装置还包括：动态链接库加载模块，用于利用第一自定义类加载器加载插件的动态链接库。

在一示例性实施例中，应用程序的加载装置还包括：动态链接库更新模块，用于更新动态链接库，以在加载动态链接库时，加载更新后的动态链接库。

在一示例性实施例中，应用程序的加载装置还包括：资源加载模块，用于利用预先创建的插件的资源管理器，加载插件的资源。

在一示例性实施例中，应用程序的加载装置还包括：资源更新模块，用于更新资源，以在加载资源时，加载更新后的资源。

在一示例性实施例中，目标应用程序包括多个插件，分别与不同的SDK相关联；应用程序的加载装置还包括：类设置模块，用于分别设置每个插件的第一自定义类加载器和第二自定义类加载器。

在一示例性实施例中，每个插件具有各自的动态链接库，且不同的动态链接库位于不同的路径。

上述装置中各模块的具体细节在方法部分实施方式中已经详细说明，未披露的细节内容可以参见方法部分的实施方式内容，因而不再赘述。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

本公开的示例性实施方式还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤，例如可以执行图3、图8、图9或图12中任意一个或多个步骤。

本公开的示例性实施方式还提供了一种用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

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

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施方式。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施方式仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限。

Claims (12)

1.一种应用程序的加载方法，其特征在于，所述方法包括：

利用基础类加载器加载目标应用程序中的宿主；所述基础类加载器包括默认类加载器；

利用第一自定义类加载器加载所述目标应用程序中与软件开发工具包SDK关联的插件，并通过加载所述插件调用SDK接口；所述基础类加载器与所述第一自定义类加载器不存在直接关联；

利用第二自定义类加载器调用与所述SDK接口连接的中间接口，并通过所述中间接口加载SDK实现类，以实现所述插件；所述第二自定义类加载器为所述基础类加载器和所述第一自定义类加载器的父类加载器；

所述与SDK关联的插件为与SDK关联的热修复插件；所述与SDK关联的热修复插件通过配置的下发渠道下发至已经安装所述目标应用程序的客户端；所述方法还包括：

当所述目标应用程序的客户端检测到应用程序的版本需要进行更新时，向服务器发起插件获取请求，并接收所述目标应用程序的服务器响应于所述插件获取请求下发的所述与SDK关联的热修复插件；

所述目标应用程序包括多个所述插件，分别与不同的SDK相关联；所述方法还包括：

分别设置每个所述插件的第一自定义类加载器和第二自定义类加载器。

2.根据权利要求1所述的方法，其特征在于，在利用基础类加载器加载目标应用程序中的宿主以及利用第一自定义类加载器加载所述目标应用程序中与软件开发工具包SDK关联的插件之前，所述方法还包括：

更新所述SDK实现类，以在加载所述SDK实现类时，加载更新后的SDK实现类，实现所述目标应用程序的热更新。

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

利用第三自定义类加载器加载所述插件中四大组件的代理组件，并通过所述代理组件实现所述四大组件；所述第三自定义类加载器为所述第二自定义类加载器的父类加载器。

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

更新所述代理组件，以在加载所述代理组件时，加载更新后的代理组件，并实现所述四大组件的更新。

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

利用所述第一自定义类加载器加载所述插件的动态链接库。

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

更新所述动态链接库，以在加载所述动态链接库时，加载更新后的动态链接库。

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

利用预先创建的所述插件的资源管理器，加载所述插件的资源。

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

更新所述资源，以在加载所述资源时，加载更新后的资源。

9.根据权利要求1所述的方法，其特征在于，每个所述插件具有各自的动态链接库，且不同的所述动态链接库位于不同的路径。

10.一种应用程序的加载装置，其特征在于，所述装置包括：

宿主加载模块，用于利用基础类加载器加载目标应用程序中的宿主；所述基础类加载器包括默认类加载器；

接口调用模块，用于利用第一自定义类加载器加载所述目标应用程序中与软件开发工具包SDK关联的插件，并通过加载所述插件调用SDK接口；所述基础类加载器与所述第一自定义类加载器不存在直接关联；

插件实现模块，用于利用第二自定义类加载器调用与所述SDK接口连接的中间接口，并通过所述中间接口加载SDK实现类，以实现所述插件；所述第二自定义类加载器为所述基础类加载器和所述第一自定义类加载器的父类加载器；

所述与SDK关联的插件为与SDK关联的热修复插件；所述与SDK关联的热修复插件通过配置的下发渠道下发至已经安装所述目标应用程序的客户端；所述装置还被配置为：

当所述目标应用程序的客户端检测到应用程序的版本需要进行更新时，向服务器发起插件获取请求，并接收所述目标应用程序的服务器响应于所述插件获取请求下发的所述与SDK关联的热修复插件；

所述目标应用程序包括多个所述插件，分别与不同的SDK相关联；所述装置还被配置为：

分别设置每个所述插件的第一自定义类加载器和第二自定义类加载器。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至9任一项所述的方法。

12.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至9任一项所述的方法。