CN112612511B - 一种多组件合并打包方法及装置 - Google Patents

一种多组件合并打包方法及装置 Download PDF

Info

Publication number
CN112612511B
CN112612511B CN202011597057.6A CN202011597057A CN112612511B CN 112612511 B CN112612511 B CN 112612511B CN 202011597057 A CN202011597057 A CN 202011597057A CN 112612511 B CN112612511 B CN 112612511B
Authority
CN
China
Prior art keywords
merging
file
main component
aar
folder
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011597057.6A
Other languages
English (en)
Other versions
CN112612511A (zh
Inventor
蔡马坤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Agricultural Bank of China
Original Assignee
Agricultural Bank of China
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agricultural Bank of China filed Critical Agricultural Bank of China
Priority to CN202011597057.6A priority Critical patent/CN112612511B/zh
Publication of CN112612511A publication Critical patent/CN112612511A/zh
Application granted granted Critical
Publication of CN112612511B publication Critical patent/CN112612511B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

本发明提供一种多组件合并打包方法及装置，在触发bundleReleaseAar任务时，对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar并解压缩，得到的文件缓存于主组件下的目标文件夹，调用预设的合并函数，在目标文件夹的路径下，完成文件合并之后执行bundleReleaseAar任务，根据目标文件夹生成目标压缩包aar。通过上述方案，针对不同产品的SDK的开发，无需重复开发，只需配置不同的module完成对SDK的打包，从而利于SDK的管理和集成。此外，配置不同的module就能完成对SDK的打包，减少代码的耦合性，提高代码复用性，提高开发效率和迭代速度。

Description

一种多组件合并打包方法及装置
技术领域
本发明涉及信息处理技术领域，尤其涉及一种多组件合并打包方法及装置。
背景技术
软件开发工具包(Software Development Kit，SDK)是指为了特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。
Android平台开发SDK时通过组件化开发各组件，并将各组件打包成SDK，SDK中每一个组件对应一个目标压缩包aar。第三方的应用将SDK进行输出，SDK中会包含多个aar，若使用SDK的功能，则需同时依赖于多个aar才能实现，从而不利于SDK包的管理和集成。
因此，现有开发SDK的方式不利于SDK的管理和集成。
发明内容
有鉴于此，本发明公开了一种多组件合并打包方法，利于SDK的管理和集成，且能减少代码的耦合性，提高代码复用性，提高了开发效率和迭代速度。
为实现上述目的，本发明实施例提供如下技术方案：
本发明第一方面公开了一种多组件合并打包方法，所述方法包括：
在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar；
对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于所述主组件下的目标文件夹；
根据文件类型调用预设的合并函数，在所述目标文件夹的路径下，对所述解压缩得到的文件进行合并；
在完成文件合并之后，执行所述bundleReleaseAar任务，根据所述目标文件夹生成目标压缩包aar。
优选的，所述预先配置插件和多组件的过程包括：
确定生成SDK所需的主组件；
在所述主组件中配置Gradle插件，所述Gradle插件用于为所述主组件提供合并功能；
基于预设的embed关键字确定所述主组件所依赖的子组件，所述预设的embed关键字用于指示所述主组件所依赖的需要合并的子组件。
优选的，所述根据文件类型调用预设的合并函数，在所述目标文件夹的路径下，对所述解压缩得到的文件进行合并，包括：
针对class.jar类型的文件，调用processClassesAndJars函数，将class.jar文件合并至所述主组件的javac文件夹内；
针对AndroidManifest.xml文件，调用processManifest函数，将所述子组件的AndroidManifest.xml合并至所述主组件的library_manifest文件夹内，所述processManifest函数用于利用ManifestMerger2.Invoker类合并AndroidManifest.xml，使用addManifestProviders函数，将所述AndroidManifest.xml的文件路径添加至ManifestMerger2.Invoker对象中，调用merge函数将所述ManifestMerger2.Invoker对象合并至所述主组件的library_manifest文件夹内；
针对缓存res资源文件的待合并文件夹，调用processResourcesAndR，将所述res资源文件的合并路径指向所述主组件的目标压缩包aar；
针对缓存assets资源文件的待合并文件夹，调用processAssets，将所述assets资源文件的合并路径指向所述主组件的目标压缩包aar；
针对缓存jni资源文件的待合并文件夹，调用processJniLibs，将所述jni资源文件的合并路径指向所述主组件的目标压缩包aar。
优选的，所述在完成文件合并之后，执行所述bundleReleaseAar任务，根据所述目标文件夹生成目标压缩包aar，包括：
在完成文件合并之后，执行所述bundleReleaseAar任务，将路径指向所述主组件的目标压缩包aar的res资源文件、所述asset资源文件和jni资源文件，以及所述主组件的javac文件夹和所述主组件的library_manifest文件夹进行打包，得到目标压缩包aar。
优选的，还包括：
在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息。
优选的，还包括：
在生成目标压缩包aar的过程中，若出现两个或两个以上文件名称相同的待打包文件时，选取任一待打包文件执行打包。
本发明第二方面公开了一种多组件合并打包装置，所述装置包括：
编译模块，用于在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar；
解压缩模块，用于对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于所述主组件下的目标文件夹；
合并模块，用于根据文件类型调用预设的合并函数，在所述目标文件夹的路径下，对所述解压缩得到的文件进行合并；
打包模块，用于在完成文件合并之后，执行所述bundleReleaseAar任务，根据所述目标文件夹生成目标压缩包aar。
优选的：预先配置插件和多组件的预配置模块；
所述预配置模块，具体用于确定生成SDK所需的主组件；在所述主组件中配置Gradle插件，基于预设的embed关键字确定所述主组件所依赖的子组件，所述Gradle插件用于为所述主组件提供合并功能，所述预设的embed关键字用于指示所述主组件所依赖的需要合并的子组件。
优选的，所述打包模块，具体用于在完成文件合并之后，执行所述bundleReleaseAar任务，将路径指向所述主组件的目标压缩包aar的res资源文件、所述asset资源文件和jni资源文件，以及所述主组件的javac文件夹和所述主组件的library_manifest文件夹进行打包，得到目标压缩包aar。
优选的，还包括：第一生成模块；
第一生成模块，用于在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息。
经由上述技术方案可知，在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar，对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于主组件下的目标文件夹，根据文件类型调用预设的合并函数，在目标文件夹的路径下，对解压缩得到的文件进行合并，在完成文件合并之后，执行bundleReleaseAar任务，根据目标文件夹生成目标压缩包aar。通过上述方案，得到的SDK中包含目标压缩包aar，针对不同产品的SDK的开发，无需重复开发，只需配置不同的module完成对SDK的打包，从而利于SDK的管理和集成。此外，配置不同的module就能完成对SDK的打包，能大大减少代码的耦合性，提高代码复用性，提高了开发效率和迭代速度。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明实施例提供的一种多组件合并打包方法的流程示意图；
图2为本发明实施例提供的对解压缩得到的文件进行合并的过程的示意图；
图3为本发明实施例提供的对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于主组件下的目标文件夹的过程的示意图；
图4为本发明实施例提供的预先配置插件和多组件的过程的流程示意图；
图5为本发明实施例提供的根据文件类型调用预设的合并函数，在目标文件夹的路径下，对解压缩得到的文件进行合并的过程的流程示意图；
图6为本发明实施例提供的在完成文件合并之后，执行bundleReleaseAar任务，根据目标文件夹生成目标压缩包aar的过程的流程示意图；
图7为本发明实施例提供的一种多组件合并打包装置的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
由背景技术可知，现有得到的SDK的方式不利于SDK的管理和集成。
为了实现上述目的，本发明实施例公开了一种多组件合并打包方法及装置，针对不同产品的SDK的开发，无需重复开发，只需配置不同的module完成对SDK的打包，从而利于SDK的管理和集成。此外，配置不同的module就能完成对SDK的打包，能大大减少代码的耦合性，提高代码复用性，提高了开发效率和迭代速度。
参见图1，示出了本发明实施例提供的一种多组件合并打包方法的流程示意图，该多组件合并打包方法主要包括如下步骤：
步骤S101：在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar。
在步骤S101中，在触发bundleReleaseAar任务时，即为SDK构建任务名称的过程，启动Android Studio的构建方法，在主组件中配置Gradle插件，基于embed关键字确定主组件所依赖的子组件，将子组件对应的module进行编译，得到子组件生成的压缩包aar。
使用embed关键字依赖需要合并的组件或者第三方组件。
该bundleReleaseAar任务为合并打包入口。
aar是Android提供的一种官方文件形式，aar是一个Zip文件，该文件包含Android里所有的元素。
SDK是指为了特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。
步骤S102：对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于主组件下的目标文件夹。
在步骤S102中，执行子组件对应的module的preReleaseBuild方法，然后依次执行所有通过preReleaseBuild方法生成对应的module的aar，当preReleaseBuild执行完成后解压所有aar并缓存于主组件下的目标文件夹。
步骤S103：根据文件类型调用预设的合并函数，在目标文件夹的路径下，对解压缩得到的文件进行合并。
在步骤S103中，文件类型包括class.jar类型、AndroidManifest.xmlw文件、缓存res资源文件和缓存assets资源文件和缓存jni资源文件。
Android平台下的aar合并方法，基于Gradle构建工具完成的合并构建方法。
根据文件类型调用预设的合并函数，在目标文件夹的路径下，对解压缩得到的文件进行合并的过程如下：
针对class.jar类型的文件，调用processClassesAndJars函数，将class.jar文件合并至主组件的javac文件夹内。
针对AndroidManifest.xml文件，调用processManifest函数，将子组件的AndroidManifest.xml合并至主组件的library_manifest文件夹内，processManifest函数用于利用ManifestMerger2.Invoker类合并AndroidManifest.xml，使用addManifestProviders函数，将AndroidManifest.xml的文件路径添加至ManifestMerger2.Invoker对象中，调用merge函数将ManifestMerger2.Invoker对象合并至主组件的library_manifest文件夹内。
针对缓存res资源文件的待合并文件夹，调用processResourcesAndR，将res资源文件的合并路径指向主组件的目标压缩包aar。
针对缓存assets资源文件的待合并文件夹，调用processAssets，将assets资源文件的合并路径指向主组件的目标压缩包aar。
针对缓存jni资源文件的待合并文件夹，调用processJniLibs函数，将jni资源文件的合并路径指向主组件的目标压缩包aar。
步骤S104：在完成文件合并之后，执行bundleReleaseAar任务，根据目标文件夹生成目标压缩包aar。
在步骤S104中，目标压缩包aar为开发完成的最终的SDK，该SDK中依赖所有module的源代码即资源，供第三方合作方集成调用。
执行bundleReleaseAar任务会把主组件的javac文件夹里的class文件打包成一个完成的class.jar，即生成目标压缩包aar。
为了方便理解对解压缩得到的文件进行合并的过程，可参考图2，图2示出了解压缩得到的文件进行合并的示意图。
图2中，account.aar、network.aar、common.aar和pay.aar为在目标文件夹的路径下解压缩得到的文件。
将class.jar文件合并至主组件的文件夹内。
将AndroidManifest.xml合并至主组件的文件夹内。
将res资源文件合并至主组件的文件夹内。
将asset资源文件合并至主组件的文件夹内。
将jni资源文件合并至主组件的文件夹内。
在完成文件合并aar之后生成SDK，SDK中包含SDK.aar。
为了方便理解对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于主组件下的目标文件夹的过程，可参考图3，图3示出了对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于主组件下的目标文件夹的示意图。
图3中，解压exploded-aar得到的文件缓存于临时文件夹com.facebook.fresco和com.facebook.soloader中，解压lib-aar得到的文件缓存于临时文件夹flavor1Debug中。
本发明实施例中，针对不同产品的SDK的开发，无需重复开发，只需配置不同的module完成对SDK的打包，从而利于SDK的管理和集成。此外，配置不同的module就能完成对SDK的打包，能减少代码的耦合性，提高代码复用性，提高了开发效率和迭代速度。
在上述步骤S101中涉及到预先配置插件和多组件的过程，如图4所示，具体包括如下步骤：
步骤S401：确定生成SDK所需的主组件。
在步骤S401中，主组件为构建SDK主体框架的组件，主组件的个数可以为多个，每个主组件所依赖的组件为子组件。
步骤S402：在主组件中配置Gradle插件。
在步骤S402中，Gradle插件用于为主组件提供合并功能。
在配置插件的过程中需使用Gradle插件或者具有Gradle插件功能的其他插件。
步骤S403：基于预设的embed关键字确定主组件所依赖的子组件。
在步骤S403中，预设的embed关键字用于指示主组件所依赖的需要合并的子组件。
使用project.configurations.create创建embed关键字，若不创建embed关键字，则在根据预先配置的插件对预先配置的多组件进行编译的过程中会报错，通过embed关键字依赖的所有组件，使用集合缓存这些组件的名称。
本发明实施例中，确定生成SDK所需的主组件，在主组件中配置Gradle插件，基于预设的embed关键字确定主组件所依赖的子组件，实现配置Gradle插件和确定主组件所依赖的子组件的目的。
在上述步骤S103中涉及到根据文件类型调用预设的合并函数，在目标文件夹的路径下，对解压缩得到的文件进行合并的过程，如图5所示，具体包括如下步骤：
步骤S501：针对class.jar类型的文件，调用processClassesAndJars函数，将class.jar文件合并至主组件的javac文件夹内。
步骤S502：针对AndroidManifest.xml文件，调用processManifest函数，将子组件的AndroidManifest.xml文件合并至主组件的library_manifest文件夹内。
在步骤S502中，processManifest函数用于利用ManifestMerger2.Invoker类合并AndroidManifest.xml，使用addManifestProviders函数，将AndroidManifest.xml的文件路径添加至ManifestMerger2.Invoker对象中，调用merge函数将ManifestMerger2.Invoker对象合并至主组件的library_manifest文件夹内。
步骤S503：针对缓存res资源文件的待合并文件夹，调用processResourcesAndR，将res资源文件的合并路径指向主组件的目标压缩包aar。
在步骤S503中，调用processResourcesAndR，则是使用Gradle插件的srcDIR闭包设置主组件的文件路径。
processResourcesAndR使用的是DefaultAndroidSourceSet.res.srcDir函数，指向所有res资源文件的文件路径，bundleReleaseAar任务将所有的res资源文件全部打包到主组件的目标压缩包aar。
步骤S504：针对缓存assets资源文件的待合并文件夹，调用processAssets，将assets资源文件的合并路径指向主组件的目标压缩包aar。
在步骤S504中，processAssets使用的是sourceSets.assets.srcDir函数，指向asset资源文件的文件路径，bundleReleaseAar任务将所有的asset资源文件全部打包到主组件的目标压缩包aar。
步骤S505：针对缓存jni资源文件的待合并文件夹，调用processJniLibs，将jni资源文件的合并路径指向主组件的目标压缩包aar。
在步骤S505中，processJniLibs使用的是sourceSets.jniLibs.srcDir函数，指向jni资源文件的文件路径，bundleReleaseAar任务将所有的jni资源文件全部打包到主组件的目标压缩包aar。
本发明实施例中，根据文件类型调用预设的合并函数，在目标文件夹的路径下，实现对解压缩得到的文件进行合并的目的。
可选的，在进行文件合并过程中，若待合并的两个或多个资源文件的资源名称相同且预先添加的标签相同，确定两个或多个资源文件存在冲突，并丢弃。
当确定两个或多个资源文件存在冲突时，bundleReleaseAar任务会抛异常，并丢弃。
本发明实施例中，若待合并的两个或多个资源文件的资源名称相同且预先添加的标签相同，确定两个或多个资源文件存在冲突，并丢弃，避免在文件合并完成后执行bundleReleaseAar任务时出现资源文件冲突。
在步骤S104中涉及到在完成文件合并之后，执行bundleReleaseAar任务，根据目标文件夹生成目标压缩包aar的过程，如图6所示，具体包括如下步骤：
步骤S601：在完成文件合并之后，执行bundleReleaseAar任务。
步骤S602：将路径指向主组件的目标压缩包aar的res资源文件、assets资源文件和jni资源文件，以及主组件的javac文件夹和主组件的library_manifest文件夹进行打包，得到目标压缩包aar。
本发明实施例中，在完成文件合并之后，执行bundleReleaseAar任务，将路径指向主组件的目标压缩包aar的res资源文件、assets资源文件和jni资源文件，以及主组件的javac文件夹和主组件的library_manifest文件夹进行打包，实现得到目标压缩包aar的目的。
可选的，在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息。
其中，报错信息用于提示对出现文件名称相同的文件进行修改。
本发明实施例中，在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息，实现通过报错信息提示对出现文件名称相同的文件进行修改的目的。
可选的，在生成目标压缩包aar的过程中，若出现两个或两个以上文件名称相同的待打包文件时，选取任一待打包文件执行打包。
可选的，在生成目标压缩包aar的过程中，若出现两个或两个以上文件名称相同的待打包文件时，选取第一个待打包文件执行打包。
本发明实施例中，在生成目标压缩包aar的过程中，若出现两个或两个以上文件名称相同的待打包文件时，选取任一待打包文件执行打包或选取第一个待打包文件执行打包，实现对待打包文件执行打包的目的。
基于上述实施例图1公开的一种多组件合并打包方法，本发明实施例还对应公开了一种多组件合并打包装置的结构示意图，如图7所示，该多组件合并打包装置主要包括编译模块、解压缩模块、合并模块和打包模块。
编译模块701，用于在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar。
解压缩模块702，用于对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于所述主组件下的目标文件夹。
合并模块703，用于根据文件类型调用预设的合并函数，在所述目标文件夹的路径下，对所述解压缩得到的文件进行合并。
打包模块704，用于在完成文件合并之后，执行所述bundleReleaseAar任务，根据所述目标文件夹生成目标压缩包aar。
可选的，还包括预先配置插件和多组件的预配置模块。
预配置模块，具体用于确定生成SDK所需的主组件；在主组件中配置Gradle插件，基于预设的embed关键字确定主组件所依赖的子组件，Gradle插件用于为主组件提供合并功能，预设的embed关键字用于指示主组件所依赖的需要合并的子组件。
进一步的，合并模块703，包括：
第一合并单元，用于针对class.jar类型的文件，调用processClassesAndJars函数，将class.jar文件合并至主组件的javac文件夹内。
第二合并单元，用于针对AndroidManifest.xml文件，调用processManifest函数，将子组件的AndroidManifest.xml文件合并至主组件的library_manifest文件夹内，processManifest函数用于利用ManifestMerger2.Invoker类合并AndroidManifest.xml，使用addManifestProviders函数，将AndroidManifest.xml的文件路径添加至ManifestMerger2.Invoker对象中，调用merge函数将ManifestMerger2.Invoker对象合并至主组件的library_manifest文件夹内。
第一指向单元，用于针对缓存res资源文件的待合并文件夹，调用processResourcesAndR，将res资源文件的合并路径指向主组件的目标压缩包aar。
第二指向单元，用于针对缓存assets资源文件的待合并文件夹，调用processAssets，将assets资源文件的合并路径指向主组件的目标压缩包aar。
第三指向单元，用于针对缓存jni资源文件的待合并文件夹，调用processJniLibs函数，将jni资源文件的合并路径指向主组件的目标压缩包aar。
进一步的，打包模块704，具体用于在完成文件合并之后，执行bundleReleaseAar任务，将路径指向主组件的目标压缩包aar的res资源文件、asset资源文件和jni资源文件，以及主组件的javac文件夹和主组件的library_manifest文件夹进行打包，得到目标压缩包aar。
可选的，还包括：第一生成模块。
第一生成模块，用于在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息。
可选的，还包括：第二生成模块。
第二生成模块，用于在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息。
可选的，还包括：选取模块。
选取模块，用于在生成目标压缩包aar的过程中，若出现两个或两个以上文件名称相同的待打包文件时，选取任一待打包文件执行打包。
本发明实施例中公开了一种多组件合并打包装置，在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar，对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于主组件下的目标文件夹，根据文件类型调用预设的合并函数，在目标文件夹的路径下，对解压缩得到的文件进行合并，在完成文件合并之后，执行bundleReleaseAar任务，根据目标文件夹生成目标压缩包aar。通过上述装置，得到的SDK中包含目标压缩包aar，针对不同产品的SDK的开发，无需重复开发，只需配置不同的module完成对SDK的打包，从而利于SDK的管理和集成。此外，配置不同的module就能完成对SDK的打包，能大大减少代码的耦合性，提高代码复用性，提高了开发效率和迭代速度。
对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于系统类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本发明各实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (7)

1.一种多组件合并打包方法，其特征在于，所述方法包括：
在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar；
对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于所述主组件下的目标文件夹；
根据文件类型调用预设的合并函数，在所述目标文件夹的路径下，对所述解压缩得到的文件进行合并；
在完成文件合并之后，执行所述bundleReleaseAar任务，根据所述目标文件夹生成目标压缩包aar；
其中，所述根据文件类型调用预设的合并函数，在所述目标文件夹的路径下，对所述解压缩得到的文件进行合并，包括：
针对class.jar类型的文件，调用processClassesAndJars函数，将class.jar文件合并至所述主组件的javac文件夹内；
针对AndroidManifest.xml文件，调用processManifest函数，将所述子组件的AndroidManifest.xml合并至所述主组件的library_manifest文件夹内，所述processManifest函数用于利用ManifestMerger2.Invoker类合并AndroidManifest.xml，使用addManifestProviders函数，将所述AndroidManifest.xml的文件路径添加至ManifestMerger2.Invoker对象中，调用merge函数将所述ManifestMerger2.Invoker对象合并至所述主组件的library_manifest文件夹内；
针对缓存res资源文件的待合并文件夹，调用processResourcesAndR，将所述res资源文件的合并路径指向所述主组件的目标压缩包aar；
针对缓存assets资源文件的待合并文件夹，调用processAssets，将所述assets资源文件的合并路径指向所述主组件的目标压缩包aar；
针对缓存jni资源文件的待合并文件夹，调用processJniLibs，将所述jni资源文件的合并路径指向所述主组件的目标压缩包aar；
其中，所述在完成文件合并之后，执行所述bundleReleaseAar任务，根据所述目标文件夹生成目标压缩包aar，包括：
在完成文件合并之后，执行所述bundleReleaseAar任务，将路径指向所述主组件的目标压缩包aar的res资源文件、所述assets资源文件和jni资源文件，以及所述主组件的javac文件夹和所述主组件的library_manifest文件夹进行打包，得到目标压缩包aar。
2.根据权利要求1所述的方法，其特征在于，所述预先配置插件和多组件的过程包括：
确定生成SDK所需的主组件；
在所述主组件中配置Gradle插件，所述Gradle插件用于为所述主组件提供合并功能；
基于预设的embed关键字确定所述主组件所依赖的子组件，所述预设的embed关键字用于指示所述主组件所依赖的需要合并的子组件。
3.根据权利要求1或2所述的方法，其特征在于，还包括：
在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息。
4.根据权利要求1或2所述的方法，其特征在于，还包括：
在生成目标压缩包aar的过程中，若出现两个或两个以上文件名称相同的待打包文件时，选取任一待打包文件执行打包。
5.一种多组件合并打包装置，其特征在于，所述装置包括：
编译模块，用于在触发bundleReleaseAar任务时，根据预先配置的插件对预先配置的多组件进行编译，得到主组件所依赖的每一子组件生成的压缩包aar；
解压缩模块，用于对生成的所有压缩包aar进行解压缩，并将解压缩得到的文件缓存于所述主组件下的目标文件夹；
合并模块，用于根据文件类型调用预设的合并函数，在所述目标文件夹的路径下，对所述解压缩得到的文件进行合并；
打包模块，用于在完成文件合并之后，执行所述bundleReleaseAar任务，根据所述目标文件夹生成目标压缩包aar；
其中，所述合并模块，包括：
第一合并单元，用于针对class.jar类型的文件，调用processClassesAndJars函数，将class.jar文件合并至所述主组件的javac文件夹内；
第二合并单元，用于针对AndroidManifest.xml文件，调用processManifest函数，将所述子组件的AndroidManifest.xml合并至所述主组件的library_manifest文件夹内，所述processManifest函数用于利用ManifestMerger2.Invoker类合并AndroidManifest.xml，使用addManifestProviders函数，将所述AndroidManifest.xml的文件路径添加至ManifestMerger2.Invoker对象中，调用merge函数将所述ManifestMerger2.Invoker对象合并至所述主组件的library_manifest文件夹内；
第一指向单元，用于针对缓存res资源文件的待合并文件夹，调用processResourcesAndR，将所述res资源文件的合并路径指向所述主组件的目标压缩包aar；
第二指向单元，用于针对缓存assets资源文件的待合并文件夹，调用processAssets，将所述assets资源文件的合并路径指向所述主组件的目标压缩包aar；
第三指向单元，用于针对缓存jni资源文件的待合并文件夹，调用processJniLibs，将所述jni资源文件的合并路径指向所述主组件的目标压缩包aar；
其中，所述打包模块具体用于在完成文件合并之后，执行所述bundleReleaseAar任务，将路径指向所述主组件的目标压缩包aar的res资源文件、所述assets资源文件和jni资源文件，以及所述主组件的javac文件夹和所述主组件的library_manifest文件夹进行打包，得到目标压缩包aar。
6.根据权利要求5所述的装置，其特征在于，还包括：预先配置插件和多组件的预配置模块；
所述预配置模块，具体用于确定生成SDK所需的主组件；在所述主组件中配置Gradle插件，基于预设的embed关键字确定所述主组件所依赖的子组件，所述Gradle插件用于为所述主组件提供合并功能，所述预设的embed关键字用于指示所述主组件所依赖的需要合并的子组件。
7.根据权利要求5或6所述的装置，其特征在于，还包括：第一生成模块；
所述第一生成模块，用于在生成目标压缩包aar的过程中，若待打包的文件的文件名称相同，生成报错信息。
CN202011597057.6A 2020-12-28 2020-12-28 一种多组件合并打包方法及装置 Active CN112612511B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011597057.6A CN112612511B (zh) 2020-12-28 2020-12-28 一种多组件合并打包方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011597057.6A CN112612511B (zh) 2020-12-28 2020-12-28 一种多组件合并打包方法及装置

Publications (2)

Publication Number Publication Date
CN112612511A CN112612511A (zh) 2021-04-06
CN112612511B true CN112612511B (zh) 2023-06-30

Family

ID=75248966

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011597057.6A Active CN112612511B (zh) 2020-12-28 2020-12-28 一种多组件合并打包方法及装置

Country Status (1)

Country Link
CN (1) CN112612511B (zh)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110321131A (zh) * 2019-07-05 2019-10-11 北京百佑科技有限公司 业务组件打包方法、系统及服务器

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9367530B2 (en) * 2011-01-21 2016-06-14 Jive Software Distributed document co-authoring and processing
US20160026366A1 (en) * 2014-07-22 2016-01-28 Runfeng LUAN Method and system for customizing mobile terminal application

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110321131A (zh) * 2019-07-05 2019-10-11 北京百佑科技有限公司 业务组件打包方法、系统及服务器

Also Published As

Publication number Publication date
CN112612511A (zh) 2021-04-06

Similar Documents

Publication Publication Date Title
Chudnov et al. Continuous formal verification of Amazon s2n
US8595700B2 (en) Method and apparatus for reusing components of a component-based software system
CN104346184A (zh) 应用打包装置及方法
CN111290780B (zh) 一种自动化上传SDK到maven仓库的方法
CN109766099A (zh) 前端源码编译方法、装置、存储介质及计算机设备
Sommer et al. Spicy: a unified deep packet inspection framework for safely dissecting all your data
CN108647142B (zh) 一种Gatling压测脚本本地预编译调试方法及系统
CN112612511B (zh) 一种多组件合并打包方法及装置
US10606569B2 (en) Declarative configuration elements
Sillito et al. Use case level pointcuts
Dejon et al. Automated security analysis of IoT software updates
CN106648770A (zh) 一种应用程序安装包的生成方法、加载方法及装置
Ba et al. Composing web services with PEWS: A trace-theoretical approach
CN101145954A (zh) 通讯功能打桩类实现方法
Strittmatter et al. Supplementary material for the evaluation of the layered reference architecture for metamodels to tailor quality modeling and analysis
Brogi et al. Workflow semantics of peer and service behaviour
CN113934460A (zh) 一种资源提供方法及装置
Liu et al. ReuNify: A Step Towards Whole Program Analysis for React Native Android Apps
Lau et al. (Behavioural) design patterns as composition operators
Knecht et al. CASC: Content Addressed Smart Contracts
Parrend Enhancing automated detection of vulnerabilities in java components
CN116893821A (zh) Gradle插件、产物部署方法、介质和计算设备
US9772826B2 (en) Build-time resolving and type checking references
Götzelmann et al. The Design of the European Ground Systems-Common Core (EGS-CC)
CN113312026A (zh) 一种app开发方法和系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant