应用程序包的打包方法、打包终端和计算机可读存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种应用程序包的打包方法、打包终端和计算机可读存储介质。

背景技术

开发人员在对应用程序进行开发时，比如智能手表中的应用程序，不可避免的需要将文件打包至应用程序包内。

目前，在将项目内包中的文件打入应用程序包时，是无法将外包中的打包至应用程序包的。因此，当开发人员在外包中发现项目可用的文件时，无法将文件打入应用程序包，也即在项目中可用的外包文件无法打包至应用程序包。

发明内容

本发明的主要目的在于提供一种应用程序包的打包方法、打包终端和计算机可读存储介质，旨在解决项目中可用的外包文件无法打包至应用程序包的问题。

为实现上述目的，本发明提供一种应用程序包的打包方法，所述应用程序包的打包方法包括以下步骤：

获取外包以及内包，其中，所述内包中的文件为项目的文件，所述外包中的文件不为所述项目的文件；

在检测到所述外包中包括第一文件时，将所述第一文件的目录信息添加至打包脚本中的打包目录内，得到目标目录，其中，所述打包目录根据所述内包中各个第二文件的目录信息确定，所述第一文件为所述内包所需的文件；

控制所述打包脚本基于所述目标目录对所述第一文件以及所述第二文件进行编译，得到应用程序包。

在一实施例中，所述获取外包以及内包的步骤之后，还包括：

在检测到所述外包中不包括第一文件时，控制所述打包脚本基于所述打包目录对所述第二文件进行编译，得到应用程序包。

在一实施例中，所述获取外包以及内包的步骤之前，还包括：

获取打包指令；

在所述打包指令中包括预设参数时，执行所述获取外包以及内包的步骤。

在一实施例中，所述接收打包指令的步骤之后，还包括：

在所述打包指令中未包括预设参数时，控制所述打包脚本基于所述打包目录对所述第二文件进行编译，得到应用程序包。

在一实施例中，所述控制所述打包脚本基于所述目标目录对所述第一文件以及所述第二文件进行编译，得到应用程序包的步骤包括：

根据所述第一文件的目录信息获取第一文件，并将所述第一文件添加至所述内包，所述目录信息至少包括路径以及文件名；

控制所述打包脚本基于所述目标目录，对添加所述第一文件的所述内包内的文件进行编译，得到应用程序包。

在一实施例中，所述控制所述打包脚本基于所述目标目录，对添加所述第一文件的所述内包内的文件进行编译，得到应用程序包的步骤之后，还包括：

在所述内包中，删除所述第一文件。

在一实施例中，所述控制所述打包脚本基于所述目标目录对所述第一文件以及所述第二文件进行编译，得到应用程序包的步骤之后，还包括：

在所述目标目录中，删除所述第一文件的目录信息，以还原得到所述打包程序的打包目录。

在一实施例中，所述获取外包以及内包的步骤之后，还包括：

确定所述内包对应的业务场景；

确定所述外包中是否包括所述业务场景所需的文件；

在所述外包中包括所述业务场景所需的文件时，执行所述将所述第一文件的目录信息添加至打包脚本中的打包目录内的步骤，其中，所述外包中包括所述业务场景所需的文件，判定所述外包中包括第一文件。

为实现上述目的，本发明还提供一种打包终端，所述打包终端包括存储器、处理器以及存储在所述存储器并可在所述处理器上运行的打包程序，所述打包程序被所述处理器执行时实现如上所述的应用程序包的打包方法的各个步骤。

为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质包括打包程序，所述打包程序被处理器执行时实现如上所述的应用程序包的打包方法的各个步骤。

本发明提供的应用程序包的打包方法、打包终端和计算机可读存储介质，打包终端获取项目以外的外包以及项目以内的内包，在检测到外包中含有项目所需的第一文件的时，将文件的目录信息添加至打包脚本的打包目录中得到目标目录，最后控制打包脚本基于目标目录对第一文件以及内包中的第二文件进行编译得到应用程序包。由于打包终端通过将项目所需的外包文件的目录信息添加至打包脚本的打包目录内，从而通过打包脚本实现了将外包中可用的文件打包至应用程序包的目的。

附图说明

图1为本发明实施例涉及的打包终端的硬件结构示意图；

图2为本发明应用程序包的打包方法第一实施例的流程示意图；

图3为本发明应用程序包的打包方法第二实施例的流程示意图；

图4为本发明应用程序包的打包方法第三实施例的流程示意图；

图5为本发明应用程序包的打包方法第四实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

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

本发明实施例的主要解决方案是：获取外包以及内包，其中，所述内包中的文件为项目的文件，所述外包中的文件不为所述项目的文件；在检测到所述外包中包括第一文件时，将所述第一文件的目录信息添加至打包脚本中的打包目录内，得到目标目录，其中，所述打包目录根据所述内包中各个第二文件的目录信息确定，所述第一文件为所述内包所需的文件；控制所述打包脚本基于所述目标目录对所述第一文件以及所述第二文件进行编译，得到应用程序包。

由于打包终端通过将项目所需的外包文件的目录信息添加至打包脚本的打包目录内，从而通过打包脚本实现了将外包中可用的文件打包至应用程序包的目的。

如图1所示，图1是本发明实施例方案涉及的打包终端的硬件结构示意图。

如图1所示，本发明实施例方案涉及是打包终端可以包括：处理器101，例如CPU，通信总线102，存储器103。其中，通信总线102用于实现这些组件之间的连接通信。存储器103可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器103可选的还可以是独立于前述处理器101的存储装置。本领域技术人员可以理解，图1中示出的结构并不构成对打包终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器103中可以包括打包程序。

在图1所示的装置中，处理器101可以用于调用存储器103中存储的打包程序，并执行以下操作：

获取外包以及内包，其中，所述内包中的文件为项目的文件，所述外包中的文件不为所述项目的文件；

在检测到所述外包中包括第一文件时，将所述第一文件的目录信息添加至打包脚本中的打包目录内，得到目标目录，其中，所述打包目录根据所述内包中各个第二文件的目录信息确定，所述第一文件为所述内包所需的文件；

控制所述打包脚本基于所述目标目录对所述第一文件以及所述第二文件进行编译，得到应用程序包。

在一实施例中，处理器101可以调用存储器103中存储的打包程序，还执行以下操作：

在检测到所述外包中不包括第一文件时，控制所述打包脚本基于所述打包目录对所述第二文件进行编译，得到应用程序包。

在一实施例中，处理器101可以调用存储器103中存储的打包程序，还执行以下操作：

获取打包指令；

在所述打包指令中包括预设参数时，执行所述获取外包以及内包的步骤。

在一实施例中，处理器101可以调用存储器103中存储的打包程序，还执行以下操作：

在所述打包指令中未包括预设参数时，控制所述打包脚本基于所述打包目录对所述第二文件进行编译，得到应用程序包。

在一实施例中，处理器101可以调用存储器103中存储的打包程序，还执行以下操作：

根据所述第一文件的目录信息获取第一文件，并将所述第一文件添加至所述内包，所述目录信息至少包括路径以及文件名；

控制所述打包脚本基于所述目标目录，对添加所述第一文件的所述内包内的文件进行编译，得到应用程序包。

在一实施例中，处理器101可以调用存储器103中存储的打包程序，还执行以下操作：

在所述内包中，删除所述第一文件。

在一实施例中，处理器101可以调用存储器103中存储的打包程序，还执行以下操作：

在所述目标目录中，删除所述第一文件的目录信息，以还原得到所述打包程序的打包目录。

在一实施例中，处理器101可以调用存储器103中存储的打包程序，还执行以下操作：

确定所述内包对应的业务场景；

确定所述外包中是否包括所述业务场景所需的文件；

在所述外包中包括所述业务场景所需的文件时，执行所述将所述第一文件的目录信息添加至打包脚本中的打包目录内的步骤，其中，所述外包中包括所述业务场景所需的文件，判定所述外包中包括第一文件。

本实施例根据上述方案，打包终端获取项目以外的外包以及项目以内的内包，在检测到外包中含有项目所需的第一文件的时，将文件的目录信息添加至打包脚本的打包目录中得到目标目录，最后控制打包脚本基于目标目录对第一文件以及内包中的第二文件进行编译得到应用程序包。由于打包终端通过将项目所需的外包文件的目录信息添加至打包脚本的打包目录内，从而通过打包脚本实现了将外包中可用的文件打包至应用程序包的目的。

基于上述打包终端的硬件构架，提出本发明应用程序包的打包方法的实施例。

参照图2，图2为本发明应用程序包的打包方法的第一实施例，所述应用程序包的打包方法包括以下步骤：

步骤S10，获取外包以及内包，其中，所述内包中的文件为项目的文件，所述外包中的文件不为所述项目的文件；

在本实施例中，执行主体为打包终端。打包终端中设有插件，打包终端通过该插件实现对应用程序包的打包。应用程序包可为APK(Android application package，Android应用程序包)，也即应用程序包为安卓系统的应用的安装包。插件可为Gradle插件。Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具。Gradle所构建的脚本使用一种基于Groovy的特定领域语来声明项目设置，抛弃了基于XML(ExtensibleMarkup Language，可扩展标记语言)的各种繁琐配置。Gradle插件构建的脚本即为打包脚本。也即打包终端设有打包脚本。打包脚本可为Grovvy脚本。应用程序包可以为穿戴设备上的应用程序的安装包，穿戴设备可为智能手表、智能手环等。

项目进行开发时，项目以内的各个文件构成为内包，而项目以外的各个文件构成外包。可以理解的是，内包的文件为项目的文件，而外包中的文件不为项目的文件。内包以及外包存储于项目所对应的存储区域，在打包终端需要进行打包时，从存储区域中获取内包以及外包。

需要说明的是，打包脚本中包括有打包目录。在构建完内包后，会将内包中的所有文件的目录信息录入打包目录中。目录信息包括至少包括文件的文件名以及路径。可以理解的是，打包目录所录入的文件为内包中的文件，打包目录中以外的文件为外包中的文件。

步骤S20，在检测到所述外包中包括第一文件时，将所述第一文件的目录信息添加至打包脚本中的打包目录内，得到目标目录，其中，所述打包目录根据所述内包中各个第二文件的目录信息确定，所述第一文件为所述内包所需的文件；

外包设有对应的目录，该目录根据外包中各个文件的目录信息确定。打包终端。打包终端打包脚本对目录进行遍历以确定外包中是否包括第一文件。第一文件即为内包所需的文件。具体的，打包脚本基于项目的生命周期函数projectsEvaluated，检测外包中是否有内包可用的第一文件。在确定外包中包括第一文件时，打包终端从该目录中获取第一文件的目录信息，第一文件的目录信息至少包括第一文件的路径以及文件名，路径即为第一文件的存储路径。打包终端将第一文件的目录信息添加至打包目录中得到目标目录，打包目录由内包中各个第二文件的目录信息确定，而目标目录由第一文件的目录信息以及第二文件的目录信息确定。

步骤S30，控制所述打包脚本基于所述目标目录对所述第一文件以及所述第二文件进行编译，得到应用程序包。

在得到目标目录后，打包终端控制打包脚本基于目标目录将第一文件以及第二文件进行编译得到应用程序包。

具体的，打包终端基于目标目录中第一文件的目录信息在外包中提取第一文件，再将第一文件添加至内包。打包脚本再通过目标目录对添加第一文件的内包中的文件进行编译得到应用程序包。打包脚本需要通过目标目录对内包中的文件进行比对，也即打包脚本会将目标目录对应的所有文件进行编译。

另外，打包终端可以直接通过第一文件的目录信息获取第一文件，再将第一文件添加至内包中，使得打包脚本基于目标目录对添加第一文件的内包内的文件进行编译得到应用程序包。

在本实施例提供的技术方案中，打包终端获取项目以外的外包以及项目以内的内包，在检测到外包中含有项目所需的第一文件的时，将文件的目录信息添加至打包脚本的打包目录中得到目标目录，最后控制打包脚本基于目标目录对第一文件以及内包中的第二文件进行编译得到应用程序包。由于打包终端通过将项目所需的外包文件的目录信息添加至打包脚本的打包目录内，从而通过打包脚本实现了将外包中可用的文件打包至应用程序包的目的。

参照图3，图3为本发明应用程序包的打包方法的第二实施例，基于第一实施例，所述步骤S10之后，还包括：

步骤S40，在检测到所述外包中不包括第一文件时，控制所述打包脚本基于所述打包目录对所述第二文件进行编译，得到应用程序包。

在本实施例中，打包终端基于打包脚本对外包所对应的目录进行遍历，以查找外包中是否包括内包所需的文件。内包所需的文件可以理解为，应用程序包对应的应用程序所需的文件。

若是外包中并未含有内包所需的文件时，打包终端则无需将外包中的文件打包至应用程序包中。此时，打包终端控制打包脚本基于打包目录对内包中的各个第二文件进行编译，从而得到应用程序包。

打包终端在得到应用程序包后，打包终端通过打包脚本将添加至内包的第一文件删除。也即打包终端在完成打包后，会还原内包的文件，从而不影响默认的打包流程。打包终端可以在生命周期函数中判断是否有预设参数，若有预设参数，即可确定此次打包中内包中有第一文件，打包终端将内包中的第一文件删除。

进一步的，在得到应用程序后，打包终端将目标目录中的第一文件的目录信息删除，从而还原得到打包程序的打包目录，避免影响默认的打包流程。

在本实施例提供的技术方案中，打包终端在得到内包以及外包时，若是检测到外包中未含有内包所需的文件时，则控制打包脚本基于打包目录对内包中的各个文件进行编译得到应用程序包，也即外包中没有可用的文件时，对默认的打包流程没有任何影响。

参照图4，图4为本发明应用程序包的打包方法的第三实施例，基于第一或第二实施例，所述步骤S10之前，还包括：

步骤S50，获取打包指令；

步骤S60，在所述打包指令中包括预设参数时，执行所述获取外包以及内包的步骤，其中，所述内包中的文件为项目的文件，所述外包中的文件不为所述项目的文件。

在本实施例中，项目的开发人员可向打包终端发送打包指令，当然，开放人员可在打包终端进行操作，从而触发打包指令。若是需要将外包中的文件打包至应用程序包中，则开发人员在打包终端中需要输入参数，打包终端基于该参数生成打包指令，该参数定义为预设参数。预设参数可为gradlew aDebug-PBUILD_TYPE。

打包终端在获取到打包指令后，若是打包指令中包含有预设参数，即可确定开发人员有将外包中文件打入应用程序包的需求，此时，打包终端获取外包以及内包，也即执行步骤S10-步骤S30。

若是打包指令中未包括预设参数，则控制打包脚本基于打包目录对第二文件进行编译得到应用程序包，也即开发人员没有将外包中的文件打包至应用程序程序包的需求，打包终端仅需对内包中的各个第二文件进行编译。

在本实施例提供的技术方案中，打包终端获取打包指令，在打包指令中包括预设参数，打包终端则将外包中的可用文件打包至内包中。

参照图5，图5为本发明应用程序包的打包方法的第四实施例，基于第一至第三中任一实施例，所述步骤S10之后，还包括：

步骤S70，确定所述内包对应的业务场景；

步骤S80，确定所述外包中是否包括所述业务场景所需的文件；

步骤S90，在所述外包中包括所述业务场景所需的文件时，执行所述将所述第一文件的目录信息添加至打包脚本中的打包目录内的步骤，其中，所述外包中包括所述业务场景所需的文件，判定所述外包中包括第一文件。

在本实施例中，内包对应的一个应用程序，而应用程序可以包括多个业务场景。例如，应用程序为游戏应用程序，则业务场景包括充值场景等。可以理解的是，内包对应多个业务场景。打包终端在外包中确定是否包括业务场景所需的文件。例如，业务场景为充值场景，则需要确定外包中是否包括充值相关的文件，如可以将充值验证的文件作为业务场景作为第一文件。可以理解的是，外包中的文件与业务场景相关联，若是外包中的文件管理的业务场景为内包所对应的业务场景，即可确定外包中包括第一文件。通过将业务场景放入至外包中，可以减少内包的维护成本。

打包终端基于业务场景确定外包中是否包括业务场景所需的文件。若是外包中包括业务场景所需的文件时，即可判定外包中包括第一文件，打包终端则执行步骤S20以及步骤S30。

在本实施例提提的技术方案中，打包终端确定内包对应的业务场景，并确定外包中是否包括业务场景所需的文件，若外包中包括业务场景所需的文件，则将该文件打包至应用程序包内。

基于上述实施例，对本发明提供的应用程序包的打包方法进行简要的描述，具体参照如下步骤：

步骤1、将项目以外的资源文件放入创建好的外包；

步骤2、获取打包指令，若是打包指令中包括参数＝gradlew aDebug-PBUILD_TYPE，开始构建项目，进行外包打入内包的流程；

步骤3、在项目的生命周期函数projectsEvaluated中，检测外包中是否有可用的文件，具体通过Grovvy脚本检测外包的目录中是否有内包可用的文件，若有，则进行步骤4，若无，则进行步骤5；

步骤4、使用Grovvy脚本对外包目录进行遍历，在外包中将可用的文件到、内包中，并将可用的文件的路径和文件名添加至Grovvy脚本的打包目录中；

步骤5，采用Grovvy脚本的开发工具打包目录中的文件进行编译得到应用程序包；

步骤6，在得到应用程序后，在项目的生命周期函数buildFinished中，判断是否有预设参数，若有，则使用Grovvy脚本在内包中，将外包复制进来的文件删除。

本发明的有益效果在于：

1、解决开发工具不能将外包内容打入APK的问题；

2、优化APK体积；

3、不涉及外包时，对默认的打包流程没有任何影响；

4、将特殊的业务场景放到外包中，减少维护成本，方便业务功能的控制和使用；

5、涉及外包时，完成打包操作后会还原内包的文件，不影响默认打包流程。

6、外包、内包文件分离，并且能够实现多渠道的功能。

本发明还提供一种打包终端，所述打包终端包括存储器、处理器以及存储在所述存储器并可在所述处理器上运行的打包程序，所述打包程序被所述处理器执行时实现如上实施例所述的应用程序包的打包方法的各个步骤。

本发明还提供一种计算机可读存储介质，所述计算机可读存储介质包括打包程序，所述控制程序被处理器执行时实现如上实施例所述的打包程序包的打包方法的各个步骤。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。