一种软件打包的方法、装置及系统与流程

本发明涉及计算机技术领域，特别涉及一种软件打包的方法、装置及系统。

背景技术：

同一款软件在面对不同需求的差异时，需要进行差异化打包，以安卓(android)客户端的打包为例，如果是面向消费者(c，client)端业务，则通常需要在android众多应用市场发布，每个应用市场的需求都可能不同；如果是面向商务(b，business)端业务，则需要支持各种众多不同类型的b端。这些应用市场和不同的b端之间，同一款软件的android应用程序包(apk，androidapplicationpackage)闪屏页、图标、文案、包名，甚至实现逻辑可能都存在差异。所以无论是面向c端业务，还是面向b端业务，软件的打包方案都需要解决差异化打包的问题。

flavors是一种现有的android客户端差异化打包解决方案，它可以根据不同需求配置不同的代码、资源、配置或库。但它存在下面几个问题：1.配置全部以本地的形式在源码仓库中。这些差异更多的是运营人员或产品经理需要关心的，但是由于技术壁垒的存在，他们需要给研发人员提需求增加或修改配置，具体的配置的修改或增加则只能由研发人员再来实现，知晓需求的运营人员或产品经理与研发人员之间的沟通成本高，导致整体工作效率低；2.维护成本较高：每支持一个新的应用市场、b端的需求，研发人员都需要增加一个新的productflavors，如果每个productflavors需要的配置项很多，那么完全正确的配置对于维护人员也是一个挑战；另外，每新增一个配置项，则需要修改之前所有的productflavors；android客户端差异化还存在一些其它方案，与flavors原理类似，同样存在上述问题。

技术实现要素：

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种软件打包的方法、装置及系统。

第一方面，本发明实施例提供一种软件打包的方法，包括：

响应于软件的打包命令，从云端服务器，请求所述软件打包所需的配置数据；所述云端服务器中预先存储有至少一款软件各类需求信息所对应的配置数据；

通过云端服务器返回的下载地址，下载所述配置数据；

根据获取到的所述配置数据，对所述配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包。

在一个或一些可能的实施例中，所述配置数据通过下述方式预先生成：

配置管理服务器根据输入的软件的包名、第三方sdk的密钥key、所属应用市场或b端的标识、日志目录，以及工程代码和资源文件，按照预设的数据格式生成对应的配置数据。

在一个或一些可能的实施例中，响应于软件的打包命令，请求所述软件打包所需的配置数据，具体包括：

当接收到所述软件的打包命令时，根据所述打包命令中待打包软件的目标需求信息，生成对应的获取配置数据的请求；

向云端服务器发送所述获取配置数据的请求。

在一个或一些可能的实施例中，生成对应的获取配置数据的请求，包括：

将所述目标需求信息中的所述待打包软件所属平台信息、所属应用市场或b端的标识、当前时间戳信息和加密信息，拼接生成所述获取配置数据的请求。

在一个或一些可能的实施例中，所述配置文件包括：资源文件和配置表文件；

根据获取到的所述配置数据，对所述配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包，具体包括：

对工程代码和配置文件进行下述处理，得到可编译的工程：将所述配置文件中的资源文件，拷贝至工程代码中；读取所述配置文件中的配置表文件，生成对应的xml文件和java文件；

对所述可编译的工程，进行编译，生成对应的安装包。

在一个或一些可能的实施例中，所述配置文件还包括：用于修改java包名的java文件；

所述对工程代码和配置文件进行下述处理，得到可编译的工程，还包括：读取所述用于修改java包名的java文件，更改当前工程代码的包名，以生成可用的java类。

在一个或一些可能的实施例中，所述生成对应的安装包之后，所述方法还包括：

根据待打包软件的目标需求信息，生成上传安装包的请求；

将所述上传安装包的请求发送给云端服务器，并上传安装包。

在一个或一些可能的实施例中，根据输入的软件的目标需求信息，生成上传安装包的请求，包括：

将软件所属平台信息、所属应用市场或b端的标识、所述安装包的版本号信息、安装包的存储地址信息以及时间戳和加密信息，拼接生成上传安装包的请求。

第二方面，本发明实施例提供一种软件打包的装置，其特征在于，包括：

请求模块，用于响应于软件的打包命令，从云端服务器，请求所述软件打包所需的配置数据；所述云端服务器中预先存储有至少一款软件各类需求信息所对应的配置数据；

下载模块，用于通过云端服务器返回的下载地址，下载所述配置数据；

打包模块，用于根据获取到的所述配置数据，对所述配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包。

第三方面，本发明实施例提供一种软件打包的系统，包括：

至少一个云端服务器，用于存储至少一款软件各类需求信息所对应的配置数据；

打包客户端，用于响应于软件的打包命令，从云端服务器，请求所述软件打包所需的配置数据；所述云端服务器中预先存储有至少一款软件各类需求信息所对应的配置数据；通过云端服务器返回的下载地址，下载所述配置数据；根据获取到的所述配置数据，对所述配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包。

在一个或一些可能的实施例中，所述系统还包括：

配置管理服务器，用于根据输入的软件的包名、第三方sdk的密钥key、所属应用市场或b端的标识、日志目录，以及工程代码和资源文件，按照预设的数据格式生成对应的配置数据，并存储于所述云端服务器中。

第四方面，本发明实施例提供一种打包终端，包括：存储器和处理器；其中，所述存储器存储有计算机程序，所述程序被处理器执行时能够实现前述软件打包的方法。

第五方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现前述软件打包的方法。

本发明实施例提供的上述技术方案的有益效果至少包括：

本发明实施例提供的软件打包的方法、装置及系统中，预先将软件各类需求所对应的配置数据存储于云端服务器中，打包所需的配置数据中配置文件的内容可以预先由了解差异化需求的运营人员或产品经理来设置，这样，当接收到打包指令时，可自动地实现从云端获取该目标需求对应的配置数据，然后对配置数据中的配置文件和工程代码进行处理，自动完成打包操作，生成对应的安装包。本发明实施例可利用预先设置好的配置数据来实现打包操作，由于这些配置数据中的配置文件可由知晓差异化需求的运营人员或产品经理来定义，降低了运营人员或者产品经理参与软件差异化打包的技术门槛，避免了现有技术中沟通成本高、修改和增加配置整体效率低的问题；另一方面，将同一款软件的各类不同需求所对应的工程代码和配置文件等放在云端，也方便了运营人员和产品经理进行维护，降低了维护成本，在输入目标需求信息，便可完成自动打包，减少人工干预，提升了软件打包的执行效率。

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

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明实施例中软件打包的方法实现的网络架构图；

图2为本发明实施例中软件打包的方法的流程图；

图3为本发明实施例中可视化交互界面的示意图；

图4为本发明实施例中生成对应的获取配置数据的请求的流程图；

图5为本发明实施例中软件打包的方法的又一流程图；

图6为本发明实施例中软件打包的装置的结构框图；

图7为本发明实施例中软件打包的方法实现的又一网络架构图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了解决现有软件差异化打包的问题，本发明实施例提供了一种软件打包的方法，将生成配置和打包全部自动化。

在对本发明实施例提供的软件打包的方法进行说明之前，首先说明下该方法适用的网络架构，参照图1所示，包括至少一个云端服务器1和打包客户端2，云端服务器1主要用于预先存储有至少一款软件各类需求信息所对应的配置数据，为运营人员或产品经理维护这些数据提供方便；打包客户端2主要用于响应于运营人员或产品经理实际的软件打包需求，对指定的应用市场或者指定的b端进行打包生成对应的安装包。

本发明实施例提供的一种软件打包的方法，可应用于上述打包客户端，参照图2所示，该方法包括下述步骤：

s21、响应于软件的打包命令，从云端服务器，请求软件打包所需的配置数据；

该云端服务器中预先存储有至少一款软件各类需求信息所对应的配置数据；

需要说明的是，在本发明实施例中，云端服务器中预先存储有至少一款软件各类需求信息所对应的配置数据；

各类差异化的需求信息如前述，可以是待打包软件所属的各种平台(andriod、ios等)、所属应用市场标识(例如豌豆荚应用市场、苹果应用市场等)，或者所属b端标识(银行端、券商端、司机端)等。

这些配置数据例如可以包括：工程代码和配置文件(包括资源、配置表文件)，包名和签名数据等。

这些与差异化需求相对应的配置数据可以通过下述方式自动生成：

运营人员或产品经理通过一个可交互的平台例如配置管理服务器，输入配置的相关信息(比如app的包名、第三方sdk的密钥(key)、b端名称、日志目录等等)，配置管理服务器设置有对应的新增、删除、修改等交互项，供使用的用户(运营人员或产品经理)输入这些配置的相关信息，配置管理服务器根据用户输入的这些信息，以及类工程代码和资源文件，自动生成各个需求对应的云端配置数据，自动生成的过程例如可以采用下面的方式：根据设定的格式，将用户输入的数据和工程代码和资源文件等写入对应的配置文件。这个配置管理服务器可以采用多种的实现方式，比如网页的方式，或者app客户端的方式，本发明实施例对此不做限定。

配置管理服务器可以集成在云端服务器上，也可以是独立的平台，本发明实施例对此不做限定。

在需要进行软件打包时，运营人员或产品经理可以通过打包客户端提供的可视化的交互界面，输入需要待打包的软件的需求信息，以请求软件打包所需的配置数据。

一个交互界面的示意图参照图3所示，用户在交互界面上输入待打包软件的相关目标需求信息，比如软件所属平台标识(andriod)、b端名称等，可选地，用户还可以在该界面上指定待打包软件的版本号等其他辅助信息。

打包客户端收到用户输入的上述目标需求信息后，根据输入的目标需求信息，从云端服务器处获取预先存储的、与该目标需求信息对应的配置数据。

s22、通过云端服务器返回的下载地址，下载配置数据；

云端服务器在收到打包客户端发送的配置数据的请求之后，会根据请求中待打包软件的需求信息，将对应的配置数据的地址返回给云端服务器，这个地址为配置数据的存储地址，打包客户端可以访问这个地址来下载对应的配置数据。

s23、根据获取到的配置数据，对配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包。

需要说明的是，上述步骤s23中的工程代码是代码仓库中源代码中的几个(不一定是全部)，代码仓库里的源代码因为不知道必要的信息，所以不能直接编译成安装包，需要根据配置文件进行处理后，才能变成可编译成安装包的工程代码。

在本步骤s23中，打包客户端根据从云端服务器处获取到的与目标需求相对应的配置数据(包括配置文件和工程代码)，进行处理后，将其变成可编译成安装包的工程，然后进行编译，生成对应的安装包。

本发明实施例提供的上述软件打包的方法，预先将软件各类需求所对应的配置数据存储于云端服务器中，打包所需的配置数据中配置文件的内容可以预先由了解差异化需求的运营人员或产品经理来设置，这样，当接收到对软件的打包指令时，可自动地实现从云端获取该目标需求对应的配置数据，然后对配置数据中的配置文件和工程代码进行处理，自动完成打包操作，生成对应的安装包。本发明实施例可利用预先设置好的配置数据来实现打包操作，由于这些配置数据中的配置文件可由知晓差异化需求的运营人员或产品经理来定义，降低了运营人员或者产品经理参与软件差异化打包的技术门槛，避免了现有技术中沟通成本高、修改和增加配置整体效率低的问题；另一方面，将同一款软件的各类不同需求所对应的工程代码和配置文件等放在云端，也方便了运营人员和产品经理进行维护，降低了维护成本，在输入目标需求信息，便可完成自动打包，减少人工干预，运营人员、产品经理与研发人员沟通的工作量，提升了软件打包的执行效率。

下面进一步地对上述两个步骤进行详细的说明。

在一个实施例中，上述步骤s21中，响应于软件的打包命令，请求所述软件打包所需的配置数据的步骤，在具体实施时，参照图4所示，可以通过下述流程实现：

s41、当接收到软件的打包命令时，根据打包命令中待打包软件的目标需求信息，生成对应的获取配置数据的请求；

在具体实施时，打包客户端在收到软件的打包命令时，可以根据打包命令中待打包软件的目标需求信息的待打包软件所属平台信息、所属应用市场或b端的标识以及当前时间戳信息和加密信息，拼接生成获取配置数据的请求。

上述时间戳信息和加密信息，是云端服务器处于安全和记录而需要的参数，时间戳信息例如可以是生成该请求(或者发送该请求)时的时间，携带于该请求中，用于云端服务器进行记录和对比等逻辑，加密信息是出于安全性考虑，在某些情形下，也可能不需要时间戳和/或加密信息。

s42、向云端服务器发送获取配置数据的请求。

上述步骤s21～s22在具体实施时，可以由运行在打包客户端侧的脚本程序实现，例如采用python编写的脚本等。

在一个实施例中，上述配置文件例如可以包括：资源文件和配置表文件；

其中，资源文件，通常指图片、字符串等资源。

配置表文件，通常包括下述一项或多项信息或数据：app的包名、第三方sdk的key(访问第三方sdk用)、app所属应用市场名或b端名称、日志目录等。

上述步骤s23中，根据获取到的配置数据，对配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包，具体可以通过下述方式实现：

对工程代码和配置文件进行下述处理，得到可编译的工程：将配置文件中的资源文件，拷贝至工程代码中；读取配置文件中的配置表文件，生成对应的xml文件和java文件；对可编译的工程，进行编译后，便可生成对应的安装包。

在一个实施例中，配置文件中，还可以包含一种用于修改java包名的java文件；对于一些使用第三方sdk的软件来说，如果这些第三方sdk要求java类的包名必须与app的包名一致，那么配置文件需要提供这种java文件，读取这种java文件时，就能更换当前工程代码的包名，最终生成软件打包可用的java类。

经过将资源文件，拷贝至工程代码中、读取配置文件中的配置表文件，生成对应的xml文件和java文件，以及更换当前工程代码的包名等操作后，至此，一个标准的可编译的代码工程已经生成，然后执行编译指令，再执行签名等操作，就生成了软件安装包。

在一个实施例中，在前述步骤s23生成对应的安装包之后，参照图5所示，还可执行下述步骤：

s24、根据待打包软件的目标需求信息，生成上传安装包的请求；

s25、将上传安装包的请求发送给云端服务器，并上传安装包。

上述步骤s24～s25的目的是将安装包上传，以便让使用者下载。

在一个实施例中，上述步骤s24中，将软件所属平台信息、所属应用市场或b端的标识、所述安装包的版本号信息、安装包的存储地址信息以及时间戳和加密信息，拼接生成上传安装包的请求。

上述上传安装包的请求中的软件所属平台信息、所属应用市场或b端的标识可以使用之前用户在配置管理服务器输入的信息。

时间戳信息，例如可以是生成该请求(或者发送该请求)的时间，加密信息等，与前述获取配置数据的请求类似，在此不再赘述；

版本号信息，可以是预先指定的，也可以是按照设定规则实时自动生成的。

为了更好地说明本发明实施例提供的上述软件打包的方法，本发明实施例以一个简单的实例进行说明。

该实例以打车应用的生成为例：

该打车软件分为司机端软件和乘客端软件。其中以司机端软件为例，其生成流程如下：

1.调用下述指令：./package-tdriver-camap-massemblerelease-u-v3.6.1。其中：package为打包命令名称，t(target的缩写)表示目标(是司机端软件还是乘客端软件)，c(channel的缩写)表示b端具体名称，m(make的缩写)表示android打包任务的名称，u(upload)表示是否上传，v(version)表示软件版本。这句指令的意思是：对名称为amap的b端生成司机端软件的release版本的apk并上传，且上传的apk版本号为3.6.1；

2.解析上面的指令，参照前述步骤s41的方式，生成下载请求串，并参照前述s21～s22的方法，下载与所述请求串对应的配置文件和工程代码；

3.解压配置文件后，会生成两个目录，一个是司机端软件的配置，一个是乘客端软件的配置，参照前述步骤s23的方式，处理司机端配置目录下的文件，复制资源文件，生成司机端android工程需要的xml文件和java文件；

4.参照前述步骤s23的方式，调用gradle(gradle是一个基于apacheant和apachemaven概念的项目自动化构建开源工具)的assemblerelease任务，生成releaseapk文件，即正式版本的安装包；

5.生成上传请求串，参照s24和s25的方法，将生成的apk上传到云端。

需要说明的是，乘客端软件的安装包的生成流程与上述司机端软件相似，所不同的是将-t的参数改为passenger，后续选择乘客端软件的配置即可，在此不再赘述。

基于同一发明构思，本发明实施例还提供了一种软件打包的装置、软件打包的系统和打包终端，由于这些装置和系统所解决问题的原理与前述软件打包的方法相似，因此该装置和系统的实施可以参见前述方法的实施，重复之处不再赘述。

本发明实施例提供的一种软件打包的装置，参照图6所示，包括：

请求模块61，用于响应于软件的打包命令，从云端服务器，请求所述软件打包所需的配置数据；所述云端服务器中预先存储有至少一款软件各类需求信息所对应的配置数据；

下载模块62，用于通过云端服务器返回的下载地址，下载所述配置数据；

打包模块63，用于根据获取到的配置数据，对配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包。

在一个实施例中，上述请求模块61，具体用于当接收到待打包软件的目标需求信息时，根据所述目标需求信息，生成对应的获取配置数据的请求；向云端服务器发送所述获取配置数据的请求；接收所述云端服务器返回的所述待打包软件对应的配置数据的下载地址，并根据所述下载地址，下载对应的配置数据。

在一个实施例中，上述请求模块61，进一步用于将所述目标需求信息中的所述待打包软件所属平台信息、所属应用市场或b端的标识、当前时间戳信息和加密信息，拼接生成所述获取配置数据的请求。

在一个实施例中，所述配置文件包括：资源文件和配置表文件；

相应地，上述打包模块63，具体用于对工程代码和配置文件进行下述处理，得到可编译的工程：将所述配置文件中的资源文件，拷贝至工程代码中；读取所述配置文件中的配置表文件，生成对应的xml文件和java文件；对所述可编译的工程，进行编译，生成对应的安装包。

在一个实施例中，所述配置文件还包括：用于修改java包名的java文件；

上述打包模块63，还用于读取所述用于修改java包名的java文件，更改当前工程代码的包名，以生成可用的java类。

在一个实施例中，上述软件打包的装置，参照图6所示，还可以包括：上传模块64，用于根据软件的目标需求信息，生成上传安装包的请求；以及将所述上传安装包的请求发送给云端服务器，并上传安装包。

本发明实施例还提供一种软件打包的系统，参照图1所示，包括：

至少一个云端服务器1，用于存储至少一款软件各类需求信息所对应的配置数据；

打包客户端2，用于响应于软件的打包命令，从云端服务器，请求所述软件打包所需的配置数据；所述云端服务器中预先存储有至少一款软件各类需求信息所对应的配置数据；通过云端服务器返回的下载地址，下载所述配置数据；根据获取到的所述配置数据，对所述配置数据中包含的配置文件和工程代码执行打包操作，生成对应的安装包。

在一个实施例中，上述软件打包的系统，参照图7所示，还可以包括：

配置管理服务器3，用于根据输入的软件的包名、第三方sdk的密钥key、所属应用市场或b端的标识、日志目录，以及工程代码和资源文件，按照预设的数据格式生成对应的配置数据，并存储于所述云端服务器中。

在本发明实施例中，上述配置管理服务器3，可以集成于云端服务器1中，也可以独立于云端服务器1之外，本发明实施例对此不做限定。

本发明实施例还提供一种打包终端，包括：存储器和处理器；其中，所述存储器存储有计算机程序，所述程序被处理器执行时能够实现前述软件打包的方法。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现本发明实施例提供的前述软件打包的方法。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。