CN110321131B

CN110321131B - 业务组件打包方法、系统及服务器

Info

Publication number: CN110321131B
Application number: CN201910608611.7A
Authority: CN
Inventors: 赵彪; 李丽阳
Original assignee: Beijing Baiyou Technology Co ltd
Current assignee: Beijing Baiyou Technology Co ltd
Priority date: 2019-07-05
Filing date: 2019-07-05
Publication date: 2022-11-08
Anticipated expiration: 2039-07-05
Also published as: CN110321131A

Abstract

本发明提供了业务组件打包方法、系统及服务器，主要包括：首先如果接收到用户输入的打包操作指令，在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个功能组件包括主功能业务组件和多个子功能业务组件；然后将预先编译好的合并脚本信息添加到主功能业务组件中；最后编辑主功能业务组件的项目构建文件，以便于工程项目运行时，执行合并脚本信息，将多个子功能业务组件合并，并嵌入到主功能业务组件进行打包处理。本发明可以很好的兼容多种版本的gradle构建场景，满足用户的多种业务组件打包需求，提高用户体验。

Description

业务组件打包方法、系统及服务器

技术领域

本发明涉及计算机技术领域，尤其是涉及业务组件打包方法、系统及服务器。

背景技术

随着Android技术的广泛应用，Android App(Application，手机软件)开发工具IDE(Integrated Development Environment，集成开发环境)Android Studio可高效为开发者使用，其中，Android Studio创建组件时可以选择类型，当我们选择Android Library的形式构建组件时，可以打包得到一个AAR(Android Archive)包。通常开发一个复杂业务流程的SDK(Software Development Kit，软件开发工具包)项目跟一般应用项目一样，会按照业务拆分成多个组件进行构建，由于一个依赖组件对应一个AAR文件，因此，多个组件进行构建对外提供依赖库时需要提供多个AAR文件。

现有的对多个组件进行打包处理，通常采用gradle构建，但是由于项目输出结构和构建环境有关，因此，难以满足同时兼容新旧版本的gradle构建场景。

发明内容

有鉴于此，本发明的目的在于提供业务组件打包方法、系统及服务器，可以很好的兼容多种版本的gradle构建场景，满足用户的多种业务组件打包需求，提高用户体验。

第一方面，本发明实施例提供了一种业务组件打包方法，应用于服务器，所述方法包括：

如果接收到用户输入的打包操作指令，在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个所述功能组件包括主功能业务组件和多个子功能业务组件；

将预先编译好的合并脚本信息添加到所述主功能业务组件中；

编辑所述主功能业务组件的项目构建文件，以便于所述当前工程项目运行时，执行所述合并脚本信息，将多个所述子功能业务组件合并，并嵌入至所述主功能业务组件进行打包处理。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，所述编辑所述主功能业务组件的项目构建文件的步骤包括：

在所述项目构建文件中添加所述合并脚本信息的应用指令，以及所述子功能业务组件的嵌入指令。

结合第一方面的第一种可能的实施方式，本发明实施例提供了第一方面的第二种可能的实施方式，其中，所述项目构建文件为build.gradle文件，所述在所述项目构建文件中添加所述合并脚本信息的应用指令，以及所述子功能业务组件的嵌入指令的步骤包括：

在所述build.gradle文件中添加所述应用指令和所述嵌入指令，以便于所述合并脚本信息被执行时，对多个所述子功能业务组件进行合并打包处理。

结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，其中，所述主功能业务组件和多个所述子功能业务组件均为*.aar文件。

结合第一方面的第三种可能的实施方式，本发明实施例提供了第一方面的第四种可能的实施方式，其中，所述方法还包括：

根据打包处理之后的主功能业务组件构建出所述主功能业务组件的*.aar文件，并将所述主功能业务组件的*.aar文件关联至所述当前工程项目的文件目录中供宿主工程依赖引用；

其中，打包处理之后的主功能业务组件嵌入有多个合并的所述子功能业务组件。

结合第一方面的第四种可能的实施方式，本发明实施例提供了第一方面的第五种可能的实施方式，其中，所述方法还包括：

将所述主功能业务组件的*.aar文件放入所述宿主工程；

运行所述宿主工程，以对所述主功能业务组件的*.aar文件进行验证。

第二方面，本发明实施例还提供一种业务组件打包系统，应用于服务器，所述系统包括：

查找模块，用于如果接收到用户输入的打包操作指令，在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个所述功能组件包括主功能业务组件和多个子功能业务组件；

添加模块，用于将预先编译好的合并脚本信息添加到所述主功能业务组件中；

编辑模块，用于编辑所述主功能业务组件的项目构建文件，以便于所述当前工程项目运行时，执行所述合并脚本信息，将多个所述子功能业务组件合并，并嵌入至所述主功能业务组件进行打包处理。

结合第二方面，本发明实施例提供了第二方面的第一种可能的实施方式，其中，所述编辑模块还包括：

第三方面，本发明实施例还提供一种服务器，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现第一方面所述的方法的步骤。

第四方面，本发明实施例还提供一种计算机可读介质，其中，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行第一方面所述的方法的步骤。

本发明实施例提供了业务组件打包方法、系统及服务器，应用于服务器，主要包括：首先如果接收到用户输入的打包操作指令，在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个功能组件包括主功能业务组件和多个子功能业务组件；然后将预先编译好的合并脚本信息添加到主功能业务组件中；最后编辑主功能业务组件的项目构建文件，以便于工程项目运行时，执行合并脚本信息，将多个子功能业务组件合并，并嵌入到主功能业务组件进行打包处理。本发明可以很好的兼容多种版本的gradle构建场景，满足用户的多种业务组件打包需求，提高用户体验。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本发明实施例提供的业务组件打包方法的流程图；

图2为本发明实施例提供的业务组件打包原理框图；

图3为本发明实施例提供的业务组件打包方法中验证流程图；

图4为本发明实施例提供的业务组件打包系统的示意图。

图标：

10-查找模块；20-添加模块；30-编辑模块。

具体实施方式

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

为便于对本实施例进行理解，下面对本发明实施例进行详细介绍。

当前，对多个组件进行打包处理最简单的方案是将所有的组件合并为一个总组件，将多个组件的打包转换为一个总组件的打包处理，然后通过Android Studio完成打包处理，但是这种打包方法较为繁琐，属于原先代码未拆分前的老路，为最不优先考虑的方案。其次，还可以使用项目管理工具maven管理aar文件依赖方案，即：使用maven仓库进行远程依赖时，可在其POM((Project Object Model，项目对象模型)文件中看到依赖关系，添加依赖时会自动导入其依赖的其他库，我们可以把每个组件都上传到maven库，上传时会在POM文件中会保留各个组件之间的依赖关系，当用户添加某一库时也可以正确引入其他依赖的库，但是这种方式通常需要gradle构建，在兼容一些旧版本或其他场景下难以直接提供库文件。此外，在对组件进行打包处理时，还可以从打包好的APK(Android Package，安卓安装包)文件中抽取相关代码，然后组成新的aar文件并手动合并；以及把组件构建aar文件时依赖的其他组件进行复制并合并进来打包处理，这些方案虽然也可以实现项目工程中的多个组件的打包处理，但是通常采用gradle构建，由于项目输出结构和构建环境有关，因此，难以满足同时兼容新旧版本的gradle构建场景。

针对这种情况，本发明实施例提供了业务组件打包方法、系统及服务器，通过编写一个merge.gradle合并脚本信息，将工程项目中的多个业务组件进行打包处理，可以很好的兼容多种版本的gradle构建场景，满足用户的多种业务组件打包需求，提高用户体验。

实施例一：

本发明实施例将工程项目中的多个业务组件进行打包处理，合并为一个SDK，并且在SDK上提供一个入口，该过程不依赖内网编译，可以很好的兼容多种版本的gradle构建场景，满足第三方公司直接使用。图1为本发明实施例提供的业务组件打包方法的流程图，参照图1，执行主体为服务器，该打包方法包括以下步骤：

步骤S101，如果接收到用户输入的打包操作指令，在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个功能组件包括主功能业务组件和多个子功能业务组件；

具体地，当接收到用户输入的打包操作指令时，首先在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个功能组件包括主功能业务组件和多个子功能业务组件。为了便于理解，这里举例说明，对于一个Android工程项目，在该工程项目下具有如下的多个功能组件：

app：宿主工程；

lib_1：引用库1；

lib_2：引用库2；

lib_3：引用库3；

main_lib：引用库1、库2、库3，供宿主工程使用；

其中，main_lib为主功能业务组件，lib_1、lib_2、lib_3为多个子功能业务组件，库1、库2、库3为任意依赖库，且，这里主功能业务组件和多个子功能业务组件均为*.aar文件，可以在主功能业务组件和多个子功能业务组件下的build/outputs/aar下找到编译生成的主功能业务组件和多个子功能业务组件得*.aar文件。

步骤S102，将预先编译好的合并脚本信息添加到主功能业务组件中；

具体地，将预先编译好的合并脚本信息添加到主功能业务组件中，且，预先编译好的合并脚本信息为merge.gradle合并脚本信息。其中，由于上述主功能业务组件和多个子功能业务组件均为*.aar文件，因此，本发明实施例中merge.gradle合并脚本信息具体为merge-aar.gradle合并脚本信息。

步骤S103，编辑主功能业务组件的项目构建文件，以便于当前工程项目运行时，执行合并脚本信息，将多个子功能业务组件合并，并嵌入至主功能业务组件进行打包处理。

具体地，上述项目构建文件为build.gradle文件，通过在项目构建文件中添加合并脚本信息的应用指令，以及子功能业务组件的嵌入指令实现上述编辑主功能业务组件的项目构建文件。其中，添加的合并脚本信息的应用指令具体为apply from：merge-aar.gradle，子功能业务组件的嵌入指令具体则是将build.gradle文件中的compile更改为embedded，从而便于合并脚本信息被执行时，对多个子功能业务组件进行合并打包处理。如图2所示，将依赖的主功能业务组件A.aar和多个子功能业务组件A1.aar、A2.aar和A3.aar进行合并打包时，通过将预先编译好的合并脚本信息添加到主功能业务组件A.aar中，以及在build.gradle文件中添加合并脚本信息的应用指令，以及子功能业务组件的嵌入指令，从而构建出打包处理之后的主功能业务组件，且，该构建出的打包处理之后的主功能业务组件嵌入有多个合并的子功能业务组件，同时主功能业务组件A.aar的调用者接入方式保持不变，因此，在依赖该构建出的打包处理之后的主功能业务组件时不需要再重新下载主功能业务组件A.aar内部依赖的其他aar文件。此外，当后期利用网络进行更新操作时，更新一个依赖包也会更新依赖多个依赖包的更新速度快，从而方便用户的多种需求。

此外，对于根据打包处理之后的主功能业务组件构建出的主功能业务组件的*.aar文件，还需放到宿主工程中进行验证。具体地，将构建出的主功能业务组件的*.aar文件关联至当前工程项目的文件目录中供宿主工程依赖引用；其中，打包处理之后的主功能业务组件嵌入有多个合并的子功能业务组件，如图3所示，上述验证过程主要包括以下步骤：

步骤S201，将主功能业务组件的*.aar文件放入宿主工程；

步骤S202，运行宿主工程，以对主功能业务组件的*.aar文件进行验证。

进一步的，在merge-aar.gradle合并脚本信息中，根据aar文件的不同结构，还划分为多个子任务，并根据在项目构建文件定义的embedded属性找到需要合并的子功能业务组件，如果存在embedded属性的依赖，还需定义各个子任务的执行顺序，并在merge-aar.gradle合并脚本信息中定义相关的任务。例如，当合并Assets文件时，将embedded属性依赖的assets路径添加到当前工程项目的assets目录中；当合并Res文件时，通过getMerged Input Resource Sets获取所有aar文件的res资源路径，并将获取的res资源路径添加到当前工程项目的res资源路径中；当合并Proguard时，首先读取embedded属性依赖aar文件中proguard混淆代码，并将上述proguard混淆代码添加到当前工程项目的proguard后面；当合并jni中so文件时，将embedded属性依赖aar文件中jni目录下的所有文件复制到当前工程项目的jni目录中；当根据aar文件中的R.txt文件生成相应的R文件时，首先通过Manifest文件获取相应的包名，然后通过遍历embeddedAarDirs查找每个aar文件中是否存在R.txt文件，并根据查找到的R.txt文件生成相应的R文件，且，所有的id(identity)指向当前工程项目的id。此外，还将generateRClass生成的R文件拷贝到'$build_dir/merge-aar/release/'目录下，以及将'$build_dir/merge-aar/release/'路径中R文件打包进同一个JAR包，放在'$bundle_release_dir/libs/'目录下，并在collecRClass后执行，从而满足用户的多种业务组件打包需求，提高用户体验。

实施例二：

在上述实施例的基础上，本发明实施例还提供了一种业务组件打包系统，该系统应用于服务器，如图4所示的一种业务组件打包系统的示意图。

参照图4，上述系统包括：

查找模块10，用于如果接收到用户输入的打包操作指令，在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个功能组件包括主功能业务组件和多个子功能业务组件；

添加模块20，用于将预先编译好的合并脚本信息添加到主功能业务组件中；

编辑模块30，用于编辑主功能业务组件的项目构建文件，以便于工程项目运行时，执行合并脚本信息，将多个子功能业务组件合并，并嵌入至主功能业务组件进行打包处理。

进一步的，上述编辑模块30还包括：

在项目构建文件中添加合并脚本信息的应用指令，以及子功能业务组件的嵌入指令。

本发明实施例提供了业务组件打包方法、系统及服务器，应用于服务器，主要包括：首先如果接收到用户输入的打包操作指令，在当前工程项目包含的多个功能组件中查找主功能业务组件，其中，多个功能组件包括主功能业务组件和多个子功能业务组件；然后将预先编译好的合并脚本信息添加到主功能业务组件中；最后编辑主功能业务组件的项目构建文件，以便于工程项目运行时，执行合并脚本信息，将多个子功能业务组件合并，并嵌入到主功能业务组件进行打包处理，可以很好的兼容多种版本的gradle构建场景，满足用户的多种业务组件打包需求，提高用户体验。

本发明实施例还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例提供的业务组件打包方法的步骤。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器运行时执行上述实施例的业务组件打包方法的步骤。

本发明实施例所提供的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

另外，在本发明实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

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

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims

1.一种业务组件打包方法，其特征在于，应用于服务器，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述编辑所述主功能业务组件的项目构建文件的步骤包括：

3.根据权利要求2所述的方法，其特征在于，所述项目构建文件为build.gradle文件，所述在所述项目构建文件中添加所述合并脚本信息的应用指令，以及所述子功能业务组件的嵌入指令的步骤包括：

4.根据权利要求1-3任一项所述的方法，其特征在于，所述主功能业务组件和多个所述子功能业务组件均为*.aar文件。

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

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

将所述主功能业务组件的*.aar文件放入所述宿主工程；

7.一种业务组件打包系统，其特征在于，应用于服务器，所述系统包括：

8.根据权利要求7所述的系统，其特征在于，所述编辑模块还包括：

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

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