CN114995847A - 热更新方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种热更新方法、装置、设备及计算机可读存储介质；应用于云技术领域，所述方法包括：接收终端发送的规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息；获取待更新客户端的每一业务模块的规则集合；规则集合包括业务模块对应的至少一个规则信息；基于运行信息和每一业务模块对应的至少一个规则信息，确定至少一个目标规则信息；将至少一个目标规则信息发送至终端，以使终端根据至少一个目标规则信息对应的目标业务代码包完成待更新客户端的热更新过程。通过本申请提供的热更新方法，能够实现各个业务模块的单独更新，在提升各业务模块的开发效率和发布效率的基础上，提升了待更新客户端整体的热更新效率。

Description

热更新方法、装置、设备及计算机可读存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种热更新方法、装置、设备及计算机可读存储介质。

背景技术

客户端(Client)或称为用户端，是指与服务器相对应，为客户提供本地服务的应用程序，通过不同的应用程序可以为用户提供不同的服务。而在实际应用中，出于扩展功能，修复漏洞，提升用户体验等目的，常常需要对应用程序进行更新。

传统更新技术在进行上述改进时，需要对应用程序进行完整的替换，即，需要开发人员修改源代码，并在开发环境中重新编译链接，生成新的应用软件，发布在对应的移动终端上以供用户重新安装，这就会带来工作量大，耗时长等问题。而补丁更新和热更新推送虽然可以改善传统更新技术存在的问题，但也会存在更新效率较低的问题。

发明内容

本申请实施例提供一种热更新方法、装置、设备及计算机可读存储介质，能够提升热更新效率。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种热更新方法，应用于服务器，所述方法包括：接收终端发送的规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息；获取待更新客户端的每一业务模块的规则集合；规则集合包括业务模块对应的至少一个规则信息；基于运行信息和每一业务模块对应的至少一个规则信息，确定至少一个目标规则信息；将至少一个目标规则信息发送至终端，以使终端根据至少一个目标规则信息对应的目标业务代码包完成待更新客户端的热更新过程。

在本申请的一些实施例中，所述规则信息包括：代码包版本信息和更新范围信息；所述基于运行信息和每一业务模块对应的至少一个规则信息，确定至少一个目标规则信息，包括：在业务模块对应的至少一个规则信息中，筛选更新范围信息与运行信息匹配的待确定规则信息；在存在至少一个待确定规则信息的情况下，将代码包版本信息最新的待确定规则信息确定为目标规则信息。

在本申请的一些实施例中，所述规则信息还包括：代码包地址信息。

在本申请的一些实施例中，所述方法还包括：获取待更新客户端对应的待更新源代码；以待更新客户端的业务模块作为构建维度，将待更新源代码构建为至少一个待配置代码包；确定每一待配置代码包的规则信息；将每一待配置代码包的规则信息保存至每一待配置代码包对应的业务模块的规则集合。

在本申请的一些实施例中，所述确定每一待配置代码包的规则信息，包括：通过配置界面接收用户针对待配置代码包的配置操作；根据配置操作确定待配置代码包的规则信息。

在本申请的一些实施例中，在通过配置界面接收用户针对待配置代码包的配置操作之前，所述方法还包括：接收用户的配置查看请求；响应于配置查看请求，通过展示界面展示每一业务模块对应的代码包列表；代码包列表包括业务模块对应的待配置代码包和已配置代码包；通过展示界面接收用户针对待配置代码包的选择请求；响应于选择请求，跳转至配置界面，通过配置界面接收用户针对待配置代码包的配置操作。

在本申请的一些实施例中，所述根据配置操作确定待配置代码包的规则信息，包括：响应于配置界面的生成事件，生成待配置代码包的代码包版本信息，并获取待配置代码包的代码包地址信息；根据配置操作，确定待配置代码包的更新范围信息；更新范围信息包括以下至少之一：客户端范围信息和用户范围信息；基于代码包版本信息、代码包地址信息和更新范围信息，生成规则信息。

本申请实施例还提供一种热更新方法，应用于终端，所述方法包括：响应于客户端唤醒事件，向服务器发送规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息；接收服务器发送的与运行信息匹配至少一个目标规则信息；获取至少一个目标规则信息对应的目标业务代码包；根据目标业务代码包完成热更新过程。

在本申请的一些实施例中，所述获取至少一个目标规则信息对应的目标业务代码包，包括：获取每一目标规则信息中携带的目标代码包版本信息，和每一目标规则信息对应的业务模块；获取待更新客户端中每一业务模块对应的运行代码包版本信息；根据每一业务模块对应的运行代码包版本信息和目标代码包版本信息，确定至少一个待更新规则信息；根据每一待更新规则信息中携带的目标业务代码包地址信息，获取目标业务代码包。

在本申请的一些实施例中，所述根据目标业务代码包完成热更新过程，包括：检测待更新客户端的运行状态；运行状态包括前台状态和后台状态；在待更新客户端的从前台状态切换至后台状态的情况下，将目标业务代码包加载至内存中，以完成热更新过程。

在本申请的一些实施例中，所述将目标业务代码包加载至内存中，包括：获取目标业务代码包对应的业务模块的状态依赖信息；在状态依赖信息表征业务模块不需要依赖当前运行状态的情况下，将目标业务代码包加载至内存中。

在本申请的一些实施例中，所述方法还包括：在目标业务代码包对应的目标规则信息携带强制更新标记的情况下，监控待更新客户端的实例创建事件；根据目标业务代码包完成热更新过程，包括：在实例创建事件依赖携带强制更新标记的目标业务代码包的情况下，将目标业务代码包加载至内存中；基于目标业务代码包创建实例，以完成热更新过程。

本申请实施例提供一种热更新装置，所述装置包括：

第一接收模块，用于接收终端发送的规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息；

第一获取模块，用于获取待更新客户端的每一业务模块的规则集合；规则集合包括业务模块对应的至少一个规则信息；

确定模块，用于基于运行信息和每一业务模块对应的至少一个规则信息，确定至少一个目标规则信息；

第一更新模块，用于将至少一个目标规则信息发送至终端，以使终端根据至少一个目标规则信息对应的目标业务代码包完成待更新客户端的热更新过程。

本申请实施例还提供一种热更新装置，所述装置包括：

发送模块，用于响应于客户端唤醒事件，向服务器发送规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息；

第二接收模块，用于接收服务器发送的与运行信息匹配至少一个目标规则信息；

第二获取模块，用于获取至少一个目标规则信息对应的目标业务代码包；

第二更新模块，用于根据目标业务代码包完成热更新过程

本申请实施例提供一种热更新设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的热更新方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的热更新方法。

本申请实施例具有以下有益效果：

本申请实施例通过获取终端的运行信息，并与每一业务模块对应的至少一个规则信息进行匹配，确定符合要求的至少一个目标规则信息，将至少一个目标规则信息发送至终端，以使终端基于该至少一个目标规则信息对应的目标物代码包完成待更新客户端的热更新过程。如此，服务器可以根据登录该待更新客户端的用户标识，进而实现灰度发布的效果，并且，服务器还可以基于不同的待更新客户端的客户端版本，确定不同的目标规则信息，进而使不同客户端版本的待更新客户端获取不同的目标业务代码包；同时，本申请将待更新客户端的更新任务划分为不同业务模块的更新任务，实现了各个业务模块的单独更新，在提升各业务模块的开发效率和发布效率的基础上，提升了待更新客户端整体的热更新效率。

附图说明

图1是本申请实施例提供的热更新系统的一个可选的架构示意图；

图2A是本申请实施例提供的热更新设备的结构示意图；

图2B是本申请实施例提供的热更新设备的结构示意图；

图3是本申请实施例提供的热更新方法的一个可选的流程示意图；

图4是本申请实施例提供的热更新方法的一个可选的流程示意图；

图5是本申请实施例提供的热更新方法的一个可选的流程示意图；

图6是本申请实施例提供的热更新方法的一个可选的流程示意图；

图7是本申请实施例提供的热更新方法的一个可选的流程示意图；

图8是本申请实施例提供的热更新方法的一个可选的流程示意图；

图9是本申请实施例提供的热更新方法的一个可选的流程示意图；

图10是本申请实施例提供的热更新方法的一个可选的流程示意图；

图11是本申请实施例提供的热更新系统的一个可选的架构示意图；

图12是本申请实施例提供的配置界面的一个可选的界面示意图；

图13是本申请实施例提供的配置分发过程示意图；

图14是本申请实施例提供的客户端热更新的流程示意图；

图15是本申请实施例提供的代码包存储架构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使在本实施例中描述的本申请实施例能够以除了在在本实施例中图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

(1)Jenkins：一个开源的、提供友好操作界面的持续集成(ContinuousIntegration，CI)工具，起源于Hudson(可扩展的持续集成引擎)，主要用于持续、自动的构建测试软件项目、监控外部任务的运行。

(2)持续集成：一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。

(3)React Native：是一个开源的跨平台移动应用的开发框架，它能在JavaScript(一种解释性脚本语言，代码不需要进行预编译即可被运行)中用React(一种设计思想)抽象操作系统元素的用户接口组件，代替文档对象模型进行渲染，利用React Native开发应用为开发者们提供了便利。

(4)灰度发布：可以理解为在正式版本发布之前的一个版本。灰度版本的作用是用来验证新版本是否有重大bug或者严重影响用户体验的问题。理想状态是发布一个灰度版本v1后没有任何问题，那么就可以将这个灰度版本v1作为正式版本全量发布；如果这个灰度版本v1存在问题，那么需要开发人员进行修复，还要经过测试，然后再发布一个灰度版本v2，然后再观察这个v2版本是否有什么问题。如果有问题仍然需要再发布一个v3版本，甚至更多。

(5)A/B测试：发布时大部分用户使用A版本，然后让一小部分用户开始使用B版本，观察B版本用户的反应，如果B版本用户没什么反应，那么就逐步地让A版本用户过渡到B版本。

参见图1，图1是本申请实施例提供的热更新系统100的一个可选的架构示意图，为实现支撑一个热更新应用，终端(示例性示出了终端400-1和终端400-2)通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。图1还示出了服务器200可以为服务器集群，该服务器集群包括服务器200-1至200-3，同样地，服务器200-1至200-3可以是实体机器，也可以是利用虚拟化技术(如容器技术及虚拟机技术等)构建的虚拟机器，本申请实施例对此不做限定，当然，在本实施例中也可使用单个服务器来进行服务的提供。

本申请实施例可以借助于云技术(Cloud Technology)实现，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、以及应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，例如，教育系统的门户网站。

作为示例，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、以及智能手表等，但并不局限于此。终端以及服务器200可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。

参见图2A，图2A是本申请实施例提供的热更新设备500的结构示意图，图2A所示的热更新设备500包括：至少一个处理器510、存储器550、至少一个网络接口520和用户接口530。热更新设备500中的各个组件通过总线系统540耦合在一起。可理解，总线系统540用于实现这些组件之间的连接通信。总线系统540除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2A中将各种总线都标为总线系统540。

参见图2B，图2B是本申请实施例提供的热更新设备600的结构示意图，图2B所示的热更新设备600包括：至少一个处理器610、存储器650、至少一个网络接口620和用户接口630。热更新设备600中的各个组件通过总线系统640耦合在一起。可理解，总线系统640用于实现这些组件之间的连接通信。总线系统640除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2B中将各种总线都标为总线系统640。

处理器510/610可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口530/630包括使得能够呈现媒体内容的一个或多个输出装置531/631，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口530/630还包括一个或多个输入装置532/632，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器550/650包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器550/650旨在包括任意适合类型的存储器。存储器550/650可选地包括在物理位置上远离处理器510/610的一个或多个存储设备。

在本申请的一些实施例中，存储器550/650能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统551/651，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块552/652，用于经由一个或多个(有线或无线)网络接口520/620到达其他计算设备，示例性的网络接口520/620包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

显示模块553/653，用于经由一个或多个与用户接口530/630相关联的输出装置531/631(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；

输入处理模块554/654，用于对一个或多个来自一个或多个输入装置532/632之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在本申请的一些实施例中，本申请实施例提供的热更新装置可以采用软硬件结合的方式实现，作为示例，本申请实施例提供的热更新装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的热更新方法/热更新方法。

在本申请的一些实施例中，本申请实施例提供的热更新装置可以采用软件方式实现，图2A示出了存储在存储器550中的热更新装置555，其可以是程序和插件等形式的软件，包括以下软件模块：第一接收模块5551、第一获取模块5552、确定模块5553和第一更新模块5554。图2B示出了存储在存储器650中的热更新装置655，其可以是程序和插件等形式的软件，包括以下软件模块：发送模块6551、第二接收模块6552、第二获取模块6553和第二更新模块6554，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。

将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的热更新方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。

将结合本申请实施例提供的服务器的示例性应用和实施，在本申请实施例中，将以服务器为执行主体说明本申请实施例提供的热更新方法。

参见图3，图3是本申请实施例提供的热更新方法的一个可选的流程示意图，将结合图3示出的步骤进行说明。

在步骤301中，服务器接收终端发送的规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息。

在本申请的一些实施例中，该规则信息获取请求可以是终端响应于预设的请求触发事件向该服务器发送的。其中，该请求触发事件可以包括以下至少之一：接收用户的更新触发操作，该待更新客户端对应的定时更新请求等。在本申请的一些实施例中，该规则信息获取请求还可以是终端响应于服务器发送的运行信息获取请求而发送的。

在本申请的一些实施例中，所述终端包括所述待更新客户端，该待更新客户端的运行信息可以包括以下至少之一：该待更新客户端的客户端版本、和登录该待更新客户端的用户标识等。

在本申请的一些实施例中，该待更新客户端可以为React Native应用，即由开发者利用React Native开发的应用。其中，React Native应用可以是各种类型的ReactNative应用，包括但不限于游戏类React Native应用、影音娱乐类React Native应用、实用工具类React Native应用以及社交通信类React Native应用等。

在步骤302中，服务器获取待更新客户端的每一业务模块的规则集合；规则集合包括业务模块对应的至少一个规则信息。

在本申请的一些实施例中，对于该待更新客户端，可以包括多个业务模块，不同的业务模块可以用于实现不同的业务功能。例如，针对社交通信类的待更新客户端，可以包括单人聊天模块、群组聊天模块和状态分享模块等。

在本申请的一些实施例中，服务器中存储该待更新模型的全部业务模块中每一业务模块对应的规则集合。对于任意一个业务模块，服务器中存储有该业务模块对应的至少一个规则信息，每一规则信息用于确定该规则信息对应的业务代码包的更新规则。

在步骤303中，服务器基于运行信息和每一业务模块对应的至少一个规则信息，确定至少一个目标规则信息。

在本申请的一些实施例中，服务器会根据当前待更新客户端发送的运行信息，在至少有一个规则信息中确定与该运行信息匹配的至少一个目标规则信息。其中，在未找到与该运行信息匹配的目标规则信息的情况下，则此次热更新过程结束，返回无需更新的指示消息至该终端。需要说明的是，针对任意一个业务模块，对应的目标规则信息最多只有一个，也就是说，得到的至少一个目标规则信息中，每一目标规则信息对应的业务模块均不相同。通过上述方式，可以实现基于待更新客户端的登录用户标识进行灰度发布的效果，同时，由于运行信息还包括客户端的版本，上述方式还可以针对不同待更新客户端的版本，确定不同的目标规则信息，进而使终端获取不同的目标业务代码包。

在本申请的一些实施例中，该规则信息可以包括代码包版本信息和更新范围信息，可以通过以下方法实现上述基于所述运行信息和每一所述业务模块对应的至少一个规则信息，确定至少一个目标规则信息：在所述业务模块对应的至少一个规则信息中，筛选更新范围信息与所述运行信息匹配的待确定规则信息；在存在至少一个所述待确定规则信息的情况下，将代码包版本信息最新的待确定规则信息确定为所述目标规则信息。

在步骤304中，服务器将至少一个目标规则信息发送至终端。

在本申请的一些实施例中，该目标规则信息还包括代码包地址信息。

在步骤305中，终端根据至少一个目标规则信息对应的目标业务代码包完成待更新客户端的热更新过程。

在本申请的一些实施例中，终端可以根据每一目标规则信息中携带的代码包地址信息，确定该目标业务代码包的代码包地址信息，通过该目标业务代码包的代码包地址信息可以得到该目标业务代码包，并利用该目标业务代码包完成该待更新客户端的热更新过程。

通过本申请实施例对于图3的上述示例性实施可知，本申请实施例通过获取终端的运行信息，并与每一业务模块对应的至少一个规则信息进行匹配，确定符合要求的至少一个目标规则信息，将至少一个目标规则信息发送至终端，以使终端基于该至少一个目标规则信息对应的目标物代码包完成待更新客户端的热更新过程。如此，服务器可以根据登录该待更新客户端的用户标识，进而实现灰度发布的效果，并且，服务器还可以基于不同的待更新客户端的客户端版本，确定不同的目标规则信息，进而使不同客户端版本的待更新客户端获取不同的目标业务代码包；同时，本申请将待更新客户端的更新任务划分为不同业务模块的更新任务，实现了各个业务模块的单独更新，在提升各业务模块的开发效率和发布效率的基础上，提升了待更新客户端整体的热更新效率。

参见图4，图4是本申请实施例提供的热更新方法的一个可选的流程示意图，基于图3，在步骤302之前，所述方法还可以包括步骤401至步骤404，将结合图4示出的步骤进行说明。

在步骤401中，获取待更新客户端对应的待更新源代码。

在本申请的一些实施例中，服务器可以通过代码托管平台接收用户针对该待更新客户端上传的待更新源代码。其中，用户将该待更新代码上传至代码托管平台之后，代码托管平台会响应于该上传事件，向服务器中的持续集成工具发送集成构建请求，集成构建工具会从该代码托管平台中拉取该待更新源代码，以完成后续的构建过程。该代码托管平台可以为Gitlab，该持续集成工具可以为Jenkins。

在步骤402中，以待更新客户端的业务模块作为构建维度，将待更新源代码构建为至少一个待配置代码包。

在本申请的一些实施例中，服务器中存储有不同客户端对应的业务模块信息，在需要生成待更新客户端对应的至少一个待配置代码包的情况下，会先获取该待更新客户端对应的业务模块信息，其中，该业务模块信息可以包括客户端对应的所有业务模块。在构建过程中，可以依据该待更新客户端对应的所有业务模块，将该待更新源代码构建为至少一个待配置代码包。在一个业务模块对应的待配置代码包中，包含了该业务模块在运行中会使用到的资源；该资源包括但不限于是图像、声音和编译好的代码。

例如，在该待更新客户端为React Native应用的情况下，该待配置代码包可以为React Native Bundle(包)。

在本申请的一些实施例中，服务器还可以将得到的待配置代码包存储于内容分发网络(Content Delivery Network，CDN)服务器来获取，CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求，提高用户访问响应速度和命中率。在本申请实施例中，通过采用CDN服务器提高了获取待配置代码包的效率，进而缩短了热更新的时间。

在步骤403中，确定每一待配置代码包的规则信息。

在本申请的一些实施例中，该规则信息包括待配置代码包的代码包版本信息和更新范围信息。

其中，服务器中可以预先存储该待更新客户端的预配置信息，该预配置信息包括每一业务模块对应的规则信息。在得到构建好的至少一个待配置代码包之后，会在预配置信息中获取各待配置代码包对应的规则信息。

其中，在得到构建好的至少一个待配置代码包之后，还可以接收用户针对每一待配置代码包设置的规则信息。

在步骤404中，将每一待配置代码包的规则信息保存至每一待配置代码包对应的业务模块的规则集合。

在本申请的一些实施例中，在客户端版本更迭的过程中，对于每一业务模块，可能会存在多个版本对应的业务代码包，每一业务代码包均对应该版本对应的规则信息，服务器将业务模块对应的多个版本对应的规则信息作为该业务模块对应的规则集合，并保存至数据库中。

通过本申请实施例对于图4的上述示例性实施可知，本申请实施例在构建过程中，以待更新客户端的业务模块作为构建维度，实现了各业务模块对应的待配置代码包的获取；同时，通过确定每一待配置代码包的规则信息，更新了每一业务模块对应的规则集合，在确定终端对应的至少一个目标规则信息的过程中，可以保证获取到最新的规则信息，进一步提升热更新效率。

参见图5，图5是本申请实施例提供的热更新方法的一个可选的流程示意图，基于图4，图4示出的步骤403可更新为步骤501至步骤502，将结合图4示出的步骤进行说明。

在步骤501中，通过配置界面接收用户针对待配置代码包的配置操作。

在本申请的一些实施例中，服务器可以接收用户针对任意一个待配置代码包的配置请求，响应于该配置请求，通过用户侧的终端设备显示配置界面，并通过配置界面接收用户针对该待配置代码包的配置操作。其中，该配置操作可以包括以下至少之一：针对配置界面中设置的配置选项的选择操作，针对配置界面中输入窗口中的输入操作，和针对配置界面中显示的配置规则的保存/发布操作。

其中，服务器中还可以设置配置平台，在步骤501中，服务器可以通过该配置平台提供该配置界面，并根据该配置界面接收用户针对所述待配置代码包的配置操作。

在步骤502中，根据配置操作确定待配置代码包的规则信息。

在本申请的一些实施例中，基于该配置界面和配置操作，可以确定该待配置代码包的规则信息。例如，该配置界面中可以包括更新范围信息对应的多个选项，如用户范围1(尾号为0-4)，用户范围2(尾号为5-9)，用户范围3(全部用户)，客户端版本范围1(1.0-2.0)和客户端范围2(全部客户端)；在配置操作包括对用户范围1和客户端版本范围1的选择操作后，生成的配置规则至少包括：该待配置代码包的更新范围为尾号为0-4，且客户端版本为1.0-2.0之间的客户端。

在本申请的一些实施例中，可以通过步骤5021至步骤5023实现上述根据所述配置操作确定所述待配置代码包的规则信息：

在步骤5021中，响应于配置界面的生成事件，生成待配置代码包的代码包版本信息，并获取待配置代码包的代码包地址信息。

在本申请的一些实施例中，在服务器接收到配置请求之后，会触发该配置界面的生成事件，响应于该生成事件，会生成该待配置代码包的代码包版本信息，并显示与该配置界面中。其中，该代码包版本信息可以通过以下方式生成：确定该待配置代码包对应的业务模块，获取该业务模块对应的规则集合，该规则集合包括该业务模块的至少一个历史代码包和对应的历史规则信息，基于各历史规则信息中的历史代码包版本信息，生成该待配置代码包对应的代码包版本信息。其中，生成的代码包版本信息用于表征该待配置代码包的版本比各历史代码包的新。例如，代码包版本信息可以但不限于是版本号，在业务模块对应的规则集合包括的1.1，1.2，1.3的历史代码包版本信息的情况下，生成的代码包版本信息可以为1.4或1.35等高于各历史代码包版本信息的版本号。

在本申请的一些实施例中，响应于该生成事件，服务器还会获取该待配置代码包的代码包地址信息。该代码包地址信息用于表征该待配置代码包在服务器中的存储地址。在一些实施例中，为了便于终端获取业务代码包，服务器还可以将该待配置代码包存储于CDN服务器中，进而该代码包地址信息还用于表征该待配置代码包在CDN服务器中的存储地址。

在步骤5022中，根据配置操作，确定待配置代码包的更新范围信息；更新范围信息包括以下至少之一：客户端范围信息和用户范围信息。

在本申请的一些实施例中，该更新范围信息可以包括客户端范围信息，也可以包括用户范围信息，还可以同时由客户端范围信息和用户范围信息共同确定。在该配置界面中，可以显示有客户端范围信息对应的至少一个客户端范围选项，也可以显示有用户范围信息对应的至少一个用户范围选项，基于针对任意客户端范围选项和用户范围选项的选择操作，确定该待配置代码包的客户端范围信息和/或用户范围信息，进而得到该更新范围信息。

在步骤5023中，基于代码包版本信息、代码包地址信息和更新范围信息，生成规则信息。

在本申请的一些实施例中，该配置界面还可以包括规则发布选项，服务器还可以通过该配置界面接收用户针对该发布选项的选择操作，生成发布事件，响应于该发布事件，服务器基于该代码包版本信息、代码包地址信息和更新范围信息，生成规则信息。

通过本申请实施例对于图5的上述示例性实施可知，本申请实施例通过可视化界面接收用户针对每一待配置代码包的配置操作，进而基于该配置操作得到该待配置代码包的规则信息，提升了热更新过程中用户对于代码包发布的操作便捷性。

参见图6，图6是本申请实施例提供的热更新方法的一个可选的流程示意图，基于图5，在图5示出的步骤501之前，还可以包括步骤601至步骤603，步骤501可更新为步骤604，将结合图6示出的步骤进行说明。

在步骤601中，接收用户的配置查看请求。

在本申请的一些实施例中，服务器还可以接收用户针对存储的各业务代码包的配置查看请求，该配置查看请求用于查看已经存储的已配置代码包和待配置代码包。其中，该已配置代码包为经过上述实施例中以生成对应更新规则的待配置代码包。

在步骤602中，响应于配置查看请求，通过展示界面展示每一业务模块对应的代码包列表；代码包列表包括业务模块对应的待配置代码包和已配置代码包。

在本申请的一些实施例中，响应于该配置查看请求，服务器还可以生成用于显示已配置代码包和待配置代码包的展示界面，并通过用户侧的终端展示给用户。其中，服务器可以按照业务模块的不同，分别获取各业务模块对应的已配置代码包和待配置代码包，并通过各业务模块对应的代码包列表进行展示。

在步骤603中，通过展示界面接收用户针对待配置代码包的选择请求；

在步骤604中，响应于选择请求，跳转至配置界面，通过配置界面接收用户针对待配置代码包的配置操作。

通过本申请实施例对于图6的上述示例性实施可知，本申请实施例通过展示界面向用户呈现每一业务模块对应的已配置代码包和待配置代码包，便于用户对各业务模块的发布情况进行掌控；并且，本申请实施例还通过接收用户针对待配置代码包的选择请求，跳转至配置界面，简化了用户对于待配置代码包的操作步骤，提升了整体配置效率。

将结合本申请实施例提供的终端的示例性应用和实施，在本申请实施例中，将以终端为执行主体说明本申请实施例提供的热更新方法。

参见图7，图7是本申请实施例提供的热更新方法的一个可选的流程示意图，将结合图7示出的步骤进行说明。

在步骤701中，响应于客户端唤醒事件，终端向服务器发送规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息。

在本申请的一些实施例中，该客户端唤醒事件包括以下至少之一：待更新客户端启动，待更新客户端从后台状态切换至前台状态，待更新客户端的登录状态发生变化，待更新客户端的网络连接状态发生变更等。

在步骤702中，终端接收服务器发送的与运行信息匹配的至少一个目标规则信息。

在本申请的一些实施例中，服务器将根据终端发送的运行信息获取至少一个目标规则信息，其中，每一目标规则信息均对应一个业务模块。具体的实施过程可以参阅上述实施例，在此不再赘述。

在步骤703中，终端获取至少一个目标规则信息对应的目标业务代码包。

在步骤704中，终端根据目标业务代码包完成热更新过程。

在本申请的一些实施例中，在该待更新客户端下一次冷启动的过程中，终端会自动加载该目标业务代码包至内存中，此时，已经完成该目标业务代码包对应业务模块的热更新过程。其中，冷启动指的是该待更新客户端启动时，终端后台没有该待更新客户端的进程，这时系统会重新给待更新客户端分配一个进程，这种方法就叫冷启动。

通过本申请实施例对于图7的上述示例性实施可知，本申请实施例中终端响应于客户端唤醒事件，直接从服务器中获取该待更新客户端对应的至少一个目标规则信息，并基于该至少一个目标规则信息对应的目标业务代码包完成热更新过程，提升了更新效率；并且，由于目标业务代码包是以业务模块进行构建的，可以实现各个业务模块的单独更新，在提升各业务模块的开发效率和发布效率的基础上，提升了待更新客户端整体的热更新效率。

参见图8，图8是本申请实施例提供的热更新方法的一个可选的流程示意图，基于图7，图7所示的步骤702可以通过步骤801至步骤804实现，将结合图8示出的步骤进行说明。

在步骤801中，确定每一目标规则信息对应的目标业务模块和目标代码包版本信息。

在本申请的一些实施例中，每一个目标规则信息对应一个目标业务代码包，相应地，可以根据该目标业务代码包确定对应的目标业务模块，并且，该目标规则信息包括该目标业务代码包的目标代码包版本信息。

在步骤802中，获取待更新客户端中的每一目标业务模块对应的运行代码包版本信息。

在本申请的一些实施例中，待更新客户端在启动的时候，会首先初始化ReactNative运行环境，并且将所有业务模块读取到内存中，进行执行。按照React NativeBundle的文件组织结构初始化React Native运行环境的时候，会对于每个业务模块的目录中的所有代码包目录进行解析。选择其中版本最新的一个业务代码包进行使用。将这个业务代码包读取到内存中，并且进行执行。在步骤802中，终端将内存中各目标业务模块的业务代码包的代码包版本信息作为该目标业务模块的运行代码包版本信息。

在本申请的一些实施例中，在部分的目标业务模块没有运行在终端内存中的情况下，即该待更新客户端没有该目标业务模块对应的业务代码包的情况下，可以将对应的运行代码包信息设置为空。

在步骤803中，根据每一目标业务模块对应的运行代码包版本信息和目标代码包版本信息，确定至少一个待更新规则信息。

在本申请的一些实施例中，在目标业务模块对应的目标代码包版本信息比运行代码包版本信息更新的情况下，将该目标业务模块对应的目标规则信息确定为待更新规则信息。以代码包版本信息为版本号为例，版本号越大表示对应的代码包版本越新，目标业务代码包的版本号大于运行代码包的版本号时，将对应的目标规则信息确定为待更新规则信息。

在步骤804中，根据每一待更新规则信息中携带的目标业务代码包地址信息，获取目标业务代码包。

通过本申请实施例对于图8的上述示例性实施可知，本申请实施例中终端通过比对服务器下发的目标规则信息中目标代码包版本信息与内存中运行代码包版本信息，得到至少一个待更新规则信息，可以实现进一步对热更新过程进行控制，避免重复下载旧版本代码包的风险，不仅可以减轻终端的运行压力，也可以避免网络堵塞。

参见图9，图9是本申请实施例提供的热更新方法的一个可选的流程示意图，基于图7，图7所示的步骤704可以通过步骤901、步骤902实现，将结合图9示出的步骤进行说明。

在步骤901中，检测待更新客户端的运行状态；运行状态包括前台状态和后台状态。

在步骤902中，在待更新客户端的从前台状态切换至后台状态的情况下，将目标业务代码包加载至内存中，以完成热更新过程。

在本申请的一些实施例中，可以通过步骤9021和步骤9022实现上述将所述目标业务代码包加载至内存中：

在步骤9021中，获取目标业务代码包对应的业务模块的状态依赖信息。

在步骤9022中，在状态依赖信息表征业务模块不需要依赖当前运行状态的情况下，将目标业务代码包加载至内存中。其中，业务模块的状态依赖信息可以用于表征该业务模块在运行过程中是否需要历史运行状态。在需要将业务代码包加载至内存之前，通过解析该状态依赖信息，可以确定该业务代码包对应的业务模块在更新后是否依赖当前的运行状态，进而确定是否进行更新。

通过本申请实施例对于图9的上述示例性实施可知，本申请实施例可以在客户端从前台状态切换至后台状态的过程中，基于目标业务代码包对需要更新的业务模块进行热更新，不仅提升了覆盖率，而且可以在终端用户未感知的情况下完成热更新，提升了用户体验。

参见图10，图10是本申请实施例提供的热更新方法的一个可选的流程示意图，基于图7，图7所示的步骤704可以通过步骤1001、步骤1002实现，将结合图10示出的步骤进行说明。

在步骤1001中，在目标业务代码包对应的目标规则信息携带强制更新标记的情况下，监控待更新客户端的实例创建事件。

在步骤1002中，在实例创建事件依赖携带强制更新标记的目标业务代码包的情况下，将目标业务代码包加载至内存中；基于目标业务代码包创建实例，以完成热更新过程。

通过本申请实施例对于图10的上述示例性实施可知，本申请实施例通过强制更新功能，可以让线上有问题的客户端功能被强制覆盖到正常版本，提升发布的安全性和稳定性。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

近年来，随着移动设备硬件性能的提升以及业务快速迭代的需要，很多互联网产品都倾向于使用动态化的方式，在运行时更新用户本地代码来将新的功能提供给用户。

相关的动态化方案包括以下方案：(1)基于H5的hybrid APP方案；(2)基于tinker的android端动态化方案；(3)基于React Native的动态分发方案。

申请人经过研究发现上述方案存在以下优缺点：

(1)基于H5的hybrid APP方案，在业务侧代码更新之后，所有线上的用户都可以立即体验到最新的功能，具有最强的实时性。但是，由于H5依赖于iOS与Android两端的浏览器内核提供的WebView内核，在体验以及执行效率上都达不到原生的效果，在性能不是非常理想的用户端设备上，存在卡顿以及首屏渲染慢的问题。

(2)基于tinker的动态化方案，受限于iOS端闭源的问题，并不能够实现两端同时进行动态更新。

(3)React Native是一种开源的跨平台开发框架，基于JavaScriptCore进行代码解析，通过一层C++胶水层(粘合层)抹平了两端的差异，让一份代码可以同时运行在两端。由于React Native在运行时实际上是执行JavaScript代码，而JavaScript本身是解释型语言，所以可以通过直接将源代码分发到客户端的方式来实现热更新。并且，在React Native运行时，其会将JavaScript代码的执行结果映射到原生客户端的对应组件上，来实现原生渲染，所以，React Native可以实现近似客户端的渲染效果。

其中，对于React Native的热更新方案，存在以下两种常用的热更新方案：

(1)Pushy是一个开源的React Native热更新平台，提供了React Native发布和热更新的能力，支持增量更新以及CDN托管能力。(2)CodePush是微软开源的React Native代码托管平台，支持对于部分React Native功能进行热更新。

但是，申请人经过研究发现，Pushy和CodePush这两个开源的React Native热更新托管平台虽然提供了基础的热更新功能，但仍然存在以下缺点：

(1)Pushy对于分包的场景支持不足，目前大批量使用React Native作为客户端开发语言的APP都会在多个业务场景下进行使用，为了防止业务包较大，都会采用分包的方式，将业务包分成多个，在这种场景下，Pushy提供的支持不足；

(2)CodePush的代码托管基于微软的CDN实现，由于CDN位于海外，国内用户拉取更新较慢；

(3)Pushy和CodePush都缺少灰度发布以及可视化覆盖率监控；

(4)Pushy和CodePush都缺少多版本共存的能力；

(5)Pushy和CodePush在覆盖率方面都不能令人满意。

为了解决上述问题，本申请实施例提供了一种基于CDN和Redis的分发方案，可以达到以下技术效果：(1)提高了热更新的覆盖能力；(2)提供了热更新的可视化配置；(3)提高了发布上线效率；(4)支持React Native多包热更新；(5)支持多版本共存以及实现了灰度发布效果。

在本申请的一些实施例中，本申请提供的热更新方法可以应用到任何客户端产品中，能够让客户端产品得到热更新能力，提供不需要发布就能够将最新功能提供到客户端的能力。并且在此基础功能上，能够让用户更加可控地进行代码提交和热更新发布。通过对于热更新覆盖率的优化策略，让用户在无感知的情况下更新到最新功能。在需要快速迭代验证的场景下，比如电商、活动等场景，本申请可以让应用实现不需要客户端发布的功能更新，并且保证接近于原生的用户体验。在需要A/B测试验证功能效果的场景下，比如某些策略修改或者功能更新需要进行效果验证的时候，可以通过本申请的灰度功能进行针对性的A/B测试。解决了现有的React Native热更新流程的覆盖率慢，缺少灰度和可视化的痛点和问题。

请参阅图11提供的热更新系统架构示意图，其中，本系统提供了一套完整的ReactNative的热更新分发过程，包括：代码提交持续集成A1，规则配置A2和客户端加载A3。通过CDN托管平台可以加快用户拉取代码更新的速度，并且通过云端构建服务，将持续集成和发布过程进行收敛，简化发布路径。

在本申请的一些实施例中，针对代码提交持续集成A1的过程，开发人员在源代码提交之后，会触发代码托管平台(例如Gitlab)的钩子，代码托管平台会将这次提交事件，报告到持续集成工具(例如Jenkins)当中，持续集成工具会将代码托管平台上的代码进行拉取，并且执行构建过程，通过构建可以得到可执行的业务代码包(即React Native代码包，以下简称Bundle)。其中，在构建过程中，会按照客户端的业务维度进行拆分，得到的是每一个业务模块对应的业务代码包。

在本申请的一些实施例中，针对规则配置A2，本申请可以针对每一个业务模块的业务代码包可以设置对应的配置规则，其中，该配置规则可以包括以下至少之一：

(1)支持使用本次欲发布Bundle的用户ID尾号；

(2)本次欲发布Bundle的版本号，类型为一个递增的整型数值；

(3)本次欲发布Bundle的CDN链接；

(4)可以使用本次欲发布Bundle的APP版本范围；

(5)Bundle构建的基础信息，包含提交记录，构建流水线信息，触发人信息等。

在本申请的一些实施例中，配置平台可以通过CDN提供的批量拉取接口，将对应的Bundle列表拉取下来，并显示于交互界面中，用户可以在该交互界面选择需要本次预发布的Bundle，跳转至对应的配置界面，用户可以根据本次预发布的Bundle需要覆盖的用户和设备群体，在配置界面中填写上述的规则信息。配置平台通过配置界面接收用户输入的配置操作，生成本次预发布的Bundle的配置规则。例如，可以通过图12所示的配置界面接收用户输入的配置操作，其中，该配置界面1200包括配置规则填写区域1201和保存选项1202，在接收到用户针对“保存”选项的选择操作之后，生成当前Bundle的配置规则。

在本申请的一些实施例中，对于每一个业务代码包对应的配置规则，可以按照各业务代码包对应的业务模块，进行分组显示。例如，在上述交互界面1200中，还可以包括则显示区域1203，在规则显示区域中，显示本次预发布的Bundle所属业务模块对应的其他Bundle及相应的配置规则。

在本申请的一些实施例中，配置平台还可以接收用户针对任意业务模块的选择操作，进而在该交互界面显示该选择操作对应的业务模块的所有Bundle及相应的配置规则。

请参阅图13提供的配置分发过程示意图。在图13中，该配置分发过程主要包括业务代码包构建阶段1301、配置阶段1302和拉取阶段1303。

在本申请的一些实施例中，该业务代码包构建阶段1301和配置阶段1302与上述实施例中的代码提交持续集成过程和分发配置过程相同。

在本申请的一些实施例中，拉取阶段1303包括：在用户保存之后，会本次预发布的Bundle的配置规则保存至数据库中(例如Redis)，并且触发一个同步请求至所有的分发服务，这些分发服务主动去数据拉取最新的配置规则，并且解析为格式化的配置列表。其中，每个业务模块的配置列表，都会按照各配置规则中的Bundle版本号降序排序，也就是按照配置规则的保存时间降序排序。

在本申请的一些实施例中，当APP在被唤醒之后，会发送携带自己的元信息(对应上述实施例中的运行信息)的请求至分发服务，包括用户ID，APP版本号等。分发服务在收到这个请求之后，从请求中读取该用户的元信息，从头至尾遍历整个配置列表。当遇到了第一个符合用户元信息条件的配置规则后，会停止遍历，将该配置规则返回至APP。

请参阅图14提供的客户端热更新的流程示意图，该热更新流程主要应用于终端中待更新的客户端，将结合图12示出的步骤进行说明。

在步骤B1中，启动客户端APP；

在步骤B2中，请求分发服务以拉取各业务模块的最新版本信息；

在步骤B3中，解析最新版本信息；

在步骤B4中，加载本地中各业务模块的业务代码包；

在步骤B5中，获取各业务模块的本地版本信息；

在步骤B6中，根据最新版本信息和本地版本信息判断是否需要版本更新；

在本申请的一些实施例中，在最新版本信息大于本地版本信息的情况下，判定需要版本更新，执行步骤B7；在本地版本信息大于最新版本信息的情况下，判定不需要版本更新，执行步骤B14。

在步骤B7中，从托管平台(CDN)中获取对应的业务代码包；

在步骤B8中，按照各业务代码包的版本信息和本地存储结构，存储至本地；

在步骤B9中，启动React Native模块；

在步骤B10中，应用最新的业务代码包；

在步骤B11中，客户端退到后台；

在步骤B12中，判断是否有存活的依赖模块状态的React Native模块；

在本申请的一些实施例中，该依赖模块状态的React Native模块指的是该ReactNative模块在重载之后，之前的模块状态会丢失，为了避免该情况，步骤B12会判断是否有存活的依赖模块状态的React Native模块；在不存在存活的依赖模块状态的React Native模块的情况下，判定需要版本更新，执行步骤B13；在存在存活的依赖模块状态的ReactNative模块的情况下，判定不需要版本更新，执行步骤B14。

在步骤B13中，重载React Native模块；

在步骤B14中，结束。

在本申请的一些实施例中，如图15所示的代码包存储架构示意图，客户端侧会将React Native的Bundle按照业务模块以及Bundle热更新版本号两个维度来组织。每个业务的目录下都会存在多个热更新Bundle。每个热更新Bundle的目录名均为配置平台规则集中的版本号字段，为一个按照时间顺序递增的整型数字。

在本申请的一些实施例中，客户端在启动的时候，会首先初始化React Native运行环境，并且将所有业务模块读取到内存中，进行执行。其中，按照React Native Bundle的文件组织结构，初始化React Native运行环境的时候，会对于每个业务的目录中的所有Bundle目录进行解析。选择其中版本号最大的一个Bundle进行使用。将这个Bundle读取到内存中，并且进行执行。

当客户端唤醒的时候，会向分发服务发送一个网络请求，并且携带上述元信息，包含用户ID、APP版本号等字段。

分发服务会将符合当前元信息的所有规则集返回至客户端。客户端会优先匹配本地的版本号，如果分发服务返回的Bundle版本号大于客户端本地，那么客户端会尝试去CDN拉取对应的Bundle，在Bundle拉取成功之后，将其按照分发服务下发的版本号，存储至客户端本地。当客户端下一次冷启动之后，就会自动使用到最新的代码，完成一次最基本的热更新操作。

为了进行热更新覆盖率的提升，本申请采用了两种优化方案：

(1)后台热更新：React Native模块会监听客户端生命周期，当客户端退到后台的时候，会检测当前所有业务模块正在使用的Bundle版本，与客户端本地存储的Bundle最新版本进行对比，如果客户端本地有版本号大于客户端当前使用的Bundle时，客户端会执行一次React Native的更新行为。将原有的React Native组件进行卸载，并且将最新的Bundle代码加载到内存中，进行一次新的挂载操作。在客户端再次唤醒的时候，客户端中使用的React Native代码就会使用最新的版本。

(2)强制更新：当分发服务下发的规则集中带有强制更新标记的时候，客户端会监测每个React Native业务实例的创建行为，当一个新的实例创建的时候，客户端就会检查这个实例是否依赖于带有强制更新标记的业务模块，如果符合该条件，则客户端会执行一次React Native的更新行为。与后台热更新类似，将最新的Bundle代码加载到内存中，并且重建React Native实例。如果Bundle代码还未从CDN拉取完成，则会进行同步阻塞拉取，如果在指定时间内，新的代码还没有拉取回来，则允许客户端直接使用旧的版本实例化ReactNative模块。

通过本申请实施例可以产生以下有益效果：(1)本申请可以让客户端代码动态下发至用户客户端，并且基于用户元信息进行灰度发布，并且支持对于不同客户端版本的用户下发不同的业务代码。(2)在基础功能之上，对于覆盖率进行优化，保证大部分用户能够被快速触达。(3)通过强制更新功能，可以让线上有问题的客户端功能被强制覆盖到正常版本，提升发布的安全性和稳定性。

下面继续说明本申请实施例提供的热更新装置555的实施为软件模块的示例性结构，在本申请的一些实施例中，如图2A所示，存储在存储器550的热更新装置555中的软件模块包括：

第一接收模块5551，用于接收终端发送的规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息；

第一获取模块5552，用于获取待更新客户端的每一业务模块的规则集合；规则集合包括业务模块对应的至少一个规则信息；

确定模块5553，用于基于运行信息和每一业务模块对应的至少一个规则信息，确定至少一个目标规则信息；

第一更新模块5554，用于将至少一个目标规则信息发送至终端，以使终端根据至少一个目标规则信息对应的目标业务代码包完成待更新客户端的热更新过程。

在本申请的一些实施例中，所述规则信息包括：代码包版本信息和更新范围信息；所述确定模块5553还用于在业务模块对应的至少一个规则信息中，筛选更新范围信息与运行信息匹配的待确定规则信息；在存在至少一个待确定规则信息的情况下，将代码包版本信息最新的待确定规则信息确定为目标规则信息。

在本申请的一些实施例中，所述规则信息还包括：代码包地址信息。

在本申请的一些实施例中，所述热更新装置555还包括配置模块，所述配置模块用于：获取待更新客户端对应的待更新源代码；以待更新客户端的业务模块作为构建维度，将待更新源代码构建为至少一个待配置代码包；确定每一待配置代码包的规则信息；将每一待配置代码包的规则信息保存至每一待配置代码包对应的业务模块的规则集合。

在本申请的一些实施例中，所述配置模块还用于：通过配置界面接收用户针对待配置代码包的配置操作；根据配置操作确定待配置代码包的规则信息。

在本申请的一些实施例中，所述配置模块还用于：接收用户的配置查看请求；响应于配置查看请求，通过展示界面展示每一业务模块对应的代码包列表；代码包列表包括业务模块对应的待配置代码包和已配置代码包；通过展示界面接收用户针对待配置代码包的选择请求；响应于选择请求，跳转至配置界面，通过配置界面接收用户针对待配置代码包的配置操作。

在本申请的一些实施例中，所述配置模块还用于：响应于配置界面的生成事件，生成待配置代码包的代码包版本信息，并获取待配置代码包的代码包地址信息；根据配置操作，确定待配置代码包的更新范围信息；更新范围信息包括以下至少之一：客户端范围信息和用户范围信息；基于代码包版本信息、代码包地址信息和更新范围信息，生成规则信息。

下面继续说明本申请实施例提供的热更新装置655的实施为软件模块的示例性结构，在本申请的一些实施例中，如图2B所示，存储在存储器650的热更新装置655中的软件模块包括：

发送模块6551，用于响应于客户端唤醒事件，向服务器发送规则信息获取请求；规则信息获取请求携带终端中待更新客户端的运行信息；

第二接收模块6552，用于接收服务器发送的与运行信息匹配至少一个目标规则信息；

第二获取模块6553，用于获取至少一个目标规则信息对应的目标业务代码包；

第二更新模块6554，用于根据目标业务代码包完成热更新过程。

在本申请的一些实施例中，所述第二获取模块6553还用于：获取每一目标规则信息中携带的目标代码包版本信息，和每一目标规则信息对应的业务模块；获取待更新客户端中每一业务模块对应的运行代码包版本信息；根据每一业务模块对应的运行代码包版本信息和目标代码包版本信息，确定至少一个待更新规则信息；根据每一待更新规则信息中携带的目标业务代码包地址信息，获取目标业务代码包。

在本申请的一些实施例中，所述第二更新模块6554还用于：检测待更新客户端的运行状态；运行状态包括前台状态和后台状态；在待更新客户端的从前台状态切换至后台状态的情况下，将目标业务代码包加载至内存中，以完成热更新过程。

在本申请的一些实施例中，所述第二更新模块6554还用于：获取目标业务代码包对应的业务模块的状态依赖信息；在状态依赖信息表征业务模块不需要依赖当前运行状态的情况下，将目标业务代码包加载至内存中。

在本申请的一些实施例中，所述第二接收模块6552，还用于：在目标业务代码包对应的目标规则信息携带强制更新标记的情况下，监控待更新客户端的实例创建事件；，所述第二更新模块6554还用于：在实例创建事件依赖携带强制更新标记的目标业务代码包的情况下，将目标业务代码包加载至内存中；基于目标业务代码包创建实例，以完成热更新过程。

本公开实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的热更新方法。

本公开实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的热更新方法，例如，如图3至图10示出的方法。

在本申请的一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在本申请的一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，通过本申请实施例能够实现以下技术效果：

(1)本申请实施例通过获取终端的运行信息，并与每一业务模块对应的至少一个规则信息进行匹配，确定符合要求的至少一个目标规则信息，将至少一个目标规则信息发送至终端，以使终端基于该至少一个目标规则信息对应的目标物代码包完成待更新客户端的热更新过程。如此，服务器可以根据登录该待更新客户端的用户标识，进而实现灰度发布的效果，并且，服务器还可以基于不同的待更新客户端的客户端版本，确定不同的目标规则信息，进而使不同客户端版本的待更新客户端获取不同的目标业务代码包；同时，本申请将待更新客户端的更新任务划分为不同业务模块的更新任务，实现了各个业务模块的单独更新，在提升各业务模块的开发效率和发布效率的基础上，提升了待更新客户端整体的热更新效率。

(2)本申请实施例在构建过程中，以待更新客户端的业务模块作为构建维度，实现了各业务模块对应的待配置代码包的获取；同时，通过确定每一待配置代码包的规则信息，更新了每一业务模块对应的规则集合，在确定终端对应的至少一个目标规则信息的过程中，可以保证获取到最新的规则信息，进一步提升热更新效率。

(3)本申请实施例通过可视化界面接收用户针对每一待配置代码包的配置操作，进而基于该配置操作得到该待配置代码包的规则信息，提升了热更新过程中用户对于代码包发布的操作便捷性。

(4)本申请实施例通过展示界面向用户呈现每一业务模块对应的已配置代码包和待配置代码包，便于用户对各业务模块的发布情况进行掌控；并且，本申请实施例还通过接收用户针对待配置代码包的选择请求，跳转至配置界面，简化了用户对于待配置代码包的操作步骤，提升了整体配置效率。

(5)本申请实施例中终端响应于客户端唤醒事件，直接从服务器中获取该待更新客户端对应的至少一个目标规则信息，并基于该至少一个目标规则信息对应的目标业务代码包完成热更新过程，提升了更新效率；并且，由于目标业务代码包是以业务模块进行构建的，可以实现各个业务模块的单独更新，在提升各业务模块的开发效率和发布效率的基础上，提升了待更新客户端整体的热更新效率。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种热更新方法，其特征在于，应用于服务器，所述方法包括：

接收终端发送的规则信息获取请求；所述规则信息获取请求携带所述终端中待更新客户端的运行信息；

获取所述待更新客户端的每一业务模块的规则集合；所述规则集合包括所述业务模块对应的至少一个规则信息；

基于所述运行信息和每一所述业务模块对应的至少一个规则信息，确定至少一个目标规则信息；

将所述至少一个目标规则信息发送至所述终端，以使所述终端根据所述至少一个目标规则信息对应的目标业务代码包完成所述待更新客户端的热更新过程。

2.根据权利要求1所述的方法，其特征在于，所述规则信息包括：代码包版本信息和更新范围信息；所述基于所述运行信息和每一所述业务模块对应的至少一个规则信息，确定至少一个目标规则信息，包括：

在所述业务模块对应的至少一个规则信息中，筛选更新范围信息与所述运行信息匹配的待确定规则信息；

在存在至少一个所述待确定规则信息的情况下，将代码包版本信息最新的待确定规则信息确定为所述目标规则信息。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取所述待更新客户端对应的待更新源代码；

以所述待更新客户端的业务模块作为构建维度，将所述待更新源代码构建为至少一个待配置代码包；

确定每一所述待配置代码包的规则信息；

将每一所述待配置代码包的规则信息保存至每一所述待配置代码包对应的业务模块的规则集合。

4.根据权利要求3所述的方法，其特征在于，所述确定每一所述待配置代码包的规则信息，包括：

通过配置界面接收用户针对所述待配置代码包的配置操作；

根据所述配置操作确定所述待配置代码包的规则信息。

5.根据权利要求4所述的方法，其特征在于，在所述通过配置界面接收用户针对所述待配置代码包的配置操作之前，所述方法还包括：

接收用户的配置查看请求；

响应于所述配置查看请求，通过展示界面展示每一所述业务模块对应的代码包列表；所述代码包列表包括所述业务模块对应的待配置代码包和已配置代码包；

通过所述展示界面接收用户针对待配置代码包的选择请求；

响应于所述选择请求，跳转至所述配置界面，通过所述配置界面接收用户针对所述待配置代码包的配置操作。

6.根据权利要求4所述的方法，其特征在于，所述根据所述配置操作确定所述待配置代码包的规则信息，包括：

响应于所述配置界面的生成事件，生成所述待配置代码包的代码包版本信息，并获取所述待配置代码包的代码包地址信息；

根据所述配置操作，确定所述待配置代码包的更新范围信息；所述更新范围信息包括以下至少之一：客户端范围信息和用户范围信息；

基于所述代码包版本信息、所述代码包地址信息和所述更新范围信息，生成所述规则信息。

7.一种热更新方法，其特征在于，应用于终端，所述方法包括：

响应于客户端唤醒事件，向服务器发送规则信息获取请求；所述规则信息获取请求携带所述终端中待更新客户端的运行信息；

接收所述服务器发送的与所述运行信息匹配至少一个目标规则信息；

获取所述至少一个目标规则信息对应的目标业务代码包；

根据所述目标业务代码包完成热更新过程。

8.一种热更新装置，其特征在于，包括：

接收模块，用于接收终端发送的规则信息获取请求；所述规则信息获取请求携带所述终端中待更新客户端的运行信息；

获取模块，用于获取所述待更新客户端的每一业务模块的规则集合；所述规则集合包括所述业务模块对应的至少一个规则信息；

确定模块，用于基于所述运行信息和每一所述业务模块对应的至少一个规则信息，确定至少一个目标规则信息；

更新模块，用于将所述至少一个目标规则信息发送至所述终端，以使所述终端根据所述至少一个目标规则信息对应的目标业务代码包完成所述待更新客户端的热更新过程。

9.一种热更新设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至6任一项所述的方法，或，实现权利要求7所述的方法。

10.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于被处理器执行时，实现权利要求1至6任一项所述的方法，或，实现权利要求7所述的方法。

Images