CN111913730A - 用户无感的应用程序内更新方法及用户端、程序服务器 - Google Patents

Abstract

本发明属于软件工程技术领域，具体公开了一种用户无感的应用程序内更新方法，该方法在所述应用程序在线期间，直接更新用户端的内存，包括如下步骤：上传步骤，将修改过的代码以更新包的格式上传至一网络容器；通知步骤，支撑所述应用程序运行的程序服务器发出更新通知，并将所述网络容器的网络地址提供给所述用户端；获取步骤，所述用户端根据所述网络地址获取所述更新包；更新步骤，所述用户端解析所述更新包，并将解析后的文件加载到内存，覆盖内存中相应的内容。本发明的优点在于通过服务器端与用户端通信就解决了应用程序的更新问题，用户无感。

Description

用户无感的应用程序内更新方法及用户端、程序服务器

技术领域

本发明涉及软件工程技术领域，尤其涉及了一种用户无感的应用程序内更新方法及用 户端、程序服务器。

背景技术

无论是电脑端还是手机、平板，都可以运行品种繁多的应用程序。为了提供给用户更 好的使用体验，通常应用程序都需要进行更新。

而游戏作为应用程序中迭代速度最快的一个种类，总是会出现开发时未发现的漏洞以 及在游戏生存期间对业务逻辑的调整需求。当前业界对上述问题的处理方式主要包括：① 离线修复问题，即，重新发布新的应用程序安装包，通过运营渠道投放到市场，由用户主 动选择是否更新；②在线修复问题，即，等用户退出游戏再重新登录后，拉取修复代码更 新包。上述的第一种方案存在修复周期长，修复不完整问题，如果用户不主动去获取修复 后的应用程序，那么这些漏洞是没法修复的。也就是说，如果用户不知道已发布了应用程 序的更新包，那么更新就无法进行。而第二种方案存在玩家不重启游戏就无法修复的问题。 而事实上，尤其是手机或平板的用户，往往登录了一个账号后，就不再退出，会维持登录 状态很久很久，那么第二种修复方法也不能及时达到目的。

综上，现有的更新/修复方法都对用户有要求，需要用户的主动参与，在一定程度上对 用户的使用体验造成负面影响。

发明内容

为了解决上述缺陷，提高用户的使用感受，本发明提出了新的应用程序更新方法，该 方法不需要用户主动参与，在用户无感的情况下，静默升级/修复程序，且过程短暂，不需 要停止应用程序的使用，不影响用户使用应用程序。

本发明提供一种用户无感的应用程序内更新方法，在所述应用程序在线期间，直接更 新用户端的内存，包括如下步骤：

上传步骤，支撑所述应用程序运行的程序服务器将更新包上传至一网络容器；

通知步骤，所述程序服务器发出更新通知，并将所述网络容器的网络地址提供给所述 用户端；

获取步骤，所述用户端根据所述网络地址获取所述更新包；

更新步骤，所述用户端解析所述更新包，并将解析后的文件加载到内存，覆盖内存中 相应的内容。

上述的更新方法，其中，所述更新包包括以文本格式存储的代码，所述代码为通过改 写和/或复写方式修改的新的代码段；

所述改写包括：删除原代码段并重新输入新的代码段；

所述复写包括：保留原代码段并新增代码段，以修正所述原代码段中的偏差。

上述的更新方法，其中，所述上传步骤中，上传的所述更新包是全部代码或部分代码 段。

上述的更新方法，其中，所述网络容器包括下载服务器。

上述的更新方法，其中，所述通知步骤中包括：

广播步骤，所述程序服务器向在线用户广播所述更新通知及所述网络地址；或

强制更新步骤，对于离线后重新登录的用户，所述程序服务器强制用户端拉取所述更 新包；或

打时间戳步骤，所述程序服务器在发出所述更新通知时记录通知时间，当休眠用户发 出重连请求后，首先比较所述用户最近一次的登录时间和所述通知时间，若所述登陆时间 早于所述通知时间，则向所述用户发送所述更新通知及所述网络地址。

上述的更新方法，其中，所述获取步骤中包括退出机制，所述退出机制包括：预设一 超时时间，若所述用户端在所述超时时间内未能获得所述更新包，则退出，再次执行所述 获取步骤。

上述的更新方法，其中，所述获取步骤中包括退出机制，所述退出机制还包括：预设 一最大次数，若所述用户端连续获取所述更新包不成功超次数过所述最大次数，则退出更 新过程。

相应的，本发明还提出了一种客户端，所述用户端响应于一更新通知执行如下步骤：

获取步骤，根据所述更新通知提供的网络地址获取一更新包；

更新步骤，解析所述更新包，并将解析后的文件加载到内存，覆盖内存中相应的内容。

上述的用户端，其中，所述获取步骤中包括一退出机制，所述退出机制包括：预设一 超时时间，若所述用户端在所述超时时间内未能获得所述更新包，则退出，再次执行所述 获取步骤。

上述的用户端，其中，所述退出机制还包括：预设一最大次数，若所述用户端连续获 取所述更新包不成功次数超过所述最大次数，则退出更新过程。

相应的，本发明还提出了一种程序服务器，所述程序服务器响应于一修改过的代码执 行如下步骤：

上传步骤，将所述修改过的代码以更新包的格式上传至一网络容器；

通知步骤，发出更新通知，并提供所述网络容器的网络地址。

上述的程序服务器中，

对于在线用户，通过广播的方式通知所述更新通知及所述网络地址；

对于离线后重新登录的用户，直接强制拉取所述更新包；

对于休眠用户，所述程序服务器在发出所述更新通知时记录通知时间，当所述用户发 出重连请求后，首先比较所述用户最近一次的登录时间和所述通知时间，若所述登陆时间 早于所述通知时间，则向所述用户发送所述更新通知及所述网络地址，否则不通知。

相应的，本发明还提出了一种应用程序的支撑系统，包括如上所述的程序服务器和如 上所述的用户端，所述程序服务器向所述用户端提供更新包；所述用户端包括一代码解析 器，所述代码解析器对所述代码文本进行解析，并使用解析后的文件替换内存中相应的内 容，从而完成程序内更新

与现有技术相比，本发明在通过服务器端与用户端通信就解决了应用程序的更新问题。 以OSI的标准7层协议来分析，相当于在会话层就解决了程序更新的问题，不需要应用层 (用户)的参与，因此可以做到用户无感。其次，用户端获取的是更新包主要包括的内容 是文本文件，而一般来说，应用程序的文本部分至多是兆级(MB)的，因此，本发明中 需要传输和编译的文件很小，从而可进一步保证用户无感。此外，用户端用解析后的文件 直接覆盖内存中相应部分的内容，不需要像传统的升级方法那样重新启动应用程序，从另 一个层面保证了用户无感。

附图说明

图1是根据本发明一实施例的系统流程图；

图2是根据本发明中一个用户端实施例的流程图；

图3是根据本发明中一个程序服务器实施例的流程图。

具体实施方式

以下由特定的具体实施例说明本发明的实施方式，本领域技术人员可由本说明书所揭 示的内容轻易地了解本发明的其他优点及功效。虽然本发明的描述将结合较佳实施例一起 介绍，但这并不代表此发明的特征仅限于该实施方式。恰恰相反，结合实施方式作发明介 绍的目的是为了覆盖基于本发明的权利要求而有可能延伸出的其它选择或改造。为了提供 对本发明的深度了解，以下描述中将包含许多具体的细节。本发明也可以不使用这些细节 实施。此外，为了避免混乱或模糊本发明的重点，有些具体细节将在描述中被省略。需要 说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

应注意的是，在本说明书中，相似的标号和字母在下面的附图中表示类似项，因此， 一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释， 默认为同一定义。

本发明的核心思想在于，通过程序服务器和用户端在比较底层的通信协议层上静默完 成应用程序的升级/修复以达到使用户无感的效果。此外，采用在网络传输中只传输代码文 本、解析后的文件直接覆盖内存的手段，充分缩短更新/修复所占用的时间，减少CPU的 占用时间，可从另一个角度进一步强化“用户无感”。

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

本发明所提供的实施方式可以在移动终端、计算机终端或者类似的运算装置(如ECU (Electronic Control Unit，电子控制单元))、系统中执行。

以运行在系统为例，图1是本发明一实施例的流程图。图中示意了一种用户无感的应 用程序内更新方法，所述方法在应用程序在线期间，直接更新用户端的内存，包括如下步 骤：

上传步骤S1，支撑所述应用程序运行的程序服务器将修改过的代码以更新包的格式上 传至一网络容器；

通知步骤S2，所述程序服务器发出更新通知，并将所述网络容器的网络地址提供给所 述用户端；具体的，所述网络地址可以在与所述更新通知同步下发，也可以预先配置在用 户端的所述应用程序中。

获取步骤S3，所述用户端根据所述网络地址获取所述更新包；

更新步骤S4，所述用户端解析所述更新包，并将解析后的文件加载到内存，覆盖内存 中相应的内容。

所述更新包包括以文本格式存储的代码，所述代码为通过改写和/或复写方式修改的新 的代码段。多数情况下，修复或升级现有程序都只要修改程序中的某一段程序，这一段程 序一般为一个函数。当一函数与预期效果出入较大，或者逻辑变动较大时，可以采取改写 的方式，也就是删除原有的不符合预期的代码，重新写入新的代码。当一函数存在的问题 属于逻辑性的偏差，可通过补充计算的方式来修正，则可采取复写的方式，也就是不改动 原有的代码段，而在该代码段前后补充用于修正偏差的代码段。当然，上述的改写和复写 也可以同时运用在同一函数中。

一个应用程序中实现一功能的最小单元一般为函数，一个函数的文本通常只占用几百 到几千字节。在当今网络速度的前提下，传输一个函数所需要的时间基本可以忽略不计， 因此，本发明优选上传的代码为代码段，以函数为最小单位上传。当然，在时间可以接受 的前提下，上传全部代码也是可行的。

进一步的，所述网络容器用于暂存上传的代码文本，并提供网络地址，供用户端访问。 所述网络容器可以是支撑所述应用程序运行的程序服务器本身，也可以是第三方的服务器、 云端。考虑到可能存在的爆发式的访问，所述网络容器优选下载服务器，例如CDN(Content Delivery Network，内容分发网络)服务器。通过CDN服务器下载内容的稳定性和并发性 都非常高效，并且还可以拓展到其他文件(例如图像、声音文件)的更新。此外，CDN服 务器可以在不影响程序服务器业务的情况下，安全承载十万以上在线用户的瞬间同时请求， 为本发明提供了强有力的技术支持。

通知步骤S2由支撑所述应用程序运行的程序服务器实现，通知的对象是所有用户端。 在此过程中需要考虑三种用户：在线用户、休眠用户和离线用户。

在线用户指发出更新通知时保持TCP长连接的用户。对于这一类用户，可以直接通过广播的方式将更新通知发送到用户端，由用户端根据所述更新通知给出的网络地址向CDN服务器发起连接请求，而不必要求所述在线用户执行任何操作。

休眠用户是指发出更新通知时并没有退出应用程序，但是将该应用程序保持在后台， 并没有在操作该应用程序的用户。对于这一类用户，需要保证应用程序被切回活动状态时 可以快速重连，在用户无感的情况下完成更新，用户可直接继续操作应用程序。相比于在 线用户，休眠用户的数量更加庞大，程序服务器无法通过广播的方式一一通知。本发明提 出，通过打时间戳的方式来通知休眠后重新活跃的用户。即，程序服务器记录发出所述更 新通知的时间。当所述休眠用户重新连接服务器时，比较用户最近一次登录时间和所述时 间戳。若所述登录时间比较早，则说明用户没有收到过所述更新通知，程序服务器主动在 重连的回包中通知用户端，所述用户端根据所述更新通知给出的网络地址向CDN服务器 发起连接请求，继而完成更新。

离线用户是指发出更新通知时已经退出登录的用户。当离线用户再次登录时，也就是 当用户端与程序服务器重新建立连接时，程序服务器在建立连接阶段直接强制要求服务端 更新，以确保用户可以更新到最新版。

在线用户、休眠用户和离线用户之间存在相互转化的可能。

对在线用户而言，程序服务器发出广播通知后在线用户就已经更新了应用程序，但是， 此时的在线用户的登录时间明显是早于时间戳的。当在线用户转为休眠用户后，重新连接 程序服务器时，会获得一个新的登录时间，但也会触发一次重复的更新。因此，对所述在 线用户而言，存在重复更新一次的情况。但这一情况属于可以接受的范围。

离线用户重新登录后，立刻更新应用程序，并记录登录时间，成为在线用户。当该在 线用户将应用程序切换到后台，成为休眠用户后再重连时，所述登录时间必然晚于时间戳 的时间，因此不会重复更新。

获取步骤S3和更新步骤S4由用户端实现。所述用户端收到更新通知后，根据给出的 网络地址向CDN服务器发出连接请求。当请求获得允许后，可下载所述更新包，从而更新用户程序。

在请求连接的过程中，还包括一退出机制，以防止请求未通过，用户端死等的情况。 所述退出机制包括超时退出和超次退出。所述超时退出包括：预设一超时时间，若用户端 发出连接请求后，超过所述超时时间也没有收到CDN服务器的应答，则主动退出等待，重新发出连接请求。所述超次退出包括，预设一最大次数，若用户端连续3次超时退出， 则不再请求连接，而是直接退出更新过程，放弃本次更新。

图2所示为用户端的一个实施例。如图所示，用户端接收到更新通知后，首先向下载 服务器提出连接请求S31，以便后续获取文件；为了不出现死循环，用户端开启退出机制， 即执行超时判断步骤S32和超次判断步骤S33。超时判断步骤S32中设定超时时间为12s， 即当所述下载服务器超过12s无应答时，重新提出连接请求。同时，在超时判断步骤S32 的基础上叠加超次判断步骤S33，即，若连续3次超时，则认为下载服务器或者网络存在故障，退出更新，后续根据其他指令再次更新。如成功获取文件，则进入更新步骤S4。首 先调用解析器执行解析步骤S41，将更新包中的代码解析为应用程序可识别的文件，然后 执行覆盖内存步骤S42。也就是说，下载的更新包或解析后的文件都不用于修改用户端的 应用程序本身，而是直接修正正在内存中运行的副本。直接覆盖内存的优点在于，不需要 重新启动所述应用程序，从用户角度来看，该应用程序没有任何改变，但事实上，当该应 用程序再次运行到被覆盖的部分时，执行的已经是新的代码，也就是说，更新是即时生效 的。

图3所示为服务器端的一个实施例。如图所示，程序服务器上传了修改后的代码文本 后，开始通知用户更新。首先执行调用接口步骤S21，当前通用的，一般采用套接字socket 方式远程通知用户端。同时，在服务器端记录发出通知的时间，即执行打时间戳步骤S22。 程序服务器可通过与用户端之间的网络通信状态判定用户端的在线情况，对于实时在线的 用户端，程序服务器执行广播通知步骤S23，即时通知用户端有更新。对于离线用户，则 在所述离线用户登录时，执行强制拉取步骤S24要求用户端强制拉取更新的文本。对于休 眠用户，则需要进行一分析。休眠用户可能是在线用户转化而来，也可能是反复休眠的用 户，因此，需要对其进行确认，不能在每个休眠用户重连时无差别的更新。对于休眠用户， 首先执行比较步骤S25，即比较该休眠用户最近一次的登录时间和之前记录的时间戳。如 果是所述登录时间较早，则说明该用户尚未更新过应用程序，在重连是可发送更新通知； 如果所述时间戳较早，则说明该用户必然已执行过一次同样的更新，不需要重复更新了。

以下，给出一些更新实例，以助于理解。

首先给出几个关于复写和改写的实例。基于应用程序中的数据多数以变量、函数或对 象结构体的形式存在内存中，针对所述三种不同的存储形式，做如下不同的处理：

其一，针对变量，设变量名为V，需要将其修改成数123，则可使用如下赋值语句进行改写：

V＝123；

其二，针对函数，设函数名为F，若需要重新定义该函数，则可重新定义该函数：

F＝function(){重新定义的代码}

其三，针对对象结构体，可以应用javascript语言的原型对象特性，保留现有原型代 码，在现有原型代码生效后添加补充逻辑。定义如下函数名：ed.functionName，用如下方式进行复写：

在现有原型代码生效后添加补充逻辑。定义如下函数名：ed.functionName，用如下方式进行复写：

其次，给出一个计算玩家星盘属性的程序对比。

其次，给出一个计算玩家星盘属性的程序对比。

以上的函数在计算英雄属性时忘了算玩家星盘的属性，对于这种影响所有玩家的重大 问题，就可以通过本发明修复。

以下为修改后的函数：

将该段程序保存为名为overwrite.code的更新包，并上传至下载服务器。

在用户端则执行预先定义的syncBackDoor函数，该函数的功能为：定义一个retryCnt 变量，初始化为0，记录请求文件的次数；建立https网络请求，远程获取前面保存的 overwrite.code文件。

同时，设定一个12秒超时逻辑。如果在12秒内获取成功，执行下一步。如果获取失败，则执行ed.checkNetConnect检查应用程序的网络情况，如果网络正常，用retryCnt 跟3进行比较，小于3则调用sednHttpRequest函数重新拉取文件。大于3则判定拉取失 败；如果网络异常，调用recnnect函数进行网络重连。重连成功后调用sednHttpRequest 重新拉取。这一步的终止条件是拉取成功或者尝试拉取三次都在12秒后超时。

结合JavaScript语言的特性，所述overwrite.code文件内的字符串执行newFunction(txt)()处理。这一步的目的是对字符串进行解析，并将解析好的代码加载到内存。 至此，整个更新流程就完成了，新的代码会替换掉内存内的旧代码。在接下来的程序运行 过程中，对原有代码的调用都会被改到对新加载的代码的调用。例如：执行newFunction(txt)()后，前述的有关玩家星盘属性的程序就按修改后的函数执行。整个过程都是在后 台运行的，对玩家的游戏体验不会有任何影响，即玩家在玩游戏的过程中实现了函数级的 应用更新，玩家不需要退出游戏重新启动即可修复问题。

综上，本发明所提出的用户无感的应用程序内更新方法直接覆盖内存，是一种即时生 效的更新方法，其使用非常灵活适合于对应用程序的微小修订和临时改动。结合现有的发 布更新包的升级方法，应用程序服务商可采取两种方法相结合的方式来维护该应用程序。 例如，每隔较长的周期(例如半年或一年)发布一次更新包，以完整修改用户端的应用程 序；在周期内则采用本发明提出的无感更新方法，快速修改内存，以弥补漏洞。或者，当 应用程序服务商需要开展临时活动时，采用本发明提出的无感更新方法，在一段时期内推 送消息或服务。可以说，本发明还为服务商提供了更多选择。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例 可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构 和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本发明并帮助理解各个发明方面中的一个或多个，在上 面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、 图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保 护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利 要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循 具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作 为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变 并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或 组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组 件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合 对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方 法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要 求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所 包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围 之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都 可以以任意的组合方式来使用。

Claims (13)

1.一种用户无感的应用程序内更新方法，其特征在于，在所述应用程序在线期间，直接更新用户端的内存，包括如下步骤：

上传步骤，支撑所述应用程序运行的程序服务器将更新包上传至一网络容器；

通知步骤，所述程序服务器发出更新通知，并将所述网络容器的网络地址提供给所述用户端；

获取步骤，所述用户端根据所述网络地址获取所述更新包；

更新步骤，所述用户端解析所述更新包，并将解析后的文件加载到内存，覆盖内存中相应的内容。

2.如权利要求1所述的方法，其特征在于，所述更新包包括以文本格式存储的代码，所述代码为通过改写和/或复写方式修改的新的代码段；

所述改写包括：删除原代码段并重新输入新的代码段；

所述复写包括：保留原代码段并新增代码段，以修正所述原代码段中的偏差。

3.如权利要求1所述的方法，其特征在于，所述上传步骤中，上传的所述更新包是全部代码或部分代码段。

4.如权利要求1所述的方法，其特征在于，所述网络容器包括下载服务器。

5.如权利要求1所述的方法，其特征在于，所述通知步骤中包括：

广播步骤，所述程序服务器向在线用户广播所述更新通知及所述网络地址；或

强制更新步骤，对于离线后重新登录的用户，所述程序服务器强制用户端拉取所述更新包；或

打时间戳步骤，所述程序服务器在发出所述更新通知时记录通知时间，当休眠用户发出重连请求后，首先比较所述用户最近一次的登录时间和所述通知时间，若所述登陆时间早于所述通知时间，则向所述用户发送所述更新通知及所述网络地址。

6.如权利要求1所述的方法，其特征在于，所述获取步骤中包括退出机制，所述退出机制包括：预设一超时时间，若所述用户端在所述超时时间内未能获得所述更新包，则退出，再次执行所述获取步骤。

7.如权利要求6所述的方法，其特征在于，所述获取步骤中包括退出机制，所述退出机制还包括：预设一最大次数，若所述用户端连续获取所述更新包不成功超次数过所述最大次数，则退出更新过程。

8.一种用户端，其特征在于，所述用户端响应于一更新通知执行如下步骤：

获取步骤，根据所述更新通知提供的网络地址获取一更新包；

更新步骤，解析所述更新包，并将解析后的文件加载到内存，覆盖内存中相应的内容。

9.如权利要求8所述的用户端，其特征在于，所述获取步骤中包括一退出机制，所述退出机制包括：预设一超时时间，若所述用户端在所述超时时间内未能获得所述更新包，则退出，再次执行所述获取步骤。

10.如权利要求9所述的用户端，其特征在于，所述退出机制还包括：预设一最大次数，若所述用户端连续获取所述更新包不成功次数超过所述最大次数，则退出更新过程。

11.一种程序服务器，其特征在于，所述程序服务器响应于一修改过的代码执行如下步骤：

上传步骤，将所述修改过的代码以更新包的格式上传至一网络容器；

通知步骤，发出更新通知，并提供所述网络容器的网络地址。

12.如权利要求11所述的程序服务器，其特征在于：

对于在线用户，通过广播的方式通知所述更新通知及所述网络地址；

对于离线后重新登录的用户，直接强制拉取所述更新包；

对于休眠用户，所述程序服务器在发出所述更新通知时记录通知时间，当所述用户发出重连请求后，首先比较所述用户最近一次的登录时间和所述通知时间，若所述登陆时间早于所述通知时间，则向所述用户发送所述更新通知及所述网络地址，否则不通知。

13.一种应用程序的支撑系统，其特征在于，包括如权利要求11或12所述的程序服务器和如权利要求8～10任一项所述的用户端，所述程序服务器向所述用户端提供更新包；所述用户端包括一代码解析器，所述代码解析器对所述代码文本进行解析，并使用解析后的文件替换内存中相应的内容，从而完成程序内更新。

Images