CN112083968A - 一种宿主中插件加载方法及装置 - Google Patents

Abstract

本申请涉及计算机技术领域，尤其涉及一种宿主中插件加载方法及装置，在运行应用程序时，启动所述应用程序的宿主可执行文件，若当前执行的功能所对应的资源位于插件可执行文件中，则在触发所述应用程序所对应的操作系统的组件启动程序时，基于所述第二类加载器和插件的组件声明代码，确定查找到所述当前执行的功能对应的组件声明，并创建组件对象；修改所述插件可执行文件中所述组件对象对应的组件，以使所述插件可执行文件中对应组件的资源赋值给所述组件对象；运行所述组件对象，以执行所述插件可执行文件中对应组件的资源所实现的功能，以实现宿主和插件的类相互访问，并且无需侵入修改插件源码，进而实现在宿主中动态加载插件的目的。

Description

一种宿主中插件加载方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种宿主中插件加载方法及装置。

背景技术

目前，应用程序可以划分为宿主和插件，用户只需要安装宿主安卓安装包(AndroidPackage，Apk)即可，插件的运行依赖宿主程序的运行，在运行时可以动态加载插件Apk，从而实现插件对应的功能，但是相关技术中，宿主和插件之间的类加载，或者相互隔离，或者只能单向依赖，并且对于插件的组件加载，通常采用预埋壳子组件，并将壳子组件和插件的组件联系起来的方式，这就需要修改启动组件的代码，侵入插件中组件源码，修改相关逻辑，不利于代码复用和移植。

发明内容

本申请实施例提供一种宿主中插件加载方法及装置，以实现宿主和插件的类相互访问，并且无需侵入修改插件源码，进而实现在宿主中动态加载插件的目的。

本申请实施例提供的具体技术方案如下：

本申请一个实施例提供了一种宿主中插件加载方法，包括：

在运行应用程序时，启动所述应用程序的宿主可执行文件，其中，所述应用程序包括宿主可执行文件和插件可执行文件，所述宿主可执行文件中至少打包有宿主类加载器、插件类加载器以及插件的组件声明代码，所述宿主类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器；

若当前执行的功能所对应的资源位于插件可执行文件中，则在触发所述应用程序所对应的操作系统的组件启动程序时，基于所述第二类加载器和插件的组件声明代码，确定查找到所述当前执行的功能对应的组件声明，并创建组件对象；

修改所述插件可执行文件中所述组件对象对应的组件，以使所述插件可执行文件中对应组件的资源赋值给所述组件对象；

运行所述组件对象，以执行所述插件可执行文件中对应组件的资源所实现的功能。

本申请另一个实施例提供了一种宿主中插件加载装置，包括：

启动模块，用于在运行应用程序时，启动所述应用程序的宿主可执行文件，其中，所述应用程序包括宿主可执行文件和插件可执行文件，所述宿主可执行文件中至少打包有宿主类加载器、插件类加载器以及插件的组件声明代码，所述宿主类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器；

创建模块，用于若当前执行的功能所对应的资源位于插件可执行文件中，则在触发所述应用程序所对应的操作系统的组件启动程序时，基于所述第二类加载器和插件的组件声明代码，确定查找到所述当前执行的功能对应的组件声明，并创建组件对象；

修改模块，用于修改所述插件可执行文件中所述组件对象对应的组件，以使所述插件可执行文件中对应组件的资源赋值给所述组件对象；

运行模块，用于运行所述组件对象，以执行所述插件可执行文件中对应组件的资源所实现的功能。

本申请另一个实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一种宿主中插件加载方法的步骤。

本申请另一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一种宿主中插件加载方法的步骤。

本申请实施例中，构建类加载器以实现宿主和插件之间可以相互加载类，宿主可执行文件中至少打包有宿主类加载器、插件类加载器以及插件的组件声明代码，插件的程序源码无需打包到宿主可执行文件中，以在宿主集成插件功能目的下，减少宿主可执行文件的大小，并且在宿主中内置插件的组件的声明代码，进而在运行应用程序时，启动宿主可执行文件，若当前执行的功能所对应的资源位于插件可执行文件中，则在触发应用程序所对应的操作系统的组件启动程序时，基于所述第二类加载器和插件的组件声明代码，确定查找到所述当前执行的功能对应的组件声明，并创建组件对象，并动态修改插件可执行文件中该组件对象对应的组件，以使插件可执行文件中对应组件的资源赋值给组件对象，进而运行组件对象，即可以执行插件可执行文件中对应组件的资源所实现的功能，这样，由于构建的宿主类加载器可以加载插件的类，并且在宿主可执行文件中预埋了插件的组件声明代码，因此在运行时，触发插件的组件时，可以支持并正常创建组件对象，并在插件的组件对象创建时，动态修改插件的组件，从而运行该组件可以执行对应的功能，实现无侵入插件并使得插件的组件正常运行。

附图说明

图1为相关技术中插件化技术原理示意图；

图2为相关技术中虚拟化技术原理示意图；

图3为本申请实施例中提供的一种应用架构示意图；

图4为本申请实施例中宿主中插件加载方法流程图；

图5为本申请实施例中插件类加载器的结构示意图；

图6为本申请实施例中宿主类加载器的结构示意图；

图7为本申请实施例中宿主中插件加载方法的编译方案逻辑原理图；

图8为本申请实施例中宿主中插件加载方法的运行期方案逻辑原理图；

图9为本申请实施例中一种宿主中插件加载装置结构示意图；

图10所示为本申请实施例中电子设备的结构示意图。

具体实施方式

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

为便于对本申请实施例的理解，下面先对几个概念进行简单介绍：

安卓安装包(AndroidPackage，Apk)：把Android SDK编译的工程打包成一个安装程序文件，格式为Apk，Apk文件其实是zip格式，但后缀名被修改为Apk，通过将Apk文件直接传到Android模拟器或Android终端中执行即可安装。通过UnZip解压后，可以看到Dex文件，Dex是DalvikVM executes的简称，即Android Dalvik执行程序，并非Java ME的字节码而是Dalvik字节码。

软件开发工具包(Software Development Kit，SDK)：通常都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。

宿主：也称为应用程序(Application，APP)宿主，为便于开发，也提高应用程序发布效率，通常应用程序可以分为宿主和插件，可以基于宿主动态加载插件，宿主表示APP构建出的Apk文件运行起来提供的基础运行环境，单只Apk文件本身所包含的代码，与运行期间动态加载起来的其他可执行代码区别开。

插件：也称为动态插件、动态文件，指包含一部分Android平台可执行代码的独立文件，可以是Apk文件、Dex文件、Zip文件等，它的运行需要宿主提供一套运行机制，该机制可能要求插件文件内的代码实现有约束。

组件：Android应用程序由一些零散的有联系的组件组成，通过一个工程绑定在一起，是Android应用程序的基石，例如本申请实施例中应用程序主要以Android应用程序为例，则组件即表示Android平台的四大组件：活动(Activity)、服务(Service)、内容提供者(Content Provider)和广播接收器(Broadcast Receiver)，组件都需要注册才能使用。

其中，Activity是Android程序与用户交互的窗口，是Android构造块中最基本的一种，需要保持各界面的状态，做很多持久化的事情，妥善管理生命周期以及一些跳转逻辑；Service后台服务于Activity，封装一个完整的功能逻辑实现，接受上层指令，完成相关的事物；Content Provider是Android提供的第三方应用数据的访问方式，可以派生Content Provider类，对外提供数据，可以像数据库一样进行选择排序，屏蔽内部数据的存储细节，向外提供了统一的接口模型，大大简化上层应用，对数据整合提供了更方便的途径；Broadcast Receiver接受一种或者多种意图(Intent)作为触发事件，接受相关消息，做一些简单处理，转换成一条通知(Notification)，统一了Android的事件广播模型。

类：是一组相互关联的属性和行为的集合，例如，Java是面向对象语言，所有的Java代码都是由一个个类组成。

类加载器：Java程序中的类，从源码的编写(.java文本文件)到最终运行，中间会经过编译(输出字节码)、加载、验证、准备、解析、初始化，最终使用这些过程。而负责将编译的字节码产物，进行加载、验证、准备、解析、初始化，最终把类提供给程序使用的工具被称为类加载器(例如，ClassLoader及其子类)，例如本申请实施例中分别构建了新的宿主类加载器和插件类加载器，实现宿主和插件之间类可以相互访问。

双亲委派模型：指Java语言中，类加载器加载类的行为，即：每个类加载器都有一个父(parent)成员变量(也是一个类加载器对象)。每当需要加载类时，类加载器都会优先尝试从parent中加载类，仅当parent加载不到类时，才会尝试从自己关联的字节码文件中加载类。该行为是Java语言默认的类加载行为，实际应用中，某类加载器的parent可能会被程序重新赋值，从而可以修改这种默认的类加载行为。

compileOnly依赖：Android构建工具Gradle提供的一种代码依赖形式，指定compileOnly依赖时，被依赖的模块仅在编译期间可见，其代码不会输出到最终的编译产物内，即不会参与最终Apk打包。

Implement依赖：表示直接依赖关系，被依赖的模块可以跟随依赖者一起打包输出。

实际中，Android平台插件动态下发，目的倾向于在不影响功能的前提下，其对宿主包大小增量的控制，目前基于该目的采用的技术方案有：插件化和虚拟化两大类。其中，例如参阅图1所示，为相关技术中插件化技术原理示意图，插件化技术是将完整的App工程划分成宿主和插件两类，通过自定义类加载器，完成对插件的加载，并通过修改插件内Android组件的代码，使其与原始Android组件看起来一样，从而实现插件内Android组件的动态运行；例如，参阅图2所示，为相关技术中虚拟化技术原理示意图，虚拟化技术则是以模拟Android系统的思路，完成对独立Apk文件的完整加载运行，该类技术需要模拟整个Android系统，给目标Apk提供完整的系统运行环境，因此这类技术的实现颇为复杂、繁重，并且为了让目标Apk中的Android组件可以完整运行起来，虚拟化存在大量的系统应用程序接口(Application Program Interface，API)钩子(hook)操作。

可知插件动态化下发和加载方案，主要面临的问题是：类加载问题和插件内Android组件运行问题。

但是相关技术中的插件化技术或虚拟化技术，所采用的类加载器或者相互隔离，或者只能单向依赖，无法支持插件和宿主可以互相查找类的需求，而在实际场景中，宿主需要使用插件的类，插件需要使用宿主的类是常见需求，如果有一方不支持加载另一方的类，会导致宿主无法依赖插件或者插件不可依赖宿主的约束条件，最终导致插件SDK模块无法动态化。并且，对于插件内组件的加载和运行问题，通常采用预埋壳子组件，并将壳子组件和插件的组件联系起来的方式，使得壳子组件的运行效果和插件的组件一致，但是这种方式，由于插件的组件并非真正的安卓组件，而以壳子包裹欺骗安卓系统，这样不仅需要修改启动组件的代码，同时为了实现组件能以此方式运行起来，必须进行大量的系统hook(虚拟化类)或者侵入插件内组件的源码，修改关键逻辑，使其可以被牵线加载，不利于代码复用和移植，也降低了应用程序开发效率。

因此，针对上述问题，本申请实施例中提供了一种宿主中插件加载方法，优化类加载器的结构，即修改宿主类加载器和插件类加载器，以实现宿主和插件之间可以相互加载类，并且在宿主可执行文件中打包有插件的组件声明代码，即将插件的组件预埋到宿主中，进而在运行应用程序时，启动宿主可执行文件，若当前执行的功能所对应的资源位于插件可执行文件中，触发了插件的组件，则在触发操作系统的组件启动程序时，基于宿主类加载器中的第二类加载器和插件的组件声明代码，确定查找到当前执行的功能对应的组件声明，并创建组件对象，动态修改插件可执行文件中该组件对象对应的组件，以使插件可执行文件中对应组件的资源赋值给组件对象，进而运行组件对象，即可以执行插件可执行文件中对应组件的资源所实现的功能，这样，通过优化类加载器的结构，最终实现插件可加载宿主的类，同时宿主可以加载插件的类，并且将插件内组件声明预埋到宿主中，并且以真实的组件信息预埋，使得这些插件的组件和原生接入时表现一致，是真实的Android组件，在运行时，只需要通过反射修改插件的组件的资源，不需要侵入修改插件源码，即可以支持运行插件的组件，使得插件内的组件以真实的Android组件的形式完整的运行起来，以实现插件的组件对应的功能，便于开发，提高了复用性和移植性。

参阅图3所示，为本申请实施例中提供的一种应用架构示意图，包括终端100、服务器200。

终端100可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此，本申请实施例中终端100可以是分为面向使用者的终端，也可以是面向开发人员的终端。

例如，终端100为面向开发人员的终端，则开发人员可以在该终端100上对宿主和插件进行编译，并且还可以运行编译后的宿主可执行文件，以测试在宿主中动态加载插件的效果，进而开发完成后，可以将编译后的宿主可执行文件和插件可执行文件上传至服务器200，普通使用者可以从服务器200下载应用程序的宿主可执行文件和插件可执行文件。

又例如，终端100为面向使用者的终端，则用户即使用者从服务器200下载到应用程序的宿主可执行文件和插件可执行文件后，可以运行该应用程序，即可以启动宿主可执行文件，并在宿主中动态加载和运行插件，以执行插件所实现的功能。

服务器200为终端100的后台服务器，能够为终端100提供各种网络服务，对于不同的应用程序，服务器200可以认为是相应的后台服务器，服务器200可以为使用者的终端100提供不同应用程序的宿主可执行文件和插件可执行文件，可以动态下发不同的插件，以实现应用程序的更新。

其中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。

终端100与服务器200可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制，例如图1中以终端100和服务器200通过互联网相连，实现相互之间的通信为例。

可选地，上述的互联网使用标准通信技术、协议，或者两者结合。互联网通常为因特网、但也可以是任何网络，包括但不限于局域网(Local Area Network，LAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合。在一些实施例中，使用包括超文本标记语言(Hyper Text Mark-up Language，HTML)、可扩展标记语言(Extensible MarkupLanguage，XML)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(Secure Socket Layer，SSL)、传输层安全(Transport Layer Security，TLS)、虚拟专用网络(Virtual Private Network，VPN)、网际协议安全(Internet ProtocolSecurity，IPsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。

需要说明的是，本申请实施例中的宿主中插件加载方法主要由终端100执行，本申请实施例以该方法应用于终端100进行说明，例如，终端100从服务器200中下载获取某应用程序的宿主可执行文件和插件可执行文件，用户在终端100上点击运行该应用程序时，即可以启动宿主可执行文件，并且在运行宿主可执行文件时，可以调用和加载插件中类和组件，以运行插件来执行插件所对应的功能。

值得说明的是，本申请实施例中的应用架构图是为了更加清楚地说明本申请实施例中的技术方案，并不构成对本申请实施例提供的技术方案的限制，并且本申请实施例中主要以Android应用程序为例，但对于其它的应用架构和应用，本申请实施例提供的技术方案对于类似的问题，同样适用，本申请各个实施例中，以宿主中插件加载方法应用于图3所示的应用架构为例进行示意性说明。

基于上述实施例，参阅图4所示，为本申请实施例中宿主中插件加载方法流程图，具体该方法包括：

步骤400：在运行应用程序时，启动应用程序的宿主可执行文件，其中，应用程序包括宿主可执行文件和插件可执行文件，宿主可执行文件中至少打包有宿主类加载器、插件类加载器以及插件的组件声明代码。

其中，宿主类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器。

本申请实施例中，在编译生成宿主可执行文件时，打包输出的宿主可执行文件中至少包括宿主类加载器、插件的组件声明代码，还包括宿主的代码工程、插件类加载器等，其中，可执行文件例如为Apk文件。

其中，应用程序并不进行限制，可以任何可以安装并运行在终端操作系统中的应用程序，应用程序包括宿主可执行文件和插件可执行文件。用户在终端只需安装和运行宿主可执行文件即可，插件可执行文件对于用户来说是无感知的，但是也会下发到用户终端，从而实现在运行宿主可执行文件时，可以在宿主中动态加载插件的类或组件。例如，用户点击终端中应用程序图标，运行该应用程序，即启动该应用程序的宿主可执行文件。

步骤410：若当前执行的功能所对应的资源位于插件可执行文件中，则在触发应用程序所对应的操作系统的组件启动程序时，基于第二类加载器和插件的组件声明代码，确定查找到当前执行的功能对应的组件声明，并创建组件对象。

例如，某应用程序基于功能划分，由不同插件实现不同功能，在运行宿主可执行文件时，宿主类加载器和插件类加载器初始化，并且组件启动器代理初始化，依次执行宿主可执行文件，若触发启动插件可执行文件中的组件，即实际功能所对应的资源位于插件可执行文件中，则可以通过调用操作系统的组件启动程序和宿主类加载器中的用于加载插件的类的第二类加载器，创建操作系统的组件对象。

其中，该操作系统为应用程序的运行环境，例如为Android系统，本申请实施例中并不进行限制。

实际中，组件运行需要依赖操作系统，组件是需要注册才可以使用的，即注册到操作系统，本申请实施例中，在触发启动插件中组件时，操作系统组件启动程序创建组件对象时，需要宿主类加载器提供实现支撑，这是因为在运行宿主可执行文件时，若该组件没有在宿主可执行文件中或无法查找到该组件，就直接创建组件对象会报错，应用程序无法继续运行，而通过宿主类加载器可以访问并加载插件可执行文件中的类，即可以查找到对应的组件，因此在创建对象时可以避免报错的情况。

步骤420：修改插件可执行文件中组件对象对应的组件，以使插件可执行文件中对应组件的资源赋值给组件对象。

本申请实施例中，创建组件对象后，组件对象会指向宿主可执行文件中资源，而实际中，该组件对象的真正资源位于插件可执行文件中，为了使得插件中组件可以正常运行，本申请实施例中，通过反射修改插件内组件的资源及context对象，以使得插件可执行文件中对应组件的资源赋值给组件对象。

通常在Java中，根据类的名字，就可以通过反射机制获得类的所有信息，反射机制可以实现动态创建对象和编译，获得类的各种内容，使得代码更加灵活，也就是说，在运行状态时，对于任意一个类，都能够知道这个类的属性和方法，并且对于任意一个对象，都能够调用它的任何方法和属性，这种动态获取信息以及动态调用对象的方法的功能可以称为Java的反射，这样，基于反射机制的原理，本申请实施例中，可以实现不侵入修改插件的组件源码，而是在运行时，通过反射修改以实现插件的组件的运行。

具体地，执行步骤420时包括：通过反射机制，基于宿主类加载器中的第二类加载器，从插件可执行文件中加载组件对象对应的组件，并将插件可执行文件中对应组件的资源赋值给组件对象。

步骤430：运行组件对象，以执行插件可执行文件中对应组件的资源所实现的功能。

这样，运行该组件，即可以执行对应插件可执行文件中功能，例如运行某应用程序时，需执行广告播放功能，该广告播放功能由某插件的组件实现，在宿主可执行文件中，运行到该插件的组件时，创建组件对象，并反射修改插件中该组件，可以使得创建的组件对象的赋值指向该插件中组件的资源，进而可以实现插件的组件的动态运行。

进一步地，在启动宿主可执行文件时，若当前执行的功能所对应的资源位于宿主可执行文件，即触发的即为宿主中组件，则无需修改，在触发操作系统的组件启动程序，创建组件对象后，通过反射修改，该组件对象的资源赋值即指向宿主可执行文件，因此创建后，直接运行该组件即可。

进一步地，本申请实施例中构建的宿主类加载器的结构中不仅集成有用于加载宿主的类的第一类加载器，还包括用于加载插件的类的第二类加载器，插件类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器，这样，通过构建特殊的类加载器的结构，可以打通插件和宿主间的类加载器，解决动态运行插件的过程中类查找问题，以及解决宿主和插件之间的类需要互相依赖的问题，实现宿主和插件之间可以互相加载类，而不出现循环加载的死锁。

进而在运行宿主可执行文件过程中，可以通过宿主类加载器和插件类加载器，在执行某个类时都可以查找并加载到，保证程序正常运行，针对非组件的普通类时，具体本申请实施例中提供了一种可能的实施方式，针对当前触发执行的类，基于宿主类加载器，通过第一类加载器从宿主可执行文件中进行查找类，若未查找到，则通过第二类加载器从插件可执行文件中查找，确定查找到后，加载插件可执行文件中的类，并执行类对应的功能。

这样，通过宿主类加载器，可以优先加载宿主的类，其次加载插件的类，从而实现在宿主中加载插件的类的目的。

另外还可以实现在插件中加载宿主的类的目的，本申请实施例中提供了一种可能的实施方式，加载插件可执行文件中的类，或执行插件可执行文件中对应组件的资源所实现的功能时，若触发执行宿主可执行文件中的类，则通过插件类加载器从宿主可执行文件中插件，并确定查找到后，加载宿主可执行文件中的类。

这样，本申请实施例中插件类加载器的结构中还可以包含用于加载宿主的类的第一类加载器，从而可以满足插件需要使用宿主的类的需求，从而基于插件类加载器和宿主类加载器，实现了宿主和插件之间的类互相访问，而不出现循环加载的死锁。

基于上述实施例中，可知本申请实施例为了在插件动态下发时，实现宿主和插件的类相互访问并无需侵入修改插件源码的目的，主要还是在编译期，预先构建类加载器和在宿主中预埋插件的组件，进而才能在运行期实现该目的，下面对本申请实施例中编译期的实施方式进行说明，具体地，针对编译期，本申请实施例中提供了一种可能的实施方式：

S1、在编译时，获取插件的程序源码、插件的组件声明代码和宿主的代码工程。

其中，插件的程序源码为任何需要被动态下发的SDK代码。

S2、编译插件的程序源码，获得插件的插件可执行文件。

具体编译方法并不进行限制，本申请实施例中仅需把插件SDK程序源码，按原样打包成插件可执行文件，即插件Apk文件，而无需打包入宿主Apk文件，减小宿主Apk文件的大小。

S3、在编译时，基于宿主和插件的程序源码的依赖关系，在宿主的代码工程中编译生成需调用插件的程序源码中类的声明代码，并将基于插件的程序源码编译后的宿主的代码工程，以及插件的组件声明代码和宿主类加载器、插件类加载器进行打包，获得宿主的宿主可执行文件。

本申请实施例中，定义宿主的代码工程与插件的程序源码的依赖关系，为仅编译依赖关系，即compileOnly依赖，在不影响功能的前提下，插件的程序源码仅参与编译而不打包输出，并且定义宿主的代码工程与插件的组件声明代码的依赖关系为直接依赖，即implement依赖，以及宿主的代码工程与类加载器(包括宿主类加载器和插件类加载器)的依赖关系也为implement依赖，这样，在编译宿主的代码工程时，编译期依赖插件的程序源码，进行代码编写，在宿主的代码工程中编译生成需调用插件的程序源码中类的生命代码，而对于插件的组件声明代码、宿主类加载器和插件类加载器与宿主的代码工程打包输出，而得到最终的宿主可执行文件。

可知，动态化的插件的程序源码，并未包含在宿主Apk文件中，宿主在执行到插件相关的逻辑时，如果加载不到对应的类，程序便会崩溃，因此，本申请实施例中构建了新的类加载器，具体地：采用双亲委派模型，分别构建宿主类加载器和插件类加载器。

下面分别具体介绍本申请实施例中的宿主类加载器和插件类加载器。

本申请实施例中，针对Java语言，Java平台类加载器必须满足双亲委派模型，因此类的加载动作总是优先委托给父类加载器。因此，本申请实施例中构建的宿主类加载器，满足优先加载宿主的类，其次加载动态文件的类的目的。

1)插件类加载器的结构为：操作系统的操作系统类加载器为第二组类加载器的父类加载器，第二组类加载器中包含有复制后的第一类加载器和第二类加载器。

例如，参阅图5所示，为本申请实施例中插件类加载器的结构示意图，如图5所示，BootClassLoader为操作系统类加载器，用于加载Java语言的软件开发工具包(JavaDevelopment Kit，JDK)类和系统公共类，第一类加载器为HostClassLoader，第二类加载器为PluginClassLoader，创建独立的类加载器即第二组类加载器加载插件，并持有用于加载宿主的类的第一类加载器复制后的对象，即CopyHostClassLoader，使得插件类加载器可以加载插件的类，同时也能加载宿主的类。

2)宿主类加载器的结构为：操作系统的操作系统类加载器为第一组类加载器的父类加载器，第一组类加载器为第一类加载器的父类加载器，第一组类加载器中包含有复制后的第一类加载器和第二类加载器。

例如，参阅图6所示，为本申请实施例中宿主类加载器的结构示意图，创建宿主原始的宿主类加载器(即第一类加载器)复制后的对象，并创建新的类加载器，持有复制后的第一类加载器，并且该新创建的类加载器的类加载的过程被修改，增加优先宿主类加载、加载不到时从插件的类加载器加载的逻辑，同时将此类加载器通过反射的方式，设置为第一类加载器的父类加载器，这样实现了宿主类加载器可以加载到插件的类。

本申请实施例中，通过构建新的宿主类加载器和插件类加载器，实现宿主和插件之间可以相互加载类，并且在宿主可执行文件中内置插件的组件声明，将插件内组件的声明全部预埋到宿主中，以真实的组件信息预埋，进而在运行应用程序时，启动应用程序的宿主可执行文件，若当前执行的功能所对应的资源位于插件可执行文件中，则基于宿主类加载器，触发应用程序所对应的操作系统的组件启动程序，创建组件对象，并修改插件可执行文件中组件对象对应的组件，以使插件可执行文件中对应组件的资源赋值给组件对象，进而运行组件对象，即以执行插件可执行文件中对应组件的资源所实现的功能，这样，在运行期间，插件内的组件对象创建时，通过反射修改插件组件，例如修改插件的组件的关键成员变量的方法，修改插件的组件的资源和context对象，无侵入，轻量地实现插件的组件动态运行，进而可以实现插件的逻辑代码可以不随着宿主发布，可以动态下发，并且无需集成插件到宿主可执行文件中，最终达到宿主能集成插件的能力但是宿主包大小增量很小的目的。

基于上述实施例中，下面采用具体应用场景进行说明，本申请实施例中宿主中插件加载方法可以分为编译期和运行期两方面，下面分别进行说明：

一、编译期。参阅图7所示，为本申请实施例中宿主中插件加载方法的编译方案逻辑原理图。

如图7所示，本申请实施例中编译方案中可以包括几个模块，从而实现无侵入式并轻量级的插件SDK动态下发方法，具体可以包括动态化框架、宿主工程、插件的程序源码、插件的组件声明代码、插件动态化编译工程等。

1)动态化框架：为插件SDK动态化实现的核心模块，主要包括：类加载器处理模块、插件下载模块、插件加载运行模块，主要负责插件的下载和运行。

2)插件的程序源码：为需要被动态下发的插件代码，本申请实施例中并不进行限制，例如，为一个实现小程序运行的小程序运行平台SDK，也可以为一个实现广告播放能力的广告SDK等。

3)插件的组件声明代码：包括插件组件定义和资源定义，插件内涉及到的Activity、Content Provider、Receiver和Service等组件的定义需要事先声明，并提供给宿主直接依赖使用，否则运行期间会被Android系统认为是非法组件。

4)宿主工程：为宿主Apk的代码工程，直接依赖动态化框架模块，实现动态化加载能力；编译期依赖插件的程序源码，便于代码编写；直接依赖插件的组件声明代码，用于编入插件内组件的声明代码，进而编译输出宿主Apk文件，即宿主可执行文件。

5)插件动态化编译工程：负责把插件的程序源码编译输出Apk文件，输出动态化产物，即插件可执行文件。

这样，本申请实施例中，在编译期，直接将插件的程序源码编译成插件可执行文件，而不打包到宿主可执行文件中，可以减少引入插件能力导致的宿主包大小增量，并且为了能保证在宿主中可以正常加载和运行插件，构建新的宿主类加载器和插件类加载器的结构，实现宿主和插件之间类可以相互加载，另外考虑到插件SDK的组件数量通常是有限的，并且不会轻易修改和添加，因此在宿主可执行文件中打包预埋插件的组件定义，采用该组件预埋的方式可以解决操作系统对组件的检查约束，可以保证插件的组件正常运行。

二、运行期。

1)在运行应用程序时，启动宿主可执行文件，当前触发执行某个非组件的类时，基于宿主类加载器，先通过第一类加载器从宿主可执行文件中查找，若未查找到，则通过第二类加载器从插件可执行文件中查找，确定查找到后，加载插件可执行文件中的类，并执行该类对应的功能。

并且在执行插件可执行文件中的类或组件过程中，若触发到宿主中类时，也可以通过插件类加载器从宿主可执行文件中加载该类。

这样，可以实现了宿主类加载器可以加载到插件的类，同时插件类加载器也可以加载到宿主的类。

2)本申请实施例中还可以通过反射修改插件内组件的资源对象，使得插件的组件可以正常运行，参阅图8所示，为本申请实施例中宿主中插件加载方法的运行期方案逻辑原理图，具体该方法包括：

步骤800：启动应用程序的宿主可执行文件。

例如，用户在终端点击某应用程序的图标，触发运行应用程序，启动宿主可执行文件。

步骤801：启动应用attachBaseContext()方法。

步骤802：类加载器初始化。

本申请实施例中类加载器包括宿主类加载器和插件类加载器。

步骤803：组件启动器代理初始化。

步骤804：执行宿主的程序流程。

即启动宿主可执行文件，依次执行宿主可执行文件的程序流程。

步骤805：触发启动插件的组件。

即当前执行的功能所对应的资源位于插件可执行文件中，触发启动插件内组件。

步骤806：触发操作系统的组件启动程序。

例如，操作系统为Android系统，Android系统组件启动逻辑运行。

步骤807：创建组件对象。

本申请实施例中，调用Android系统的组件启动程序创建组件对象时，需要类加载器提供实现支撑，可以在宿主可执行文件中加载到该组件，确定查找到该组件的声明代码，即可以保证创建组件对象时不会出现错误，能够正常创建组件对象。

步骤808：修改插件可执行文件中组件对象对应的组件。

例如，通过反射修改插件中对应组件的资源及context对象，使得插件可执行文件中对应组件的资源赋值给组件对象，无需侵入插件的组件源码，即可以完成插件内组件的正常运行。

步骤809：运行组件。

即可以正常运行插件的组件，以执行该组件的资源所实现的功能。

这样，本申请实施例中，无需侵入修改插件的组件源码，使得插件的组件可以正常运行，实现轻量的插件动态下发的目的。

另外，本申请实施例中，宿主中插件加载方法可以应用到各类Android平台应用程序的减少宿主包大小，部分独立能力插件模块动态接入下发等场景，这样，应用程序的宿主中可以动态加载用于实现不同功能的插件，该插件可以是第三方开发，并不进行限制，便于开发和复用，动态下发插件，可以实现不断更新该应用程序。

基于同一发明构思，本申请实施例中还提供了一种宿主中插件加载装置，该宿主中插件加载装置例如可以是前述实施例中的终端，该宿主中插件加载装置可以是硬件结构、软件模块、或硬件结构加软件模块。基于上述实施例，参阅图9所示，本申请实施例中一种宿主中插件加载装置，具体包括：

启动模块90，用于在运行应用程序时，启动应用程序的宿主可执行文件，其中，应用程序包括宿主可执行文件和插件可执行文件，宿主可执行文件中至少打包有宿主类加载器、插件类加载器以及插件的组件声明代码，宿主类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器；

创建模块91，用于若当前执行的功能所对应的资源位于插件可执行文件中，则在触发应用程序所对应的操作系统的组件启动程序时，基于第二类加载器和插件的组件声明代码，确定查找到当前执行的功能对应的组件声明，并创建组件对象；

修改模块92，用于修改插件可执行文件中组件对象对应的组件，以使插件可执行文件中对应组件的资源赋值给组件对象；

运行模块93，用于运行组件对象，以执行插件可执行文件中对应组件的资源所实现的功能。

可选的，进一步包括第一加载模块94，用于：

针对当前触发执行的类，基于宿主类加载器，通过第一类加载器从宿主可执行文件中进行查找类，若未查找到，则通过第二类加载器从插件可执行文件中查找，确定查找到后，加载插件可执行文件中的类，并执行类对应的功能。

可选的，宿主可执行文件中还至少打包有插件类加载器，插件类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器，则进一步包括：

第二加载模块95，用于加载插件可执行文件中的类，或执行插件可执行文件中对应组件的资源所实现的功能时，若触发执行宿主可执行文件中的类，则通过插件类加载器从宿主可执行文件中查找，并确定查找到后，加载宿主可执行文件中的类。

可选的，修改插件可执行文件中组件对象对应的组件，以使插件可执行文件中对应组件的资源赋值给组件对象时，修改模块92具体用于：

通过反射机制，基于宿主类加载器中的第二类加载器，从插件可执行文件中加载组件对象对应的组件，并将插件可执行文件中对应组件的资源赋值给组件对象。

可选的，进一步包括，编译模块96用于：

在编译时，获取插件的程序源码、插件的组件声明代码和宿主的代码工程；

编译插件的程序源码，获得插件的插件可执行文件；

并且在编译时，基于宿主和插件的程序源码的依赖关系，在宿主的代码工程中编译生成需调用插件的程序源码中类的声明代码，并将基于插件的程序源码编译后的宿主的代码工程，以及插件的组件声明代码和宿主类加载器、插件类加载器进行打包，获得宿主的宿主可执行文件。

可选的，编译模块96进一步用于：

采用双亲委派模型，分别构建宿主类加载器和插件类加载器；

其中，宿主类加载器的结构为：操作系统的操作系统类加载器为第一组类加载器的父类加载器，第一组类加载器为第一类加载器的父类加载器，第一组类加载器中包含有复制后的第一类加载器和第二类加载器；

插件类加载器的结构为：操作系统的操作系统类加载器为第二组类加载器的父类加载器，第二组类加载器中包含有复制后的第一类加载器和第二类加载器。

基于上述实施例，参阅图10所示为本申请实施例中电子设备的结构示意图。

本申请实施例提供了一种电子设备，该电子设备可以是前述实施例中的终端，该电子设备可以包括处理器1010(Center Processing Unit，CPU)、存储器1020、输入设备1030和输出设备1040等。

存储器1020可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器1010提供存储器1020中存储的程序指令和数据。在本申请实施例中，存储器1020可以用于存储本申请实施例中任一种宿主中插件加载方法的程序。

处理器1010通过调用存储器1020存储的程序指令，处理器1010用于按照获得的程序指令执行本申请实施例中任一种宿主中插件加载方法。

基于上述实施例，本申请实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意方法实施例中的宿主中插件加载方法。

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

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

Claims (12)

1.一种宿主中插件加载方法，其特征在于，包括：

在运行应用程序时，启动所述应用程序的宿主可执行文件，其中，所述应用程序包括宿主可执行文件和插件可执行文件，所述宿主可执行文件中至少打包有宿主类加载器、插件类加载器以及插件的组件声明代码，所述宿主类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器；

若当前执行的功能所对应的资源位于插件可执行文件中，则在触发所述应用程序所对应的操作系统的组件启动程序时，基于所述第二类加载器和插件的组件声明代码，确定查找到所述当前执行的功能对应的组件声明，并创建组件对象；

修改所述插件可执行文件中所述组件对象对应的组件，以使所述插件可执行文件中对应组件的资源赋值给所述组件对象；

运行所述组件对象，以执行所述插件可执行文件中对应组件的资源所实现的功能。

2.如权利要求1所述的方法，其特征在于，进一步包括：

针对当前触发执行的类，基于所述宿主类加载器，通过所述第一类加载器从所述宿主可执行文件中进行查找所述类，若未查找到，则通过所述第二类加载器从所述插件可执行文件中查找，确定查找到后，加载所述插件可执行文件中的类，并执行所述类对应的功能。

3.如权利要求2所述的方法，其特征在于，所述插件类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器，则进一步包括：

加载所述插件可执行文件中的类，或执行插件可执行文件中对应组件的资源所实现的功能时，若触发执行所述宿主可执行文件中的类，则通过所述插件类加载器从所述宿主可执行文件中查找，并确定查找到后，加载所述宿主可执行文件中的类。

4.如权利要求1所述的方法，其特征在于，修改所述插件可执行文件中所述组件对象对应的组件，以使所述插件可执行文件中对应组件的资源赋值给所述组件对象，具体包括：

通过反射机制，基于所述宿主类加载器中的所述第二类加载器，从所述插件可执行文件中加载所述组件对象对应的组件，并将所述插件可执行文件中对应组件的资源赋值给所述组件对象。

5.如权利要求1所述的方法，其特征在于，进一步包括：

在编译时，获取所述插件的程序源码、所述插件的组件声明代码和所述宿主的代码工程；

编译所述插件的程序源码，获得所述插件的插件可执行文件；

并且在编译时，基于宿主和所述插件的程序源码的依赖关系，在所述宿主的代码工程中编译生成需调用所述插件的程序源码中类的声明代码，并将基于所述插件的程序源码编译后的所述宿主的代码工程，以及所述插件的组件声明代码和所述宿主类加载器、所述插件类加载器进行打包，获得所述宿主的宿主可执行文件。

6.如权利要求1-5任一项所述的方法，其特征在于，进一步包括：

采用双亲委派模型，分别构建所述宿主类加载器和所述插件类加载器；

其中，所述宿主类加载器的结构为：所述操作系统的操作系统类加载器为第一组类加载器的父类加载器，所述第一组类加载器为所述第一类加载器的父类加载器，所述第一组类加载器中包含有复制后的所述第一类加载器和所述第二类加载器；

所述插件类加载器的结构为：所述操作系统的操作系统类加载器为第二组类加载器的父类加载器，所述第二组类加载器中包含有复制后的所述第一类加载器和所述第二类加载器。

7.一种宿主中插件加载装置，其特征在于，包括：

启动模块，用于在运行应用程序时，启动所述应用程序的宿主可执行文件，其中，所述应用程序包括宿主可执行文件和插件可执行文件，所述宿主可执行文件中至少打包有宿主类加载器、插件类加载器以及插件的组件声明代码，所述宿主类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器；

创建模块，用于若当前执行的功能所对应的资源位于插件可执行文件中，则在触发所述应用程序所对应的操作系统的组件启动程序时，基于所述第二类加载器和插件的组件声明代码，确定查找到所述当前执行的功能对应的组件声明，并创建组件对象；

修改模块，用于修改所述插件可执行文件中所述组件对象对应的组件，以使所述插件可执行文件中对应组件的资源赋值给所述组件对象；

运行模块，用于运行所述组件对象，以执行所述插件可执行文件中对应组件的资源所实现的功能。

8.如权利要求7所述的装置，其特征在于，进一步包括，第一加载模块，用于：

针对当前触发执行的类，基于所述宿主类加载器，通过所述第一类加载器从所述宿主可执行文件中进行查找所述类，若未查找到，则通过所述第二类加载器从所述插件可执行文件中查找，确定查找到后，加载所述插件可执行文件中的类，并执行所述类对应的功能。

9.如权利要求8所述的装置，其特征在于，所述插件类加载器的结构中集成有用于加载宿主的类的第一类加载器和用于加载插件的类的第二类加载器，则进一步包括：

第二加载模块，用于加载所述插件可执行文件中的类，或执行插件可执行文件中对应组件的资源所实现的功能时，若触发执行所述宿主可执行文件中的类，则通过所述插件类加载器从所述宿主可执行文件中查找，并确定查找到后，加载所述宿主可执行文件中的类。

10.如权利要求7-9任一项所述的装置，其特征在于，进一步包括，编译模块，用于：

采用双亲委派模型，分别构建所述宿主类加载器和所述插件类加载器；

其中，所述宿主类加载器的结构为：所述操作系统的操作系统类加载器为第一组类加载器的父类加载器，所述第一组类加载器为所述第一类加载器的父类加载器，所述第一组类加载器中包含有复制后的所述第一类加载器和所述第二类加载器；

所述插件类加载器的结构为：所述操作系统的操作系统类加载器为第二组类加载器的父类加载器，所述第二组类加载器中包含有复制后的所述第一类加载器和所述第二类加载器。

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

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

Images