应用程序更新方法、装置及设备与流程
未命名
08-05
阅读:120
评论:0
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.接收所述服务器通过所述服务器中的应用程序编程接口api网关发送的第一响应消息,所述第一响应消息包括所述第一消息,所述第一响应消息为所述服务器对所述终端设备的任意消息进行响应的消息。
28.在一种可能的实施方式中,所述方法还包括:
29.确定轮询周期;
30.按照所述轮询周期,向所述服务器发送轮询请求,所述轮询请求中包括所述第一应用程序的标识和所述第一应用程序的当前版本号;
31.若所述服务器的所述第一应用程序的最新版本号大于所述当前版本号,则接收所述服务器发送的所述更新文件;
32.根据所述更新文件对所述第一应用程序进行更新。
33.第二方面,本技术实施例提供一种应用程序更新方法,应用于服务器,所述方法包括:
34.在确定第一应用程序的版本发生更新后,向终端设备发送第一消息,所述第一消息包括所述第一应用程序的最新版本号;
35.接收所述终端设备根据所述第一消息发送的请求消息;
36.根据所述请求消息,向所述终端设备发送所述第一应用程序的更新文件。
37.在一种可能的实施方式中,向终端设备发送第一消息,包括:
38.通过所述终端设备和所述服务器之间的通道,向所述终端设备发送所述第一消息。
39.在一种可能的实施方式中,通过所述终端设备和所述服务器之间的通道,向所述终端设备发送所述第一消息,包括:
40.获取所述终端设备的设备状态,所述设备状态为在线状态或者离线状态;
41.若所述设备状态为所述在线状态,则通过所述通道向所述终端设备发送所述第一消息,所述第一消息还包括延时信息;
42.若所述设备状态为所述离线状态,则监测终端设备的设备状态,直至所述设备状
态在当前时刻之后的预设时长内切换至在线状态时,通过所述通道向所述终端设备发送所述第一消息。
43.在一种可能的实施方式中,向终端设备发送第一消息,包括:
44.生成所述第一消息;
45.在生成所述第一消息之后的预设时段内,若接收到终端设备发送的第二消息,则生成所述第二消息对应的第一响应消息,所述第一响应消息包括所述第一消息,所述第二消息为所述终端设备向所述服务器发送的任意消息;
46.在等待第一时长后,通过应用程序编程接口api网关向所述终端设备发送所述第一响应消息。
47.在一种可能的实施方式中,根据所述请求消息,向所述终端设备发送所述第一应用程序的更新文件,包括:
48.确定待处理请求量;
49.若所述待处理请求量小于所述预设阈值,向所述终端设备发送所述第一应用程序的更新文件;
50.若所述待处理请求量大于或等于预设阈值,则向所述终端设备发送第二等待时长,并在所述第二等待时长之后接收所述终端设备重发的所述请求消息,直至所述待处理请求量小于所述预设阈值时,向所述终端设备发送所述第一应用程序对应的更新文件。
51.第三方面,本技术实施例提供一种应用程序更新装置,应用于终端设备,所述终端设备中安装有第一应用程序,所述装置包括:接收模块、获取模块和更新模块,其中,
52.所述接收模块用于,接收服务器发送的第一消息,所述第一消息用于指示第一应用程序的版本发生更新,所述第一消息包括所述第一应用程序的最新版本号;
53.所述获取模块用于,若确定未从所述服务器轮询获取到所述第一应用程序对应的更新文件,则根据所述第一消息从所述服务器获取所述更新文件;
54.所述更新模块用于,根据所述更新文件对所述第一应用程序进行更新。
55.在一种可能的实施方式中,所述第一消息中包括延时信息;所述获取模块具体用于:
56.根据所述延时信息,确定第一等待时长;
57.等待所述第一等待时长,并在所述第一等待时长结束之后判断是否从所述服务器轮询获取到所述更新文件;
58.若否,则根据所述第一消息从所述服务器获取所述更新文件。
59.在一种可能的实施方式中,所述获取模块具体用于:
60.所述延时信息包括延时时长,则将所述延时信息中的延时时长确定为所述第一等待时长;或者,
61.所述延时信息中包括延时范围,则根据所述延时范围随机生成所述第一等待时长,所述第一等待时长位于所述延时范围内。
62.在一种可能的实施方式中,所述获取模块具体用于:
63.向所述服务器发送请求消息,所述请求消息包括所述第一应用程序的标识;
64.接收所述服务器发送的响应消息,所述响应消息包括第二等待时长或者所述更新文件;
65.若所述响应消息中包括所述第二等待时长,则根据所述第二等待时长向所述服务器重发所述请求消息,直至接收到的响应消息中包括所述更新文件时,获取得到所述更新文件。
66.在一种可能的实施方式中,所述获取模块具体用于:
67.获取所述第一应用程序的当前版本号;
68.若所述当前版本号和所述最新版本号不同,则确定未从所述服务器轮询获取到所述第一应用程序对应的更新文件。
69.在一种可能的实施方式中,所述接收模块具体用于:
70.通过所述终端设备和所述服务器之间的通道接收所述服务器发送的所述第一消息;或者;
71.接收所述服务器通过所述服务器中的应用程序编程接口api网关发送的第一响应消息,所述第一响应消息包括所述第一消息,所述第一响应消息为所述服务器对所述终端设备的任意消息进行响应的消息。
72.在一种可能的实施方式中,所述装置还包括:确定模块和发送模块,其中,
73.所述确定模块用于,确定轮询周期;
74.所述发送模块用于,按照所述轮询周期,向所述服务器发送轮询请求,所述轮询请求中包括所述第一应用程序的标识和所述第一应用程序的当前版本号;
75.所述接收模块还用于,若所述服务器的所述第一应用程序的最新版本号大于所述当前版本号,则接收所述服务器发送的所述更新文件;
76.所述更新模块用于,根据所述更新文件对所述第一应用程序进行更新。
77.第四方面,本技术实施例提供一种应用程序更新装置,应用于服务器,所述装置还包括:发送模块和接收模块,其中,
78.所述发送模块用于,在确定第一应用程序的版本发生更新后,向终端设备发送第一消息,所述第一消息包括所述第一应用程序的最新版本号;
79.所述接收模块用于,接收所述终端设备根据所述第一消息发送的请求消息;
80.所述发送模块用于,根据所述请求消息,向所述终端设备发送所述第一应用程序的更新文件。
81.在一种可能的实施方式中,所述发送模块具体用于:
82.通过所述终端设备和所述服务器之间的通道,向所述终端设备发送所述第一消息。
83.在一种可能的实施方式中,所述发送模块具体用于:
84.获取所述终端设备的设备状态,所述设备状态为在线状态或者离线状态;
85.若所述设备状态为所述在线状态,则通过所述通道向所述终端设备发送所述第一消息,所述第一消息还包括延时信息;
86.若所述设备状态为所述离线状态,则监测终端设备的设备状态,直至所述设备状态在当前时刻之后的预设时长内切换至在线状态时,通过所述通道向所述终端设备发送所述第一消息。
87.在一种可能的实施方式中,所述发送模块具体用于:
88.生成所述第一消息;
89.在生成所述第一消息之后的预设时段内,若接收到终端设备发送的第二消息,则生成所述第二消息对应的第一响应消息,所述第一响应消息包括所述第一消息,所述第二消息为所述终端设备向所述服务器发送的任意消息;
90.在等待第一时长后,通过应用程序编程接口api网关向所述终端设备发送所述第一响应消息。
91.在一种可能的实施方式中,所述发送模块具体用于:
92.确定待处理请求量;
93.若所述待处理请求量小于所述预设阈值,向所述终端设备发送所述第一应用程序的更新文件;
94.若所述待处理请求量大于或等于预设阈值,则向所述终端设备发送第二等待时长,并在所述第二等待时长之后接收所述终端设备重发的所述请求消息,直至所述待处理请求量小于所述预设阈值时,向所述终端设备发送所述第一应用程序对应的更新文件。
95.第五方面,本技术实施例提供一种终端设备,包括:存储器和处理器;
96.所述存储器存储计算机执行指令;
97.所述处理器执行所述存储器存储的计算机执行指令,使得所述处理器执行第一方面任一项所述的应用程序更新方法。
98.第六方面,本技术实施例提供一种服务器,包括:存储器和处理器;
99.所述存储器存储计算机执行指令;
100.所述处理器执行所述存储器存储的计算机执行指令,使得所述处理器执行第二方面任一项所述的应用程序更新方法。
101.第七方面,本技术实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当所述计算机执行指令被处理器执行时用于实现第一方面任一项所述的应用程序更新方法。
102.第八方面,本技术实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当所述计算机执行指令被处理器执行时用于实现第二方面任一项所述的应用程序更新方法。
103.第九方面,本技术实施例提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现第一方面任一项所示的应用程序更新方法。
104.第十方面,本技术实施例提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现第二方面任一项所示的应用程序更新方法。
105.本技术实施例提供一种应用程序更新方法、装置及设备,服务器在确定第一应用程序的版本发生更新后,可以向终端设备发送第一消息。若终端设备确定未从服务器轮询获取到第一应用程序对应的更新文件,则可以根据第一消息向服务器发送请求消息。服务器可以根据请求消息,向终端设备发送第一应用程序的更新文件。终端设备可以根据更新文件对第一应用程序进行更新。由于可以通过第一消息及时通知终端设备获取第一应用程序对应的更新文件,且终端设备还可以通过轮询的方式,从服务器中轮询获取第一应用程序对应的更新文件。结合了通过第一消息通知终端设备获取更新文件、以及从服务器中轮询获取更新文件这2种方式,相比终端设备只通过轮询的方式从服务器中获取更新文件,提高了对应用程序的更新时效性。
附图说明
106.此处所说明的附图用来提供对本技术的进一步理解,构成本技术的一部分,本技术的示意性实施例及其说明用于解释本技术,并不构成对本技术的不当限定。在附图中:
107.图1为本技术示例性实施例提供的一种场景示意图;
108.图2为本技术示例性实施例提供的一种应用程序更新方法的流程示意图;
109.图3为本技术示例性实施例提供的另一种应用程序更新方法的流程示意图;
110.图4为本技术示例性实施例提供的一种应用程序更新方法的过程示意图;
111.图5为本技术示例性实施例提供的又一种应用程序更新方法的流程示意图;
112.图6为本技术示例性实施例提供的另一种应用程序更新方法的过程示意图;
113.图7为本技术示例性实施例提供的一种应用程序更新装置的结构示意图;
114.图8为本技术示例性实施例提供的另一种应用程序更新装置的结构示意图;
115.图9为本技术示例性实施例提供的一种终端设备的结构示意图;
116.图10为本技术示例性实施例提供的一种服务器的结构示意图。
具体实施方式
117.需要说明的是,本技术所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、使用和处理需要遵守相关法律法规和标准,并提供有相应的操作入口,供用户选择授权或者拒绝。
118.为使本技术的目的、技术方案和优点更加清楚,下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本技术一部分实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本技术保护的范围。
119.图1为本技术示例性实施例提供的一种场景示意图。请参见图1,包括服务器和多个终端设备。该多个终端设备可以分别为终端设备1、终端设备2、
……
、终端设备n(n为大于或等于1的整数)。服务器与任意一个终端设备之间可以进行互相通信。
120.针对任意一个终端设备,终端设备中可以安装有第一应用程序。例如,第一应用程序可以为应用程序(application,app)1。
121.服务器中可以存储有第一应用程序的配置文件。当服务器中第一应用程序的版本发生更新后,服务器可以向终端设备发送第一消息,终端设备接收到第一消息之后,可以从服务器中获取第一应用程序对应的更新文件,通过该更新文件对第一应用程序进行更新。
122.例如,若终端设备中安装的app1为1.0版本,若服务器中第一应用程序的版本更新为2.0版本,则服务器可以向终端设备发送第一消息,第一消息中可以包括版本号2.0。终端设备接收到第一消息之后,可以从服务器中获取app1为2.0版本的更新文件1,并根据该更新文件1对app 1进行更新。
123.终端设备还可以通过轮询的方式,向服务器发送请求消息,以在服务器中获取第一应用程序对应的更新文件。
124.在相关技术中,通常是终端设备通过轮询的方式,发送轮询请求,以从服务器中获取应用程序对应的更新文件。然而,在上述方式中,为了降低服务器的负载,通常设置的轮
询周期较长,使得终端设备无法及时获取更新文件,进而使得应用程序无法尽快恢复。在相关技术中,对应用程序的更新时效性较低。
125.在本技术实施例中,在第一应用程序的版本发生更新后,服务器可以立即向终端设备发送第一消息,终端设备接收到第一消息之后,可以根据第一消息从服务器中获取第一应用程序对应的更新文件。终端设备也可以通过轮询的方式从服务器中获取更新文件。由于可以通过第一消息及时通知终端设备获取第一应用程序对应的更新文件,相比终端设备只通过轮询的方式从服务器中获取更新文件,提高了对应用程序的更新时效性。
126.下面,通过具体实施例对本技术所示的技术方案进行详细说明。需要说明的是,下面几个实施例可以单独存在,也可以相互结合,对于相同或相似的内容,在不同的实施例中不再重复说明。
127.图2为本技术示例性实施例提供的一种应用程序更新方法的流程示意图。请参见图2,所述方法可以包括:
128.s201、服务器在确定第一应用程序的版本发生更新后,向终端设备发送第一消息。
129.服务器中可以存储有第一应用程序。例如,服务器中可以存储有1.0版本的app1。
130.终端设备中可以安装有第一应用程序。例如,终端设备可以为手机,手机中可以安装有1.0版本的app1。
131.第一应用程序可以有多个版本、以及多个版本对应的版本号。例如,当第一应用程序为1.0版本时,版本号可以为1.0。
132.第一消息可以用于指示第一应用程序的版本发生更新。第一消息中可以包括第一应用程序的最新版本号,还可以包括延时信息。
133.可选地,第一消息的结构可以由关键字(key)-值(value)组成。例如,第一消息的结构可以为“{key1}/{value1}{key2}/{value2}
……”
。其中key1对应的值为value1,key2对应的值为value2。
134.例如,第一消息可以为“biz/07ver/2.0de/120”,其含义可以如表1所示:
135.表1
136.keyvalue含义biz07表示第一消息的任务标识biz为07ver2.0表示第一应用程序的最新版本号ver为2.0de120表示延时时长de为120s,可以默认延时范围为0~120s
137.例如,若第一应用程序为app1,服务器在确定第一应用程序的版本由版本1.0更新为版本2.0,则可以向终端设备发送第一消息。第一消息中可以包括app1的最新版本号2.0。第一消息的数据量可以为1千字节(kb)。
138.s202、若终端设备确定未从服务器轮询获取到第一应用程序对应的更新文件,则根据第一消息向服务器发送请求消息。
139.更新文件是指第一应用程序的版本发生更新后的配置文件。例如,若第一应用程序的版本更新为2.0,则更新文件可以为第一应用程序为版本2.0的配置文件。
140.从服务器轮询获取到第一应用程序对应的更新文件,是指终端设备可以通过轮询方式,从服务器中获取到第一应用程序对应的更新文件。
141.在一可选实施例中,终端设备中还可以设置有轮询获取更新文件的方式。
142.在轮询获取更新文件的方式中,终端设备可以确定轮询周期;按照轮询周期,向服务器发送轮询请求,轮询请求中包括第一应用程序的标识和第一应用程序的当前版本号;若服务器的第一应用程序的最新版本号大于当前版本号,则接收服务器发送的更新文件;根据更新文件对第一应用程序进行更新。若服务器的第一应用程序的最新版本号等于当前版本号,则接收服务器发送的反馈信息,反馈信息可以用于指示终端设备中的第一应用程序已是最新版本,无需获取更新文件。
143.轮询周期可以是人为预先设置的。例如,轮询周期可以为2小时(h)。
144.当前版本号是指终端设备中已安装的第一应用程序的版本号。
145.例如,若第一应用程序为app1,对应的标识为001,若终端设备中安装的app1的当前版本号为1.0,若轮询周期为2h,则终端设备可以按照轮询周期,每隔2h向服务器发送轮询请求,以从服务器中轮询获取第一应用程序对应的更新文件。轮询请求中包括第一应用程序的标识001和第一应用程序的当前版本号1.0。
146.若服务器的第一应用程序的最新版本号为1.0,等于当前版本号1.0,则服务器可以向终端设备发送反馈信息,反馈信息可以为“第一应用程序的当前版本已是最新版本”;若服务器的第一应用程序的最新版本号为2.0,大于当前版本号1.0,则服务器可以向终端设备发送更新文件即app1为2.0版本的配置文件,以使终端接收该更新文件,根据该更新文件对app1进行更新。
147.通过轮询获取更新文件的方式,获取更新文件的可靠性较高。
148.若终端设备接收到第一消息之后,还没有通过上述轮询方式从服务器中获取到第一应用程序对应的更新文件,则终端设备可以根据第一消息向服务器发送请求消息。
149.请求消息中可以包括第一应用程序的标识。例如,若第一应用程序为app1,对应的标识为001,则请求消息中可以包括第一应用程序的标识001。
150.可选地,终端设备可以调用接口,向服务器发送请求消息。
151.例如,若第一应用程序为app1,第一消息中可以包括app1的最新版本号2.0,若终端设备还没有通过轮询的方式从服务器中获取到app1对应的更新文件即版本2.0对应的文件,则终端设备可以调用接口,根据第一消息向服务器发送请求消息。若第一应用程序app1对应的标识为001,则请求消息中可以包括第一应用程序的标识001。
152.可选地,终端设备在调用接口,发送请求消息成功之后,可以重置轮询周期。
153.s203、服务器根据请求消息,向终端设备发送第一应用程序的更新文件。
154.在一可选实施例中,可以通过如下方式,根据请求消息向终端设备发送第一应用程序的更新文件:确定待处理请求量;若待处理请求量小于预设阈值,向终端设备发送第一应用程序的更新文件;若待处理请求量大于或等于预设阈值,则向终端设备发送第二等待时长,并在第二等待时长之后接收终端设备重发的请求消息,直至待处理请求量小于预设阈值时,向终端设备发送第一应用程序的更新文件。
155.待处理请求量是指待处理的请求消息的数量。
156.预设阈值可以是人为设定的。例如,预设阈值可以为1000。
157.由于服务器可以接收多个终端设备发送的请求消息,则服务器可能需要同时处理很多个请求消息,存在处理不过来的情况,因此服务器可以确定待处理请求量,根据待处理请求量对请求消息进行处理,即若待处理请求量小于预设阈值,则向终端设备发送第一应
用程序对应的更新文件;若待处理请求量大于或等于预设阈值,则向终端设备发送第二等待时长。
158.终端设备接收到第二等待时长之后,可以第二等待时长之后向服务器重发请求消息。服务器可以接收终端设备重发的请求消息,直至待处理请求量小于预设阈值时,向终端设备发送第一应用程序的更新文件。
159.第二等待时长可以是由服务器随机确定的。例如,第二等待时长可以为100秒(s)。
160.例如,若第一应用程序为app1,若预设阈值为1000,服务器确定待处理请求量为800,则由于待处理请求量800小于预设阈值1000,则服务器可以向终端设备发送app1对应的更新文件;若服务器确定待处理请求量为5000,待处理请求量5000大于或等于预设阈值1000,则服务器可以向终端设备发送第二等待时长。假设第二等待时长为10s,则终端设备接收到第二等待时长10s之后,可以等待10s,向服务器重发请求消息。若此时服务器确定待处理请求为900,小于预设阈值1000,则服务器可以向终端设备发送app1对应的更新文件。
161.需要说明的是,更新文件中可以包括多个配置数据和多个动态规则。在更新文件的版本相同的情况下,服务器可以根据更新文件中的动态规则,进行条件计算和/或灰度计算等,以针对不同的终端设备选择性发送包含较优配置数据的更新文件。
162.例如,若更新文件为app1为版本2.0的配置文件,该更新文件中包括配置数据a、配置数据b、配置数据c和发送规则1。其中,配置数据a、配置数据b、配置数据c可以为同一配置的不同参数值。假设发送规则1为:若终端设备满足条件1,则向该终端设备发送配置数据a;若终端设备满足条件2,则向该终端设备发送配置数据b;若终端设备不满足条件1和条件2,则向该终端设备发送配置数据c。例如,若终端设备1满足条件1,则服务器可以根据发送规则,向终端设备1发送更新文件1,更新文件1中可以包括配置数据a;若终端设备2满足条件2,则服务器可以根据发送规则,向终端设备2发送更新文件2,更新文件2中可以包括配置数据b;若终端设备3不满足条件1和条件2,则服务器可以根据发送规则,向终端设备3发送更新文件3,更新文件3中可以包括配置数据c。更新文件1、更新文件2和更新文件3均为app1为版本2.0的配置文件。
163.s204、终端设备根据更新文件对第一应用程序进行更新。
164.例如,若第一应用程序为app1,终端设备中安装的app1的版本为1.0,更新文件为app1的2.0版本的配置文件,则终端设备可以根据更新文件对app1进行更新,将app1从1.0版本更新为2.0版本。
165.在本技术实施例中,服务器在确定第一应用程序的版本发生更新后,可以向终端设备发送第一消息。若终端设备确定未从服务器轮询获取到第一应用程序对应的更新文件,则可以根据第一消息向服务器发送请求消息。服务器可以根据请求消息,向终端设备发送第一应用程序的更新文件。终端设备可以根据更新文件对第一应用程序进行更新。由于可以通过第一消息及时通知终端设备获取第一应用程序对应的更新文件,且终端设备还可以通过轮询的方式,从服务器中轮询获取第一应用程序对应的更新文件。结合了通过第一消息通知终端设备获取更新文件、以及从服务器中轮询获取更新文件这2种方式,相比终端设备只通过轮询的方式从服务器中获取更新文件,提高了对应用程序的更新时效性。
166.下面,在图2所示实施例的基础上,结合图3,对上述应用程序更新方法进行详细说明。
167.图3为本技术示例性实施例提供的另一种应用程序更新方法的流程示意图。请参见图3,所述方法包括:
168.s301、服务器在确定第一应用程序的版本发生更新后,通过终端设备和服务器之间的通道,向终端设备发送第一消息。
169.可选地,服务器与终端设备之间可以通过通道进行通信。
170.通道使用的协议可以为消息队列遥测传输(message queuing telemetry transport,mqtt)。通道可以保持长连接,使得传输消息的时效性高。
171.通道有数据承载量限制,因此通道可以用于传输数据量较小的消息。例如,通道的最大数据承载量可以为2kb,则该通道只能传输小于2kb的消息。
172.由于第一消息的数据量较小,小于通道的最大数据承载量,因此可以通过通道传输第一消息。
173.例如,若服务器存储有1.0版本的app1,当app1的版本由1.0版本更新为2.0版本时,若通道的最大数据承载量为2kb,第一消息中包括app1的最新版本号2.0,数据量为1kb,则服务器可以通过通道向终端设备发送第一消息。
174.在一可选实施例中,可以通过如下方式,通过通道向终端设备发送第一消息:获取终端设备的设备状态;根据终端设备的设备状态向终端设备发送第一消息。
175.设备状态可以包括在线状态或者离线状态。
176.可选地,根据终端设备的设备状态向终端设备发送第一消息,可以包括如下2种情况:
177.情况1:若终端设备的设备状态为在线状态。
178.由于在该种情况下,终端设备可以正常接收消息,因此可以通过通道向终端设备发送第一消息。
179.例如,若终端设备1的设备状态为在线状态,则服务器可以通过通道向终端设备1发送第一消息。第一消息中可以包括第一应用程序的最新版本号2.0和延时信息120s。
180.情况2:若终端设备的设备状态为离线状态。
181.由于在该种情况下,终端设备无法接收消息,因此可以监测终端设备的设备状态,直至设备状态在当前时刻之后的预设时长内切换至在线状态时,通过通道向终端设备发送第一消息。
182.当前时刻是指生成第一消息的时刻。
183.预设时长是指通道可保存第一消息的时长。在预设时长之内,第一消息未被丢弃。例如,预设时长可以为72h,则在该72h内第一消息未被丢弃。
184.例如,若终端设备2的设备状态为离线状态,则服务器可以通过心跳消息监测设备终端设备2的设备状态,直至设备终端设备2的设备状态在当前时刻之后的72h内切换至在线状态时,服务器可以通过通道向终端设备2发送第一消息。第一消息中可以包括第一应用程序的最新版本号2.0。
185.s302、终端设备根据第一消息,获取第一应用程序的最新版本号和延时信息。
186.可选地,终端设备接收到第一消息之后,可以对第一消息进行解析处理,以获取第一消息中第一应用程序的最新版本号和延时信息。
187.例如,若第一消息中包括第一应用程序的最新版本号2.0和延时信息120s,则终端
设备可以对第一消息进行解析处理,得到第一应用程序的最新版本号为2.0、以及延时信息为120s。
188.s303、终端设备确定是否未从服务器轮询获取到第一应用程序对应的更新文件。
189.在一可选实施例中,可以通过如下方式,确定是否未从服务器轮询获取到第一应用程序对应的更新文件:获取第一应用程序的当前版本号;若当前版本号和最新版本号不同,则可以确定未从服务器轮询获取到第一应用程序对应的更新文件,则执行s304;若当前版本号和最新版本号相同,则可以确定已从服务器轮询获取到了第一应用程序对应的更新文件,则无需再次获取第一应用程序对应的更新文件。
190.例如,若第一应用程序为app1,第一消息包括app1的最新版本号2.0,若终端设备确定安装的app1为2.0版本,即app1的当前版本号为2.0,则由于当前版本号2.0和最新版本号2.0相同,则终端设备可以确定已从服务器中通过轮询的方式获取到app1对应的更新文件,即版本2.0对应的文件;若终端设备确定安装的app1为1.0版本,即app1的当前版本号为1.0,则由于当前版本号1.0和最新版本号2.0不同,则终端设备可以确定未从服务器中通过轮询的方式获取到app1对应的更新文件,即版本2.0对应的文件,则执行s304。
191.s304、终端设备根据延时信息,确定第一等待时长,并等待第一等待时长。
192.第一等待时长用于指示终端设备在第一等待时长之后向服务器发送消息。对于不同的终端设备,第一等待时长可以不同,目的是为了避免多个终端设备在同一时刻向服务器发送消息所造成的服务器负载过高。
193.可选地,根据延时信息,确定第一等待时长,可以包括如下2种情况:
194.情况1:延时信息包括延时时长。
195.在该种情况下,则终端设备可以将延时信息中的延时时长确定为第一等待时长。
196.例如,若延时信息中包括延时时长为120s,则终端设备可以将延时时长120s,确定为第一等待时长。
197.情况2:延时信息中包括延时范围。
198.在该种情况下,则终端设备可以根据延时范围随机生成第一等待时长,第一等待时长位于延时范围内。
199.例如,若延时信息中包括延时范围为0~120s,则终端设备可以将根据延时范围随机生成第一等待时长,假设随机生成的第一等待时长为80s。
200.可选地,终端设备确定第一等待时长之后,可以等待第一等待时长。例如,若终端设备确定第一等待时长为80s,则终端设备可以等待80s。
201.s305、终端设备在第一等待时长结束之后,判断是否从服务器轮询获取到更新文件。
202.由于终端设备中也可以通过轮询的方式从服务器中轮询获取到更新文件,若在第一等待时长内,终端设备刚好从服务器中轮询获取到了更新文件,则在第一等待时长结束之后,无需再次获取更新文件;若在第一等待时长内,终端设备未从服务器中轮询获取到更新文件,则在第一等待时长结束之后,终端设备需要获取更新文件,则可以执行s306。
203.因此,在第一等待时长结束之后,终端设备需要判断是否从服务器中轮询获取到更新文件,即终端设备可以获取第一应用程序的当前版本号;若当前版本号和最新版本号不同,则可以确定未从服务器轮询获取到第一应用程序对应的更新文件。
204.例如,若第一应用程序为app1,第一消息包括app1的最新版本号2.0,若第一等待时长为80s,则终端设备在等待80s之后,可以确定安装的app1的版本。假设安装的app1为1.0版本即app1的当前版本号为1.0,则由于当前版本号1.0和最新版本号2.0不同,则终端设备可以确定未从服务器中通过轮询的方式获取到app1对应的更新文件。
205.s306、终端设备向服务器发送请求消息。
206.终端设备可以通过超文本传输协议(hyper text transfer protocol,http),调用接口向服务器发送请求消息。请求消息中可以包括第一应用程序的标识。
207.例如,若第一应用程序为app1,对应的标识为001,则终端设备可以向服务器发送请求消息,请求消息中可以包括第一应用程序的标识001。
208.可选地,在终端设备可以调用接口,向服务器发送请求消息成功之后,可以重置轮询周期。
209.s307、服务器根据请求消息,向终端设备发送响应消息。
210.可选地,服务器接收到请求消息之后,可以确定待处理请求量,根据待处理请求量向终端设备发送响应消息。
211.根据待处理请求量向终端设备发送响应消息,可以包括如下2种情况:
212.情况1:待处理请求量小于预设阈值。
213.在该种情况下,服务器可以向终端设备发送响应消息,响应消息中可以包括第一应用程序的更新文件。
214.例如,若第一应用程序为app1,若预设阈值为1000,若服务器确定待处理请求量为800,由于待处理请求量800小于预设阈值1000,则服务器可以向终端设备发送响应消息,响应消息中可以包括app1对应的更新文件。
215.情况2:待处理请求量大于或等于预设阈值。
216.在该种情况下,服务器可以向终端设备发送响应消息,响应消息中可以包括第二等待时长。
217.例如,若第一应用程序为app1,若预设阈值为1000,若服务器确定待处理请求量为5000,待处理请求量5000大于或等于预设阈值1000,则服务器可以向终端设备发送响应消息,响应消息中可以包括第二等待时长。假设第二等待时长为10s。
218.需要说明的是,若服务器中的待处理请求量大于等于预设阈值时,服务器每次向终端设备发送响应消息时,响应消息中的第二等待时长会随着发送响应消息的次数增大,直到服务器中的待处理请求量小于预设阈值时,响应消息中包括更新文件。
219.例如,若服务器的待处理请求量为5万,大于预设阈值1000,则服务器第1次响应于请求消息发送的响应消息1中,第二等待时长可以为10s;若在10s后,服务器的待处理请求量为4万,服务器第2次响应于终端设备第2次发送的请求消息,发送的响应消息2中,第二等待时长可以为30s;
……
;直至服务器的待处理请求量小于预设阈值1000时,服务器第i次响应于终端设备第i次发送的请求消息,发送的响应消息i中,响应消息i包括更新文件。i可以为大于或等于1的整数。
220.s308、终端设备确定响应消息中是否包括更新文件。
221.若是,则执行s309;若否,则在第二等待时长之后执行s306,向服务器重发请求消息,直至接收到的响应消息中包括更新文件时,获取得到更新文件。
222.例如,若第一应用程序为app1,若响应消息中包括app1对应的更新文件,则终端设备可以执行s309;若响应消息中可以包括第二等待时长10s,则终端设备可以等待10s之后,可以执行s306,向服务器重发请求消息,直至接收到的响应消息中包括app1对应的更新文件时,以获取得到更新文件。
223.s309、终端设备根据更新文件对第一应用程序进行更新。
224.例如,若第一应用程序为app1,终端设备中安装的app1的版本为1.0,更新文件为app1的2.0版本的配置文件,则终端设备可以根据更新文件对app1进行更新,将app1从1.0版本更新为2.0版本。
225.在本技术实施例中,服务器在确定第一应用程序的版本发生更新后,可以通过终端设备和服务器之间的通道,向终端设备发送第一消息。终端设备接收到第一消息之后,可以根据第一消息,获取第一应用程序的最新版本号和延时信息。终端设备可以确定是否未从服务器轮询获取到第一应用程序对应的更新文件。若是,则终端设备可以根据延时信息,确定第一等待时长,并等待第一等待时长。在第一等待时长结束之后,终端设备可以判断是否从服务器轮询获取到更新文件;若是,则终端设备可以向服务器发送请求消息。服务器可以根据请求消息,向终端设备发送响应消息。终端设备可以确定响应消息中是否包括更新文件,若是,则终端设备根据更新文件对第一应用程序进行更新。由于通道可以保持长连接,通过通道传输第一消息的时效性较高,因此可以通过第一消息及时通知终端设备获取第一应用程序对应的更新文件;且终端设备还可通过轮询的方式,从服务器中轮询获取第一应用程序对应的更新文件。结合了通过第一消息通知终端设备获取更新文件、以及从服务器中轮询获取更新文件这2种方式,相比终端设备只通过轮询的方式从服务器中获取更新文件,提高了对应用程序的更新时效性。
226.下面,在上述任一实施例的基础上,结合图4,通过具体示例,对上述应用程序更新方法进行进一步详细说明。
227.图4为本技术示例性实施例提供的一种应用程序更新方法的过程示意图。请参见图4,包括服务器和多个终端设备。该多个终端设备可以分别为终端设备1、终端设备2、
……
、终端设备10。
228.服务器中可以包括配置中心和配置下发服务。配置中心可以保存有第一应用程序对应的更新文件。例如,若第一应用程序为app1,则配置中心可以保存app1对应的更新文件,更新文件可以为app1为2.0版本的配置文件。
229.在步骤
①
中,配置下发服务可以周期性监听配置中心中第一应用程序的版本是否发生更新,即是否有更新文件。当第一应用程序的版本发生更新时,配置中心可以响应配置下发服务的监听消息,向配置下发服务发送第一应用程序的最新版本号。例如,当app1的版本发生更新时,配置中心可以向配置下发服务发送app1的最新版本号2.0。
230.需要说明的是,配置下发服务对配置中心的周期性监听可以做到秒级或者毫秒级,以及时获取第一应用程序的最新版本号。
231.在步骤
②
中,服务器可以获取终端设备的设备状态,根据终端设备的设备状态,通过通道向多个终端设备发送第一消息。第一消息中可以包括第一应用程序的最新版本号,还可以包括延时信息。例如,第一消息中可以包括第一应用程序的最新版本号2.0和延时信息120s。
232.例如,若在该10个终端设备中,终端设备1、终端设备2、
……
、终端设备9为在线状态,终端设备10为离线状态,则服务器可以获取每个终端设备的设备状态,向在线状态的9个终端设备发送第一消息,以使该9个终端设备及时接收第一消息;若服务器确定终端设备10的设备状态为离线状态,通道可保存第一消息的预设时长为72h,则服务器可以监测终端设备10的设备状态,直至终端设备10在当前时刻之后的预设时长72h内切换至在线状态时,通过通道向终端设备10发送第一消息。
233.在步骤
③
中,终端设备根据第一消息,向服务器发送请求消息,以请求获取第一应用程序对应的更新文件。
234.针对任意一个终端设备,终端设备接收到第一消息之后,可以对第一消息进行解析处理,以获取第一消息中第一应用程序的最新版本号和延时信息。
235.终端设备可以获取第一应用程序的当前版本号;若当前版本号和最新版本号不同,则终端设备可以确定未从服务器轮询获取到第一应用程序对应的更新文件,则可以根据第一消息,向服务器发送请求消息;若当前版本号和最新版本号相同,则终端设备可以确定已从服务器轮询获取到了第一应用程序对应的更新文件,则无需向服务器发送请求消息,以获取第一应用程序对应的更新文件。
236.由于第一消息中还可以包括延时信息,则终端设备可以根据延时信息,确定第一等待时长,并在第一等待时长结束之后,再次判断是否从服务器轮询获取到更新文件,若确定未从服务器轮询获取到第一应用程序对应的更新文件,则终端设备可以调用接口,向服务器发送请求消息。
237.可选地,在终端设备可以调用接口,向服务器发送请求消息成功之后,可以重置轮询周期。
238.在步骤
④
中,服务器接收到请求消息之后,可以确定待处理请求量,根据待处理请求量,向终端设备发送响应消息。
239.若待处理请求量小于预设阈值,则服务器可以向终端设备发送响应消息,响应消息中可以包括第一应用程序的更新文件。例如,响应消息中可以包括app1对应的更新文件。
240.若待处理请求量大于或等于预设阈值,则服务器可以向终端设备发送响应消息,响应消息中可以包括第二等待时长。例如,响应消息中可以包括第二等待时长为10s。
241.在步骤
⑤
中,终端设备接收到服务器发送的响应消息之后,可以确定响应消息中是否包括更新文件。若是,则可以根据更新文件对第一应用程序进行更新;若否,则在第二等待时长之后向服务器重发请求消息,直至接收到的响应消息中包括更新文件时,获取得到更新文件,根据更新文件对第一应用程序进行更新。例如,若终端设备中安装的app1的版本为1.0,更新文件为app1的2.0版本的配置文件,则终端设备可以根据更新文件对app1进行更新,将app1从1.0版本更新为2.0版本。
242.可选地,每个终端设备中还可以设置有轮询获取更新文件的方式、以及冷启动获取更新文件的方式。
243.在轮询方式中,终端设备按照轮询周期,向服务器发送轮询请求。若服务器的第一应用程序的最新版本号大于当前版本号,则可以接收服务器发送的更新文件,根据更新文件对第一应用程序进行更新。若服务器的第一应用程序的最新版本号等于当前版本号,则可以接收服务器发送的反馈信息,反馈信息可以用于指示终端设备中的第一应用程序已是
最新版本,无需获取更新文件。
244.冷启动是指在终端设备没有运行第一应用程序的情况下,启动第一应用程序。
245.在冷启动获取更新文件的方式中,在终端设备每次启动第一应用程序时,终端设备可以调用接口,向服务器发送请求消息,获取第一应用程序对应的更新文件。
246.在本技术实施例中,服务器在确定第一应用程序的版本发生更新后,可以通过终端设备和服务器之间的通道,向终端设备发送第一消息。终端设备接收到第一消息之后,可以根据第一消息,向服务器发送请求消息。服务器可以根据请求消息,向终端设备发送响应消息。终端设备可以确定响应消息中是否包括更新文件,若是,则终端设备根据更新文件对第一应用程序进行更新。由于通道可以保持长连接,通过通道传输第一消息的时效性较高,因此可以通过第一消息及时通知终端设备获取第一应用程序对应的更新文件;且终端设备还可通过轮询的方式,从服务器中轮询获取第一应用程序对应的更新文件。结合了通过第一消息通知终端设备获取更新文件、以及从服务器中轮询获取更新文件这2种方式,相比终端设备只通过轮询的方式从服务器中获取更新文件,提高了对应用程序的更新时效性。
247.下面,在图2所示实施例的基础上,结合图5,对上述应用程序更新方法进行进一步详细说明。
248.图5为本技术示例性实施例提供的又一种应用程序更新方法的流程示意图。请参见图5,所述方法包括:
249.s501、服务器在确定第一应用程序的版本发生更新后,在api网关生成第一消息。
250.应用程序编程接口(application programming interface,api)网关是指自建的网关,终端设备发送的任意请求都会经过api网关。
251.服务器中可以设置有api网关。当服务器确定第一应用程序的版本发生更新后,可以在api网关中生成第一消息并保存,则api网关中保存有第一消息。
252.第一消息中可以包括第一应用程序的最新版本号。例如,第一消息中可以包括第一应用程序的最新版本号2.0。
253.例如,若服务器确定第一应用程序的版本更新为2.0版本,则可以在api网关中生成第一消息,第一消息中可以包括第一应用程序的最新版本号2.0。
254.s502、在生成第一消息之后的预设时段内,若服务器接收到终端设备发送的第二消息,则生成第二消息对应的第一响应消息。
255.预设时段是指第一消息的生成时刻之后的一段时长。在预设时段内第一消息未被丢弃;在预设时段结束之后,第一消息会被丢弃,换而言之,第一消息的有效时长为预设时段对应的时长。
256.例如,若第一消息的生成时刻为10:00,若预设时段为5min,则预设时段是指10:00-10:05之间的5min。在该5min内,第一消息未被丢弃;在该5min结束后,第一消息会被丢弃,即第一消息的有效时长为5min。
257.第二消息可以为终端设备在预设时段内向服务器发送的任意消息。例如,若预设时段为10:00-10:05之间的5min,则终端设备在该5min内向服务器发送的任意消息都可以称为第二消息。
258.第一响应消息为服务器对终端设备发送的第二消息进行响应的消息。第一响应消息中可以包括第一消息。例如,若第一消息中包括第一应用程序的最新版本号2.0,则第一
响应消息中可以包括该第一消息。
259.若在预设时段内,服务器接收到终端设备发送的第二消息,由于第一消息在预设时段内是有效的,则服务器向终端设备发送第二消息对应的第一响应消息时,可以附带第一消息,即第一响应消息中可以包括第一消息。
260.需要说明的是,在第一响应消息中附带第一消息,是因为在预设时段内,终端设备可能会向服务器发送其他任意请求,而没有发轮询请求以获取更新文件,因此为了及时通知终端设备获取更新文件,则可以在对终端设备发送的第二消息即任意消息进行响应时,生成的第一响应消息中附带第一消息。
261.s503、服务器在等待第一时长后,通过api网关发送向终端设备发送第一响应消息。
262.第一时长可以是由服务器随机确定的。例如,第一时长可以为3s。
263.例如,若第一时长为3s,则服务器在等待3s后,向终端设备发送第一响应消息。
264.需要说明的是,服务器随机等待第一时长之后,向终端设备发送第一响应消息,是为了避免多个终端设备同时接收到第一响应消息,并根据第一响应消息同时向服务器发送请求消息,容易造成服务器的负载过大。
265.s504、终端设备根据第一响应消息获取第一消息,并获取第一应用程序的最新版本号。
266.可选地,终端设备接收到第一响应消息之后,可以对第一响应消息进行解析处理,以获取第一响应消息中的第一消息,进而可以根据第一消息,确定第一应用程序的最新版本号。
267.例如,若第一响应消息中包括第一消息,第一消息中包括第一应用程序的最新版本号2.0,则终端设备可以对第一响应消息进行解析处理,得到第一消息,进而可以根据第一消息,确定第一应用程序的最新版本号为2.0。
268.s505、终端设备确定是否从服务器轮询获取到第一应用程序对应的更新文件。
269.可选地,终端设备可以获取第一应用程序的当前版本号;若当前版本号和最新版本号不同,则可以确定未从服务器轮询获取到第一应用程序对应的更新文件,则执行s506;若当前版本号和最新版本号相同,则可以确定已从服务器轮询获取到了第一应用程序对应的更新文件,则无需再次获取第一应用程序对应的更新文件。
270.例如,若第一应用程序为app1,终端设备确定app1的最新版本号2.0,若终端设备确定安装的app1为2.0版本,即app1的当前版本号为2.0,则由于当前版本号2.0和最新版本号2.0相同,则终端设备可以确定已从服务器中通过轮询的方式获取到app1对应的更新文件,即版本2.0对应的文件;若终端设备确定安装的app1为1.0版本,即app1的当前版本号为1.0,则由于当前版本号1.0和最新版本号2.0不同,则终端设备可以确定未从服务器中通过轮询的方式获取到app1对应的更新文件,即版本2.0对应的文件,则执行s506。
271.s506、终端设备向服务器发送请求消息。
272.终端设备可以通过http协议,调用接口向服务器发送请求消息。请求消息中可以包括第一应用程序的标识。
273.例如,若第一应用程序为app1,对应的标识为001,则终端设备可以向服务器发送请求消息,请求消息中可以包括第一应用程序的标识001。
274.可选地,在终端设备可以调用接口,向服务器发送请求消息成功之后,可以重置轮询周期。
275.s507、服务器根据请求消息,向终端设备发送响应消息。
276.可选地,服务器接收到请求消息之后,可以确定待处理请求量,若待处理请求量小于预设阈值,则服务器可以向终端设备发送响应消息,响应消息中可以包括第一应用程序的更新文件;若待处理请求量大于或等于预设阈值,则服务器可以向终端设备发送响应消息,响应消息中可以包括第二等待时长。
277.例如,若第一应用程序为app1,若预设阈值为1000,若服务器确定待处理请求量为800,则由于待处理请求量800小于预设阈值1000,则服务器可以向终端设备发送响应消息,响应消息中可以包括app1对应的更新文件;若服务器确定待处理请求量为5000,待处理请求量5000大于或等于预设阈值1000,则服务器可以向终端设备发送响应消息,响应消息中可以包括第二等待时长。假设第二等待时长为10s。
278.s508、终端设备确定响应消息中是否包括更新文件。
279.若是,则执行s509;若否,则在第二等待时长之后,执行s506向服务器重发请求消息,直至接收到的响应消息中包括更新文件时,获取得到更新文件。
280.例如,若第一应用程序为app1,若响应消息中包括app1对应的更新文件,则终端设备可以执行s509;若响应消息中可以包括第二等待时长10s,则终端设备可以等待10s之后,执行s506可以向服务器重发请求消息,直至接收到的响应消息中包括app1对应的更新文件时,以获取得到更新文件。
281.s509、终端设备根据更新文件对第一应用程序进行更新。
282.例如,若第一应用程序为app1,终端设备中安装的app1的版本为1.0,更新文件为app1的2.0版本的配置文件,则终端设备可以根据更新文件对app1进行更新,将app1从1.0版本更新为2.0版本。
283.在本技术实施例中,服务器可以在确定第一应用程序的版本发生更新后,在api网关生成第一消息。在生成第一消息之后的预设时段内,若服务器接收到终端设备发送的第二消息,则生成第二消息对应的第一响应消息。服务器在等待第一时长后,可以通过api网关发送向终端设备发送第一响应消息。终端设备可以根据第一响应消息获取第一消息,并获取第一应用程序的最新版本号。终端设备确定是否服务器轮询获取到第一应用程序对应的更新文件。若否,则终端设备可以向服务器发送请求消息。服务器可以根据请求消息,向终端设备发送响应消息。终端设备可以确定响应消息中是否包括更新文件。若是,则终端设备根据更新文件对第一应用程序进行更新。由于可以在api网关中生成第一消息,在预设时段内,服务器可以对终端设备发送的任意消息,进行响应生成附带第一消息的第一响应消息,使得终端设备可以及时得知需要获取第一应用程序对应的更新文件;且终端设备还可通过轮询的方式,从服务器中轮询获取第一应用程序对应的更新文件。结合了通过第一消息通知终端设备获取更新文件、以及从服务器中轮询获取更新文件这2种方式,相比终端设备只通过轮询的方式从服务器中获取更新文件,提高了对应用程序的更新时效性。
284.下面,在图2和图5所示实施例的基础上,结合图6,通过具体示例,对上述应用程序更新方法进行进一步详细说明。
285.图6为本技术示例性实施例提供的另一种应用程序更新方法的过程示意图。请参
见图6,可以包括服务器和终端设备。
286.服务器中可以包括配置中心和api网关。配置中心可以保存有第一应用程序对应的更新文件。例如,若第一应用程序为app1,则配置中心可以保存app1对应的更新文件,更新文件可以为app1为2.0版本的配置文件。
287.在步骤
①
中,api网关可以周期性监听配置中心中第一应用程序的版本是否发生更新,并生成第一消息。
288.当第一应用程序的版本发生更新时,即有更新文件时,配置中心可以响应api网关的监听消息,向api网关发送第一应用程序的最新版本号。api网关可以根据第一应用程序的最新版本号,生成第一消息。第一消息中可以包括第一应用程序的最新版本号。在预设时段内,第一消息是有效的。
289.例如,当app1的版本发生更新时,配置中心可以向api网关发送app1的最新版本号2.0。api网关可以生成第一消息,第一消息中可以包括第一应用程序的最新版本号2.0。若预设时段为5min,则在该5min内,第一消息为有效的。
290.需要说明的是,api网关对配置中心的周期性监听可以做到秒级或者毫秒级,以及时获取第一应用程序的最新版本号。
291.在步骤
②
中,终端设备可以向服务器发送第二消息,第二消息可以为终端设备在预设时段内向服务器发送的任意消息。
292.在步骤
③
中,若在预设时段内,服务器接收到终端设备发送的第二消息,服务器可以生成第二消息对应的第一响应消息。第一响应消息中可以包括第一消息。例如,若第一消息中包括第一应用程序的最新版本号2.0,则第一响应消息中可以包括该第一消息。
293.服务器可以随机确定第一时长,并等待第一时长后,通过api网关发送向终端设备发送第一响应消息。
294.终端设备接收到第一响应消息之后,可以根据第一响应消息获取第一消息,并获取第一应用程序的最新版本号。
295.在步骤
④
中,终端设备可以根据第一消息,向服务器发送请求消息,以请求获取第一应用程序对应的更新文件。
296.终端设备接收到第一响应消息之后,可以根据第一响应消息获取第一消息,并获取第一应用程序的最新版本号。
297.终端设备可以获取第一应用程序的当前版本号;若当前版本号和最新版本号不同,则终端设备可以确定未从服务器轮询获取到第一应用程序对应的更新文件,则可以根据第一消息,调用接口向服务器发送请求消息;若当前版本号和最新版本号相同,则终端设备可以确定已从服务器轮询获取到了第一应用程序对应的更新文件,则无需向服务器发送请求消息,以获取第一应用程序对应的更新文件。
298.可选地,在终端设备可以调用接口,向服务器发送请求消息成功之后,可以重置轮询周期。
299.在步骤
⑤
中,服务器接收到请求消息之后,可以确定待处理请求量,根据待处理请求量,向终端设备发送响应消息。
300.若待处理请求量小于预设阈值,则服务器可以向终端设备发送响应消息,响应消息中可以包括第一应用程序的更新文件。例如,响应消息中可以包括app1对应的更新文件。
301.若待处理请求量大于或等于预设阈值,则服务器可以向终端设备发送响应消息,响应消息中可以包括第二等待时长。例如,响应消息中可以包括第二等待时长为10s。
302.在步骤
⑥
中,终端设备接收到服务器发送的响应消息之后,可以确定响应消息中是否包括更新文件。若是,则可以根据更新文件对第一应用程序进行更新;若否,则在第二等待时长之后向服务器重发请求消息,直至接收到的响应消息中包括更新文件时,获取得到更新文件,根据更新文件对第一应用程序进行更新。例如,若终端设备中安装的app1的版本为1.0,更新文件为app1的2.0版本的配置文件,则终端设备可以根据更新文件对app1进行更新,将app1从1.0版本更新为2.0版本。
303.可选地,终端设备中还可以设置有轮询获取更新文件的方式、以及冷启动获取更新文件的方式。
304.在轮询方式中,终端设备按照轮询周期,向服务器发送轮询请求。若服务器的第一应用程序的最新版本号大于当前版本号,则可以接收服务器发送的更新文件,根据更新文件对第一应用程序进行更新。若服务器的第一应用程序的最新版本号等于当前版本号,则可以接收服务器发送的反馈信息,反馈信息可以用于指示终端设备中的第一应用程序已是最新版本,无需获取更新文件。
305.在冷启动获取更新文件的方式中,在终端设备每次启动第一应用程序时,终端设备可以调用接口,向服务器发送请求消息,获取第一应用程序对应的更新文件。
306.在本技术实施例中,服务器可以在确定第一应用程序的版本发生更新后,在api网关生成第一消息。在生成第一消息之后的预设时段内,若服务器接收到终端设备发送的第二消息,则生成第二消息对应的第一响应消息。服务器在等待第一时长后,可以通过api网关发送向终端设备发送第一响应消息。终端设备可以根据第一响应消息获取第一消息,并根据第一消息,向服务器发送请求消息。服务器可以根据请求消息,向终端设备发送响应消息。终端设备可以确定响应消息中是否包括更新文件,若是,则终端设备根据更新文件对第一应用程序进行更新。由于可以在api网关中生成第一消息,在预设时段内,服务器可以对终端设备发送的任意消息,进行响应生成附带第一消息的第一响应消息,使得终端设备可以及时得知需要获取第一应用程序对应的更新文件;且终端设备还可通过轮询的方式,从服务器中轮询获取第一应用程序对应的更新文件。结合了通过第一消息通知终端设备获取更新文件、以及从服务器中轮询获取更新文件这2种方式,相比终端设备只通过轮询的方式从服务器中获取更新文件,提高了对应用程序的更新时效性。
307.图7为本技术示例性实施例提供的一种应用程序更新装置的结构示意图。请参见图7,所述应用程序更新装置10应用于终端设备,所述应用程序更新装置10包括:接收模块11、获取模块12和更新模块13,其中,
308.所述接收模块11用于,接收服务器发送的第一消息,所述第一消息用于指示第一应用程序的版本发生更新,所述第一消息包括所述第一应用程序的最新版本号;
309.所述获取模块12用于,若确定未从所述服务器轮询获取到所述第一应用程序对应的更新文件,则根据所述第一消息从所述服务器获取所述更新文件;
310.所述更新模块13用于,根据所述更新文件对所述第一应用程序进行更新。
311.本技术实施例提供的应用程序更新装置可以执行上述方法实施例所示的技术方案,其实现原理以及有益效果类似,此处不再进行赘述。
312.在一种可能的实施方式中,所述第一消息中包括延时信息;所述获取模块12具体用于:
313.根据所述延时信息,确定第一等待时长;
314.等待所述第一等待时长,并在所述第一等待时长结束之后判断是否从所述服务器轮询获取到所述更新文件;
315.若否,则根据所述第一消息从所述服务器获取所述更新文件。
316.在一种可能的实施方式中,所述获取模块12具体用于:
317.所述延时信息包括延时时长,则将所述延时信息中的延时时长确定为所述第一等待时长;或者,
318.所述延时信息中包括延时范围,则根据所述延时范围随机生成所述第一等待时长,所述第一等待时长位于所述延时范围内。
319.在一种可能的实施方式中,所述获取模块12具体用于:
320.向所述服务器发送请求消息,所述请求消息包括所述第一应用程序的标识;
321.接收所述服务器发送的响应消息,所述响应消息包括第二等待时长或者所述更新文件;
322.若所述响应消息中包括所述第二等待时长,则根据所述第二等待时长向所述服务器重发所述请求消息,直至接收到的响应消息中包括所述更新文件时,获取得到所述更新文件。
323.在一种可能的实施方式中,所述获取模块12具体用于:
324.获取所述第一应用程序的当前版本号;
325.若所述当前版本号和所述最新版本号不同,则确定未从所述服务器轮询获取到所述第一应用程序对应的更新文件。
326.在一种可能的实施方式中,所述接收模块11具体用于:
327.通过所述终端设备和所述服务器之间的通道接收所述服务器发送的所述第一消息;或者;
328.接收所述服务器通过所述服务器中的应用程序编程接口api网关发送的第一响应消息,所述第一响应消息包括所述第一消息,所述第一响应消息为所述服务器对所述终端设备的任意消息进行响应的消息。
329.在一种可能的实施方式中,所述应用程序更新装置10还可以包括:确定模块14和发送模块15,其中,
330.所述确定模块14用于,确定轮询周期;
331.所述发送模块15用于,按照所述轮询周期,向所述服务器发送轮询请求,所述轮询请求中包括所述第一应用程序的标识和所述第一应用程序的当前版本号;
332.所述接收模块11还用于,若所述服务器的所述第一应用程序的最新版本号大于所述当前版本号,则接收所述服务器发送的所述更新文件;
333.所述更新模块13用于,根据所述更新文件对所述第一应用程序进行更新。
334.本技术实施例提供的应用程序更新装置可以执行上述方法实施例所示的技术方案,其实现原理以及有益效果类似,此处不再进行赘述。
335.图8为本技术示例性实施例提供的另一种应用程序更新装置的结构示意图。请参
见图8,所述应用程序更新装置20应用于服务器,所述应用程序更新装置20还包括:发送模块21和接收模块22,其中,
336.所述发送模块21用于,在确定第一应用程序的版本发生更新后,向终端设备发送第一消息,所述第一消息包括所述第一应用程序的最新版本号;
337.所述接收模块22用于,接收所述终端设备根据所述第一消息发送的请求消息;
338.所述发送模块21用于,根据所述请求消息,向所述终端设备发送所述第一应用程序的更新文件。
339.本技术实施例提供的应用程序更新装置可以执行上述方法实施例所示的技术方案,其实现原理以及有益效果类似,此处不再进行赘述。
340.在一种可能的实施方式中,所述发送模块21具体用于:
341.通过所述终端设备和所述服务器之间的通道,向所述终端设备发送所述第一消息。
342.在一种可能的实施方式中,所述发送模块21具体用于:
343.获取所述终端设备的设备状态,所述设备状态为在线状态或者离线状态;
344.若所述设备状态为所述在线状态,则通过所述通道向所述终端设备发送所述第一消息,所述第一消息还包括延时信息;
345.若所述设备状态为所述离线状态,则监测终端设备的设备状态,直至所述设备状态在当前时刻之后的预设时长内切换至在线状态时,通过所述通道向所述终端设备发送所述第一消息。
346.在一种可能的实施方式中,所述发送模块21具体用于:
347.生成所述第一消息;
348.在生成所述第一消息之后的预设时段内,若接收到终端设备发送的第二消息,则生成所述第二消息对应的第一响应消息,所述第一响应消息包括所述第一消息,所述第二消息为所述终端设备向所述服务器发送的任意消息;
349.在等待第一时长后,通过应用程序编程接口api网关向所述终端设备发送所述第一响应消息。
350.在一种可能的实施方式中,所述发送模块21具体用于:
351.确定待处理请求量;
352.若所述待处理请求量小于所述预设阈值,向所述终端设备发送所述第一应用程序的更新文件;
353.若所述待处理请求量大于或等于预设阈值,则向所述终端设备发送第二等待时长,并在所述第二等待时长之后接收所述终端设备重发的所述请求消息,直至所述待处理请求量小于所述预设阈值时,向所述终端设备发送所述第一应用程序对应的更新文件。
354.本技术实施例提供的应用程序更新装置可以执行上述方法实施例所示的技术方案,其实现原理以及有益效果类似,此处不再进行赘述。
355.本技术示例性实施例提供一种终端设备的结构示意图,请参见图9,该终端设备30可以包括处理器31和存储器32。示例性地,处理器31、存储器32,各部分之间通过总线33相互连接。
356.所述存储器32存储计算机执行指令;
357.所述处理器31执行所述存储器32存储的计算机执行指令,使得所述处理器31执行如上述方法实施例所示的应用程序更新方法。
358.本技术示例性实施例提供一种服务器的结构示意图,请参见图10,该服务器40可以包括处理器41和存储器42。示例性地,处理器41、存储器42,各部分之间通过总线43相互连接。
359.所述存储器42存储计算机执行指令;
360.所述处理器41执行所述存储器42存储的计算机执行指令,使得所述处理器41执行如上述方法实施例所示的应用程序更新方法。
361.相应地,本技术实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当所述计算机执行指令被处理器执行时用于实现上述任一方法实施例所述的应用程序更新方法。
362.相应地,本技术实施例还可提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时,可实现上述任一方法实施例所示的应用程序更新方法。
363.本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
364.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
365.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
366.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
367.在一个典型的配置中,计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
368.内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
369.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。
计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
370.还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个
……”
限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
371.以上所述仅为本技术的实施例而已,并不用于限制本技术。对于本领域技术人员来说,本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本技术的权利要求范围之内。
技术特征:
1.一种应用程序更新方法,其特征在于,应用于终端设备,所述终端设备中安装有第一应用程序,所述方法包括:接收服务器发送的第一消息,所述第一消息用于指示第一应用程序的版本发生更新,所述第一消息包括所述第一应用程序的最新版本号;若确定未从所述服务器轮询获取到所述第一应用程序对应的更新文件,则根据所述第一消息从所述服务器获取所述更新文件;根据所述更新文件对所述第一应用程序进行更新。2.根据权利要求1所述的方法,其特征在于,所述第一消息中包括延时信息;根据所述第一消息从所述服务器获取所述更新文件,包括:根据所述延时信息,确定第一等待时长;等待所述第一等待时长,并在所述第一等待时长结束之后判断是否从所述服务器轮询获取到所述更新文件;若否,则根据所述第一消息从所述服务器获取所述更新文件。3.根据权利要求2所述的方法,其特征在于,根据所述延时信息,确定第一等待时长,包括:所述延时信息包括延时时长,则将所述延时信息中的延时时长确定为所述第一等待时长;或者,所述延时信息中包括延时范围,则根据所述延时范围随机生成所述第一等待时长,所述第一等待时长位于所述延时范围内。4.根据权利要求2或3所述的方法,其特征在于,根据所述第一消息从所述服务器获取所述更新文件,包括:向所述服务器发送请求消息,所述请求消息包括所述第一应用程序的标识;接收所述服务器发送的响应消息,所述响应消息包括第二等待时长或者所述更新文件;若所述响应消息中包括所述第二等待时长,则根据所述第二等待时长向所述服务器重发所述请求消息,直至接收到的响应消息中包括所述更新文件时,获取得到所述更新文件。5.根据权利要求1-4任一项所述的方法,其特征在于,确定未从所述服务器轮询获取到所述第一应用程序对应的更新文件,包括:获取所述第一应用程序的当前版本号;若所述当前版本号和所述最新版本号不同,则确定未从所述服务器轮询获取到所述第一应用程序对应的更新文件。6.根据权利要求1-5任一项所述的方法,其特征在于,接收服务器发送的第一消息,包括:通过所述终端设备和所述服务器之间的通道接收所述服务器发送的所述第一消息;或者;接收所述服务器通过所述服务器中的应用程序编程接口api网关发送的第一响应消息,所述第一响应消息包括所述第一消息,所述第一响应消息为所述服务器对所述终端设备的任意消息进行响应的消息。7.根据权利要求1-6任一项所述的方法,其特征在于,所述方法还包括:
确定轮询周期;按照所述轮询周期,向所述服务器发送轮询请求,所述轮询请求中包括所述第一应用程序的标识和所述第一应用程序的当前版本号;若所述服务器的所述第一应用程序的最新版本号大于所述当前版本号,则接收所述服务器发送的所述更新文件;根据所述更新文件对所述第一应用程序进行更新。8.一种应用程序更新方法,其特征在于,应用于服务器,所述方法包括:在确定第一应用程序的版本发生更新后,向终端设备发送第一消息,所述第一消息包括所述第一应用程序的最新版本号;接收所述终端设备根据所述第一消息发送的请求消息;根据所述请求消息,向所述终端设备发送所述第一应用程序的更新文件。9.根据权利要求8所述的方法,其特征在于,向终端设备发送第一消息,包括:通过所述终端设备和所述服务器之间的通道,向所述终端设备发送所述第一消息。10.根据权利要求9所述的方法,其特征在于,通过所述终端设备和所述服务器之间的通道,向所述终端设备发送所述第一消息,包括:获取所述终端设备的设备状态,所述设备状态为在线状态或者离线状态;若所述设备状态为所述在线状态,则通过所述通道向所述终端设备发送所述第一消息,所述第一消息还包括延时信息;若所述设备状态为所述离线状态,则监测终端设备的设备状态,直至所述设备状态在当前时刻之后的预设时长内切换至在线状态时,通过所述通道向所述终端设备发送所述第一消息。11.根据权利要求8所述的方法,其特征在于,向终端设备发送第一消息,包括:生成所述第一消息;在生成所述第一消息之后的预设时段内,若接收到终端设备发送的第二消息,则生成所述第二消息对应的第一响应消息,所述第一响应消息包括所述第一消息,所述第二消息为所述终端设备向所述服务器发送的任意消息;在等待第一时长后,通过应用程序编程接口api网关向所述终端设备发送所述第一响应消息。12.根据权利要求8-11任一项所述的方法,其特征在于,根据所述请求消息,向所述终端设备发送所述第一应用程序的更新文件,包括:确定待处理请求量;若所述待处理请求量小于所述预设阈值,向所述终端设备发送所述第一应用程序的更新文件;若所述待处理请求量大于或等于预设阈值,则向所述终端设备发送第二等待时长,并在所述第二等待时长之后接收所述终端设备重发的所述请求消息,直至所述待处理请求量小于所述预设阈值时,向所述终端设备发送所述第一应用程序对应的更新文件。13.一种终端设备,其特征在于,包括:至少一个处理器;以及与所述至少一个处理器通信连接的存储器;
其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述终端设备执行权利要求1-7任一项所述的方法。14.一种服务器,其特征在于,包括:至少一个处理器;以及与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述服务器执行权利要求8-12任一项所述的方法。15.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如权利要求1-7任一项所述的方法,或者权利要求8-12任一项所述的方法。16.一种计算机程序产品,包括计算机程序,其特征在于,该计算机程序被处理器执行时实现如权利要求1-7任一项所述的方法,或者权利要求8-12任一项所述的方法。
技术总结
本申请提供一种应用程序更新方法、装置及设备,应用于终端设备,终端设备中安装有第一应用程序,所述方法包括:接收服务器发送的第一消息,第一消息用于指示第一应用程序的版本发生更新,第一消息包括第一应用程序的最新版本号;若确定未从服务器轮询获取到第一应用程序对应的更新文件,则根据第一消息从服务器获取更新文件;根据更新文件对第一应用程序进行更新。提高了对应用程序的更新时效性。提高了对应用程序的更新时效性。提高了对应用程序的更新时效性。
技术研发人员:覃啟东 王友葆 毛正卫 代巨鹏 孙士伍 刘晓 秦凯 张韶伟
受保护的技术使用者:阿里云计算有限公司
技术研发日:2023.05.10
技术公布日:2023/8/4
版权声明
本文仅代表作者观点,不代表航空之家立场。
本文系作者授权航家号发表,未经原创作者书面授权,任何单位或个人不得引用、复制、转载、摘编、链接或以其他任何方式复制发表。任何单位或个人在获得书面授权使用航空之家内容时,须注明作者及来源 “航空之家”。如非法使用航空之家的部分或全部内容的,航空之家将依法追究其法律责任。(航空之家官方QQ:2926969996)
飞行汽车 https://www.autovtol.com/
