CN116173511A - 一种游戏热更新方法、装置、计算机设备和存储介质 - Google Patents

一种游戏热更新方法、装置、计算机设备和存储介质 Download PDF

Info

Publication number
CN116173511A
CN116173511A CN202310217391.1A CN202310217391A CN116173511A CN 116173511 A CN116173511 A CN 116173511A CN 202310217391 A CN202310217391 A CN 202310217391A CN 116173511 A CN116173511 A CN 116173511A
Authority
CN
China
Prior art keywords
updated
loading
file
link library
dynamic link
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310217391.1A
Other languages
English (en)
Inventor
魏振果
魏君成
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Zitiao Network Technology Co Ltd
Original Assignee
Beijing Zitiao Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Zitiao Network Technology Co Ltd filed Critical Beijing Zitiao Network Technology Co Ltd
Priority to CN202310217391.1A priority Critical patent/CN116173511A/zh
Publication of CN116173511A publication Critical patent/CN116173511A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/77—Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/552—Details of game data or player data management for downloading to client devices, e.g. using OS version, hardware or software profile of the client device
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供了一种游戏热更新方法、装置、计算机设备和存储介质，其中，该方法包括：获取目标游戏对应的待更新文件和待更新动态链接库；所述待更新文件用于在游戏引擎运行所述待更新动态链接库时提供运行依赖信息；响应于所述目标游戏的启动，将所述游戏引擎对应的链接库加载路径，更新为所述待更新动态链接库的目标加载路径，并利用所述待更新文件替换所述目标游戏对应的原始文件；响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数；通过更新后的所述加载参数，加载所述待更新动态链接库，并利用所述待更新文件运行所述待更新动态链接库，以替换所述目标游戏的原始动态链接库。

Description

一种游戏热更新方法、装置、计算机设备和存储介质
技术领域
本公开涉及计算机技术领域，具体而言，涉及一种游戏热更新方法、装置、计算机设备和存储介质。
背景技术
在游戏开发领域中，通常需要对开发好的游戏进行迭代更新，而由于游戏的代码包一般体积较大，整包更新的方式具有较高的迭代成本，所以热更新方式在游戏开发领域更能得到游戏开发人员的青睐，具有较强的实用价值。
但是，当前主流的一些游戏热更新方案，通常存在更新能力有限、更新性能差的问题，弊端较大。
发明内容
本公开实施例至少提供一种游戏热更新方法、装置、计算机设备和存储介质。
第一方面，本公开实施例提供了一种游戏热更新方法，包括：
获取目标游戏对应的待更新文件和待更新动态链接库；所述待更新文件用于在游戏引擎运行所述待更新动态链接库时提供运行依赖信息；
响应于所述目标游戏的启动，将所述游戏引擎对应的链接库加载路径，更新为所述待更新动态链接库的目标加载路径，并利用所述待更新文件替换所述目标游戏对应的原始文件；所述原始文件用于在所述游戏引擎运行原始动态链接库时提供运行依赖信息；
响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数；
通过更新后的所述加载参数，加载所述待更新动态链接库，并利用所述待更新文件运行所述待更新动态链接库，以替换所述目标游戏的原始动态链接库。
在一种可能的实施方式中，利用所述目标加载路径，更新加载参数中的路径位置参数，包括：
利用动态链接库的目标加载方法，获取加载参数，并在所述加载参数满足预设条件的情况下，利用所述目标加载路径更新加载参数中的路径位置参数。
在一种可能的实施方式中，根据以下步骤确定所述加载参数是否满足预设条件：
在所述加载参数中的路径长度参数等于预设长度、且所述加载参数中的路径格式参数等于预设格式参数的情况下，确定所述加载参数中的可变类型的路径位置参数是否为所述目标游戏对应的应用程序信息库目录；
若是，则在所述加载参数中的库名称与所述原始动态链接库的名称一致的情况下，判断所述目标加载路径下的所述待更新动态链接库是否能够访问；
若是，则确定所述加载参数满足预设条件。
在一种可能的实施方式中，所述方法还包括：
在所述加载参数不满足预设条件的情况下，利用所述目标加载方法中的目标调用函数调用替换函数，将所述加载参数中的路径位置参数和库名称组合为待加载路径；所述替换函数用于替换原始加载方法的原始函数，与所述原始函数具有相同功能，且支持调用列表类型的参数；
加载所述待加载路径处的所述原始动态链接库，并利用所述原始文件运行所述原始动态链接库。
在一种可能的实施方式中，在所述响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数之前，还包括：
利用所述目标游戏对应的系统库加载方法，将所述目标加载路径处的所述待更新动态链接库，加载至目标存储介质中；
在所述通过更新后的所述加载参数，加载所述待更新动态链接库之前，还包括：
判断所述目标存储介质中是否存储有所述待更新动态链接库；
若是，则将所述目标存储介质中存储的所述待更新动态链接库，作为加载完成的待更新动态链接库。
在一种可能的实施方式中，所述获取目标游戏对应的待更新文件和待更新动态链接库，包括：
获取目标游戏的热更新文件对应的压缩文件，所述压缩文件包括压缩后的待更新文件和压缩后的待更新动态链接库；
从所述压缩后的待更新文件中，提取与所述原始文件的区别文件内容，以及从所述压缩后的待更新动态链接库中，提取与原始动态链接库的区别链接库内容；
在所述压缩后的待更新文件对应的文件校验值，指示所述压缩后的待更新文件与沙盒环境中的所述原始文件相匹配的情况下，将所述原始文件和所述区别文件内容，合并为待更新文件，以及将所述原始动态链接库和所述区别链接库内容，合并为待更新动态链接库。
在一种可能的实施方式中，在所述利用所述待更新文件替换所述目标游戏对应的原始文件之前，还包括：
将所述待更新文件设置为暂存状态；
所述利用所述待更新文件替换所述目标游戏对应的原始文件，包括：
响应于检测到存在处于所述暂存状态的所述待更新文件，利用处于所述暂存状态的所述待更新文件，替换沙盒环境中的所述原始文件，并取消所述待更新文件的暂存状态。
在一种可能的实施方式中，在所述利用处于所述暂存状态的所述待更新文件，替换沙盒环境中的所述原始文件之前，还包括：
备份所述原始文件；
在备份所述原始文件之后，还包括：
响应于所述待更新动态链接库对应的更新后功能下线，删除本地存储的热更新信息；所述热更新信息包括在运行所述待更新动态链接库的过程中产生的运行信息；
响应于目标游戏的启动，利用备份的所述原始文件，替换沙盒环境中的所述待更新文件。
在一种可能的实施方式中，在利用动态链接库的目标加载方法，获取加载参数之前，还包括：
利用程序链接表钩子技术，为所述游戏引擎对应的原始加载方法建立目标钩子；
为所述目标钩子挂载所述目标加载方法；所述目标加载方法用于获取并更新所述加载参数中的路径位置参数；
所述利用动态链接库的目标加载方法，获取加载参数，包括：
响应于调用所述动态链接库的所述原始加载方法，触发所述目标钩子挂载的所述目标加载方法；
利用所述目标加载方法，获取所述加载参数。
第二方面，本公开实施例还提供一种游戏热更新装置，包括：
获取模块，用于获取目标游戏对应的待更新文件和待更新动态链接库；所述待更新文件用于在游戏引擎运行所述待更新动态链接库时提供运行依赖信息；；
替换模块，用于响应于所述目标游戏的启动，将所述游戏引擎对应的链接库加载路径，更新为所述待更新动态链接库的目标加载路径，并利用所述待更新文件替换所述目标游戏对应的原始文件；所述原始文件用于在所述游戏引擎运行原始动态链接库时提供运行依赖信息；
更新模块，用于响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数；
第一加载模块，用于通过更新后的所述加载参数，加载所述待更新动态链接库，并利用所述待更新文件运行所述待更新动态链接库，以替换所述目标游戏的原始动态链接库。
第三方面，本公开可选实现方式还提供一种计算机设备，处理器、存储器，所述存储器存储有所述处理器可执行的机器可读指令，所述处理器用于执行所述存储器中存储的机器可读指令，所述机器可读指令被所述处理器执行时，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。
第四方面，本公开可选实现方式还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被运行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。
关于上述游戏热更新装置、计算机设备、及计算机可读存储介质的效果描述参见上述游戏热更新方法的说明，这里不再赘述。
本公开实施例提供的游戏热更新方法、装置、计算机设备和存储介质，通过对加载参数中的路径位置参数的更新，可以实现将路径位置参数指示的路径，从原始动态链接库的加载路径更新为热更新后的待更新动态链接库的加载路径，进而实现对新的待更新动态链接库的加载。由于包含常量的信息的文件用于保证动态链接库的正常运行，所以通过将目标游戏对应的原始文件替换为待更新文件，可以利用待更新文件保障待更新动态链接库的正常运行，实现对目标游戏的热更新。整个方案通过对原始动态链接库和原始文件进行整体替换的方式，实现了对目标游戏的热更新。由于待更新动态链接库的格式与原始动态链接库的格式一致，所以在运行更新后功能对应的待更新动态链接库时，可以保证不影响运行性能，相比现有技术中的游戏热更新方案，存在更新性能差的问题而言，本公开实施例提供的游戏热更新方法的性能更优，且由于是对原始动态链接库的直接替换，可以使得该游戏热更新方法适用于各种更新场景，实现了游戏热更新性能的提高。
为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本公开实施例所提供的一种游戏热更新方法的流程图；
图2示出了本公开实施例所提供的一种本地库目录数组在热更新前后的示意图；
图3示出了本公开实施例所提供的一种目标加载方法的内部处理流程图；
图4示出了本公开实施例所提供的一种对libmain.so进行hook前后，加载动态链接库的对比示意图；
图5示出了本公开实施例所提供的一种暂存待更新文件的示意图；
图6示出了本公开实施例所提供的一种替换原始文件的示意图；
图7示出了本公开实施例所提供的一种还原原始文件的示意图；
图8示出了本公开实施例所提供的一种游戏热更新方法的具体实施流程图；
图9示出了本公开实施例所提供的一种游戏热更新装置的示意图；
图10示出了本公开实施例所提供的一种计算机设备的结构示意图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。
另外，本公开实施例中的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。
在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
经研究发现，在游戏开发领域，联合(unity)引擎是被广泛使用的游戏引擎，unity游戏开发主要使用C#语言编写代码，在对编写好的代码进行打包时，通常会先将C#代码编译成中间语言(Intermediate Language，简称IL)代码，再利用IL2CPP工具将IL代码转换为libil2cpp.so。最后可以通常运行libil2cpp.so的方式，实现对开发好的游戏的运行。然后，传统的游戏热更新方案可以包括以下几种：
1、注入修改(InjectFix)方法，核心在于编译期先对IL进行插桩，运行时使用自建的IL虚拟机动态加载IL替换原有的逻辑。但是，该方法不仅在性能上较差，低于直接运行libil2cpp.so，而且更新能力有限，仅限于方法替换，一般仅能用于漏洞修复(bugfix)。
2、IL运行时(ILRuntime)方法，核心在于将游戏工程拆分为主工程和热更工程，运行时使用自建的IL虚拟机动态加载热更工程中的IL，从而实现对原有逻辑的替换。但是，该方法不仅在性能上较差，低于直接运行libil2cpp.so，而且需要对开发流程进行拆分，存在开发流程侵入度高的问题，此外，该方法的使用限制、兼容性以及更新能力均较差。
3、混合CLR(HybridCLR)方法，核心在于修改libil2cpp的源码，开启运行前编译(Ahead Of Time，AOT)+翻译(Interpreter)的混合Runtime，运行时使用Interpreter模式动态加载热更的IL。但是，该方法在性能上低于直接运行libil2cpp.so。
综上可知，传统的游戏热更新方案普遍存在更新能力有限、更新性能差的问题。
基于上述研究，本公开提供了一种游戏热更新方法、装置、计算机设备和存储介质，通过对加载参数中的路径位置参数的更新，可以实现将路径位置参数指示的路径，从原始动态链接库的加载路径更新为热更新后的待更新动态链接库的加载路径，进而实现对新的待更新动态链接库的加载。由于包含常量的信息的文件用于保证动态链接库的正常运行，所以通过将目标游戏对应的原始文件替换为待更新文件，可以利用待更新文件保障待更新动态链接库的正常运行，实现对目标游戏的热更新。整个方案通过对原始动态链接库和原始文件进行整体替换的方式，实现了对目标游戏的热更新。由于待更新动态链接库的格式与原始动态链接库的格式一致，所以在运行更新后功能对应的待更新动态链接库时，可以保证不影响运行性能，相比现有技术中的游戏热更新方案，存在更新性能差的问题而言，本公开实施例提供的游戏热更新方法的性能更优，且由于是对原始动态链接库的直接替换，可以使得该游戏热更新方法适用于各种更新场景，实现了游戏热更新性能的提高。
针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
可以理解的是，在使用本公开各实施例公开的技术方案之前，均应当依据相关法律法规通过恰当的方式对本公开所涉及个人信息的类型、使用范围、使用场景等告知用户并获得用户的授权。
需要说明的是，本公开实施例中所提到的特定名词包括：
Unity：是一种应用十分广泛的游戏引擎，使用Unity开发游戏一般使用C#代码语言进行编程；
IL：Intermediate Language，中间语言，C#代码的编译产生，可以被IL虚拟机运行；
libil2cpp.so：动态链接库，利用IL2CPP工具对IL代码进行转换为后得到，目标游戏对应的应用程序启动后，可以直接加载运行libil2cpp.so，从而实现对目标游戏的流畅运行；
global-metadata.dat：全局元数据文件，用于存在C#的常量，libil2cpp.so在运行时需要加载global-metadata.dat文件，以从中获取需要的常量信息；
libmain.so：Unity引擎初始化后时最先加载的一种动态库，包括多种调用方法，可以通过调用dlload方式，加载libil2cpp.so；
PTL Hook技术：Procedure Linkage Table Hook，程序链接表钩子，一种可以将libmain.so中的方法替换为自己实现的方法，从而实现对so中某些逻辑的修改的技术；
MD5：MD5 Message-Digest Algorithm，信息摘要算法，一种被广泛使用的密码散列函数，可以产生出一个128位(16字节)的散列值(hash value)，用于确保信息传输完整一致；
va_list类型，定义类型变量来指向可变参数的地址。
为便于对本实施例进行理解，首先对本公开实施例所公开的一种游戏热更新方法进行详细介绍，本公开实施例所提供的游戏热更新方法的执行主体一般为具有一定计算能力的终端设备或其他处理设备，其中终端设备可以为用户设备(User Equipment，UE)、移动设备、用户终端、终端、个人数字助理设备(Personal Digital Assistant，PDA)、手持设备、计算机设备等；在一些可能的实现方式中，该游戏热更新方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。
下面以执行主体为终端设备为例对本公开实施例提供的游戏热更新方法加以说明。
如图1所示，为本公开实施例提供的一种游戏热更新方法的流程图，可以包括以下步骤：
S101：获取目标游戏对应的待更新文件和待更新动态链接库；待更新文件用于在游戏引擎运行待更新动态链接库时提供运行依赖信息。
这里，目标游戏可以为任一利用Unity引擎开发的游戏，待更新动态链接库即为新的libil2cpp.so，是对目标游戏进行热更新后得到的动态链接库，新的libil2cpp.so对应于更新后功能，一个游戏可以存在一个动态链接库，通过运行动态链接库，可以实现对游戏的运行。在对目标游戏进行热更新前，目标游戏对应的动态链接库为原始动态链接库(也即原始的libil2cpp.so)，原始动态链接库对应的功能与更新后功能不同。
待更新文件即为新的global-metadata.dat文件，是对目标游戏的原始文件进行更新后得到的文件，待更新文件与待更新动态链接库相匹配，其中存储有待更新动态链接库运行所需的常量信息。待更新文件可以用于在游戏引擎运行待更新动态链接库时提供运行依赖信息，其中，运行依赖信息即为运行动态链接库时所需的信息，具体的，待更新文件提供的运行依赖信息即为待更新文件存储的常量信息。在对目标游戏进行热更新前，目标游戏所需使用的常量信息由原始文件(也即原始global-metadata.dat)提供，原始文件与原始动态链接库相匹配，用于存储原始动态链接库运行所需的常量信息，原始文件可以用于在游戏引擎运行原始动态链接库时提供运行依赖信息。待更新文件与原始文件中存储的常量信息不同。
目标游戏可以以游戏应用程序(Application，简称APP)为载体部署在终端设备中，游戏APP运行也即目标游戏运行。
具体实施时，若需要对目标游戏进行热更新，可以在打开游戏App的时候，获取目标游戏对应的新的libil2cpp.so和新的global-metadata.dat。
在一种实施例中，针对上述S101，还可以按照以下步骤实施：
S101-1：获取目标游戏的热更新文件对应的压缩文件，压缩文件包括压缩后的待更新文件和压缩后的待更新动态链接库。
这里，在需要对目标游戏进行热更新的情况下，通常可以以补丁patch的方式，对热更新文件进行下发。其中，热更新文件为用于对目标游戏的游戏代码进行更新的文件，其中可以包括待更新文件和待更新动态链接库。热更新文件可以部署在目标游戏对应的服务端。
压缩文件即为对热更新文件进行打包压缩后得到的文件。例如，可以用patch.jar表示。由于热更新文件中包括待更新文件和待更新动态链接库，所以压缩文件中可以包括压缩后的待更新文件和压缩后的待更新动态链接库。
之所以需要获取压缩文件，是由于目标游戏的代码包的体积通常很大，所以若直接从服务端下载热更新文件，可以需要花费一定的下载时间以及消费一定的下载资源，所以为了提高热更新的速度，采用了从服务端下载目标游戏的热更新文件对应的压缩文件的方式。
示例性的，终端设备可以通过与服务端的通讯，从服务端获取patch文件对应的patch.jar文件。
S101-2：从压缩后的待更新文件中，提取与原始文件的区别文件内容，以及从压缩后的待更新动态链接库中，提取与原始动态链接库的区别链接库内容。
这里，区别文件内容即为待更新文件中与原始文件不同的文件内容，为与更新后功能相关的文件内容，可以用常量diff表示。区别链接库内容即为待更新动态链接库中与原始动态链接库不同的链接库内容，区别链接库内容为与更新后功能相关的链接库内容，可以用链接库diff表示。
在启动目标游戏(以重启目标游戏为例)之前，unity引擎当前加载的动态链接库为原始动态链接库，当前使用的提供常量信息的文件为原始文件。所以在得到压缩后的待更新文件和压缩后的待更新动态链接库之后，可以将当前使用的原始文件和压缩后的待更新文件进行对比，确定两个文件对应的区别文件内容；同时，可以将当前加载的原始动态链接库和压缩后的待更新动态链接库进行对比，确定两个动态链接库对应的区别链接库内容。
S101-3：在压缩后的待更新文件对应的文件校验值，指示压缩后的待更新文件与沙盒环境中的原始文件相匹配的情况下，将原始文件和区别文件内容，合并为待更新文件，以及将原始动态链接库和区别链接库内容，合并为待更新动态链接库。
这里，文件校验值用于校验压缩后的待更新文件与原始文件是否匹配，具体的，在两个用于提供常量信息的文件对应的文件校验值一致的情况下，可以说明两个文件对应于相同的游戏，且两个文件分别为迭代前后的文件。示例性的，文件校验值可以为待更新文件对应的MD5值。
具体实施时，在得到压缩后的待更新文件之后，可以计算出压缩后的待更新文件对应的文件校验值，同时，可以确定出当前使用的原始文件的文件校验值，在两个文件校验值一致的情况下，可以说明压缩后的待更新文件与沙盒环境中的原始文件相匹配。然后，可以对原始文件和区别文件内容进行合并，得到待更新文件，以及，可以对原始动态链接库和区别链接库内容进行合并，得到待更新动态链接库。
反之，若压缩后的待更新文件对应的文件校验值，与当前使用的原始文件的文件校验值不一致，则可以说明当前获取的压缩后的待更新文件存在异常，拒绝文件内容的合并，并生成异常提示信息进行反馈。
可选的，在对原始动态链接库和区别链接库内容进行合并之前，也可以确定压缩后的待更新动态链接库对应的链接库校验值，以及确定当前加载的原始动态链接库对应的链接库校验值。在两个链接库校验值一致的情况下，说明压缩后的待更新动态链接库与当前加载的原始动态链接库相匹配，为迭代前后的两个动态链接库，然后可以对原始动态链接库和区别链接库内容进行合并，从而得到待更新动态链接库。
反之，若压缩后的待更新动态链接库的链接库校验值，与当前加载的原始动态链接库的链接库校验值不一致，则拒绝文件内容的合并，并生成异常提示信息进行反馈。
这样，通过使用压缩后的待更新文件和压缩后的待更新动态链接库，可以提高获取待更新文件和待更新动态链接库的速度，进而提高游戏热更新的速度。
可选的，终端设备也可以直接从服务端下载热更新文件，然后可以从下载完成的热更新文件中，提取出待更新文件和待更新动态链接库。
S102：响应于目标游戏的启动，将游戏引擎对应的链接库加载路径，更新为待更新动态链接库的目标加载路径，并利用待更新文件替换目标游戏对应的原始文件；原始文件用于在游戏引擎运行原始动态链接库时提供运行依赖信息。
这里，之所以在启动目标游戏之后才进行待更新文件的替换，是因为在获取待更新文件和待更新动态链接库时，已经在线启动了目标游戏以及游戏引擎，此时游戏引擎已经加载完成了原始libil2cpp.so和原始global-metadata.dat，若此时直接对提供常量信息的文件进行替换，则会导致出现已经加载完成的原始libil2cpp.so，无法在待更新文件中获取需要的常量信息，进而造成目标游戏运行异常的问题。为了避免热更新过程中出现目标游戏运行异常的问题，则在获取新的libil2cpp.so和新的global-metadata.dat之后，需要在再次重启目标游戏后对提供常量信息的文件进行替换，也即，在重启目标游戏后对提供常量信息的文件进行替换。
目标加载路径为用于加载待更新动态链接库的路径，游戏引擎对应的链接库加载路径，即为游戏引擎在加载动态链接库时获取动态链接库的路径。具体的，链接库加载路径可以为终端设备的本地库目录(nativeLibraryDirectories)的头部位置，nativeLibraryDirectories具体可以为一个数组，该数组用于存储各种文件的加载路径。
具体实施时，在游戏APP重启的情况下，可以确定目标游戏被重启。然后，为了实现对原始动态链接库的热更新，可以响应于目标游戏的重启，将新的libil2cpp.so的目标加载路径，插入到类加载器(Class Loader)的路径列表(Path List)中的nativeLibraryDirectories数组的头部位置。如图2所示，为本公开实施例提供的一种本地库目录数组在热更新前后的示意图，其中，在热更新前，nativeLibraryDirectories数组的头部位置为应用程序包(Android application package，Android，简称APK)1的安装路径，在APK1之后为AP2的安装路径，APK3的安装路径，……，依次类推。其中，每个APK的安装路径中可以存储有至少一个libil2cpp.so的加载路径(例如图2中的/lib/xxx和/base.apk/xxx)，在热更新前的各个APK中存在一个目标APK，该目标APK的安装路径中存储有原始动态链接库的加载路径，也即在热更新前，游戏引擎对应的链接库加载路径为原始动态链接库的加载路径。在热更新后，nativeLibraryDirectories数组的头部位置为新的libil2cpp.so的目标加载路径，如此，实现了将游戏引擎对应的链接库加载路径，更新为目标加载路径。而且，在图2中，在热更新后，在目标加载路径之后的是APK1的安装路径，AP2的安装路径，APK3的安装路径，……。
同时，在将目标加载路径插入到nativeLibraryDirectories数组的头部位置的情况下，还可以将沙盒环境中存储的目标游戏对应的原始文件，替换为待更新文件。其中，原始文件可以用于在游戏引擎运行原始动态链接库时提供运行依赖信息。
S103：响应于游戏引擎的初始化，利用目标加载路径，更新加载参数中的路径位置参数。
这里，游戏引擎具体可以为unity引擎。Unity引擎通常在目标游戏启动之后进行初始化，Unity引擎的初始化时间与目标游戏的启动时间之间，存在时间间隔。加载参数为unity引擎启动之后，加载目标游戏所需的各种参数，具体可以包括用于指示需要加载的libil2cpp.so的加载路径的路径位置参数(也即用于指示链接库加载路径的路径位置参数)、用于指示加载路径的路径长度的长度参数、用于指示加载路径的路径格式的路径格式参数、用于指示需要加载的动态链接库的库名称的库名称参数等。
在具体实施时，在目标游戏重启之后，可以响应于unity引擎的初始化，在确定nativeLibraryDirectories数组的头部位置处，存在新的libil2cpp.so的目标加载路径的情况下，可以从头部位置处获取目标加载路径，并将加载参数中的路径位置参数，更新为目标加载路径。
具体实施时，针对S103，可以按照以下步骤实施：
利用动态链接库的目标加载方法，获取加载参数，并在加载参数满足预设条件的情况下，利用目标加载路径更新加载参数中的路径位置参数。
这里，目标加载方法为用于加载动态链接库、并能够修改路径位置参数的方法。Unity引擎在初始化后最先加载的文件为libmain.so文件，libmain.so会通过调用dlload方法中的原始加载方法，加载动态链接库，其中，原始加载方法可以为snprintf方法，目标加载方法为对snprintf方法hook后的方法，用于更新snprintf方法的逻辑。目标加载方法可以为称为原始加载方法的代理方法，可以用snprintf_proxy表示。
之所以需要对snprintf方法进行hook，是因为libmain.so文件在通过调用dlload中的snprintf方法加载动态链接库时，取的是应用程序本地信息库目录(ApplicationInfo.nativeLibraryDir)，该目录对应的链接库加载路径为nativeLibraryDirectories数组中的APK包里面的路径，而该路径为原始libil2cpp.so的加载路径，非新的libil2cpp.so的加载路径。因此，若直接使用snprintf方法加载动态链接库，则会导致nativeLibraryDirectories数组的头部位置处目标加载路径无法被获取，从而导致新的libil2cpp.so无法被Unity引擎加载。因此，利用通过hook的方法，将原始加载方法改变为目标加载方法，并利用目标加载方法实现对新的libil2cpp.so的加载。
需要说明的是，在热更新前，原始加载方法加载原始libil2cpp.so的方法为，获取到ApplicationInfo.nativeLibraryDir之后，可以利用dlload中的dlopen方法，根据ApplicationInfo.nativeLibraryDir加载原始原始libil2cpp.so。其中，dlopen方法是libmain中根据加载路径加载libil2cpp.so的方法。
加载参数可以包括多个，一个加载参数可以对应于一个预设条件。需要说明的是，目标加载方法获取的加载参数，与原始加载方法获取的加载参数是相同的，如下示出了原始加载方法获取的加载参数：
Snprintf(path，sizeof(path–1)，"％s/％s"，libdir，libname)。
其中，path表示需要获取的加载路径，sizeof(path)–1、"％s/％s"、libdir和libname均为获取加载路径时所使用的参数，sizeof(path)–1表示路径长度参数对应的值，路径长度参数可以用_size表示；"％s/％s"表示路径格式参数对应的值，路径格式参数可以用_fmt表示，libdir表示可变类型的路径位置参数对应的值，libname表示需要加载的库的库名称对应的值。
具体实施时，在游戏引擎初始化之后，可以利用目标加载方法，先获取目标游戏对应的加载参数。其中，加载参数可以包括多个。然后，可以判断各个加载参数是否均满足对应的预设条件，若是，则可以将加载参数中的路径位置参数，更新为目标加载路径。
在一种实施例中，可以按照以下步骤确定加载参数是否满足预设条件：
首先，可以确定路径长度参数指示路径长度是否等于预设长度，预设长度可以为2047，也即判断_size是否等于2047。若是，则可以继续判断路径格式参数是否为预设格式参数，预设格式参数为“％s/％s”，也即判断_fmt是否为“％s/％s”。在加载参数中的路径长度参数等于预设长度、且加载参数中的路径格式参数等于预设格式参数的情况下，可以确定加载参数中的可变类型的路径位置参数是否为目标游戏对应的应用程序信息库目录(即ApplicationInfo.nativeLibraryDir)，也即判断libdir是否为ApplicationInfo.nativeLibraryDir。
若是，则可以确定加载参数中的库名称与原始动态链接库的名称是否一致，也即判断libname是否为libil2cpp.so。在加载参数中的库名称与原始动态链接库的名称一致的情况下，判断目标加载路径下的待更新动态链接库是否能够访问。
这里，加载参数还可以包括待更新动态链接库是否能够访问。具体的，可以判断头部位置处的目标加载路径下是否存在待更新动态链接库，若存在，则可以确定待更新动态链接库能够访问，进而则可以确定利用目标加载方法获取的加载参数，均满足对应的预设条件。
综上可知，路径长度参数对应的预设条件为路径长度等于预设长度，路径格式参数对应的预设条件为预设格式参数等于预设格式参数，路径位置参数对应的预设条件为路径位置参数为应用程序信息库目录，库名称对应的预设条件为库名称等于原始动态链接库的名称，待更新动态链接库是否能够访问对应的预设条件为待更新动态链接库能够访问。
需要说明的是，对路径长度参数、路径格式参数、路径位置参数、库名称、以及待更新动态链接库是否能够访问，这几个加载参数进行判断时，并不存在严格的判断顺序，但当存在至少一个加载参数不满足对应的预设条件时，则不允许利用目标加载路径更新加载参数中的路径位置参数。只有在各个加载参数均满足对应的预设条件时，才可以利用目标加载路径更新加载参数中的路径位置参数。
示例性的，当加载参数满足下述5个条件时，允许利用目标加载路径更新加载参数中的路径位置参数：
1、_size等于2047；2、_fmt＝“％s/％s”；3、libdir等于ApplicationInfo.nativeLibraryDir；4、libname等于libil2cpp.so；5、待更新动态链接库能够访问。
在另一种实施例中，在加载参数不满足预设条件的情况下，利用目标加载方法中的目标调用函数调用替换函数，将加载参数中的路径位置参数和库名称组合为待加载路径；替换函数用于替换原始加载方法的原始函数，与原始函数具有相同功能，且支持调用列表类型的参数。
这里，原始函数为原始加载方法中的调用函数，用于获取加载参数并加载动态链接库，具体的，原始函数具体为上述snprintf函数。替换函数为对原始函数进行替换的函数，与原始函数具有相同功能。替换函数支持调用列表类型的参数，具体的，替换函数可以为vsnprintf函数。
由snprintf函数的声明可知，最后的参数类型是可变类型的参数.(用…表示)也即可知原始函数支持调用可变类型的参数，不支持调用列表类型的参数。
目标调用函数为用于对目标加载方法所代理的原始加载方法进行调用的函数，具体的，目标调用函数可以为PLT Hook技术中的字节钩子调用原方法函数(即BYTEHOOK_CALL_PREV)。待加载路径为原始动态链接库对应的加载路径。
在加载参数不满足预设条件的情况下，目标加载方法需要对原始加载方法进行调用，但由于snprintf_proxy中的BYTEHOOK_CALL_PREV函数，不支持可变类型的参数的传参，所以若直接使用BYTEHOOK_CALL_PREV调用原始加载方法中的原始函数进行加载参数的传参，将导致出现传参异常的问题。
为了避免传参异常问题的出现，可以使用替换函数替换原始函数进行加载参数的传参，其中，替换函数能够将可变类型的参数变为va_list类型的参数。
示例性的，在加载参数不满足预设条件的情况下，可以利用snprintf_proxy中的BYTEHOOK_CALL_PREV函数，调用vsnprintf函数，将加载参数传入va_list，然后利用vsnprintf函数将va_list中的路径位置参数和库名称组合为待加载路径，也即待加载路径为“libdir+libname”。
进一步的，可以加载待加载路径处的原始动态链接库，并利用原始文件运行原始动态链接库。
这里，由于加载参数不满足预设条件，所以无法加载新的libil2cpp.so，为了保证目标游戏的正常运行，可以利用dlopen函数，从待加载路径处加载原始动态链接库，并利用原始文件运行原始动态链接库。
如图3所示，为本公开实施例提供的一种目标加载方法的内部处理流程图，可以包括以下步骤：
snprintf_proxy开始，也即目标加载方法开始运行。
S301、使用va_list承载可变参数。
这里，在加载参数满足预设条件的情况下，可以使用va_list承载可变参数，具体的，可变参数可以为“libdir”和“libname”。
S302、判断路径长度参数指示的路径长度是否为预设长度。
若是，则执行下述S303；若否，则执行下述S311。
S303、判断路径格式参数指示的路径格式是否为预设格式参数。
若是，则执行下述S304；若否，则执行下述S311。
S304：获取第一个可变参数。也即获取“libdir”。
S305：判断第一个可变参数是否为应用程序信息库目录。也即，判断“libdir”是否为“ApplicationInfo.nativeLibraryDir”。
若是，则执行下述S306；若否，则执行下述S310。
S306：获取第二个可变参数。也即获取“libname”。
S307：判断第二个可变参数是否为原始动态链接库的名称。
这里，也即判断“libname”是否为“libil2cpp.so”，若是，则执行下述S308，若否，则执行下述S310。
S308：判断待更新动态链接库是否能够访问。
这里，也即判断待更新动态链接库是否存在，若是，则执行下述S309，若否，则执行下述S310。
S309：利用目标加载路径替换第一个可变参数，并调用原始加载方法。
也即，利用目标加载路径更新libdir，并调用snprintf方法。在S309执行完成后，可以执行S312。
S310：重置va_list。
这里，S310执行完成后，可以执行S311。
S311：调用替换函数，传入va_list。
这里，S311执行完成后，可以执行S312。
S312：释放va_list。
snprintf_proxy结束，也即已经实现将原始libil2cpp.so替换为新的libil2cpp.so。
在一种实施例中，可以按照以下步骤，将原始加载方法替换为目标加载方法：
利用程序链接表钩子技术，为游戏引擎对应的原始加载方法建立目标钩子。
这里，程序链接表钩子技术即为PTL Hook技术。
示例性的，可以利用PTL Hook技术，为unity引擎对应的snprintf方法建立目标hook。
然后，可以为目标钩子挂载目标加载方法；目标加载方法用于获取并更新加载参数中的路径位置参数。
这里，目标加载方法即为上文中的snprintf_proxy方法，其具体的执行流程可以参照图3，不仅可以获取和更新加载参数中的路径位置参数(具体可以将路径位置参数更新为目标加载路径)，还可以用于加载新的libil2cpp.so或原始libil2cpp.so。
进一步的，针对利用动态链接库的目标加载方法，获取加载参数的步骤，可以在unity引擎初始化后，响应于调用动态链接库的原始加载方法，触发目标钩子挂载的目标加载方法。然后利用目标加载方法，按照图3所示的流程获取加载参数。
示例性的，在libmain.so调用snprintf方法时，可以触发为snprintf方法挂载的目标hook，然后，执行目标hook对应的snprintf_proxy方法，从而获取到加载参数。
如此，通过对libmain.so进行hook，实现了用snprintf_proxy方法替换snprintf方法，从而实现将路径位置参数修改为目标加载路径，进而实现对新的libil2cpp.so的加载，实现热更新的目的。
如图4所示，为本公开实施例提供的一种对libmain.so进行hook前后，加载动态链接库的对比示意图，其中，patch安装部分，具体可以包括下载patch文件，然后进行patch文件的校验和合并，得到新的libil2cpp.so。这里，对patch文件的校验即为校验patch文件中动态链接库的链接库校验值，与原始动态链接库的链接库校验值是否一致，在一致的情况下，将patch文件中动态链接库对应的区别链接库内容，与原始动态链接库进行合并，从而得到新的libil2cpp.so并存储至目标加载路径。然后可以将新的libil2cpp.so的目标加载路径，插入到类加载器(Class Loader)的路径列表(Path List)中的nativeLibraryDirectories数组的头部位置。
在patch安装部分完成之后，可以说明能够根据目标加载路径下载到新的libil2cpp.so。
然后，针对hook后的方法而言，可以利用libmain.so调用dlload方法，执行被hook后的snprintf，也即执行snprintf_proxy方法。具体的，关于执行snprintf_proxy方法，具体即为确定加载参数是否满足预设条件。其中，关于确定加载参数是否满足预设条件的步骤，也即判断各个加载参数是否满足对应的预设条件。在加载参数满足预设条件的情况下，利用目标加载路径更新加载参数中的路径位置参数。然后，可以利用dlopen方法，根据目标加载路径，加载新的libil2cpp.so。
针对hook前的方法而言，可以利用libmain.so调用dlload方法，执行snprintf方法，将libdir和libname组合为待加载路径。然后，利用利用dlopen方法，根据待加载路径，加载原始libil2cpp.so。
关于图4中的各步骤的具体实施过程，可以参照上述各实施例，此处不再赘述。
这样，通过借助PLT Hook技术，完成了对libmain.so中的snprintf方法的修改，继而能够在加载libil2cpp.so时，优先加载目标加载路径下的新的libil2cpp.so，从而实现了对libil2cpp.so的热更支持。同时，这种方式也可以实现对libunity.so的热更支持，从而达到热更unity引擎源码的目的。其中，libunity.so为unity引擎对应的动态链接库。
S104：通过更新后的加载参数，加载待更新动态链接库，并利用待更新文件运行待更新动态链接库，以替换目标游戏的原始动态链接库。
具体实施时，unity引擎可以利用dlopen方法，按照目标加载路径加载新的libil2cpp.so至目标存储位置，并从沙盒环境中存储的新的global-metadata.dat提取运行所需的常量信息，然后，利用提取的常量信息，运行新的libil2cpp.so。如此，通过直接运行待更新动态链接库，相当于利用待更新动态链接库替换了原始动态链接库，从而实现对目标游戏的热更新。
在运行待更新动态链接库之后，可以根据待更新动态链接库中包括的具体不同游戏功能的代码，实现对不同游戏功能的响应。
这样，通过对加载参数中的路径位置参数的更新，可以实现将路径位置参数指示的路径，从原始动态链接库的加载路径更新为热更新后的待更新动态链接库的加载路径，进而实现对新的待更新动态链接库的加载。由于包含常量的信息的文件用于保证动态链接库的正常运行，所以通过将目标游戏对应的原始文件替换为待更新文件，可以利用待更新文件保障待更新动态链接库的正常运行，实现对目标游戏的热更新。整个方案通过对原始动态链接库和原始文件进行整体替换的方式，实现了对目标游戏的热更新。由于待更新动态链接库的格式与原始动态链接库的格式一致，所以在运行更新后功能对应的待更新动态链接库时，可以保证不影响运行性能，相比现有技术中的游戏热更新方案，存在更新性能差的问题而言，本公开实施例提供的游戏热更新方法的性能更优，且由于是对原始动态链接库的直接替换，可以使得该游戏热更新方法适用于各种更新场景，实现了游戏热更新性能的提高。
在一种实施例中，为了进一步提高待更新动态链接库的加载速度，还可以在执行S103之前，利用目标游戏对应的系统库加载方法，将目标加载路径处的待更新动态链接库，加载至目标存储介质中。
这里，系统库加载方法(即System.loadLibrary方法)为用于对nativeLibraryDirectories中的加载路径处的动态链接库进行加载的方法，可以按照各个加载路径在nativeLibraryDirectories中的位置顺序，依次对各个加载路径进行加载。同时，若一个动态链接库已经被加载，若按照加载顺序在nativeLibraryDirectories中再一次找到了该动态链接库对应的其他加载路径，可以进行去重判断，从而避免根据其他加载路径进行重复加载的问题。目标存储介质具体可以为终端设备的内存。
具体实施时，在将目标加载路径，插入到nativeLibraryDirectories数组的头部位置之后，可以调用System.loadLibrary方法。这里，由于System.loadLibrary方法是按照各个加载路径在nativeLibraryDirectories中的位置顺序进行加载，且nativeLibraryDirectories数组的头部位置为目标加载路径，所以利用System.loadLibrary方法，可以将头部位置的目标加载路径对应的新的libil2cpp.so，优先加载至内存中。
进一步的，在执行S104之前，还可以判断目标存储介质中是否存储有待更新动态链接库。若是，则可以将目标存储介质中存储的待更新动态链接库，作为加载完成的待更新动态链接库。若否，则可以直接通过更新后的加载参数中的目标加载路径，加载待更新动态链接库
这里，由于已经利用System.loadLibrary方法，将待更新动态链接库加载至目标存储介质中，所以在执行S104时，若直接利用dlopen方法根据目标加载路径加载待更新动态链接库时，会被判重方法对此次加载进行判重拦截。其中，判重方法可以用于对重复对加载同一加载路径处的动态链接库的方法进行拦截。示例性的，判重方法可以判断出目标存储介质中是否存储有待更新动态链接库，若是，则可以对dlopen方法进行拦截，在拦截dlopen方法之后，可以将目标存储介质中存储的待更新动态链接库，作为加载完成的待更新动态链接库。也即，可以将利用System.loadLibrary方法加载至内存中的待更新动态链接库，作为目标游戏对应的待更新动态链接库。
这样，通过预先利用System.loadLibrary方法，将待更新动态链接库加载至内存，可以实现在利用snprintf_proxy方法，将路径位置参数修改为目标加载路径后，在无需dlopen方法的情况下，快速得到加载完成的待更新动态链接库。
可选的，也可以不利用System.loadLibrary方法，将待更新动态链接库加载至内存中，然后在利用snprintf_proxy方法，将路径位置参数修改为目标加载路径后，可以直接利用dlopen方法，将待更新动态链接库加载至内存中。
在一种实施例中，在获取到待更新文件之后，且在启动目标游戏之前，这时目标游戏对应的unity已经加载了原始动态链接库，且沙盒环境中存储额原始文件大概率已经被加载到目标存储位置，从而保证原始动态链接库的正常运行。此时，若直接利用待更新文件对原始文件进行替换，则可能会影响已经加载的原始动态链接库的正常运行，因此，在利用待更新文件替换目标游戏对应的原始文件之前，可以先将待更新文件设置为暂存状态。具体的，可以在重启目标游戏之前，将获取的待更新文件设置为暂存状态。
示例性的，可以将新的global-metadata.dat文件暂存为元信息挂起文件(即meta_pending文件)，其中，meta_pending文件的文件存储状态为暂存状态。
如图5所示，为本公开实施例提供的一种暂存待更新文件的示意图，其中，终端设备可以获取patch文件(即热更新文件)对应的压缩文件(即patch.jar)。然后，可以从patch.jar中的压缩后的待更新文件中，提取与原始文件的区别文件内容。同时，可以从patch.jar中提取出新的global-metadata.dat文件的文件校验值(MD5值)。然后，执行校验文件校验值的操作，具体为确定新的global-metadata.dat文件的文件校验值，与沙盒环境中的原始文件的文件校验值是否一致。在一致的情况下，可以执行合并操作，也即对原始文件和区别文件内容进行合并，得到待更新文件，也即得到新的global-metadata.dat文件。然后，在重启目标游戏之前，可以将新的global-metadata.dat文件暂存为元信息挂载文件(meta_pending文件)。
然后，针对S102中“利用待更新文件替换目标游戏对应的原始文件”的步骤，可以响应于检测到存在处于暂存状态的待更新文件，利用处于暂存状态的待更新文件，替换沙盒环境中的原始文件，并取消待更新文件的暂存状态。
示例性的，在目标游戏重启之后，可以先检测是否存在处于暂存状态的待更新文件，也即检测是否存在meta_pending文件。若是，则说明存在热更新后的新的global-metadata.dat，则可以利用meta_pending文件，覆盖沙盒环境中的原始文件。同时，可以取消待更新文件的暂存状态。这里，由于meta_pending文件已经完成对原始文件的覆盖，所以meta_pending文件已经存储至沙盒环境中，因此需要取消待更新文件的暂存状态，防止在下一次重启之后出现重复替换的问题。示例性的，在利用meta_pending文件，覆盖沙盒环境中的原始文件之后，可以通过删除meta_pending文件的方式，实现对待更新文件的暂存状态的取消。
在另一种实施例中，在利用处于暂存状态的待更新文件，替换沙盒环境中的原始文件之前，还可以备份原始文件。
具体实施时，在目标游戏重启之后，且检测到存在meta_pending文件的情况下，可以先对沙盒环境中的原始文件进行备份，将其备份为原始元信息备份文件(即origin_meta_bak文件)。然后，可以执行利用meta_pending文件，覆盖沙盒环境中的原始文件的步骤。
如图6所示，为本公开实施例提供的一种替换原始文件的示意图，其中，在目标游戏重启之后，且检测到存在meta_pending文件的情况下，可以先执行1、沙盒环境中的原始文件备份为origin_meta_bak文件。然后，可以执行2、利用meta_pending文件，覆盖沙盒环境中的原始文件。最后，可以执行3、删除meta_pending文件。
进一步的，在备份原始文件之后，还可以存在下线更新后功能的情况(也可称为下线patch文件的情况或者下线新的libil2cpp.so以及新的global-metadata.dat的情况)，在这种情况下，可以按照以下步骤实现对原始libil2cpp.so以及原始global-metadata.dat的重新使用：
步骤一、响应于待更新动态链接库对应的更新后功能下线，删除本地存储的热更新信息；热更新信息包括在运行待更新动态链接库的过程中产生的运行信息。
这里，待更新动态链接库对应的更新后功能即为新的libil2cpp.so对应的功能。热更新信息即为在运行待更新动态链接库的过程中产生的所有的运行信息，记录在终端设备的本地，也可称为本地记录的patch信息。
同样的，为了不影响目标游戏的当前次运行，在删除本地存储的热更新信息之后，可以等待重启目标游戏。
步骤二、响应于启动目标游戏，利用备份的原始文件，替换沙盒环境中的待更新文件。
这里，在再次启动(即重启)目标游戏之后，由于更新后功能下线之后，unity引擎将会重新加载原始动态链接库(即原始libil2cpp.so)，而为了保证原始libil2cpp.so的正常运行，需要使用原始文件。因此，在重启目标游戏之后，可以在unity引擎尝试加载原始动态链接库的情况下，确定更新后功能已下线，然后为了保证原始动态链接库的正常运行，此时可以利用备份的origin_meta_bak文件，替换沙盒环境中的待更新文件。
需要说明的是，若出现patch安装后尚未生效即下线的情况，也即出现将新的global-metadata.dat文件暂存为meta_pending文件之后，未等到重启目标游戏就下线新的global-metadata.dat文件的情况，此时，可以直接将meta_pending文件删除。
反之，在patch安装且生效的情况下，则需要利用origin_meta_bak文件，覆盖沙盒环境中的待更新文件，并在覆盖成功的情况下，删除origin_meta_bak文件。如图7所示，为本公开实施例提供的一种还原原始文件的示意图，其中，在出现patch安装后尚未生效即下线的情况下，可以执行a、删除meta_pending文件。在patch安装且生效的情况下，可以执行b、利用origin_meta_bak文件，覆盖沙盒环境中的待更新文件，然后执行c、删除origin_meta_bak文件。
这样，通过使用meta_pending文件暂存，实现了目标游戏重启时对原始global-metadata.dat的安全替换。通过使用origin_meta_bak文件，实现了在更新后功能下线时，对原始global-metadata.dat的还原，从而保证了目标游戏在热更新前后均能正常运行。并且，通过直接替换global-metadata.dat的方式，可以实现在不更改libil2cpp.so的加载逻辑的情况下，完成对global-metadata.dat的热更新。
如图8所示，为本公开实施例提供的一种游戏热更新方法的具体实施流程图，可以包括以下步骤：
S801：下载热更新文件。
可选的，也可以直接下载热更新文件对应的压缩文件。
S802：文件合并。
这里，文件合并具体可以包括两部分，一部分是将热更新文件中的区别文件内容，与当前加载的原始文件合并，得到待更新文件；另一部分是将热更新文件中的区别链接库内容，与当前加载的原始动态链接库合并，得到待更新动态链接库。在得到待更新动态链接库的同时，也可以确定待更新动态链接库及其目标加载路径。
S803：将待更新文件设置为暂存状态。
这里，在目标游戏重启之前，可以将新的global-metadata.dat暂存为meta_pending文件。
S804：将游戏引擎对应的链接库加载路径，更新为待更新动态链接库的目标加载路径。
S805：加载待更新动态链接库。
这里，具体可以利用系统库加载方法，将目标加载路径处的待更新动态链接库，加载至内存中。
S806：加载libmain.so。
S807：执行目标加载方法。
这里，执行目标加载方法即为执行snprintf_proxy方法，其具体过程可以参数上述图3。
S808：利用dlopen方法，加载待更新动态链接库。
这里，可以利用判重方法拦截dlopen方法，然后直接使用利用系统库加载方法加载到内存中的待更新动态链接库。
S809：加载提供常量信息的文件。
这里，在重启目标游戏之前，加载的提供常量信息的文件都是原始文件，在重启目标游戏之后，可以先执行利用待更新文件覆盖沙盒环境中的原始文件的步骤，然后加载的提供常量信息的文件则可以变为待更新文件。并且，在利用待更新文件覆盖沙盒环境中的原始文件之前，还可以备份原始文件，以实现在更新后功能下线时，对原始global-metadata.dat进行还原。
S810：利用待更新文件运行待更新动态链接库。
关于上述S801～S810的具体实施步骤，可以参照上述各实施例，此处不再赘述。
本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思，本公开实施例中还提供了与游戏热更新方法对应的游戏热更新装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述游戏热更新方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
如图9所示，为本公开实施例提供的一种游戏热更新装置的示意图，包括：
获取模块901，用于获取目标游戏对应的待更新文件和待更新动态链接库；所述待更新文件用于在游戏引擎运行所述待更新动态链接库时提供运行依赖信息；
替换模块902，用于响应于所述目标游戏的启动，将所述游戏引擎对应的链接库加载路径，更新为所述待更新动态链接库的目标加载路径，并利用所述待更新文件替换所述目标游戏对应的原始文件；所述原始文件用于在所述游戏引擎运行原始动态链接库时提供运行依赖信息；
更新模块903，用于响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数；
第一加载模块904，用于通过更新后的所述加载参数，加载所述待更新动态链接库，并利用所述待更新文件运行所述待更新动态链接库，以替换所述目标游戏的原始动态链接库。
在一种可能的实施方式中，所述更新模块903，在利用所述目标加载路径，更新加载参数中的路径位置参数时，用于：
利用动态链接库的目标加载方法，获取加载参数，并在所述加载参数满足预设条件的情况下，利用所述目标加载路径更新加载参数中的路径位置参数。
在一种可能的实施方式中，所述更新模块903，用于根据以下步骤确定所述加载参数是否满足预设条件：
在所述加载参数中的路径长度参数等于预设长度、且所述加载参数中的路径格式参数等于预设格式参数的情况下，确定所述加载参数中的可变类型的路径位置参数是否为所述目标游戏对应的应用程序信息库目录；
若是，则在所述加载参数中的库名称与所述原始动态链接库的名称一致的情况下，判断所述目标加载路径下的所述待更新动态链接库是否能够访问；
若是，则确定所述加载参数满足预设条件。
在一种可能的实施方式中，所述更新模块903，还用于：
在所述加载参数不满足预设条件的情况下，利用所述目标加载方法中的目标调用函数调用替换函数，将所述加载参数中的路径位置参数和库名称组合为待加载路径；所述替换函数用于替换原始加载方法的原始函数，与所述原始函数具有相同功能，且支持调用列表类型的参数；
所述第一加载模块904，还用于：
加载所述待加载路径处的所述原始动态链接库，并利用所述原始文件运行所述原始动态链接库。
在一种可能的实施方式中，所述装置还包括：
第二加载模块905，在所述响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数之前，用于：
利用所述目标游戏对应的系统库加载方法，将所述目标加载路径处的所述待更新动态链接库，加载至目标存储介质中；
所述第一加载模块904，在所述通过更新后的所述加载参数，加载所述待更新动态链接库之前，还用于：
判断所述目标存储介质中是否存储有所述待更新动态链接库；
若是，则将所述目标存储介质中存储的所述待更新动态链接库，作为加载完成的待更新动态链接库。
在一种可能的实施方式中，所述获取模块901，在所述获取目标游戏对应的待更新文件和待更新动态链接库时，用于：
获取目标游戏的热更新文件对应的压缩文件，所述压缩文件包括压缩后的待更新文件和压缩后的待更新动态链接库；
从所述压缩后的待更新文件中，提取与所述原始文件的区别文件内容，以及从所述压缩后的待更新动态链接库中，提取与原始动态链接库的区别链接库内容；
在所述压缩后的待更新文件对应的文件校验值，指示所述压缩后的待更新文件与沙盒环境中的所述原始文件相匹配的情况下，将所述原始文件和所述区别文件内容，合并为待更新文件，以及将所述原始动态链接库和所述区别链接库内容，合并为待更新动态链接库。
在一种可能的实施方式中，所述装置还包括：
处理模块906，在所述利用所述待更新文件替换所述目标游戏对应的原始文件之前，用于：
将所述待更新文件设置为暂存状态；
所述替换模块902，在所述利用所述待更新文件替换所述目标游戏对应的原始文件时，用于：
响应于检测到存在处于所述暂存状态的所述待更新文件，利用处于所述暂存状态的所述待更新文件，替换沙盒环境中的所述原始文件，并取消所述待更新文件的暂存状态。
在一种可能的实施方式中，所述处理模块906，在所述利用处于所述暂存状态的所述待更新文件，替换沙盒环境中的所述原始文件之前，还用于：
备份所述原始文件；
所述替换模块902，在备份所述原始文件之后，还用于：
响应于所述待更新动态链接库对应的更新后功能下线，删除本地存储的热更新信息；所述热更新信息包括在运行所述待更新动态链接库的过程中产生的运行信息；
响应于目标游戏的启动，利用备份的所述原始文件，替换沙盒环境中的所述待更新文件。
在一种可能的实施方式中，所述装置还包括：
建立模块907，在利用动态链接库的目标加载方法，获取加载参数之前，用于：
利用程序链接表钩子技术，为所述游戏引擎对应的原始加载方法建立目标钩子；
为所述目标钩子挂载所述目标加载方法；所述目标加载方法用于获取并更新所述加载参数中的路径位置参数；
所述更新模块903，在所述利用动态链接库的目标加载方法，获取加载参数时，用于：
响应于调用所述动态链接库的所述原始加载方法，触发所述目标钩子挂载的所述目标加载方法；
利用所述目标加载方法，获取所述加载参数。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。
基于同一技术构思，本申请实施例还提供了一种计算机设备。参照图10所示，为本申请实施例提供的一种计算机设备的结构示意图，包括：
处理器1001、存储器1002和总线1003。其中，存储器1002存储有处理器1001可执行的机器可读指令，处理器1001用于执行存储器1002中存储的机器可读指令，所述机器可读指令被处理器1001执行时，处理器1001执行下述步骤：S101：获取目标游戏对应的待更新文件和待更新动态链接库；待更新文件用于在游戏引擎运行待更新动态链接库时提供运行依赖信息；S102：响应于目标游戏的启动，将游戏引擎对应的链接库加载路径，更新为待更新动态链接库的目标加载路径，并利用待更新文件替换目标游戏对应的原始文件；原始文件用于在游戏引擎运行原始动态链接库时提供运行依赖信息；S103：响应于游戏引擎的初始化，利用目标加载路径，更新加载参数中的路径位置参数以及S104：通过更新后的加载参数，加载待更新动态链接库，并利用待更新文件运行待更新动态链接库，以替换目标游戏的原始动态链接库。
上述存储器1002包括内存1021和外部存储器1022；这里的内存1021也称内存储器，用于暂时存放处理器1001中的运算数据，以及与硬盘等外部存储器1022交换的数据，处理器1001通过内存1021与外部存储器1022进行数据交换，当计算机设备运行时，处理器1001与存储器1002之间通过总线1003通信，使得处理器1001在执行上述方法实施例中所提及的执行指令。
本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的游戏热更新方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。
本公开实施例所提供的游戏热更新方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行上述方法实施例中所述的游戏热更新方法的步骤，具体可参见上述方法实施例，在此不再赘述。
该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
若本申请技术方案涉及个人信息，应用本申请技术方案的产品在处理个人信息前，已明确告知个人信息处理规则，并取得个人自主同意。若本申请技术方案涉及敏感个人信息，应用本申请技术方案的产品在处理敏感个人信息前，已取得个人单独同意，并且同时满足“明示同意”的要求。例如，在摄像头等个人信息采集装置处，设置明确显著的标识告知已进入个人信息采集范围，将会对个人信息进行采集，若个人自愿进入采集范围即视为同意对其个人信息进行采集；或者在个人信息处理的装置上，利用明显的标识/信息告知个人信息处理规则的情况下，通过弹窗信息或请个人自行上传其个人信息等方式获得个人授权；其中，个人信息处理规则可包括个人信息处理者、个人信息处理目的、处理方式、处理的个人信息种类等信息。
最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种游戏热更新方法，其特征在于，包括：
获取目标游戏对应的待更新文件和待更新动态链接库；所述待更新文件用于在游戏引擎运行所述待更新动态链接库时提供运行依赖信息；
响应于所述目标游戏的启动，将所述游戏引擎对应的链接库加载路径，更新为所述待更新动态链接库的目标加载路径，并利用所述待更新文件替换所述目标游戏对应的原始文件；所述原始文件用于在所述游戏引擎运行原始动态链接库时提供运行依赖信息；
响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数；
通过更新后的所述加载参数，加载所述待更新动态链接库，并利用所述待更新文件运行所述待更新动态链接库，以替换所述目标游戏的原始动态链接库。
2.根据权利要求1所述的方法，其特征在于，利用所述目标加载路径，更新加载参数中的路径位置参数，包括：
利用动态链接库的目标加载方法，获取加载参数，并在所述加载参数满足预设条件的情况下，利用所述目标加载路径更新加载参数中的路径位置参数。
3.根据权利要求2所述的方法，其特征在于，根据以下步骤确定所述加载参数是否满足预设条件：
在所述加载参数中的路径长度参数等于预设长度、且所述加载参数中的路径格式参数等于预设格式参数的情况下，确定所述加载参数中的可变类型的路径位置参数是否为所述目标游戏对应的应用程序信息库目录；
若是，则在所述加载参数中的库名称与所述原始动态链接库的名称一致的情况下，判断所述目标加载路径下的所述待更新动态链接库是否能够访问；
若是，则确定所述加载参数满足预设条件。
4.根据权利要求3所述的方法，其特征在于，所述方法还包括：
在所述加载参数不满足预设条件的情况下，利用所述目标加载方法中的目标调用函数调用替换函数，将所述加载参数中的路径位置参数和库名称组合为待加载路径；所述替换函数用于替换原始加载方法的原始函数，与所述原始函数具有相同功能，且支持调用列表类型的参数；
加载所述待加载路径处的所述原始动态链接库，并利用所述原始文件运行所述原始动态链接库。
5.根据权利要求1所述的方法，其特征在于，在所述响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数之前，还包括：
利用所述目标游戏对应的系统库加载方法，将所述目标加载路径处的所述待更新动态链接库，加载至目标存储介质中；
在所述通过更新后的所述加载参数，加载所述待更新动态链接库之前，还包括：
判断所述目标存储介质中是否存储有所述待更新动态链接库；
若是，则将所述目标存储介质中存储的所述待更新动态链接库，作为加载完成的待更新动态链接库。
6.根据权利要求1所述的方法，其特征在于，所述获取目标游戏对应的待更新文件和待更新动态链接库，包括：
获取目标游戏的热更新文件对应的压缩文件，所述压缩文件包括压缩后的待更新文件和压缩后的待更新动态链接库；
从所述压缩后的待更新文件中，提取与所述原始文件的区别文件内容，以及从所述压缩后的待更新动态链接库中，提取与原始动态链接库的区别链接库内容；
在所述压缩后的待更新文件对应的文件校验值，指示所述压缩后的待更新文件与沙盒环境中的所述原始文件相匹配的情况下，将所述原始文件和所述区别文件内容，合并为待更新文件，以及将所述原始动态链接库和所述区别链接库内容，合并为待更新动态链接库。
7.根据权利要求1所述的方法，其特征在于，在所述利用所述待更新文件替换所述目标游戏对应的原始文件之前，还包括：
将所述待更新文件设置为暂存状态；
所述利用所述待更新文件替换所述目标游戏对应的原始文件，包括：
响应于检测到存在处于所述暂存状态的所述待更新文件，利用处于所述暂存状态的所述待更新文件，替换沙盒环境中的所述原始文件，并取消所述待更新文件的暂存状态。
8.根据权利要求7所述的方法，其特征在于，在所述利用处于所述暂存状态的所述待更新文件，替换沙盒环境中的所述原始文件之前，还包括：
备份所述原始文件；
在备份所述原始文件之后，还包括：
响应于所述待更新动态链接库对应的更新后功能下线，删除本地存储的热更新信息；所述热更新信息包括在运行所述待更新动态链接库的过程中产生的运行信息；
响应于目标游戏的启动，利用备份的所述原始文件，替换沙盒环境中的所述待更新文件。
9.根据权利要求2所述的方法，其特征在于，在利用动态链接库的目标加载方法，获取加载参数之前，还包括：
利用程序链接表钩子技术，为所述游戏引擎对应的原始加载方法建立目标钩子；
为所述目标钩子挂载所述目标加载方法；所述目标加载方法用于获取并更新所述加载参数中的路径位置参数；
所述利用动态链接库的目标加载方法，获取加载参数，包括：
响应于调用所述动态链接库的所述原始加载方法，触发所述目标钩子挂载的所述目标加载方法；
利用所述目标加载方法，获取所述加载参数。
10.一种游戏热更新装置，其特征在于，包括：
获取模块，用于获取目标游戏对应的待更新文件和待更新动态链接库；所述待更新文件用于在游戏引擎运行所述待更新动态链接库时提供运行依赖信息；
替换模块，用于响应于所述目标游戏的启动，将所述游戏引擎对应的链接库加载路径，更新为所述待更新动态链接库的目标加载路径，并利用所述待更新文件替换所述目标游戏对应的原始文件；所述原始文件用于在所述游戏引擎运行原始动态链接库时提供运行依赖信息；
更新模块，用于响应于游戏引擎的初始化，利用所述目标加载路径，更新加载参数中的路径位置参数；
第一加载模块，用于通过更新后的所述加载参数，加载所述待更新动态链接库，并利用所述待更新文件运行所述待更新动态链接库，以替换所述目标游戏的原始动态链接库。
11.一种计算机设备，其特征在于，包括：处理器、存储器，所述存储器存储有所述处理器可执行的机器可读指令，所述处理器用于执行所述存储器中存储的机器可读指令，所述机器可读指令被所述处理器执行时，所述处理器执行如权利要求1至9任意一项所述的游戏热更新方法的步骤。
12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被计算机设备运行时，所述计算机设备执行如权利要求1至9任意一项所述的游戏热更新方法的步骤。
CN202310217391.1A 2023-03-08 2023-03-08 一种游戏热更新方法、装置、计算机设备和存储介质 Pending CN116173511A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310217391.1A CN116173511A (zh) 2023-03-08 2023-03-08 一种游戏热更新方法、装置、计算机设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310217391.1A CN116173511A (zh) 2023-03-08 2023-03-08 一种游戏热更新方法、装置、计算机设备和存储介质

Publications (1)

Publication Number Publication Date
CN116173511A true CN116173511A (zh) 2023-05-30

Family

ID=86442310

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310217391.1A Pending CN116173511A (zh) 2023-03-08 2023-03-08 一种游戏热更新方法、装置、计算机设备和存储介质

Country Status (1)

Country Link
CN (1) CN116173511A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116414424A (zh) * 2023-06-09 2023-07-11 建信金融科技有限责任公司 热更新方法、装置、设备及存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116414424A (zh) * 2023-06-09 2023-07-11 建信金融科技有限责任公司 热更新方法、装置、设备及存储介质
CN116414424B (zh) * 2023-06-09 2023-09-12 建信金融科技有限责任公司 热更新方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
JP4288292B2 (ja) オペレーティングシステム監視設定情報生成装置及びオペレーティングシステム監視装置
US9081596B2 (en) Information processing device, virtual machine creation method, and application distribution system
CN107506221B (zh) 应用程序升级方法、装置及设备
US8196130B2 (en) Tri-phase boot process in electronic devices
JP4510373B2 (ja) 共有名を用いてコンポーネントにセキュリティを提供するシステムおよび方法
CN111782302B (zh) 进程更新方法和装置、存储介质及电子设备
CN108229107B (zh) 一种Android平台应用程序的脱壳方法及容器
CN112256286B (zh) 一种应用运行的方法、装置及计算机存储介质
CN108229148B (zh) 一种基于Android虚拟机的沙箱脱壳方法及系统
EP1869606A1 (en) Software protection
CN109255235B (zh) 基于用户态沙箱的移动应用第三方库隔离方法
CN111008034B (zh) 一种补丁生成方法及装置
WO2021143845A1 (zh) 扩展系统分区的方法、装置、存储介质和计算机设备
JP2008502968A (ja) 中間オブジェクト指向言語を備えるソフトウェアをポータブル・デバイスにロードするための方法
CN111880987A (zh) 应用程序的动态监测方法、装置、存储介质以及电子装置
CN107797818A (zh) 应用程序升级方法及装置
CN116173511A (zh) 一种游戏热更新方法、装置、计算机设备和存储介质
CN113867768A (zh) 操作系统处理方法、装置、电子设备及存储介质
CN111399860A (zh) 轻应用部署方法、装置、计算机设备和存储介质
CN112286543B (zh) 一种应用服务部署方法及装置
CN116775087A (zh) 一种热修复方法、装置、电子设备及存储介质
CN114090434B (zh) 一种代码调试方法、装置、计算机设备和存储介质
CN108536444B (zh) 插件编译方法、装置、计算机设备和存储介质
CN107783837B (zh) 一种进行存储扩展的方法、装置及电子设备
CN113220314B (zh) App资源加载及apk生成方法、装置、设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination