CN110187910B

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

Info

Publication number: CN110187910B
Application number: CN201910475059.9A
Authority: CN
Inventors: 张硕; 黄沛鑫
Original assignee: Tencent Technology Shanghai Co Ltd
Current assignee: Tencent Technology Shanghai Co Ltd
Priority date: 2019-05-30
Filing date: 2019-05-30
Publication date: 2023-09-05
Anticipated expiration: 2039-05-30
Also published as: CN110187910A

Abstract

本发明实施例公开了一种热更新方法、装置、设备及计算机可读存储介质。该方法包括：首先获取热更新所需的目标文件，该目标文件与目标客户端使用相同的目标语言，然后根据所述目标文件初始化用于实现代码热更新的平台；所述平台包括基于所述目标语言开发的平台，通过该初始化后的平台，将目标文件中的热更新函数替换目标客户端中对应的待热更新函数，实现对目标客户端的热更新。采用本发明实施例，能够实现热更新，并提高热更新的效率。

Description

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

技术领域

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

背景技术

热更新是一种各大手游等众多APP常用的更新方式，简单来说，就是在用户打开APP时遇到的即时更新，它可以使开发者在不发布新版本的情况下，修复BUG和发布功能，让开发者得以绕开审核机制，避免长时间的审核等待以及多次被拒造成的成本。

现有技术通过xLua和ILRuntime来进行热更新，xLua为Unity、Net、Mono等C#环境增加Lua脚本编程的能力，借助xLua，这些Lua代码可以方便的和C#相互调用，即可实现游戏的代码热更新，也可使用Lua代码对已有的C#代码进行补丁修复，然而这种方式需要开发人员掌握两种开发语言(C#和Lua)，对于比较大的函数，翻译起来工作量会很大；ILRuntime是通过提供外部代码的方式进行热更新，但ILRuntime提供的代码是在外部运行的，性能不好，而如果选择在unity里面写，当unity存在bug时，就不能进行热更新了。因此，如何提高热更新的效率是本领域技术人员正在研究的问题。

发明内容

本发明实施例公开了一种热更新方法、装置、设备及计算机可读存储介质，能够实现热更新，并提高热更新的效率。

第一方面，本发明实施例提供了一种热更新方法，该方法包括：

获取热更新所需的目标文件，所述目标文件使用的开发语言与目标客户端使用的开发语言为相同的目标语言；

根据所述目标文件初始化用于实现代码热更新的平台；所述平台包括基于所述目标语言开发的平台；

通过初始化后的所述平台，将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数，所述目标文件中包括所述热更新函数和所述目标客户端中的待热更新函数的对应关系。

在上述方法中，首先获取热更新所需的目标文件，该目标文件与目标客户端使用相同的目标语言，然后根据所述目标文件初始化用于实现代码热更新的平台；所述平台包括基于所述目标语言开发的平台，通过初始化后的平台，将目标文件中的热更新函数替换目标客户端中对应的待热更新函数。在这个过程中，通过热更新函数对目标客户端中对应的待热更新函数替换实现了对目标客户端的热更新，通过使用统一目标语言提高热更新效率。

基于第一方面，在其中一种可选的实现方式中，所述将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数，具体包括：

根据所述目标文件获取所述目标客户端中对应的待热更新函数的类；

根据输入的配置表参数，计算出与所述待热更新函数的类相对应的静态变量对应的变量名，并获取所述静态变量的引用，所述配置表参数包括所述待热更新函数的类和所述静态变量对应的变量名之间的对应关系；

根据所述静态变量以及所述配置表参数，通过反射获取所述热更新函数的类及其中相应的所述热更新函数；

将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数。

基于第一方面，在其中一种可选的实现方式中，所述目标文件还包括第一组件，所述第一组件用于通过所述目标客户端中的类调用monobehavior的功能，所述目标客户端中的类继承了Monobehavior的类。

基于第一方面，在其中一种可选的实现方式中，所述目标文件还包括第二组件，所述第二组件用于使用所述目标客户端中的类中除了所述Monobehavior以外的功能。

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

通过预设规则搜集第一场景的待热更新函数；

通过输入的热更新函数，建立所述热更新函数与所述第一场景的待热更新函数的对应关系；

根据所述热更新函数和所述对应关系生成所述目标文件，所述目标文件用于热更新目标客户端。

在上述方法中，首先通过预设规则搜集第一场景的待热更新函数，然后通过输入的热更新函数，建立热更新函数与待热更新函数的对应关系，根据所述热更新函数和所述对应关系生成目标文件，该目标文件用于热更新目标客户端。通过建立热更新函数与待热更新函数的对应关系，为实现热更新做好了预处理，提供了目标文件。

基于第二方面，在其中一种可选的实现方式中，所述目标文件还包括中间键类，所述中间键类包括对象变量和静态变量，所述对象变量用于存储函数，所述函数用于执行在所述目标文件中的目标函数替换所述目标客户端中对应的函数之后；所述静态变量插入在所述待热更新函数中，用于指示所述待热更新函数是否需要进行替换。

基于第二方面，在其中一种可选的实现方式中，所述根据所述热更新函数和所述对应关系生成所述目标文件之前，包括：

判断所述第一场景的待热更新函数是否全部建立与所述热更新函数的对应关系；

若全部建立完成，且存在第二场景，通过预设规则搜集所述第二场景的待热更新函数，所述第二场景与所述第一场景不同；

通过输入的热更新函数，建立所述热更新函数与所述第二场景的待热更新函数的对应关系。

这种实现方式通过对目标客户端多个场景中的待热更新函数的搜集，对所有场景下的待热更新函数进行注入，提高了热更新的效率。

第三方面，本发明实施例提供了一种热更新装置，包括：

获取单元，用于获取热更新所需的目标文件，所述目标文件使用的开发语言与目标客户端使用的开发语言为相同的目标语言；

初始化单元，用于根据所述目标文件初始化用于实现代码热更新的平台；所述平台包括基于所述目标语言开发的平台；

替换单元，用于通过初始化后的所述平台，将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数，所述目标文件中包括所述热更新函数和所述目标客户端中的待热更新函数的对应关系。

需要说明的是，第三方面的实现方式及相应的有益效果可以参照第一方面以及相应实现方式中的描述，此处不再赘述。

第四方面，本发明实施例提供了一种热更新装置，包括：

搜集单元，用于通过预设规则搜集第一场景的待热更新函数；

建立单元，用于通过输入的热更新函数，建立所述热更新函数与所述第一场景的待热更新函数的对应关系；

生成单元，用于根据所述热更新函数和所述对应关系生成所述目标文件，所述目标文件用于热更新所述服务器对应的目标客户端。

需要说明的是，第四方面的实现方式及相应的有益效果可以参照第二方面以及相应实现方式中的描述，此处不再赘述。

第五方面，本发明实施例提供了一种热更新设备，包括处理器、存储器和通信设备，所述处理器、存储器和通信设备相互连接，其中，所述通信设备用于与外部设备进行信息交互；所述存储器存储可执行程序代码；所述处理器被配置用于调用存储的程序代码，执行包括：

通过所述通信设备获取热更新所需的目标文件，所述目标文件使用的开发语言与目标客户端使用的开发语言为相同的目标语言；

需要说明的是，第五方面的实现方式及相应的有益效果可以参照第一方面以及相应实现方式中的描述，此处不再赘述。

第六方面，本发明实施例提供了一种热更新设备，包括处理器、存储器和通信设备，所述处理器、存储器和通信设备相互连接，其中，所述通信设备用于与外部设备进行信息交互；所述存储器存储可执行程序代码；所述处理器被配置用于调用存储的程序代码，执行包括：

通过预设规则搜集第一场景的待热更新函数；

根据所述热更新函数和所述对应关系生成所述目标文件，所述目标文件用于热更新所述服务器对应的目标客户端。

需要说明的是，第六方面的实现方式及相应的有益效果可以参照第二方面以及相应实现方式中的描述，此处不再赘述。

第七方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序指令，所述程序指令当被处理器执行时使所述处理器执行第一方面所述的方法。

需要说明的是，第七方面的实现方式及相应的有益效果可以参照第一方面以及相应实现方式中的描述，此处不再赘述。

第八方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序指令，所述程序指令当被处理器执行时使所述处理器执行第一方面所述的方法。

需要说明的是，第八方面的实现方式及相应的有益效果可以参照第二方面以及相应实现方式中的描述，此处不再赘述。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对本发明实施例或背景技术中所需要使用的附图作简单地介绍。

图1是本发明实施例提供的一种热更新方法的系统架构图；

图2是本发明实施例提供的一种热更新方法的原理流程图；

图3是本发明实施例提供的一种热更新方法的流程示意图；

图4是本发明实施例提供的一种热更新方法的编程界面图；

图5是本发明实施例提供的有一种热更新方法的编程界面图；

图6是本发明实施例提供的又一种热更新方法的流程示意图；

图7是本发明实施例提供的一种热更新装置的结构示意图；

图8是本发明实施例提供的又一种热更新装置的结构示意图；

图9是本发明实施例提供的一种热更新设备的结构示意图；

图10是本发明实施例提供的又一种热更新设备的结构示意图。

具体实施方式

下面将结合附图对本发明实施例中的技术方案进行描述。

应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。在本申请说明书中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。在本说明书中使用的术语“设备”、“单元”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，设备可以是但不限于，处理器，数据处理平台，计算设备，计算机，2个或更多个计算机等。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

为了更好的理解本发明实施例提供的一种热更新方法、装置及计算机可读存储介质，下面先对本发明实施例的热更新方法的系统架构进行描述。如图1所示，其为本发明实施例提供的一种热更新方法的系统架构示意图，

系统架构可以包括一个或多个服务器(多个服务器可以构成一个服务器集群)，以及一个或多个终端(或设备)，这个服务器与本地终端构成一个系统，其中：

服务器可以包括但不限于后台服务器、组件服务器、数据处理服务器等，服务器可以通过互联网与多个终端进行通信。服务器为终端提供热更新服务。服务器上需要运行有相应的服务器端程序来提供相应的热更新服务，如数据库服务、数据计算等等。

终端可以安装并运行相关的客户端。客户端是指与服务器相对应，为客户提供本地服务的程序。这里，该本地服务可包括但不限于：向服务器发送信息(例如请求信息)和接收服务器发送的信息(例如目标文件)以及共享信息等等。本方案实施例中的终端可以包括但不限于任何一种基于智能操作系统的电子产品，其可与用户通过键盘、虚拟键盘、触摸板、触摸屏以及声控设备等输入设备来进行人机交互，诸如智能手机、平板电脑、个人电脑等。其中，智能操作系统包括但不限于任何通过向移动设备提供各种移动应用来丰富设备功能的操作系统，诸如安卓(Android^TM)、iOS^TM、Windows Phone^TM等。

在本申请实施例中，提供了一种基于ILRuntime的C#代码的热更新方案，ILRuntime项目为基于C#的平台(例如Unity)提供了一个纯C#实现，快速、方便且可靠的IL运行时，使得在不支持JIT的硬件环境(如iOS)能够实现代码的热更新。其实现原理是，ILRuntime借助Mono.Cecil库来读取DLL的PE信息，以及其中类型的所有信息，最终得到方法的IL汇编码，然后通过内置的IL解译执行虚拟机来执行DLL中的代码。白话来讲，就是自主建立了一个IL的解析虚拟机，来解析执行加载进来的DLL。具体原理如图2所示，将不同类型的开发语言(如Lua、C#、VB、C++等)编写的热更新代码通过mono编译成IL字节码，通过建立的IL汇编器编译到DLL文件中，当客户端加载该DLL文件时，执行IL字节码，然后初始化ILRuntime，加载热更新代码。

其中，Mono是一个自由开放源代码项目。该项目的目标是创建一系列匹配ECMA标准(Ecma-334和Ecma-335)的.NET工具，包括C#编译器和通用语言架构。与微软的.NETFramework(共通语言运行平台)不同，Mono项目不仅可以运行于Windows系统上，还可以运行于Linux，FreeBSD，Unix，OS X和Solaris，甚至一些游戏平台，例如：Playstation 3，Wii或XBox 360。Mono的类库为应用程序开发提供一套广泛而有效的工具类。这些工具类本是采用C#编写的，但是由于.NET采用的公共语言运行时，它们可以用于任何.NET语言。类库被按命名空间进行了结构化，并被放置于称为程序集的共享库中。

下面结合图3就本申请的热更新方法进行说明，如图3所示，其为本申请实施例提供的一种热更新方法的流程示意图，该方法可以基于图1所示的系统架构或者其他架构来实现，该方法可以包括但不限于以下步骤：

步骤S301：获取热更新所需的目标文件。

具体地，用户启动目标客户端后，目标客户端自动获取热更新所需的目标文件，目标文件使用的开发语言与目标客户端使用的开发语言相同，目标客户端为需要热更新的客户端，该开发语言可以是C#；其中，热更新的代码写在一个VS工程中，目标文件为该VS工程生成的DLL文件，目标文件的热更新的代码中包括中间键、第一组件以及第二组件等部分；

其中，中间键Wrapper用于连通目标文件中的热更新代码和目标客户端中的原工程代码，客户端中的原工程能通过中间键Wrapper使用反射调用Mono的相关功能，也就是在中间键Wrapper中写一个空函数(包括Awake函数和Start函数等)，然后在原工程的待热更新函数中调用目标文件中的外部类的相应函数即可；举例来说，如图4所示，在热更新的过程中，可以通过中间键Wrapper将继承了MonoBehavior的脚本放在热更新工程中，如图5所示，可以通过中间键Wrapper将继承了UIWindow的脚本放在热更新工程中，该UIWindow是一个通过用户自定义的继承了MonoBehavior的类，与图4的MonoBehaviorWrapper一起使用。

该中间键Wrapper还可以响应UI事件，也就是能为NGUI或者UGUI提供相应事件的函数，通过直接提供相应以string为传入参数的函数的方式，以供UI事件调用。需要注意的是，与UGUI不同，NGUI没法直接传string，只能通过GameObject来间接传string值(例如某些手游中直接使用Transform.name物体的名字来作为string传入)，至于在ILRuntime中，通过编写对应对象的OnClick(通过点击触发)的方法即可。

第一组件，即基础组件，在本申请实施例中通过ILRuntime可以直接使用其跨域继承的机制，来实现目标文件的外部类中对客户端原工程中继承父类的成员的使用。通过ILRuntime的这个跨域继承机制，外部继承MonoBehavior的类，实际运行时的继承顺序是：外部类->ILMonoBehaviourAdaptor->MonoBehavior，这里的Adapter只是起到了一个中间键转换的作用。通过继承的方式可以透过继承父类的成员，来调用MonoBehavior里面本身的功能(比如协程)，对功能的实现更方便，举例来说，通过调用图4中继承了MonoBehavior的脚本，来调用MonoBehavior里面本身的功能。基础组件主要负责的功能有：实例化外部类(即在外部对客户端内部类的实例化和引用)，序列化与反序列化功能，MonoBehavior相关功能(比如协程)，UI点击事件实现等。

第二组件，即扩展组件，是在外部类中继承另一个继承了MonoBehavior的类，例如火影手游中的UIWindow类。通过该继承的方式可以使用继承父类的成员的功能(只包括MonoBehavior以外的自身的功能)，举例来说，通过调用图5中继承了UIWindow的脚本，来调用UIWindow中除了MonoBehavior以外的本身的功能，也即是说，基础组件和扩展组件共同组成了该继承父类的成员的全部功能，使用组合的方式，让BehaviorWrapper作为基础组件，外加一个扩展组件(加了另外一个wrapper)，就可以实现隔代继承的全部功能了，扩展组件负责的功能有：获取基础组件中实例化出来的外部类以供使用，以及所有扩展组件继承父类的成员的功能。

在其中一个实施方式中，该中间键还具备对数据的序列化与反序列化功能，如果目标客户端检测到目标文件的外部类中是引用外部的mono类，则需要在序列化和反序列时进行处理，在序列化时，客户端内部存储不变，但用于检测的对象Inspection上显示的应该是中间键Wrapper类型(也就是只更改了存储的外部变量的值)，以便能直接赋值，即将外部变量的值赋值到中间键Wrapper；在反序列化时，在将Wrapper在Inspection上显示的参数(即序列化中存储的值)，同步到目标对象中时，需要取Wrapper中的目标对象(通过实现CrossBindingAdaptorType接口得到)。也就是说，存储的时候，存储的是一个Wrapper，取值的时候，取的是Wrapper中的目标对象。

步骤S302：根据所述目标文件初始化用于实现代码热更新的平台；所述平台包括基于所述目标语言开发的平台。

具体地，目标客户端获取热更新所需的目标文件后，根据目标文件初始化ILRuntime，ILRuntime是基于C#开发的平台，与目标客户端的开发语言相同，为了每次都能使用最新的用于热更新的资源补丁，所以将初始化ILRuntime的操作放在热更新完资源之后。

步骤S303：通过初始化后的平台，将目标文件中的热更新函数替换目标客户端中对应的待热更新函数。

具体地，目标文件中包括热更新函数和目标客户端中的待热更新函数的对应关系。初始化完成之后，通过读取目标文件中定义的一个注册函数来实现热更新函数和待热更新函数的替换，该注册函数的API如下：

public static void RegHookWithParamType(Type mainType,stringmainMethodName,string fixMethodName,params Type[]paramTypes)

该注册函数的参数分别释义如下：mainType代表要热修复函数所属的类，mainMethodName代表要被热修复函数的名字，fixMethodName代表要用于修复该函数的对应的函数名，paramTypes是可选参数数组，代表要被热修复函数中所有的参数类型；即该注册函数建立了热更新函数与待热更新函数的对应关系，通过该对应关系，客户端将目标文件中的热更新函数替换客户端中对应的待热更新函数，实现对目标客户端的热更新。

可以理解的，也有相应的解除该函数热修复的映射关系的接口，使用这个接口可以解除热更新函数和待热更新函数的对应关系，之后就可以直接调用原函数来使用原函数的功能(比如对原函数的修复，只是在原函数执行完成后继续执行一些代码)，因此可以让替换后的函数写起来更加简洁高效，从而更方便的完成修复。解除该函数热修复的映射关系的接口后，即解除了修复注册后，后续需要将写好的替换后的函数与待热更新函数重新建立映射关系，即恢复注册。

为了以防万一替换时可能会出现的问题，所以所有的替换相关功能都是写在ILRuntime的热更新C#项目中的。主Unity工程只是调起了热更新函数。再通过该热更新函数作为入口进行替换处理。其中，替换的具体流程可以包括：

第一、首先通过反射获取待热更新函数所在的类，然后通过输入的配置表参数计算出相应的private静态变量对应的变量名(这个计算过程只在替换时做一次，且计算量不大，对性能的影响可以忽略不计)，最后就可以通过反射获取待热更新函数了；其中具体的计算方式可以为：固定前缀名+函数名+所有参数的字符串的MD5码，来得到相应的private静态变量对应的变量名。第二、通过反射以及上述获取的变量名，获取到private静态变量的引用；也就是说，可以通过C#函数提供的反射接口以及上述获取的变量名，获取到private静态变量的引用，以便能使用该静态变量来建立热更新函数和待热更新函数的对应关系。第三、通过反射以及输入的配置表参数，通过对静态变量的引用找到用于热更新函数的类及其中相应的函数；也就是说，可以通过C#函数提供的反射接口及输入的配置表参数，可获取到外部用于热更新的函数的引用，再通过上述获取到的private静态变量，来建立用于热更新函数和待热更新函数的对应关系。第四、目标文件中定义的一个ILBridge对象，为该ILBridge对象中的Func<object[],object>变量赋值，其值为一个Func<object[],object>，在该Func中通过反射执行第三的步骤中获取到的用于篡改或替换Hook的函数。这里使用反射方式执行的好处是，装箱和拆箱操作会在反射的过程中自动执行，而不需要手动的转换。

实施本申请实施例，首先获取热更新所需的目标文件，该目标文件与目标客户端使用相同的目标语言，然后根据所述目标文件初始化用于实现代码热更新的平台；所述平台包括基于所述目标语言开发的平台，通过初始化后的平台，将目标文件中的热更新函数替换目标客户端中对应的待热更新函数。在这个过程中，通过热更新函数对目标客户端中对应的待热更新函数替换实现了对目标客户端的热更新，通过使用统一目标语言提高了热更新效率。

如图6所示，其为本申请实施例提供的另一种热更新方法的流程示意图，方法应用于图3中的目标客户端对应的服务器，该方法可以基于图1所示的系统架构或者其他架构来实现，该方法可以包括但不限于以下步骤：

步骤S601：通过预设规则搜集第一场景的待热更新函数。

具体地，服务器通过预设规则搜集第一场景的待热更新函数，预设规则可以是自动过滤掉某些不适合被注入的函数。例如用于处理静态变量的.cctor函数等等。这些函数一般都是不适合被注入和替换的，为了避免一些不必要的问题，根据项目自身的情况，做了过滤处理；预设规则还可以是对不同函数进行权限设置，没有权限的函数不能被搜集。

在每个待热更新的函数所对应的类中插入一个静态变量ilbridge，需要对这个函数篡改或替换Hook时，直接用反射给这个值赋值即可。同时每个要注入的函数中，注入if语句判断ilbridge是否为空，不为空时执行Hook。

当只有为数不多的几个Fix函数带来的暂时性的性能损耗(主要是传入参数的装箱拆箱操作)，直接使用一个Func<object[],object>委托来执行被Hook的函数。

步骤S602：通过输入的热更新函数，建立热更新函数与第一场景的待热更新函数的对应关系。

具体地，服务器搜集到待热更新函数后，通过输入的热更新函数，建立热更新函数与第一场景的待热更新函数的对应关系，建立过程可以理解为注入过程，即将热更新函数注入到待热更新函数中，在外部的C#工程中引入Mono.Cecil.dll编写相应的注入热更新函数，最后生成一个DLL再放到Unity工程中，然后用Unity中的C#脚本调用这个生成的DLL中的注入热更新函数。这样做可以避免Mono.Cecil.dll与ILRuntime自带的Mono.Cecil命令空间的冲突。

注入热更新函数所需要处理的问题主要有如下几点：第一、对当前DLL是否已经注入过的判断。这里直接在每次成功注入热更新函数时在DLL中多加一个特定命名空间的类。那么每次进行注入时，如果检测到该DLL中存在该特定命名空间的类，则可以认为该DLL已被注入过，所以不要故意去创建这个命名空间；第二、Hofix标签的处理。本申请实施例定义了两个Attribute标签：HotfixAttribute(用于标识该类或函数会被热更新)和IgnoreHotfixAttribute(用于标识该类或函数不会被热更新，就算他所属的类加了HotfixAttribute标签)；第三、注入热更新函数的具体过程。这里使用的插入函数是InsertBefore，也就是选择一个插入点之后，持续在这个插入点的前面插入代码，这样就模拟了从前往后书写代码的过程。具体插入的语句，可以预先在C#中写好相应想要的代码之后，通过反编译工具(例如.NET Reflector 9.0等)获取其IL指令，再做相应的插入操作即可。以其中一个插入代码的示例如下：

L_000d:brfalse L_0032

L_0012:ldloc bridge

其中，brfalse是IL中的判断if false的指令，L_0032是插入点地址；ldloc是IL中将指定索引处的局部变量加载到计算堆栈上。所以注入热更新函数操作的代码如下：

processor.InsertBefore(insertPoint,processor.Create(OpCodes.Brfalse,insertPoint))；

processor.InsertBefore(insertPoint,processor.Create(OpCodes.Ldloc,ilInjection))。

在其中一个实施方式中，该目标客户端可以存在多个场景，在热更新函数和对应关系生成所述目标文件之前，判断第一场景的待热更新函数是否全部建立与热更新函数的对应关系；若全部建立完成，且存在第二场景，服务器通过预设规则搜集第二场景的待热更新函数，其中，第二场景与第一场景不同，预设规则可以是自动过滤掉某些不适合被注入的函数。例如用于处理静态变量的.cctor函数等等。这些函数一般都是不适合被注入和替换的，为了避免一些不必要的问题，根据项目自身的情况，做了过滤处理；预设规则还可以是对不同函数进行权限设置，没有权限的函数不能被搜集；服务器通过输入的热更新函数，建立热更新函数与第二场景的待热更新函数的对应关系。也即是说，如果目标客户端中包含了多个场景，将会多次进入注入的流程，通过对所有场景的遍历，一次性完成对所有带热更新函数的搜集。这种实现方式通过对目标客户端多个场景中的待热更新函数的搜集，对所有场景下的待热更新函数进行注入，提高了热更新的效率。

步骤S603：根据热更新函数和对应关系生成目标文件。

具体地，服务器建立热更新函数与第一场景的待热更新函数的对应关系之后，根据该热更新函数和该对应关系生成目标文件，目标文件中包括热更新函数和目标客户端中的函数的对应关系，该目标文件用于热更新该目标客户端。

在其中一个实施方式中，目标文件还包括用于注入热更新函数的中间键类，该中间键类包括一个对象变量和一个静态变量，该对象变量用于，存储在目标文件中的目标函数替换目标客户端中对应的函数之后执行的函数；所述静态变量插入在所述待热更新函数中，用于指示所述待热更新函数是否需要进行替换。举例来说，本申请实施例使用一个类作为中间键，该类的大致代码如下：

Public class ILBridge

{Func<object[],object>DoHookFunc；

Public object DoHook(params object[]args)

{if(DoHookFunc！＝null)

Return DoHookFunc(args)；

else return null；}}

其中，该类里面定义了一个Func<object[],object>变量用来存储被Hook后执行的函数，外加一个DoHook函数来供DLL注入之后的函数在被Hook后调用执行。同时需要注入的内容还有两个部分：第一、每个要注入热更新函数的待热更新函数所对应的类中插入一个静态变量ilbridge，需要对这个函数Hook(篡改、替换)时，直接用反射给这个静态变量ilbridge赋值即可。第二、每个要注入热更新函数的待热更新函数中，注入if判断ilbridge是否为空，不为空时执行DoHook，即用于检测是否被替换。

可以理解的，在本申请实施例中，鉴于只有为数不多的几个Fix函数带来的暂时性的性能损耗(主要是传入参数的装箱拆箱操作)，可以直接使用一个Func<object[],object>委托来执行被Hook的函数。

实施本申请实施例，首先通过预设规则搜集第一场景的待热更新函数，然后通过输入的热更新函数，建立热更新函数与待热更新函数的对应关系，根据所述热更新函数和所述对应关系生成目标文件，该目标文件用于热更新目标客户端。通过建立热更新函数与待热更新函数的对应关系，提供了目标文件，为实现热更新做好了预处理。

为了便于更好地实施本申请实施例的上述方案，本申请还对应提供了一种热更新装置，下面结合附图来进行详细说明：

如图7所示，本申请实施例提供一种热更新装置70的结构示意图，热更新装置70可以包括：获取单元701、初始化单元702和替换单元703，其中，

获取单元701，用于获取热更新所需的目标文件，所述目标文件使用的开发语言与目标客户端使用的开发语言为相同的目标语言；

初始化单元702，用于根据所述目标文件初始化用于实现代码热更新的平台；所述平台包括基于所述目标语言开发的平台；

替换单元703，用于通过所述初始化后的所述平台，将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数，所述目标文件中包括所述热更新函数和所述目标客户端中的待热更新函数的对应关系。

在本申请实施例中，所述替换单元703具体包括：

第一获取子单元，用于根据所述目标文件获取所述目标客户端中对应的待热更新函数的类；

计算子单元，根据输入的配置表参数，计算出与所述待热更新函数的类相对应的静态变量对应的变量名，并获取所述静态变量的引用，所述配置表参数包括所述待热更新函数的类和所述静态变量对应的变量名之间的对应关系；

第二获取子单元，根据所述静态变量以及所述配置表参数，通过反射获取所述热更新函数的类及其中相应的所述热更新函数；

替换子单元，将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数。

在本申请实施例中，所述目标文件还包括第一组件，所述第一组件用于通过所述目标客户端中的类调用Monobehavior的功能，所述目标客户端中的类继承了Monobehavior的类。

在本申请实施例中，所述目标文件还包括第二组件，所述第二组件用于使用所述目标客户端中的类中除了所述Monobehavior以外的功能。

需要说明的是，本申请实施例中图7所描述的装置中各功能单元的功能可参见上述图3中所述的方法实施例中步骤S301-步骤S303的相关描述，此处不再赘述。热更新装置70可以包括但不限于任何一种基于智能操作系统的电子产品，其可与用户通过键盘、虚拟键盘、触摸板、触摸屏以及声控设备等输入设备来进行人机交互，诸如智能手机、平板电脑、个人电脑等。

如图8所示，本申请实施例提供一种热更新装置80的结构示意图，热更新装置80可以包括：搜集单元801、建立单元802和生成单元803，其中，

搜集单元801，用于通过预设规则搜集第一场景的待热更新函数；

建立单元802，用于通过输入的热更新函数，建立所述热更新函数与所述第一场景的待热更新函数的对应关系；

生成单元803，用于根据所述热更新函数和所述对应关系生成所述目标文件，所述目标文件用于热更新目标客户端。

在本申请实施例中，所述目标文件还包括中间键类，所述中间键类包括对象变量和静态变量，所述对象变量用于存储函数，所述函数用于执行在所述目标文件中的目标函数替换所述目标客户端中对应的函数之后；所述静态变量插入在所述待热更新函数中，用于指示所述待热更新函数是否需要进行替换。

在本申请实施例中，所述装置还包括：

判断单元，根据在所述热更新函数和所述对应关系生成所述目标文件之前，判断所述第一场景的待热更新函数是否全部建立与所述热更新函数的对应关系；

所述搜集单元803还用于若全部建立完成，且存在第二场景，通过预设规则搜集所述第二场景的待热更新函数，所述第二场景与所述第一场景不同；

所述建立单元802还用于通过输入的热更新函数，建立所述热更新函数与所述第二场景的待热更新函数的对应关系。

需要说明的是，本申请实施例中图8所描述的装置中各功能单元的功能可参见上述图6中所述的方法实施例中步骤S601-步骤S603的相关描述，此处不再赘述。热更新装置80可以包括但不限于后台服务器、组件服务器、数据处理服务器等，服务器可以通过互联网与多个终端进行通信。服务器为终端提供热更新服务。

根据以上热更新装置图，请参考图9，图9是本申请实施例提供的一种热更新设备结构示意图。便于理解和图示方便，图9的热更新设备90中，可以包括以下一个或多个组件：存储器901、处理器902和通信设备903。

存储器901可以包括一个或多个存储单元，每个单元可以包括一个或多个存储器，存储器可用于存储程序和各种数据，并能在热更新设备90运行过程中高速、自动地完成程序或数据的存取。当图9所示的热更新设备90，执行图2所述方法时，存储器可以用来存储热更新代码、热更新缓存数据以及其他相关数据等。

通信设备903，也可以称为收发机，或收发器等，其中可以包括用来进行无线、有线或其他通信方式的单元。可选的，可以将903部分中用于实现接收功能的器件视为接收单元，将用于实现发送功能的器件视为发送单元，即903部分包括接收单元和发送单元。

处理器902，处理器也可以称为处理单元，处理单板，处理模块，处理装置等。处理器可以是中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合。当图9所示的热更新设备90，执行图3所述方法时，所述处理器902调用所述存储器901的热更新程序，执行以下步骤：

通过所述通信设备903获取热更新所需的目标文件，所述目标文件使用的开发语言与目标客户端使用的开发语言为相同的目标语言；

通过所述初始化后的所述平台，将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数，所述目标文件中包括所述热更新函数和所述目标客户端中的待热更新函数的对应关系。

在其中一个实施方式中，处理器902将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数，具体包括：

在其中一个实施方式中，所述目标文件还包括第一组件，所述第一组件用于通过所述目标客户端中的类调用Monobehavior的功能，所述目标客户端中的类继承了Monobehavior的类。

在其中一个实施方式中，所述目标文件还包括第二组件，所述第二组件用于使用所述目标客户端中的类中除了所述Monobehavior以外的功能。

需要说明的是，本申请实施例中的热更新设备90中处理器902的执行步骤可参考上述各方法实施例中图3实施例中的具体实现方式，这里不再赘述。

根据以上热更新装置图，请参考图10，图10是本申请实施例提供的一种热更新设备结构示意图。便于理解和图示方便，图10的热更新设备100中，可以包括以下一个或多个组件：存储器1001、处理器1002和通信设备1003。

存储器1001可以包括一个或多个存储单元，每个单元可以包括一个或多个存储器，存储器可用于存储程序和各种数据，并能在热更新设备100运行过程中高速、自动地完成程序或数据的存取。当图10所示的热更新设备100，执行图2所述方法时，存储器可以用来存储热更新代码、热更新缓存数据以及其他相关数据等。

通信设备1003，也可以称为收发机，或收发器等，其中可以包括用来进行无线、有线或其他通信方式的单元。可选的，可以将1003部分中用于实现接收功能的器件视为接收单元，将用于实现发送功能的器件视为发送单元，即1003部分包括接收单元和发送单元。

处理器1002，处理器也可以称为处理单元，处理单板，处理模块，处理装置等。处理器可以是中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合。当图10所示的热更新设备100，执行图2所述方法时，所述处理器1002调用所述存储器1001的热更新程序，执行以下步骤：

通过预设规则搜集第一场景的待热更新函数；

在其中一个实施方式中，所述目标文件还包括中间键类，所述中间键类包括对象变量和静态变量，所述对象变量用于存储函数，所述函数用于执行在所述目标文件中的目标函数替换所述目标客户端中对应的函数之后；所述静态变量插入在所述待热更新函数中，用于指示所述待热更新函数是否需要进行替换。

在其中一个实施方式中，在所述处理器1002根据所述热更新函数和所述对应关系生成所述目标文件之前，包括：

需要说明的是，本申请实施例中的热更新设备100中处理器1002的执行步骤可参考上述各方法实施例中图6实施例中的具体实现方式，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。而前述的存储介质包括：磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

在本申请中，所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。尽管在此结合各实施例对本申请进行了描述，然而，在实施例所要求保护的本申请过程中，本领域技术人员可理解并实现公开实施例的其他变化。

Claims

1.一种热更新方法，其特征在于，包括：

根据所述目标文件初始化用于实现代码热更新的平台，所述平台包括基于所述目标语言开发的平台；

通过初始化后的所述平台，根据所述目标文件获取所述目标客户端中对应的待热更新函数的类；

根据所述静态变量以及所述配置表参数，通过反射获取热更新函数的类及其中相应的所述热更新函数；

将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数，所述目标文件中包括所述热更新函数和所述目标客户端中的待热更新函数的对应关系；所述目标文件还包括中间键类，所述中间键用于连通所述目标文件中的热更新代码和目标客户端中的原工程代码，所述中间键类包括对象变量和静态变量，所述对象变量用于存储函数，所述函数用于在所述目标文件中的目标函数替换所述目标客户端中对应的函数之后执行；所述中间键类中的静态变量插入在所述待热更新函数中，用于指示所述待热更新函数是否需要进行替换。

2.根据权利要求1所述的方法，其特征在于，所述目标文件还包括第一组件，所述第一组件用于通过所述目标客户端中的类调用Monobehavior的功能，所述目标客户端中的类继承了Monobehavior的类。

3.根据权利要求2所述的方法，其特征在于，所述目标文件还包括第二组件，所述第二组件用于使用所述目标客户端中的类中除了所述Monobehavior以外的功能。

4.一种热更新方法，其特征在于，包括：

通过预设规则搜集第一场景的待热更新函数；

根据所述热更新函数和所述对应关系生成目标文件，所述目标文件用于热更新目标客户端；所述目标文件使用的开发语言与目标客户端使用的开发语言为相同的目标语言；

其中，所述热更新目标客户端为：所述目标客户端通过初始化后的用于实现代码热更新的平台，根据所述目标文件获取所述目标客户端中对应的待热更新函数的类，所述平台包括基于所述目标语言开发的平台；根据输入的配置表参数，计算出与所述待热更新函数的类相对应的静态变量对应的变量名，并获取所述静态变量的引用，所述配置表参数包括所述待热更新函数的类和所述静态变量对应的变量名之间的对应关系；根据所述静态变量以及所述配置表参数，通过反射获取所述热更新函数的类及其中相应的所述热更新函数；将所述目标文件中的热更新函数替换所述目标客户端中对应的待热更新函数；所述目标文件还包括中间键类，所述中间键用于连通所述目标文件中的热更新代码和目标客户端中的原工程代码，所述中间键类包括对象变量和静态变量，所述对象变量用于存储函数，所述函数用于在所述目标文件中的目标函数替换所述目标客户端中对应的函数之后执行；所述中间键类中的静态变量插入在所述待热更新函数中，用于指示所述待热更新函数是否需要进行替换。

5.一种热更新装置，其特征在于，包括用于执行如权利要求1-4任一项所述的方法的单元。

6.一种热更新设备，其特征在于，所述热更新设备包括处理器、存储器和通信设备，所述处理器、存储器和通信设备相互连接，其中，所述通信设备用于与外部设备进行信息交互；所述存储器存储可执行程序代码；所述处理器被配置用于调用存储的程序代码，执行包括：

7.一种热更新设备，其特征在于，所述热更新设备包括处理器、存储器和通信设备，所述处理器、存储器和通信设备相互连接，其中，所述通信设备用于与外部设备进行信息交互；所述存储器存储可执行程序代码；所述处理器被配置用于调用存储的程序代码，执行包括：

通过预设规则搜集第一场景的待热更新函数；

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1-4任一项所述的方法。