CN117573138A - 一种编译处理方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请实施例公开了一种编译处理方法、装置、存储介质及电子设备，其中，方法包括：确定针对宿主的至少一个依赖插件，获取针对依赖插件的至少一个插件清单信息数据，依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库，对依赖插件的插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，基于目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对宿主的程序运行文件。

Description

一种编译处理方法、装置、存储介质及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种编译处理方法、装置、存储介质及电子设备。

背景技术

插件化编译是一种用于应用程序开发的方式，插件化编译可以将应用程序的功能模块以插件的形式单独开发和编译，并在运行时动态加载到宿主应用程序中。

目前插件化编译采用了将插件和宿主的代码放在同一个代码仓库，在同一代码仓库中进行联合编译以及编译整合的方式进行应用程序相关的插件开发，插件化编译的方式为应用程序的开发带来了更大的灵活性和扩展性，使得可以更好地组织和管理应用程序的功能模块。

发明内容

本申请实施例提供了一种编译处理方法、装置、存储介质及电子设备，所述技术方案如下：

第一方面，本申请实施例提供了一种编译处理方法，所述方法包括：

确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，所述依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据；

基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

第二方面，本申请实施例提供了一种编译处理装置，所述装置包括：

数据获取模块，用于确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，所述依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

数据处理模块，用于对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据；

文件整合模块，用于基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

第三方面，本申请实施例提供一种计算机存储介质，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行上述的方法步骤。

第四方面，本申请实施例提供一种电子设备，可包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行上述的方法步骤。

本申请一些实施例提供的技术方案带来的有益效果至少包括：

在本说明书一个或多个实施例中，电子设备可以确定针对宿主的至少一个依赖插件，获取针对依赖插件的至少一个插件清单信息数据，依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库，对依赖插件的插件清单信息数据进行校验合并处理得到目标插件清单信息数据，然后集合目标插件清单信息数据对依赖插件进行编译整合处理得到针对宿主的程序运行文件，相对于原有将宿主代码和所有插件代码放在同一代码仓库中进行编译处理方式而言，通过设置独立插件降低了共仓的代码耦合度，便于插件代码版本以及宿主代码版本管理，在设置独立插件的情形下引入对所有依赖插件的插件清单信息校验合并以及编译整合，可以确保插件编译处理顺利进行，降低了编译过程中处理冲突现象提高了独立插件的兼容性，也即在插件编译时可以突破宿主的依赖插件来源限制，选择合适的非共仓插件进行接入，提高了插件编译的多样性以及便利化程度，且对于独立插件而言可以被多个宿主同时依赖并可确保插件成功编译处理，提高了插件的复用程度。

附图说明

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

图1是本申请实施例提供的一种编译处理方法的流程示意图；

图2是本申请实施例提供的一种编译处理方法的流程示意图；

图3是本申请实施例提供的一种独立插件处理的示意图；

图4是本申请实施例提供的一种共仓插件处理的示意图；

图5是本申请实施例提供的一种编译处理方法的另一种实施例的流程示意图；

图6是本申请实施例提供的一种编译处理装置的结构示意图；

图7是本申请实施例提供的一种数据获取模块的结构示意图；

图8是本申请实施例提供的一种数据处理模块的结构示意图；

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

图10是本申请实施例提供的操作系统和用户空间的结构示意图；

图11是图10中安卓操作系统的架构图；

图12是图10中IOS操作系统的架构图。

具体实施方式

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

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

在相关技术中，将宿主代码和插件代码放在同一代码仓库中，一方面，代码耦合度高：宿主和插件的代码有可能会产生交叉引用，这样会使得代码之间的耦合度变高，增加维护成本。另一方面，版本管理困难：一旦需要对宿主或插件进行版本更新，就需要同时更新整个仓库，而不能只更新其中某一部分。另一方面，安全性问题：同一个仓库中的插件代码可能会访问宿主代码中的敏感信息，从而引发安全性问题。

基于此，可见相关技术中的编译处理方式存在一定的局限性，通过执行本说明书一个或多个实施例所提及的所述编译处理方法可以至少解决乃至彻底改善上述所存在的局限。

下面结合具体的实施例对本申请进行详细说明。

在一个实施例中，如图1所示，特提出了一种编译处理方法，该方法可依赖于计算机程序实现，可运行于基于冯诺依曼体系的编译处理装置上。该计算机程序可集成在应用中，也可作为独立的工具类应用运行。所述编译处理装置可以为电子设备，包括但不限于：个人电脑、平板电脑、手持设备、车载设备、可穿戴设备、计算设备或连接到无线调制解调器的其它处理设备等。在不同的网络中终端设备可以叫做不同的名称，例如：用户设备、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置、蜂窝电话、无绳电话、5G网络或未来演进网络中的电子设备等。

具体的，该编译处理方法包括：

S102：确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，所述依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

在插件化编译场景下，通常将程序的功能模块以依赖插件的形式单独开发和编译，并在运行时动态加载到宿主中，宿主可以是一个程序或平台，宿主可以依赖于一个或多个“插件”来提供特定的功能或服务，例如，宿主可以是一个应用程序或库，宿主可以依赖于插件来提供额外的功能。依赖插件可以是一些代码模块，依赖插件与宿主进行集成，以扩展其功能或提供附加的服务。

在本说明书中，基于实际编程开发需求，为宿主设置了一个或多个依赖插件以此来确定针对宿主的依赖插件，需要说明的是为了避免或改善由于插件的插件代码与宿主的宿主代码均属于同一代码仓库所引发的前述局限，本说明书中，针对宿主的依赖插件中存在至少一个独立插件，独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；可选的，针对宿主的依赖插件中可以配置共仓插件，共仓插件代码与宿主的宿主代码属于同一代码仓库。

在本说明书中，依赖插件中的独立插件与宿主的代码隶属于不同的代码仓库，独立插件可以被一个或多个宿主进行复用，也就是说插件可以基于实际需要配置多个宿主，作为多个宿主的依赖插件。

在本说明书中，由于依赖插件中的独立插件与宿主的代码隶属于不同的代码仓库，直接采用相关技术中针对同一代码仓库的插件化编译流程无法适配到“独立插件与宿主的代码隶属于不同的代码仓库”的场景下，基于此可以执行本说明书所涉及的编译处理方法，实现对于存在“独立插件与宿主的代码隶属于不同的代码仓库”的场景下的插件化编译过程，执行本说明书所涉及的编译处理方法可以支持宿主与依赖插件分仓编译，还可以支持宿主在存在独立插件的同时引入共仓插件，并实现插件化编译过程。

在本说明书中，在确定针对当前插件编译处理对象-宿主的一个或多个依赖插件后，电子设备可以获取依赖插件的插件清单信息数据，例如获取独立插件的插件清单信息数据；

其中，插件清单数据包括清单信息manifest及依赖插件的插件信息(如插件名、版本等)；

例如，以电子设备系统为安卓系统为例，可以获取宿主所有依赖插件的AndroidManifest.xml和plugin-info.json，AndroidManifest.xml为清单信息manifest，plugin-info.json为依赖插件的插件信息。

S104：对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据；

具体的，针对当前插件编译处理对象-宿主配置了一个或多个依赖插件，插件编译处理过程中，依赖插件中存在与宿主不属于同一代码仓库的一个或多个独立插件，亦或是在存在独立插件的情况下存在与宿主属于同一代码仓库的共仓插件，本说明书提出了一种兼容插件编译方式，通过对宿主所有依赖插件的插件清单信息数据进行校验以及合并处理，校验处理过程可以包括包标识符packageID冲突校验、资源文件asset冲突校验、宿主与插件版本校验等一种或多种的拟合，然后对所有依赖插件的插件清单信息中的清单信息manifest进行合并以及整合所有依赖插件的插件清单信息中的插件信息，完成合并处理，然后得到目标插件清单信息数据。目标插件清单信息数据中可以包括宿主的综合清单信息manifest和依赖插件的综合插件信息。

S106：基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

具体的，在完成对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据之后，基于目标插件清单信息数据对依赖插件进行编译得到编译结果，以及可以基于编译结果在宿主中加载所有依赖插件，以此生成程序运行文件；程序运行文件可以是宿主的依赖插件应用程序包(简称插件apk)、也可以是宿主应用程序包(简称宿主apk)、也可以是整合宿主和“全部或部分依赖插件”的应用程序包等。

其中，APK是电子设备使用的一种应用程序包文件格式，代指电子设备APP的安装包，用于分发和安装应用程序及中间件。一个应用程序的代码若需在设备上运行，需先进行编译，然后被打包成为一个能被电子设备系统所识别的文件才可以被运行，而这种能被系统识别并运行的文件格式便是“APK”。通过将安装包，即完整的APK文件直接传到系统模拟器或电子设备系统中执行即可安装该APK文件对应的APP。

通常情况下，经编译后一个应用程序完整的程序运行文件可包括多个文件，例如Manifest.xml文件、Dex文件、ELF文件、res文件和签名文件等，还可包括文件夹如assets、META-INF等。

其中，Manifest.xml文件是应用全局配置文件，里面包含多种信息，比如应用程序的包名、数据权限、接口权限、版本信息、安装参数等等，另外，它还可以声明应用程序的每一个组件及其属性，声明应用程序所申请的权限、进程，声明显示模式等等。

其中，Dex是Android系统上可执行文件的类型，能够被识别、加载并执行的文件格式，DEX文件时系统上的可执行文件。Dex文件被执行时，可用于实现应用程序的功能。应用通常是用Java语言开发的，它用Android开发工具编译之后变成了二进制的字节码(bytecode)，这些字节码被打包成classes.dex文件，由平台的Dalvik虚拟机来解释执行。为了能够调用系统功能，系统提供了一套运行环境(Framework)，应用调用系统各功能都是通过调用Framework的库来实现的。

其中，ELF是Executable and Linkable Format的缩写，是操作系统中可执行文件、共享库的文件格式。系统也支持应用程序通过JNI或者nativeexecutable直接运行。此时应用执行的是直接在CPU上运行的二进制机器码，不需要经过虚拟机解释，可以直接调用操作系统库如libc、WebKit、SQLite、OpenGL/ES等来调用系统各功能。如果应用要通过JNI或者native executable运行，就需要将要执行的代码编译成ELF文件格式。在一些实施方式中，APK文件包括so文件格式的文件，其中so为shareobject的简称，so文件也是一种ELF文件。

其中，res文件为应用程序的资源文件，例如图像素材、布局文件等。

其中，assets文件夹包括静态文件，比如说明文档或者字体文件。

其中，签名文件可以是应用程序开发者对该应用程序进行签名的签名证书文件。签名文件可用于安全性校验，校验文件是否被篡改等。签名文件可存放于META-INF文件夹中，META-INF文件夹可包括安装包中每个文件哈希值的计算结果、安装包的签名文件等。

在本说明书一个或多个实施例中，电子设备可以确定针对宿主的至少一个依赖插件，获取针对依赖插件的至少一个插件清单信息数据，依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库，对依赖插件的插件清单信息数据进行校验合并处理得到目标插件清单信息数据，然后集合目标插件清单信息数据对依赖插件进行编译整合处理得到针对宿主的程序运行文件，相对于原有将宿主代码和所有插件代码放在同一代码仓库中进行编译处理方式而言，通过设置独立插件降低了共仓的代码耦合度，便于插件代码版本以及宿主代码版本管理，在设置独立插件的情形下引入对所有依赖插件的插件清单信息校验合并以及编译整合，可以确保插件编译处理顺利进行，降低了编译过程中处理冲突现象提高了独立插件的兼容性，也即在插件编译时可以突破宿主的依赖插件来源限制，选择合适的非共仓插件进行接入，提高了插件编译的多样性以及便利化程度，且对于独立插件而言可以被多个宿主同时依赖并可确保插件成功编译处理，提高了插件的复用程度。

请参见图2，图2是本申请提出的一种编译处理方法的另一种实施例的流程示意图。具体的：

S202：获取针对所述宿主的独立插件；

在本说明书一个或多个实施例中，基于程序开发需求开发一个或多个功能模块，模块模块是依赖插件的形式单独开发的，并根据预先设置的配置信息对宿主配置一个或多个独立插件，独立插件并在运行时动态加载到宿主中，宿主可以是一个程序或平台，宿主可以依赖于一个或多个“独立插件”来提供特定的功能或服务，例如，宿主可以是一个应用程序或库，宿主可以依赖于独立插件来提供额外的功能。独立插件可以是一些代码模块，独立插件与宿主进行集成，以扩展其功能或提供附加的服务；

在本说明书中一个或多个实施例中，为了避免或改善由于插件的插件代码与宿主的宿主代码均属于同一代码仓库所引发的前述局限，本说明书中，基于实际编程开发需求，针对宿主的依赖插件中设置了至少一个独立插件，独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

S204：对所述独立插件进行编译得到独立插件程序运行文件并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器；

预设编译服务可以是一种用于编译处理的编译插件、编译程序、编译模块，预设编译服务的具体表征形式此处不做具体限定，可基于实际应用环境进行设置。

可选的，可以针对独立插件设置第一预设编译服务，采用第一预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据，然后将第一插件清单信息数据上传至云端服务器；或者，采用第一预设编译服务对独立插件进行编译得到独立插件apk，然后编译完成后将第一插件清单信息数据上传至云端服务器。

如图3所示，图3是本说明书提供的一种独立插件处理的示意图，使用第一预设编译服务对独立插件的处理可参考下述方式：

1、预先制定插件配置信息对独立插件进行编译得到独立插件程序运行文件(也即独立插件apk)，按照插件配置信息为插件开发者提供一个配置文件(例如：plugin-config.json)，其中可以指定packageID和其他相关信息，读取此配置信息，获取独立插件的packageID。

2、对独立插件进行编译时收集插件中的资源文件assets信息：具体而言，在编译时，遍历插件项目的资源文件目录，收集所有文件和目录信息，得到资源文件assets信息，以及生成清单信息Manifest.xml。

3、进行插件信息整合，例如可以从build.gradle或其他配置文件中获取插件名、版本等信息以此作为独立插件的插件信息。

独立插件的插件信息结合上一步收集的清单信息Manifest.xml，整合为一个插件描述对象，该插件描述对象也即第一插件清单信息数据。

4、将第一插件清单信息数据上传到云端服务器。

S206：获取针对所述宿主的独立插件和共仓插件；

在本说明书中，基于实际编程开发需求，为宿主设置了一个或多个依赖插件以此来确定针对宿主的依赖插件，需要说明的是为了避免或改善由于插件的插件代码与宿主的宿主代码均属于同一代码仓库所引发的前述局限，本说明书中，针对宿主的依赖插件中存在至少一个独立插件，独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库，进一步的，针对宿主的依赖插件中可以配置共仓插件，共仓插件代码与宿主的宿主代码属于同一代码仓库。

S208：对所述独立插件进行编译得到独立插件程序运行文件以及对所述共仓插件进行编译得到共仓插件程序运行文件，并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据和对所述共仓插件进行插件清单信息数据设置得到第二插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器，基于所述云端服务器和/或本地存储空间对所述第二插件清单信息数据进行储存。

其中，步骤“对所述独立插件进行编译得到独立插件程序运行文件”以及步骤“采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据”可参考前述方法步骤，此处不再赘述。

可选的，可以针对独立插件设置第二预设编译服务，采用第二预设编译服务对所述共仓插件进行插件清单信息数据设置得到第二插件清单信息数据，然后将第二插件清单信息数据保存至云端服务器和/或本地存储空间；或者，采用第二预设编译服务对共仓插件进行编译得到共仓插件apk，然后编译完成后将第二插件清单信息数据保存至云端服务器保存至云端服务器和/或本地存储空间。

如图4所示，图4是本说明书提供的一种共仓插件处理的示意图，使用第二预设编译服务对共仓插件的处理可参考下述方式：

1使用第二预设编译服务编译共仓插件，生成共仓插件apk，按照插件配置信息，修改共仓插件的manifest组件以及添加process，读取共仓插件的清单信息Manifest.xml，基于插件配置信息确定相应目标组件对相应目标组件添加process属性，以完成根据插件配置信息修改共仓插件的清单信息Manifest。

2进行插件信息整合，保存共仓插件的插件信息，例如可以从build.gradle或其他配置文件中获取插件名、版本等信息以此作为共仓插件的插件信息。

共仓插件的插件信息结合上一步收集的清单信息Manifest.xml，整合为一个插件描述对象，该插件描述对象也即第二插件清单信息数据。

S210：采用预设编译服务，执行所述确定针对宿主的至少一个依赖插件的步骤；

可选的，可以针对宿主设置第三预设编译服务，采用第三预设编译服务开始执行本说明书一个或多个实施例中所述确定针对宿主的至少一个依赖插件的步骤，也即对宿主进行编译处理。

例如，可以采用第三预设编译服务执行S102-S106，又例如，可以采用第三预设编译服务执行S302-S314；

可选的，第一预设编译服务、第二预设编译服务和第三预设编译服务彼此之间可以是同一预设编译服务，也可以是不同的预设编译服务。

在本说明书一个或多个实施例中，采用上述方式相对于原有将宿主代码和所有插件代码放在同一代码仓库中进行编译处理方式而言，通过设置独立插件降低了共仓的代码耦合度，便于插件代码版本以及宿主代码版本管理，在设置独立插件的情形下引入对所有依赖插件的插件清单信息校验合并以及编译整合，可以确保插件编译处理顺利进行，降低了编译过程中处理冲突现象提高了独立插件的兼容性，也即在插件编译时可以突破宿主的依赖插件来源限制，选择合适的非共仓插件进行接入，提高了插件编译的多样性以及便利化程度，且对于独立插件而言可以被多个宿主同时依赖并可确保插件成功编译处理，提高了插件的复用程度。

请参见图5，图5是本申请提出的一种编译处理方法的另一种实施例的流程示意图。具体的：

S302：获取针对宿主的至少一个依赖插件，确定所述依赖插件的插件类型；

根据一些实施例中，依赖插件的插件类型可以包括独立插件类型和共仓插件类型。

在对宿主进行编译处理时，获取针对宿主的至少一个依赖插件，确定每个依赖插件的插件类型是独立插件类型还是共仓插件类型，在本说明书中，宿主的至少一个依赖插件存在独立插件，基于实际开发需求可以存在共仓插件或不存在共仓插件，基于此，可以基于依赖插件的所述插件类型，从云端服务器获取针对依赖插件的至少一个插件清单信息数据。也即至少可以从云端服务器获取到独立插件的第一插件清单信息数据。

可选的，在依赖插件存在共仓插件的情形下，预先共仓插件的第二插件清单信息数据可以保存在云端服务器也可以保存在本次存储空间中，基于此，可基于实际共仓插件的插件清单信息数据的映射关系，来确定从从云端服务器或本地存储空间中获取针对共仓插件的至少一个第二插件清单信息数据。

S304：若所述插件类型为独立插件类型，则从云端服务器获取针对所述独立插件的至少一个第一插件清单信息数据；

S306：若所述插件类型为共仓插件类型，则从云端服务器或本地存储空间中获取针对共仓插件的至少一个第二插件清单信息数据，所述共仓插件的共仓插件代码与所述宿主的宿主代码属于同一代码仓库。

S308：基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验，得到编译校验结果；

基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验可以理解为是在针对宿主的编译处理过程中，对其的依赖插件进行数据校验处理，以避免后续编译过程中的数据冲突。说明书提出了一种兼容插件编译方式，通过对宿主所有依赖插件的插件清单信息数据进行校验，校验处理过程可以包括包标识符packageID冲突校验、资源文件asset冲突校验、宿主与插件版本校验等一种或多种的拟合，完成编译校验之后，可以得到编译校验结果。

在一种可行的实施方式中，所述基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验，得到编译校验结果，可以采用如下方式：

可选的，从所述第一插件清单信息数据和所述第二插件清单信息数据获取标识符数据，基于所述标识符数据对所述独立插件、所述共仓插件和所述宿主进行标识符重复性校验，得到标识符重复校验结果；和/或，

可选的，基于所述第一插件清单信息数据和所述第二插件清单信息数据获取资源名数据，基于所述资源名数据对所述独立插件、所述共仓插件和所述宿主进行资源名冲突校验，得到资源冲突校验结果；和/或，

可选的，基于所述第二插件清单信息数据确定插件版本和宿主版本，基于所述插件版本和所述宿主版本对所述共仓插件和所述宿主进行库插件版本校验，得到版本校验结果。

示例性的，从所述第一插件清单信息数据和所述第二插件清单信息数据获取标识符数据，基于所述标识符数据对所述独立插件、所述共仓插件和所述宿主进行标识符重复性校验，得到标识符重复校验结果，参考如下：

从所述第一插件清单信息数据和所述第二插件清单信息数据获取标识符数据，标识符数据是指独立插件的第一标识符数据、共仓插件的第二标识符数据、宿主的第三标识符数据；

标识符重复性校验：校验第一标识符数据、第二标识符数据以及第三标识符数据是否存在相同的标识符packageID，标识符重复性校验作用在于校验每个依赖插件需要与“宿主和其他插件”存在不同的packageID；进一步的，若第一标识符数据、第二标识符数据以及第三标识符数据全部不同，则生成校验成功类型的标识符重复校验结果，若第一标识符数据、第二标识符数据以及第三标识符数据中标识符数据至少两个相同，则生成校验失败类型的标识符重复校验结果。

由于存在独立插件，独立插件与宿主代码相隔离，需要独立插件的packageID与“宿主和其他插件”的packageID不一样，以避免后续packageID重复导致编译失败。

可选的，若所述标识符重复校验结果为校验失败类型，则进行停止编译处理；可以理解为，标识符重复停止编译，输出插件校验失败；若标识符重复校验结果为校验成功类型，则继续进行下一步校验，直至完成所有校验，执行所述对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据的步骤。

示例性的，基于所述第一插件清单信息数据和所述第二插件清单信息数据获取资源名数据，基于所述资源名数据对所述独立插件、所述共仓插件和所述宿主进行资源名冲突校验，得到资源冲突校验结果，可参考如下方式：

从所述第一插件清单信息数据和所述第二插件清单信息数据获取资源名数据，资源名数据是指独立插件的第一资源名数据、共仓插件的第二资源名数据、宿主的第三资源名数据；

资源名重复性校验：校验第一资源名数据、第二资源名数据以及第三资源名数据是否存在相同的资源名packageID，资源名重复性校验作用在于校验每个依赖插件需要与“宿主和其他插件”存在不同的packageID；进一步的，若第一资源名数据、第二资源名数据以及第三资源名数据全部不同，则生成校验成功类型的资源名重复校验结果，若第一资源名数据、第二资源名数据以及第三资源名数据中资源名数据至少两个相同，则生成校验失败类型的资源名重复校验结果。

由于存在独立插件，独立插件与宿主代码相隔离，需要独立插件的资源文件asset名称与“宿主和其他插件”的资源文件asset名称不一样，以避免后续asset文件冲突导致编译失败。

可选的，若所述资源名重复校验结果为校验失败类型，则进行停止编译处理；可以理解为，资源名重复停止编译，输出插件校验失败；若资源名重复校验结果为校验成功类型，则继续进行下一步校验，直至完成所有校验，执行所述对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据的步骤。

其中，资源文件asset用于存放应用程序所需的原始资源文件，这些文件在编译过程中会被打包到APK中。当在asset文件夹中存在多个文件名称相同的文件时，会导致冲突。

在应用开发中，Asset是指应用程序的原始资源文件，这些文件通常存放在应用的asset文件夹中。这些资源文件可以是图片、音频、视频、字体等非编译型的文件，它们在应用程序的运行过程中可以被读取和使用。

示例性的，基于所述第二插件清单信息数据确定插件版本和宿主版本，基于所述插件版本和所述宿主版本对所述共仓插件和所述宿主进行库插件版本校验，得到版本校验结果。

插件版本校验：校验插件(代码仓库)版本是否小于或等于宿主(代码仓库)版本，若插件(代码仓库)版本是否小于或等于宿主(代码仓库)版本，则生成校验成功类型的版本校验结果，若插件(代码仓库)版本是否大于宿主(代码仓库)版本，则生成校验失败类型的版本校验结果；

进一步的，若版本校验结果为校验成功类型，则继续进行下一步校验，直至完成所有校验，执行所述对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据的步骤。若版本校验结果为校验失败类型，则进行停止编译处理；可以理解为，版本校验失败停止编译，输出插件校验失败；

在一种可行的实施方式中，若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的至少其一为校验失败类型，则进行停止编译处理；若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的均为校验成功类型，则执行所述对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据的步骤，或，可以开始执行S310。

S310：基于编译校验结果对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据；

在一种可行的实施方式中，若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的至少其一为校验失败类型，则进行停止编译处理；若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的均为校验成功类型，则执行对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据的步骤。

示例性的，对独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据，具体可以是根据配置信息修改或添加第一插件清单信息数据中插件清单信息manifest里面的针对独立插件的处理过程信息(简称process处理过程信息)，生成新的第一插件清单信息数据。

在一种可行的实施方式中，电子设备执行所述对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据，可以是：

电子设备从第一插件清单信息数据获取独立插件的独立插件清单(manifest信息)，确定针对所述独立插件的处理过程信息(process处理过程信息)；基于处理过程信息(process处理过程信息)对独立插件清单进行清单配置更新处理，得到处理后的第一插件清单信息数据。

其中，处理过程信息(process处理过程信息)：简称"处理步骤"或"处理过程"，它指的是对插件或宿主进行特定操作或处理的步骤，具体处理过程信息在插件开发阶段存储在配置信息中，也即预先设置好的。

S312：对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据。

示例性的，以依赖插件包括独立插件和共仓插件，所述插件清单信息数据包括所述独立插件的第一插件清单信息数据和所述共仓插件的第二插件清单信息数据为例；此时，在前述校验通之后，即可对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据；通常可以是对所述第一插件清单信息数据中的第一清单信息manifest和第二插件清单信息数据中的第二清单信息manifest进行清单数据合并处理得到目标清单信息，以及，整合所有依赖插件的插件信息，也即第一插件清单信息数据中的第一插件信息和第二插件清单信息数据中的第二插件信息进行插件信息合并处理得到目标插件信息，生成包含目标清单信息和目标插件信息的目标插件清单信息数据。

S314：基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

根据一些实施例中，在完成对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据之后，基于目标插件清单信息数据对依赖插件进行编译得到编译结果，以及可以基于编译结果在宿主中加载所有依赖插件，以此生成程序运行文件；程序运行文件可以是宿主的依赖插件应用程序包(简称插件apk)、也可以是宿主应用程序包(简称宿主apk)、也可以是整合宿主和“全部或部分依赖插件”的应用程序包等。

示例性的，在一种具体的实施场景中，电子设备可执行如下步骤：

S502：获取针对所述宿主的独立插件和共仓插件；

S504：对所述独立插件进行编译得到独立插件程序运行文件以及对所述共仓插件进行编译得到共仓插件程序运行文件，并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据和对所述共仓插件进行插件清单信息数据设置得到第二插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器，基于本地存储空间对所述第二插件清单信息数据进行储存；

S506：获取针对宿主的至少一个依赖插件，依赖插件包括独立插件和共仓插件，确定所述依赖插件的插件类型为独立插件类型和共仓插件类型；

S508：若所述插件类型为独立插件类型，则从云端服务器获取针对所述独立插件的至少一个第一插件清单信息数据，若所述插件类型为共仓插件类型，则从本地存储空间中获取针对共仓插件的至少一个第二插件清单信息数据，所述共仓插件的共仓插件代码与所述宿主的宿主代码属于同一代码仓库；

S510：从所述第一插件清单信息数据和所述第二插件清单信息数据获取标识符数据，基于所述标识符数据对所述独立插件、所述共仓插件和所述宿主进行标识符重复性校验，得到标识符重复校验结果；

S510-2：若标识符重复校验结果为校验成功类型，则执行S512；

S510-4：若标识符重复校验结果为校验失败类型，则进行停止编译处理；

S512：基于所述第一插件清单信息数据和所述第二插件清单信息数据获取资源名数据，基于所述资源名数据对所述独立插件、所述共仓插件和所述宿主进行资源名冲突校验，得到资源冲突校验结果；

S512-2：若资源冲突校验结果为校验成功类型，则执行S514；

S512-4：若资源冲突校验结果为校验失败类型，则进行停止编译处理；

S514：对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据；

S516：基于所述第二插件清单信息数据确定插件版本和宿主版本，基于所述插件版本和所述宿主版本对所述共仓插件和所述宿主进行库插件版本校验，得到版本校验结果；

S516-2：若版本校验结果为校验成功类型，则执行S518；

S516-4：若版本校验结果为校验失败类型，则进行停止编译处理；

S518：对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据；

S520：基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

在本说明书一个或多个实施例中，采用上述方式相对于原有将宿主代码和所有插件代码放在同一代码仓库中进行编译处理方式而言，通过设置独立插件降低了共仓的代码耦合度，便于插件代码版本以及宿主代码版本管理，在设置独立插件的情形下引入对所有依赖插件的插件清单信息校验合并以及编译整合，可以确保插件编译处理顺利进行，降低了编译过程中处理冲突现象提高了独立插件的兼容性，也即在插件编译时可以突破宿主的依赖插件来源限制，选择合适的非共仓插件进行接入，提高了插件编译的多样性以及便利化程度，且对于独立插件而言可以被多个宿主同时依赖并可确保插件成功编译处理，提高了插件的复用程度。

下面将结合图6，对本申请实施例提供的编译处理装置进行详细介绍。需要说明的是，图6所示的编译处理装置，用于执行本申请图1～图5所示实施例的方法，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请图1～图5所示的实施例。

请参见图6，其示出本申请实施例的编译处理装置的结构示意图。该编译处理装置1可以通过软件、硬件或者两者的结合实现成为用户终端的全部或一部分。根据一些实施例，该编译处理装置1包括数据获取模块11、数据处理模块12和文件整合模块13，具体用于：

数据获取模块11，用于确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，所述依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

数据处理模块12，用于对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据；

文件整合模块13，用于基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

可选的，如图7所示，所述数据获取模块11，包括：

插件获取单元111，用于获取针对宿主的至少一个依赖插件，确定所述依赖插件的插件类型；

数据获取单元112，用于基于所述依赖插件的所述插件类型，从云端服务器获取针对所述依赖插件的至少一个插件清单信息数据。

可选的，所述数据获取单元112，用于：

若所述插件类型为独立插件类型，则从云端服务器获取针对所述独立插件的至少一个第一插件清单信息数据；

若所述插件类型为共仓插件类型，则从云端服务器或本地存储空间中获取针对共仓插件的至少一个第二插件清单信息数据，所述共仓插件的共仓插件代码与所述宿主的宿主代码属于同一代码仓库。

可选的，所述依赖插件包括独立插件和共仓插件，所述插件清单信息数据包括所述独立插件的第一插件清单信息数据和所述共仓插件的第二插件清单信息数据，如图8所示，所述数据处理模块12，包括：

编译校验单元121，用于基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验，得到编译校验结果；

配置更新单元122，用于基于编译校验结果对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据；

数据合并单元123，用于对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据。

可选的，所述编译校验单元121，用于：

从所述第一插件清单信息数据和所述第二插件清单信息数据获取标识符数据，基于所述标识符数据对所述独立插件、所述共仓插件和所述宿主进行标识符重复性校验，得到标识符重复校验结果；和/或，

基于所述第一插件清单信息数据和所述第二插件清单信息数据获取资源名数据，基于所述资源名数据对所述独立插件、所述共仓插件和所述宿主进行资源名冲突校验，得到资源冲突校验结果；和/或，

基于所述第二插件清单信息数据确定插件版本和宿主版本，基于所述插件版本和所述宿主版本对所述共仓插件和所述宿主进行库插件版本校验，得到版本校验结果。

可选的，所述编译校验单元121，用于：

若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的至少其一为校验失败类型，则进行停止编译处理；

若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的均为校验成功类型，则执行所述对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据的步骤。

可选的，配置更新单元122，用于：

基于第一插件清单信息数据获取所述独立插件的独立插件清单，确定针对所述独立插件的处理过程信息；

基于所述处理过程信息对所述独立插件清单进行清单配置更新处理，得到处理后的所述第一插件清单信息数据。

可选的，所述装置1，还用于：

获取针对所述宿主的独立插件，对所述独立插件进行编译得到独立插件程序运行文件并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器；或，

获取针对所述宿主的独立插件和共仓插件，对所述独立插件进行编译得到独立插件程序运行文件以及对所述共仓插件进行编译得到共仓插件程序运行文件，并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据和对所述共仓插件进行插件清单信息数据设置得到第二插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器，基于所述云端服务器和/或本地存储空间对所述第二插件清单信息数据进行储存；

所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件，包括：

采用预设编译服务，执行所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件的步骤。

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

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请实施例还提供了一种计算机存储介质，所述计算机存储介质可以存储有多条指令，所述指令适于由处理器加载并执行如上述图1～图5所示实施例的所述编译处理方法，具体执行过程可以参见图1～图5所示实施例的具体说明，在此不进行赘述。

本申请还提供了一种计算机程序产品，该计算机程序产品存储有至少一条指令，所述至少一条指令由所述处理器加载并执行如上述图1～图5所示实施例的所述编译处理方法，具体执行过程可以参见图1～图5所示实施例的具体说明，在此不进行赘述。

请参考图9，其示出了本申请一个示例性实施例提供的电子设备的结构方框图。本申请中的电子设备可以包括一个或多个如下部件：处理器110、存储器120、输入装置130、输出装置140和总线150。处理器110、存储器120、输入装置130和输出装置140之间可以通过总线150连接。

处理器110可以包括一个或者多个处理核心。处理器110利用各种接口和线路连接整个电子设备内的各个部分，通过运行或执行存储在存储器120内的指令、程序、代码集或指令集，以及调用存储在存储器120内的数据，执行电子设备100的各种功能和处理数据。可选地，处理器110可以采用数字信号处理(digital signal processing，DSP)、现场可编程门阵列(field－programmable gate array，FPGA)、可编程逻辑阵列(programmable logicArray，PLA)中的至少一种硬件形式来实现。处理器110可集成中央处理器(centralprocessing unit，CPU)、图像处理器(graphics processing unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器110中，单独通过一块通信芯片进行实现。

存储器120可以包括随机存储器(random Access Memory，RAM)，也可以包括只读存储器(read-only memory，ROM)。可选地，该存储器120包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等，该操作系统可以是安卓(Android)系统，包括基于Android系统深度开发的系统、苹果公司开发的IOS系统，包括基于IOS系统深度开发的系统或其它系统。存储数据区还可以存储电子设备在使用中所创建的数据比如电话本、音视频数据、聊天记录数据，等。

参见图10所示，存储器120可分为操作系统空间和用户空间，操作系统即运行于操作系统空间，原生及第三方应用程序即运行于用户空间。为了保证不同第三方应用程序均能够达到较好的运行效果，操作系统针对不同第三方应用程序为其分配相应的系统资源。然而，同一第三方应用程序中不同应用场景对系统资源的需求也存在差异，比如，在本地资源加载场景下，第三方应用程序对磁盘读取速度的要求较高；在动画渲染场景下，第三方应用程序则对GPU性能的要求较高。而操作系统与第三方应用程序之间相互独立，操作系统往往不能及时感知第三方应用程序当前的应用场景，导致操作系统无法根据第三方应用程序的具体应用场景进行针对性的系统资源适配。

为了使操作系统能够区分第三方应用程序的具体应用场景，需要打通第三方应用程序与操作系统之间的数据通信，使得操作系统能够随时获取第三方应用程序当前的场景信息，进而基于当前场景进行针对性的系统资源适配。

以操作系统为Android系统为例，存储器120中存储的程序和数据如图11所示，存储器120中可存储有Linux内核层320、系统运行时库层340、应用框架层360和应用层380，其中，Linux内核层320、系统运行库层340和应用框架层360属于操作系统空间，应用层380属于用户空间。Linux内核层320为电子设备的各种硬件提供了底层的驱动，如显示驱动、音频驱动、摄像头驱动、蓝牙驱动、Wi-Fi驱动、电源管理等。系统运行库层340通过一些C/C++库来为Android系统提供了主要的特性支持。如SQLite库提供了数据库的支持，OpenGL/ES库提供了3D绘图的支持，Webkit库提供了浏览器内核的支持等。在系统运行时库层340中还提供有安卓运行时库(Android runtime)，它主要提供了一些核心库，能够允许开发者使用Java语言来编写Android应用。应用框架层360提供了构建应用程序时可能用到的各种API，开发者也可以通过使用这些API来构建自己的应用程序，比如活动管理、窗口管理、视图管理、通知管理、内容提供者、包管理、通话管理、资源管理、定位管理。应用层380中运行有至少一个应用程序，这些应用程序可以是操作系统自带的原生应用程序，比如联系人程序、短信程序、时钟程序、相机应用等；也可以是第三方开发者所开发的第三方应用程序，比如游戏类应用程序、即时通信程序、相片美化程序等。

以操作系统为IOS系统为例，存储器120中存储的程序和数据如图12所示，IOS系统包括：核心操作系统层420(Core OS layer)、核心服务层440(Core Services layer)、媒体层460(Media layer)、可触摸层480(Cocoa Touch Layer)。核心操作系统层420包括了操作系统内核、驱动程序以及底层程序框架，这些底层程序框架提供更接近硬件的功能，以供位于核心服务层440的程序框架所使用。核心服务层440提供给应用程序所需要的系统服务和/或程序框架，比如基础(Foundation)框架、账户框架、广告框架、数据存储框架、网络连接框架、地理位置框架、运动框架等等。媒体层460为应用程序提供有关视听方面的接口，如图形图像相关的接口、音频技术相关的接口、视频技术相关的接口、音视频传输技术的无线播放(AirPlay)接口等。可触摸层480为应用程序开发提供了各种常用的界面相关的框架，可触摸层480负责用户在电子设备上的触摸交互操作。比如本地通知服务、远程推送服务、广告框架、游戏工具框架、消息用户界面接口(User Interface，UI)框架、用户界面UIKit框架、地图框架等等。

在图12所示出的框架中，与大部分应用程序有关的框架包括但不限于：核心服务层440中的基础框架和可触摸层480中的UIKit框架。基础框架提供许多基本的对象类和数据类型，为所有应用程序提供最基本的系统服务，和UI无关。而UIKit框架提供的类是基础的UI类库，用于创建基于触摸的用户界面，iOS应用程序可以基于UIKit框架来提供UI，所以它提供了应用程序的基础架构，用于构建用户界面，绘图、处理和用户交互事件，响应手势等等。

其中，在IOS系统中实现第三方应用程序与操作系统数据通信的方式以及原理可参考Android系统，本申请在此不再赘述。

其中，输入装置130用于接收输入的指令或数据，输入装置130包括但不限于键盘、鼠标、摄像头、麦克风或触控设备。输出装置140用于输出指令或数据，输出装置140包括但不限于显示设备和扬声器等。在一个示例中，输入装置130和输出装置140可以合设，输入装置130和输出装置140为触摸显示屏，该触摸显示屏用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作，以及显示各个应用程序的用户界面。触摸显示屏通常设置在电子设备的前面板。触摸显示屏可被设计成为全面屏、曲面屏或异型屏。触摸显示屏还可被设计成为全面屏与曲面屏的结合，异型屏与曲面屏的结合，本申请实施例对此不加以限定。

除此之外，本领域技术人员可以理解，上述附图所示出的电子设备的结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，电子设备中还包括射频电路、输入单元、传感器、音频电路、无线保真(wireless fidelity，WiFi)模块、电源、蓝牙模块等部件，在此不再赘述。

在本申请实施例中，各步骤的执行主体可以是上文介绍的电子设备。可选地，各步骤的执行主体为电子设备的操作系统。操作系统可以是安卓系统，也可以是IOS系统，或者其它操作系统，本申请实施例对此不作限定。

本申请实施例的电子设备，其上还可以安装有显示设备，显示设备可以是各种能实现显示功能的设备，例如：阴极射线管显示器(cathode ray tubedisplay，简称CR)、发光二极管显示器(light-emitting diode display，简称LED)、电子墨水屏、液晶显示屏(liquid crystal display，简称LCD)、等离子显示面板(plasma display panel，简称PDP)等。用户可以利用电子设备101上的显示设备，来查看显示的文字、图像、视频等信息。所述电子设备可以是智能手机、平板电脑、游戏设备、AR(Augmented Reality，增强现实)设备、汽车、数据存储装置、音频播放装置、视频播放装置、笔记本、桌面计算设备、可穿戴设备诸如电子手表、电子眼镜、电子头盔、电子手链、电子项链、电子衣物等设备。

在图9所示的电子设备中，其中电子设备可以是一种终端，处理器110可以用于调用存储器120中存储的应用程序，并具体执行以下操作：

确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，所述依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据；

基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

在一个实施例中，所述处理器110在执行所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，执行以下步骤：

获取针对宿主的至少一个依赖插件，确定所述依赖插件的插件类型；

基于所述依赖插件的所述插件类型，从云端服务器获取针对所述依赖插件的至少一个插件清单信息数据。

在一个实施例中，所述处理器110在执行所述基于所述依赖插件的所述插件类型，从云端服务器获取针对所述依赖插件的至少一个插件清单信息数据，执行以下步骤：

若所述插件类型为独立插件类型，则从云端服务器获取针对所述独立插件的至少一个第一插件清单信息数据；

若所述插件类型为共仓插件类型，则从云端服务器或本地存储空间中获取针对共仓插件的至少一个第二插件清单信息数据，所述共仓插件的共仓插件代码与所述宿主的宿主代码属于同一代码仓库。

在一个实施例中，所述依赖插件包括独立插件和共仓插件，所述插件清单信息数据包括所述独立插件的第一插件清单信息数据和所述共仓插件的第二插件清单信息数据，所述处理器110在执行所述对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，执行以下步骤：

基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验，得到编译校验结果；

基于编译校验结果对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据；

对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据。

在一个实施例中，所述处理器110在执行所述基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验，得到编译校验结果，执行以下步骤：

从所述第一插件清单信息数据和所述第二插件清单信息数据获取标识符数据，基于所述标识符数据对所述独立插件、所述共仓插件和所述宿主进行标识符重复性校验，得到标识符重复校验结果；和/或，

基于所述第一插件清单信息数据和所述第二插件清单信息数据获取资源名数据，基于所述资源名数据对所述独立插件、所述共仓插件和所述宿主进行资源名冲突校验，得到资源冲突校验结果；和/或，

基于所述第二插件清单信息数据确定插件版本和宿主版本，基于所述插件版本和所述宿主版本对所述共仓插件和所述宿主进行库插件版本校验，得到版本校验结果。

在一个实施例中，所述处理器110在执行所述基于编译校验结果对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据，执行以下步骤：

若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的至少其一为校验失败类型，则进行停止编译处理；

若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的均为校验成功类型，则执行所述对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据的步骤。

在一个实施例中，所述处理器110在执行所述对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据，执行以下步骤：

基于第一插件清单信息数据获取所述独立插件的独立插件清单，确定针对所述独立插件的处理过程信息；

基于所述处理过程信息对所述独立插件清单进行清单配置更新处理，得到处理后的所述第一插件清单信息数据。

在一个实施例中，所述处理器110在执行所述确定针对宿主的至少一个依赖插件之前，还执行以下步骤：

获取针对所述宿主的独立插件，对所述独立插件进行编译得到独立插件程序运行文件并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器；或，

获取针对所述宿主的独立插件和共仓插件，对所述独立插件进行编译得到独立插件程序运行文件以及对所述共仓插件进行编译得到共仓插件程序运行文件，并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据和对所述共仓插件进行插件清单信息数据设置得到第二插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器，基于所述云端服务器和/或本地存储空间对所述第二插件清单信息数据进行储存；

所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件，包括：

采用预设编译服务，执行所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体或随机存储记忆体等。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (11)

1.一种编译处理方法，其特征在于，所述方法包括：

确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，所述依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据；

基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

2.根据权利要求1所述的方法，其特征在于，所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，包括：

获取针对宿主的至少一个依赖插件，确定所述依赖插件的插件类型；

基于所述依赖插件的所述插件类型，从云端服务器获取针对所述依赖插件的至少一个插件清单信息数据。

3.根据权利要求2所述的方法，其特征在于，所述基于所述依赖插件的所述插件类型，从云端服务器获取针对所述依赖插件的至少一个插件清单信息数据，包括：

若所述插件类型为独立插件类型，则从云端服务器获取针对所述独立插件的至少一个第一插件清单信息数据；

若所述插件类型为共仓插件类型，则从云端服务器或本地存储空间中获取针对共仓插件的至少一个第二插件清单信息数据，所述共仓插件的共仓插件代码与所述宿主的宿主代码属于同一代码仓库。

4.根据权利要求1所述的方法，其特征在于，所述依赖插件包括独立插件和共仓插件，所述插件清单信息数据包括所述独立插件的第一插件清单信息数据和所述共仓插件的第二插件清单信息数据，

所述对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，包括：

基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验，得到编译校验结果；

基于编译校验结果对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据；

对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据。

5.根据权利要求4所述的方法，其特征在于，所述基于所述第一插件清单信息数据和所述第二插件清单信息数据进行编译校验，得到编译校验结果，包括：

从所述第一插件清单信息数据和所述第二插件清单信息数据获取标识符数据，基于所述标识符数据对所述独立插件、所述共仓插件和所述宿主进行标识符重复性校验，得到标识符重复校验结果；和/或，

基于所述第一插件清单信息数据和所述第二插件清单信息数据获取资源名数据，基于所述资源名数据对所述独立插件、所述共仓插件和所述宿主进行资源名冲突校验，得到资源冲突校验结果；和/或，

基于所述第二插件清单信息数据确定插件版本和宿主版本，基于所述插件版本和所述宿主版本对所述共仓插件和所述宿主进行库插件版本校验，得到版本校验结果。

6.根据权利要求5所述的方法，其特征在于，所述基于编译校验结果对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据，包括：

若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的至少其一为校验失败类型，则进行停止编译处理；

若所述标识符重复校验结果、所述资源冲突校验结果和所述版本校验结果中的均为校验成功类型，则执行所述对所述第一插件清单信息数据和所述第二插件清单信息数据进行数据合并处理，得到目标插件清单信息数据的步骤。

7.根据权利要求4所述的方法，其特征在于，所述对所述独立插件的第一插件清单信息数据进行清单配置更新处理，得到处理后的所述第一插件清单信息数据，包括：

基于第一插件清单信息数据获取所述独立插件的独立插件清单，确定针对所述独立插件的处理过程信息；

基于所述处理过程信息对所述独立插件清单进行清单配置更新处理，得到处理后的所述第一插件清单信息数据。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述确定针对宿主的至少一个依赖插件之前，还包括：

获取针对所述宿主的独立插件，对所述独立插件进行编译得到独立插件程序运行文件并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器；或，

获取针对所述宿主的独立插件和共仓插件，对所述独立插件进行编译得到独立插件程序运行文件以及对所述共仓插件进行编译得到共仓插件程序运行文件，并采用预设编译服务对所述独立插件进行插件清单信息数据设置得到第一插件清单信息数据和对所述共仓插件进行插件清单信息数据设置得到第二插件清单信息数据，将所述第一插件清单信息数据上传至云端服务器，基于所述云端服务器和/或本地存储空间对所述第二插件清单信息数据进行储存；

所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件，包括：

采用预设编译服务，执行所述确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据，基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件的步骤。

9.一种编译处理装置，其特征在于，所述装置包括：

数据获取模块，用于确定针对宿主的至少一个依赖插件，获取针对所述依赖插件的至少一个插件清单信息数据，所述依赖插件中至少存在独立插件的独立插件代码与所述宿主的宿主代码不属于同一代码仓库；

数据处理模块，用于对所述依赖插件的所述插件清单信息数据进行校验合并处理，得到目标插件清单信息数据；

文件整合模块，用于基于所述目标插件清单信息数据对所述依赖插件进行编译整合处理，得到针对所述宿主的程序运行文件。

10.一种计算机存储介质，其特征在于，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行如权利要求1～8任意一项的方法步骤。

11.一种电子设备，其特征在于，包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行如权利要求1～8任意一项的方法步骤。