一种用户定制产品的批量打包方法与流程

本发明涉及软件开发技术领域，尤其涉及一种用户定制产品的批量打包方法。

背景技术：

所谓用户定制产品，例如原始设备制造商(originalequipmentmanufacturer，oem)制造的并卖给第三方代理商的软件产品等，其具有能够根据不同的客户修改产品特性的特点。

正因为用户定制产品具有上述特点，导致不同的第三方代理商对于其私人订制的需求非常多并且非常复杂，例如希望私人订制公司的图标、联系电话、公司的宣传网站等信息，这就导致用户定制产品的oem包越来越多，每次修改都需要复制不同的代码以组成新的oem包，非常不便于管理。并且，当版本升级后，所有的工作进程都需要重新再来一遍，降低处理效率的同时还容易出现错误。

综上，现有的用户定制产品的开发和处理过程中需要投入大量的人力和物力，也会耗费大量的时间，并且无法保证测试效果，这给软件开发过程带来了很多的未知风险。

技术实现要素：

根据现有技术中存在的上述问题，现提供一种用户定制产品的批量打包方法的技术方案，旨在降低用户定制产品打包过程中的人力物力成本，减少打包时间，提升打包效率。

上述技术方案具体包括：

一种用户定制产品的批量打包方法，适用于安卓系统；其中，每个所述用户定制产品具有多个不同的配置信息；

针对同一个批次内的所有所述用户定制产品的所述批量打包方法包括：

步骤s1，形成一用于执行所述用户定制产品的底层逻辑操作的逻辑单元；

步骤s2，形成一用于展示所述用户定制产品的所述产品元素的展示单元；

步骤s3，形成所述逻辑单元与所述展示单元之间的对应关系；

步骤s4，整理所述用户定制产品的所述配置信息，以形成包括不同的所述用户定制产品的配置文件；

步骤s5，根据所述配置文件对同一个批次内的所有所述用户定制产品进行批量打包操作，以分别形成关联于每个所述用户定制产品的产品安装文件；

每个所述产品安装文件中包括所述展示单元中对应于所述用户定制产品的所述配置文件，以及所述逻辑单元中对应于所述用户定制产品的所述底层逻辑操作的代码文件。

优选的，该批量打包方法，其中，所述配置信息包括：

所述用户定制产品的图标信息；和/或

所述用户定制产品的标题信息；和/或

所述用户定制产品的签名信息；和/或

所述用户定制产品对应的代理商主页信息。

优选的，该批量打包方法，其中，所述逻辑单元执行的所述底层逻辑操作包括执行所述用户定制产品的业务代码，以及执行所述用户定制产品的数据协议交互操作。

优选的，该批量打包方法，其中，所述步骤s3中，所述逻辑单元与所述展示单元之间的所述对应关系包括：

所述展示单元依赖于所述逻辑单元工作。

优选的，该批量打包方法，其中，所述展示单元中，针对每个所述用户定制产品形成一对应的产品文件夹，所述产品文件夹中包括对应的所述用户定制产品的所有所述配置信息；

所述步骤s5中，对所述用户定制产品进行打包的过程具体包括：

步骤s51，针对每个所述用户定制产品分别增加一可定义子目录；

步骤s52，针对每个所述用户定制产品分别增加源集节点，每个所述源集节点分别指向所述用户定制产品的源代码目录下对应的所述产品文件夹的存储位置；

步骤s53，针对每个所述用户定制产品分别修改对应的默认配置属性；

步骤s54，对同一个批次内的所有所述用户定制产品进行批量打包操作，以分别形成关联于每个所述用户定制产品的产品安装文件。

优选的，该批量打包方法，其中，所述步骤s5中，通过修改gradle配置脚本对所述用户定制产品进行批量打包。

优选的，该批量打包方法，其中，所述步骤s5中，通过修改gradle配置脚本对所述用户定制产品进行批量打包；

所述步骤s51中，所述可定义子目录为所述gradle配置脚本中的productflavors节点。

优选的，该批量打包方法，其中，所述步骤s5中，通过修改gradle配置脚本对所述用户定制产品进行批量打包；

所述步骤s52中：

所述源集节点为所述gradle配置脚本中的sourcesets节点。

优选的，该批量打包方法，其中，所述步骤s5中，通过修改gradle配置脚本对所述用户定制产品进行批量打包；

所述步骤s53中，所述默认配置属性为所述gradle配置脚本中的defaultconfig属性。

上述技术方案的有益效果是：提供一种用户定制产品的批量打包方法，能够降低用户定制产品打包过程中的人力物力成本，减少打包时间，提升打包效率。

附图说明

图1是本发明的较佳的实施例中，一种用户定制产品的批量打包方法的总体流程示意图；

图2是本发明的较佳的实施例中，于图1的基础上，对用户定制产品进行打包的具体流程示意图。

具体实施方式

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

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

下面结合附图和具体实施例对本发明作进一步说明，但不作为本发明的限定。

本发明的较佳的实施例中，基于现有技术中存在的上述问题，现提供一种用户定制产品的批量打包方法，该方法适用于安卓(android)系统。具体地，每个用户定制产品具有多个不同的配置信息(该配置信息在下文中会详述)。

则上述批量打包方法中，针对同一个批次的所有用户定制产品的批量打包方法具体如图1所示，包括：

步骤s1，形成一用于执行用户定制产品的底层逻辑操作的逻辑单元；

步骤s2，形成一用于展示用户定制产品的产品元素的展示单元；

步骤s3，形成逻辑单元与展示单元之间的对应关系；

步骤s4，整理用户定制产品的配置信息，以形成包括不同的用户定制产品的配置文件；

步骤s5，根据配置文件对同一个批次内的所有用户定制产品进行批量打包操作，以分别形成关联于每个用户定制产品的产品安装文件；

每个产品安装文件中包括展示单元中对应于用户定制产品的配置文件，以及逻辑单元中对应于用户定制产品的底层逻辑操作的代码文件。

具体地，本实施例中，上述用户定制产品即oem产品，因此下文中采用oem产品来替代“用户定制产品”进行描述。

本实施例中，上述步骤s1中形成的逻辑单元即为oem产品应用的逻辑层，该逻辑层主要负责业务代码以及数据协议交互等方面的工作。

本实施例中，上述步骤s2中形成的展示单元即为oem产品应用的展示层，该展示层主要负责显示各个oem产品的工作。

因此，本实施例中，上述步骤s1和步骤s2实际为采用分库的方式，将整个应用划分成逻辑层和展示层两大块。

本实施例中，上文中所述的“逻辑单元”和“展示单元”均为开发和形成oem产品的开发应用的相关单元。换言之，将开发oem产品的开发应用分城逻辑层和展示层两大块。

进一步地，上述步骤s1中形成逻辑单元的方式是抽取应用中的逻辑层代码。

相应地，上述步骤s2中形成展示单元的方式是抽取应用中的展示层代码。

本实施例中，上述步骤s3中，上述逻辑单元和展示单元之间的对应关系具体为：逻辑单元作为展示单元的被依赖单元(即逻辑单元作为展示单元的依赖库)。

即上述步骤s1中，抽取逻辑层的相应代码并形成一个独立的逻辑单元，并将逻辑单元作为核心依赖库；相应地，上述步骤s2中，抽取ui层的相应代码并形成一个独立的展示单元，并把上述逻辑层的业务代码作为展示单元的library包含，即建立逻辑单元和展示单元的依赖关系。

本实施例中，上述步骤s4中，根据上述已被分离的逻辑单元和展示单元，对同一个批次的所有oem产品均进行配置信息的整理，以形成包括该同一个批次的所有oem产品的配置文件。该配置文件在展示单元的存储和展示方式为树形文件夹的方式。该树形文件夹中，根目录为不同的oem产品的产品资源，根目录下的不同的子目录分别代表该oem产品的各个配置信息。

本实施例中，最终应用根据上述已经形成的配置文件，将每个oem产品的文件夹作为一个独立的库进行依次打包，以将同一批次的oem产品批量打包分别形成对应的产品安装文件，该产品安装文件中包括展示单元中对应于用户定制产品的配置文件，以及逻辑单元中对应于用户定制产品的底层逻辑操作的代码文件。

本实施例中，上述步骤s1-s5可以重复进行，以分别对不同批次的oem产品进行批量打包操作。

本发明的较佳的实施例中，上述配置信息中可以包括下文中的至少一种：

用户定制产品的图标信息(logo信息)；

用户定制产品的标题信息；

用户定制产品的签名信息；以及

用户定制产品对应的代理商主页信息。

则本发明的较佳的实施例中，上述树形文件夹中，根目录下的不同的子目录分别表示上述配置信息中的一种。

本发明的较佳的实施例中，上述展示单元中，针对每个用户定制产品形成一对应的产品文件夹，产品文件夹中包括对应的用户定制产品的所有配置信息；

则上述步骤s5中，对用户定制产品进行打包的过程具体如图2中所示，包括：

步骤s51，针对每个用户定制产品分别增加一可定义子节点；

步骤s52，针对每个用户定制产品分别增加源集节点，每个源集节点分别指向用户定制产品的源代码目录下对应的产品文件夹的存储位置；

步骤s53，针对每个用户定制产品分别修改对应的默认配置属性；

步骤s54，对同一个批次内的所有用户定制产品进行批量打包操作，以分别形成关联于每个用户定制产品的产品安装文件。

本发明的较佳的实施例中，对上述oem产品进行打包可以通过修改android系统中的gradle配置脚本实现，即通过修改gradle配置脚本将每个oem产品的文件夹都当作一个独立的库进行打包操作。

具体地，上述步骤s51中，上述可定义子节点即为android系统下的productflavors节点，即上述步骤s51中，针对每个oem产品分别增加对应的一个productflavors节点，有几个oem就增加几个子节点。

上述步骤s52中，上述源集节点即为android系统下的sourcesets节点，针对每个oem文件夹的sourcesets节点分别指向该oem对应的源代码(src)目录下的文件夹的存储位置。

上述步骤s53中，上述默认配置属性即为android系统下的defaultconfig属性。上述每个oem文件夹中若有相同的属性，可以统一在这里进行配置。

上述步骤s54中，最终通过gradle命令执行批量打包操作。具体地，指令下发控制gradlewassemblerelease对所有的release包进行打包，也可以采用gradle指令对指定的oem进行打包。

本发明技术方案中，通过将逻辑层和展示层模块的代码分库拆开，以形成相对独立又具有依赖关系的逻辑单元和展示单元，则每次新增或者修改oem包时，只需要增加或者修改配置节点并修改对应节点目录下的配置文件图片即可。在对oem进行批量打包时核心依赖库的代码只需要编译一次，因此提升了打包速度，并使得开发分工更明确，版本管理更方便。

以上所述仅为本发明较佳的实施例，并非因此限制本发明的实施方式及保护范围，对于本领域技术人员而言，应当能够意识到凡运用本发明说明书及图示内容所作出的等同替换和显而易见的变化所得到的方案，均应当包含在本发明的保护范围内。