更新手机软件、获取补丁文件的方法及设备与流程

文档序号:12463387阅读:367来源:国知局
更新手机软件、获取补丁文件的方法及设备与流程

本发明涉及通讯领域,特别是涉及一种更新手机软件、获取补丁文件的方法及设备。



背景技术:

目前市面上的各种APP(手机软件)或多或少都会遇到线上版本有重大bug(漏洞)的情况。有时我们的bug修复需要更新程序,但在苹果商店中发布新版本的时间是很长的,因此,我们需要有一套可利用的机制,以便在不发版的情况下就能修复线上的bug。

大多数开发者的做法是使用热修复技术,也就是在APP刚一启动的时候去下载一段修复脚本,利用Objective-C的动态特性将有问题的代码替换掉,从而使APP能够正常运行,其技术细节如下:

(1)如果APP存在bug,则开发者把正确的代码作为补丁文件上传到APP对应的服务器。当前主流的补丁文件,一种是JSPatch,一种是lua脚本。

(2)当APP启动时,首先加载本地已经下载了的补丁文件,APP把补丁文件中的代码解析出来,利用IOS系统专用语言objective-c的动态性和运行时机制,替换APP包中旧的错误代码。

(3)APP启动时,同时发送接口请求,询问服务器是否有新的补丁文件,如果有,则下载这个补丁文件到本地。此时,APP处于等待状态,同时APP继续执行启动流程,以开启APP进行使用。

当APP等到第(3)步下载完成补丁文件后,在下一次重新启动该APP时,会向步骤(2)的过程一样,重新去加载新的补丁文件。

上述过程中,由于APP启动时已经加载了已下载的补丁文件,因此,当APP执行到出现bug的页面时,会执行被替换后的正确代码,而非有问题的旧代码,因此,通过以上方法,不需要发版,就可实现修复线上APP的bug。

然而,如果当前APP的bug发生在启动过程中,导致来不及下载服务器上新的补丁文件,在刚启动的过程中就会crash(崩溃),则当前APP的bug将得不到修复,将会一启动就crash,用户将无法使用当前APP,必须等到重新发版才可以使用,用户体验较低。



技术实现要素:

本发明提供一种更新手机软件、获取补丁文件的方法及设备,用以解决现有技术的如下问题:如果当前APP的bug发生在启动过程中,会导致来不及下载服务器上新的补丁文件,在刚启动的过程中APP就会crash,用户将无法使用当前APP,必须等到重新发版才可以使用,用户体验较低。

为解决上述技术问题,一方面,本发明提供一种更新手机软件的方法,包括:移动终端接收来自IOS推送服务器的静默消息,其中,所述静默消息携带有预定APP补丁文件的补丁ID;所述移动终端根据所述补丁ID向所述预定APP对应的服务器下载所述预定APP的补丁文件;当所述预定APP被启动时,所述移动终端加载所述补丁文件,以更新所述预定APP。

可选的,所述移动终端加载所述补丁文件,包括:所述移动终端检测内存中是否存在已下载的补丁文件;在存在所述已下载的补丁文件的情况下,所述移动终端加载所述补丁文件。

可选的,所述移动终端加载所述补丁文件,包括:所述移动终端检测所述已下载的补丁文件的数量是否大于一个;在所述已下载的补丁文件的数量大于一个的情况下,加载时间上距离所述预定APP开启时间最近的补丁文件。

另一方面,本发明还提供一种发送手机软件补丁文件的方法,包括:APP服务器接收来自移动终端的下载请求,其中,所述下载请求携带有请求下载所述APP的补丁文件的补丁ID,所述补丁ID为所述移动终端根据静默消息得到的;所述APP服务器根据所述补丁ID在补丁文件库中查找对应的补丁文件,并将查找到的补丁文件发送至所述移动终端。

可选的,APP服务器接收来自移动终端的下载请求之前,还包括:所述APP服务器存储来自开发者平台的补丁文件,并为所述补丁文件生成对应的补丁ID;所述APP服务器将所述补丁ID发送至所述开发者平台,以通过所述开发者平台将所述补丁ID上传至IOS推送服务器。

另一方面,本发明还提供一种移动终端,包括:消息接收模块,用于接收来自IOS推送服务器的静默消息,其中,所述静默消息携带有预定APP补丁文件的补丁ID;下载模块,用哟根据所述补丁ID向所述预定APP对应的服务器下载所述预定APP的补丁文件;更新模块,用于当所述预定APP被启动时,所述移动终端加载所述补丁文件,以更新所述预定APP。

可选的,所述更新模块包括:第一检测单元,用于检测内存中是否存在已下载的补丁文件;第一加载单元,用于在存在所述已下载的补丁文件的情况下,加载所述补丁文件。

可选的,所述更新模块包括:第二检测单元,用于检测所述已下载的补丁文件的数量是否大于一个;第二加载单元,用于在所述已下载的补丁文件的数量大于一个的情况下,加载时间上距离所述预定APP开启时间最近的补丁文件。

另一方面,本发明还提供一种手机软件服务器,包括:请求接收模块,用于接收来自移动终端的下载请求,其中,所述下载请求携带有请求下载APP的补丁文件的补丁ID,所述补丁ID为所述移动终端根据静默消息得到的;查找模块,用于根据所述补丁ID在补丁文件库中查找对应的补丁文件;第一发送模块,用于将查找到的补丁文件发送至所述移动终端。

可选的,还包括:生成模块,用于存储来自开发者平台的补丁文件,并为所述补丁文件生成对应的补丁ID;第二发送模块,用于将所述补丁ID发送至所述开发者平台,以通过所述开发者平台将所述补丁ID上传至IOS推送服务器。

本发明移动终端通过IOS推送服务器接收静默消息,该静默消息与普通静默消息不同,其携带了预定APP需要下载补丁文件的补丁ID,移动终端可以在后台激活该预定APP,以根据补丁ID来在后台就下载好补丁文件,当预定APP被启动时,就可以直接加载补丁文件了,整个过程中,在用户毫无察觉的情况下就能够完成软件更新,在APP完全启动前就修复好各种bug,APP不会遇到crash风险,系统性能整体提高,用户体验也较好,解决了现有技术的如下问题:如果当前APP的bug发生在启动过程中,会导致来不及下载服务器上新的补丁文件,在刚启动的过程中APP就会crash,用户将无法使用当前APP,必须等到重新发版才可以使用,用户体验较低。

附图说明

图1是本发明第一实施例中更新手机软件的方法的流程图;

图2是本发明第二实施例中发送手机软件补丁文件的方法的流程图;

图3是本发明第三实施例中移动终端的结构示意图;

图4是本发明第四实施例中手机软件服务器的结构示意图;

图5是本发明第四实施例中手机软件服务器的优选结构示意图;

图6是本发明第五实施例中移动终端修复app中的bug的方法的流程图。

具体实施方式

为了解决现有技术的如下问题:如果当前APP的bug发生在启动过程中,会导致来不及下载服务器上新的补丁文件,在刚启动的过程中APP就会crash,用户将无法使用当前APP,必须等到重新发版才可以使用,用户体验较低;本发明提供了一种更新手机软件、获取补丁文件的方法及设备,以下结合附图以及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不限定本发明。

本发明第一实施例提供了一种更新手机软件的方法,该方法的流程如图1所示,包括步骤S102至S106:

S102,移动终端接收来自IOS推送服务器的静默消息,其中,静默消息携带有预定APP补丁文件的补丁ID;

S104,移动终端根据补丁ID向预定APP对应的服务器下载预定APP的补丁文件;

S106,当预定APP被启动时,移动终端加载补丁文件,以更新预定APP。

本发明实施例移动终端通过IOS推送服务器接收静默消息,该静默消息与普通静默消息不同,其携带了预定APP需要下载补丁文件的补丁ID,移动终端可以在后台激活该预定APP,以根据补丁ID来在后台就下载好补丁文件,当预定APP被启动时,就可以直接加载补丁文件了,整个过程中,在用户毫无察觉的情况下就能够完成软件更新,在APP完全启动前就修复好各种bug,APP不会遇到crash风险,系统性能整体提高,用户体验也较好,解决了现有技术的如下问题:如果当前APP的bug发生在启动过程中,会导致来不及下载服务器上新的补丁文件,在刚启动的过程中APP就会crash,用户将无法使用当前APP,必须等到重新发版才可以使用,用户体验较低。

上述过程实现的过程中IOS推送服务器推送的静默消息中的补丁ID是开发者平台发送至IOS推送服务器。在开发者平台完成了补丁文件后,就可以将补丁文件发送至该预定APP对应的服务器,服务器为存储的补丁文件生成一个唯一的补丁ID,并将其返回至开发者平台。

开发者平台在接收到该补丁ID后,就可以将该补丁ID发送至IOS推送服务器,此时,IOS推送服务器在推送静默消息时,就可以将该补丁ID携带在静默消息中,并发送至移动终端。

当预定APP被启动时,移动终端检测内存中是否存在已下载的补丁文件;如果有补丁文件,则进一步检测已下载的补丁文件的数量是否大于一个;如果已下载的补丁文件的数量大于一个,则加载时间上距离预定APP开启时间最近的补丁文件,来完成预定APP的更新。

本发明第二实施例提供了一种发送手机软件补丁文件的方法,该方法的流程如图2所示,包括步骤S202至S204:

S202,APP服务器接收来自移动终端的下载请求,其中,

下载请求携带有请求下载APP的补丁文件的补丁ID,补丁ID为移动终端根据静默消息得到的;

S204,APP服务器根据补丁ID在补丁文件库中查找对应的补丁文件,

并将查找到的补丁文件发送至移动终端。

本发明实施例APP服务器可以是任意一个APP对应的服务器,

当某一个APP对应的服务器收到下载请求后,

就会根据下载请求中的补丁ID来下载对应的补丁文件,

并将该补丁文件发送到移动终端,

则移动终端就可以使用该补丁文件更新对应的APP了。

实现的过程中,在APP服务器接收来自移动终端的下载请求之前,APP服务器存储来自开发者平台的补丁文件,并为补丁文件生成对应的补丁ID;随后,APP服务器将补丁ID发送至开发者平台,以通过开发者平台将补丁ID上传至IOS推送服务器。这样,IOS推送服务器在推送静默消息时,会将携带补丁ID的静默消息发送至移动终端,以便移动终端更新APP使用。

本发明第三实施例还提供一种移动终端,该移动终端的结构示意如图3所示,包括:

消息接收模块10,用于接收来自IOS推送服务器的静默消息,其中,静默消息携带有预定手机软件APP补丁文件的补丁ID;下载模块11,与消息接收模块10耦合,用哟根据补丁ID向预定APP对应的服务器下载预定APP的补丁文件;更新模块12,与下载模块11耦合,用于当预定APP被启动时,移动终端加载补丁文件,以更新预定APP。

其中,上述更新模块12包括:第一检测单元,用于检测内存中是否存在已下载的补丁文件;第一加载单元,用于在存在已下载的补丁文件的情况下,加载补丁文件。

在实现过程中,上述更新模块12还可以包括:第二检测单元,用于检测已下载的补丁文件的数量是否大于一个;第二加载单元,用于在已下载的补丁文件的数量大于一个的情况下,加载时间上距离预定APP开启时间最近的补丁文件。

上述更新模块12如果同时具备第一检测单元、第一加载单元、第二检测单元和第二加载单元,则由于两个加载单元执行的都是相同的加载补丁文件的功能,因此,在设置时可以将两个加载单元合成为一个,即更新模块12包括第一检测单元、第二检测单元和加载单元,其中第一检测单元和第二检测单元连接,第二检测单元和加载单元连接。

本发明实施例提供的移动终端通过IOS推送服务器接收静默消息,该静默消息与普通静默消息不同,其携带了预定APP需要下载补丁文件的补丁ID,移动终端可以在后台激活该预定APP,以根据补丁ID来在后台就下载好补丁文件,当预定APP被启动时,就可以直接加载补丁文件了,整个过程中,在用户毫无察觉的情况下就能够完成软件更新,在APP完全启动前就修复好各种bug,APP不会遇到crash风险,系统性能整体提高,用户体验也较好。

本发明第四实施例提供了一种手机软件服务器,该服务器的结构示意如图4所示,包括:

请求接收模块20,用于接收来自移动终端的下载请求,其中,下载请求携带有请求下载APP的补丁文件的补丁ID,补丁ID为移动终端根据静默消息得到的;查找模块21,与请求接收模块20耦合,用于根据补丁ID在补丁文件库中查找对应的补丁文件;第一发送模块22,与查找模块21耦合,用于将查找到的补丁文件发送至移动终端。

实现的过程中,上述手机软件服务器还包括如图5所示的结构;其中,生成模块23,用于存储来自开发者平台的补丁文件,并为补丁文件生成对应的补丁ID;第二发送模块24,与生成模块23和请求接收模块20耦合,用于将补丁ID发送至开发者平台,以通过开发者平台将补丁ID上传至IOS推送服务器。

为了解决app在启动过程中发生crash,导致无法通过传统的热修复来解决bug的问题,本发明第五实施例提出了一种利用IOS提供的静默推送功能来修复app中的bug的方法。

在本实施例中,IOS提供的静默推送功能去激活App在后台下载补丁文件,并保存在本地。app启动时直接去加载这个补丁文件,来修复启动过程中的bug,这样APP在启动时就可以安全执行完成,不会发生crash。

在移动终端安装了支持静默推送的IOS系统版本的情况下,移动终端修复app中的bug的方法如下,其过程如图6所示,包括步骤S1至S6。

S1,app的开发者通过开发者平台修正出现bug的代码,把新的修复代码转换为JS或者lua语言实现,将其保存为补丁文件。

S2,app的开发者把以上补丁文件上传到app对应的服务器,并服务器针对该补丁文件生成一个对应的id。

S3,通过推送服务将一条特殊格式的携带补丁id的静默消息推送给移动终端(用户)。

S4,移动终端收到消息后在后台激活app,然后app在后台通过特定的接口去根据id到APP的服务器下载补丁文件,保存在本地的共享文件中。

S5,app再次启动时,判断本地有没有补丁文件,如果有补丁文件,则读取其中较新的一个,app把补丁文件中的代码解析出来,利用objective-c的动态性和运行时机制,替换app包中旧的错误代码。

S6,app继续执行启动过程,直到APP完全开启。即使原本启动过程存在bug会产生crash,但是上述S5已经替换了bug代码,所以这里不再有bug,bug得以修复。

本发明可以实现在App不启动的情况下将修复脚本下载到用户设备上,当App启动后,第一时间去获取脚本进行修复,可以解决在获取到修复脚本前,程序就崩溃的问题。

尽管为示例目的,已经公开了本发明的优选实施例,本领域的技术人员将意识到各种改进、增加和取代也是可能的,因此,本发明的范围应当不限于上述实施例。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1