CN114741121A - 用于模块加载的方法与装置、电子设备 - Google Patents

Abstract

本申请公开了一种用于模块加载的方法与装置、电子设备；该方法包括：根据配置文件生成可编译文件，可编译文件包含全局依赖关系信息，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，可编译文件用于加载M个模块，配置文件包含多个单向模块依赖描述信息，单向模块依赖描述信息用于描述一个模块与其他模块之间的局部加载依赖关系，模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。本申请通过全局加载依赖关系实现从全局角度上快速深度遍历或广度优先遍历M个模块以进行加载，从而有利于提高模块加载的效率、可靠性和灵活性。

Description

用于模块加载的方法与装置、电子设备

技术领域

本申请涉及计算机技术领域，具体涉及一种用于模块加载和方法与装置、电子设备。

背景技术

在计算机技术领域中定义了模块(module)。其中，模块可以定义为用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务。

例如，用于驱动硬件的软件驱动程序可以包括串口(如UART、SPI、I2C等)驱动程序、计时器驱动程序、看门狗驱动程序等；用于提供特定功能的软件服务可以包括用于跨系统通信的软件服务、用于管理存储器(如非易失性存储器(Non-Volatile Memory，NVM))的软件服务、用于管理电源的软件服务、用于提供协议栈的软件服务等。

操作系统在运行过程中通常需要加载(启动/运行等)各类模块，而不同的操作系统可能会采用不同的加载方式。

例如，Linux操作系统中采用静态加载和动态加载两种方式来加载模块。其中，静态加载的方式是将模块直接编译进内核中，并随内核的启动而加载；动态加载的方式不是将模块编译到内核中，而是在内核启动完成后，仅在需要用到某一模块时才会进行加载。

另外，在一些操作系统中，会使用优先级来定义模块在操作系统中的位置，从而通过模块优先级的方式来决定模块的加载顺序。除此之外，如何进行模块加载，还需要进一步研究。

发明内容

本申请实施例提供了一种用于模块加载和方法与装置、电子设备，以期望从单个模块的局部角度来构建单个模块之间的局部加载依赖关系，再根据单个模块之间的局部加载依赖关系从全局角度来确定整个模块之间的全局加载依赖关系，以便通过全局加载依赖关系实现从全局角度上快速深度遍历或广度优先遍历M个模块以进行加载，从而有利于提高模块加载的效率、可靠性和灵活性。

第一方面，为本申请的一种用于模块加载的方法，包括

根据配置文件生成可编译文件，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，所述可编译文件用于加载M个所述模块，所述配置文件包含多个单向模块依赖描述信息，所述单向模块依赖描述信息用于描述一个所述模块与其他所述模块之间的局部加载依赖关系，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。

可见，本申请实施例可以通过配置文件中的单向模块加载描述信息来描述一个模块与其他模块之间的局部加载依赖关系，实现直接显式配置单个模块之间的局部加载依赖关系，从而通过直接显式配置使得单个模块之间的局部加载依赖关系更加简洁、清晰和灵活；根据配置文件生成可编译文件，实现根据单个模块之间的局部加载依赖关系确定整个模块之间的全局加载依赖关系，以及实现从单个模块的局部角度到整个模块的全局角度来生成M个模块之间的全局加载依赖关系，以便通过全局加载依赖关系实现从全局角度上快速深度遍历或广度优先遍历M个模块以进行加载，从而有利于提高模块加载的效率、可靠性和灵活性。

第二方面，为本申请的一种用于模块加载的方法，包括：

创建加载队列和加载线程，所述加载队列用于存放模块，所述加载线程用于维护所述加载队列以进行所述模块的加载，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务；

控制所述加载队列和所述加载线程以根据可编译文件对M个所述模块进行加载，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个所述模块的全局加载依赖关系，M为大于1的整数。

可见，本申请实施例引入了加载队列和加载线程，并通过控制加载线程来维护加载队列以根据可编译文件对M个模块进行高效、灵活的加载，从而有利于实现模块加载的高效率、高可靠性和高灵活性的可能性。

第三方面，为本申请的一种用于模块加载的装置，包括：

生成单元，用于根据配置文件生成可编译文件，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个模块的全局加载依赖关系，所述可编译文件用于加载M个所述模块，所述配置文件包含多个单向模块依赖描述信息，所述单向模块依赖描述信息用于描述一个所述模块加载时所需依赖的其他所述模块，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。

第三方面的技术方案所带来的有益效果可以参见第一方面的技术方案所带来的技术效果，此处不再赘述。

第四方面，为本申请的一种用于模块加载的装置，包括：

创建单元，用于创建加载队列和加载线程，所述加载队列用于存放模块，所述加载线程用于维护所述加载队列以进行所述模块的加载，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务；

加载单元，用于控制所述加载队列和所述加载线程以根据可编译文件对M个所述模块进行加载，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个所述模块的全局加载依赖关系，M为大于1的整数。

第四方面的技术方案所带来的有益效果可以参见第二方面的技术方案所带来的技术效果，此处不再赘述。

第五方面，为本申请的一种电子设备，包括处理器、存储器及存储在所述存储器上的计算机程序或指令，所述处理器执行所述计算机程序或指令以实现上述第一方面或第二方面中所设计的方法中的步骤。

第六方面，为本申请的一种计算机可读存储介质，其中，所述计算机可读存储介质上存储有计算机程序或指令，所述计算机程序或指令被处理器执行时以实现上述第一方面或第二方面中所设计的方法中的步骤。

第七方面，为本申请的一种计算机程序产品，包括计算机程序或指令，其中，所述计算机程序或指令被处理器执行时实现上述第一方面或第二方面中所设计的方法中的步骤。

第五方面至第七方面的技术方案所带来的有益效果可以参见第一方面的技术方案所带来的技术效果，此处不再赘述。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍。

图1是本申请实施例的一种模块加载架构的架构示意图；

图2是本申请实施例的一种全局加载依赖关系图的结构示意图；

图3是本申请实施例的又一种全局加载依赖关系图的结构示意图；

图4是本申请实施例的又一种全局加载依赖关系图的结构示意图；

图5是本申请实施例的又一种全局加载依赖关系图的结构示意图；

图6是本申请实施例的一种模块加载的架构示意图；

图7是本申请实施例的一种用于模块加载的方法的流程示意图；

图8是本申请实施例的又一种用于模块加载的方法的流程示意图；

图9是本申请实施例的一种用于模块加载的装置的功能单元组成框图；

图10是本申请实施例的又一种用于模块加载的装置的功能单元组成框图；

图11是本申请实施例的一种电子设备的结构示意图；

图12是本申请实施例的又一种电子设备的结构示意图。

具体实施方式

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

应理解，本申请实施例中涉及的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、软件、产品或设备没有限定于已列出的步骤或单元，而是还包括没有列出的步骤或单元，或还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

本申请实施例中涉及的“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本申请实施例中的“和/或”，描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示如下三种情况：单独存在A；同时存在A和B；单独存在B。其中，A、B可以是单数或者复数。

本申请实施例中，符号“/”可以表示前后关联对象是一种“或”的关系。另外，符号“/”也可以表示除号，即执行除法运算。例如，A/B，可以表示A除以B。

本申请实施例中的“至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合，是指一个或多个，多个指的是两个或两个以上。例如，a、b或c中的至少一项(个)，可以表示如下七种情况：a，b，c，a和b，a和c，b和c，a、b和c。其中，a、b、c中的每一个可以是元素，也可以是包含一个或多个元素的集合。

本申请实施例中的“等于”可以与大于连用，适用于大于时所采用的技术方案，也可以与小于连用，适用于与小于时所采用的技术方案。当等于与大于连用时，不与小于连用；当等于与小于连用时，不与大于连用。

本申请实施例中的“连接”是指直接连接或者间接连接等各种连接方式，以实现设备间的通信，对此不做任何限定。

本申请实施例中的“加载”可以与“启动”、“初始化”或“运行”等表达为同一概念。

本申请实施例中的“去加载”可以与“关闭”或“停止运行”等表达为同一概念。

本申请实施例中的“依赖”可以与“关联”等表达为同一概念。

在计算机技术领域中定义了模块(module)。其中，模块可以定义为用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务。

操作系统在运行过程中通常需要加载(启动/运行等)各类模块，而不同操作系统可能会采用不同的加载方式。例如，在一些操作系统中，会使用优先级来定义模块在操作系统中的位置，从而通过模块优先级的方式来决定模块的加载顺序。但是，这种方式存在模块之间的加载依赖关系不清晰，从而会影响加载效率、可靠性和灵活性。

基于此，本申请实施例可以直接显式配置每个模块加载时所需依赖的模块，使得模块之间的加载依赖关系更加简洁、清晰和灵活；根据每个模块加载时所需依赖的模块，生成整个模块的全局加载依赖关系图，并通过全局加载依赖关系图从全局上直观反映出整个模块之间的加载依赖关系，进一步达到简洁和清晰的目的；根据全局加载依赖关系图能够实现快速的深度遍历或广度优先遍历所有模块以进行加载，从而有利于提高模块加载的效率、可靠性和灵活性。

下面对本申请实施例所涉及的技术方案以及相关概念等进行具体说明。

一、电子设备

本申请实施例的电子设备可以是手持设备、车载设备、可穿戴设备、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、投影设备、投影仪或者连接到无线调制解调器的其他设备，也可以是用户设备(user equipment，UE)、终端设备(terminal device)、终端、移动终端、手机(smart phone)、智慧屏、智慧电视、智能手表、笔记本电脑、智能音响、摄像头、游戏手柄、麦克风、站点(station，STA)、接入点(accesspoint，AP)、移动台(mobile Station，MS)、个人数字助理(personal digital assistant，PDA)、个人计算机(personal computer，PC)或者中继设备等。

例如，电子设备可以是可穿戴设备。其中，该可穿戴设备也可以称为智能穿戴式设备，是应用穿戴式技术对日常穿戴进行智能化设计、开发的智能设备的总称，例如智能眼镜、智能手套、智能手表、各类具体征监测的智能手环、智能首饰等。该可穿戴设备即可以直接穿在身上，也可以整合到用户的服饰或配件上的一种便携式设备。该可穿戴设备不仅可以搭载专用的硬件架构，还可以搭载专用的软件架构进行数据交互、云端交互等。该穿戴式智能设备可以不依赖其他智能设备以实现完整或者部分的功能。

1、电子设备的硬件结构的示例说明

示例性的，电子设备的硬件结构可以包括处理器、传感组件、显示组件、摄像组件和输入驱动器等。

①处理器

在本申请实施例中，电子设备可以包括处理器。

在一些可能的实现中，处理器可以用于运行或加载操作系统，该操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统。例如，Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统、Windows操作系统、Zephyr操作系统、实时操作系统(Real Time Operating System，RTOS)、DOS操作系统、Mac操作系统、ThreadX操作系统、嵌入式操作系统、NucleusPlus操作系统等。

在一些可能的实现中，处理器可以看作一个完整的系统级芯片(system on chip，SOC)。

在一些可能的实现中，处理器可以包括一个或多个处理单元。例如，处理单元可以包括中央处理器(central processing unit，CPU)、应用处理器(application processor，AP)、微控制单元(microcontroller Unit，MCU)、单片微型计算机(single chipmicrocomputer，SCM)、单片机、图形处理器(graphics processing unit，GPU)、图像信号处理器(image signal processor，ISP)、控制器、数字信号处理器(digital signalprocessor，DSP)、现场可编程逻辑门阵列(field programmable gate array，FPGA)、专用集成电路(application-specific integrated circuit，ASIC)、基带处理器、神经网络处理器(neural-network processing unit，NPU)等中的至少之一。其中，不同的处理单元可以是各自分离，也可以集成在一起。

在一些可能的实现中，一个处理单元可以是单核或者多核。

在一些可能的实现中，一个处理单元可以运行或加载一个多核子系统。其中，多核子系统，可以是具有多核处理能力的操作系统。

在一些可能的实现中，处理器中还可以包含存储器，用于存储指令和数据。

例如，处理器可以调用存储器中存储的程序以运行操作系统。

又例如，处理器中的存储器可以保存或缓存该处理器刚用过或循环使用的指令。若该处理器需要再次使用该指令或数据，则可以从该存储器中直接调用，从而避免重复存取，减少处理器的等待时间以提高系统效率。

又例如，处理器中的存储器还可以保存或缓存数据，并该数据同步或传输给其他处理器执行。其中，处理器中的存储器可以为高速缓冲存储器。

在一些可能的实现中，处理器可以包括一个或多个通信接口。其中，该通信接口可以包括串行外设接口(serial peripheral interface，SPI)、集成电路(inter-integratedcircuit，I2C)接口、集成电路内置音频(inter-integrated circuit sound，I2S)接口、脉冲编码调制(pulse code modulation，PCM)接口、通用异步收发传输器(universalasynchronous receiver/transmitter，UART)接口、移动产业处理器接口(mobileindustry processor interface，MIPI)、通用输入输出(general-purpose input/output，GPIO)接口、用户标识模块(subscriber identity module，SIM)接口、通用串行总线(universal serial bus，USB)接口等中的至少之一。

②传感组件

在本申请实施例中，电子设备可以包括传感组件。

在一些可能的实现中，传感组件可以为传感器。

例如，传感组件可以包括惯性传感器(如惯性运动单元(Inertial Motion Unit，IMU))、压力传感器、陀螺仪传感器、气压传感器、磁传感器、加速度传感器、距离传感器、接近光传感器、指纹传感器、温度传感器、触摸传感器、环境光传感器、骨传导传感器、超带宽UWB传感器、近场通信NFC传感器、激光传感器和/或可见光传感器等。

③显示组件

在本申请实施例中，电子设备可以包括显示组件。显示组件可以用于显示用户界面、用户界面元素和特征、用户可选择控件、各种可显示对象等。

在一些可能的实现中，显示组件可以为显示屏、触摸屏等。

例如，显示组件可以包括显示面板。其中，显示面板可以采用液晶显示屏(liquidcrystal display，LCD)、有机发光二极管(organic light-emitting diode，OLED)、有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emittingdiode，AMOLED)、柔性发光二极管(flex light-emitting diode，FLED)、量子点发光二极管(quantum dot light emitting diodes，QLED)等。

需要说明的是，电子设备可以通过GPU、显示组件以及处理器等实现显示功能。其中，GPU可以用于执行数学和几何计算，并进行图形渲染。另外，GPU可以为图像处理的微处理器，并连接显示组件和处理器。处理器可以包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

④摄像组件

在本申请实施例中，电子设备可以包括摄像组件。

摄像组件可以为摄像头或者摄像模组，其用于捕获(拍摄/扫描等)静态/动态的图像或视频。

摄像组件可以包括镜头、感光元件等，而感光元件可以是电荷耦合器件(chargecoupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。

因此，物体对象可以通过镜头生成光学图像投射到感光元件。感光元件可以把该光学图像中的光信号转换成电信号，再将该电信号传递给ISP转换成数字图像信号。ISP将该数字图像信号输出到DSP。DSP将该数字图像信号转换成标准的RGB、YUV等格式的图像信号。

需要说明的是，电子设备可以通过ISP、DSP、摄像组件、视频编解码器、GPU、显示组件以及处理器等实现捕获(拍摄/扫描等)图像等功能。

ISP可以用于处理摄像组件反馈的数据。例如，在拍照时，先打开快门，再由光线通过摄像组件的镜头传递到摄像组件的感光元件上，实现光信号转换为电信号，最终通过感光元件将该电信号传递给ISP处理以转化为数字图像等。

另外，ISP还可以对图像的噪点、亮度、肤色进行算法优化。

ISP还可以对拍摄场景的曝光、色温等参数进行优化。

在一些可能的示例中，ISP和/或DSP可以设置在摄像组件中。

⑤输入驱动器

在本申请实施例中，电子设备可以包括输入驱动器，用以处理来自用户操作电子设备的各种输入。

例如，当显示屏为触摸屏时，输入驱动器可操作以检测和处理各种触摸输入和/或触摸事件。其中，触摸屏上的触摸输入或触摸事件以同时指示感兴趣的区域以及开始向物体对象(如证件)进行扫描。物体对象可在触摸屏上被显示为要扫描的图像的预览，并且在触摸屏上的特定位置处的触摸事件指示应该扫描的图像。

2、电子设备的软硬件结构的示例说明

示例性的，电子设备的软硬件结构可以包括硬件层、运行在硬件层之上的操作系统层以及运行在操作系统层上的应用层等。

在一些可能的实现中，该硬件层可以包括处理器、内存管理单元(memorymanagement unit，MMU)和内存(也称为存储器)等硬件。

在一些可能的实现中，该内存可以用于存储软体程序/计算机程序/计算机指令/数据等，可以包括存储程序区和存储数据区。其中，存储程序区可以用于存储操作系统或者至少一个功能所需的软体程序/计算机程序/计算机指令等，并且该至少一个功能所需的软件程序/计算机程序/计算机指令可以用于执行本申请实施例所涉及的技术方案；存储数据区可以用于存储本申请实施例所涉及的数据等。

需要说明的是，本申请实施例未对内存数据压缩方法的执行主体的具体结构进行特别限定，只要能够通过运行记录有本申请实施例的提供的方法的计算机程序或指令，以及根据本申请实施例提供的方法进行处理即可。例如，本申请实施例提供的方法的执行主体可以是电子设备，也可以是电子设备中能够调用计算机程序或指令并执行的处理器/装置/模块/单元等，对此不作具体限制。

二、设备驱动模型(Device Driver Model)

目前，计算机技术领域中存在各种类型的设备驱动模型，通过设备驱动模块可以解决设备之间的依赖，使得设备之间按照一定的顺序进行加载(启动/运行等)。

下面以Linux设备驱动模型和Zephyr设备驱动模型为例进行说明。

1、Linux设备驱动模型

Linux设备驱动模型，是Linux内核为了管理硬件上的设备和对应的驱动所制定的一套软件体系，可以支持热插拔和动态更新。

Linux设备驱动模型定义了总线(Bus)、设备(Device)、驱动(Driver)三大组件。其中，Bus是系统中的Device和Driver之间信息交互的通道，且总线管理挂在其上的所有Device和Driver；Device表示系统中的硬件设备，可以包含用于描述硬件设备的名字、属性等信息；Driver表示用于驱动硬件设备的驱动程序。

2、Zephyr设备驱动模型

Zephyr设备驱动模型，是Zephyr内核为了支持和管理大量的软件驱动程序所制定的一套软件体系。其中，不同类型的串口(如UART、SPI、I2C)驱动程序都有通用类型的应用程序接口(Application Programming Interface，API)。

在Zephyr操作系统中，每个设备都有设备等级(Level)和优先级(Prio)两个属性。其中，Level有首要(PRIMARY)、次要(SECONDARY)、超微内核(NANOKERNEL)等五个等级；Prio取值为0～99。

Zephyr设备驱动模型在初始化设备时，先将所有的设备按照各自的Level依次进行排列，然后在每个Level中按照Prio由高到低进行排列，最后按照该顺序进行初始化。

三、一种模块加载机制

为了实现模块加载，本申请提出了一种模块加载机制，优先考虑模块加载的效率、可靠性和灵活性等，并且可以支持在多个并行工作的多核子系统上进行模块加载。

1、实现原理

本申请实施例可以从局部角度直接显式配置单个模块之间的局部加载依赖关系，使得单个模块之间的局部加载依赖关系更加简洁、清晰和灵活；根据单个模块之间的局部加载依赖关系确定整个模块之间的全局加载依赖关系，并通过全局加载依赖关系从全局上直观反映出整个模块之间的加载依赖关系，进一步达到简洁和清晰的目的；根据全局加载依赖关系能够实现快速的深度遍历或广度优先遍历所有模块以进行加载，从而有利于提高模块加载的效率、可靠性和灵活性。

具体实现时，本申请实施例的模块加载机制采用编译时(build-time)与运行时(run-time)相结合的方式。具体如下：

在编译时，利用专门工具(Specific Tool)对配置文件中的M(M为大于1的整数)个模块之间的局部加载依赖关系进行编译处理，生成包含全局依赖关系信息的可编译文件。其中，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，可编译文件可以用于加载M个模块。

在运行时，根据可编译文件中的全局依赖关系信息对M个模块进行加载。

因此，在采用编译时与运行时相结合的方式中，本申请可以将复杂且耗时的从单个模块之间的局部加载依赖关系生成整个模块之间的全局加载依赖关系的处理工作放在编译时进行完成，使得运行时可以直接根据全局加载依赖关系快速的深度遍历或广度优先遍历所有模块以进行加载，从而有利于减少运行时模块加载所占用的时间，提高模块加载的效率、可靠性和灵活性。

2、相关概念

①M个模块

在本申请实施例中，模块可以定义为用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务。或者说，模块可以包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务。

例如，用于驱动硬件的软件驱动程序可以包括串口(如UART、SPI、I2C等)驱动程序、计时器驱动程序、看门狗驱动程序等；用于提供特定功能的软件服务可以包括用于跨子系统通信的软件服务、用于管理存储器(如NVM)的软件服务、用于管理电源的软件服务、用于提供协议栈的软件服务等。

另外，在本申请实施例中，模块使用者可以按照自身的需要来定义各个模块之间的局部加载依赖关系。为了便于描述，本申请实施例引入M个模块，M为大于1的整数。也就是说，模块使用者需要定义M个模型之间的局部加载依赖关系。

②多核子系统

本申请实施例的模块加载机制可以应用于多核多操作系统的场景。

需要说明的是，多核多操作系统，可以是具有多核处理能力的多操作系统，可以包括多个多核子系统。其中，一个多核子系统可以是一个具有多核处理能力的操作系统，而不同的多核子系统可能具有不同的核数和操作系统。

例如，一个多核子系统为具有核数4的ThreadX操作系统，另一个多核子系统为具有核数为2的Zephyr操作系统。

另外，为了支持多核多操作系统，从硬件结构层面来讲，本申请实施例需要具有多个处理单元，每个处理单元可以运行或加载一个多核子系统。

在一些可能的实现中，不同的多核子系统之间可以支持并行工作。也就是说，当某一个多核子系统在运行工作时，另一个多核子系统也可以处于运行工作状态。通过并行工作，使得支持不同的多核子系统的模块可以实现并行加载，从而有利于提高模块加载的效率。

③模块所支持的多核子系统

需要说明的是，本申请实施例的模块可以支持多核子系统。也就是说，模块可以在多核子系统上进行加载。

在一些可能的实现中，不同的模块之间所支持的多核子系统可能是不同的。也就是说，不同的模块可能需要在不同的多核子系统上进行加载。因此，本申请实施例可以实现对跨子系统的模块进行加载。

在一些可能的实现中，不同的模块之间所支持的多核子系统可以是相同的。也就是说，不同的模块可能需要在同一个多核子系统上进行加载。因此，本申请实施例可以实现对同一个子系统下的模块进行加载。

在一些可能的实现中，M个模块中存在所支持的多核子系统是不相同的模块。

例如，有4(M＝4)个模块，分别为模块A、模块B、模块C和模块D。其中，模块A和模块B支持在ThreadX操作系统上加载，模块C和模块D支持在Zephyr操作系统上加载。

④跨子系统的模块

跨子系统的模块，可以是一个模块，该模块依赖的其他模块各自所支持的多核子系统是不同的。

例如，模块C依赖模块A和模块B。其中，模块A支持在ThreadX操作系统上加载，模块B支持在Zephyr操作系统上加载。因此，模块C为跨子系统的模块。

⑤加载依赖关系

a)定义

在本申请实施例中，加载依赖关系，可以用于表示模块加载时模块之间的依赖关系(或关联关系)，或者用于表示模块加载时模块之间的加载顺序，或者用于表示模块关闭时模块之间的关闭顺序等。

例如，若模块B依赖模块A，则需要先加载完成模块A，才能对模块B进行加载。

又例如，若模块B依赖模块A，则需要先关闭完成模块B，才能对模块A进行关闭。

另外，加载依赖关系，可以为单个模块之间的局部加载依赖关系，可以为M个模块之间的全局加载依赖关系。

b)单个模块之间的局部加载依赖关系

在本申请实施例中，单个模块之间的局部加载依赖关系，可以用于表示从局部角度上一个模块加载时所需依赖的其他模块，或者说一个模块与其他模块之间的加载依赖关系。

c)M个模块之间的全局加载依赖关系

在本申请实施例中，M个模块之间的全局加载依赖关系，可以用于表示从全局角度上整个模块之间的加载依赖关系。

例如，有4(M＝4)个模块，分别为模块A、模块B、模块C和模块D。其中，在全局加载依赖关系中，模块B依赖模块A、模块C依赖模块A、模块D依赖模块C。

⑥配置文件

需要说明的是，模块使用者可以按照自身的需求来配置M个模块中每个模块之间的局部加载依赖关系。

在本申请实施例中，配置文件，可以是由模块使用者编写的文件，可以用于配置M个模块加载时所需的相关描述信息。

当然，配置文件也可以采用其他术语描述，如脚本文件、文本文件、模块描述文件等，只要具体相同的功能/含义/概念/定义等，都在本申请所要求保护的范围内，对此不作具体限制。

另外，配置文件具有一定的格式。例如，配置文件的格式为XML，即配置文件为一种XML格式(.xml格式)的文件。

⑦配置文件包含的信息类型

在本申请实施例中，配置文件可以包含以下至少一项：模块依赖描述信息、模块名字描述信息、模块标识符描述信息、模块所支持子系统描述信息。下面分别进行说明。

a)模块依赖描述信息

模块依赖描述信息，可以用于从局部角度描述M个模块各自(或M个模块中每个模块)的局部加载依赖关系。因此，根据模块依赖描述信息，可以从局部角度获知模块之间的局部加载依赖关系，以便后续根据模块依赖描述信息，生成全局依赖关系信息。

当然，模块依赖描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

在一些可能的实现中，模块依赖描述信息可以包含多个单向模块依赖描述信息(或正向模块依赖描述信息)。因此，针对M个模块，会有M个单向模块依赖描述信息。也就是说，模块依赖描述信息可以是M个单向模块依赖描述信息的集合。

◆单向模块依赖描述信息

在本申请实施例中，单向模块依赖描述信息，可以仅用于描述某一个模块与其他模块之间的局部加载依赖关系，或者说某一个模块加载时依赖其他模块，但不能用于描述该某一个模块还被其他模块依赖。也就是说，单向模块依赖描述信息，仅用于描述自身所依赖的那些模块。

当然，单向模块依赖描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

例如，模块C的单向模块依赖描述信息，仅用于描述模块C加载时所需依赖的其他模块为模块A，即模块C依赖模块A。

又例如，模块C的单向模块依赖描述信息，仅用于描述模块C加载时所需依赖的其他模块为模块A和模块C，即模块C依赖模块A和模块B。

◆单模块依赖多个模块

在本申请实施例中，若单向模块依赖描述信息描述自身需要依赖多个模块(即单模块依赖多个模块)，则该多个模块中的每个模块所支持的多核子系统可以是相同的或者不相同的。

例如，模块C的单向模块依赖描述信息，仅用于描述模块C依赖模块A和模块B。其中，模块A所支持的多核子系统与模块B所支持的多核子系统是不相同的。

又例如，模块C的单向模块依赖描述信息，仅用于描述模块C依赖模块A和模块B。其中，模块A所支持的多核子系统与模块B所支持的多核子系统是相同的。

b)模块名字描述信息

在本申请实施例中，模块名字描述信息，可以用于描述M个模块各自的名字(或名称)。因此，通过名字可以快速进行模块的查找、检索等操作，提高模块查找效率。

当然，模块名字描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

在一些可能的实现中，模块名字描述信息可以包含多个单向模块名字描述信息。因此，针对M个模块，会有M个单向模块名字描述信息。也就是说，模块名字描述信息可以是M个单向模块名字描述信息的集合。

◆单向模块名字描述信息

在本申请实施例中，单向模块名字描述信息，可以用于描述某一个模块自身的名字(或名称)。也就是说，单向模块名字描述信息，用于描述自身的名字。

当然，单向模块名字描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

c)模块标识符描述信息

在本申请实施例中，模块标识符描述信息，可以用于M个模块各自的标识符(ID)。因此，通过ID可以快速进行模块的查找、检索等操作，提高模块查找效率。

当然，模块标识符描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

在一些可能的实现中，模块标识符描述信息可以包含多个单向模块标识符描述信息。因此，针对M个模块，会有M个单向模块标识符描述信息。也就是说，模块标识符描述信息可以是M个单向模块标识符描述信息的集合。

◆单向模块标识符描述信息

在本申请实施例中，单向模块标识符描述信息，可以用于描述某一个模块自身的标识符。也就是说，单向模块标识符描述信息，用于描述自身的标识符。

当然，单向模块标识符描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

d)模块所支持子系统描述信息

在本申请实施例中，模块所支持子系统描述信息，用于描述M个模块各自所支持的多核子系统。因此，通过模块所支持子系统描述信息可以确定模块所需加载到哪个多核子系统上，有利于保证模块的正确加载。

当然，模块所支持子系统描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

在一些可能的实现中，模块所支持子系统描述信息可以包含多个单向模块所支持子系统描述信息。因此，针对M个模块，会有M个单向模块所支持子系统描述信息。也就是说，模块所支持子系统描述信息可以是M个单向模块所支持子系统描述信息的集合。

◆单向模块所支持子系统描述信息

在本申请实施例中，单向模块所支持子系统描述信息，可以用于描述某一个模块自身所支持的多核子系统。也就是说，单向模块所支持子系统描述信息，用于描述自身所支持的多核子系统。

当然，单向模块所支持子系统描述信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

⑧可编译文件

在本申请实施例中，可编译文件，可以是根据配置文件生成的，可以用于运行M个模块的加载，可以包含用于运行M个模块加载时所需的相关信息等。

当然，可编译文件也可以采用其他术语描述，如可执行文件等，只要具体相同的功能/含义/概念/定义等，都在本申请所要求保护的范围内，对此不作具体限制。

另外，可编译文件具有一定的格式。例如，可编译文件为一种C语言源程序文件(即.c文件)。

⑨可编译文件包含的信息类型

在本申请实施例中，可编译文件可以包含以下至少一项：全局依赖关系信息、度信息、列表信息。下面分别进行说明。

a)全局依赖关系信息

在本申请实施例中，全局依赖关系信息，可以用于描述M个模块之间的全局加载依赖关系。其中，全局加载依赖关系，用于从全局角度上表示M个模块之间的加载依赖关系，可以用于从全局角度上深度遍历或广度优先遍历所有模块。

当然，全局依赖关系信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

在一些可能的实现中，M个模块之间的全局加载依赖关系可以由全局加载依赖关系图表示。

◆全局加载依赖关系图

本申请实施例可以利用图论模型，将M个模块看作M个节点，并根据单个模块之间的局部加载依赖关系，将具有加载依赖关系的节点用一条边进行连接，从而得到全局加载依赖关系图，即全局加载依赖关系图包括M个节点和至少一条边。因此，可以存在如下：

全局加载依赖关系图中的一个节点，可以用于表示M个模块中的一个；其中，该节点可以是根节点，可以是叶子节点，可以是父节点，也可以是子节点；

全局加载依赖关系图中的一条边，可以用于表示该边的两端节点存在局部加载依赖关系。

总之，全局加载依赖关系图可以看作是一个有向的图结构，或者类似于树的图结构，通过全局加载依赖关系图可以从全局角度上直观反映出整个模块之间的加载依赖关系，使得整个模块之间的加载依赖关系简洁和清晰。

另外，由于不同的模块之间所支持的多核子系统可以是不同的，因此全局加载依赖关系图还可以看作是一个具有跨子系统的图结构，即跨子系统的全局加载依赖关系图。

b)度信息

在本申请实施例中，度信息，可以用于描述全局加载依赖关系图中的所有节点各自的入度和出度，入度可以用于表示节点的入边条数，出度可以用于表示节点的出边条数。

当然，度信息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

需要说明的是，本申请实施例可以利用入度和出度来深度遍历或广度优先遍历全局加载依赖关系图中的各个节点，从而实现遍历所有模块。

在一些可能的实现中，入度可以用于进行模块的加载，出度可以用于进行模块的关闭。

例如，本申请可以将入度为0的节点所表示的一个模块进行加载，可以将出度为0的节点所表示的一个模块进行关闭。

c)列表信息

在本申请实施例中，列表信息，可以用于描述支持同一个多核子系统下的所有模块各自的标识符(ID)所组成的列表。

需要说明的是，由于本申请需要涉及多个多核子系统，而不同的模块可能需要加载到不同的多核子系统上，因此本申请可以生成多个列表，每个列表是由同一个多核子系统下的所有模块的ID组成，并利用ID以直接在该多个列表中对不同的多核子系统下的模块进行查找和检索等，从而有利于提高跨子系统加载时模块查找和检索的效率。

⑩专门工具

在本申请实施例中，专门工具，可以为一种用于根据配置文件生成可编译文件的软件程序。

3、模块加载架构

本申请的模块加载机制采用编译时与运行时相结合的方式。下面对实现该方式的模块加载架构进行示例性说明。

示例性的，如图1所示，模块加载架构10可以包括编译时的专门工具(SpecificTool)110和运行时的加载框架(Boot Framework)120。其中，编译时的专门工具110可以包括描述生成(DescriptorGenerator)模块1101、图生成(Graph Generator)模块1102、图简化(Graph Simplifier)模块1103、依赖检测(Dependency Check)模块1104；运行时的加载框架120可以包括加载策略(Boot Policy)模块1201、加载模块管理(Boot ModuleManager)模块1202、加载服务(Boot Service)模块1203、跨子系统通信(Cross-SubsystemCommunication)模块1204。

1)编译时

编译时的专门工具110在编译时执行，根据配置文件生成可编译文件。其中，编译时的专门工具110中的各个模块的功能描述如下：

①描述生成模块1101

在本申请实施例中，描述生成模块1101，可以用于根据配置文件生成可编译文件。

例如，将.xml格式的配置文件生成.c格式的可编译文件。

②图生成模块1102

在本申请实施例中，图生成模块1102，可以用于根据配置文件生成全局加载依赖关系图，以及全局加载依赖关系图中各节点的入度和出度等。

例如，描述生成模块1101根据配置文件中的多个单向模块依赖描述信息生成全局依赖关系信息和度信息等。

下面对图生成模块1102所生成的全局加载依赖关系图进行示例性说明。

示例性的，如图2所示，有6(M＝6)个模块，分别为模块A、模块B、模块C、模块D、模块E和模块F。其中，配置文件包含6个单向模块依赖描述信息，具体如下：

模块A的单向模块依赖描述信息：未描述模块A所依赖的模块；

模块B的单向模块依赖描述信息：描述模块B依赖模块A；因此，模块B需要等待模块A加载完成，才能进行加载；或者，模块A需要等待模块B关闭完成，才能进行关闭；

模块C的单向模块依赖描述信息：描述模块C依赖模块A；因此，模块C需要等待模块A加载完成，才能进行加载；或者，模块A需要等待模块C关闭完成，才能进行关闭；

模块D的单向模块依赖描述信息：描述模块D依赖模块A，以及模块D还依赖模块C；因此，模块D需要等待模块A和模块C加载完成，才能进行加载；或者，需要先关闭模块D，才能进行模块A和模块C的关闭；

模块E的单向模块依赖描述信息：描述模块E依赖模块B；因此，模块E需要等待模块B加载完成，才能进行加载；或者，需要先关闭模块E，才能进行模块B的关闭；

模块F的单向模块依赖描述信息：描述模块F依赖模块D；因此，模块F需要等待模块D加载完成，才能进行加载；或者，需要先关闭模块F，才能进行模块D的关闭；

因此，根据配置文件生成的全局加载依赖关系图，包含6个节点和6条边，具体如下：

节点A表示模块A；节点A的入度为0，节点A的出度为3，即节点A的度表示为(0,3)；节点A可以为根节点，可以为节点B、节点C和节点D的父节点；

节点B表示模块B；节点B的入度为1，节点B的出度为1，即节点B的度表示为(1,1)；节点B可以为节点A的子节点，可以为节点E的父节点，可以为叶子节点；

节点C表示模块C；节点C的入度为1，节点C的出度为1，即节点C的度表示为(1,1)；节点C可以为节点A的子节点，可以为节点D的父节点，可以为叶子节点；

节点D表示模块D；节点D的入度为1，节点D的出度为1，即节点D的度表示为(1,1)；节点D可以为节点A的子节点，可以为节点F的父节点，可以为叶子节点；

节点E表示模块E；节点E的入度为1，节点E的出度为0，即节点E的度表示为(1,0)；节点E可以为节点B的子节点，可以为叶子节点；

节点F表示模块F；节点F的入度为1，节点F的出度为0，即节点F的度表示为(1,0)；节点F可以为节点D的子节点，可以为叶子节点。

下面再对图生成模块1102所生成的跨子系统的全局加载依赖关系图进行示例性说明。

示例性的，如图3所示，有7(M＝7)个模块，分别为模块A、模块B、模块C、模块D、模块E、模块F和模块G。其中，配置文件包含7个单向模块依赖描述信息和7个单向模块所支持子系统描述信息，具体如下：

模块A的单向模块依赖描述信息：未描述模块A所依赖的模块；

模块E的单向模块依赖描述信息：未描述模块E所依赖的模块；

模块B的单向模块依赖描述信息：描述模块B依赖模块A；因此，模块B需要等待模块A加载完成，才能进行加载；或者，模块A需要等待模块B关闭完成，才能进行关闭；

模块C的单向模块依赖描述信息：描述模块C依赖模块A；因此，模块C需要等待模块A加载完成，才能进行加载；或者，模块A需要等待模块C关闭完成，才能进行关闭；

模块F的单向模块依赖描述信息：描述模块F依赖模块E；因此，模块F需要等待模块E加载完成，才能进行加载；或者，需要先关闭模块F，才能进行模块E的关闭；

模块G的单向模块依赖描述信息：描述模块G依赖模块E；因此，模块G需要等待模块E加载完成，才能进行加载；或者，需要先关闭模块G，才能进行模块E的关闭；

模块D的单向模块依赖描述信息：描述模块D依赖模块C，以及模块D还依赖模块F；因此，模块D需要等待模块C和模块F加载完成，才能进行加载；或者，需要先关闭模块D，才能进行模块C和模块F的关闭；

模块A的单向模块所支持子系统描述信息：描述模块A支持第一多核子系统；

模块A的单向模块所支持子系统描述信息：描述模块A支持第一多核子系统；

模块B的单向模块所支持子系统描述信息：描述模块B支持第一多核子系统；

模块C的单向模块所支持子系统描述信息：描述模块C支持第一多核子系统；

模块D的单向模块所支持子系统描述信息：描述模块D支持第一多核子系统；

模块E的单向模块所支持子系统描述信息：描述模块E支持第二多核子系统；

模块F的单向模块所支持子系统描述信息：描述模块F支持第二多核子系统；

模块G的单向模块所支持子系统描述信息：描述模块G支持第二多核子系统；

因此，根据配置文件生成的跨子系统的全局加载依赖关系图，包含7个节点和6条边，具体如下：

节点A表示模块A；节点A的入度为0，节点A的出度为2，即节点A的度表示为(0,2)；节点A可以为根节点，可以为节点B和节点C的父节点；

节点B表示模块B；节点B的入度为1，节点B的出度为0，即节点B的度表示为(1,0)；节点B可以为节点A的子节点，可以为叶子节点；

节点C表示模块C；节点C的入度为1，节点C的出度为1，即节点C的度表示为(1,1)；节点C可以为节点A的子节点，可以为节点D的父节点，可以为叶子节点；

节点D表示模块D；节点D的入度为2，节点D的出度为0，即节点D的度表示为(2,0)；节点D可以为节点A的子节点，可以为节点F的子节点，可以为叶子节点；

节点E表示模块E；节点E的入度为0，节点E的出度为2，即节点E的度表示为(0,2)；节点E可以为根节点；

节点F表示模块F；节点F的入度为1，节点F的出度为1，即节点F的度表示为(1,1)；节点F可以为节点E的子节点，可以为节点D的父节点，可以为叶子节点；

节点G表示模块G；节点G的入度为1，节点F的出度为0，即节点F的度表示为(1,0)；节点G可以为节点E的子节点，可以为叶子节点。

③图简化模块1103

在本申请实施例中，图简化模块1103，可以用于简化加载依赖关系，去掉多余(或不必要)的加载依赖关系(即去掉冗余边)，生成一个最小化(或最简化)的全局加载依赖关系图。也就是说，图简化模块1103，可以用于执行冗余边删除处理，该冗余边删除处理用于减少全局加载依赖关系图中的节点之间多余的局部加载依赖关系，生成一个最小化的全局加载依赖关系图。

可见，通过去掉冗余边，生成一个最小化的全局加载依赖关系图，使得模块之间的加载依赖关系更加简洁和清晰，从而不仅有利于减少对全局加载依赖关系图中所有节点的遍历时间，还有利于提高模块加载的效率、可靠性。

下面对图简化模块1103去掉全局加载依赖关系图中的冗余边进行示例性说明。

示例性的，如图4所示，图4是对图2中的全局加载依赖关系图去掉冗余边之后的结构示意图。在图2所示的全局加载依赖关系图中，由于模块C加载完成后，模块A也已经加载完成，而模块D只需在模块C后面加载即可，没有必要增加模块D对模块A的依赖，即模块A和模块D之间为多余的加载依赖关系，因此将连接节点A与节点D的那条边看作冗余边，并将该冗余边进行删除，以简化图2所示的全局加载依赖关系图，减少节点的遍历时间，提高模块加载的效率、可靠性。

④依赖检测模块1104

在本申请实施例中，依赖检测模块1104，可以用于检测全局加载依赖关系图中是否存在环路的依赖。若存在，则抛出异常，阻止模块之间的不正确的依赖。这是因为，不正确的依赖关系会导致模块无法正确加载。

也就是说，依赖检测模块1104，可以用于执行环路检测处理，该环路检测处理用于根据拓扑排序对全局加载依赖关系图进行检测以判断是否存在闭合的环路。

可见，通过删除闭合的环路，能够避免模块之间的不正确的依赖，从而不仅有利于保证模块的正确加载，还有利于提高模块加载的效率和可靠性。

下面对依赖检测模块1104删除全局加载依赖关系图中的环路进行示例性说明。

示例性的，如图5所示。依赖检测模块1104根据拓扑排序对图5所示的全局加载依赖关系图进行检测，判断出节点A、节点C和节点D之间形成一个闭合的环路。因此，可以将连接节点A和节点D的那条边删除，从而删除闭合的环路，避免模块之间的不正确的依赖，保证模块的正确加载，提高模块加载的效率和可靠性。

2)运行时

运行时的加载框架120在运行时执行，根据可编译文件对M个模块进行加载。其中，运行时的加载框架120中的各个模块的功能描述如下：

①加载策略模块1201

在本申请实施例中，加载策略模块1201，可以用于创建(或初始化)加载队列和加载线程，控制加载队列和加载线程以根据可编译文件对M个模块进行加载。

a)加载队列

在本申请实施例中，加载队列，可以用于存放模块。

当然，加载队列也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

另外，加载队列可以按照先入先出的方式来存入和取出模块。

需要说明的是，加载队列，可以是由加载线程所维护的队列，该队列可以用于存放M个模块中就绪的模块。

◆就绪

就绪，可以根据表示该模块的节点的入度是否为0来判断。若入度为0，则该模块为就绪；否则，该模块不为就绪。

◆就绪模块

就绪模块，可以是就绪的模块。其中，表示就绪模块的节点的入度为0。

也就是说，就绪模块可以为第一节点(为了便于区分和描述，采用“第一节点”，当然也可以采用其他术语描述)所表示的模块，第一节点是入度为0的节点。

例如，在图2中，节点A所表示的模块A是就绪模块。

◆维护，可以是将就绪的模块存入加载队列，以及从加载队列中取出就绪的模块以进行初始化(如加载)。

b)加载线程

在本申请实施例中，加载线程，可以用于维护加载队列以进行模块的加载。其中，维护加载队列，可以包括将模块存入加载队列，以及从加载队列中取出模块。

当然，加载线程也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

需要说明的是，加载线程，可以看做是一个线程。

在一些可能的实现中，加载线程可以包含以下至少一项：生产者线程、消费者线程和跨子系统通信线程。

◆生产者线程

生产者线程，可以用于将就绪模块存入加载队列中，就绪模块为第一节点所表示的模块，第一节点为全局加载依赖关系图中的入度为0的节点。

也就是说，生产者线程可以负责把入度为0的节点所表示的模块存入加载队列中。

当然，生产者线程也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

例如，在图2中，生产者线程将节点A所表示的模块A存入加载队列中。

另外，生产者线程只在创建自身的多核子系统上运行，并且只能对支持创建自身的多核子系统的模块进行处理。

例如，在图3中，7(M＝7)个模块分别支持第一多核子系统和第二多核子系统。其中，第一多核子系统中会创建生产者线程(为了便于区分，该生产者线程称为“第一生产者线程”)，第二多核子系统中也会创建生产者线程(为了便于区分，该生产者线程称为“第二生产者线程”)。因此，第一生产者线程只能对模块A、模块B、模块C和模块D进行处理，第二生产者线程只能对模块E、模块F和模块G进行处理。另外，第一多核子系统和第二多核子系统可以是并行工作的。

◆消费者线程

消费者线程，可以用于从加载队列中取出就绪模块，以及对就绪模块进行加载。

也就是说，消费者线程可以负责从加载队列中取出就绪模块，并对就绪模块进行初始化(如加载)。

当然，消费者线程也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

例如，在图2中，若生产者线程将节点A所表示的模块A存入加载队列，则消费者线程从加载队列中取出模块A，并对模块A进行加载。

另外，消费者线程只在创建自身的多核子系统上运行，并且只能对支持创建自身的多核子系统的模块进行处理。

例如，在图3中，7(M＝7)个模块分别支持第一多核子系统和第二多核子系统。其中，第一多核子系统会创建消费者线程(为了便于区分，该消费者线程称为“第一消费者线程”)，第二多核子系统也会创建消费者线程(为了便于区分，该消费者线程称为“第二消费者线程”)。因此，第一消费者线程只能对模块A、模块B、模块C和模块D进行处理，第二消费者线程只能对模块E、模块F和模块G进行处理。另外，第一多核子系统和第二多核子系统可以是并行工作的。

◆跨子系统通信线程

由于生产者线程和消费者线程只能对支持创建自身的多核子系统的模块进行处理，因此为了保证跨子系统的模块的加载，本申请实施例需要有专门的线程(即跨子系统通信线程)来处理跨子系统的模块的加载时相关消息的传输等。

跨子系统通信线程，可以用于维护不同的多核子系统之间的相关消息的传输，以及对跨子系统的模块进行处理。

当然，跨子系统通信线程也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

另外，跨子系统通信线程只在创建自身的多核子系统上运行，而通过不同的多核子系统上的跨子系统通信线程维护不同的多核子系统之间的相关消息的传输。

例如，在图3中，7(M＝7)个模块分别支持第一多核子系统和第二多核子系统。其中，第一多核子系统会创建跨子系统通信线程(为了便于区分，该跨子系统通信线程称为“第一跨子系统通信线程”)，第二多核子系统也会创建跨子系统通信线程(为了便于区分，该跨子系统通信线程称为“第二跨子系统通信线程”)。

由于模块D依赖的模块C和模块F分别支持不同的多核子系统，因此模块D为跨子系统的模块，且模块D需要等待模块C和模块F加载完成，才能进行加载。若模块C加载完成，而模块F还未加载完成，则需要等待模块F的加载。当模块F加载完成时，通过第二跨子系统通信线程向第一跨子系统通信线程发送消息，该消息用于通知第一跨子系统通信线程模块D已加载完成。对此，第一跨子系统通信线程可以模块D的加载进行处理。

另外，由于第一多核子系统和第二多核子系统可以并行工作，因此模块A和模块E可以并行加载，以提高模块加载的效率等。

◆第一消息

第一消息，可以由消费者线程发送给生产者线程，用于通知生产者线程当前的就绪模块已加载完成，需要对依赖该当前的就绪模块的其他模块进行入度处理。

也就是说，在消息者线程已加载完成第一节点所表示的模块的情况下，消费者线程，还可以用于向生产者线程发送第一消息，第一消息可以用于通知生产者线程对第一消息所携带的第二节点(为了便于区分和描述，采用“第二节点”，当然也可以采用其他术语描述)的入度进行处理，第二节点为全局加载依赖关系图中第一节点的子节点，且第二节点和第一节点支持同一个多核子系统。

例如，在图3中，当第一消费者线程完成模块A的加载时，第一消费者线程会向第一生产者发送第一消息，第一消息用于通知第一生产者线程对第一消息所携带的节点B和节点C的入度进行处理。

当然，第一消息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

◆入度处理和第二消息

入度处理，可以是对节点的入度减去1。

也就是说，在消息者线程向生产者线程发送第一消息的情况下，生产者线程，还可以用于接收第一消息，以及对第二节点的入度减去1。此时，存在如下：

一种是：

若第二节点的入度减去1之后为0，则生产者线程，还可以用于将第二节点所表示的模块存入加载队列中；

例如，在图3中，当第一消费者线程完成模块A的加载时，第一消费者线程会向第一生产者发送第一消息，第一消息用于通知第一生产者线程对第一消息所携带的节点B和节点C的入度减去1。由于节点B和节点C的入度减去1之后均为0，因此第一生产者线程会依次将模块B和模块C存入加载队列中。

需要说明是的，是先将模块B存入加载队列，还是将模块C存入加载队列，取决于第一生产者线程的实现，对此不作具体限制。

另一种是：

若第二节点的入度减去1之后不为0，且第二节点还为全局加载依赖关系图中第三节点的子节点，第二节点和第三节点支持不同的多核子系统，则

消费者线程，还可以用于向跨子系统通信线程发送第二消息，第二消息可以用于通知第三节点所表示的模块已加载完成；

跨子系统通信线程，可以用于接收第二消息，以及在第二节点的入度减去1的基础上再减去1。

例如，在图3中，当第一消费者线程完成模块C的加载时，第一消费者线程会向第一生产者发送第一消息，第一消息用于通知第一生产者线程对第一消息所携带的节点D的入度减去1。由于模块D为跨子系统的模块，因此模块D还需要等待模块F的加载完成。

当模块F加载完成时，第二跨子系统通信线程向第一跨子系统通信线程发送第二消息，第二消息用于通知第一跨子系统通信线程模块F已加载完成。对此，第一跨子系统通信线程可以在节点D的入度减去1的基础上再减去1。此时，节点D的入度已为0，并由第一跨子系统通信线程将模块D存入加载队列中。

当然，第二消息也可以采用其他术语描述，只要具有相同的功能/作用/含义/概念等，都在本申请所要求保护的范围内，对此不作具体限制。

◆重新加载模块

需要说明的是，本申请实施例也可以利用生产者线程和消费者线程对模块进行重新加载。

例如，当消费者线程加载某一模块失败时，消费者线程可以向生产者线程发送消息，该消息用于通知该模块加载失败。对此，在生产者线程接收到该消息之后，生产者线程重新将该模型存入加载队列，再由消费者线程从该加载队列中取出该模块以进行该模块的重新加载。

②加载模块管理模块1202

在本申请实施例中，加载模块管理模块1202，可以用于管理模块加载或关闭所需的函数，以及向加载策略模块1201提供该函数等。

③加载服务模块1203

在本申请实施例中，加载服务模块1203，可以用于管理加载线程和加载队列等，以及向加载策略模块1201提供加载线程和加载队列等。

④跨子系统通信模块1204。

在本申请实施例中，跨子系统通信模块1204，可以用于管理跨子系统之间的通信等。

3)示例性说明

下面本申请实施例再结合上述内容对图3中的模块加载的实现流程做一个示例性的说明。

如图6所示，具体实现流程如下：

◆初始化第一加载队列

需要说明的是，加载策略模块1201会在第一多核子系统中对第一加载队列进行初始化(如加载)，便于进行模块的存取。

◆创建第一生产者线程

需要说明的是，加载策略模块1201在第一多核子系统中创建第一生产者线程。

然后，第一生产者线程从图3所示的全局加载依赖关系图的节点A开始，将入度为0的节点A所表示的模块A存入第一加载队列中。

◆创建第一消费者线程

需要说明的是，加载策略模块1201在第一多核子系统中创建第一消费者线程。

然后，第一消费者线程从第一加载队列中取出模块A，加载模块A，以及向第一生产者线程发送消息1。其中，消息1，携带模块B和模块C，用于通知模块A已加载完成，用于通知第一生产者线程对模块B和模块C进行入度处理。

◆接收消息1

需要说明的是，在第一生产者线程接收到消息1之后，第一生产者线程对模块B和模块C进行入度处理。

具体实现时，对节点B的入度(为1)和节点C的入度(为1)减去1。

由于节点B的入度和节点C的入度减去1之后均为0，因此第一生产者线程会依次将模块B和模块C存入第一加载队列中。

需要说明的是，是先将模块B存入第一加载队列，还是将模块C存入第一加载队列，取决于第一生产者线程的实现，对此不作具体限制。

◆加载模块B和模块C

需要说明的是，在第一生产者线程依次将模块B和模块C存入第一加载队列之后，第一消费者线程会从第一加载队列中取出模块B，并加载模块B。在加载完成模块B之后，第一消费者线程会从第一加载队列中取出模块C，加载模块C，在加载完成模块C之后，向第一生产者线程发送消息2。其中，消息2，携带模块D，用于通知模块B和模块C已加载完成，用于通知第一生产者线程对模块D进行入度处理。

◆接收消息2

需要说明的是，在第一生产者线程接收到消息2之后，第一生产者线程对模块D进行入度处理。

具体实现时，对节点D的入度(为2)减去1。

由于模块D为跨子系统的模块，因此模块D还需要等待模块F的加载完成。

当然也有可能是模块F先加载完成，因此模块D会等待模块的加载完成，对此不作具体限制。

◆初始化第二加载队列

需要说明的是，加载策略模块1201会在第二多核子系统中对第二加载队列进行初始化(如加载)，便于进行模块的存取。

另外，“初始化第二加载队列”的过程可以与“初始化第一加载队列”的过程并行。

◆创建第二生产者线程

需要说明的是，加载策略模块1201在第二多核子系统中创建第二生产者线程。

然后，第二生产者线程从图3所示的全局加载依赖关系图的节点E开始，将入度为0的节点E所表示的模块E存入第二加载队列中。

另外，“创建第二生产者线程”的过程可以与“创建第一生产者线程”的过程并行。

◆创建第二消费者线程

需要说明的是，加载策略模块1201在第二多核子系统中创建第二消费者线程。

然后，第二消费者线程从第二加载队列中取出模块E，加载模块E，以及向第二生产者线程发送消息3。其中，消息3，携带模块F和模块G，用于通知模块E已加载完成，用于通知第二生产者线程对模块F和模块G进行入度处理。

另外，“创建第二消费者线程”的过程可以与“创建第一消费者线程”的过程并行。

◆接收消息3

需要说明的是，在第二生产者线程接收到消息3之后，第二生产者线程对模块F和模块G进行入度处理。

具体实现时，对节点F的入度(为1)和节点G的入度(为1)减去1。

由于节点F的入度和节点G的入度减去1之后均为0，因此第二生产者线程会依次将模块F和模块G存入第二加载队列中。

需要说明的是，是先将模块F存入第二加载队列，还是将模块G存入第二加载队列，取决于第二生产者线程的实现，对此不作具体限制。

◆加载模块F和模块G

需要说明的是，在第二生产者线程依次将模块F和模块G存入第二加载队列之后，第二消费者线程会从第二加载队列中取出模块F，并加载模块F。在加载完成模块F之后，第二消费者线程会从第二加载队列中取出模块G，加载模块G。

◆创建第二跨子系统通信线程

需要说明的是，加载策略模块1201在第二多核子系统中创建第二跨子系统通信线程。

◆创建第一跨子系统通信线程

需要说明的是，加载策略模块1201在第一多核子系统中创建第一跨子系统通信线程。

◆发送消息4

需要说明的是，当模块F加载完成时，第二消费者线程会向第二跨子系统通信线程发送消息4。其中，消息4用于通知模块F已加载完成。

◆发送消息5

在第二跨子系统通信线程接收到消息4之后，第二跨子系统通信线程会向第一跨子系统通信线程发送消息5。其中，消息5，用于通知模块F已加载完成，用于通知第一跨子系统通信线程对模块D进行入度处理。

◆接收消息5

需要说明的是，在第一跨子系统通信线程接收到消息5之后，第一跨子系统通信线程对模块D进行入度处理。

具体实现时，在节点D的入度减去1的基础上再减去1。此时，节点D的入度已为0，因此，第一跨子系统通信线程将模块D存入第一加载队列中。

◆加载模块D

需要说明的是，在第一跨子系统通信线程将模块D存入第一加载队列之后，第一消费者线程会从第一加载队列中取出模块D，并加载模块D。

总之，模块的加载从全局加载依赖关系图的父节点向子节点依次进行。对应的，模块的关闭从全局加载依赖关系图的子节点向父节点依次进行。

四、一种用于模块加载的方法的示例性说明

结合上述对编译时所需执行的步骤，对本申请实施例的一种用于模块加载的方法进行示例性说明。

如图7所示，图7是本申请实施例的一种用于模块加载的方法的流程示意图，可以应用于电子设备，该电子设备可以包括专门工具。该方法具体可以包括如下步骤：

S710、根据配置文件生成可编译文件，可编译文件包含全局依赖关系信息，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，可编译文件用于加载M个模块，配置文件包含多个单向模块依赖描述信息，单向模块依赖描述信息用于描述一个模块与其他模块之间的局部加载依赖关系，模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。

需要说明的是，“配置文件”、“模块”、“全局加载依赖关系”、“局部加载依赖关系”、“模块加载描述信息”等可以详见上述相关的内容和描述，对此不再赘述。

另外，在S710之前，该方法还可以包括：获取配置文件。

可见，本申请实施例可以通过配置文件中的单向模块加载描述信息来描述一个模块与其他模块之间的局部加载依赖关系，实现直接显式配置单个模块之间的局部加载依赖关系，从而通过直接显式配置使得各个模块之间的局部加载依赖关系更加简洁、清晰和灵活；根据配置文件生成可编译文件，实现根据单个模块之间的局部加载依赖关系确定整个模块之间的全局加载依赖关系，以及实现从单个模块的局部角度到整个模块的全局角度来生成M个模块之间的全局加载依赖关系，以便通过全局加载依赖关系实现从全局角度上快速深度遍历或广度优先遍历M个模块以进行加载，从而有利于提高模块加载的效率、可靠性和灵活性。

在一些可能的实现中，配置文件还可以包含以下至少一项：多个单向模块名字描述信息、多个单向模块标识符描述信息、多个单向模块所支持子系统描述信息；

单向模块名字描述信息，用于描述一个模块自身的名字；

单向模块标识符描述信息，用于描述一个模块自身的标识符；

单向模块所支持子系统描述信息，用于描述一个模块自身所支持的多核子系统。

可见，本申请实施例通过单向模块名字描述信息所描述的名字可以对模块进行快速查找、检索等操作，有利于提高模块查找效率。

另外，本申请实施例通过单向模块标识符描述信息所描述的标识符可以对模块进行快速查找、检索等操作，有利于提高模块查找效率。通过单向模块所支持子系统描述信息可以确定模块所需加载到哪些多核子系统上，有利于保证模块的正确加载。

在一些可能的实现中，不同的模块之间所支持的多核子系统是不同的；不同的多核子系统之间支持并行工作。

可见，本申请实施例可以支持多个多核子系统的模块的加载。

另外，由于不同的多核子系统之间可以支持并行工作，因此支持不同的多核子系统的模块可以实现并行加载，从而有利于提高模块加载的效率。

在一些可能的实现中，M个模块之间的全局加载依赖关系由全局加载依赖关系图表示；全局加载依赖关系图包括M个节点和至少一条边，一个节点用于表示M个模块中的一个，一条边用于表示该边的两端节点存在局部加载依赖关系。

在一些可能的实现中，可编译文件还包含度信息、列表信息中的至少一项；

度信息，用于描述全局加载依赖关系图中的M个节点各自的入度和出度，入度用于表示节点的入边条数，出度用于表示节点的出边条数；

列表信息，用于描述支持同一个多核子系统下的所有模块各自的标识符所组成的列表。

可见，本申请实施例通过度信息所描述的入度和出度来深度遍历或广度优先遍历全局加载依赖关系图中的各个节点，以便后续进行M个模块的加载或关闭。

另外，本申请实施例可以利用模块的标识符，直接在列表信息所描述的列表中对不同的多核子系统下的模块进行查找和检索等，从而有利于提高跨子系统加载时模块查找的效率。

在一些可能的实现中，入度可以用于进行模块的加载，出度可以用于进行模块的关闭。

在一些可能的实现中，全局加载依赖关系图是经过冗余边删除处理的，冗余边删除处理可以用于减少全局加载依赖关系图中的节点之间多余的局部加载依赖关系。

可见，通过去掉冗余边，生成一个最小化的全局加载依赖关系图，使得模块之间的加载依赖关系更加简洁和清晰，从而不仅有利于减少对全局加载依赖关系图中所有节点的遍历时间，还有利于提高模块加载的效率、可靠性。

在一些可能的实现中，全局加载依赖关系图是经过环路检测处理的，环路检测处理可以用于对全局加载依赖关系图进行检测以判断是否存在闭合的环路。

可见，通过删除闭合的环路，能够避免模块之间的不正确的依赖，从而不仅有利于保证模块的正确加载，还有利于提高模块加载的效率和可靠性。

五、又一种用于模块加载的方法的示例性说明

结合上述对有运行时所需执行的步骤，对本申请实施例的又一种用于模块加载的方法进行示例性说明。

如图8所示，图8是本申请实施例的又一种用于模块加载的方法的流程示意图，可以应用于电子设备，该电子设备可以包括加载框架。该方法具体可以包括如下步骤：

S810、创建加载队列和加载线程，加载队列用于存放模块，加载线程用于维护加载队列以进行模块的加载，模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务。

其中，维护加载队列，可以包括将模块存入加载队列，以及从加载队列中取出模块。

需要说明的是，“加载队列”、“加载线程”等可以详见上述相关的内容和描述，对此不再赘述。

另外，在S810之前，该方法还可以包括：获取可编译文件。

S820、控制加载队列和加载线程以根据可编译文件对M个模块进行加载，可编译文件包含全局依赖关系信息，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，M为大于1的整数。

需要说明的是，“可编译文件”、“全局依赖关系信息”、“全局加载依赖关系”等可以详见上述相关的内容和描述，对此不再赘述。

可见，本申请实施例引入了加载队列和加载线程，并通过控制加载线程来维护加载队列以根据可编译文件对M个模块进行高效、灵活的加载，从而有利于实现模块加载的高效率、高可靠性和高灵活性的可能性。

在一些可能的实现中，M个模块之间的全局加载依赖关系由全局加载依赖关系图表示；

全局加载依赖关系图包括M个节点和至少一条边，一个节点用于表示M个模块中的一个，一条边用于表示该边的两端节点存在局部加载依赖关系。

在一些可能的实现中，可编译文件还可以包含度信息；

度信息，用于描述全局加载依赖关系图中的M个节点各自的入度和出度，入度用于表示节点的入边条数，出度用于表示节点的出边条数。

可见，本申请实施例通过度信息所描述的入度和出度来深度遍历或广度优先遍历全局加载依赖关系图中的各个节点，以便后续进行M个模块的加载或关闭。

在一些可能的实现中，加载线程包含生产者线程和消费者线程；

生产者线程，用于将就绪模块存入加载队列中，就绪模块为第一节点所表示的模块，第一节点是全局加载依赖关系图中入度为0的节点；

消费者线程，用于从加载队列中取出就绪模块，以及对就绪模块进行加载。

可见，通过生产者线程负责将就绪模块存入加载队列，再由消费者线程负责从加载队列中取出就绪模块以进行加载，从而通过生产者线程和消费者线程的方式来维护加载队列，实现高效、灵活的加载模块。

在一些可能的实现中，S820中的控制加载队列和加载线程以根据可编译文件对M个模块进行加载，可以包括如下步骤：

控制生产者线程，将就绪模块存入加载队列中；

控制消费者线程，从加载队列中取出就绪模块，以及对就绪模块进行加载。

可见，通过生产者线程负责将就绪模块存入加载队列，再由消费者线程负责从加载队列中取出就绪模块以进行加载，从而通过生产者线程和消费者线程的方式来维护加载队列，实现高效、灵活的加载模块。

在一些可能的实现中，消费者线程，还用于向生产者线程发送第一消息；

第一消息用于通知生产者线程对第一消息所携带的第二节点的入度进行处理；

第二节点是全局加载依赖关系图中第一节点的子节点，且第二节点和第一节点支持同一个多核子系统。

可见，通过第一消息实现消费者线程和生产者线程之间的通信，使得在消费者线程已加载完成第一节点所表示的模块的情况下，通过第一消息来通知生产者线程对第二节点进行入度处理，以便后续实现对第二节点所表示的模块进行加载。

在一些可能的实现中，生产者线程，还用于接收第一消息，以及对第二节点的入度减去1。

可见，在消息者线程向生产者线程发送第一消息的情况下，生产者线可以对第一消息所携带的第二节点的入度减去1，从而实现对第二节点进行入度处理，以便后续实现对第二节点所表示的模块进行加载。

在一些可能的实现中，若第二节点的入度减去1之后为0，则生产者线程，还用于将第二节点所表示的模块存入加载队列中。

可见，生产者线可以将第二节点所表示的模块存入加载队列中，以便后续消费者线程从加载队列中取出第二节点所表示的模块，从而实现对该模块的加载。

在一些可能的实现中，若第二节点的入度减去1之后不为0，且第二节点还为全局加载依赖关系图中第三节点的子节点，第二节点和第三节点支持不同的多核子系统，则

加载线程还包含跨子系统通信线程；

消费者线程，还用于向跨子系统通信线程发送第二消息，第二消息用于通知第三节点所表示的模块已加载完成；

跨子系统通信线程，用于接收第二消息，以及在第二节点的入度减去1的基础上再减去1。

需要说明的是，由于生产者线程和消费者线程只能对支持创建自身的多核子系统的模块进行处理，因此为了保证跨子系统的模块的加载，本申请实施例引入跨子系统通信线程来处理跨子系统的模块的加载时第二消息的传输。

可见，通过第二消息实现消费者线程和跨子系统通信线程之间的通信，使得在消费者线程已加载完成第三节点所表示的模块的情况下，通过第二消息来通知跨子系统通信线程第三节点所表示的模块已加载完成，使得跨子系统通信线程可以对第二节点再进行入度处理，以便后续实现对第二节点所表示的模块进行加载。

在一些可能的实现中，可编译文件还包含列表信息；

列表信息，用于描述支持同一个多核子系统下的所有模块各自的标识符所组成的列表。

可见，本申请实施例可以利用模块的标识符，直接在列表信息所描述的列表中对不同的多核子系统下的模块进行查找和检索等，从而有利于提高跨子系统加载时模块查找的效率。

六、一种用于模块加载的装置的示例性说明

上述主要从方法侧执行过程的角度对本申请实施例的方案进行了介绍。可以理解的是，设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该知悉，结合本文中所提供的实施例描述的各示例的方法、功能、模块、单元或者步骤，本申请能够以硬件或者硬件与计算机软件的结合形式来实现。某个方法、功能、模块、单元或者步骤究竟以硬件或计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用使用不同方法来实现所描述的方法、功能、模块、单元或者步骤，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对电子设备进行功能单元/模块的划分。例如，可以对应各个功能划分各个功能单元/模块，也可以将两个或两个以上的功能集成在一个功能单元/模块中。上述集成的功能单元/模块既可以采用硬件的方式实现，也可以采用软件程序的方式实现。需要说明的是，本申请实施例中对功能单元/模块的划分是示意性的，只是一种逻辑功能划分，而实际实现时可以有另外的划分方式。

在采用集成的单元的情况下，图9是本申请实施例的一种用于模块加载的装置的功能单元组成框图。用于模块加载的装置900，具体包括：生成单元910。

需要说明的是，生成单元910可以是一种用于处理信号、数据、信息等的模块单元，对此不作具体限制。

在一些可能的实现中，生成单元910可以集成在处理单元中。

需要说明的是，处理单元可以是处理器或控制器，例如可以是中央处理器(central processing unit，CPU)、通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application-specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框、模块和电路。处理单元也可以是实现计算功能的组合，例如包含一个或多个微处理器组合、DSP和微处理器的组合等。

在一些可能的实现中，用于模块加载的装置900还可以包括获取单元。其中，获取单元可以用于获取配置文件。

需要说明的是，获取单元可以是一种用于获取或处理信号、数据、信息等的模块单元，对此不作具体限制。

在一些可能的实现中，获取单元和生成单元910可以是相互分离的，可以是集成在同一个单元中。

例如，若获取单元和生成单元910集成在同一个单元中，则获取单元和生成单元910可以集成在处理单元中。

又例如，获取单元可以集成在通信单元中，生成单元910可以集成在处理单元中。

需要说明的是，通信单元可以是通信接口、收发器、收发电路等。

在一些可能的实现中，用于模块加载的装置900还可以包括存储单元，用于存储用于模块加载的装置900所执行的计算机程序或者指令。

例如，该存储单元可以是存储器。

在一些可能的实现中，用于模块加载的装置900可以是芯片/芯片模组/处理器/硬件/操作系统/专门工具等。

具体实现时，用于模块加载的装置900用于执行如上述方法实施例中所描述的步骤。下面进行详细说明。

生成单元910，用于根据配置文件生成可编译文件，可编译文件包含全局依赖关系信息，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，可编译文件用于加载M个模块，配置文件包含多个单向模块依赖描述信息，单向模块依赖描述信息用于描述一个模块与其他模块之间的局部加载依赖关系，模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。

需要说明的是，用于模块加载的装置900执行的各个操作的具体实现可以参见上述图7所示的方法实施例的相应描述，在此不再赘述。

可见，本申请实施例可以通过配置文件中的单向模块加载描述信息来描述一个模块与其他模块之间的局部加载依赖关系，实现直接显式配置单个模块之间的局部加载依赖关系，从而通过直接显式配置使得单个模块之间的局部加载依赖关系更加简洁、清晰和灵活；根据配置文件生成可编译文件，实现根据单个模块之间的局部加载依赖关系确定整个模块之间的全局加载依赖关系，以及实现从单个模块的局部角度到整个模块的全局角度来生成M个模块之间的全局加载依赖关系，以便通过全局加载依赖关系实现从全局角度上快速深度遍历或广度优先遍历M个模块以进行加载，从而有利于提高模块加载的效率、可靠性和灵活性。

在一些可能的实现中，配置文件还包含以下至少一项：多个单向模块名字描述信息、多个单向模块标识符描述信息、多个单向模块所支持子系统描述信息；

单向模块名字描述信息，用于描述一个模块自身的名字；

单向模块标识符描述信息，用于描述一个模块自身的标识符；

单向模块所支持子系统描述信息，用于描述一个模块自身所支持的多核子系统。

在一些可能的实现中，不同的模块之间所支持的多核子系统是不同的；不同的多核子系统之间支持并行工作。

在一些可能的实现中，M个模块之间的全局加载依赖关系由全局加载依赖关系图表示；全局加载依赖关系图包括M个节点和至少一条边，一个节点用于表示M个模块中的一个，一条边用于表示该边的两端节点存在局部加载依赖关系。

在一些可能的实现中，可编译文件还包含度信息、列表信息中的至少一项；

度信息，用于描述全局加载依赖关系图中的M个节点各自的入度和出度，入度用于表示节点的入边条数，出度用于表示节点的出边条数；

列表信息，用于描述支持同一个多核子系统下的所有模块各自的标识符所组成的列表。

在一些可能的实现中，全局加载依赖关系图是经过冗余边删除处理的，冗余边删除处理用于减少全局加载依赖关系图中的节点之间多余的局部加载依赖关系。

在一些可能的实现中，全局加载依赖关系图是经过环路检测处理的，环路检测处理用于序对全局加载依赖关系图进行检测以判断是否存在闭合的环路。

七、又一种用于模块加载的装置的示例性说明

在采用集成的单元的情况下，图10是本申请实施例的又一种用于模块加载的装置的功能单元组成框图。用于模块加载的装置1000，具体包括：创建单元1010和加载单元1020。

需要说明的是，

创建单元1010可以是一种用于处理信号、数据、信息等的模块单元，对此不作具体限制。

加载单元1020可以是一种用于处理信号、数据、信息等的模块单元，对此不作具体限制。

在一些可能的实现中，创建单元1010和加载单元1020可以是相互分离的，可以是集成在同一个单元中。

例如，若创建单元1010和加载单元1020集成在同一个单元中，则创建单元1010和加载单元1020可以集成在处理单元中。

需要说明的是，处理单元可以是处理器或控制器，例如可以是中央处理器(central processing unit，CPU)、通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application-specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框、模块和电路。处理单元也可以是实现计算功能的组合，例如包含一个或多个微处理器组合、DSP和微处理器的组合等。

在一些可能的实现中，用于模块加载的装置1000还可以包括获取单元，该获取单元用于获取可编译文件。

需要说明的是，获取单元可以是一种用于处理信号、数据、信息等的模块单元，对此不作具体限制。

又例如，获取单元可以集成在通信单元中。

需要说明的是，通信单元可以是通信接口、收发器、收发电路等。

在一些可能的实现中，用于模块加载的装置1000还可以包括存储单元，用于存储用于模块加载的装置1000所执行的计算机程序或者指令。

例如，该存储单元可以是存储器。

在一些可能的实现中，用于模块加载的装置1000可以是芯片/芯片模组/处理器/硬件/操作系统/加载架构等。

具体实现时，用于模块加载的装置1000用于执行如上述方法实施例中所描述的步骤。下面进行详细说明。

创建单元1010，用于创建加载队列和加载线程，加载队列用于存放模块，加载线程用于维护加载队列以进行模块的加载，模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务；

加载单元1020，用于控制加载队列和加载线程以根据可编译文件对M个模块进行加载，可编译文件包含全局依赖关系信息，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，M为大于1的整数。

可见，本申请实施例引入了加载队列和加载线程，并通过控制加载线程来维护加载队列以根据可编译文件对M个模块进行高效、灵活的加载，从而有利于实现模块加载的高效率、高可靠性和高灵活性的可能性。

需要说明的是，用于模块加载的装置1000执行的各个操作的具体实现可以参见上述图8所示的方法实施例的相应描述，在此不再赘述。

在一些可能的实现中，M个模块之间的全局加载依赖关系由全局加载依赖关系图表示；

全局加载依赖关系图包括M个节点和至少一条边，一个节点用于表示M个模块中的一个，一条边用于表示该边的两端节点存在局部加载依赖关系。

在一些可能的实现中，可编译文件还包含度信息；

度信息，用于描述全局加载依赖关系图中的M个节点各自的入度和出度，入度用于表示节点的入边条数，出度用于表示节点的出边条数。

在一些可能的实现中，加载线程包含生产者线程和消费者线程；

生产者线程，用于将就绪模块存入加载队列中，就绪模块为第一节点所表示的模块，第一节点是全局加载依赖关系图中入度为0的节点；

消费者线程，用于从加载队列中取出就绪模块，以及对就绪模块进行加载。

在一些可能的实现中，在控制加载队列和加载线程以根据可编译文件对M个模块进行加载方面，加载单元1030用于：

控制生产者线程，将就绪模块存入加载队列中；

控制消费者线程，从加载队列中取出就绪模块，以及对就绪模块进行加载。

在一些可能的实现中，消费者线程，还用于向生产者线程发送第一消息；

第一消息用于通知生产者线程对第一消息所携带的第二节点的入度进行处理；

第二节点是全局加载依赖关系图中第一节点的子节点，且第二节点和第一节点支持同一个多核子系统。

在一些可能的实现中，生产者线程，还用于接收第一消息，以及对第二节点的入度减去1。

在一些可能的实现中，若第二节点的入度减去1之后为0，则生产者线程，还用于将第二节点所表示的模块存入加载队列中。

在一些可能的实现中，若第二节点的入度减去1之后不为0，且第二节点还为全局加载依赖关系图中第三节点的子节点，第二节点和第三节点支持不同的多核子系统，则

加载线程还包含跨子系统通信线程；

消费者线程，还用于向跨子系统通信线程发送第二消息，第二消息用于通知第三节点所表示的模块已加载完成；

跨子系统通信线程，用于接收第二消息，以及在第二节点的入度减去1的基础上再减去1。

在一些可能的实现中，可编译文件还包含列表信息；

列表信息，用于描述支持同一个多核子系统下的所有模块各自的标识符所组成的列表。

八、一种电子设备的示例性说明

下面介绍本申请实施例的一种电子设备的结构示意图，如图11所示。其中，电子设备1100包括处理器1110、存储器1120和至少一个用于连接处理器1110、存储器1120的通信总线。

在一些可能的实现中，处理器1110可以是一个或多个中央处理器CPU。在处理器1110是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。存储器1120包括但不限于是随机存储记忆体(random access memory,RAM)、只读存储器(read-only memory,ROM)、可擦除可编程只读存储器(erasable programmable read only memory,EPROM)或便携式只读存储器(compact disc read-only memory,CD-ROM)，并且存储器1120用于存储计算机程序或指令。

在一些可能的实现中，电子设备1100还包括通信接口，该通信接口用于接收和发送数据。

在一些可能的实现中，电子设备1100中的处理器1110用于执行存储器1120中存储的计算机程序或指令1121以实现如下步骤：

根据配置文件生成可编译文件，可编译文件包含全局依赖关系信息，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，可编译文件用于加载M个模块，配置文件包含多个单向模块依赖描述信息，单向模块依赖描述信息用于描述一个模块与其他模块之间的局部加载依赖关系，模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。

需要说明的是，电子设备1100执行的各个操作的具体实现可以参见上述图7所示的方法实施例的相应描述，在此不再赘述。

九、又一种电子设备的示例性说明

下面介绍本申请实施例的又一种电子设备的结构示意图，如图12所示。其中，电子设备1200包括处理器1210、存储器1220和至少一个用于连接处理器1210、存储器1220的通信总线。

在一些可能的实现中，处理器1210可以是一个或多个中央处理器CPU。在处理器1210是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。存储器1220包括但不限于是随机存储记忆体(random access memory,RAM)、只读存储器(read-only memory,ROM)、可擦除可编程只读存储器(erasable programmable read only memory,EPROM)或便携式只读存储器(compact disc read-only memory,CD-ROM)，并且存储器1220用于存储计算机程序或指令。

在一些可能的实现中，电子设备1200还包括通信接口，该通信接口用于接收和发送数据。

在一些可能的实现中，电子设备1200中的处理器1210用于执行存储器1220中存储的计算机程序或指令1221以实现如下步骤：

创建加载队列和加载线程，加载队列用于存放模块，加载线程用于维护加载队列以进行模块的加载，模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务；

控制加载队列和加载线程以根据可编译文件对M个模块进行加载，可编译文件包含全局依赖关系信息，全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，M为大于1的整数。

需要说明的是，电子设备1200执行的各个操作的具体实现可以参见上述图8所示的方法实施例的相应描述，在此不再赘述。

十、其他示例性说明

本申请实施例还提供一种计算机可读存储介质，其中，该计算机可读存储介质上存储有计算机程序或指令，该计算机程序或指令被处理器执行时以实现上述实施例中所描述的步骤。

本申请实施例还提供一种计算机程序产品，包括计算机程序或指令，其中，该计算机程序或指令被处理器执行时以实现上述实施例中所描述的步骤。示例性的，该计算机程序产品可以为一个软件安装包。

另外，计算机程序产品，应理解为，主要通过计算机程序或指令实现解决本申请的技术方案的软件产品。

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

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

本领域技术人员应该知悉，本申请实施例所描述的方法、步骤或者相关模块/单元的功能可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式来实现，也可以是由处理器执行计算机程序指令的方式来实现。其中，该计算机程序产品包括至少一个计算机程序指令，计算机程序指令可以由相应的软件模块组成，软件模块可以被存放于RAM、闪存、ROM、EPROM、EEPROM、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。该计算机程序指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。例如，该计算机程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质、或者半导体介质(如SSD)等。

上述实施例中描述的各个装置或产品包含的各个模块/单元，其可以是软件模块/单元，可以是硬件模块/单元，也可以一部分是软件模块/单元，而另一部分是硬件模块/单元。例如，对于应用于或集成于芯片的各个装置或产品，其包含的各个模块/单元可以都采用电路等硬件的方式实现；或者，其包含的一部分模块/单元可以采用软件程序的方式实现，该软件程序运行于芯片内部集成的处理器，而另一部分(如果有)的部分模块/单元可以采用电路等硬件方式实现。对于应用于或集成于芯片模组的各个装置或产品，或者应用于或集成于终端的各个装置或产品，同理可知。

以上的具体实施方式，对本申请实施例的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本申请实施例的具体实施方式而已，并不用于限定本申请实施例的保护范围。凡在本申请实施例的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请实施例的保护范围之内。

Claims (20)

1.一种用于模块加载的方法，其特征在于，包括：

根据配置文件生成可编译文件，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，所述可编译文件用于加载M个所述模块，所述配置文件包含多个单向模块依赖描述信息，所述单向模块依赖描述信息用于描述一个所述模块与其他所述模块之间的局部加载依赖关系，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。

2.根据权利要求1所述的方法，其特征在于，所述配置文件还包含以下至少一项：多个单向模块名字描述信息、多个单向模块标识符描述信息、多个单向模块所支持子系统描述信息；

所述单向模块名字描述信息，用于描述一个所述模块自身的名字；

所述单向模块标识符描述信息，用于描述一个所述模块自身的标识符；

所述单向模块所支持子系统描述信息，用于描述一个所述模块自身所支持的多核子系统。

3.根据权利要求1所述的方法，其特征在于，不同的所述模块之间所支持的多核子系统是不同的；

不同的所述多核子系统之间支持并行工作。

4.根据权利要求1所述的方法，其特征在于，M个所述模块之间的全局加载依赖关系由全局加载依赖关系图表示；

所述全局加载依赖关系图包括M个节点和至少一条边，一个节点用于表示M个所述模块中的一个，一条边用于表示所述边的两端节点存在局部加载依赖关系。

5.根据权利要求4所述的方法，其特征在于，所述可编译文件还包含度信息、列表信息中的至少一项；

所述度信息，用于描述所述全局加载依赖关系图中的M个节点各自的入度和出度，所述入度用于表示节点的入边条数，所述出度用于表示节点的出边条数；

所述列表信息，用于描述支持同一个多核子系统下的所有所述模块各自的标识符所组成的列表。

6.根据权利要求4所述的方法，其特征在于，所述全局加载依赖关系图是经过冗余边删除处理的，所述冗余边删除处理用于减少所述全局加载依赖关系图中的节点之间多余的局部加载依赖关系。

7.根据权利要求4所述的方法，其特征在于，所述全局加载依赖关系图是经过环路检测处理的，所述环路检测处理用于对所述全局加载依赖关系图进行检测以判断是否存在闭合的环路。

8.一种用于模块加载的方法，其特征在于，包括：

创建加载队列和加载线程，所述加载队列用于存放模块，所述加载线程用于维护所述加载队列以进行所述模块的加载，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务；

控制所述加载队列和所述加载线程以根据可编译文件对M个所述模块进行加载，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个所述模块之间的全局加载依赖关系，M为大于1的整数。

9.根据权利要求8所述的方法，其特征在于，M个所述模块之间的全局加载依赖关系由全局加载依赖关系图表示；

所述全局加载依赖关系图包括M个节点和至少一条边，一个节点用于表示M个所述模块中的一个，一条边用于表示所述边的两端节点存在局部加载依赖关系。

10.根据权利要求9所述的方法，其特征在于，所述可编译文件还包含度信息；

所述度信息，用于描述所述全局加载依赖关系图中的M个节点各自的入度和出度，所述入度用于表示节点的入边条数，所述出度用于表示节点的出边条数。

11.根据权利要求9所述的方法，其特征在于，所述加载线程包含生产者线程和消费者线程；

所述生产者线程，用于将就绪模块存入所述加载队列中，所述就绪模块为第一节点所表示的所述模块，所述第一节点是所述全局加载依赖关系图中所述入度为0的节点；

所述消费者线程，用于从所述加载队列中取出所述就绪模块，以及对所述就绪模块进行加载。

12.根据权利要求11所述的方法，其特征在于，所述控制所述加载队列和所述加载线程以根据可编译文件对M个所述模块进行加载，包括：

控制所述生产者线程，将所述就绪模块存入所述加载队列中；

控制所述消费者线程，从所述加载队列中取出所述就绪模块，以及对所述就绪模块进行加载。

13.根据权利要求11所述的方法，其特征在于，所述消费者线程，还用于向所述生产者线程发送第一消息；

所述第一消息用于通知所述生产者线程对所述第一消息所携带的第二节点的所述入度进行处理；

所述第二节点是所述全局加载依赖关系图中所述第一节点的子节点，且所述第二节点和所述第一节点支持同一个多核子系统。

14.根据权利要求11所述的方法，其特征在于，所述生产者线程，还用于接收所述第一消息，以及对所述第二节点的所述入度减去1。

15.根据权利要求14所述的方法，其特征在于，若所述第二节点的所述入度减去1之后为0，则所述生产者线程，还用于将所述第二节点所表示的所述模块存入所述加载队列中。

16.根据权利要求14所述的方法，其特征在于，若所述第二节点的所述入度减去1之后不为0，且所述第二节点还为所述全局加载依赖关系图中第三节点的子节点，所述第二节点和所述第三节点支持不同的多核子系统，则

所述加载线程还包含跨子系统通信线程；

所述消费者线程，还用于向所述跨子系统通信线程发送第二消息，所述第二消息用于通知所述第三节点所表示的所述模块已加载完成；

所述跨子系统通信线程，用于接收所述第二消息，以及在所述第二节点的所述入度减去1的基础上再减去1。

17.一种用于模块加载的装置，其特征在于，包括：

生成单元，用于根据配置文件生成可编译文件，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个模块之间的全局加载依赖关系，所述可编译文件用于加载M个所述模块，所述配置文件包含多个单向模块依赖描述信息，所述单向模块依赖描述信息用于描述一个所述模块与其他所述模块之间的局部加载依赖关系，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务，M为大于1的整数。

18.一种用于模块加载的装置，其特征在于，包括：

创建单元，用于创建加载队列和加载线程，所述加载队列用于存放模块，所述加载线程用于维护所述加载队列以进行所述模块的加载，所述模块包括用于驱动硬件的软件驱动程序和/或用于提供特定功能的软件服务；

加载单元，用于控制所述加载队列和所述加载线程以根据可编译文件对M个所述模块进行加载，所述可编译文件包含全局依赖关系信息，所述全局依赖关系信息用于描述M个所述模块之间的全局加载依赖关系，M为大于1的整数。

19.一种电子设备，包括处理器、存储器及存储在所述存储器上的计算机程序或指令，其特征在于，所述处理器执行所述计算机程序或指令以实现权利要求1-7或8-16中任一项所述方法的步骤。

20.一种计算机可读存储介质，其特征在于，其存储有计算机程序或指令，所述计算机程序或指令被执行时实现权利要求1-7或8-16中任一项所述方法的步骤。

Images