一种APP批量发版方法、装置及系统与流程

本申请涉及互联网技术领域，尤其涉及一种app批量发版方法、装置及系统。

背景技术：

移动互联网技术目前正在飞速发展，用户可通过智能手机下载各类应用(英文：application，简称：app)以满足日常的使用需求。app的开发方开发出一款app之后，通常需要将已经开发好的app发布到特定的应用发布平台，以使得app能够被用户下载和使用。

app发布流程中有个非常重要的流程节点，即根据版本、渠道、适配系统类型以及合作方的不同来发布相应的版本。现有技术通常采用独立app版本单次发布的方法进行发版，具体流程如下：先由app开发人员开发、打包创建app安装包文件，之后将每个安装包文件及对应的配置信息发送给发版操作人员。发版操作人员根据app开发人员提供的安装包文件以及对应的配置信息，在发版后台进行单次单个的版本配置及发布操作，其中的配置内容比较复杂，包括渠道类型、系统类型、更新日志、版本号、更新版本号以及最小版本号等。app发版完成后，用户智能手机安装的app会检测到新版本发布，从而实现对app进行后续的更新等处理。

然而在实际操作中，上述app发版方法存在以下缺点：一方面，面对客户的大量云交易所定制app，采用单次单个版本发布的方式进行app发版，流程较为繁琐，操作过于机械且重复，极大地浪费发版操作人员的时间且发版效率低；另一方面，单次单个版本发布的方式在更新内容配置时容易混乱，不利于后期的维护。

技术实现要素：

本申请提供了一种app批量发版方法、装置及系统，以解决现有的app发版方法较为繁琐，面对客户的大量云交易所定制app时，发版效率低，并且不便于后期维护的问题。

第一方面，本申请提供一种app批量发版方法，所述方法包括：

根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个所述安装包文件同名的配置文件；

将所述安装包文件和所述配置文件放置在同一文件夹内，并添加所述文件夹；

解析所述安装包文件和所述配置文件的文件名；

判断所述安装包文件和所述配置文件的文件名是否与大版本号相匹配；

如果所述安装包文件和所述配置文件的文件名与所述大版本号相匹配，将各组所述安装包文件和所述配置文件加入到上传列表，依次上传至服务器，以使所述服务器对所述配置文件进行解析；

接收服务器反馈的所述安装包文件的上传状态，以及与所述安装包文件同名的配置文件的解析状态；

判断所述安装包文件是否上传成功，以及与所述安装包文件同名的配置文件是否解析成功；

如果所述安装包文件上传成功，并且与所述安装包文件同名的配置文件解析成功，向所述服务器发送确认发版指令，以对app进行批量发版。

结合第一方面，在第一方面的第一种可实现方式中，所述安装包文件和所述配置文件的文件名依次包括以下信息：交易所id、系统类型、渠道代码、打包日期以及版本名。

结合第一方面，在第一方面的第二种可实现方式中，所述安装包文件的格式为apk或ipa格式，所述配置文件的格式为txt格式。

结合第一方面的第二种可实现方式，在第一方面的第三种可实现方式中，解析所述安装包文件和所述配置文件的文件名的步骤中，读取ipa、txt以及apk格式文件。

结合第一方面，在第一方面的第四种可实现方式中，判断所述安装包文件和所述配置文件的文件名是否与大版本号相匹配之后，所述方法还包括：

如果所述安装包文件和所述配置文件的文件名与所述大版本号不匹配，终止将所述安装包文件以及与所述安装包文件同名的配置文件加入到上传列表。

结合第一方面，在第一方面的第五种可实现方式中，根据所述安装包文件的上传状态，以及与所述安装包文件同名的配置文件的解析状态，判断所述安装包文件是否上传成功，以及与所述安装包文件同名的配置文件是否解析成功之后，所述方法还包括：

如果所述安装包文件上传失败，重新向所述服务器上传所述安装包文件；

如果与所述安装包文件同名的配置文件解析失败，重新向所述服务器上传所述配置文件。

结合第一方面，在第一方面的第六种可实现方式中，所述服务器对所述配置文件进行解析，包括：

判断所述上传列表中的安装包文件和与所述安装包文件同名的配置文件是否上传完成；

如果所述上传列表中的安装包文件和与所述安装包文件同名的配置文件没有上传完成，则显示所述配置文件的解析状态为待解析状态；

如果所述上传列表中的安装包文件和与所述安装包文件同名的配置文件上传完成，则将所述配置文件加入解析列表，显示所述配置文件的解析状态为解析中；

按照预设解析规则，从所述配置文件中筛选配置字段；

判断是否从所述配置文件中筛选出配置字段；

如果从所述配置文件中筛选出配置字段，则显示所述配置文件的解析状态为解析成功；

如果从所述配置文件中未筛选出配置字段，则显示所述配置文件的解析状态为解析异常。

第二方面，本申请提供一种app批量发版装置，所述装置包括：

创建单元，用于根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个所述安装包文件同名的配置文件；

添加单元，用于将所述安装包文件和所述配置文件放置在同一文件夹内，并添加所述文件夹；

解析单元，用于解析所述安装包文件和所述配置文件的文件名；

第一判断单元，用于判断所述安装包文件和所述配置文件的文件名是否与大版本号相匹配；

上传单元，用于如果所述安装包文件和所述配置文件的文件名与所述大版本号相匹配，将各组所述安装包文件和所述配置文件加入到上传列表，依次上传至服务器，以使所述服务器对所述配置文件进行解析；

接收单元，用于接收服务器反馈的所述安装包文件的上传状态，以及与所述安装包文件同名的配置文件的解析状态；

第二判断单元，用于判断所述安装包文件是否上传成功，以及与所述安装包文件同名的配置文件是否解析成功；

发送单元，用于如果所述安装包文件上传成功，并且与所述安装包文件同名的配置文件解析成功，向所述服务器发送确认发版指令，以对app进行批量发版。

结合第二方面，在第二方面的第一种可实现方式中，所述安装包文件和所述配置文件的文件名依次包括以下信息：交易所id、系统类型、渠道代码、打包日期以及版本名。

结合第二方面，在第二方面的第二种可实现方式中，所述安装包文件的格式为apk或ipa格式，所述配置文件的格式为txt格式。

结合第二方面的第二种可实现方式，在第二方面的第三种可实现方式中，所述解析单元，用于读取ipa、txt以及apk格式文件。

结合第二方面，在第二方面的第四种可实现方式中，所述装置还包括：

终止单元，用于如果所述安装包文件和所述配置文件的文件名与所述大版本号不匹配，终止将所述安装包文件以及与所述安装包文件同名的配置文件加入到上传列表。

结合第二方面，在第二方面的第五种可实现方式中，所述上传单元，还用于如果所述安装包文件上传失败，重新向所述服务器上传所述安装包文件，如果与所述安装包文件同名的配置文件解析失败，重新向所述服务器上传所述配置文件。

第三方面，本申请提供一种app批量发版系统，所述系统包括：发版端和与所述发版端通信连接的服务器；

所述发版端，用于根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个所述安装包文件同名的配置文件，将所述安装包文件和所述配置文件放置在同一文件夹内，并添加所述文件夹，解析所述安装包文件和所述配置文件的文件名，判断所述安装包文件和所述配置文件的文件名是否与大版本号相匹配，如果所述安装包文件和所述配置文件的文件名与所述大版本号相匹配，将各组所述安装包文件和所述配置文件加入到上传列表，依次上传至服务器，以使所述服务器对所述配置文件进行解析；接收服务器反馈的所述安装包文件的上传状态，以及与所述安装包文件同名的配置文件的解析状态，判断所述安装包文件是否上传成功，以及与所述安装包文件同名的配置文件是否解析成功，如果所述安装包文件上传成功，并且与所述安装包文件同名的配置文件解析成功，向所述服务器发送确认发版指令；

所述服务器，用于接收所述发版端上传的所述安装包文件和所述配置文件，对所述配置文件进行解析，向所述发版端反馈所述安装包文件的上传状态，以及与所述安装包文件同名的配置文件的解析状态，接收所述发版端发送的确认发版指令，对app进行批量发版。

由以上技术方案可知，本申请提供了一种app批量发版方法、装置及系统，该方法先根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个安装包文件同名的配置文件，之后将安装包文件和配置文件放置在同一文件夹内，并添加文件夹，再通过解析安装包文件和配置文件的文件名来判断是否与大版本号相匹配，如果匹配，则将各组安装包文件和配置文件加入到上传列表，依次上传至服务器，以使服务器对配置文件进行解析；在安装包文件上传成功，并且与安装包文件同名的配置文件解析成功的条件下，向服务器发送确认发版指令，以实现对app进行批量发版，操作流程简单，尤其在面对客户的大量云交易所定制app时，可显著提升app发版效率，同时也便于后期的维护。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种app批量发版方法的流程图。

图2为本申请实施例提供的一种app批量发版方法中服务器对配置文件进行解析的流程图。

图3为本申请实施例提供的一种app批量发版装置的结构框图。

图4为本申请实施例提供的一种app批量发版系统的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。以下结合附图，详细说明本申请各实施例提供的技术方案。

请参阅图1，为本申请实施例提供的一种app批量发版方法，所述方法包括：

步骤101，根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个安装包文件同名的配置文件。

具体地，由开发人员在发版端批量创建app的安装包文件，同时按照预设的文件命名规则生成每个安装包文件的配置文件。在本实施例中，安装包文件和配置文件的文件名依次包括以下信息：交易所id、系统类型、渠道代码、打包日期以及版本名，即命名格式为“交易所id_系统类型_渠道代码_打包日期_版本名称_版本号”。

其中，交易所id表示合作方交易所的识别id，系统类型可以根据app支持的系统版本进行区分。如果支持的系统为android系统，则系统类型对应为androidpro。如果支持的系统为ios系统，则系统类型对为ios交易版。如果支持的系统为mac，则系统类型对应为mac版。如果支持的系统为windows，则系统类型对应为windows版。渠道代码多用于对app的投放跟踪，具体的代码字符串可根据投放平台名称的不同进行识别，例如“wandoujia”。打包日期的格式为“yyyymmddhhmm”，即“年-月-日-时-分”。版本名称由四个int类型字符拼接而成，单个数字不超过9。版本名称的前三位为pro大版本号，版本名称的第四位为交易所定制版本号。版本号即版本名称的int化，便于对比版本的大小。android系统下，app安装包文件的具体格式为apk格式，在ios系统下，app安装包文件的具体格式为ipa。

以下为两种不同的app的安装包文件的命名示例：

“1001_android_wandoujia_201808131337_3.0.0.1_3001.apk”；

“1001_iosep_company_201808131337_3.0.0.1_3001.ipa”。

具体地，配置文件的编码格式为utf-8，配置文件包含的具体字段包括“section、title、condition以及minvesion”。其中，“section”用于配置文件标识，后面加空格，以及相应语言的缩写，“title”可以为空，用于记载更新标题，“condition”可以为空，用于记载更新内容，“minvesion”即最小版本号，默认为0，用于标识当前版本支持的最小版本号，“minvesion为全语言共用的配置参数。

以下为两种不同的配置文件的记载示例，例如：

[sectionzh-cn]

title＝版本更新2.0

condition＝本次更新了以下内容：<br>1.修复了xxxx的bug<br>2.新增了xxxx功能

minvesion＝0”。

或者：

[sectionen-us]

title＝log

condition＝update:<br>1.fixxxxxxxxxxxxxx。

步骤102，将安装包文件和配置文件放置在同一文件夹内，并添加文件夹。

步骤103，解析安装包文件和配置文件的文件名。

添加文件夹后，发版端将自动解析同目录下的安装包文件与配置文件。

步骤104，判断安装包文件和配置文件的文件名是否与大版本号相匹配。

如果文件名不匹配大版本号，将不支持上传，并且最大支持50组文件的发版。

步骤1041，如果安装包文件和配置文件的文件名与大版本号不匹配，终止将安装包文件以及与安装包文件同名的配置文件加入到上传列表。

步骤105，如果安装包文件和配置文件的文件名与大版本号相匹配，将各组安装包文件和配置文件加入到上传列表，依次上传至服务器，以使服务器对配置文件进行解析。

具体地，安装包文件的格式为apk或ipa格式，配置文件的格式为txt格式。解析安装包文件和配置文件的文件名的步骤中，读取ipa、txt以及apk格式文件。

步骤106，接收服务器反馈的安装包文件的上传状态，以及与安装包文件同名的配置文件的解析状态。

具体地，发版端可显示上传列表，上传列表中具体包含：包文件、配置文件、上传状态、配置文件解析状态以及操作项等。

步骤107，判断安装包文件是否上传成功，以及与安装包文件同名的配置文件是否解析成功。

具体地，配置文件与包文件一同上传成功后，服务器将按照上述文件命名规则对配置文件进行自动解析并保存至服务器。配置文件的解析状态具体可以包括：待解析、解析中、解析成功以及解析异常。

请参阅图2，服务器对配置文件进行解析，具体可以包括以下步骤201～步骤207：

步骤201，判断上传列表中的安装包文件和与安装包文件同名的配置文件是否上传完成。

步骤202，如果上传列表中的安装包文件和与安装包文件同名的配置文件没有上传完成，则显示配置文件的解析状态为待解析状态。

步骤203，如果上传列表中的安装包文件和与安装包文件同名的配置文件上传完成，则将配置文件加入解析列表，显示配置文件的解析状态为解析中。

步骤204，按照预设解析规则，从配置文件中筛选配置字段。

步骤205，判断是否从配置文件中筛选出配置字段。

步骤206，如果从配置文件中筛选出配置字段，则显示配置文件的解析状态为解析成功。

步骤207，如果从配置文件中未筛选出配置字段，则显示配置文件的解析状态为解析异常。

步骤1071，如果安装包文件上传失败，重新向服务器上传安装包文件，如果与安装包文件同名的配置文件解析失败，重新向服务器上传配置文件。

步骤108，如果安装包文件上传成功，并且与安装包文件同名的配置文件解析成功，向服务器发送确认发版指令，以对app进行批量发版。

具体地，安装包文件上传成功，并且配置文件也都解析成功后，服务器将向发版端返回对应的处理结果。相关操作人员对相关的信息进行确认后，即可在发版端向服务器发送确认发版指令，从而实现对app进行批量发版。

由以上实施例可知，本申请提供了一种app批量发版方法，先根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个安装包文件同名的配置文件，之后将安装包文件和配置文件放置在同一文件夹内，并添加文件夹，再通过解析安装包文件和配置文件的文件名来判断是否与大版本号相匹配，如果匹配，则将各组安装包文件和配置文件加入到上传列表，依次上传至服务器，以使服务器对配置文件进行解析；在安装包文件上传成功，并且与安装包文件同名的配置文件解析成功的条件下，向服务器发送确认发版指令，以实现对app进行批量发版；本申请实施例提供的app批量发版方法，操作流程简单，尤其在面对客户的大量云交易所定制app时，可显著提升app发版效率，同时也便于后期的维护。

请参阅图3，为本申请实施例提供的一种app批量发版装置，所述装置包括：

创建单元301，用于根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个安装包文件同名的配置文件。

添加单元302，用于将安装包文件和配置文件放置在同一文件夹内，并添加文件夹。

解析单元303，用于解析安装包文件和配置文件的文件名。

第一判断单元304，用于判断安装包文件和配置文件的文件名是否与大版本号相匹配。

上传单元305，用于如果安装包文件和配置文件的文件名与大版本号相匹配，将各组安装包文件和配置文件加入到上传列表，依次上传至服务器，以使服务器对配置文件进行解析。

接收单元306，用于接收服务器反馈的安装包文件的上传状态，以及与安装包文件同名的配置文件的解析状态。

第二判断单元307，用于判断安装包文件是否上传成功，以及与安装包文件同名的配置文件是否解析成功。

发送单元308，用于如果安装包文件上传成功，并且与安装包文件同名的配置文件解析成功，向服务器发送确认发版指令，以对app进行批量发版。

在本申请实施例提供的一种app批量发版装置中，安装包文件和配置文件的文件名依次包括以下信息：交易所id、系统类型、渠道代码、打包日期以及版本名。安装包文件的格式为apk或ipa格式，配置文件的格式为txt格式。解析单元，用于读取ipa、txt以及apk格式文件。

在本申请实施例提供的一种app批量发版装置中，所述装置还包括：终止单元，用于如果安装包文件和配置文件的文件名与大版本号不匹配，终止将安装包文件以及与安装包文件同名的配置文件加入到上传列表。

在本申请实施例提供的一种app批量发版装置中，上传单元，还用于如果安装包文件上传失败，重新向服务器上传安装包文件，如果与安装包文件同名的配置文件解析失败，重新向服务器上传配置文件。

请参阅图4，本申请实施例还提供一种app批量发版系统，所述系统包括：发版端41和与发版端通信连接的服务器42。

发版端41，用于根据预设的文件命名规则，批量打包创建多个安装包文件，同时分别生成与每个安装包文件同名的配置文件，将安装包文件和配置文件放置在同一文件夹内，并添加文件夹，解析安装包文件和配置文件的文件名，判断安装包文件和配置文件的文件名是否与大版本号相匹配，如果安装包文件和配置文件的文件名与大版本号相匹配，将各组安装包文件和配置文件加入到上传列表，依次上传至服务器，以使服务器对配置文件进行解析；接收服务器反馈的安装包文件的上传状态，以及与安装包文件同名的配置文件的解析状态，判断安装包文件是否上传成功，以及与安装包文件同名的配置文件是否解析成功，如果安装包文件上传成功，并且与安装包文件同名的配置文件解析成功，向服务器发送确认发版指令；

服务器42，用于接收发版端上传的安装包文件和配置文件，对配置文件进行解析，向发版端反馈安装包文件的上传状态，以及与安装包文件同名的配置文件的解析状态，接收发版端发送的确认发版指令，对app进行批量发版。

具体实现中，本申请还提供一种计算机存储介质，其中，该计算机存储介质可存储有程序，该程序执行时可包括本发明提供的app批量发版方法的各实施例中的部分或全部步骤。所述的存储介质可为磁碟、光盘、只读存储记忆体(英文：read-onlymemory，简称：rom)或随机存储记忆体(英文：randomaccessmemory，简称：ram)等。

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

本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于app批量发版装置以及终端实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例中的说明即可。

以上所述的本申请实施方式并不构成对本申请保护范围的限定。