一种小程序的更新方法、装置、设备和计算机可读介质
技术领域
本申请涉及计算机技术领域,尤其涉及一种小程序的更新方法、装置、设备及计算机可读介质。
背景技术
小程序(Mini Program),是一种不需要下载安装即可使用的应用程序。小程序的最大特点是使用便捷,无需手动在操作系统中安装,通常小程序依托于大型应用作为载体进行使用。对于用户来说,小程序能够节约使用时间成本和移动终端的存储空间;对于开发者来说,小程序能够节约开发和推广成本。因此,小程序作为大型互联网平台类产品的重要组成部分,未来将有较为广阔的发展前景。
小程序是依托于用户终端上安装的主应用程序来运行的独立程序,可以被便捷地获取和传播,为终端用户提供更好的用户体验。在小程序不断发展的基础上,小程序经常需要更新,以呈现给用户不同的数据内容或者越来越好的应用体验。
鉴于此,需要提供相应的小程序更新方案。
发明内容
有鉴于此,本申请实施例提供了一种小程序的更新方法、装置、设备及计算机可读介质,用于在满足小程序更新需求的同时节省用户流量、提升用户体验。
为解决上述技术问题,本说明书实施例是这样实现的:
本说明书实施例提供的一种小程序的更新方法,包括:获取对于小程序的启动指令;响应于所述启动指令,显示所述小程序的页面;获取第一当前时间;判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期,得到第一判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第一当前时间的时间间隔;若所述第一判断结果为是,则下载所述小程序的更新文件包,以用于下次启动小程序时对所述小程序进行更新。
本说明书实施例提供的一种小程序的更新装置,包括:指令获取模块,用于获取对于小程序的启动指令;页面显示模块,用于响应于所述启动指令,显示所述小程序的页面;时间获取模块,用于获取第一当前时间;判断模块,用于判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期,得到第一判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第一当前时间的时间间隔;下载模块,用于若所述第一判断结果为是,则下载所述小程序的更新文件包,以用于下次启动小程序时对所述小程序进行更新。
本说明书实施例提供的一种电子设备,包括:
至少一个处理器;以及,
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够:
获取对于小程序的启动指令;响应于所述启动指令,显示所述小程序的页面;获取第一当前时间;判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期,得到第一判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第一当前时间的时间间隔;若所述第一判断结果为是,则下载所述小程序的更新文件包,以用于下次启动小程序时对所述小程序进行更新。
本说明书实施例提供的一种计算机可读介质,其上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现前述任一实施例所述的小程序的更新方法。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果:
提供了一种小程序的更新方法,具体地,获取用户指示打开小程序页面的指令后,先向用户提供该小程序的页面,然后判断小程序的文件包的更新时间间隔是否超过了预设更新周期,在超过的情况下,下载小程序的文件包,以用于下次启动小程序时对所述小程序进行更新。该方案中,由于先向用户提供小程序页面,再进行异步更新,用户无需等待小程序更新的过程,用户体验好。此外,只有当小程序的实际更新时间间隔大于预设周期的时候,才会查询和下载更新的小程序的文件包,若不大于,则不去查询和下载。即,不是每次打开小程序都发出网络请求查询是否需要更新,可以为用户节省流量。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本说明书实施例提供的一种小程序的更新方法的流程示意图;
图2示出了本说明书实施例提供的一种基于异步更新的小程序的更新方法的流程示意图;
图3示出了本说明书实施例提供的一种异步更新与同步更新相结合的小程序的更新方法的流程示意图;
图4为本说明书实施例提供的对应于图1的一种小程序的更新装置的结构示意图;
图5为本说明书实施例提供的对应于图2的一种电子设备的结构示意图。
具体实施方式
基于各种实际需求,例如为了给用户呈现不同的数据内容或者给用户提供越来越好的使用体验,经常需要对小程序进行更新。
一种更新小程序的方法是,在每次启动主应用程序时,通过网络请求查询并下载新版本的小程序离线包,如此,在网络情况正常的条件下,每次应用启动都能获取到最新版本的小程序包。然而,由于应用程序启动时,需要做很多初始化的工作,如果在此时发起应用程序中相关小程序更新的网络请求并触发多个下载任务,影响应用程序的启动效率,对应用程序的启动性能是一个较大的挑战;并且,通常,应用程序启动的频次较多,而小程序更新的频率并不会如此频繁,如果每次启动应用程序都通过网络请求查询并下载新版本的小程序离线包,这会导致大量无用的网络请求,消耗用户的流量。
另一种更新小程序的方法是,在每次启动小程序时,通过网络请求查询并下载新版本的小程序离线包。然而,由于小程序的更新频次并不会如小程序的启动频次那么高,每次启动小程序时都发送网络请求查询是否有最新版本,会消耗大量无效流量,尤其是该小程序的使用频率较高的情况下,将会有大量无效的网络请求发出,消耗用户大量流量;并且,如果查询到有新版本的小程序包,会通过网络下载最新版本的小程序包,此时会让用户等待小程序的下载过程,即小程序每次的更新,都会让用户等待一段时间,用户体验较差。
鉴于现有技术中存在的上述问题,由于启动主应用程序时查询所有的小程序包是否有更新会导致主应用程序的启动性能变差,所以在本申请的实施例中在启动小程序本身时进行查询;而如果每次启动小程序时都进行查询,则会消耗大量用户流量,且影响用户使用小程序的体验,为此,在本申请的实施例中,引入了小程序更新周期的概念,只有当达到一定的更新周期之后,才会发起查询,由此在一定程度上节省了用户流量;此外,本申请的实施例可以在打开小程序的同时在后台进行异步更新,使得小程序的更新不会增加用户的等待时间,提升用户的使用体验。
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1为本说明书实施例提供的一种小程序的更新方法的流程示意图。从程序角度而言,流程的执行主体可以为搭载于应用客户端的程序,具体地,可以为主应用程序,即,可以为小程序的宿主应用程序。
如图1所示,该流程可以包括以下步骤:
步骤102:获取对于小程序的启动指令。
其中,小程序是在主应用程序中运行的微应用,具有独立的运行逻辑,由一系列可执行的代码和资源组成。主应用程序是部署在用户终端中的应用程序,也可称为小程序的宿主程序。用户终端可以包括智能手机、平板电脑、个人电脑、台式机、一体机、智能手表、智能机器人等任何类型的终端设备。
所述对于小程序的启动指令可以是,基于用户对用于显示小程序页面的控件的触发操作而生成的指令。所述用于显示小程序页面的控件可以包括小程序的图标、小程序的分享链接等,不限于此。所述小程序页面可以是小程序中的任意页面,包括起始页面或其他页面。
作为示例,用户可以通过点击小程序的图标来启动小程序,也可以通过点击被分享的小程序中的任意页面的链接来启动小程序,还可以通过扫描图形码(例如,二维码或条形码等)来打开小程序,用户启动小程序的方法和应用场景不限于此。
步骤104:响应于所述启动指令,显示所述小程序的页面。
具体地,显示的所述小程序的该页面,是与小程序的所述打开指令相对应的页面。作为示例,若基于用户对小程序的图标的操作生成对于小程序的启动指令,则向用户显示小程序的起始页面;若基于用户对小程序的分享链接的图标的操作生成对于小程序的打开指令,可以向用户显示小程序的起始页面或被分享的页面。
步骤106:获取第一当前时间。
在本申请的说明书中,使用了术语第一、第二等来描述各种周期、结果、时间等,但是这些周期、结果、时间不应受这些术语的限制。这些术语用来将一个周期、结果、时间与另一周期、结果、时间区分开。
具体地,所述获取第一当前时间可以是获取用户终端当前的系统时间。
步骤108:判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期,得到第一判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第一当前时间的时间间隔。
其中,所述小程序的文件包的更新时间间隔指的是用户终端当前存储的小程序文件包对应的时间戳与用户终端的当前时间的时间间隔。其中,当前存储的小程序文件包对应的时间戳表示该当前存储的小程序的更新时间,也就是所述小程序对应的文件包的最后一次更新的时间。
步骤108之前,还可以包括:获取所述小程序的文件包对应的时间戳;计算所述时间戳与所述第一当前时间之间的差值,作为所述小程序的文件包的更新时间间隔。其中,所述第一当前时间指的是执行计算更新时间间隔这一步骤之前,获取的用户终端的系统时间。所述更新时间间隔可以用于表征当前使用的小程序的文件包有多长的时间未进行更新,从而,可以根据该更新时间间隔是否超过预设的阈值(即,第一预设更新周期),来决定是否要对小程序进行更新。
在该方案中,无论是否进行小程序的更新,均会先为用户打开小程序,即向用户展示小程序的页面。在实际应用中,可以在向用户展示小程序页面的同时,在后台通过另外的线程来异步执行所述判断步骤以及后续的更新步骤,由此,该第一预设更新周期,又可以称为异步更新周期,图1中的对小程序进行更新的方案,又可以称为异步更新方案。
例如,可以设置异步更新周期为30分钟,若距离上次更新超过30分钟之后,超过了异步更新周期,此时打开小程序,便会发起异步更新请求(步骤110)。
步骤110:若所述第一判断结果为是,则下载所述小程序的更新文件包,以用于下次启动小程序时对所述小程序进行更新。
基于步骤108中的判断操作,若所述第一判断结果表示所述小程序的文件包的更新时间间隔大于第一预设更新周期,即,更新时间间隔大于预设阈值,则下载新的文件包,对现存的文件包进行更新。对小程序的文件包进行更新后,当下次接收到用户的启动小程序的指令时,则可以基于更新后的小程序文件包来向用户展示小程序的页面。
基于步骤108中的判断操作,若所述第一判断结果表示所述小程序的文件包的更新时间间隔等于或小于第一预设更新周期,即,更新时间间隔等于或小于预设阈值,则不去下载新的文件包,也不对现存的文件包进行更新。
在实际应用中,可以将小程序业务代码构建为压缩包存放于内容分发网络(Content Delivery Network,CDN)上,用户终端的小程序容器可以通过网络请求下载该压缩包并存储到本地。在本申请的实施例中,小程序的更新指的是对小程序的一系列可执行的代码和资源包的更新,即,对小程序的文件包的更新,在下文中,也称为对小程序包的更新。
图1中提供的一种小程序的更新方法,获取用户指示打开小程序页面的指令后,先向用户提供该小程序页面,然后判断小程序的文件包的更新时间间隔是否超过了预设更新周期,在超过的情况下,下载小程序的文件包,以用于下次启动小程序时对所述小程序进行更新。
在图1的方案中,首先,在启动小程序时而非启动主应用程序时触发对小程序的更新,不会影响应用程序的启动性能。并且,由于响应于用户指令便直接向用户提供小程序页面,用户本次打开小程序时使用的文件包是上次更新的文件包,本次更新的小程序文件包(如果进行更新)则用于下次启动小程序时对所述小程序进行更新,使得,用户每次启动小程序时,无需等待对小程序的新版本进行查询和更新小程序的过程,用户体验好。再者,只有当小程序的实际更新时间间隔大于预设周期的时候,才会查询(和下载)小程序的更新的文件包,而不是每次打开小程序都发出网络请求查询是否有更新的文件包,使得,在确保用户使用到较新版本的前提下,可以为用户节省流量,尤其是,当用户打开小程序的频次较高时,为用户节省流量的效果就更加显著。
应当理解,本说明书一个或多个实施例所述的方法其中部分步骤的顺序可以根据实际需要相互交换,或者其中的部分步骤也可以省略或删除。
基于图1的方法,本说明书实施例还提供了该方法的一些具体实施方案,下面进行说明。
在步骤110中,若所述第一判断结果为是,则下载所述小程序的更新文件包,具体可以包括:若所述第一判断结果为是,则获取所述小程序的最新版本信息;判断所述小程序的当前版本信息与所述最新版本信息是否一致,得到第二判断结果;若所述第二判断结果为否,则下载所述最新版本的所述小程序的文件包。
在上述实施例中,得到第一判断结果之前,不会发送网络请求来查询是否有新版本的小程序包信息。只有当小程序的文件包的更新时间间隔大于第一预设更新周期的情况下,才会发送网络请求获取小程序包的最新版本信息,而不是每次启动小程序都查询是否有最新版本的小程序包,这减少了用户的流量消耗。
在上述实施例中,判断所述小程序的当前版本信息与所述最新版本信息是否一致,具体可以是判断小程序的文件包的最新版本是否新于当前版本,若最新版本新于当前版本,则下载最新版本的文件包;否则,不下载,流程结束。
可选地,若所述第一判断结果为是,还可以获取所述最新版本的所述小程序的文件包的下载地址信息。例如,上述在获取所述小程序的最新版本信息的同时,也可以获取所述小程序的文件包的下载地址信息。相应地,所述若所述第二判断结果为否,则下载所述最新版本的所述小程序的文件包,具体可以包括:若所述第二判断结果为否,则根据所述下载地址信息,下载所述最新版本的所述小程序的文件包。若所述第四判断结果为是,说明在用户未打开小程序的这段时间内,服务端的小程序未被更新,则流程结束。
在该实施例中,当获取小程序包的最新版本信息的同时,可以获取该最新版本小程序包的下载地址信息,例如,该小程序包在CDN上的具体位置信息,以便于后续根据该获取的下载地址信息来下载小程序包。
在上述获取所述小程序的最新版本信息之后,还可以包括:根据获取到最新版本信息后的时间对所述小程序的文件包对应的时间戳进行更新。在实际应用中,当访问服务器并获取到最新版本信息之后,无论该实际获取的最新版本信息是否新于当前的本地版本,即,无论是否后续下载新版本的小程序文件包(如果有新版本,则下载;如果没有新版本,则不下载),都可以对本地的小程序文件包对应的时间戳进行更新。由此,该时间戳意味着最新一次对小程序新版本进行查询的时间,因此,基于时间戳计算得到的时间间隔,表示的是距离上次进行最新版本查询的时间间隔。
在本申请的实施例中,由于在判断了时间间隔超出更新周期之后,获取最新版本信息,进而更新时间戳信息,也就是说,并不是每次打开小程序都发出网络请求来查询是否有最新版本信息并更新时间戳信息,由此,节省了用户流量。换句话说,无论后续是否有新版本的小程序,无论是否触发后续的下载步骤,本申请的实施例均可以实现节省用户流量的技术效果。
在步骤108之前,还可以包括:从后端获取所述小程序的第一预设更新周期。其中,所述第一预设更新周期是可以是由小程序的维护人员设定的。例如,可以从小程序的服务器或小程序商业化服务平台(例如,SaaS平台)来获取由小程序维护人员动态配置的第一预设更新周期。
也就是说,可以通过动态配置服务下发动态配置数据,以动态地控制预设更新周期,从而在策略上做调整。由此使得,可以根据小程序开发者更新小程序版本的实际频次来动态调控预设更新周期。在一些情况下,若小程序版本的实际更新频次需要降低,则可以将预设更新周期设置为更大,从而,可以降低用户频繁发送针对新版本小程序包的网络查询请求的流量消耗。在一些情况下,若小程序版本的实际更新频次需要升高,则可以将预设更新周期设置为更小,从而,可以使用户能够及时地使用到较新版本的小程序,提升用户体验。可以动态配置的更新周期包括上文中的第一预设更新周期以及下文中的第二预设更新周期。
基于前述描述的具体实施方案,图2示出了本说明书实施例提供的一种基于异步更新的小程序的更新方法的流程示意图。
如图2中所示,包括以下步骤。
步骤200:用户终端接收用户的用于打开小程序的指令;
步骤202:打开小程序,即,向用户展示小程序页面;
步骤204:查询上次更新小程序的时间;
步骤206:获取异步更新周期,并将上次更新小程序的时间与当前时间进行比较;
步骤208:判断当前距离上次更新小程序的时间间隔是否超过所述异步更新周期;若是,继续步骤210,若否,流程结束;
步骤210:异步查询并获取最新的小程序信息,例如,小程序版本信息,小程序下载地址信息;
步骤212:更新本地的小程序时间信息;
步骤214:根据查询结果,判断是否有新版本的小程序;若是,继续步骤216;若否,流程结束;
步骤216:下载新版本的小程序。
本申请实施例的引入异步更新机制的小程序更新方案中,当客户端本地已经存在小程序包时,能够尽快打开小程序,避免用户等待的时间过长。当启动小程序时,如果达到异步更新周期,则在打开本地已经存在的小程序包的同时,开启后台异步任务查询是否有新版本的小程序包,如果存在新版本,则异步下载新的离线包。
本申请的实施例的方案,解决了现有技术中小程序更新影响应用启动性能的技术问题,以及小程序更新对用户流量消耗过多、使用户等待导致用户体验较差等技术问题。具体地,在启动小程序时查询该小程序的版本信息,避免了影响主应用程序的启动性能;通过异步更新机制,降低了查询频率,节省了用户流量,提升了用户体验。上述实施例的方案,在用户打开小程序的频率较高的情况下,对于用户流量节省的技术效果、以及对用户使用体验提升的技术效果,将表现的更加突出。
在实际应用中,如果一个小程序的打开频率非常低,那么,用户再次打开小程序的时候,为了避免用户仍然使用过低版本的小程序,本申请的实施例又引入了同步更新机制,将其与异步更新机制相结合,使得,在节省用户流量、提升用户体验的同时,又能保证用户始终使用到较新版本的小程序。下面进行具体说明。
在上述实施例的基础上,可选地,在所述步骤104之前,还可以包括:获取第三当前时间;判断所述小程序的文件包的更新时间间隔是否大于第二预设更新周期,得到第三判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第三当前时间的时间间隔;若所述第三判断结果为是,则下载所述小程序的更新文件包,并根据所述更新文件包显示所述小程序的页面,流程结束。相应地,步骤104具体可以包括:若所述第三判断结果为否,则响应于所述启动指令,显示所述小程序的页面,流程继续。
其中,所述第二预设更新周期即同步更新周期,所述第二预设更新周期大于所述第一预设更新周期,即,同步更新周期大于异步更新周期。作为示例,同步更新周期可以为例如7天,异步更新周期可以为例如1小时。
在该方案中,在向用户显示小程序的页面之前,需要判断小程序的文件包的更新时间间隔是否大于同步更新周期,若判断结果表示更新时间间隔超过同步更新周期,则表示当前的小程序包较长时间未进行更新,需要先进行更新再向用户展示。
在实际应用中,当第三判断结果为是的情况下,执行同步更新方案,而无需再执行步骤106至110;当第三判断结果为否的情况下,继续步骤106至110,执行异步更新方案。
根据该实施例的方案,当用户打开小程序时,如果距离上次更新小程序数据的时间周期超过同步更新周期,例如超过7天,则发起同步更新请求查询是否有新的小程序版本,如果有新的版本,则同步下载小程序包并打开。如此,能够保证如果用户长时间未打开某个小程序,再次打开时也能体验到最新的版本,保障用户体验。
当用户打开小程序时,如果距离上次更新小程序数据的时间周期未超过同步更新周期,例如未超过7天,则先为用户打开小程序,与此同时,如果距离上次更新小程序数据的时间周期超过异步更新周期,例如,超过30分钟,则发起异步更新请求查询是否有新的小程序版本,如果有新的版本,则异步下载小程序包,以供下次打开小程序时使用。如此,在确保用户能够体验到较新版本的小程序的同时,能够为用户减少无效的网络访问流量,且减少用户等待小程序更新的时间,整体可以提升用户的使用体验。
在上述实施例中,所述判断所述小程序的文件包的更新时间间隔是否大于第二预设更新周期之前,还可以包括:获取所述小程序的文件包对应的时间戳;计算所述时间戳与所述第三当前时间之间的差值,作为所述小程序的文件包的更新时间间隔。其中,所述第三时间指的是执行计算所述时间戳与所述第三当前时间之间的差值这一步骤前,获取的用户终端的系统时间。
在上述实施例中,所述判断所述小程序的文件包的更新时间间隔是否大于第二预设更新周期之前,还可以包括:从后端获取所述小程序的第二预设更新周期,其中,所述第二预设更新周期可以是由小程序的维护人员设定的。例如,可以从小程序的服务器或小程序商业化服务平台(例如,SaaS平台)来获取由小程序的维护人员动态配置的所述第二预设更新周期。
在上述实施例中,所述若所述第三判断结果为是,则下载所述小程序的更新文件包,具体可以包括:若所述第三判断结果为是,则获取所述小程序的最新版本信息;判断所述小程序的当前版本信息与所述最新版本信息是否一致,得到第四判断结果;若所述第四判断结果为否,则下载所述最新版本的所述小程序的文件包。若所述第四判断结果为是,说明在用户未打开小程序的这段时间内,服务端的小程序未被更新,则直接打开小程序。
可选地,所述若所述第三判断结果为是,还可以获取所述最新版本的所述小程序的文件包的下载地址信息。即,在获取所述小程序的最新版本信息时,也可以获取所述最新版本的所述小程序的文件包的下载地址信息。所述下载地址信息可以与所述小程序的最新版本信息一同被反馈至终端设备。相应地,所述若所述第四判断结果为否,则下载所述最新版本的所述小程序的文件包,具体可以包括:若所述第四判断结果为否,则根据所述下载地址信息,下载所述最新版本的所述小程序的文件包。
在上述获取所述小程序的最新版本信息之后,还可以包括:根据获取到最新版本信息后的时间对所述小程序的文件包对应的时间戳进行更新。在实际应用中,当访问服务器并获取到最新版本信息之后,无论该实际获取的最新版本信息是否新于当前的本地版本,即,无论是否后续下载新版本的小程序文件包(如果有新版本,则下载;如果没有新版本,则不下载),都可以对本地的小程序文件包对应的时间戳进行更新。由此,该时间戳意味着最新一次对小程序新版本进行查询的时间,因此,基于时间戳计算得到的时间间隔,表示的是距离上次进行最新版本查询的时间间隔。
在本申请的实施例中,由于在判断了时间间隔超出更新周期之后,获取最新版本信息,进而更新时间戳信息,也就是说,并不是每次打开小程序都发出网络请求来查询是否有最新版本信息并更新时间戳信息,由此,节省了用户流量。换句话说,无论后续是否有新版本的小程序,无论是否触发后续的下载步骤,本申请的实施例均可以实现节省用户流量的技术效果。
基于前述描述的具体实施方案,图3示出了本说明书实施例提供的一种异步更新与同步更新相结合的小程序的更新方法的流程示意图。
如图3所示,可以包括以下步骤。
步骤300:用户终端接收用户的用于打开小程序的指令;
302:查询上次更新小程序的时间;
304:获取同步更新周期,并将上次更新小程序的时间与当前时间比较;
306:判断当前距离上次更新小程序的时间间隔是否超过所述同步更新周期(得到上文所述的第三判断结果);若是,继续步骤308;若否,跳至步骤316;
308:同步查询并获取最新的小程序信息,例如,小程序版本信息,小程序下载地址信息;
310:更新本地存储的小程序时间信息;
312:根据查询结果,判断是否有新版本的小程序,若是,继续步骤314;若否,跳至步骤316;
314:下载新版本的小程序;
316:打开小程序,即,向用户展示小程序页面;
318:获取异步更新周期,并将上次更新小程序的时间与当前时间比较;
320:判断当前距离上次更新小程序的时间间隔是否超过所述异步更新周期(得到上文所述的第一判断结果);若是,继续步骤322;若否,流程结束;
322:异步查询并获取最新的小程序信息,例如,小程序版本信息,小程序下载地址信息;
324:更新本地的小程序时间信息;
326:根据查询结果,判断是否有新版本的小程序;若是,继续步骤328;若否,流程结束;
328:下载新版本的小程序。
根据上述实施例,在实际应用中,若实际的更新时间间隔大于预设的同步更新周期,则先更新小程序再向用户展示;若实际的更新时间间隔不大于预设的同步更新周期,但是大于预设的异步更新周期,则先向用户展示再异步更新小程序;若实际的更新时间间隔不大于异步更新周期,则只执行向用户展示而不进行小程序更新。在实际使用中,用户基本不需要同步等待下载,除非遇到长时间不打开小程序才会触发同步等待。
在本申请提供的技术方案中,引入了更新周期的概念,只有达到一定的更新周期之后,才进行查询,即,按需进行查询,减少了大量无效的查询,为用户节省了流量。具体地,提供了将异步更新与同步更新相结合的技术方案,通过同步更新机制确保了用户即便长时间未打开小程序也能够使用到最新版本的小程序,通过异步更新机制使得当客户端本地已经存在小程序包的时候,可以为用户尽快打开小程序,减少用户的等待时间,提升用户体验。异步更新及同步更新结合的模式,保障用户基本使用到最新的版本,同时又避免太频繁的同步网络请求导致用户需要同步等待以及消耗过多用户流量的情况。在实际应用中,无论用户打开小程序的频率高还是低,本申请的实施例的方案均能够综合地提升用户的使用体验。
此外,由于小程序开发人员可以根据实际上小程序的更新频次来动态地调整同步更新周期和异步更新周期,即,可以使得小程序的更新周期始终处于较优的值,能够最大化地优化上述方案的技术效果,即,能够进一步地确保用户能够用到较新版本的小程序,同时又能更大程度地节省用户流量,提升用户体验。具体地,通过动态配置下发的方式,可以动态控制小程序包的异步更新和同步更新的周期时长,可以根据小程序开发者的平均更新周期来制定合理的策略,进一步提升小程序包更新的精准性,进一步降低用户的流量消耗。
采用本申请中的实施例的方案,预期可以降低用户因查询小程序更新信息导致的流量消耗50%以上。采用异步更新和同步更新的机制,可以保证用户在体验到最新版本小程序的前提下,减少用户因同步更新而等待小程序包下载场景90%以上。
基于同样的思路,本说明书实施例还提供了上述方法对应的装置。图4为本说明书实施例提供的对应于图1的一种小程序的更新装置的结构示意图。
如图4所示,该装置可以包括:
指令获取模块402,用于获取对于小程序的启动指令;
页面显示模块404,用于响应于所述启动指令,显示所述小程序的页面;
时间获取模块406,用于获取第一当前时间;
判断模块408,用于判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期,得到第一判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第一当前时间的时间间隔;
下载模块410,用于若所述第一判断结果为是,则下载所述小程序的更新文件包,以用于下次启动小程序时对所述小程序进行更新。
根据实施例,所述装置还可以包括:更新时间间隔计算模块,用于在判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期之前,获取所述小程序的文件包对应的时间戳;计算所述时间戳与所述第一当前时间之间的差值,作为所述小程序的文件包的更新时间间隔。
根据实施例,所述装置还可以包括:预设更新周期获取模块,用于在判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期之前,获取所述小程序的第一预设更新周期,其中,所述第一预设更新周期是由小程序的维护人员设定的。
根据实施例,所述下载模块410,具体可以包括:
信息获取单元,可以用于若所述第一判断结果为是,则获取所述小程序的最新版本信息;
判断单元,可以用于判断所述小程序的当前版本信息与所述最新版本信息是否一致,得到第二判断结果;
下载单元,可以用于若所述第二判断结果为否,则下载所述最新版本的所述小程序的文件包。
其中,所述信息获取单元,还可以用于:若所述第一判断结果为是,则获取所述最新版本的所述小程序的文件包的下载地址信息。相应地,所述下载单元,具体可以用于:若所述第二判断结果为否,则根据所述下载地址信息,下载所述最新版本的所述小程序的文件包。
根据实施例,所述装置还可以包括时间更新模块,可以用于当获取所述小程序的最新版本信息之后,根据获取到最新版本信息后的时间对所述小程序的文件包对应的时间戳进行更新。
在可选的实施例中,所述时间获取模块406,还可以用于,获取第三当前时间;所述判断模块408,还可以用于,在显示所述小程序的页面之前,判断所述小程序的文件包的更新时间间隔是否大于第二预设更新周期,得到第三判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与第三当前时间的时间间隔。其中,所述第二预设更新周期大于所述第一预设更新周期。相应地,所述页面显示模块404,具体用于,若所述第三判断结果为是,则下载所述小程序的更新文件包,并根据所述更新文件包显示所述小程序的页面,流程结束;若所述第三判断结果为否,则响应于所述启动指令,显示所述小程序的页面,流程继续。
根据实施例,所述更新时间间隔计算模块,还可以用于,在判断所述小程序的文件包的更新时间间隔是否大于第二预设更新周期之前,获取所述小程序的文件包对应的时间戳;计算所述时间戳与所述第三当前时间之间的差值,作为所述小程序的文件包的更新时间间隔。
根据实施例,所述预设更新周期获取模块,还可以用于,在判断所述小程序的文件包的更新时间间隔是否大于第二预设更新周期之前,获取所述小程序的第二预设更新周期,其中,所述第二预设更新周期是由小程序的维护人员设定的。
根据实施例,所述下载模块410中:
所述信息获取单元,还可以用于,若所述第三判断结果为是,则获取所述小程序的最新版本信息;
所述判断单元,还可以用于,判断所述小程序的当前版本信息与所述最新版本信息是否一致,得到第四判断结果;
所述下载单元,还可以用于,若所述第四判断结果为否,则下载所述最新版本的所述小程序的文件包。
其中,所述信息获取单元,还可以用于:若所述第三判断结果为是,则获取所述最新版本的所述小程序的文件包的下载地址信息。相应地,所述下载单元,具体还可以用于:若所述第四判断结果为否,则根据所述下载地址信息,下载所述最新版本的所述小程序的文件包。
根据实施例,所述时间更新模块,还可以用于,当获取所述小程序的最新版本信息之后,根据获取到最新版本信息后的时间对所述小程序的文件包对应的时间戳进行更新。
可以理解,上述的各模块是指计算机程序或者程序段,用于执行某一项或多项特定的功能。此外,上述各模块的区分并不代表实际的程序代码也必须是分开的。
基于同样的思路,本说明书实施例还提供了上述方法对应的设备。
图5为本说明书实施例提供的对应于图2的一种电子设备的结构示意图。如图5所示,设备500可以包括:
至少一个处理器510;以及,
与所述至少一个处理器通信连接的存储器530;其中,
所述存储器530存储有可被所述至少一个处理器510执行的指令520,所述指令被所述至少一个处理器510执行,以使所述至少一个处理器510能够:
获取对于小程序的启动指令;
响应于所述启动指令,显示所述小程序的页面;
获取第一当前时间;
判断所述小程序的文件包的更新时间间隔是否大于第一预设更新周期,得到第一判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第一当前时间的时间间隔;
若所述第一判断结果为是,则下载所述小程序的更新文件包,以用于下次启动小程序时对所述小程序进行更新。
可选地,所述显示所述小程序的页面之前,还可以包括:
获取第三当前时间;
判断所述小程序的文件包的更新时间间隔是否大于第二预设更新周期,得到第三判断结果,其中,所述更新时间间隔表示所述小程序的文件包对应的时间戳与所述第三当前时间的时间间隔;
若所述第三判断结果为是,则下载所述小程序的更新文件包,并根据所述更新文件包显示所述小程序的页面,流程结束;
所述响应于所述启动指令,显示所述小程序的页面,具体可以包括:
若所述第三判断结果为否,则响应于所述启动指令,显示所述小程序的页面,流程继续。
基于同样的思路,本说明书实施例还提供了上述方法对应的一种计算机可读介质,其上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现上面任一实施例中所述的小程序的更新方法。
上述对本说明书特定实施例进行了描述,在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置、设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书实施例提供的装置、设备与方法是对应的,因此,装置、设备也具有与对应方法类似的有益技术效果,由于上面已经对方法的有益技术效果进行了详细说明,因此,这里不再赘述对应装置、设备的有益技术效果。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带式磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。