CN112596746B - 应用安装包生成方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种应用安装包生成方法、装置、计算机设备和存储介质。所述方法包括：获取目标应用的至少两个应用用户分别对应的需求信息；创建所述目标应用的应用开发项目所对应的公用配置文件；根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息；基于各所述应用配置信息，分别配置各所述应用用户各自对应的资源文件；根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包。采用本方法能够降低应用开发成本。

Description

应用安装包生成方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种应用安装包生成方法、装置、计算机设备和存储介质。

背景技术

随着计算机技术的发展，计算机设备上应用程序的使用越来越普遍。通常应用开发工作主要集中在开发人员身上，由于不同的用户可能会存在不同的需求，这样随着用户量的增加，应用开发中需求会越来越多，需求变化也会越来越多。开发人员在依据大量不同的需求进行应用开发时，开发代码量会大大增加且复杂，另外还包括大量冗余代码，不利于代码维护，从而导致应用开发成本高。

发明内容

基于此，有必要针对上述技术问题，提供一种降低应用开发成本的应用安装包生成方法、装置、计算机设备和存储介质。

一种应用安装包生成方法，所述方法包括：

获取目标应用的至少两个应用用户分别对应的需求信息；

创建所述目标应用的应用开发项目所对应的公用配置文件；

根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息；

基于各所述应用配置信息，分别配置各所述应用用户各自对应的资源文件；

根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包。

在一个实施例中，所述方法还包括：

在所述公用配置文件的第一区域统一配置公用资源库；所述公用资源库中的公用资源包括界面资源和网络资源中的至少一种；

所述根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息，包括：

根据各所述需求信息，在所述公用配置文件中的第二区域分别配置各所述应用用户各自对应的应用配置信息；其中，当所述需求信息的功能实现需要调用公用资源时，所述应用配置信息中包括调用所述公用资源的路径。

在一个实施例中，所述根据各所述需求信息，在所述公用配置文件中的第二区域分别配置各所述应用用户各自对应的应用配置信息，包括：

在所述公用配置文件中的第二区域，根据各所述应用用户所对应的需求信息分区扩展各所述应用用户所对应的应用配置信息；其中，每个分区包括按照配置节点分别配置的其中一个应用用户的应用标识、应用签名及专用资源路径；不同分区的应用配置信息包括差异化的应用标识。

在一个实施例中，所述方法还包括：

当新增应用用户、且新增的所述应用用户所对应的需求信息与已有的需求信息不一致时，根据新增的所述需求信息，在所述第二区域中已有的应用配置信息之后继续配置新增的所述应用用户所对应的应用配置信息。

在一个实施例中，所述应用配置信息还包括应用版本信息；所述方法还包括：

当已有的需求信息发生变更时，确定发生变更的需求信息对应的目标节点；

根据发生变更的需求信息对所述目标节点处的应用配置信息进行修改；

更新所述目标节点所属应用配置信息的应用版本信息。

在一个实施例中，所述根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包，包括：

配置应用清单文件，并将所述公用配置文件引入所述应用清单文件；

执行打包脚本，在执行所述打包脚本的过程中装配所述应用清单文件，通过装配所述应用清单文件加载所述公用配置文件，以根据至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包。

在一个实施例中，所述执行打包脚本，在执行所述打包脚本的过程中装配所述应用清单文件，通过装配所述应用清单文件加载所述公用配置文件，以根据至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包，包括：

执行打包脚本，在执行所述打包脚本的过程中装配所述应用清单文件，通过装配所述应用清单文件加载所述公用配置文件；

当所述打包脚本的打包字段指定应用用户时，根据指定的应用用户所对应的资源文件，生成指定的应用用户所对应的目标应用安装包；

当所述打包脚本的打包字段未指定应用用户时，根据各所述应用用户所对应的资源文件，批量生成各所述应用用户分别对应的目标应用安装包。

在一个实施例中，所述目标应用为组织应用，所述应用用户为组织用户。

一种应用安装包生成装置，其特征在于，所述装置包括：

获取模块，用于获取目标应用的至少两个应用用户分别对应的需求信息；

创建模块，用于创建所述目标应用的应用开发项目所对应的公用配置文件；

配置模块，用于根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息；基于各所述应用配置信息，分别配置各所述应用用户各自对应的资源文件；

生成模块，用于根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

获取目标应用的至少两个应用用户分别对应的需求信息；

创建所述目标应用的应用开发项目所对应的公用配置文件；

根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息；

基于各所述应用配置信息，分别配置各所述应用用户各自对应的资源文件；

根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

获取目标应用的至少两个应用用户分别对应的需求信息；

创建所述目标应用的应用开发项目所对应的公用配置文件；

根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息；

基于各所述应用配置信息，分别配置各所述应用用户各自对应的资源文件；

根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包。

上述应用安装包生成方法、装置、计算机设备和存储介质，自动获取不同应用用户分别对应的需求信息，创建目标应用的应用开发项目所对应的公用配置文件；随后根据各应用用户的需求信息，在统一的公用配置文件中分别配置各应用用户各自的应用配置信息，进而基于各应用用户的应用配置信息，分别配置各应用用户各自的资源文件。这样在进行应用程序打包时，可以根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包；也就是对于同一款目标应用，对于不同的应用用户会结合其需求开发打包出与其需求适配的目标应用供使用，可以减少冗余代码，减少代码量，以及减少开发人员数量，进而降低开发成本，而且在一个公用配置文件中批量配置差异化的应用配置信息便于代码维护。

附图说明

图1为一个实施例中应用安装包生成方法的流程示意图；

图2为一个实施例中应用安装包生成装置的结构框图；

图3为一个实施例中计算机设备的内部结构图；

图4为另一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种应用安装包生成方法，本实施例以该方法应用于终端进行举例说明，可以理解的是，该方法也可以应用于服务器，还可以应用于包括终端和服务器的系统，并通过终端和服务器的交互实现。其中，终端可以但不限于是各种个人计算机、笔记本电脑、智能手机和平板电脑，服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。本实施例中，该应用安装包生成方法包括以下步骤：

步骤102，获取目标应用的至少两个应用用户分别对应的需求信息。

其中，目标应用是待开发的应用程序，应用程序是为了得到某种结果而可以由计算机等具有信息处理能力的终端执行的代码化指令序列，或者可以被自动转换成代码化指令序列的符号化指令序列或者符号化语句序列。目前，用户可以在终端上安装各种应用程序，如拍照应用程序、社交应用程序或者邮件应用程序等，从而通过终端上安装的这些应用可以实现各种功能，如拍照功能、社交功能或者电子邮件管理功能等。

在一个实施例中，目标应用可以是基于组织的应用程序，比如企业即时通讯应用。组织是多个对象按一定方式相互结合而成的集团或团体，比如学校、班级、企业、部门或者群组等。目标应用可以是基于个人的应用程序，比如个人即时通讯应用。那么基于此，在目标应用是基于组织的应用程序时，目标应用的应用用户为组织用户，比如企业或者学校等。在目标应用是基于个人的应用程序时，目标应用的应用用户为个人用户，比如自然人小甲或者小乙等。

需要说明的是，本申请对目标应用所运行的计算机设备的操作系统不作限定。目标应用所运行的计算机设备的操作系统可以是视窗(Windows)操作系统或Linux操作系统或Mac OS(苹果桌面操作系统)等桌面操作系统，也可以是 iOS(苹果移动终端操作系统)或者安卓(Android)操作系统等移动操作系统。

具体地，需求信息是反映应用用户对目标应用在功能上需求的信息。可以理解，目标用户通常会存在至少两个应用用户，这些应用用户的需求信息可能相同也可能不同，计算机设备可获取这些应用用户各自对应的需求信息。

步骤104，创建目标应用的应用开发项目所对应的公用配置文件。

其中，应用开发项目是对目标应用进行开发的程序项目。公用配置文件是应用开发项目公用的配置文件。公用配置文件中可配置应用开发项目开发的目标应用的需求。在一个实施例中，每个应用开发项目存在唯一对应的公用配置文件。

步骤106，根据各需求信息，在公用配置文件中分别配置各应用用户各自对应的应用配置信息。

其中，应用配置信息是根据需求信息为目标应用专门配置的功能个性化的配置信息。应用配置信息配置了应用程序运行时所需要资源的路径。

可以理解，在不同的应用用户的需求信息存在差异时，这不同的应用用户各自对应的应用配置信息不同；在不同的应用用户的需求信息不存在差异时，这不同的应用用户各自对应的应用配置信息相同。

在一个实施例中，计算机设备可针对目标应用的每个应用用户，分别配置该应用用户所对应的应用配置信息。这样可以方便对每个应用用户进行单独管理，便于初始需求相同的应用用户在后续产生不同的需求时的应用开发处理。

在一个实施例中，计算机设备可针对目标应用的每种需求信息，分别配置该需求信息所对的应用配置信息。这样可以避免对相同的需求重复开发，避免资源浪费。此时，步骤102包括：获取目标应用的所有应用用户分别对应的需求信息，对这些需求信息进行一致性比较，在这些需求信息不一致时，筛选出各不相同的至少两种需求信息。举例说明，假设目标应用存在A、B、C、D和 E五个应用用户，A、B和D的需求信息为需求1，C和E的需求信息为需求2，此时则存在两种需求信息；若A和D的需求信息为需求1，C和E的需求信息为需求2，B的需求信息为需求3，此时则存在三种需求信息。

步骤108，基于各应用配置信息，分别配置各应用用户各自对应的资源文件。

具体地，计算机设备在得到各应用用户各自对应的应用配置信息后，对于每个应用用户，根据该应用用户的应用配置信息配置具体的资源文件。资源文件可包括具体的差异化逻辑、页面、布局以及样式等代码。且各应用用户各自对应的资源文件可存储至指定文件名的文件夹中进行区分管理。

步骤110，根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，步骤110，包括：配置应用清单文件，并将公用配置文件引入应用清单文件；执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件，以根据至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

具体地，应用清单文件是每个应用程序的根目录中必须包含的文件。应用清单文件也是一种配置文件，用于对应用程序进行全局配置，操作系统需要根据应用清单文件里的内容运行应用程序的代码以及显示界面。应用清单文件比如安卓操作系统下应用程序的AndroidManifest.xml文件，或者，iOS操作系统下应用程序的iOS系统的声明文件等等。

在本申请中，将公用配置文件引入应用清单文件，这样能够在装配应用清单文件加载公用配置文件，按照公用配置文件中的配置信息打包应用安装包。由于该公用配置文件包括至少一个应用用户所对应的应用配置信息，那么可生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件，以根据至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包，包括：执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件；当打包脚本的打包字段指定应用用户时，根据指定的应用用户所对应的资源文件，生成指定的应用用户所对应的目标应用安装包；当打包脚本的打包字段未指定应用用户时，根据各应用用户所对应的资源文件，批量生成各应用用户分别对应的目标应用安装包。

需要说明的是，计算机设备上的软件开发工具包SDK在执行打包脚本过程中，会自动装配应用清单文件，因应用清单文件中引入了公用配置文件，此时公用配置文件会被自动引入并加载。由于在公用配置文件中配置了各应用用户各自对应的应用配置信息，在打包过程中自动装配并替换为租户配置的资源文件。因而可以动态化打包出至少一个应用用户所对应的目标应用安装包。

举例说明，假设基于安卓操作系统开发应用程序时，应用清单文件可以为AndroidManifest.xml文件，公用配置文件为application.yml，将公用配置文件引入应用清单文件可以是<application android:customer＝"@yml/application.yml">。

具体地，在需要对指定的应用用户打包目标应用安装包的场景下，可在打包脚本的打包字段指定应用用户，这样计算机设备在执行打包脚本时，仅对该指定应用用户打包对应的目标应用安装包。指定应用用户的数量可为至少一个。

举例说明，在需要对指定的应用用户打包目标应用安装包时，可通过修改打包字段<assemble${X}release>中占位符<${X}>的值，以指定应用用户。

指定应用用户可为一个。比如，需要对应用用户A打包目标应用安装包时，将<${X}>设置为<${A}>即可。打包脚本在执行时，会在标签下对应地找到应用用户的应用配置信息，生成根据应用用户A的需求信息定制的目标应用安装包。当然在另外的实施例中，指定应用用户也可为多个。比如指定应用用户为应用用户A和应用用户B时，分别生成根据应用用户A的需求信息定制的目标应用安装包，以及根据应用用户B的需求信息定制的目标应用安装包。

具体地，在需要对所有应用用户打包目标应用安装包的场景下，则无需在打包脚本的打包字段指定应用用户，这样计算机设备在执行打包脚本时，默认对所有应用用户打包对应的目标应用安装包。

举例说明，在需要对所有应用用户打包目标应用安装包时，可通过修改打包字段为<assemblerelease>，不指定应用用户即可。

上述实施例中，通过打包脚本中打包字段的设置，提供了灵活的打包方式，根据实际需求动态化打包出至少一个应用用户所对应的目标应用安装包。而且，在进行应用程序的安装包打包时，通过打包字段的设置，可以基于一个应用开发项目一键批量打包多个安装包，不再需要通过大量的应用开发项目逐一打包安装包的繁琐操作，极大地提高了应用开发效率。

上述应用安装包生成方法，自动获取不同应用用户分别对应的需求信息，创建目标应用的应用开发项目所对应的公用配置文件；随后根据各应用用户的需求信息，在统一的公用配置文件中分别配置各应用用户各自的应用配置信息，进而基于各应用用户的应用配置信息，分别配置各应用用户各自的资源文件。这样在进行应用程序打包时，可以根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包；也就是对于同一款目标应用，对于不同的应用用户会结合其需求开发打包出与其需求适配的目标应用供使用，可以减少冗余代码，减少代码量，以及减少开发人员数量，进而降低开发成本，而且在一个公用配置文件中批量配置差异化的应用配置信息便于代码维护。

在一个实施例中，本申请提供的应用安装包生成方法还包括：在公用配置文件的第一区域统一配置公用资源库；公用资源库中的公用资源包括界面资源和网络资源中的至少一种；根据各需求信息，在公用配置文件中分别配置各应用用户各自对应的应用配置信息，包括：根据各需求信息，在公用配置文件中的第二区域分别配置各应用用户各自对应的应用配置信息；其中，当需求信息的功能实现需要调用公用资源时，应用配置信息中包括调用公用资源的路径。

其中，公用资源库包括各应用用户公用的资源。公用资源至少包括两类资源：界面资源(baseUi，UI模块)，封装了对公共部分的抽取，如Dialog对话弹窗、activity活动页面、顶部状态栏、标题栏等；网络配置资源(baseNet，网络模块)，对网络的封装，包括统一请求头、cookie、请求与响应的校验加密处理、请求参数与、响应参数封装的POJO、JSON与POJO的转换工具、网络日志的管理等。此外，公用资源还可以包括第三方资源。

在公用配置文件的第一区域统一配置公用资源库，具体可以是配置各公用资源的标识和路径，以便在需求信息的功能实现需要调用公用资源时，在应用配置信息中配置调用公用资源的路径。

具体地，计算机设备自动或者在根据开发人员的操作布局公用配置文件时，可先在位置在前的第一区域统一配置公用资源路径。

比如：#1.公共模块依赖，所有租户都用的到的(以UI、网络，为例)

commonlibs:

-baseUi:baseuiLib#UI公共UI抽取(弹窗、公共页面抽取等)

-baseNet:baseNetLib#公共网络模块抽取

#以下可能还有多个配置

#2.公共三方依赖，所有租户都用的到的dependencies:

-glide:com.github.bumptech.glide:glide:4.9.0#依赖三方库(以glide为例)

#以下可能还有多个配置

进一步地，计算机设备可继续在第一区域后的第二区域，根据各需求信息，分别配置各应用用户各自对应的应用配置信息。

上述实施例中，对于各应用用户均可能需求的资源，通过公用配置文件的第一区域统一配置公用资源库以供调用，可以减少冗余代码，减少代码量，降低开发成本。

在一个实施例中，根据各需求信息，在公用配置文件中的第二区域分别配置各应用用户各自对应的应用配置信息，包括：在公用配置文件中的第二区域，根据各应用用户所对应的需求信息分区扩展各应用用户所对应的应用配置信息；其中，每个分区包括按照配置节点分别配置的其中一个应用用户的应用标识、应用签名及专用资源路径；不同分区的应用配置信息包括差异化的应用标识。

具体地，计算机设备可继续在第一区域后的第二区域，依次根据各应用用户所对应的需求信息扩展各应用用户所对应的应用配置信息，以分区扩展各应用用户所对应的应用配置信息。

在一个具体的实施例中，配置应用配置信息的第二区域，可存在对应的区域标签，以在需要对应用配置信息进行修改时定位第二区域。

比如，#3.在该标签下配置需要的应用配置信息(现以应用用户A和应用用户B举例,如若需要添加、删除、修改应用用户在此标签下配置)

tagged:

#3.1应用用户A配置

-A:

……………(此处省略为应用用户A的应用配置信息的具体内容)

#3.2应用用户B配置

-B:

……………(此处省略为应用用户B的应用配置信息的具体内容)

#以下可能还有多个配置

在一个实施例中，应用标识至少由两个部分组成：第一部分和第二部分。其中，各应用用户的应用标识的第一部分各不相同，用于区分不同的应用用户的个性化目标应用，第一部分具体可以是比如用户名、用户编号等可以唯一确定应用用户的用户标识。各应用用户的应用标识的第二部分相同，用于表示各应用用户的个性化目标应用是基于同一个应用开发项目开发得到，第二部分具体可以是母应用程序标识。其中，在一个具体的实施例中，应用标识的第一部分可以是前缀部分。如，应用用户A的应用标识为A.applicationId，应用用户B 的应用标识为B.applicationId。当然应用标识的第一部分也可以是后缀部分，第一部分和第二部分的顺序不受限制。

需要说明的是，一个应用开发项目对应一个应用签名和应用标识(applicationId)，计算机设备的操作系统根据应用签名和应用标识进行判断，如果相同则判断为同一应用，在同一设备下只能存在一个这样的应用。在本申请中，应用标识包括两个部分，各应用用户的应用标识的第一部分各不相同，用于区分不同的应用用户的个性化目标应用，各应用用户的应用标识的第二部分相同，用于表示各应用用户的个性化目标应用是基于同一个应用开发项目开发得到，这样各应用用户对应的个性化目标应用可在同一设备下共存。在本申请中，各应用配置信息包括差异化的应用标识，这样基于不同应用配置信息生成的目标应用安装包在同一个计算设备中同时安装时，则不会被操作系统识别为同一个应用程序。

比如，应用用户A的应用标识为A.applicationId，应用用户B的应用标识为B.applicationId，A.applicationId与B.applicationId不同，在同一个设备中同时安装应用用户A和应用用户B对应的应用时，操作系统不会认为这两个应用是同一个应用。在一个实施例中，应用安装包生成方法还包括：当新增应用用户、且新增的应用用户所对应的需求信息与已有的需求信息不一致时，根据新增的需求信息，在第二区域中已有的应用配置信息之后继续配置新增的应用用户所对应的应用配置信息。

可以理解，通常一个应用程序的应用用户会随时间的变化发生变化，比如新增应用用户。具体地，当新增应用用户、且新增的应用用户所对应的需求信息与已有的需求信息不一致时，计算机设备根据新增的需求信息，在第二区域中已有的应用配置信息之后继续配置新增的应用用户所对应的应用配置信息。

比如，新增应用用户C后，第二区域的配置信息如下

#3.在该标签下配置需要的应用配置信息

tagged:

#3.1应用用户A配置

-A:

……………(此处省略为应用用户A的应用配置信息的具体内容)

#3.2应用用户B配置

-B:

……………(此处省略为应用用户B的应用配置信息的具体内容)

#3.3应用用户C配置

-C:

……………(此处省略为应用用户C的应用配置信息的具体内容)

#以下可能还有多个配置

在另外的实施例中，应用程序的应用用户也会减少。当减少应用用户时，在第二区域中已有的应用配置信息中删除减少的应用用户所对应的应用配置信息。比如，删除应用用户B后，第二区域的配置信息如下

#3.在该标签下配置需要的应用配置信息

tagged:

#3.1应用用户A配置

-A:

……………(此处省略为应用用户A的应用配置信息的具体内容)

#3.3应用用户C配置

-C:

……………(此处省略为应用用户C的应用配置信息的具体内容)

#以下可能还有多个配置

在本实施例中，提供了应用用户发生变化时公用配置文件的处理方式，这样在应用用户发生变化时，可以灵活地修改公用配置文件，提高开发效率。

在一个实施例中，应用配置信息还包括应用版本信息；应用安装包生成方法还包括：当已有的需求信息发生变更时，确定发生变更的需求信息对应的目标节点；根据发生变更的需求信息对目标节点处的应用配置信息进行修改；更新目标节点所属应用配置信息的应用版本信息。

具体地，公用配置文件中的应用配置信息是按照节点布局的。

举例说明，以下xxx表示应用用户的名称(如应用用户A、B、C…)

application:xxx节点，用于配置应用用户的名称；

application:xxx.applicationId节点，用于配置应用用户的应用标识；

application:xxx.version:节点，用于配置应用用户的版本信息；等等。

比如以版本信息举例：

application:

#3.在该标签下配置需要的应用配置信息

tagged:

#3.1应用用户A配置

-A:

#3.3.应用用户A的版本信息

version:

#3.3.1.应用用户A的版本名称

versionName:1.1.1

#3.3.2.应用用户A的版本号

versionCode:1

具体地，当已有的需求信息发生变更时，计算机设备可确定发生变更的需求信息对应的目标节点，再根据发生变更的需求信息对目标节点处的应用配置信息进行修改，并更新目标节点所属应用配置信息的应用版本信息。这样在某个应用用户的需求发生改变时，也可灵活便捷地修改公用配置文件，而且通过版本信息可以很好地对不同阶段的需求和目标应用进行区分，提高了开发效率。

应该理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图2所示，提供了一种应用安装包生成装置，包括：获取模块201、创建模块202、配置模块203和生成模块204，其中：

获取模块201，用于获取目标应用的至少两个应用用户分别对应的需求信息；

创建模块202，用于创建目标应用的应用开发项目所对应的公用配置文件；

配置模块203，用于根据各需求信息，在公用配置文件中分别配置各应用用户各自对应的应用配置信息；基于各应用配置信息，分别配置各应用用户各自对应的资源文件；

生成模块204，用于根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，配置模块203还用于在公用配置文件的第一区域统一配置公用资源库；公用资源库中的公用资源包括界面资源和网络资源中的至少一种；根据各需求信息，在公用配置文件中的第二区域分别配置各应用用户各自对应的应用配置信息；其中，当需求信息的功能实现需要调用公用资源时，应用配置信息中包括调用公用资源的路径。

在一个实施例中，配置模块203还用于在公用配置文件中的第二区域，根据各应用用户所对应的需求信息分区扩展各应用用户所对应的应用配置信息；其中，每个分区包括按照配置节点分别配置的其中一个应用用户的应用标识、应用签名及专用资源路径；不同分区的应用配置信息包括差异化的应用标识。

在一个实施例中，配置模块203还用于当新增应用用户、且新增的应用用户所对应的需求信息与已有的需求信息不一致时，根据新增的需求信息，在第二区域中已有的应用配置信息之后继续配置新增的应用用户所对应的应用配置信息。

在一个实施例中，应用配置信息还包括应用版本信息；配置模块203还用于：当已有的需求信息发生变更时，确定发生变更的需求信息对应的目标节点；根据发生变更的需求信息对目标节点处的应用配置信息进行修改；更新目标节点所属应用配置信息的应用版本信息。

在一个实施例中，生成模块204还用于配置应用清单文件，并将公用配置文件引入应用清单文件；执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件，以根据至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，生成模块204还用于执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件；当打包脚本的打包字段指定应用用户时，根据指定的应用用户所对应的资源文件，生成指定的应用用户所对应的目标应用安装包；当打包脚本的打包字段未指定应用用户时，根据各应用用户所对应的资源文件，批量生成各应用用户分别对应的目标应用安装包。

在一个实施例中，目标应用为组织应用，应用用户为组织用户。

上述应用安装包生成装置，自动获取不同应用用户分别对应的需求信息，创建目标应用的应用开发项目所对应的公用配置文件；随后根据各应用用户的需求信息，在统一的公用配置文件中分别配置各应用用户各自的应用配置信息，进而基于各应用用户的应用配置信息，分别配置各应用用户各自的资源文件。这样在进行应用程序打包时，可以根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包；也就是对于同一款目标应用，对于不同的应用用户会结合其需求开发打包出与其需求适配的目标应用供使用，可以减少冗余代码，减少代码量，以及减少开发人员数量，进而降低开发成本，而且在一个公用配置文件中批量配置差异化的应用配置信息便于代码维护。

关于应用安装包生成装置的具体限定可以参见上文中对于应用安装包生成方法的限定，在此不再赘述。上述应用安装包生成装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图3所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于应用开发相关资源。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种应用安装包生成方法。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种应用安装包生成方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图3和4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：获取目标应用的至少两个应用用户分别对应的需求信息；创建目标应用的应用开发项目所对应的公用配置文件；根据各需求信息，在公用配置文件中分别配置各应用用户各自对应的应用配置信息；基于各应用配置信息，分别配置各应用用户各自对应的资源文件；根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：在公用配置文件的第一区域统一配置公用资源库；公用资源库中的公用资源包括界面资源和网络资源中的至少一种；根据各需求信息，在公用配置文件中分别配置各应用用户各自对应的应用配置信息，包括：根据各需求信息，在公用配置文件中的第二区域分别配置各应用用户各自对应的应用配置信息；其中，当需求信息的功能实现需要调用公用资源时，应用配置信息中包括调用公用资源的路径。

在一个实施例中，根据各需求信息，在公用配置文件中的第二区域分别配置各应用用户各自对应的应用配置信息，包括：在公用配置文件中的第二区域，根据各应用用户所对应的需求信息分区扩展各应用用户所对应的应用配置信息；其中，每个分区包括按照配置节点分别配置的其中一个应用用户的应用标识、应用签名及专用资源路径；不同分区的应用配置信息包括差异化的应用标识。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：当新增应用用户、且新增的应用用户所对应的需求信息与已有的需求信息不一致时，根据新增的需求信息，在第二区域中已有的应用配置信息之后继续配置新增的应用用户所对应的应用配置信息。

在一个实施例中，应用配置信息还包括应用版本信息；处理器执行计算机程序时还实现以下步骤：当已有的需求信息发生变更时，确定发生变更的需求信息对应的目标节点；根据发生变更的需求信息对目标节点处的应用配置信息进行修改；更新目标节点所属应用配置信息的应用版本信息。

在一个实施例中，根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包，包括：

配置应用清单文件，并将公用配置文件引入应用清单文件；

执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件，以根据至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件，以根据至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包，包括：执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件；当打包脚本的打包字段指定应用用户时，根据指定的应用用户所对应的资源文件，生成指定的应用用户所对应的目标应用安装包；当打包脚本的打包字段未指定应用用户时，根据各应用用户所对应的资源文件，批量生成各应用用户分别对应的目标应用安装包。

在一个实施例中，目标应用为组织应用，应用用户为组织用户。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：获取目标应用的至少两个应用用户分别对应的需求信息；创建目标应用的应用开发项目所对应的公用配置文件；根据各需求信息，在公用配置文件中分别配置各应用用户各自对应的应用配置信息；基于各应用配置信息，分别配置各应用用户各自对应的资源文件；根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：在公用配置文件的第一区域统一配置公用资源库；公用资源库中的公用资源包括界面资源和网络资源中的至少一种；根据各需求信息，在公用配置文件中分别配置各应用用户各自对应的应用配置信息，包括：根据各需求信息，在公用配置文件中的第二区域分别配置各应用用户各自对应的应用配置信息；其中，当需求信息的功能实现需要调用公用资源时，应用配置信息中包括调用公用资源的路径。

在一个实施例中，在公用配置文件中的第二区域，根据各应用用户所对应的需求信息分区扩展各应用用户所对应的应用配置信息；其中，每个分区包括按照配置节点分别配置的其中一个应用用户的应用标识、应用签名及专用资源路径；不同分区的应用配置信息包括差异化的应用标识。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：当新增应用用户、且新增的应用用户所对应的需求信息与已有的需求信息不一致时，根据新增的需求信息，在第二区域中已有的应用配置信息之后继续配置新增的应用用户所对应的应用配置信息。

在一个实施例中，应用配置信息还包括应用版本信息；计算机程序被处理器执行时还实现以下步骤：当已有的需求信息发生变更时，确定发生变更的需求信息对应的目标节点；根据发生变更的需求信息对目标节点处的应用配置信息进行修改；更新目标节点所属应用配置信息的应用版本信息。

在一个实施例中，根据公用配置文件以及至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包，包括：配置应用清单文件，并将公用配置文件引入应用清单文件；执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件，以根据至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包。

在一个实施例中，执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件，以根据至少一个应用用户所对应的资源文件，生成至少一个应用用户所对应的目标应用安装包，包括：执行打包脚本，在执行打包脚本的过程中装配应用清单文件，通过装配应用清单文件加载公用配置文件；当打包脚本的打包字段指定应用用户时，根据指定的应用用户所对应的资源文件，生成指定的应用用户所对应的目标应用安装包；当打包脚本的打包字段未指定应用用户时，根据各应用用户所对应的资源文件，批量生成各应用用户分别对应的目标应用安装包。

在一个实施例中，目标应用为组织应用，应用用户为组织用户。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory， SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (8)

1.一种应用安装包生成方法，其特征在于，所述方法包括：

获取目标应用的至少两个应用用户分别对应的需求信息；

创建所述目标应用的应用开发项目所对应的公用配置文件；

根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息；其中，在所述公用配置文件的第一区域统一配置公用资源库；所述公用资源库中的公用资源包括界面资源和网络资源中的至少一种；

基于各所述应用配置信息，分别配置各所述应用用户各自对应的资源文件；

根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包；

所述根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息，包括：

在所述公用配置文件中的第二区域，根据各所述应用用户所对应的需求信息分区扩展各所述应用用户所对应的应用配置信息；其中，当所述需求信息的功能实现需要调用公用资源时，所述应用配置信息中包括调用所述公用资源的路径；每个分区包括按照配置节点分别配置的其中一个应用用户的应用标识、应用签名及专用资源路径；不同分区的应用配置信息包括差异化的应用标识。

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

当新增应用用户、且新增的所述应用用户所对应的需求信息与已有的需求信息不一致时，根据新增的所述需求信息，在所述第二区域中已有的应用配置信息之后继续配置新增的所述应用用户所对应的应用配置信息。

3.根据权利要求2所述的方法，其特征在于，所述应用配置信息还包括应用版本信息；所述方法还包括：

当已有的需求信息发生变更时，确定发生变更的需求信息对应的目标节点；

根据发生变更的需求信息对所述目标节点处的应用配置信息进行修改；

更新所述目标节点所属应用配置信息的应用版本信息。

4.根据权利要求1所述的方法，其特征在于，所述根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包，包括：

配置应用清单文件，并将所述公用配置文件引入所述应用清单文件；

执行打包脚本，在执行所述打包脚本的过程中装配所述应用清单文件，通过装配所述应用清单文件加载所述公用配置文件，以根据至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包。

5.根据权利要求4所述的方法，其特征在于，所述执行打包脚本，在执行所述打包脚本的过程中装配所述应用清单文件，通过装配所述应用清单文件加载所述公用配置文件，以根据至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包，包括：

执行打包脚本，在执行所述打包脚本的过程中装配所述应用清单文件，通过装配所述应用清单文件加载所述公用配置文件；

当所述打包脚本的打包字段指定应用用户时，根据指定的应用用户所对应的资源文件，生成指定的应用用户所对应的目标应用安装包；

当所述打包脚本的打包字段未指定应用用户时，根据各所述应用用户所对应的资源文件，批量生成各所述应用用户分别对应的目标应用安装包。

6.一种应用安装包生成装置，其特征在于，所述装置包括：

获取模块，用于获取目标应用的至少两个应用用户分别对应的需求信息；

创建模块，用于创建所述目标应用的应用开发项目所对应的公用配置文件；

配置模块，用于根据各所述需求信息，在所述公用配置文件中分别配置各所述应用用户各自对应的应用配置信息；基于各所述应用配置信息，分别配置各所述应用用户各自对应的资源文件；

生成模块，用于根据所述公用配置文件以及至少一个所述应用用户所对应的资源文件，生成至少一个所述应用用户所对应的目标应用安装包；

所述配置模块，还用于：在所述公用配置文件的第一区域统一配置公用资源库；所述公用资源库中的公用资源包括界面资源和网络资源中的至少一种；

在所述公用配置文件中的第二区域，根据各所述应用用户所对应的需求信息分区扩展各所述应用用户所对应的应用配置信息；其中，当所述需求信息的功能实现需要调用公用资源时，所述应用配置信息中包括调用所述公用资源的路径；每个分区包括按照配置节点分别配置的其中一个应用用户的应用标识、应用签名及专用资源路径；不同分区的应用配置信息包括差异化的应用标识。

7.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至5中任一项所述的方法的步骤。

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

Images