CN110457045A - 组件化合并编译方法、装置、设备和存储介质 - Google Patents

Abstract

本发明实施例公开了一种组件化合并编译方法、装置、设备和存储介质，其中，该方法包括：确定参与组件合并的主组件和参与组件合并的依赖组件；获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息；基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。本发明实施例可以实现基于渠道信息的软件开发工具包相关组件的合并编译，提高工程编译效率。

Description

组件化合并编译方法、装置、设备和存储介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种组件化合并编译方法、装置、设备和存储介质。

背景技术

对于安卓(Android)系统，现在组件化开发普遍采用aar文件格式的形式。每个Android应用程序安装包(apk)均可由多个aar文件组合构成。

目前，Gradle技术作为现有的安卓通用文件打包工具，其官方服务公开的一种了一套完整的编译方案，支持应用程序(Application)编译时将所有aar文件打包成一个完整的安装包(Android Package，APK)。但是Gradle官方功能并不能很好的支持针对软件开发工具包(Software Development Kit，SDK)的组件化编译。

由此可见，Gradle官方当前公开的一种的打包功能并不能满足开发人员对SDK的组件化编译需求。

发明内容

本发明实施例提供一种组件化合并编译方法、装置、设备和存储介质，以实现基于渠道信息的软件开发工具包相关组件的合并编译，提高工程编译效率。

第一方面，本发明实施例提供了一种组件化合并编译方法，该方法包括：

确定参与组件合并的主组件和参与组件合并的依赖组件；

获取所述参与组件合并的主组件和所述参与组件合并的依赖组件涉及的渠道信息，并根据所述参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息；

基于所述参与组件合并的主组件涉及的渠道信息以及所述参与组件合并的依赖组件的组件编译信息，执行所述参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

第二方面，本发明实施例还提供了一种组件化合并编译装置，该装置包括：

合并组件确定模块，用于确定参与组件合并的主组件和参与组件合并的依赖组件；

组件编译信息确定模块，用于获取所述参与组件合并的主组件和所述参与组件合并的依赖组件涉及的渠道信息，并根据所述参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息；

合并任务链执行模块，用于基于所述参与组件合并的主组件涉及的渠道信息以及所述参与组件合并的依赖组件的组件编译信息，执行所述参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

第三方面，本发明实施例还提供了一种设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明任一实施例所述的组件化合并编译方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任一实施例所述的组件化合并编译方法。

本发明实施例通过获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息；基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链，从而得到每个渠道下合并后的目标组件，实现了基于渠道信息的软件开发工具包相关组件的合并编译，提高了工程编译效率，增加与完善了现有的Gradle系统的组件打包功能，可以更好的满足开发人员的组件化开发需求。

附图说明

图1是本发明实施例公开的一种组件化合并编译方法的流程图；

图2是本发明实施例公开的另一种组件化合并编译方法的流程图；

图3是本发明实施例公开的参与组件合并的主组件的合并任务链的一种示意图；

图4是本发明实施例公开的一种组件化合并编译装置的结构示意图；

图5是本发明实施例公开的一种设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

单一工程开发是指SDK中所有业务功能都是集中在同一个module里实现的；单一工程痛点在于：

1)对工程的任意修改调试都要编译整个工程，效率十分低下；

2)不利于多人团队协同开发；

3)无法做到功能复用；

4)业务模块间耦合严重。

然而，组件化开发是指将SDK中业务功能进行拆分，每一个功能都是一个单独的module，每个module都能独立运行，且只包含自己的业务，最后整个SDK由多个拆分出的组件集成。组件化开发的优势在于：

1)极大提高工程编译速度；

2)业务模块解耦，有利于多人团队协作开发；

3)组件化是功能重用的基石。

图1是本发明实施例公开的一种组件化合并编译方法的流程图，本实施例可适用于针对软件开发工具包的组件化开发情况，即对SDK相关组件的合并编译情景，该方法可以由组件化合并编译装置来执行，该装置可以采用软件和/或硬件的方式实现，并可集成在任意的具有计算能力的设备上，包括但不限于服务器等。

如图1所示，本实施例公开的组件化合并编译方法可以包括：

S110、确定参与组件合并的主组件和参与组件合并的依赖组件。

本实施例中，针对不同的工程业务开发需求，可以在SDK编译的初始化阶段，确定参与组件合并的和参与组件合并的依赖组件(或称为次组件)。相当于，在SDK编译的初始化阶段，需要分析哪些组件(或称为模块)将要被构建，并为每个组件创建对应的工程实例，然后通过读取解析文件(例如settings.gradle文件)，从中调取需要参与合并的多个组件。

参与组件合并的主组件对参与组件合并的依赖组件具有依赖关系，参与组件合并的依赖组件包括需要合并入该主组件中的至少一个组件。参与组件合并的主组件和参与组件合并的依赖组件均可以是由安卓系统中的库构成，参与组件合并的主组件和参与组件合并的依赖组件中均可以包括多个aar格式的文件。具体的，参与组件合并的主组件和参与组件合并的依赖组件可以是指安卓系统中软件开发涉及的Library组件。

S120、获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息。

渠道(flavor)可以理解为对组件有需求的第三方应用平台，一个第三方应用平台即对应一个渠道。以地图组件为例，该地图组件可以下发至谷歌地图应用平台、高德地图应用平台、滴滴地图应用平台，即对应三种渠道。各组件涉及的渠道信息可以包括渠道名称和渠道标识等。在当前的组件打包工具中，例如Gradle系统，当参与组件合并的依赖组件中包含渠道信息时，由于产物存储路径的未知性，该依赖组件并不会被组件打包工具成功地自动化编译，因此，本实施例为了保证组件合并过程中参与组件合并的依赖组件的成功编译，预先为携带渠道信息的依赖组件确定组件编译信息，相当于预先构建一个“被解析过的产物对象”，让编译脚本认为该对象被成功解析，从而对携带有渠道信息的依赖组件进行合并操作。此处需要说明的是，对于参与组件合并的主组件而言，在执行组件化合并编译的过程中，各参与组件合并的依赖组件是需要被预先编译完成的。

示例性的，可以在SDK编译的配置阶段，获取参与组件合并的主组件涉及的渠道信息和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息以及未携带渠道信息的依赖组件的参考编译信息，分别为每个渠道下的参与组件合并的依赖组件构建组件编译信息，其中，参考编译信息是通过对未携带渠道信息的依赖组件进行自动编译后确定。鉴于在当前的组件打包工具中，携带有渠道信息的依赖组件不会被组件打包工具自动化编译，因此，可以参考未携带渠道信息的依赖组件被打包工具自动化编译后的产物，即参考编译信息，为携带有渠道信息的参与组件合并的依赖组件预先构建组件编译信息。

其中，组件编译信息可以包括组件被编译后的产物存储路径以及参与组件合并的依赖组件和参与组件合并的主组件之间的依赖关系。进一步的，组件编译信息还可以包括组件被编译后的产物名称、产物标识符和合并编译任务信息，合并编译任务信息用于描述组件合并编译过程中涉及的具体编译任务。以Gradle系统为例，默认产物名称的依赖对象是ModuleName，组件产物标识符的依赖对象是产物存储路径。

可选的，在分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息之前，该方法还包括：遍历各个依赖组件，通过与已被自动编译的依赖组件进行名称对比，确定携带有渠道信息的参与组件合并的依赖组件。其中，已被自动编译的依赖组件即未携带渠道信息的依赖组件，其组件名称是可以确定的，通过组件名称之间的一一对比，即可从依赖组件总量中挑选出携带有渠道信息的参与组件合并的依赖组件。

S130、基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

其中，参与组件合并的主组件的合并任务链中可以包括至少一个合并编译任务以及每个合并编译任务被执行过程中需要依赖的其他任务。合并编译任务的数量与参与组件合并编译的文件类型的数量有关，每个合并编译任务可以对应组件中一类文件的合并编译操作。在合并任务链中，可以根据渠道信息对合并编译任务进行区分。通过执行合并任务链中与每个渠道相关的合并编译任务，即可得到每个渠道下参与组件合并的主组件和参与组件合并的依赖组件合并后的目标组件，从而实现渠道化组件合并。对Library组件而言，本实施例方案解决了现有的Gradle编译技术不支持Library组件的渠道化合并编译的缺陷，实现了参与组件合并的主组件和参与组件合并的依赖组件中均可携带有渠道信息参与组件合并的效果，即同时支持参与组件合并的主组件和参与组件合并的依赖组件的多渠道打包。

在上述技术方案的基础上，可选的，该方法还包括：

获取参与组件合并的主组件和参与组件合并的依赖组件支持的安卓系统版本信息和安卓编译版本信息，以分别根据安卓系统版本信息和安卓编译版本信息，将参与组件合并的依赖组件合并至参与组件合并的主组件。关于版本信息的获取，可以在SDK编译的配置阶段执行。本实施例技术方案支持任意的安卓系统版本以及安卓编译版本，针对不同的安卓系统版本信息和安卓编译版本信息，在组件合并编译过程中，可以动态分配参与组件合并的依赖组件在参与组件合并的主组件中所属的文件目录，实现支持全版本的组件化合并编译。

需要说明的是，本实施例技术方案可以自定义插件的形式嵌入现有的Gradle系统中，对Gradle系统的组件打包功能进行完善与优化。具体的，针对现有的依赖云端仓库maven的组件化合并编译方案，本实施例技术方案不需要依赖云端仓库，可以实现本地化组件的合并编译；针对最早的本地组件合并方案android-fat-aar，本实施例技术方案实现了基于渠道信息的组件化合并编译，并且对Gradle系统的版本无特殊要求，可以支持Gradle系统的更高版本，例如可以支持支持Gradle3.0以上版本；针对现有的组件编译方案fat-aar-plugin，虽然fat-aar-plugin支持了更多的组件合并属性，但是其仅仅支持组件合并编译过程中参与组件合并的主组件中携带有渠道信息，并不支持在参与组件合并的依赖组件中按照渠道信息对文件进行区分，然而本实施例技术方案可以同时支持参与组件合并的主组件和参与组件合并的依赖组件中均携带有渠道信息参与组件化合并编译，并且本实施例技术方案可以支持Gradle系统的更高版本。

本实施例的技术方案通过获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息；基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链，从而得到每个渠道下合并后的目标组件，实现了基于渠道信息的软件开发工具包相关组件的合并编译，提高了工程编译效率，增加与完善了现有的Gradle系统的组件打包功能，可以更好的满足开发人员的组件化开发需求。

图2是本发明实施例公开的另一种组件化合并编译方法的流程图，本实施例是在上述实施例的基础上进一步进行优化与扩展。如图2所示，该方法可以包括：

S210、确定参与组件合并的和参与组件合并的依赖组件，其中，参与组件合并的主组件和参与组件合并的依赖组件均包括以下目标文件中的至少之一：Resource文件、Jni文件、Assets文件、AndroidManifest文件、Class文件、Jar文件和R文件。

S220、获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息。

针对不同的目标文件，在参与组件合并的主组件的合并任务链中分别对应不同的合并编译任务。并且，在各个合并编译任务被执行之前，根据每个渠道下参与组件合并的依赖组件中不同目标文件对应的组件编译信息，以代码或程序注入的方式将不同目标文件对应的组件编译信息注入该目标文件在参与组件合并的主组件中对应的目标编译任务中，从而得到每个渠道下不同目标文件的合并编译任务，然后结合各执行任务之间的依赖关系，得到参与组件合并的主组件的合并任务链。关于合并任务链的产生，可以理解为当需要执行特定任务时，该特定任务需要依赖的其他任务也将会被提前执行。参与组件合并的依赖组件中不同目标文件对应的组件编译信息包括每个目标文件在参与组件合并的主组件和参与组件合并的依赖组件中的依赖关系，以及每个目标文件在参与组件合并的依赖组件中被编译后的产物存储路径。

S230、设置回调函数，以在回调函数执行结束之前，完成为每个渠道下的参与组件合并的依赖组件确定组件编译信息的操作，其中，回调函数用于确定合并任务链的执行时机。

在本实施例中，回调函数执行结束意味着各参与组件合并的依赖组件的组件编译信息等相关的需配置信息均完成配置，其中包括以代码或程序注入的方式将不同目标文件合并编译过程中所需的组件编译信息注入该目标文件在参与组件合并的主组件中对应的目标编译任务的操作也执行结束，参与组件合并的主组件的合并任务链才可以被执行。示例性的，在SDK编译的配置阶段，设置回调函数afterEvaluate，用于确定配置阶段需要配置的各项信息均被配置。

S240、基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链中，与参与组件合并的主组件和参与组件合并的依赖组件的各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件。

S250、针对每个渠道，将合并后的各目标文件进行压缩打包得到目标组件。

在上述技术方案的基础上，具体以Gradle系统作为实现组件化合并编译的基础，对本实施例中参与组件合并的主组件和参与组件合并的依赖组件中各目标文件的合并过程进行示例性说明。并且，图3作为示例，示出了针对不同的目标文件，通过代码或程序注入的方式，将相关的组件编译信息注入参与组件合并的主组件中对应的编译任务中，从而得到参与组件合并的主组件的合并任务链的一种示意图，其中，组件编译信息可以包括不同目标文件的预设合并信息或者预设文件拷贝函数等。图3作为一种示例，其中具体包括的任务数量不应理解为对本实施例的具体限定，在实际应用中，合并任务链包括的任务数量可以由实际的组件开发决定。

示例性一：当参与组件合并的主组件和参与组件合并的依赖组件包括AndroidManifest文件时，执行参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件，包括：

针对每个渠道，利用反射继承方式从Gradle系统中获取Manifest合并编译任务；

基于预先设置的AndroidManifest文件在参与组件合并的主组件和参与组件合并的依赖组件中被编译后的产物存储路径，执行Manifest合并编译任务，得到当前渠道下合并后的AndroidManifest文件。

Manifest合并编译任务是指从Gradle系统中获取的适用于对SDK相关组件进行合并编译的任务函数。具体的，针对每个渠道，可以通过反射继承方式从Gradle系统中获取适用于应用程序的组件化合并的官方合并任务(InvokeManifestMerger)，同时对该官方合并任务进行控制参数修改，该控制参数可以包括合并类型，使得该官方合并任务适用于SDK相关组件的合并编译，即合并类型由“应用程序”变更为“库”，参数修改后的官方合并任务即本实施例中的Manifest合并编译任务(任务函数全称可以是：mergeManifestTask)。需要说明的是，Gradle系统中Manifest官方合并任务并不支持SDK相关组件的渠道化合并编译，因此，在获取到Manifest官方合并任务后，需要进行参数修改，使其适用于SDK相关组件。

在参与组件合并的主组件中的Manifest官方合并任务执行结束后，并且在Manifest合并编译任务执行之前，将AndroidManifest文件在参与组件合并的主组件和参与组件合并的依赖组件中被编译后的产物存储路径设置为Manifest合并编译任务的输入路径，并将AndroidManifest文件在参与组件合并的主组件中被编译后的产物存储路径作为Manifest合并编译任务的产出路径，通过执行Manifest合并编译任务，实现AndroidManifest文件的渠道化合并。

其中，利用反射继承方式从Gradle系统中获取Manifest合并编译任务，包括：利用反射继承函数获取Manifest合并编译任务的类对象；基于类对象，利用任务实例创建函数，创建Manifest合并编译任务的任务实例。在获取类对象之前，需要声明类名，示例性的，该声明类名可以是com.android.build.gradle.tasks.InvokeManifestMerger，反射继承函数可以是Class.forName，任务实例创建函数可以是TaskContainer.create。之所以采用反射继承方式，是因为Manifest官方合并任务是一个私有任务，不被公开使用，因此，只能利用反射方式实现继承，得到本实施例所需的Manifest合并编译任务。

示例性二：针对每个渠道，将Resource文件、Jni文件和Assets文件中的任一种作为当前目标文件，在合并任务链中确定与该当前目标文件对应的目标编译任务；

将当前目标文件的预设合并信息，注入对应的目标编译任务中，得到当前目标文件的合并编译任务，其中，预设合并信息包括当前目标文件在参与组件合并的主组件和参与组件合并的依赖组件中的依赖关系，以及当前目标文件在参与组件合并的依赖组件中被编译后的产物存储路径。通过执行每个渠道下目标文件的合并编译任务，任务产出即合并后的目标文件。

例如，在每个渠道下，对Resource文件而言，首先在参与组件合并的主组件的合并任务链中查找Resource文件对应的目标编译任务generateReleaseResources，然后将Resource文件的预设合并信息注入该目标编译任务中，即得到Resource文件对应的合并编译任务；同理，对于Jni文件和Assets文件而言，首先在参与组件合并的主组件的合并任务链中查找Jni文件对应的目标编译任务mergeReleaseJniLibFolders，以及Assets文件对应的目标编译任务packgeReleaseAssets，然后将Jni文件和Assets文件各自的预设合并信息注入对应的目标编译任务中，即得到各自的合并编译任务。目标文件对应的目标编译任务的查找可以通过阅读Gradle官方文档以及源码方式实现。

示例性三：当参与组件合并的主组件和参与组件合并的依赖组件包括Class文件或Jar文件时，执行参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件，包括：

针对每个渠道，将Class文件或Jar文件作为当前目标文件，在合并任务链中确定与该当前目标文件对应的目标编译任务；

在目标编译任务执行结束后，利用预先设置的文件拷贝函数，将参与组件合并的依赖组件中Class文件或Jar文件被编译后的产物文件分别移动至在参与组件合并的主组件中对应的文件目录下，得到当前渠道下合并后的Class文件或Jar文件。

Class文件在合并任务链中对应的目标编译任务是compileReleaseJavaWithJavac，在该目标编译任务执行结束之后，利用预先设置的文件拷贝函数，将参与组件合并的依赖组件编译后的classes.jar文件解压后的classes文件全部拷贝到参与组件合并的主组件中classes文件指定目录下，即实现Class文件的组件化合并。同理，针对Jar文件，其在合并任务链中对应的目标编译任务是tranformClassesAndResourcesWithSyncLibJarsForRelease，在该目标编译任务执行结束之后，将参与组件合并的依赖组件编译后的所有Jar文件全部拷贝至参与组件合并的主组件中Jar文件的指定目录，即实现Jar文件的组件化合并。并且，针对不同的Gradle版本，参与组件合并的主组件中classes文件或Jar文件的指定目录可以不同，即可以根据Gradle版本动态地配置指定目录。

示例性四：当参与组件合并的主组件和参与组件合并的依赖组件包括R文件时，执行参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件，包括：

在每个渠道下，利用内容解析函数，对每个参与组件合并的依赖组件中的R文件进行内容解析，得到R文件中包括的资源标识，其中，资源标识可以是资源ID；

通过每个参与组件合并的依赖组件中的R文件内容与参与组件合并的主组件中的R文件内容进行比较，依据每个参与组件合并的依赖组件中属于参与组件合并的依赖组件和参与组件合并的主组件共有的资源标识，生成每个参与组件合并的依赖组件对应的Java文件；其中，共有资源标识对应的资源才是参与组件合并的主组件中存在以及参与组件合并的主组件需求的资源，因此，通过参与组件合并的主组件和参与组件合并的依赖组件中R文件的内容比较，可以确保R文件合并的有效性；

对每个参与组件合并的依赖组件对应的Java文件进行编译，得到每个参与组件合并的依赖组件对应的类文件，并将各参与组件合并的依赖组件对应的类文件进行打包，得到目标R.jar文件；其中，Gradle系统中提供有JavaCompile任务，只要预先设置该任务的输入路径和输出路径(具体可适应性设置)，就能产出需求的class文件，然后利用JarTask任务对class文件进行打包，即得到目标R.jar文件；

将目标R.jar文件移动至合并任务链执行结束后得到的产物的目标目录下，将目标目录下的各R文件作为当前渠道下合并后的R文件；其中，目标目录与具体的SDK相关组件有关，例如对Library组件而言，该目标目录即lib目录。R文件的合并通常是在参与组件合并的主组件的合并任务链执行结束后合并，因此，目标R.jar文件需要在合并任务链执行结束后移动至指定的产物目标目录下。

当参与组件合并的主组件和参与组件合并的依赖组件中各个目标文件的合并编译完成后，将合并后的各个目标文件进行zip压缩，便得到最终合并的目标组件。

本实施例的技术方案首先通过获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息，同时，利用回调函数确定参与组件合并的主组件的合并任务链的执行时机；在任务执行阶段，基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链中，与参与组件合并的主组件和参与组件合并的依赖组件的各目标文件对应的合并编译任务，实现了基于渠道信息的软件开发工具包相关组件的合并编译，提高了工程编译效率，增加与完善了现有的Gradle系统的组件打包功能，可以更好的满足开发人员的组件化开发需求；并且，由于参与组件合并的主组件和参与组件合并的依赖组件均可以包括Resource文件、Jni文件、Assets文件、AndroidManifest文件、Class文件、Jar文件和R文件，因此，本实施例技术方案同时实现了针对参与组件合并的主组件和参与组件合并的依赖组件中不同文件的合并编译，还解决了现有的组件编译方案fat-aar-plugin不支持R文件合并编译的问题。

图4是本发明实施例公开的一种组件化合并编译装置的结构示意图，本实施例可适用于针对软件开发工具包的组件化开发情况，即对SDK相关组件的合并编译情景。该装置可以采用软件和/或硬件的方式实现，并可集成在任意的具有计算能力的设备上，包括但不限于服务器等。

如图4所示，本发明实施例公开的组件化合并编译装置包括合并组件确定模块310、组件编译信息确定模块320和合并任务链执行模块330，其中：

合并组件确定模块310，用于确定参与组件合并的主组件和参与组件合并的依赖组件；

组件编译信息确定模块320，用于获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息；

合并任务链执行模块330，用于基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

可选的，组件编译信息确定模块320具体用于：

获取参与组件合并的主组件和参与组件合并的依赖组件涉及的渠道信息，并根据参与组件合并的依赖组件涉及的渠道信息以及未携带渠道信息的依赖组件的参考编译信息，分别为每个渠道下的参与组件合并的依赖组件构建组件编译信息，其中，参考编译信息是通过对未携带渠道信息的依赖组件进行自动编译后确定。

可选的，该装置还包括依赖组件确定模块，用于：

在组件编译信息确定模块320执行分别为每个渠道下的参与组件合并的依赖组件确定组件编译信息的操作之前，遍历各个依赖组件，通过与已被自动编译的依赖组件进行名称对比，确定携带有渠道信息的参与组件合并的依赖组件。

可选的，参与组件合并的主组件和参与组件合并的依赖组件是指安卓系统中软件开发涉及的Library组件。

可选的，组件编译信息包括组件被编译后的产物存储路径以及参与组件合并的依赖组件和参与组件合并的主组件之间的依赖关系。

可选的，参与组件合并的主组件和参与组件合并的依赖组件均包括以下目标文件中的至少之一：Resource文件、Jni文件、Assets文件、AndroidManifest文件、Class文件、Jar文件和R文件；

相应的，合并任务链执行模块330包括：

合并编译任务执行单元，用于执行参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件；

目标组件确定单元，用于针对每个渠道，将合并后的各目标文件进行压缩打包得到目标组件。

可选的，针对AndroidManifest文件，合并编译任务执行单元包括：

Manifest合并编译任务获取子单元，用于针对每个渠道，利用反射继承方式从Gradle系统中获取Manifest合并编译任务；

Manifest合并编译任务执行子单元，用于基于预先设置的AndroidManifest文件在参与组件合并的主组件和参与组件合并的依赖组件中被编译后的产物存储路径，执行Manifest合并编译任务，得到当前渠道下合并后的AndroidManifest文件。

可选的，Manifest合并编译任务获取子单元具体用于：

利用反射继承函数获取Manifest合并编译任务的类对象；

基于类对象，利用任务实例创建函数，创建Manifest合并编译任务的任务实例。

可选的，针对R文件，合并编译任务执行单元具体用于：

在每个渠道下，利用内容解析函数，对每个参与组件合并的依赖组件中的R文件进行内容解析，得到R文件中包括的资源标识；

通过每个参与组件合并的依赖组件中的R文件内容与参与组件合并的主组件中的R文件内容进行比较，依据每个参与组件合并的依赖组件中属于参与组件合并的依赖组件和参与组件合并的主组件共有的资源标识，生成每个参与组件合并的依赖组件对应的Java文件；

对每个参与组件合并的依赖组件对应的Java文件进行编译，得到每个参与组件合并的依赖组件对应的类文件，并将各参与组件合并的依赖组件对应的类文件进行打包，得到目标R.jar文件；

将目标R.jar文件移动至合并任务链执行结束后得到的产物的目标目录下，将目标目录下的各R文件作为当前渠道下合并后的R文件。

可选的，合并编译任务执行单元包括：

目标编译任务确定子单元，用于针对每个渠道，将Resource文件、Jni文件和Assets文件中的任一种作为当前目标文件，在合并任务链中确定与该当前目标文件对应的目标编译任务；

合并编译任务确定子单元，用于将当前目标文件的预设合并信息，注入对应的目标编译任务中，得到当前目标文件的合并编译任务，其中，预设合并信息包括当前目标文件在参与组件合并的主组件和参与组件合并的依赖组件中的依赖关系，以及当前目标文件在参与组件合并的依赖组件中被编译后的产物存储路径。

可选的，针对Class文件或Jar文件，合并编译任务执行单元包括：

目标编译任务确定子单元，用于针对每个渠道，将Class文件或Jar文件作为当前目标文件，在合并任务链中确定与该当前目标文件对应的目标编译任务；

产物文件拷贝子单元，用于在所述目标编译任务执行结束后，利用预先设置的文件拷贝函数，将参与组件合并的依赖组件中Class文件或Jar文件被编译后的产物文件分别移动至在参与组件合并的主组件中对应的文件目录下，得到当前渠道下合并后的Class文件或Jar文件。

可选的，该装置还包括回调函数设置模块，用于在合并任务链执行模块330执行基于参与组件合并的主组件涉及的渠道信息以及参与组件合并的依赖组件的组件编译信息，执行参与组件合并的主组件的合并任务链的操作之前，设置回调函数，以在回调函数执行结束之前，完成为每个渠道下的参与组件合并的依赖组件确定组件编译信息的操作，其中，回调函数用于确定合并任务链的执行时机。

可选的，该装置还包括版本信息获取模块，用于：

获取参与组件合并的主组件和参与组件合并的依赖组件支持的安卓系统版本信息和安卓编译版本信息，以分别根据安卓系统版本信息和安卓编译版本信息，将参与组件合并的依赖组件合并至参与组件合并的主组件。

可选的，参与组件合并的依赖组件的组件编译信息还包括组件被编译后的产物名称、产物标识符和合并编译任务信息。

本发明实施例所公开的组件化合并编译装置可执行本发明任意实施例所公开的组件化合并编译方法，具备执行方法相应的功能模块和有益效果。本实施例中未详尽描述的内容可以参考本发明任意方法实施例中的描述。

图5是本发明实施例公开的一种设备的结构示意图。图5示出了适于用来实现本发明实施方式的示例性设备412的框图。图5显示的设备412仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。设备412可以是任意的具有计算能力的设备，包括但不限于服务器。

如图5所示，设备412以通用设备的形式表现。设备412的组件可以包括但不限于：一个或者多个处理器416，存储装置428，连接不同系统组件(包括存储装置428和处理器416)的总线418。

总线418表示几类总线结构中的一种或多种，包括存储装置总线或者存储装置控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(Industry SubversiveAlliance，ISA)总线，微通道体系结构(Micro Channel Architecture，MAC)总线，增强型ISA总线、视频电子标准协会(Video Electronics Standards Association，VESA)局域总线以及外围组件互连(Peripheral Component Interconnect，PCI)总线。

设备412典型地包括多种计算机系统可读介质。这些介质可以是任何能够被设备412访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储装置428可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(Random Access Memory，RAM)430和/或高速缓存存储器432。设备412可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统434可以用于读写不可移动的、非易失性磁介质(图5未显示，通常称为“硬盘驱动器”)。尽管图5中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘，例如只读光盘(Compact Disc Read-Only Memory，CD-ROM),数字视盘(Digital Video Disc-Read Only Memory，DVD-ROM)或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线418相连。存储装置428可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。

具有一组(至少一个)程序模块442的程序/实用工具440，可以存储在例如存储装置428中，这样的程序模块442包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块442通常执行本发明所描述的实施例中的功能和/或方法。

设备412也可以与一个或多个外部设备414(例如键盘、指向终端、显示器424等)通信，还可与一个或者多个使得用户能与该设备412交互的终端通信，和/或与使得该设备412能与一个或多个其它计算终端进行通信的任何终端(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口422进行。并且，设备412还可以通过网络适配器420与一个或者多个网络(例如局域网(Local Area Network，LAN)，广域网(Wide Area Network，WAN)和/或公共网络，例如因特网)通信。如图5所示，网络适配器420通过总线418与设备412的其它模块通信。应当明白，尽管图中未示出，可以结合设备412使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、磁盘阵列(Redundant Arrays of Independent Disks，RAID)系统、磁带驱动器以及数据备份存储系统等。

处理器416通过运行存储在存储装置428中的程序，从而执行各种功能应用以及数据处理，例如实现本发明任意实施例所公开的组件化合并编译方法，该方法可以包括：

确定参与组件合并的主组件和参与组件合并的依赖组件；

获取所述参与组件合并的主组件和所述参与组件合并的依赖组件涉及的渠道信息，并根据所述参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息；

基于所述参与组件合并的主组件涉及的渠道信息以及所述参与组件合并的依赖组件的组件编译信息，执行所述参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

本发明实施例还公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所公开的组件化合并编译方法，该方法可以包括：

确定参与组件合并的主组件和参与组件合并的依赖组件；

获取所述参与组件合并的主组件和所述参与组件合并的依赖组件涉及的渠道信息，并根据所述参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息；

基于所述参与组件合并的主组件涉及的渠道信息以及所述参与组件合并的依赖组件的组件编译信息，执行所述参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

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

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

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

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (14)

1.一种组件化合并编译方法，其特征在于，包括：

确定参与组件合并的主组件和所述参与组件合并的依赖组件；

获取所述参与组件合并的主组件和所述参与组件合并的依赖组件涉及的渠道信息，并根据所述参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息；

基于所述参与组件合并的主组件涉及的渠道信息以及所述参与组件合并的依赖组件的组件编译信息，执行所述参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

2.根据权利要求1所述的方法，其特征在于，根据所述参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息，包括：

根据所述参与组件合并的依赖组件涉及的渠道信息以及未携带渠道信息的依赖组件的参考编译信息，分别为每个渠道下的所述参与组件合并的依赖组件构建所述组件编译信息。

3.根据权利要求2所述的方法，其特征在于，在所述分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息之前，所述方法还包括：

遍历各个依赖组件，通过与已被自动编译的依赖组件进行名称对比，确定携带有渠道信息的所述参与组件合并的依赖组件。

4.根据权利要求1所述的方法，其特征在于，所述参与组件合并的主组件和所述参与组件合并的依赖组件均包括以下目标文件中的至少之一：Resource文件、Jni文件、Assets文件、AndroidManifest文件、Class文件、Jar文件和R文件；

所述执行所述参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件，包括：

执行所述参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件；

针对每个渠道，将合并后的各目标文件进行压缩打包得到所述目标组件。

5.根据权利要求4所述的方法，其特征在于，当所述参与组件合并的主组件和所述参与组件合并的依赖组件包括所述AndroidManifest文件时，所述执行所述参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件，包括：

针对每个渠道，利用反射继承方式从Gradle系统中获取Manifest合并编译任务；

基于预先设置的所述AndroidManifest文件在所述参与组件合并的主组件和所述参与组件合并的依赖组件中被编译后的产物存储路径，执行所述Manifest合并编译任务，得到当前渠道下合并后的AndroidManifest文件。

6.根据权利要求5所述的方法，其特征在于，所述利用反射继承方式从Gradle系统中获取Manifest合并编译任务，包括：

利用反射继承函数获取所述Manifest合并编译任务的类对象；

基于所述类对象，利用任务实例创建函数，创建所述Manifest合并编译任务的任务实例。

7.根据权利要求4所述的方法，其特征在于，当所述参与组件合并的主组件和所述参与组件合并的依赖组件包括所述R文件时，所述执行所述参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件，包括：

在每个渠道下，利用内容解析函数，对每个参与组件合并的依赖组件中的R文件进行内容解析，得到所述R文件中包括的资源标识；

通过所述每个参与组件合并的依赖组件中的R文件内容与所述参与组件合并的主组件中的R文件内容进行比较，依据所述每个参与组件合并的依赖组件中属于所述参与组件合并的依赖组件和所述参与组件合并的主组件共有的资源标识，生成所述每个参与组件合并的依赖组件对应的Java文件；

对所述每个参与组件合并的依赖组件对应的Java文件进行编译，得到所述每个参与组件合并的依赖组件对应的类文件，并将各参与组件合并的依赖组件对应的类文件进行打包，得到目标R.jar文件；

将所述目标R.jar文件移动至所述合并任务链执行结束后得到的产物的目标目录下，将所述目标目录下的各R文件作为当前渠道下合并后的R文件。

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

针对每个渠道，将所述Resource文件、Jni文件和Assets文件中的任一种作为当前目标文件，在所述合并任务链中确定与该当前目标文件对应的目标编译任务；

将所述当前目标文件的预设合并信息，注入对应的目标编译任务中，得到所述当前目标文件的合并编译任务。

9.根据权利要求4所述的方法，其特征在于，当所述参与组件合并的主组件和所述参与组件合并的依赖组件包括所述Class文件或所述Jar文件时，所述执行所述参与组件合并的主组件的合并任务链中与各目标文件对应的合并编译任务，得到每个渠道下合并后的各目标文件，包括：

针对每个渠道，将所述Class文件或Jar文件作为当前目标文件，在所述合并任务链中确定与该当前目标文件对应的目标编译任务；

在所述目标编译任务执行结束后，利用预先设置的文件拷贝函数，将所述参与组件合并的依赖组件中Class文件或Jar文件被编译后的产物文件分别移动至在所述参与组件合并的主组件中对应的文件目录下，得到当前渠道下合并后的Class文件或Jar文件。

10.根据权利要求1所述的方法，其特征在于，在基于所述参与组件合并的主组件涉及的渠道信息以及所述参与组件合并的依赖组件的组件编译信息，执行所述参与组件合并的主组件的合并任务链之前，所述方法还包括：

设置回调函数，以在所述回调函数执行结束之前，完成为所述每个渠道下的所述参与组件合并的依赖组件确定组件编译信息的操作。

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

获取所述参与组件合并的主组件和所述参与组件合并的依赖组件支持的安卓系统版本信息和安卓编译版本信息，以分别根据所述安卓系统版本信息和安卓编译版本信息，将所述参与组件合并的依赖组件合并至所述参与组件合并的主组件。

12.一种组件化合并编译装置，其特征在于，包括：

合并组件确定模块，用于确定参与组件合并的主组件和所述参与组件合并的依赖组件；

组件编译信息确定模块，用于获取所述参与组件合并的主组件和所述参与组件合并的依赖组件涉及的渠道信息，并根据所述参与组件合并的依赖组件涉及的渠道信息，分别为每个渠道下的所述参与组件合并的依赖组件确定组件编译信息；

合并任务链执行模块，用于基于所述参与组件合并的主组件涉及的渠道信息以及所述参与组件合并的依赖组件的组件编译信息，执行所述参与组件合并的主组件的合并任务链，得到每个渠道下合并后的目标组件。

13.一种设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-11中任一所述的组件化合并编译方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-11中任一所述的组件化合并编译方法。