[发明专利]热更新方法、客户端及服务器

说明书

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

技术领域

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

背景技术

目前，基于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作为两个独立的文件单独下发给客户端。其中，CommonBundle和Patch称之为热更新配置信息。客户端接收到热更新配置信息后，根据热更新配置信息生成Service Bundle给具体的RN页面使用，从而实现热更新。

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

发明内容

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

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

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

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

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

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

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

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

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

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

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

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

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