热更新方法、客户端及服务器与流程

本申请实施例涉及计算机通信领域，尤其涉及一种热更新方法、客户端及服务器。

背景技术：

目前，基于JavaScript的开源框架React Native(以下简称为RN)的广泛应用，使得应用程序(Application，APP)摆脱了发版的限制，服务器发布RN代码，客户端根据RN代码，在不关闭APP的情况下对APP的bug进行修复，使得APP像网页一样完成热更新。

通常情况下，对于混合开发的APP来说，一个APP需要开发多个RN页面，而每一个RN页面对应一个Bundle文件，使得APP安装包过大。为了避免该问题的出现，热更新过程中，服务器针对不同的Bundle文件进行通用抽象，生成共同Bundle(Common Bundle)；每个RN页面的服务Bundle(Service Bundle)根据Common Bundle结合指定的算法生成补丁(Path)；服务器将Common Bundle和Patch作为两个独立的文件单独下发给客户端。其中，Common Bundle和Patch称之为热更新配置信息。客户端接收到热更新配置信息后，根据热更新配置信息生成Service Bundle给具体的RN页面使用，从而实现热更新。

上述热更新过程中，热更新配置信息的下发涉及两个文件：Common Bundle和Patch。若服务器对Common Bundle和Patch均进行更新，则客户端在请求热更新配置信息时，服务器无法保证将Common Bundle和Patch同时下发给客户端，使得Common Bundle和Patch不一致。若客户端根据不一致的Common Bundle和Patch对APP进行热更新，则出现错误。

技术实现要素：

本申请提供一种热更新方法、客户端及服务器，通过利用“读写锁”机制，实现热更新过程中，Common Bundle和Patch一致性的目的。

第一方面，本申请实施例提供一种热更新方法，包括：

服务器接收客户端运行应用程序时发送的更新请求，所述更新请求携带第一版本号，所述第一版本号为所述应用程序的配置文件的版本号；

所述服务器根据热更新平台的读写锁状态，确定目标配置文件；

所述服务器向所述客户端发送所述目标配置文件。

在一种可行的实现方式中，所述服务器根据热更新平台的读写锁状态，确定目标配置文件之前，还包括：

所述服务器判断第二版本号是否小于第三版本号，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号，所述第三版本号为所述热更新平台中存储的配置文件的版本号；

所述服务器根据热更新平台的读写锁状态，确定目标配置文件，包括：

若所述第二版本号小于所述第三版本号，则所述服务器确定所述读写锁状态；

若所述读写锁状态为开启状态，则所述服务器从所述热更新平台获取所述第三版本号对应的配置文件，并将所述第三版本号对应的配置文件作为所述目标配置文件。

在一种可行的实现方式中，上述的方法还包括：

若所述读写锁为关闭状态，则所述服务器判断所述第二版本号是否大于所述第一版本号；

若所述第二版本号大于所述第一版本号，则所述服务器确定所述目标配置文件为所述第二版本号对应的配置文件；

若所述第二版本号不大于所述第一版本号，则所述服务器向所述客户端返回空数据。

在一种可行的实现方式中，上述的方法还包括：

若所述第二版本号不小于所述第三版本号，则所述服务器判断所述第二版本号是否大于所述第一版本号；

若所述第二版本号大于所述第一版本号，则所述服务器确定所述目标配置文件为所述第二版本号对应的配置文件；

若所述第二版本号不大于所述第一版本号，则所述服务器向所述客户端返回空数据。

在一种可行的实现方式中，所述服务器从所述热更新平台获取所述第三版本号对应的配置文件之后，还包括：

所述服务器将所述缓存中的配置文件更新为所述第三版本号对应的配置文件。

第二方面，本申请实施例提供一种热更新方法，包括：

客户端运行应用程序时向服务器发送更新请求，所述更新请求携带第一版本号，所述第一版本号为所述应用程序的配置文件的版本号；

所述客户端接收所述服务器发送的目标配置文件，所述目标配置文件为所述服务器根据热更新平台的读写锁状态确定出的。

在一种可行的实现方式中，在所述服务器确定出第二版本号小于第三版本号、且所述热更新平台的读写锁状态为开启状态时，所述目标配置文件为所述服务器从所述热更新平台获取到的、所述第三版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号，所述第三版本号为所述热更新平台中存储的配置文件的版本号。

在一种可行的实现方式中，在所述服务器确定出第二版本号小于第三版本号、且所述热更新平台的读写锁状态为关闭状态、且所述第二版本号大于所述第一版本号时，则所述目标配置文件为所述第二版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号。

在一种可行的实现方式中，在所述服务器确定出第二版本号不小于第三版本号、且所述第二版本号大于所述第一版本号时，则所述目标配置文件为所述第二版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号。

第三方面，本申请实施例提供一种服务器，包括：

接收模块，用于接收客户端运行应用程序时发送的更新请求，所述更新请求携带第一版本号，所述第一版本号为所述应用程序的配置文件的版本号；

处理模块，用于根据热更新平台的读写锁状态，确定目标配置文件；

发送模块，用于向所述客户端发送所述目标配置文件。

在一种可行的实现方式中，所述处理模块，在根据热更新平台的读写锁状态，确定目标配置文件之前，还用于判断第二版本号是否小于第三版本号，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号，所述第三版本号为所述热更新平台中存储的配置文件的版本号，若所述第二版本号小于所述第三版本号，则确定所述读写锁状态，若所述读写锁状态为开启状态，则从所述热更新平台获取所述第三版本号对应的配置文件，并将所述第三版本号对应的配置文件作为所述目标配置文件。

在一种可行的实现方式中，所述处理模块，还用于若所述读写锁为关闭状态，则判断所述第二版本号是否大于所述第一版本号，若所述第二版本号大于所述第一版本号，则确定所述目标配置文件为所述第二版本号对应的配置文件；

所述发送模块，还用于若所述第二版本号不大于所述第一版本号，则向所述客户端返回空数据。

在一种可行的实现方式中，所述处理模块，还用于若所述第二版本号不小于所述第三版本号，则判断所述第二版本号是否大于所述第一版本号，若所述第二版本号大于所述第一版本号，则确定所述目标配置文件为所述第二版本号对应的配置文件；

所述发送模块，还用于若所述第二版本号不大于所述第一版本号，则向所述客户端返回空数据。

在一种可行的实现方式中，所述处理模块，在从所述热更新平台获取所述第三版本号对应的配置文件之后，还用于将所述缓存中的配置文件更新为所述第三版本号对应的配置文件。

第四方面，本申请实施例提供一种客户端，包括：

发送模块，用于运行应用程序时向服务器发送更新请求，所述更新请求携带第一版本号，所述第一版本号为所述应用程序的配置文件的版本号；

接收模块，用于接收所述服务器发送的目标配置文件，所述目标配置文件为所述服务器根据热更新平台的读写锁状态确定出的。

在一种可行的实现方式中，在所述服务器确定出第二版本号小于第三版本号、且所述热更新平台的读写锁状态为开启状态时，所述目标配置文件为所述服务器从所述热更新平台获取到的、所述第三版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号，所述第三版本号为所述热更新平台中存储的配置文件的版本号。

在一种可行的实现方式中，在所述服务器确定出第二版本号小于第三版本号、且所述热更新平台的读写锁状态为关闭状态、且所述第二版本号大于所述第一版本号时，则所述目标配置文件为所述第二版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号。

在一种可行的实现方式中，在所述服务器确定出第二版本号不小于第三版本号、且所述第二版本号大于所述第一版本号时，则所述目标配置文件为所述第二版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号。

本申请实施例提供的热更新方法、客户端及服务器，服务器接收客户端运行应用程序时发送的携带应用程序的配置文件的版本号的更新请求，根据热更新平台的读写锁状态确定目标配置文件，并向客户端发送目标配置文件。该过程中，目标配置文件中的Commcon Bundle和Patch是一致的，因此能够保证Commcon Bundle和Path的一致性，避免热更新过程中出现错误。

附图说明

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

图1为目前APP的热更新过程示意图；

图2为本申请热更新方法实施例一的信令图；

图3为本申请热更新方法的系统架构示意图；

图4为本申请热更新方法实施例二的流程图；

图5为本申请服务器实施例的结构示意图；

图6为本申请客户端实施例的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。以下内容为结合附图及较佳实施例，对依据本申请申请的具体实施方式、结构、特征及其功效的详细说明。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

图1为目前APP的热更新过程示意图。请参照图1，在服务器端，由于一个APP需要多个RN页面，每个RN页面对应一个可执行文件(以下称之为Bundle文件)，为避免APP安装包过大，服务器在热更新过程中针对不同的Bundle文件进行通用抽象，生成一个APP对应的多个Bundle文件的共同可执行文件(以下称之为Common Bundle)，每个RN页面的服务可执行文件(以下称之为Service Bundle)根据Common Bundle结合指定算法，如图中的命令比较文本文件(DIFF)生成补丁。然后，服务器将热更新配置信息，即将Common Bundle和Patch作为两个独立的文件单独下发给客户端。客户端根据热更新配置信息，为每一个RN页面生成Service Bundle。

上述热更新过程中，热更新配置信息的下发设计两个文件：即Common Bundle和Patch。其中，Pat车与实际业务相关，因此更改比较频繁；Commcon Bundle文件与业务逻辑无关，改动较少。当服务器只下发Patch时，服务器只需要保证Patch顺利下发即可，针对获取redis数据时做一些异常捕获。当同时更新Commcon Bundle和Patch时，因为该两个文件是先后生成的，而且Patch的生成是依赖于Commcon Bundle的，因此，当客户端请求热更新数据时，无论采用何种方式，服务器都无法保证Commcon Bundle和Path同时下发，无法保证Commcon Bundle和Path的一致性。

有鉴于此，本申请实施例提供一种热更新方法、客户端及服务器，通过利用“读写锁”机制，实现热更新过程中，Common Bundle和Patch一致性的目的。

图2为本申请热更新方法实施例一的信令图，包括：

101、客户端运行应用程序时向服务器发送更新请求。

本申请实施例中，一个APP需要多个RN页面，每个RN页面对应一个可执行文件，即Bundle文件。本步骤中，客户端在运行APP时，若需要对该APP进行热更新，则向服务器发送携带该应用程序的配置文件的版本号的更新请求，以请求热更新数据，该热更新数据也称之为目标配置文件。对于每一个RN页面来说，该目标配置文件包括Commcon Bundle和Patch。其中，对于一个具体的RN，Path为服务器针对该APP所有的RN页面提取Commcon Bundle后，基于Commcon Bundle，该RN页面的Service Bundle根据Common Bundle结合指定的算法生成的。因此，目标配置文件中的Commcon Bundle和Patch是一致的，能够保证Commcon Bundle和Path的一致性。

本申请实施例中，每一次生成配置文件都会生成对应的版本号，版本号越高，则配置文件越新。第一版本号为应用程序当前的配置文件的版本号，当热更新平台或服务器本地缓存中存在高于版本号高于第一版本号的配置文件时，则需要对应用程序执行热更新。

102、服务器根据热更新平台的读写锁状态，确定目标配置文件。

在接收到更新请求后，服务器获取热更新平台的读写锁状态，确定目标配置文件。其中，读写锁也成为全局锁，热更新平台上存储每次更新时的配置文件等。

103、服务器向客户端发送目标配置文件。

在确定出目标配置文件后，服务器向客户端发送该目标配置文件，相应的，客户端接收该目标配置文件，并根据该目标配置文件对当前正在运行的APP进行热更新。

本申请实施例提供的热更新方法，服务器接收客户端运行应用程序时发送的携带应用程序的配置文件的版本号的更新请求，根据热更新平台的读写锁状态确定目标配置文件，并向客户端发送目标配置文件。该过程中，目标配置文件中的Commcon Bundle和Patch是一致的，因此能够保证Commcon Bundle和Path的一致性，避免热更新过程中出现错误。

图3为本申请热更新方法的系统架构示意图。请参照图3，基于内容分发网络(Content Delivery Network，CDN)的系统架构中，包括客户端、服务器、热更新平台和通用服务层。其中，客户端上运行APP，包括版本管理模块、RN载体模块、预加载模块等，服务器上具有资源列表版本接口、单独RN页面版本接口等，热更新平台上具有补丁模块、版本管理模块、审核模块、日志模块等。热更新平台中，对了保证系统对在于读写性能的需求，在设计存储结构时，以单个资源为单位在redis中存储，如图中的补丁模块。redis的中文名称为重申，是一种典型的非关系性数据库(Not Only Structured Query Language，NoSQL)数据库服务，采用键-值(KEY-VALUE)存储结构。该系统架构中，通过读写锁的状态来控制对资源的读取，redis中数据的重传结构示例如下：

下面，在图3的基础上，用一个具体的实施例对本申请所述的热更新方法进行详细说明。具体的，可参加图4，图4为本申请热更新方法实施例二的流程图，包括：

201、客户端运行应用程序时向服务器发送更新请求。

其中，更新请求携带第一版本号，第一版本号为应用程序的配置文件的版本号。

202、服务器判断第二版本号是否小于第三版本号，若第二版本号小于第三版本号，则执行203；若第二版本号不小于第三版本号，则执行207；

其中，第二版本号为服务器本地缓存中存储的配置文件的版本号，第三版本号为热更新平台中存储的配置文件的版本号。

本步骤中，服务器根据第二版本号与第三版本号的大小，判断本地缓存中的配置文件的版本号是否大于热更新平台上配置文件的版本号。

203、服务器确定读写锁状态，若读写锁状态为开启状态，则执行204；若读写锁状态为关闭状态，则执行207。

本步骤中，服务器判断热更新平台的读写锁的状态，若读写锁被打开，即处于开启状态，则执行204；若读写锁未被打开，即处于关闭状态，则执行207。

204、服务器从所述热更新平台获取所述第三版本号对应的配置文件。

本步骤中，当读写锁处于开启状态时，服务器从热更新平台获取最新的配置文件，即第三版本号的配置文件，并将该第三版本号的配置文件作为目标配置文件。

205、服务器将第三版本号的配置文件作为目标配置文件并发送给客户端。

206、服务器将缓存中的配置文件更新为第三版本号对应的配置文件。

本步骤中，服务器将缓存中版本号较低的配置文件，更新为版本号较高的配置文件，即第三版本号的配置文件。通过对缓存中的配置文件进行更新，实现当热更新平台的读写锁状态关闭时，服务器从本地获取最新的配置文件，减少对热更新平台的访问次数。同时，当热更新平台出现异常时，基于贝蒂缓存数据做到服务降级，保证APP的顺利运行；当热更新平台服务恢复时，服务器自动检查热更新平台上配置文件的版本号和本地缓存中配置文件的版本号，进行本地缓存数据的更新。

207、服务器判断第二版本号是否大于第一版本号，若第二版本号大于所述第一版本号，则执行208；若第二版本号不大于所述第一版本号，则执行209。

通常情况下，服务器更新Commcon Bundle文件后，会修改热更新平台的读写所的状态，此时无法获取到热更新平台上的数据，因此服务器只能下发本地缓存中的数据。本步骤中，服务器根据第二版本号与第一版本号的大小，判断本地缓存中是否存储有版本号高于第一版本号的配置文件，即第二版本号对应的配置文件，若存在，则执行208；若不存在，则执行209。

208、服务器将第二版本号的配置文件作为目标配置文件发送给客户端。

发送过程中，服务器需要考虑接口，如资源列表版本接口、单独RN页面版本接口的可用性等。

209、服务器向客户端返回空数据。

本步骤中，服务器认为本地缓存和热更新平台中均没有版本号高于第一版本号的配置文件，无法对客户端当前运行的应用程序进行热更新，因此返回空数据。

另外，除了上述通过读写锁的状态实现Commcon Bundle和Patch一致性外，还可以采用其他的方式保证数据的一致性。例如，利用redis的原子性保证数据的更新。

具体的，热更新平台中所有的数据都是以一个Key全部存放在redis中，数据的更新则是通过redis的key的设置(set)、获取(get)操作来实现对应值的更新。其中，redis中数据的存储结构示例如下：

图5为本申请服务器实施例的结构示意图，包括：

接收模块11，用于接收客户端运行应用程序时发送的更新请求，所述更新请求携带第一版本号，所述第一版本号为所述应用程序的配置文件的版本号；

处理模块12，用于根据热更新平台的读写锁状态，确定目标配置文件；

发送模块13，用于向所述客户端发送所述目标配置文件。

本申请实施例提供的服务器，在接收客户端运行应用程序时发送的携带应用程序的配置文件的版本号的更新请求后，根据热更新平台的读写锁状态确定目标配置文件，并向客户端发送目标配置文件。该过程中，目标配置文件中的Commcon Bundle和Patch是一致的，因此能够保证Commcon Bundle和Path的一致性，避免热更新过程中出现错误。

可选的，在本申请一实施例中，所述处理模块12，在根据热更新平台的读写锁状态，确定目标配置文件之前，还用于判断第二版本号是否小于第三版本号，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号，所述第三版本号为所述热更新平台中存储的配置文件的版本号，若所述第二版本号小于所述第三版本号，则确定所述读写锁状态，若所述读写锁状态为开启状态，则从所述热更新平台获取所述第三版本号对应的配置文件，并将所述第三版本号对应的配置文件作为所述目标配置文件。

可选的，在本申请一实施例中，所述处理模块12，还用于若所述读写锁为关闭状态，则判断所述第二版本号是否大于所述第一版本号，若所述第二版本号大于所述第一版本号，则确定所述目标配置文件为所述第二版本号对应的配置文件；

所述发送模块13，还用于若所述第二版本号不大于所述第一版本号，则向所述客户端返回空数据。

可选的，在本申请一实施例中，所述处理模块12，还用于若所述第二版本号不小于所述第三版本号，则判断所述第二版本号是否大于所述第一版本号，若所述第二版本号大于所述第一版本号，则确定所述目标配置文件为所述第二版本号对应的配置文件；

所述发送模块13，还用于若所述第二版本号不大于所述第一版本号，则向所述客户端返回空数据。

可选的，在本申请一实施例中，所述处理模块12，在从所述热更新平台获取所述第三版本号对应的配置文件之后，还用于将所述缓存中的配置文件更新为所述第三版本号对应的配置文件。

图6为本申请客户端实施例的结构示意图，包括：

发送模块21，用于运行应用程序时向服务器发送更新请求，所述更新请求携带第一版本号，所述第一版本号为所述应用程序的配置文件的版本号；

接收模块22，用于接收所述服务器发送的目标配置文件，所述目标配置文件为所述服务器根据热更新平台的读写锁状态确定出的。

本申请实施例提供的客户端，在运行应用程序时，向服务器发送携带该应用程序的配置文件的版本号的更新请求，使得服务器根据热更新平台的读写锁状态确定目标配置文件，并向客户端发送目标配置文件。该过程中，目标配置文件中的Commcon Bundle和Patch是一致的，因此能够保证Commcon Bundle和Path的一致性，避免热更新过程中出现错误。

可选的，在本申请一实施例中，在所述服务器确定出第二版本号小于第三版本号、且所述热更新平台的读写锁状态为开启状态时，所述目标配置文件为所述服务器从所述热更新平台获取到的、所述第三版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号，所述第三版本号为所述热更新平台中存储的配置文件的版本号。

可选的，在本申请一实施例中，在所述服务器确定出第二版本号小于第三版本号、且所述热更新平台的读写锁状态为关闭状态、且所述第二版本号大于所述第一版本号时，则所述目标配置文件为所述第二版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号。

可选的，在本申请一实施例中，在所述服务器确定出第二版本号不小于第三版本号、且所述第二版本号大于所述第一版本号时，则所述目标配置文件为所述第二版本号对应的配置文件，所述第二版本号为所述服务器本地缓存中存储的配置文件的版本号。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。