CN109960521A - 应用程序升级方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明的实施例公开了一种应用程序升级方法、装置、电子设备及存储介质，涉及应用程序技术领域，用于提高App升级的管理方便性和发布效率。所述应用程序升级方法包括：向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号；接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到；根据所述请求响应信息，对当前App进行升级。

Description

应用程序升级方法、装置、电子设备及存储介质

技术领域

本发明涉及应用程序技术领域，尤其涉及一种应用程序升级方法、装置、电子设备及存储介质。

背景技术

随着移动设备的风靡和发展，谷歌的Android***在现今移动端设备***中的市占已达85.9％(数据来自外媒Gartner于2018年初公布的2017年整年的移动端数据)，在中国的市占也在70％左右(无权威数据支撑，数据收集于各大移动端统计平台)。

Android平台发展状况如此火爆的原因之一就是有大量的Android开发者开发出了多种多样、功能各异的移动应用程序(Application，简称App)，这些App覆盖了移动场景涉及到的方方面面的用户场景。一款Android App，它实际就是一个产品在Android平台上的呈现。而对任意一个运营中的产品来说，都会随着运营发展而产生改变，或者称之为产品迭代更新，这个改变可能是增加新的功能、优化现有流程或是修复产品问题。一旦产品发生迭代更新，那么App也需要随之进行改变，对Android开发者而言就是修改代码，生成新版本的安装包，以供用户安装使用。

然而，实际产品迭代更新不可能这么简单。第一个问题，如何让用户知道一款产品发生了迭代(App存在新版本)；第二，在用户知道有新版本的情况下，如何让用户选择使用新版本的产品，而不是继续使用旧版本的产品；第三，如果用户选择使用新版本的产品，那用户需要如何获取新版本的产品。这三个问题对应到App上，就是如何通知已安装过App的用户有新版本的App可以使用、如何让用户选择使用新版本的App、如何让用户获取到新版本的安装包。

发明人在研究过程中发现，对于App的升级和管理，现有技术中通常采用两种方式：一是通过第三方应用市场，诸如应用宝、91手机助手、小米应用市场等，二是通过App开发者自有服务器。第一种方式需要额外安装第三方应用市场软件，并且当发布App时，要受限于第三方应用市场的审核，对产品的发布效率会有较大影响；第二种方式无需额外安装第三方应用市场软件，而是通过App自身连接访问App开发者自有服务器的预设固定端口来获取App新版本信息，然而App开发者通常会有多款App，对于每一款App，每次更新升级信息均需配置到对应服务器的对应预设固定端口上才能进行新版本的发布，容易出错且效率低。

发明内容

有鉴于此，本发明实施例提供一种管理方便，发布效率高的应用程序升级方法、装置、电子设备及存储介质。

第一方面，本发明实施例提供一种应用程序升级方法，包括：

向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号；

接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到；

根据所述请求响应信息，对当前App进行升级。

结合第一方面，在第一方面的一种实施方式中，所述根据所述请求响应信息，对当前App进行升级包括：

弹出升级确认弹框，所述升级确认弹框上仅设置有升级按钮，以使用户只能选择升级后再使用当前App。

结合第一方面，在第一方面的另一种实施方式中，所述根据所述请求响应信息，对当前App进行升级包括：

用户触发所述升级按钮后，弹出下载弹框，所述下载弹框上设置有下载进度条且不设置关闭按钮；

和/或，用户触发所述升级按钮后，在***的消息栏中展示下载进度条以显示当前App最新版本的下载进度。

结合第一方面，在第一方面的再一种实施方式中，所述根据所述请求响应信息，对当前App进行升级包括：

当前App最新版本下载完成后，弹出安装弹框，所述安装弹框上不设置关闭按钮。

结合第一方面，在第一方面的又一种实施方式中，所述向App开发者自有服务器发送升级信息获取请求之前包括：

获取当前移动终端上安装的其他App的标识号；

其中，所述升级信息获取请求包括当前App的标识号和所述其他App的标识号。

结合第一方面，在第一方面的又一种实施方式中，所述请求响应信息包括App上架的第三方应用市场；

所述弹出升级确认弹框之前包括：

对于每个App，根据所述请求响应信息，确定该App上架的且在当前移动终端上已安装的第三方应用市场；

其中，所述升级确认弹框上还设置有第三方应用市场下载升级按钮，以供用户选择从所确定出的第三方应用市场下载和升级相应App。

第二方面，本发明实施例提供一种应用程序升级装置，包括：

发送模块，用于向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号；

接收模块，用于接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到；

升级模块，用于根据所述请求响应信息，对当前App进行升级。

结合第二方面，在第二方面的一种实施方式中，所述升级模块包括：

第一弹出模块，用于弹出升级确认弹框，所述升级确认弹框上仅设置有升级按钮，以使用户只能选择升级后再使用当前App。

结合第二方面，在第二方面的另一种实施方式中，所述升级模块包括：

第二弹出模块，用于用户触发所述升级按钮后，弹出下载弹框，所述下载弹框上设置有下载进度条且不设置关闭按钮；和/或，用户触发所述升级按钮后，在***的消息栏中展示下载进度条以显示当前App最新版本的下载进度。

结合第二方面，在第二方面的再一种实施方式中，所述升级模块包括：

第三弹出模块，用于当前App最新版本下载完成后，弹出安装弹框，所述安装弹框上不设置关闭按钮。

结合第二方面，在第二方面的又一种实施方式中，所述应用程序升级装置还包括：

获取模块，用于获取当前移动终端上安装的其他App的标识号；

其中，所述升级信息获取请求包括当前App的标识号和所述其他App的标识号。

结合第二方面，在第二方面的又一种实施方式中，所述请求响应信息包括App上架的第三方应用市场；

所述应用程序升级装置还包括：

确定模块，用于对于每个App，根据所述请求响应信息，确定该App上架的且在当前移动终端上已安装的第三方应用市场；

其中，所述升级确认弹框上还设置有第三方应用市场下载升级按钮，以供用户选择从所确定出的第三方应用市场下载和升级相应App。

第三方面，本发明实施例提供一种电子设备，所述电子设备包括：壳体、处理器、存储器、电路板和电源电路，其中，电路板安置在壳体围成的空间内部，处理器和存储器设置在电路板上；电源电路，用于为上述电子设备的各个电路或器件供电；存储器用于存储可执行程序代码；处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一所述的方法。

第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现前述任一所述的方法。

本发明实施例提供的应用程序升级方法、装置、电子设备及存储介质，首先向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号，然后接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到，最后根据所述请求响应信息，对当前App进行升级。这样，本申请的方案中，可将App的升级信息直接配置在升级平台(即App开发者自有服务器)上，在表中记录App与其对应的最新版本信息和下载链接，App直接访问升级平台预设的同一对外端口，无需区分哪台服务器和哪个预设固定端口，升级平台可通过当前App的标识号查表找到当前App的最新版本信息和下载链接，以供App端(即移动终端)的升级组件获取使用。本发明实施例无需在移动终端额外安装第三方应用市场软件，无需受限于第三方应用市场的审核，对App升级管理方便，发布效率高。

附图说明

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

图1为本发明的应用程序升级方法实施例的流程图；

图2为图1所示应用程序升级方法中升级确认弹框的示意图，其中(a)为非强制升级确认弹框的示意图，(b)为强制升级确认弹框的示意图；

图3为图1所示应用程序升级方法中下载弹框的示意图，其中(a)为非强制升级的下载弹框的示意图，(b)为强制升级的下载弹框的示意图，(c)为***消息栏中下载进度条的示意图；

图4为图1所示应用程序升级方法中安装弹框的示意图，其中(a)为非强制升级的安装弹框的示意图，(b)为强制升级的安装弹框的示意图，(c)为后台下载的安装提示条的示意图；

图5为图1所示应用程序升级方法中下载失败时重新下载弹框的示意图，其中(a)为重新下载弹框的示意图，(b)为***消息栏中下载失败消息通知的示意图；

图6为图1所示应用程序升级方法中聚合其他App升级的界面示意图；

图7为图1所示应用程序升级方法中聚合其他下载途径升级的界面示意图，其中(a)为非强制升级情况下聚合其他下载途径升级的界面图，(b)为强制升级情况下聚合其他下载途径升级的界面图；

图8为本发明的应用程序升级装置实施例的结构图；

图9为本发明的电子设备一个实施例的结构示意图。

具体实施方式

下面结合附图对本发明实施例进行详细描述。

应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

一方面，本发明实施例提供一种应用程序升级方法，在移动终端侧执行，如图1所示，本实施例的方法可以包括：

步骤101：向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号；

本步骤中，服务器侧不采用第三方应用市场，而是采用App开发者自有服务器(既可以是App开发者购买、自己维护的服务器，也可以是App开发者租用、由他人维护的服务器等)；移动终端侧，无需额外安装类似第三方应用市场的独立软件，而是由当前App与服务器侧直接进行通信，即由当前App向App开发者自有服务器发送升级信息获取请求。

对于背景技术提及的第一个问题“如何通知已安装过App的用户有新版本的App可以使用”，本申请采用主动查询方式(向服务器侧查询是否有App新版本)来解决，相对于推送方式(服务器侧主动下发App新版本信息，存在推送到达率较低的问题)，该主动查询方式稳定性较好，能够较为准确、及时的获知App是否有新版本。并且，可以设置为App启动后自动查询、预设固定时间点查询、间隔预设时段查询等，以适应用户的不同需求。

本申请的方案在具体实施时，移动终端侧可以对应Android App升级开发组件(以下简称升级组件)，服务器侧对应为升级平台，简单描述本申请的方案就是，开发者通过接入并配置本方案提供的升级组件，再在升级平台上进行配置，升级组件就能够从升级平台获取到当前App最新版本相关的信息，从而实现App的升级功能。

进一步的，可以在App中嵌入升级组件，升级组件是本套方案提供给Android开发者的一个便捷的实现升级能力的一套软件开发工具包SDK(简言之，可以视为在App中嵌入一段具有升级组件功能的代码)。升级组件包含了若干能力，首先是网络能力，该能力用于向升级平台(即App开发者自有服务器)发送网络请求，获取到版本信息数据，以及下载安装包；其次还有文件管理能力，用于安装安装包、删除旧版本的安装包等；最后还有UI(UserInterface，用户界面)功能，用于向用户展示新版本内容等。

步骤102：接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到；

本步骤中，当前App接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，该当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号(具体可以采用Application ID或是其他自行约定的具有唯一性的标识号)查表得到。

发明人在研究过程中发现，现有技术中对于通过App开发者自有服务器进行App升级和管理的方式，通常是通过App连接访问App开发者自有服务器的预设固定端口来获取App新版本信息，然而App开发者通常会有多款App，例如，如果App开发者有两款App分别为AApp和B App，一种升级管理方式是，将A App的升级信息配置在一台服务器a的一个端口，将B App的升级信息配置在另一台服务器b的一个端口，这样，对于每一款App，每次更新升级信息均需配置到对应服务器的对应预设固定端口上才能进行新版本的发布；另一种升级管理方式是，将A App的升级信息配置在一台服务器a的一个端口，将B App的升级信息配置在同一台服务器a的另一个端口，这样，对于每一款App，每次更新升级信息均需配置到同一台服务器的对应预设固定端口上才能进行新版本的发布，因此，无论采用这两种升级管理方式中哪一种，都存在容易出错且效率低的问题。

本申请的方案中，升级信息获取请求包括当前App的标识号，该标识号是AndroidApp的唯一标示，每个App的标识号均不一致，因此可保证唯一性。升级平台(即App开发者自有服务器)预先存储有App的标识号与该App的最新版本信息和下载链接的对应关系表，升级平台接收到升级组件发送的升级信息获取请求后，可以查表得到当前App的最新版本信息和下载链接，并向升级组件返回包含当前App的最新版本信息和下载链接的请求响应信息。

这样，本申请的方案中，可将所有App的升级信息直接配置在升级平台(即App开发者自有服务器)上，在表中记录App与其对应的最新版本信息和下载链接，App直接访问升级平台预设的同一对外端口，无需区分哪台服务器和哪个预设固定端口，升级平台可通过当前App的标识号查表找到当前App的最新版本信息和下载链接，以供App端(即移动终端)的升级组件获取使用。

步骤103：根据所述请求响应信息，对当前App进行升级。

本步骤中，当前App接收到了请求响应信息，由于请求响应信息包括当前App的最新版本信息和下载链接，故可根据该请求响应信息对当前App进行升级。具体的，升级组件可以比较App当前版本和升级平台返回的新版本信息的版本号，若二者一致，则认为当前版本就是最新版本，若新版本信息的版本号更高，则可以进入升级流程(参见后续描述)。

对于背景技术提及的第二个问题“如何让用户选择使用新版本的App”，与网站不同，对于App来说，升级是需要用户进行同意的，那么，要做的就是引导用户下载使用新版本。为解决这个问题，本申请通过优化升级和下载体验来解决。具体的升级体验优化策略将在后面详细说明。

对于背景技术提及的第三个问题“如何让用户获取到新版本的安装包”，苹果iOS***，提供了官方的应用市场App Store，用户能且仅能通过App Store进行下载和更新。然而Android平台并没有一个官方平台，诸如应用宝、小米应用市场等均为第三方应用市场，诚然可以将产品发布到第三方应用市场，让用户通过第三方应用市场进行更新下载。但这种方式一是依赖用户已经下载过第三方应用市场，二是在第三方应用市场发布App时，要受限于平台的审核，这对于产品的发布效率会有较大影响。因此为避免受制于第三方应用市场，这就需要App拥有下载安装包并升级的能力。本申请的方案通过升级平台(App开发者自有服务器)来解决这个问题。在发布产品时，将安装包上传至升级平台，升级平台提供了存储安装包的能力，这样在App从升级平台获取新版本信息时，升级平台就会将安装包下载链接和新版本信息一并发送给App，这样App就能够直接下载新版本的安装包，并升级。

作为一种可选的实施例，所述根据所述请求响应信息，对当前App进行升级(步骤103)可以包括：

步骤1031：弹出升级确认弹框，所述升级确认弹框上仅设置有升级按钮，以使用户只能选择升级后再使用当前App。

在这里提出一个关键点，App升级策略：强制/非强制升级，这是升级流程体验优化的一个核心点。简单来说，强制升级就是要求用户必须升级后才能继续使用App，而非强制升级就是用户可以选择升级或不升级，无论升级与否，用户都可以正常使用App。之所以提出这两种策略，是因为对于一般情况，新版本是会兼容旧版本的功能的，也就是，新版本是包含了旧版本全部功能，在此基础上，新版本会增加若干功能，或是界面样式等进行了优化，但都不会影响原有功能的使用。对于这种情况，用户可以自主选择升级或不升级，这种场景对应了非强制升级。但是对于某些情况，例如旧版本存在某些问题，或者旧版本某些功能在产品策略上被废弃，那么如果不升级到新版本，就会影响用户的正常使用，对于这种情况，就需要采取强制升级策略。这两种策略可以应对所有的产品迭代，且在实际应用中，用户反馈的体验较好。图2(a)为非强制升级确认弹框，图2(b)为强制升级确认弹框。

首先讲一下非强制升级，这是最常见的升级方式。非强制升级的核心是做到尽可能少的影响用户正常使用的前提下，提供下载升级的能力。这一流程对于用户体验的要求较高。而强制升级的思路与之正好相反，因为强制升级所应对的场景的要求，用户必须升级到新版本才能使用App的功能，因此需要在升级的各个流程中，阻止用户使用当前旧版本的App。从图2中可以看出，图2(a)非强制升级用户有自主选择升级与否的权利，如果选择暂不升级，那弹框就会关闭，用户就能正常使用App。升级确认弹框的作用不仅仅是让用户选择是否升级，其次还可以兼备新版本功能的描述，通过描述可以让用户了解到新版本所包含的功能，从而引导用户下载安装新版本。而强制升级，用户只能选择升级，没有其他选择，这也符合强制升级的思路。

作为另一种可选的实施例，所述根据所述请求响应信息，对当前App进行升级(步骤103)还可以包括：

步骤1032：用户触发所述升级按钮后，弹出下载弹框，所述下载弹框上设置有下载进度条且不设置关闭按钮；和/或，用户触发所述升级按钮后，在***的消息栏中展示下载进度条以显示当前App最新版本的下载进度。

用户只要选择了图2中的立即升级，App就会展示图3所示的下载弹框界面，图3(a)为非强制升级的下载弹框，图3(b)为强制升级的下载弹框。从图中可以看出，相比于升级确认弹框，下载弹框展示了一个下载进度条，用于向用户展示当前安装包下载的进度，强制升级的下载弹框是没有关闭按钮的，因此用户只能停留在当前下载页面，无法使用App的功能。而非强制升级的下载弹框上多了一个后台下载按钮，用户点击后台下载后，下载弹框就会关闭，同时App会在后台继续之前的下载任务，直到下载完成。图3(c)是用户点击后台下载后，App会在***的消息栏中展示一个下载进度条，作用与下载弹框上的进度条一样，用户可以在使用App的同时，通过消息栏查看下载进度，这也是体验优化点之一。当然图3(c)也可以是用户在图2(b)中触发升级按钮后与图3(b)的下载弹框同时出现的。

作为再一种可选的实施例，所述根据所述请求响应信息，对当前App进行升级(步骤103)还可以包括：

步骤1033：当前App最新版本下载完成后，弹出安装弹框，所述安装弹框上不设置关闭按钮。

App最新版本下载完成之后，升级组件会自动打开安装包，跳转***安装界面。使用过Android移动终端的用户都清楚，Android***安装界面是可以取消的，因此即使用户完成了前面几步，在这也是可以中断升级操作的，一旦操作中断，那本次安装就已经结束了。对于这种情况，本申请中的升级组件也能够处理。

图4是升级组件的安装弹框，这个弹框就是用于处理上面提出的场景。下载完成后，在跳转***安装界面的同时，会弹出上述的安装弹框。一旦用户中断安装操作，可以通过安装弹框再次进入安装界面。其中，图4(a)为非强制升级的安装弹框，图4(b)为强制升级的安装弹框，图4(c)为后台下载的安装提示条。这就保证了任意的下载流程，用户都能够重新进行安装操作。同时，对于强制升级，安装弹框是不能关闭的，这也能够保证在安装时，用户也无法使用App的功能。而非强制升级，用户也可以选择在此关闭安装弹框，继续使用App的功能。

此外，还有一种情况，如果用户在下载完成后，通过***的任务管理器将App杀掉，则在下一次进入App时，升级组件会使用上一次下载完成的安装包，直接弹出安装弹框，避免重复下载。

对于某些场景，可能在下载安装包时出现下载失败的情况，本方案对其也进行了处理，如图5所示，点击重新下载按钮或后台下载时点击***的消息栏中消息通知均可重新下载。

在上述所有步骤执行完后，也就意味着安装完成了，这时打开新版本的App，升级组件会自动将安装包删除，释放存储空间。至此，App端的升级组件的工作流程就结束了。

作为又一种可选的实施例，所述向App开发者自有服务器发送升级信息获取请求(步骤101)之前可以包括：

步骤100：获取当前移动终端上安装的其他App的标识号；

此时，所述向App开发者自有服务器发送升级信息获取请求(步骤101)中，所述升级信息获取请求包括当前App的标识号和所述其他App的标识号。

这样，在请求升级信息的时候，将其他App的标识号一起上传给升级平台，升级平台就可以根据这些信息检索出在升级平台配置过的其他App的新版本的信息，一并通知给App。这样App就可以使用这些新版本信息向用户进行提示，以实现“聚合其他App升级”。具体实施时，可以用代码注册Android***PackageManager服务，通过该服务即可获取到当前移动终端上安装的其他App的部分信息，这些信息里就包含了每个App各自的标识号(Application ID)和版本号。

“聚合其他App升级”，其功能是检测当前移动终端上接入了本方案所提到的App升级组件的App，在当前App检测升级的同时，会同时检测其他App是否有新版本可用。如有，则弹出通知消息，提醒用户前往下载。如图6所示，当前App的升级组件检测到了移动终端上有若干接入了升级组件的App，其中“丰物集”和“同城急送”两个App有了新版本。该功能的意义也是在于解决最开始提到的问题一，也就是让用户知道App有了新版本。该功能也是本方案的核心点之一，该功能使得接入了本方案的App在升级这一功能上成为了一个整体，任意一个App均能对用户进行新版本的提醒。该功能使得当前移动终端上接入了本方案的App越多，则用户获取到新版本提醒的概率越大，从而大大提升了用户收到新版本提醒的可能性。

作为又一种可选的实施例，所述接收App开发者自有服务器返回的请求响应信息(步骤102)中，请求响应信息包括App上架的第三方应用市场；

所述弹出升级确认弹框(步骤1031)之前包括：

对于每个App，根据所述请求响应信息，确定该App上架的且在当前移动终端上已安装的第三方应用市场；

此时，所述升级确认弹框上还设置有第三方应用市场下载升级按钮，以供用户选择从所确定出的第三方应用市场下载和升级相应App。

在Android移动终端中，一般App是没有安装Android安装包的权限的，需要用户手动打开，但是***默认赋予了第三方应用市场以安装安装包的权限，因此面对这种情况，本方案提供了跳转应用市场下载的能力。在升级平台上对App记录可以选填该App所上架过的第三方应用市场，一旦用户不希望授予App以安装的权限，用户可以选择跳转第三方应用市场进行下载，如图7所示。该功能应对了上述的问题三，对于不同的场景，本方案提供了多种多样的下载途径，保证了绝大多数情况，用户都能获取到新版本的安装包，进一步提升了升级的成功率。

本发明实施例提供的应用程序升级方法，首先向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号，然后接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到，最后根据所述请求响应信息，对当前App进行升级。这样，本申请的方案中，可将App的升级信息直接配置在升级平台(即App开发者自有服务器)上，在表中记录App与其对应的最新版本信息和下载链接，App直接访问升级平台预设的同一对外端口，无需区分哪台服务器和哪个预设固定端口，升级平台可通过当前App的标识号查表找到当前App的最新版本信息和下载链接，以供App端(即移动终端)的升级组件获取使用。本发明实施例无需在移动终端额外安装第三方应用市场软件，无需受限于第三方应用市场的审核，对App升级管理方便，发布效率高。

另一方面，本发明实施例提供一种应用程序升级装置，如图8所示，该装置可以包括：

发送模块11，用于向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号；

接收模块12，用于接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到；

升级模块13，用于根据所述请求响应信息，对当前App进行升级。

本实施例的装置，可以用于执行图1所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

优选的，所述升级模块13可以包括：

第一弹出模块，用于弹出升级确认弹框，所述升级确认弹框上仅设置有升级按钮，以使用户只能选择升级后再使用当前App。

优选的，所述升级模块13还可以包括：

第二弹出模块，用于用户触发所述升级按钮后，弹出下载弹框，所述下载弹框上设置有下载进度条且不设置关闭按钮；和/或，用户触发所述升级按钮后，在***的消息栏中展示下载进度条以显示当前App最新版本的下载进度。

优选的，所述升级模块13还可以包括：

第三弹出模块，用于当前App最新版本下载完成后，弹出安装弹框，所述安装弹框上不设置关闭按钮。

进一步的，为实现聚合其他App升级，所述应用程序升级装置还可以包括：

获取模块，用于获取当前移动终端上安装的其他App的标识号；

其中，所述升级信息获取请求包括当前App的标识号和所述其他App的标识号。

进一步的，为实现聚合其他下载途径升级，所述请求响应信息包括App上架的第三方应用市场；

所述应用程序升级装置还包括：

确定模块，用于对于每个App，根据所述请求响应信息，确定该App上架的且在当前移动终端上已安装的第三方应用市场；

其中，所述升级确认弹框上还设置有第三方应用市场下载升级按钮，以供用户选择从所确定出的第三方应用市场下载和升级相应App。

本发明实施例还提供一种电子设备，图9为本发明的电子设备一个实施例的结构示意图，可以实现本发明图1所示实施例的流程，如图9所示，上述电子设备可以包括：壳体41、处理器42、存储器43、电路板44和电源电路45，其中，电路板44安置在壳体41围成的空间内部，处理器42和存储器43设置在电路板44上；电源电路45，用于为上述电子设备的各个电路或器件供电；存储器43用于存储可执行程序代码；处理器42通过读取存储器43中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一方法实施例所述的方法。

处理器42对上述步骤的具体执行过程以及处理器42通过运行可执行程序代码来进一步执行的步骤，可以参见本发明图1所示实施例的描述，在此不再赘述。

该电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、***总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子设备。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一方法实施例所述的方法步骤。

本发明的实施例还提供一种应用程序，所述应用程序被执行以实现本发明任一方法实施例提供的方法。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。为了描述的方便，描述以上装置是以功能分为各种单元/模块分别描述。当然，在实施本发明时可以把各单元/模块的功能在同一个或多个软件和/或硬件中实现。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种应用程序升级方法，其特征在于，包括：

向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号；

接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到；

根据所述请求响应信息，对当前App进行升级。

2.根据权利要求1所述的应用程序升级方法，其特征在于，所述根据所述请求响应信息，对当前App进行升级包括：

弹出升级确认弹框，所述升级确认弹框上仅设置有升级按钮，以使用户只能选择升级后再使用当前App。

3.根据权利要求2所述的应用程序升级方法，其特征在于，所述根据所述请求响应信息，对当前App进行升级包括：

用户触发所述升级按钮后，弹出下载弹框，所述下载弹框上设置有下载进度条且不设置关闭按钮；

和/或，用户触发所述升级按钮后，在***的消息栏中展示下载进度条以显示当前App最新版本的下载进度。

4.根据权利要求3所述的应用程序升级方法，其特征在于，所述根据所述请求响应信息，对当前App进行升级包括：

当前App最新版本下载完成后，弹出安装弹框，所述安装弹框上不设置关闭按钮。

5.根据权利要求1-4中任一所述的应用程序升级方法，其特征在于，所述向App开发者自有服务器发送升级信息获取请求之前包括：

获取当前移动终端上安装的其他App的标识号；

其中，所述升级信息获取请求包括当前App的标识号和所述其他App的标识号。

6.根据权利要求5所述的应用程序升级方法，其特征在于，所述请求响应信息包括App上架的第三方应用市场；

所述弹出升级确认弹框之前包括：

对于每个App，根据所述请求响应信息，确定该App上架的且在当前移动终端上已安装的第三方应用市场；

其中，所述升级确认弹框上还设置有第三方应用市场下载升级按钮，以供用户选择从所确定出的第三方应用市场下载和升级相应App。

7.一种应用程序升级装置，其特征在于，包括：

发送模块，用于向App开发者自有服务器发送升级信息获取请求，所述升级信息获取请求包括当前App的标识号；

接收模块，用于接收App开发者自有服务器返回的请求响应信息，所述请求响应信息包括当前App的最新版本信息和下载链接，当前App的最新版本信息和下载链接由App开发者自有服务器根据当前App的标识号查表得到；

升级模块，用于根据所述请求响应信息，对当前App进行升级。

8.根据权利要求7所述的应用程序升级装置，其特征在于，所述升级模块包括：

第一弹出模块，用于弹出升级确认弹框，所述升级确认弹框上仅设置有升级按钮，以使用户只能选择升级后再使用当前App。

9.根据权利要求8所述的应用程序升级装置，其特征在于，所述升级模块包括：

第二弹出模块，用于用户触发所述升级按钮后，弹出下载弹框，所述下载弹框上设置有下载进度条且不设置关闭按钮；和/或，用户触发所述升级按钮后，在***的消息栏中展示下载进度条以显示当前App最新版本的下载进度。

10.根据权利要求9所述的应用程序升级装置，其特征在于，所述升级模块包括：

第三弹出模块，用于当前App最新版本下载完成后，弹出安装弹框，所述安装弹框上不设置关闭按钮。