游戏的漏洞修复方法和装置

技术领域

本发明涉及计算机领域，具体而言，涉及一种游戏的漏洞修复方法和装置。

背景技术

游戏运行时的逻辑和数据十分复杂，因此也很容易出现各种漏洞。及时有效地修复漏洞，能给玩家带来良好的体验。目前修复游戏漏洞主要有Patch和Hotfix两种方式，大部分游戏都会将两种方式结合使用。

Patch是指游戏在打开时通过一系列显式的过程下载游戏补丁，并更改游戏的内容。一般涉及的内容多，时效性弱，修复流程也较长，用户需要重新启动游戏或者手动进行下载才能进行漏洞修复。Patch方式适合大量内容的修改和更新，以及一些非代码层面上的修复，比如游戏中的模型资源、音频文件等，是游戏中一种必不可少的修复手段。

Hotfix技术指的是通过生成一个热修复补丁，然后发送到用户端，在游戏运行过程中执行静默修复的方式。该方式时效性极强，对用户的影响最小，且通常用户是无法察觉的。

但就目前的Hotfix技术来说，游戏中功能模块众多，通常一个模块都有特定的技术人员来维护，因此其对技术人员的依赖较深，而漏洞的发生一般都是紧急而且不定时的，这时候需要找到专门的技术人员来进行修复并书写补丁并不容易，从而有可能因为修复流程过慢影响玩家体验。

针对相关技术中采用Hotfix技术对游戏进行修复时对技术人员依赖较深的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种游戏的漏洞修复方法和装置，以至少解决相关技术中采用Hotfix技术对游戏进行修复时对技术人员依赖较深的技术问题。

根据本申请实施例的一个方面，提供了一种游戏的漏洞修复方法，包括：接收游戏修复指令；响应于游戏修复指令，从版本控制系统中获取修改记录，其中，修改记录用于记录对待修复游戏的程序代码或策划表进行的修改信息；基于修改记录自动生成修复补丁；将修复补丁上传服务器，其中，服务器用于提供下载链接，以使待修复游戏的客户端从下载链接中下载修复补丁，并对待修复游戏的漏洞进行修复。

进一步地，从版本控制系统中获取修改记录，包括：调用代码比对工具对此次修复中提交的代码文件和上一版本的代码文件进行版本比对，得到修改记录；其中，在此次修复中提交了多次代码文件的情况下，通过代码比对工具分别对每次提交的代码文件和上一版本的代码文件进行版本比对，得到多个比对结果，并将多个比对结果进行合并，得到此次修复的修改记录。

进一步地，修改记录中包括：修改行标识、修改行所在文件的文件标识以及修改内容，修改记录包括对策划表的修改，基于修改记录自动生成修复补丁，包括：根据文件标识确定修改行所在文件，并根据修改行标识在修改行所在文件中确定修改行；基于修改内容对修改行进行修改，得到修复文件；对修复文件进行封装得到修复补丁。

进一步地，基于修改内容对修改行进行修改，得到修复文件，包括：在修改行所在文件为策划表的情况下，基于修改内容替换策划表中的修改行，得到修复文件；在修改行所在文件为程序代码的情况下，通过修改行确定修改行所在的类和接口，并基于修改内容替换修改行所在的接口，得到修复文件。

进一步地，通过修改行确定修改行所在的类和接口，包括：从修改行的位置向上寻找，匹配类和接口的编译文法，并根据编译文法确定修改行所在的类和接口；或基于修改行向上遍历抽象语法树，确定修改行所在的类和接口。

进一步地，服务器用于提供测试链接，其中，测试对象从测试链接处下载修复补丁进行补丁验证，在补丁验证通过的情况下开放下载链接的访问权限，待修复游戏的客户端从开放访问权限的下载链接中下载修复补丁。

进一步地，在将修复补丁上传服务器之后，上述方法还包括：向处于游戏中的客户端发出修复命令，处于游戏中的客户端在接收到修复命令后通过下载链接下载修复补丁进行修复；其中，未处于游戏中的客户端在进入待修复游戏的同时主动通过下载链接下载修复补丁进行修复。

进一步地，将修复补丁上传服务器，包括：将修复补丁拆分为多个文件块，并分别对每个文件块进行加密后上传至服务器；其中，客户端下载加密后的文件块后，分别对每个加密后的文件块进行解密，并按照解密后的文件块对待修复游戏进行修复。

根据本申请实施例的一个方面，提供了一种游戏的漏洞修复装置，包括：接收模块，用于接收游戏修复指令；获取模块，用于响应于游戏修复指令，从版本控制系统中获取修改记录，其中，修改记录用于记录对待修复游戏的程序代码或策划表进行的修改信息；生成模块，用于基于修改记录自动生成修复补丁；上传模块，用于将修复补丁上传服务器，其中，服务器用于提供下载链接，以使待修复游戏的客户端从下载链接中下载修复补丁，并对待修复游戏的漏洞进行修复。

根据本申请实施例的一个方面，提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述的游戏的漏洞修复方法。

根据本申请实施例的一个方面，提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述的游戏的漏洞修复方法。

在本发明实施例中，接收游戏修复指令；响应于游戏修复指令，从版本控制系统中获取修改记录，其中，修改记录用于记录对待修复游戏的程序代码或策划表进行的修改信息；基于修改记录自动生成修复补丁；将修复补丁上传服务器，其中，服务器用于提供下载链接，以使待修复游戏的客户端从下载链接中下载修复补丁，并对待修复游戏的漏洞进行修复。上述方案将Hotfix技术中修复补丁的生成由人工生成变化为自动生成，从而减少了技术人员的参与，降低了Hotfix修复流程对技术人员的依赖，同时非技术人员也可以对自动化流程进行监控，以免自动化流程出错，解决了相关技术中采用Hotfix技术对游戏进行修复时对技术人员依赖较深的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是相关技术中使用Hotfix技术对游戏进行修复的流程图；

图2是根据本申请实施例的一种游戏的修复方法的流程图，；

图3是根据本申请实施例的一种游戏补丁修复的示意图；

图4是根据本申请实施例的一种自动生成修复补丁的示意图；

图5是根据本申请实施例的一种生成修复补丁的示意图；

图6是根据本申请实施例的一种上传修复补丁的示意图；

图7是根据本申请实施例的一种使用链接的方式进行提供修复补丁下载功能的示意图；

图8是根据本申请实施例的一种将修复文件划分为文件块传输的示意图；

图9是根据本申请实施例的一种游戏的修复装置的示意图。

首先，对本申请实施例出现的专业名词进行解释：

Patch：游戏补丁，指用于更新游戏内容的文件资源。

Hotfix：热修复补丁，指一段可以静默运行的代码，运行在内存中，执行后可以自动修复程序上的代码漏洞。

Python：一门编程语言，可以用于游戏开发和脚本开发。

svn：即subversion，一种用于多人协作办公工具，能够进行版本控制的工具。团队成员每次修改和提交都会生成svn提交记录。

diff：用于通过对不同版本间的记录进行比较，获得特定提交记录修改的内容。

耦合性：指多份补丁由于顺序先后有可能产生不同效果。

策划表：由游戏策划填写，能作用于对游戏中，并对数值、玩法等产生影响的表格数据。

AST：即Abstract Syntax Tree，抽象语法树，是一种代码语法结构的树状显示。

CDN：即Content Delivery Network，内容分发网络，是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率，是一种能够提高用户访问速度的网络架构。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

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

图1是相关技术中使用Hotfix技术对游戏进行修复的流程图，结合图1所示，通过技术人员发现和定位问题，通过技术人员书写补丁内容，生成加密后的Hotfix补丁，将Hotfix补丁上传至游戏服务器，游戏服务器将补丁下发给用户，用户执行补丁修复漏洞。由此可知，相关技术中使用Hotfix技术对游戏进行修复时，对技术人员过于依赖，导致有些情况下难以对游戏漏洞难以及时修复。基于这一情况，本发明实施例提供了一种游戏的修复方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图2是根据本申请实施例的一种游戏的修复方法的流程图，如图2所示，该方法包括如下步骤：

步骤S202，接收游戏修复指令。

具体的，上述游戏修复指令用于触发漏洞修复服务器执行如下的步骤。上述修复服务器可以是单独的服务器，也可以是游戏服务器。

在一种可选的实施例中，在发现游戏脚本错误并且在内部修复完成后，可以发出游戏修复指令，以启动修复脚本(自动化程序)来生成修复补丁。

步骤S204，响应于游戏修复指令，从版本控制系统中获取修改记录，其中，修改记录用于记录对待修复游戏的程序代码或策划表进行的修改信息。

具体的，可以通过运行修复脚本执行上述步骤，修复脚本可以是Python脚本，上述版本控制系统可以是svn或git(分布式版本控制系统)。技术人员会将修改后的代码文件提交至版本控制系统，因此版本控制系统中存储有待修复游戏的代码(包括代码和游戏策划表)的多个版本。

修改记录包括对游戏代码的修改信息。漏洞修复服务器在接收到游戏修复指令后，自动运行修复脚本，以自动化的获取此次修复的修改记录，以生成对应的修复补丁。

步骤S206，基于修改记录自动生成修复补丁。

具体的，仍可以通过运行修复脚本执行上述步骤。上述方案使用自动化的方法生成Hotfix补丁。在一种可选的实施例中，可以通过修改记录对修改文件进行修复得到修复文件，再对修复文件进行封装，即可得到上述修复补丁。

步骤S208，将修复补丁上传服务器，其中，服务器用于提供下载链接，以使待修复游戏的客户端从下载链接中下载修复补丁，并对待修复游戏的漏洞进行修复。

上述服务器即为修复服务器。修复服务器提供一下载链接，游戏客户端可以基于该下载链接下载修复补丁，以对待修复游戏进行漏洞修复。游戏客户端从下载链接中下载修复补丁后，通过静默修复的方式修复游戏漏洞，从而不影响正在游戏中的玩家。

图3是根据本申请实施例的一种游戏补丁修复的示意图，结合图3所示，在本申请的方案中，首先发现和定位漏洞，然后通过修复脚本自动生成加密的修复补丁，将加密的修复补丁上传至服务器，游戏客户端从服务器提供的下载链接中下载并使用补丁执行漏洞修复。

传统方案中技术人员是修复过程中的核心要素，对修复的效率和成功率起到了决定性的作用，但人工往往低效和容易出错。本申请上述实施例接收游戏修复指令；响应于游戏修复指令，从版本控制系统中获取修改记录，其中，修改记录用于记录对待修复游戏的程序代码或策划表进行的修改信息；基于修改记录自动生成修复补丁；将修复补丁上传服务器，其中，服务器用于提供下载链接，以使待修复游戏的客户端从下载链接中下载修复补丁，并对待修复游戏的漏洞进行修复。上述方案将Hotfix技术中的修复补丁的生成由人工生成变化为自动生成，从而减少了技术人员的参与，降低了Hotfix修复流程对技术人员的依赖，同时非技术人员也可以对自动化流程进行监控，以免自动化流程出错，解决了相关技术中采用Hotfix技术对游戏进行修复时对技术人员依赖较深的技术问题。

作为一种可选的实施例，从版本控制系统中获取修改记录，包括：调用代码比对工具对此次修复中提交的代码文件和上一版本的代码文件进行版本比对，得到修改记录；其中，在此次修复中提交了多次代码文件的情况下，通过代码比对工具分别对每次提交的代码文件和上一版本的代码文件进行版本比对，得到多个比对结果，并将多个比对结果进行合并，得到此次修复的修改记录。

具体的，上一版本的代码文件用于表示进行上一次修复后得到的代码文件。

在一次修复过程中，技术人员可能向版本管理系统提交了多个版本的代码文件，这些版本可能是针对一个漏洞的修复，也可能是针对多个漏洞，例如，由于游戏是多人协作开发，可能会由不同的开发人员针对不同的漏洞进行修复提交，因此在此次修复包括多次修改的情况下，对每次提交的代码文件均与之前的版本进行比对，而不能仅以版本管理系统中的最新版本或最初版本进行代码比对。

在一种可选的实施例中，在技术人员修复问题后，获取svn上的提交版本，然后使用svn的diff工具得到此次修复对应的提交内容，如果此次修复涉及到多次提交，则需要对多个提交版本进行代码比对，并将多次代码比对结果进行合并，得到一份完整的修改记录。修改记录中记录了修改行和修改行所在的文件。

作为一种可选的实施例，修改记录中包括：修改行标识、修改行所在文件的文件标识以及修改内容，基于修改记录自动生成修复补丁，包括：根据文件标识确定修改行所在文件，并根据修改行标识在修改行所在文件中确定修改行；基于修改内容对修改行进行修改，得到修复文件；对修复文件进行封装得到修复补丁。

上述方案中，通过修改行所在文件的文件标识找到修改文件，再根据修改行标识找到修改文件中的修改行，从而能够基于修改内容对修改行进行修改，得到修复文件。

图4是根据本申请实施例的一种自动生成修复补丁的示意图，结合图4所示，将修复内容提交到svn，获得不同版本之间的代码比对结果，该比对结果即为修改记录，通过代码比对溯源生成修复文件，最后将多个修复文件进行合并，并将合并的修复文件进行封装后，得到Hotfix修复补丁。

上述方案使用自动化的方法生成Hotfix补丁。在使用svn进行版本管理的项目中，可以根据svn的版本提交记录，进行diff和合并等操作，并在此基础上提取修复内容，从而能够自动生成一份Hotfix补丁，进而能有效降低对技术人员的依赖，只需要在流程中指定svn的提交版本，就能自动生成一份Hotfix补丁，达到了降低了开发中的人力成本，并提高了流程执行的效率的效果。

作为一种可选的实施例，基于修改内容对修改行进行修改，得到修复文件，包括：在修改行所在文件为策划表的情况下，基于修改内容替换策划表中的修改行，得到修复文件；在修改行所在文件为程序代码的情况下，通过修改行确定修改行所在的类和接口，并基于修改内容替换修改行所在的接口，得到修复文件。

上述方案中，策划表的Hotfix补丁采用的方法是将策划表里的修改行进行替换。因此对于策划表，直接从修改记录中提取修改策划表的表名(即修改文件的文件标识)，以及修改行的全部内容，再基于修改内容对修改策划表中的修改行进行替换，即可得到策划表对应的修改文件。

上述方案中，程序代码的Hotfix补丁采用的方法是对接口的替换。因此对于程序代码，需要分别找到修改行所在的文件、类和接口，并对接口进行替换，即可得到程序代码对应的修改文件。将策划表修改和程序代码修改分别得到修复文件后，通过封装脚本将其封装成补丁的形式，即完成了自动化生成Hotfix补丁的流程。

图5是根据本申请实施例的一种生成修复补丁的示意图，结合图5所示，首先从修改记录中获得修改的行和修改行所在的文件。对于策划表的修改，提取修改文件中的策划表，并对策划表中修改行进行替换；对于程序代码的修改，提取修改文件中的程序代码，寻找修改行所在的类和接口，对接口进行替换。最后将对策划表中修改的行的替换结果和对程序代码中接口的替换结果进行合并封装，得到修复补丁。

作为一种可选的实施例，通过修改行确定修改行所在的类和接口，包括：从修改行的位置向上寻找，匹配类和接口的编译文法，并根据编译文法确定修改行所在的类和接口；或基于修改行向上遍历抽象语法树，确定修改行所在的类和接口。

由于修改记录只完整记录了文件信息，因此需要定位具体的类和接口。上述方案提供了两种方案：

在第一种方案中，根据程序代码的结构特点，从修改行的位置往上进行寻找，匹配类和接口的编译文法，从而得出具体的类和接口。这种方式较为简单，但程序代码为特定的编程语言，且对程序代码的书写规范有一定要求。

在第二种方案中，遍历程序代码的AST获得修改行所在的节点，然后向上遍历节点，从而获取具体的类和接口。这种方式能够适用于各种语言。

在一种可选的实施例中，可以在修复脚本中都写入上述两种方案，并在修复脚本中写入一个判断步骤，在判断出程序代码为预设的代码规范良好的编程语言(例如Python语言)时，调用上述第一种方案来寻找修改行所在的类和接口，而在判断出程序代码为其他编程语言时，调用上述第二种方案来寻找修改行坐所的类和接口。

作为一种可选的实施例，服务器用于提供测试链接，其中，测试对象从测试链接处下载修复补丁进行补丁验证，在补丁验证通过的情况下开放下载链接的访问权限，待修复游戏的客户端从开放访问权限的下载链接中下载修复补丁。

在上述方案中，服务器可以同时提供测试链接和下载链接。也即，服务器可以将修复补丁同时上传至测试链接和下载链接所在位置。

具体的，测试对象可以测试用户的测试客户端，测试客户端通过测试链接下载修复补丁后，使用修复补丁对游戏漏洞进行修复，在修复成功的情况下确定修复补丁验证通过，并触发下载链接开通链接访问权限，否则确定修复补丁验证失败，需要重新的修复补丁进行调整更新。

在上述方案中，具有测试环境和正式的补丁修复环境，测试环境对应于上述测试连接，正式的补丁修复环境对应于上述的下载链接。测试环境用于供测试用户下载待测试的修复补丁，对修复补丁进行验证；正式的补丁修复环境用于玩家用户下载对游戏漏洞进行修复。

图6是根据本申请实施例的一种上传修复补丁的示意图，结合图6所示，在一种可选的实施例中，可以同时为生成的Hotfix修复补丁提供测试链接和下载链接。测试对象(即测试用户的客户端)从测试链接处下载补丁，以对修复补丁进行验证，在验证通过的情况下，触发下载链接开通链接访问权限，此时玩家的客户端即可主动下载修复补丁进行游戏漏洞的修复。

需要注意的是，客户端对修复补丁的下载可以采用CDN内容分发网络进行，在这样的场景下，上述服务器提供的下载链接可以分发至多个下载节点，客户端从与其对应的下载节点中下载修复补丁。但CDN为了加速网络链接的速度，会在下载节点处对内容进行缓存，比保持一定的刷新频率，因此客户端下载修复补丁时，补丁内容很可能是旧的。针对这一问题，本方案在修复补丁生成后，同时提供测试链接和下载链接上，此时由于下载链接还没有开放访问权限，因此玩家仍然无法下载到最新的补丁内容。当补丁测试完成时开放访问权限，下载链接中的修复补丁也正是最新的修复补丁，从而使得在CDN的分发场景下，客户端能够从各自的下载节点中下载到最新的修复补丁。

上述方案中，修复补丁从通过服务器发送改为客户端主动从下载链接处下载。一方面能够修复客户端连接服务器之前的内容，另一方面也可以将下载压力从游戏服务器转移至下载节点，有效地缓解了游戏服务器的压力，也避免了服务器故障而导致的修复失败问题。这一做法也使得Hotfix和Patch这两个功能类似的流程，在原理和数据传输方面更加一致。

进一步的，由于Hotfix补丁的生成和上传均可以采用自动化流程执行，补丁的下载和执行也可以同时完成，因此可以将这些步骤进行合并简化，从而减少了诸多流程中的环节，big减少环节能够缓解流程在特定环节上阻塞的概率，使得Hotfix的修复流程更加简洁和高效。

图7是根据本申请实施例的一种使用链接的方式进行提供修复补丁下载功能的示意图，结合图7所示，将修复补丁使用链接的方式进行管理，从而让客户端能够使用链接下载的方式获得修复补丁，进而可以有效降低服务器的压力，使修复补丁可以涉及到更多的漏洞。

作为一种可选的实施例，在将修复补丁上传服务器之后，上述方法还包括：向处于游戏中的客户端发出修复命令，处于游戏中的客户端在接收到修复命令后通过下载链接下载修复补丁进行修复；其中，未处于游戏中的客户端在进入待修复游戏的同时主动通过下载链接下载修复补丁进行修复。

上述方案中，客户端使用链接下载的方式获得Hotfix补丁。游戏的客户端通常处于两种状态，一种状态时正在游戏中，另一种状态是退出状态，即未在游戏中。下面分别对两种状态下的客户端对游戏的漏洞修复进行说明。

对于已经在游戏中的客户端，修复服务器发起命令让这些客户端去下载链接上下载Hotfix修复补丁。但该命令不会在游戏中弹出提示信息，也不会使游戏中止，而只是静默执行命令。

而对于还没进入游戏的玩家，其无法收到修复服务器的命令，因此这些客户端会在进入游戏的同时(即客户端和游戏服务器建立连接关系时)，自动去下载链接上获取Hotfix补丁。这样就能保证所有的玩家都获得最新的Hotfix补丁内容。

通过设置下载链接的方式让客户端主动下载Hotfix补丁，从而无需通过游戏服务器进行漏洞修复，支持更多情况下的修复，同时也缩短了数据的传输链路，减轻了服务器的压力，降低了服务器的成本，避免了服务器故障对于修复紧急漏洞的影响。

目前很多游戏采用的是逐帧更新的策略，通常游戏能够每秒保持30帧以上的更新频率，就会使视觉效果较为流畅，也即每帧的耗时需要小于33ms。由于修复补丁涉及到程序源代码和策划表的原始内容，因此需要进行加密处理，玩家下载后再进行解密，但对于过大的修复补丁来说，在部分配置较低的手机上，解密的过程非常耗时，无法让游戏每帧的耗时保持在33毫秒内，从而可能产生卡顿。基于这一问题，作为一种可选的实施例，将修复补丁上传服务器，包括：

将修复补丁拆分为多个文件块，并分别对每个文件块进行加密后上传至服务器；

其中，客户端下载加密后的文件块后，分别对每个加密后的文件块进行解密，并按照解密后的文件块对待修复游戏进行修复。

图8是根据本申请实施例的一种将修复文件划分为文件块传输的示意图，结合图8所示，使用动态长度对修复补丁进行分割得到多个文件块，对分割后的每个文件块单独加密，客户端下载后对每个文件块进行解密，并使用分帧策略进行漏洞修复。

上述方案采用文件分块和分帧处理的思想减缓修复时的卡顿，从而使得设备能够支持更大的修复内容。客户端在文加块的解密时，可以一帧解密一个文件块。

上述方案中，将一个大的补丁文件拆成多个部分，对每一个部分进行单独加密，然后再将加密后的每个部分合并成一个补丁文件。客户端下载后，先对补丁文件进行拆分，然后对拆分后的每个文件块进行解密。在这样的方案中，虽然玩家客户端解密过程的总耗时并不会减少，但因为游戏采用的是逐帧更新的策略，所以把每个块解密的耗时分散了不同的帧进行执行，就能避免游戏卡顿的问题了。以某品牌低端手机为例，对未分开的文件进行解密，耗时200毫秒，在加上游戏本身的耗时20毫秒，因此在修复补丁执行的那一刻，耗时达到了220毫秒，从而使游戏帧率下降到每秒不足5帧，卡顿十分严重。而使用上述方案将补丁文件分为20个块后，每个块解密需要10毫秒，此时加上游戏耗时的20毫秒，每帧耗时变成30毫秒，仍然能够让游戏保持在每秒30帧以上，从而保证游戏流畅运行。

在一种可选的方案中，可以根据修复补丁的大小来确定划分的文件块的数量，以最大程度地保证低端机型不会卡顿。但需要注意的是，文件块的数量在过多的情况下解密的过程需要的帧数也会变多，从而导致补丁修复延迟变大，例如：如果将修复补丁分为900个文件块，由于游戏每秒只能执行30帧，对应处理30个文件块，所以这些块需要在30秒后才能被全部解密完成，大大延迟了补丁修复的速度。因此在特殊的情况下，对于不同的配置和不同的补丁长度，可以调节分块数量的方式。

在一种可选实施例中，通过修复脚本生成修复补丁后，还可以读取安装玩家客户端的设备机型，并根据设备机型对应的设备配置信息确定对修复补丁所划分的文件块的数量。对于配置较高的设备机型，可以尽快能的划分出数量较少的文件块，甚至不进行划分；而对于配置较低的设备机型，可以划分出较多的文件块。

在另一种可选的实施例中，通过修复脚本还可以根据修复补丁的大小判断是否对齐进行划分，例如，可以设置一文件大小的阈值，在修复补丁的文件大小大于该阈值时再对修复补丁进行划分，否则不进行划分。

采用文件分割和分帧修复的思想来减缓修复时的卡顿，能够有效的减少Hotfix补丁修复时卡顿，一方面能够最大程度上减少对玩家游戏体验的影响，另一方面也能够同时支持对更多内容的修复，使得Hotfix补丁修复的形式更加灵活。且通过改善修复中的卡顿情况，以支持更多内容的修复，例如，由于按顺序依次进行修复多个补丁存在多种缺陷，因此可以将多次修复合并为一个单独的补丁，并进行改进以支持更多的内容，从而在缓解修复时卡顿的同时也减少了多个修复之间Hotfix补丁的耦合关系。

综上，通过以上对传统Hotfix流程的改进，使得本方案中Hotfix的流程自动化程度更高，修复效率更快，对服务器依赖更少，且支持修复的内容更多，极大程度地提升了Hotfix技术的普适性和高效性。

本发明实施例提供了一种游戏的修复装置的实施例，图9是根据本申请实施例的一种游戏的修复装置的示意图，如图9所示，该装置包括：

接收模块90，用于接收游戏修复指令；

获取模块92，用于响应于游戏修复指令，从版本控制系统中获取修改记录，其中，修改记录用于记录对待修复游戏的程序代码或策划表进行的修改信息；

生成模块94，用于基于修改记录自动生成修复补丁；

上传模块96，用于将修复补丁上传服务器，其中，服务器用于提供下载链接，以使待修复游戏的客户端从下载链接中下载修复补丁，并对待修复游戏的漏洞进行修复。

作为一种可选的实施例，获取模块包括：比对子模块，用于调用代码比对工具对此次修复中提交的代码文件和上一版本的代码文件进行版本比对，得到修改记录；其中，在此次修复中提交了多次代码文件的情况下，通过代码比对工具分别对每次提交的代码文件和上一版本的代码文件进行版本比对，得到多个比对结果，并将多个比对结果进行合并，得到此次修复的修改记录。

作为一种可选的实施例，修改记录中包括：修改行标识、修改行所在文件的文件标识以及修改内容，修改记录包括对策划表的修改，生成模块包括：获取子模块，用于根据文件标识确定修改行所在文件，并根据修改行标识在修改行所在文件中确定修改行；修改子模块，用于基于修改内容对修改行进行修改，得到修复文件；封装子模块，用于对修复文件进行封装得到修复补丁。

作为一种可选的实施例，修改子模块包括：第一替换单元，用于在修改行所在文件为策划表的情况下，基于修改内容替换策划表中的修改行，得到修复文件；第二替换单元，用于在修改行所在文件为程序代码的情况下，通过修改行确定修改行所在的类和接口，并基于修改内容替换修改行所在的接口，得到修复文件。

作为一种可选的实施例，第二替换单元包括：寻找子单元，用于从修改行的位置向上寻找，匹配类和接口的编译文法，并根据编译文法确定修改行所在的类和接口；或确定单元，用于基于修改行向上遍历抽象语法树，确定修改行所在的类和接口。

作为一种可选的实施例，服务器用于提供测试链接，其中，测试对象从测试链接处下载修复补丁进行补丁验证，在补丁验证通过的情况下开放下载链接的访问权限，待修复游戏的客户端从开放访问权限的下载链接中下载修复补丁。

作为一种可选的实施例，上述装置还包括：发送模块，用于在将修复补丁上传服务器之后，向处于游戏中的客户端发出修复命令，处于游戏中的客户端在接收到修复命令后通过下载链接下载修复补丁进行修复；其中，未处于游戏中的客户端在进入待修复游戏的同时主动通过下载链接下载修复补丁进行修复。

作为一种可选的实施例，上传模块包括：拆分子模块用于将修复补丁拆分为多个文件块，并分别对每个文件块进行加密后上传至服务器；解密子模块，用于其中，客户端下载加密后的文件块后，分别对每个加密后的文件块进行解密，并按照解密后的文件块对待修复游戏进行修复。

本发明实施例提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行上述的游戏的漏洞修复方法。

本发明实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述的游戏的漏洞修复方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

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

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。