CN110362337A - 应用程序的版本发布方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种应用程序的版本发布方法、装置、设备以及存储介质，涉及应用程序领域。该方法包括：接收终端发送的源包构建请求；根据源包构建请求调用源包构建程序的API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包；接收终端发送的版本发布请求；根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包；向渠道包分发服务器发送分发请求，分发请求用于请求渠道包分发服务器将渠道包分发至发布渠道号对应的发布渠道。在APP的发布和更新过程中，该方法简化了应用程序的版本发布流程，还免去了源包传输过程中的损坏风险，降低了人力资源的浪费，解决了APP发布和更新的交互繁琐的问题。

Description

应用程序的版本发布方法、装置、设备及存储介质

技术领域

本申请涉及互联网领域，特别涉及一种应用程序的版本发布方法、装置、设备及存储介质。

背景技术

应用市场上发布和更新有应用程序(APPlication，APP)的程序包，终端中APP是从应用市场中下载的安装得到的。

APP在应用市场上的发布和更新，是由客户端的开发人员在无线研发管理(wireless Research and Development Management，RDM)平台上手动构建APP源包，在RDM平台对APP源包构建完成后，开发人员从RDM平台的页面上下载APP源包。在进行APP的版本发布时，需要先将APP源包上传至版本发布平台。

上述APP的发布和更新的过程中，首先要手动构建APP源包，其次要下载APP源包，再次要上传APP源包，最终实现APP的版本发布，整个过程需要大量的人力资源，交互繁琐。

发明内容

本申请实施例提供了一种应用程序的版本发布方法、装置、设备及存储介质，可以解决APP的发布和更新的过程中交互繁琐的问题。所述技术方案如下：

根据本申请的一个方面，提供了一种应用程序的版本发布方法，该方法包括：

接收终端发送的源包构建请求，源包构建请求中包括应用程序的发布信息，发布信息中包括发布渠道号；

根据源包构建请求调用源包构建程序的应用程序编程接口API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包；

接收终端发送的版本发布请求；

根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包；

向渠道包分发服务器发送分发请求，分发请求中包括渠道包，分发请求用于请求渠道包分发服务器将渠道包分发至发布渠道号对应的发布渠道。

根据本申请的另一方面，提供了一种应用程序的版本发布装置，该装置包括：

接收模块，用于接收终端发送的源包构建请求，源包构建请求中包括应用程序的发布信息，发布信息中包括发布渠道号；

第一构建模块，用于根据源包构建请求调用源包构建程序的应用程序编程接口API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包；

发送模块，用于接收终端发送的版本发布请求；

第二构建模块，用于根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包；

发送模块，用于向渠道包分发服务器发送分发请求，分发请求中包括渠道包，分发请求用于请求渠道包分发服务器将渠道包分发至发布渠道号对应的发布渠道。

根据本申请的另一方面，提供了一种服务器，该服务器包括：

存储器；

与存储器相连的处理器；

其中，处理器被配置为加载并执行可执行指令以实现如上述第一方面及其可选实施例所述的应用程序的版本发布方法。

根据本申请的另一方面，提供了一种计算机可读存储介质，上述计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，上述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如上述第一方面及其可选实施例所述的应用程序的版本发布方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过接收终端发送的源包构建请求，源包构建请求中包括应用程序的发布信息，发布信息中包括发布渠道号；根据源包构建请求调用源包构建程序的API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包；接收终端发送的版本发布请求；根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包；向渠道包分发服务器发送分发请求，分发请求中包括渠道包，分发请求用于请求渠道包分发服务器将渠道包分发至发布渠道号对应的发布渠道。

上述应用程序的版本发布方法，通过接收终端上的源包构建请求和渠道包分发请求，实现APP的发布和更新，而在APP的发布和更新过程中，不需要手动构建应用程序的源包，也不需要对源包进行下载再上传，简化了应用程序的版本发布流程，还免去了源包传输过程中的损坏风险，降低了人力资源的浪费，解决了APP发布和更新的交互繁琐的问题。

附图说明

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

图1是本申请一个示例性实施例提供的计算机系统的示意图；

图2是本申请一个示例性实施例提供的应用程序的版本发布方法的流程图；

图3是本申请一个示例性实施例提供的文件管理平台的存储目录的界面示意图；

图4是本申请另一个示例性实施例提供的应用程序的版本发布方法的流程图；

图5是本申请一个示例性实施例提供的发布渠道号的管理方法的流程图；

图6是本申请另一个示例性实施例提供的发布渠道号的管理方法的流程图；

图7是本申请一个示例性实施例提供的渠道管理界面的示意图；

图8是本申请另一个示例性实施例提供的渠道管理界面的示意图；

图9是本申请另一个示例性实施例提供的渠道管理界面的示意图；

图10是本申请另一个示例性实施例提供的渠道管理界面的示意图；

图11是本申请另一个示例性实施例提供的渠道管理界面的示意图；

图12是本申请另一个示例性实施例提供的渠道管理界面的示意图；

图13是本申请一个示例性实施例提供的管理界面的示意图；

图14是本申请一个示例性实施例提供的版本管理界面的示意图；

图15是本申请另一个示例性实施例提供的版本管理界面的示意图；

图16是本申请一个示例性实施例提供的发布管理界面的示意图；

图17是本申请一个示例性实施例提供的管理界面的示意图；

图18是本申请另一个示例性实施例提供的发布管理界面的示意图；

图19是本申请另一个示例性实施例提供的发布管理界面的示意图；

图20是本申请另一个示例性实施例提供的发布管理界面的示意图；

图21是本申请另一个示例性实施例提供的发布管理界面的示意图；

图22是本申请一个示例性实施例提供的终端与服务器的交互流程图；

图23是本申请一个示例性实施例提供的应用程序的发布和更新提示方法的流程图；

图24是本申请另一个示例性实施例提供的应用程序的版本发布方法的流程图；

图25是本申请另一个示例性实施例提供的应用程序的版本发布方法的流程图；

图26是本申请另一个示例性实施例提供的应用程序的版本发布方法的流程图；

图27是本申请一个示例性实施例提供的应用程序的版本发布装置的框图；

图28是本申请一个示例性实施例提供的电子设备的结构示意图；

图29是本申请一个示例性实施例提供的服务器的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

对本申请涉及的若干个名词进行简介：

无线研发管理(wireless Research and Development Management，RDM)平台：支持应用程序的研发，包括持续集成平台，应用于本申请中应用程序的源包的构建。

应用程序(APPlication，APP)：是指计算机程序，该计算机程序被开发且运行于操作系统中以实现某项或者某几项特定的任务。

版本发布：是指APP被开发或者更新后，通过一些渠道面向用户开放，使用户能够下载并安装。

请参考图1，其示出了本申请一个示例性实施例提供的计算机系统100的结构框图。该计算机系统100包括：终端120、服务器集群140、以及服务器集群160。

终端120可以是平板电脑、膝上型便携计算机和台式计算机等等。终端120中安装有第一应用程序；第一应用程序支持版本管理系统的运行。可选地，第一应用程序包括版本管理程序或者浏览器，其中，浏览器支持网页版的版本管理系统的运行。本申请中，版本管理系统用于应用程序的版本管理、应用程序的发布管理、以及应用程序的发布渠道管理等等。可选地，应用程序可以包括第一应用程序。

可选地，版本管理系统具有帐号登录功能，用户可以在版本管理系统中注册和登录自己的帐号。

可选地，第一应用程序与应用程序可以具有相同的供应商，也可以具有不同的供应商。

终端120通过有线网络和无线网络与服务器集群140相互连接。服务器集群140可以是多个服务器、虚拟云存储或云计算中心中的任意一种。服务器集群140用于支持应用程序的发布渠道号的存储、应用程序的版本发布信息的存储、以及应用程序的渠道包的构建等等。

可选地，服务器集群140还可以向终端120发送源包构建状态信息、渠道包发布状态信息等等。可选地，服务器集群140可以是由应用程序供应商提供的服务器，也可以是由非应用程序供应商提供的第三方服务器。

服务器集群140与服务器集群160之间通过有线网络或者无线网络相连。可选地，服务器集群160包括源包构建服务器162和渠道包分发服务器164。服务器集群140与源包构建服务器162、渠道包分发服务器164之间分别通过有线网络或者无线网络相连。

源包构建服务器162用于将应用程序的程序代码构建成为应用程序的源包；渠道包分发服务器164用于将渠道包分发至对应的发布渠道。

本实施例以服务器集群140包括两个渠道包构建服务器142，服务器集群160包括一个源包构建服务器162和一个渠道包分发服务器164来举例说明，但渠道包构建服务器142可能多于或少于两个，源包构建服务器162和渠道包分发服务器164也可能多于一个；比如，服务器集群140由一个服务器上的多个虚拟机实现，或者由几十台服务器实现，本实施例对此不加以限定。

示意性的，终端120上安装有浏览器，该浏览器支持版本管理系统的运行。终端120将版本管理系统上触发的源包构建请求发送至渠道包构建服务器142，由渠道包构建服务器142调用源包构建程序的应用程序编程接口(Application Programming Interface，API)，通过源包构建程序构建应用程序的源包。比如，源包构建程序可以是RDM平台，由源包构建服务器162支持上述RDM平台的运行，以实现应用程序的源包的构建。

在源包构建服务器162构建应用程序的源包完成之后，渠道包构建服务器142将构建完成的应用程序的源包拉取回来。渠道包构建服务器142接收终端上触发的版本发布请求，根据版本发布请求对应用程序的源包构建渠道包；将构建完成的渠道包发送至渠道包分发服务器164，由渠道包分发服务器164分发至对应的发布渠道。

请参考图2，是本申请示出的一个示例性实施例提供的应用程序的版本发布方法，以该方法应用于图1所示的计算机系统中为例进行说明，该方法包括：

步骤201，终端向服务器发送源包构建请求。

上述源包构建请求中包括应用程序的发布信息，发布信息中包括发布渠道号。

上述发布渠道号对应的发布渠道包括以下任意一种：

灰度渠道；临时有效渠道；常规有效渠道；

其中，灰度发布是指过渡式的发布方式，针对特定的用户进行应用程序的版本发布，使应用程序的发布版本能够面向上述特定的用户的渠道，即为灰度渠道；临时有效渠道为本次新增的正式发布渠道；常规有效渠道为存储的正式发布渠道；正式发布渠道是指能够使应用程序的发布版本面向所有用户的渠道。

可选地，发布信息中还包括应用程序的任务标识、程序代码的版本标识以及源包构建代码的版本号。其中，应用程序的任务标识是指应用程序的源包构建任务的唯一标识；程序代码的版本标识是指一个版本的程序代码的唯一标识；源包构建代码的版本号是指构建应用程序的源包的代码的版本标识。

步骤202，服务器接收终端发送的源包构建请求。

步骤203，服务器根据源包构建请求调用源包构建程序的API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包。

服务器接调用源包构建程序的API启动源包构建任务，由源包构建服务器将应用程序的程序代码构建成为应用程序的源包；上述源包中不包括渠道号。

可选地，源包的构建可以包括以下示意性步骤：

1)服务器根据源包构建请求调用源包构建程序的API，通过源包构建程序对源包进行异步构建。

应用程序的任务标识中包括应用程序的程序代码在服务器中的存储位置，由源包构建服务器从上述存储位置上获取对应的程序代码，将程序代码构建为源包。

其中，应用程序的源包的构建过程为异步过程，因此，服务器通过步骤2)确定源包的构建状态。

2)服务器执行构建状态监控脚本轮询检测源包的构建状态。

构建状态监控脚本是服务器中用于监控对源包异步构建时的构建进度的脚本。

服务器建立一个源包构建任务对一个应用程序的源包进行异步构建，服务器轮询检测源包的构建状态；当源包构建单元中的构建状态均为构建完毕时，确定源包构建服务器中应用程序的源包的构建状态为构建完毕。

3)当源包的构建状态为构建完毕时，服务器从源包构建服务器中获取应用程序的源包。

该服务器属于服务器集群，当源包构建状态为构建完毕时，服务器从源包构建服务器中获取应用程序的源包，将应用程序的源包存储至服务器集群中的每一个服务器中。

服务器在从源包构建服务器中拉取构建完毕的应用程序的源包之前，还需要对应用程序的源包进行检验，可选地，服务器对应用程序的源包进行参数校验；当校验结果为参数校验准确时，服务器从源包构建服务器中获取应用程序的源包，示意性步骤如下：

a、服务器获取源包的名称中的关键字，将关键字与应用程序的任务标识、程序代码的版本标识以及源包构建代码的版本号进行匹配。

b、当关键字与应用程序的任务标识、程序代码的版本标识以及源包构建代码的版本号匹配时，服务器执行步骤从源包构建服务器中获取应用程序的源包。

首先，服务器判断关键字中第一字段与应用程序的任务标识是否匹配；判断关键字中第二字段与程序代码的版本标识是否匹配；判断关键字中第三字段与源包构建代码的版本号是否匹配。

其中，第一字段是关键字中与应用程序的任务标识对应的字段；第二字段是关键字中与程序代码的版本标识对应的字段；第三字段是关键字中与源包构建代码的版本号对应的字段。

其次，当第一字段与应用程序的任务标识匹配、第二字段与程序代码的版本标识匹配、第三字段与源包构建代码的版本号匹配时，服务器执行步骤从源包构建服务器中获取应用程序的源包。

比如，源包的名称对应的字段名为build_apk_name，应用程序的任务标识为对应的字段名为rdm_job_id，程序代码的版本标识对应的字段名为version_code，源包构建代码的版本号对应的字段名为svn_no；从build_apk_name中获取第一字段、第二字段和第三字段，分别与rdm_job_id、version_code和svn_no进行匹配；当第一字段与rdm_job_id匹配、第二字段与version_code匹配、以及第三字段与svn_no匹配时，服务器执行步骤从源包构建服务器中获取应用程序的源包。

其中，rdm_job_id用于关联RDM平台的源包构建任务，version_code是应用程序的程序代码的版本编号，svn_no是Subversion(一个自由开源的版本控制系统)中提供源包构建代码的版本号。

步骤204，终端向服务器发送版本发布请求。

步骤205，服务器根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包。

服务器将源包构建成为渠道包的示意性步骤如下：

1)服务器根据版本发布请求创建渠道包构建任务，并将渠道包构建任务添加至任务队列。

2)服务器执行任务队列中的渠道包构建任务，将发布渠道号分别写入源包，生成对应的渠道包。

可选地，服务器采用先进先出的顺序执行任务队列中的渠道包构建任务；比如，建立第一构建任务放置至任务队列，之后建立第二构建任务放置至任务队列，当服务器执行渠道包构建任务时，首先，服务器执行第一构建任务，其次，服务器执行第二构建任务。

可选地，服务器执行任务队列中的渠道包构建任务，对发布渠道号对应的渠道包进行同时构建，生成对应的渠道包；比如，渠道包构建服务器可以通过对300个渠道号对应的渠道包进行构建。

可选地，服务器构建渠道包的示意性步骤如下：

a、采用签名算法将第i个发布渠道号写入应用程序的源包，生成第i个发布渠道号对应的第i个渠道包，i为正整数。

可选地，上述签名算法可以是安卓V2签名算法。

步骤206，服务器向渠道包分发服务器发送分发请求。

分发请求中包括发布渠道号以及对应的渠道包，分发请求用于请求渠道包分发服务器将渠道包分发至发布渠道号对应的发布渠道。

步骤207，渠道包分发服务器根据分发请求将渠道包分发至上述发布渠道号对应的发布渠道。

渠道分发服务器将渠道包对应分发至发布渠道。示意性的，渠道分发服务器中运行有文件管理(static package manager，spm)平台，spm平台对渠道包进行存储及管理，还将渠道包对应分发至发布渠道。

可选地，渠道分发服务器将不同的版本的应用程序的渠道包存储至不同的文件路径下。示意性的，应用程序的渠道包的存储的文件路径由spm平台管理，如图3，不同版本的渠道包对应存储至标识有版本号的文件夹下，图中spm平台的用户界面中显示了版本号为“7.21.3”对应的文件夹下的渠道包。

综上所述，本实施例提供的应用程序的版本发布方法，服务器通过接收终端发送的源包构建请求，源包构建请求中包括应用程序的发布信息，发布信息中包括发布渠道号；根据源包构建请求调用源包构建程序的API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包；接收终端发送的版本发布请求；根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包；向渠道包分发服务器发送分发请求，分发请求中包括渠道包，分发请求用于请求渠道包分发服务器将渠道包分发至发布渠道号对应的发布渠道。

上述应用程序的版本发布方法，通过接收终端上的源包构建请求和渠道包分发请求，实现APP的发布和更新，而在APP的发布和更新过程中，不需要手动构建应用程序的源包，也不需要对源包进行下载再上传，简化了应用程序的版本发布流程，还免去了源包传输过程中的损坏风险，降低了人力资源的浪费，解决了APP发布和更新的交互繁琐的问题。

该应用程序的版本发布方法还通过服务器对发布渠道号对应的渠道包进行自动构建，不需要对发布渠道号对应的渠道包分别进行手动构建，也降低了人力资源的浪费。

该应用程序的版本发布方法还采用安卓V2签名算法对渠道包进行构建，解决了安卓V1签名算法打包渠道包时产生的安全漏洞，提升了渠道包的稳定性。以及通过将不同的版本的应用程序的渠道包存储至不同的文件路径下，实现版本隔离，解决了每次应用程序的版本发布时覆写渠道包数据，导致下载渠道包时渠道包损坏的问题。

需要说明的是，基于图2，在渠道包分发至对应的发布渠道的过程中，服务器还监控渠道包的分发状态，根据渠道包的分发状态确定是否对释放存储空间，示意性的，在步骤207之后增加步骤208至步骤210，如图4，步骤如下：

步骤208，服务器执行分发状态监控脚本轮询渠道包的分发状态。

分发状态监控脚本是服务器中用于监控渠道包的分发状态的脚本。可选地，分发状态监控脚本还可以用于探测异常状态以及重置分发状态；比如，探测出未分发渠道包等待时间过长、渠道包分发时间过长、以及渠道包等待分发重试时间过长等等异常状态；又比如，全部渠道包发布完毕，将版本发布的发布状态标记为发布成功。

可选地，服务器对渠道包进行异步分发；也就是说，服务器可以对多个渠道包同时进行分发。

由于受内容分发网络(Content Delivery Network，CDN)节点同步的影响，服务器采用轮询的方式检测渠道包的发布状态。

步骤209，服务器判断渠道包的分发状态是否为分发完毕。

步骤210，当渠道包的分发状态为分发完毕时，服务器清除本端服务器中存储的渠道包。

其中，本端服务器是指服务器自身。当至少一个渠道包中每一个渠道包的分发状态均为分发完毕时，服务器清除自身存储的上述至少一个渠道包。

可选地，服务器对渠道包分批次分发至对应的发布渠道，当所有批次的渠道包分发完成时，服务器清除自身存储的应用程序的源包和渠道包。

综上所述，本实施例提供的应用程序的版本发布方法，在渠道发布完成之后，服务器清除自身存储的渠道包，等待下一批次的渠道包分发，能够为下一批次的渠道包的存储以及分发提供存储空间。

还需要说明的是，服务器中存储有发布渠道号，服务器对自身存储的无效渠道号进行清除，以避免对无效渠道包的构建和分发，如图5，示意性步骤如下：

步骤301，服务器清除存储的发布渠道号中不符合预设条件的发布渠道号。

可选地，服务器周期性对自身存储的发布渠道号中不符合预设条件的发布渠道号进行清除。

可选地，预设条件包括以下至少一项：

发布渠道号的数量小于或者等于第一数量阈值；比如，服务器中存储的发布渠道号的数量不能超过2000；

发布渠道号属于白名单，白名单中包括长期有效的发布渠道号，长期有效的发布渠道号被设置为不被自动删除；比如，官方渠道号属于白名单，在清除的过程中能够不被删除；

在第一预设时间段内，发布渠道号的新增用户大于第二数量阈值；比如，上一个月内，第三方电子市场的新增用户的数量大于300；

发布渠道号为第二预设时间段内的新增发布渠道号；比如，发布渠道号为本月新增发布渠道号。

需要说明的是，服务器清除不符合预设条件的发布渠道号的时刻，与步骤201和步骤209的执行顺序之间不相关，本申请的实施例中，对步骤301的执行时刻不加以限制。

综上所述，本实施例提供的发布渠道的管理方法，能够对无效的发布渠道号及时删除，通过发布渠道的管理，避免了无效渠道包的构建和发布，增大了应用程序的版本发布效率，降低了应用程序的版本发布耗时。

在一些实施例中，用户还手动设置应用程序的版本发布对应的发布渠道号，即用户通过手动设置进行渠道管理，如图6，步骤如下：

步骤401，在终端上显示版本管理系统的渠道管理界面。

其中，渠道管理界面上包括渠道录入按钮控件，渠道录入按钮控件用于触发对发布渠道的渠道信息录入。

可选地，渠道录入按钮控件包括的单个渠道录入按钮控件和/或批量渠道录入按钮控件。

可选地，渠道信息包括发布渠道的渠道标识(渠道ID)、渠道类型、渠道名称、渠道状态和渠道描述中的至少一种。

示意性的，如图7，渠道ID可以是1001、2002等等；渠道类型可以包括第三方电子市场以及厂商电子市场等等；渠道名称可以为一二三、安卓市场等等；渠道状态可以包括常规有效、常规无效和临时新增等等，其中，常规有效表示在应用程序的版本发布的过程中该发布渠道有效，常规无效表示在应用程序的版本发布的过程中该发布渠道无效，临时新增表示在应用程序的本次版本发布的过程中该发布渠道有效；渠道描述表示对于该渠道的特征描述，比如，对于发布渠道的用处特征描述“用来测试的渠道号”。

步骤402，终端接收渠道录入按钮控件上的第一触发操作。

可选地，终端接收单个渠道录入按钮控件上的第一触发操作，以实现单个发布渠道的录入。

可选地，终端接收批量渠道录入按钮控件上的第一触发操作，以实现批量发布渠道的录入。

步骤403，终端显示渠道录入界面。

可选地，终端显示单个渠道录入界面，该单个渠道录入界面中包括渠道类型、渠道状态、渠道ID、渠道名称和渠道描述的录入控件，用于录入发布渠道的上述发布信息。示意性的，如图8，录入单个渠道，渠道类型为第三方电子市场，渠道状态为常规有效，渠道ID为110000，渠道名字为测试渠道号，渠道描述为用来测试的渠道号。

可选地，终端显示批量渠道录入界面，该批量渠道录入界面中包括导入控件，以实现对批量渠道的直接导入。示意性的，如图9，录入批量渠道，渠道状态为临时新增；批量渠道录入界面上包括导入控件，可以导入表格，表格中包括以固定格式写入的发布渠道的发布信息，比如，固定格式为渠道ID+渠道类型+渠道名称+渠道描述。

渠道录入界面中包括确定按钮控件，用于确定录入发布渠道的渠道信息。

步骤404，终端接收确定按钮控件上的第二触发操作。

步骤405，终端根据第二触发操作将发布渠道的渠道信息存储至服务器中。

示意性的，渠道信息的结构定义可以如下：

表1.渠道信息表结构定义

字段名	字段说明	数据类型
			channel_id	渠道ID	bigint(20)
channel_category	渠道类别	tinyint(1)
			channel_name	渠道名称	varchar(20)
channel_state	渠道状态	tinyint(1)
			gray_channel_flag	灰度渠道标识	tinyint(1)

需要说明的是，终端还能够通过版本管理系统对发布渠道的发布信息进行修改，渠道管理界面上还包括编辑按钮控件，用于对发布渠道的渠道信息的修改，示意性的步骤如下：

1)终端接收编辑按钮控件上的第三触发操作；

2)终端根据第三触发操作显示渠道信息的编辑界面；

编辑界面中包括渠道信息的编辑控件，示意性的，该渠道信息的编辑控件可以用于修改渠道状态，或者修改渠道类型，或者修改为灰度渠道/非灰度渠道等等，如图10，对渠道状态进行修改，可以将常规有效修改为常规无效或者临时新增。

编辑界面上包括修改确定按钮控件，用于确定将渠道信息中的修改的渠道信息写入服务器中。

3)终端接收修改确定按钮控件上的第四触发操作；

4)终端根据第四触发操作将修改的渠道信息写入服务器中。

还需要说明的是，终端还能够通过版本管理系统对发布渠道进行删除，渠道管理界面上还包括删除按钮控件，用于对发布渠道的删除渠道信息的修改，示意性步骤如下：

1)终端接收删除按钮控件上的第五触发操作；

2)终端根据第五触发操作删除选中的发布渠道。

比如，在图11中，渠道管理界面上显示有删除按钮控件，点击删除按钮控件，在渠道管理界面上叠加显示确认删除界面，在确认删除后，将选中的发布渠道删除。

如图12，在渠道管理界面上还能够实现对发布渠道的筛选，设置筛选条件为：渠道名称为安卓市场，则在渠道管理界面上仅显示渠道名称为安卓市场的发布渠道的渠道信息。

综上所述，本实施例提供的发布渠道的管理方法，能够实现对发布渠道的管理，避免了无效渠道对应的渠道包的构建与分发，提升了发布效率，也降低了发布耗时。

在一些实施例中，版本管理系统包括渠道管理之外，还包括版本管理。如图13，版本管理系统的版本管理界面中包括发布按钮控件，该发布按钮控件用于触发显示发布管理界面，以实现应用程序的版本发布，示意性步骤如下：

1)终端接收发布按钮控件上的第一发布操作；

2)终端根据第一发布操作显示发布管理界面；发布管理界面上包括正式发布按钮控件；

3)终端接收正式发布按钮控件上的第二发布操作；

4)终端根据第二发布操作对应用程序进行版本发布。

也就是说，终端根据第二发布操作生成分发请求，终端将分发请求对应用程序的源包进行渠道包构建，并将渠道包分发至对应的发布渠道，实现应用程序的版本发布。

需要说明的是，版本管理界面上包括正式发布编辑控件和灰度发布编辑控件，实现对应用程序的版本的灰度发布和正式发布；

当对应用程序的版本进行灰度发布时，示意性步骤如下：

1)终端接收灰度发布编辑控件上的编辑操作；

2)终端显示灰度发布的第一编辑界面；

第一编辑界面中包括灰度渠道选择控件，用于选择灰度渠道，灰度渠道是在进行渠道管理时写入的灰度渠道；第一编辑界面还包括应用程序的版本号、版本名称以及版本说明的录入控件。

示意性的，如图14，录入版本号为7.21.1，版本名称为动漫7.21.1，版本说明为新版本发布，选择的灰度渠道为2002、2056、2093。

第一编辑界面上包括第一提交按钮控件，该第一提交按钮控件用于提交编辑的灰度发布的内容。

3)终端接收第一提交按钮控件上的第一提交操作；

4)终端根据第一提交操作确定应用程序的版本发布的发布信息，且显示发布渠道的第一确定界面；

该发布信息包括发布信息中包括应用程序的任务标识、程序代码的版本标识、源包构建代码的版本号以及发布渠道号。

可选地，第一确定界面中包括第一确定按钮控件，第一确定按钮控件用于确定向服务器发送源包构建请求。

5)终端接收第一确定按钮控件上的第一确定操作；

6)终端根据第一确定操作确定构建应用程序的源包。

当对应用程序的版本进行正式发布时，示意性步骤如下：

1)终端接收正式发布编辑控件上的编辑操作；

2)终端显示正式发布的第二编辑界面；

第二编辑界面中包括应用程序的版本号、版本名称、版本说明以及渠道方式的录入控件。其中，渠道方式包括临时有效渠道和常规有效渠道。如图15，示意性的，录入版本号为7.21.1，版本名称为动漫7.21.1，版本说明为新版本发布，选择渠道方式为临时有效渠道。

第二编辑界面上包括第二提交按钮控件，该第二提交按钮控件用于提交编辑的正式发布的内容。

3)终端接收第二提交按钮控件上的第二提交操作；

4)终端根据第二提交操作确定应用程序的版本发布的发布信息，且显示发布渠道的第二确定界面；

可选地，第二确定界面中包括第二确定按钮控件，第二确定按钮控件用于确定向服务器发送源包构建请求。

5)终端接收第二确定按钮控件上的第二确定操作；

6)终端根据第二确定操作确定构建应用程序的源包。

示意性的，如图16，在发布管理界面上还能够实现对版本分支的筛选，比如，对版本分支“7.21.0”进行筛选，仅显示版本分支“7.21.0”的发布内容。

其次，如图17，在发布管理界面上还包括“去发布”按钮控件，当接收到“去发布”按钮控件上的触发操作时，终端上显示版本管理界面，对应用程序的版本发布进行管理操作。

再次，如图18，在发布管理界面上还包括“取消发布”按钮控件，用于取消应用程序的版本发布。

再有，如图19，在发布管理界面上还包括“开始分发”按钮控件，用于触发渠道包的构建与分发。

还需要说明的是，版本管理系统还包括发布管理界面，在灰度发布/正式发布的过程中，在确定构建应用程序的源包之后，显示版本管理系统的发布管理界面。

在一些实施例中，发布管理界面中显示发布状态，比如，发布状态为待发布、发布成功或者取消发布。当发布状态为发布成功时，发布管理界面上显示详情查看按钮控件，用于查看详情界面，如图20；可选地，详情界面上包括渠道包下载控件，用于渠道包的下载。

在源包构建成功之后，发布管理界面上还显示源包下载控件，用于源包的下载。如图21，终端的发布管理界面上还显示“源包下载”按钮控件，用于对应用程序的源包下载；终端接收“源包下载”按钮控件上的触发操作，显示下载途径，比如，可以通过二维码扫一扫进行下载。

发布管理界面上还显示应用程序的版本发布控件和发布取消控件；当终端接收到版本发布控件上的版本发布操作时，终端向服务器发送分发请求，以实现渠道包的构建与分发。

可选地，终端接收到版本发布控件上的版本发布操作，显示第三确定界面；第三确定界面上包括第三确定按钮控件；终端接收第三确定按钮控件上的第三确定操作，向服务器发送分发请求，以实现渠道包的构建与分发。示意性的，如图20，第三确定界面上包括发布信息，发布信息可以包括源包的版本号、名称、构建时间、version code、版本名称、发布类型和版本说明等等。发布成功后在发布管理界面上显示“已完成”，表示应用程序的版本发布成功。

可选地，终端接收发布取消控件的取消操作，取消操作用于取消应用程序的版本发布。

需要说明的是，终端版本发布记录以及渠道发布记录存储至服务器中，示意性的，版本发布记录的数据结构如表2所示：

表2.发布记录数据表结构定义

字段名	字段说明	数据类型
			rdm_job_id	RDM任务ID	bigint(20)
publish_type	发布类型	tinyint(1)
			version_code	APP version code	int(11)
svn_no	svn版本号	bigint(20)
			version_no	APP发布版本号	varchar(20)
version_name	APP发布版本名称	varchar(20)
			publish_state	发布状态	tinyint(2)
build_apk_name	构建包包名	varchar(64)

渠道发布记录的数据结构如表3所示：

表3.渠道发布记录数据表结构

字段	字段说明	数据类型
			list_id	版本发布列表ID	bigint(20)
channel_id	渠道ID	bigint(20)
			publish_state	分发状态	tinyint(1)

还需要说明的是，在上述一些实施例中，终端上登录有版本管理系统的网页(WEB)，用于实现与服务端(服务器)的交互，如图22，其交互过程可以如下步骤所示：

步骤11，终端根据操作指令请求相应服务端接口。

步骤22，服务端返回响应数据至终端。

步骤33，终端展示相应的可视化界面。

通过上述三个步骤实现前端与服务端之间的交互。

在一些实施例中，终端中提示应用程序的发布与更新，如图23，示意性步骤如下：

步骤501，开始。

步骤502，查询APP渠道号对应的配置信息。

APP渠道号对应的配置信息中包括应用程序的第一版本号。

步骤503，查询官方渠道对应的配置信息。

官方渠道对应的配置信息中包括应用程序的第二版本号。

步骤504，判断APP渠道号对应的配置信息是否为空。

当APP渠道号对应的配置信息为空时，执行步骤505；当APP渠道号对应的配置信息不为空时，执行步骤506。

步骤505，判断官方渠道对应的配置信息中版本号是否大于本地版本号。

终端判断第二版本号是否大于本地版本号。当官方渠道对应的配置信息中版本号小于或等于本地版本号时，执行步骤508；当官方渠道对应的配置信息中版本号大于本地版本号时，执行步骤509。

步骤506，判断APP渠道号对应的配置信息中版本号是否大于官方渠道对应的配置信息中版本号。

终端判断第一版本号是否大于第二版本号。当APP渠道号对应的配置信息中版本号小于或等于官方渠道对应的配置信息中版本号时，执行步骤505；当APP渠道号对应的配置信息中版本号大于官方渠道对应的配置信息中版本号时，执行步骤507。

步骤507，判断APP渠道号对应的配置信息中版本号是否大于本地版本号。

终端判断第一版本号是否大于本地版本号。当APP渠道号对应的配置信息中版本号小于或等于本地版本号时，执行步骤508；当APP渠道号对应的配置信息中版本号大于本地版本号时，执行步骤509。

步骤508，不提示升级。

步骤509，提示升级。

步骤510，结束。

综上所述，本实施例提供的应用程序的升级提示方法，能够通过官方渠道与本地渠道的对比来确定是否提示升级，实现了容错处理。

请参考图24，是本申请另一个示例性实施例提供的应用程序的版本发布方法，该方法示出了应用程序的发布或者更新的逻辑过程，以该方法包括：

步骤601，开始。

步骤602，在终端中录入应用程序的版本发布的发布信息。

用户在终端中录入应用程序的版本发布的发布信息，该发布信息包括应用程序的任务标识、程序代码的版本标识、源包构建代码的版本号、应用程序的版本号、应用程序的版本名称、应用程序的版本说明、发布渠道号中的至少一种。

可选地，终端上安装有浏览器，该浏览器支持网页版的版本管理系统的运行；用户在上述版本管理系统的用户界面上录入应用程序的版本发布的发布信息。

用户录入上述发布信息之后，终端将上述发布信息写入渠道包构建服务器中。

步骤603，调用RDM平台的API启动应用程序的源包的构建。

终端向服务器发送源包构建请求；服务器根据源包构建请求调用RDM平台的API启动应用程序的源包的构建，通过运行RDM平台的源包构建服务器对应用程序的源包进行构建。

当应用程序的源包的构建启动成功时，执行步骤604；当应用程序的源包的构建启动失败时，执行步骤613。

步骤604，执行源包构建监控脚本。

应用程序的源包的构建过程为异步过程，服务器执行源包构建监控脚本，轮询检测应用程序的源包的构建状态；当源包的构建状态为构建完毕时，执行步骤605。

步骤605，对源包的构建参数进行校验。

服务器对源包的构建参数进行校验，其中，构建参数包括应用程序的任务标识、程序代码的版本标识以及源包构建代码中的至少一种。

示意性的，服务器检验源包的名称中关键字是否与构建参数匹配；当上述关键字与构建参数匹配时，确定检验通过，执行步骤606；当上述关键字与构建参数不匹配时，确定检验不通过，执行步骤613。

步骤606，从源包构建服务器中拉取构建好的源包。

服务器属于服务器集群，服务器从源包构建服务器中拉取构建好的应用程序的源包，并将源包存储至服务器集群中的每一个服务器。当服务器对源包拉取成功时，执行步骤607；当服务器对源包拉取失败时，执行步骤613。

步骤607，获取应用程序的版本发布的发布渠道号。

服务器中存储有发布渠道号，服务器获取该应用程序的版本发布对应的发布渠道号，上述发布渠道号是用户预先设置的，或者版本管理系统中默认的发布渠道号。

步骤608，将应用程序的源包上传至文件管理平台。

服务器将应用程序的源包上传至spm平台上，通过spm进行对源包的文件管理。

步骤609，启动渠道包的构建和分发流程。

服务器建立渠道包构建任务，将应用程序构建成为发布渠道号对应的渠道包，并将渠道包上传至spm平台，由运行spm平台的渠道包分发服务器将渠道包对应分发至相应的发布渠道；且有spm平台进行对渠道包的文件管理。

步骤610，分发完毕，更新版本发布状态为发布成功。

当渠道包分发服务器对渠道包分发完毕时，服务器将版本发布状态更新为成功，并将版本发布状态写入发布管理数据中。

步骤611，推送渠道配置信息，线上生效。

服务器向终端推送配置信息，使应用程序的版本发布线上生效，也就是说，用户可以通过应用市场下载并安装应用程序。

可选地，服务器通过邮件发送的方式提示应用程序的版本发布成功，当收到版本发送成功的提示时，手动触发渠道配置信息的推送。

步骤612，清理临时文件。

服务器清理存储的应用程序的源包和渠道包，释放存储空间。

步骤613，更新版本发布状态为失败。

服务器将版本发布状态更新为失败，并将版本发布状态写入发布管理数据中。

综上所述，本申请提供的应用程序的版本发布方法，在APP的发布和更新过程中，不需要手动构建应用程序的源包，也不需要对源包进行下载再上传，简化了应用程序的版本发布流程，还免去了源包传输过程中的损坏风险，降低了人力资源的浪费，解决了APP发布和更新的交互繁琐的问题。

基于图24，服务器对渠道包构建时，首先，生成渠道包构建任务，如图25，步骤如下：

步骤60901，开始。

步骤60902，服务器执行渠道包构建脚本。

步骤60903，服务器生成渠道包构建任务。

其中，每一个渠道包构建任务具有唯一的任务标识。

步骤60904，服务器将发布渠道号与渠道包构建任务进行关联。

发布渠道号与渠道包构建任务的关联用于指示服务器执行该渠道包构建任务，以实现关联的发布渠道号对应的渠道包的构建。

可选地，服务器通过任务标识对发布渠道号与渠道包构建任务进行关联。

步骤60905，服务器将渠道包构建任务放置至任务队列。

服务器将渠道包构建任务放置至任务队列，等待被执行。

步骤60906，结束。

基于图25，服务器对于渠道包的构建与分发，可以通过如图26所示的逻辑流程来实现，步骤如下：

步骤60907，服务器探测任务队列。

步骤60908，服务器探测任务队列中是否存在渠道包构建任务。

当服务器探测到任务队列中存在渠道包构建任务时，执行步骤60909；当服务器探测到任务队列中不存在渠道包构建任务时，等到1秒钟(s)，之后返回执行步骤60907。

步骤60909，服务器判断渠道包构建任务关联的发布渠道号是否消耗完毕。

服务器判断渠道包构建任务关联的发布渠道号对应的渠道包是否均已经构建完毕，当关联的发布渠道号对应的渠道包均已构建完毕，则表示发布渠道号消耗完毕，执行步骤60917；当存在关联的发布渠道号对应的渠道包未构建，则表示发布渠道号未消耗完毕，执行步骤60910。

步骤60910，服务器从未消耗的发布渠道号中取出定量发布渠道号。

步骤60911，服务器更新上述定量发布渠道号的渠道号状态为处理中。

步骤60912，服务器构建定量发布渠道号对应的渠道包。

步骤60913，服务器将渠道包上传至spm平台，并向spm平台发送分发请求。

该分发请求用于指示渠道包分发服务器将渠道包分发至对应的发布渠道，渠道包分发服务器支持spm平台的运行。

步骤60914，服务器轮询探测渠道包的发布状态。

服务器轮询探测spm平台对渠道包的分发进度，确定出渠道包的分发状态，比如，spm平台对渠道包分发完成，则确定渠道包的分发状态为分发完成。当渠道包分发完成时，执行步骤60915；当渠道包的分发未完成时，等待3s，返回执行步骤60914。

步骤60915，服务器更新渠道包的分发状态。

服务器将渠道包的分发状态更新为未分发完成。

步骤60916，服务器删除渠道包。

服务器删除自身存储的渠道包。

步骤60917，服务器释放任务队列资源。

服务器释放任务队列资源，等待1s，返回执行步骤60907。

请参考图27，是本申请示出的一个示例性实施例提供的应用程序的版本发布装置，该装置可以通过软件、硬件或者二者的结合实现服务器的一部分或者全部，该装置包括：

接收模块701，用于接收终端发送的源包构建请求，源包构建请求中包括应用程序的发布信息，发布信息中包括发布渠道号；

第一构建模块702，用于根据源包构建请求调用源包构建程序的应用程序编程接口API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包；

发送模块703，用于接收终端发送的版本发布请求；

第二构建模块704，用于根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包；

发送模块703，用于向渠道包分发服务器发送分发请求，分发请求中包括渠道包，分发请求用于请求渠道包分发服务器将渠道包分发至发布渠道号对应的发布渠道。

在一些实施例中，第二构建模块704，用于根据版本发布请求创建渠道包构建任务，并将渠道包构建任务添加至任务队列；执行任务队列中的渠道包构建任务，将发布渠道号分别写入源包，生成对应的渠道包。

在一些实施例中，第二构建模块704，用于采用签名算法将第i个发布渠道号写入源包，生成第i个发布渠道号对应的第i个渠道包，i为正整数。

在一些实施例中，第一构建模块702，用于根据源包构建请求调用API，通过源包构建程序对源包进行异步构建；执行构建状态监控脚本轮询检测源包的构建状态；当源包的构建状态为构建完毕时，从源包构建服务器中获取源包。

在一些实施例中，发布信息中包括应用程序的任务标识、程序代码的版本标识以及源包构建代码的版本号；

该装置还包括：

匹配模块705，用于获取源包的名称中的关键字，将关键字与应用程序的任务标识、程序代码的版本标识以及源包构建代码的版本号进行匹配；当关键字与应用程序的任务标识、程序代码的版本标识以及源包构建代码的版本号匹配时，执行步骤从源包构建服务器中获取源包。

在一些实施例中，该装置还包括：

清除模块706，用于执行分发状态监控脚本轮询渠道包的分发状态；当渠道包的分发状态为分发完毕时，清除本端服务器中存储的渠道包。

在一些实施例中，清除模块706，还用于清除存储的发布渠道号中不符合预设条件的发布渠道号。

在一些实施例中，预设条件包括以下至少一项：

发布渠道号的数量小于或者等于第一数量阈值；

发布渠道号属于白名单，白名单中包括长期有效的发布渠道号，长期有效的发布渠道号被设置为不被自动删除；

在第一预设时间段内，发布渠道号的新增用户大于第二数量阈值；

发布渠道号为第二预设时间段内的新增发布渠道号。

综上所述，本实施例提供的应用程序的版本发布装置，通过接收终端发送的源包构建请求，源包构建请求中包括应用程序的发布信息，发布信息中包括发布渠道号；根据源包构建请求调用源包构建程序的API，通过源包构建程序将应用程序的程序代码构建成为应用程序的源包；接收终端发送的版本发布请求；根据版本发布请求将源包分别构建成为发布渠道号对应的渠道包；向渠道包分发服务器发送分发请求，分发请求中包括渠道包，由渠道包分发服务器根据分发请求将渠道包分发至发布渠道号对应的发布渠道。

上述应用程序的版本发布装置，通过接收终端上的源包构建请求和渠道包分发请求，实现APP的发布和更新，而在APP的发布和更新过程中，不需要手动构建应用程序的源包，也不需要对源包进行下载再上传，简化了应用程序的版本发布流程，还免去了源包传输过程中的损坏风险，降低了人力资源的浪费，解决了APP发布和更新的交互繁琐的问题。

该应用程序的版本发布装置还通过服务器对发布渠道号对应的渠道包进行自动构建，不需要对发布渠道号对应的渠道包分别进行手动构建，也降低了人力资源的浪费。

请参考图28，其示出了本申请一个示例性实施例提供的终端800的结构框图。该终端800可以是：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group AudioLayer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts GroupAudio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端800还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端800包括有：处理器801和存储器802。

处理器801可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器801可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器801也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器801可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器801还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器802可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器802还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器802中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器801所执行以实现本申请中方法实施例提供的应用程序的版本发布方法。

在一些实施例中，终端800还可选包括有：外围设备接口803和至少一个外围设备。处理器801、存储器802和外围设备接口803之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口803相连。具体地，外围设备包括：射频电路804、显示屏805、音频电路806、定位组件807和电源808中的至少一种。

外围设备接口803可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器801和存储器802。在一些实施例中，处理器801、存储器802和外围设备接口803被集成在同一芯片或电路板上；在一些其他实施例中，处理器801、存储器802和外围设备接口803中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路804用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路804通过电磁信号与通信网络以及其他通信设备进行通信。射频电路804将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路804包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路804可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路804还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏805用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏805是触摸显示屏时，显示屏805还具有采集在显示屏805的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器801进行处理。此时，显示屏805还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏805可以为一个，设置终端800的前面板；在另一些实施例中，显示屏805可以为至少一个，分别设置在终端800的不同表面或呈折叠设计；在一些实施例中，显示屏805可以是柔性显示屏，设置在终端800的弯曲表面上或折叠面上。甚至，显示屏805还可以设置成非矩形的不规则图形，也即异形屏。显示屏805可以采用LCD(LiquidCrystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

音频电路806可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器801进行处理，或者输入至射频电路804以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端800的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器801或射频电路804的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路806还可以包括耳机插孔。

定位组件807用于定位终端800的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件807可以是基于美国的GPS(GlobalPositioning System，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源808用于为终端800中的各个组件进行供电。电源808可以是交流电、直流电、一次性电池或可充电电池。当电源808包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

本领域技术人员可以理解，图28中示出的结构并不构成对终端800的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图29示出了本申请一个实施例提供的服务器的结构示意图。该服务器用于实施上述实施例中提供的应用程序的版本发布方法。具体来讲：

所述服务器900包括中央处理单元(CPU)901、包括随机存取存储器(RAM)902和只读存储器(ROM)903的系统存储器904，以及连接系统存储器904和中央处理单元901的系统总线905。所述服务器900还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统)906，和用于存储操作系统913、应用程序914和其他程序模块915的大容量存储设备907。

所述基本输入/输出系统906包括有用于显示信息的显示器908和用于用户输入信息的诸如鼠标、键盘之类的输入设备909。其中所述显示器908和输入设备909都通过连接到系统总线905的输入输出控制器910连接到中央处理单元901。所述基本输入/输出系统906还可以包括输入输出控制器910以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器910还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备907通过连接到系统总线905的大容量存储控制器(未示出)连接到中央处理单元901。所述大容量存储设备907及其相关联的计算机可读介质为服务器900提供非易失性存储。也就是说，所述大容量存储设备907可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

不失一般性，所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器904和大容量存储设备907可以统称为存储器。

根据本申请的各种实施例，所述服务器900还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器900可以通过连接在所述系统总线905上的网络接口单元911连接到网络912，或者说，也可以使用网络接口单元911来连接到其他类型的网络或远程计算机系统(未示出)。

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

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种应用程序的版本发布方法，其特征在于，所述方法包括：

接收终端发送的源包构建请求，所述源包构建请求中包括所述应用程序的发布信息，所述发布信息中包括发布渠道号；

根据所述源包构建请求调用源包构建程序的应用程序编程接口API，通过所述源包构建程序将所述应用程序的程序代码构建成为所述应用程序的源包；

接收所述终端发送的版本发布请求；

根据所述版本发布请求将所述源包分别构建成为所述发布渠道号对应的渠道包；

向渠道包分发服务器发送分发请求，所述分发请求中包括所述渠道包，所述分发请求用于请求所述渠道包分发服务器将所述渠道包分发至所述发布渠道号对应的发布渠道。

2.根据权利要求1所述的方法，其特征在于，所述根据所述版本发布请求将所述源包分别构建成为所述发布渠道号对应的渠道包，包括：

根据所述版本发布请求创建渠道包构建任务，并将所述渠道包构建任务添加至任务队列；

执行所述任务队列中的所述渠道包构建任务，将所述发布渠道号分别写入所述源包，生成对应的所述渠道包。

3.根据权利要求2所述的方法，其特征在于，所述将所述发布渠道号分别写入所述源包，生成对应的所述渠道包，包括：

采用签名算法将第i个发布渠道号写入所述源包，生成第i个发布渠道号对应的第i个渠道包，i为正整数。

4.根据权利要求1所述的方法，其特征在于，所述根据所述源包构建请求调用源包构建程序的应用程序编程接口API，通过所述源包构建程序将所述应用程序的程序代码构建成为所述应用程序的源包，包括：

根据所述源包构建请求调用所述API，通过所述源包构建程序对所述源包进行异步构建；

执行构建状态监控脚本轮询检测所述源包的构建状态；

当所述源包的所述构建状态为构建完毕时，从源包构建服务器中获取所述源包。

5.根据权利要求4所述的方法，其特征在于，所述发布信息中包括所述应用程序的任务标识、所述程序代码的版本标识以及源包构建代码的版本号；

所述从源包构建服务器中获取所述源包之前，还包括：

获取所述源包的名称中的关键字，将所述关键字与所述应用程序的任务标识、所述程序代码的版本标识以及所述源包构建代码的版本号进行匹配；

当所述关键字与所述应用程序的任务标识、所述程序代码的版本标识以及所述源包构建代码的版本号匹配时，执行步骤从所述源包构建服务器中获取所述源包。

6.根据权利要求1至5任一所述的方法，其特征在于，所述向渠道包分发服务器发送分发请求之后，包括：

执行分发状态监控脚本轮询所述渠道包的分发状态；

当所述渠道包的所述分发状态为分发完毕时，清除本端服务器中存储的所述渠道包。

7.根据权利要求1至5任一所述的方法，其特征在于，所述接收终端发送的源包构建请求之前，还包括：

清除存储的所述发布渠道号中不符合预设条件的发布渠道号。

8.根据权利要求7所述的方法，其特征在于，所述预设条件包括以下至少一项：

所述发布渠道号的数量小于或者等于第一数量阈值；

所述发布渠道号属于白名单，所述白名单中包括长期有效的发布渠道号，所述长期有效的发布渠道号被设置为不被自动删除；

在第一预设时间段内，所述发布渠道号的新增用户大于第二数量阈值；

所述发布渠道号为第二预设时间段内的新增发布渠道号。

9.一种应用程序的版本发布装置，其特征在于，所述装置包括：

接收模块，用于接收终端发送的源包构建请求，所述源包构建请求中包括所述应用程序的发布信息，所述发布信息中包括发布渠道号；

第一构建模块，用于根据所述源包构建请求调用源包构建程序的应用程序编程接口API，通过所述源包构建程序将所述应用程序的程序代码构建成为所述应用程序的源包；

发送模块，用于接收所述终端发送的版本发布请求；

第二构建模块，用于根据所述版本发布请求将所述源包分别构建成为所述发布渠道号对应的渠道包；

所述发送模块，用于向渠道包分发服务器发送分发请求，所述分发请求中包括所述渠道包，所述分发请求用于请求所述渠道包分发服务器将所述渠道包分发至所述发布渠道号对应的发布渠道。

10.一种服务器，所述服务器包括：

存储器；

与所述存储器相连的处理器；

其中，所述处理器被配置为加载并执行可执行指令以实现如权利要求1至8任一所述的应用程序的版本发布方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集；所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至8任一所述的应用程序的版本发布方法。