CN109908585A - 一种文件处理方法及***、计算设备及存储介质 - Google Patents

Abstract

本申请提供一种文件处理方法及***、计算设备及存储介质，其中，所述方法包括：从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件；根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件；根据获取的必要资源文件包和附加资源文件分包，生成文件包队列；根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验，将校验失败的附加资源文件进行标记损坏；运行所述文件包队列，在待加载的第一附加资源文件为被标记损坏的情况下，向服务器发送获取请求，根据所述索引文件重新获取所述第一附加资源文件。

Description

一种文件处理方法及***、计算设备及存储介质

技术领域

本申请涉及互联网技术领域，特别涉及一种文件处理方法及***、计算设备及存储介质。

背景技术

在网络游戏的运营过程中，游戏数据的修复和更新是无法回避的两个问题，现有的修复过程包括客户端提示用户下载需要修复部分的文件包，根据操作提示进行安装，并覆盖现有版本，游戏数据的更新则无例外地涉及客户端更新包的下载以及对客户端原有游戏文件中相关部分进行替换，然而一旦涉及到游戏开发者对整个游戏的修复和更新，问题则会复杂化，有时候开发者仅仅修改了一行代码，也需要对整个游戏文件进行编译打包，以及进行发布宣传和提示操作，开发者侧的修复成本高，并且在客户端侧，则需要用户等待升级包的下载和安装，更新安装成功前用户无法进行游戏。

随着游戏体量的增大，游戏的更新量和修复的复杂程度随之上升，于是用户需要等待的时间变长，随之而来的失败率也会上升，进而导致用户游戏体验变差。因此对于需要较频繁更新或者大体量的游戏，对于更新和修复需要给予一定重视。

发明内容

有鉴于此，本申请实施例提供了文件处理方法及***、计算设备及存储介质，以解决现有技术中存在的技术缺陷。

本申请还提供了一种文件处理方法，包括：

从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件；

根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件；

根据获取的必要资源文件包和附加资源文件分包，生成文件包队列；

根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验，将校验失败的附加资源文件进行标记损坏；

运行所述文件包队列，在待加载的第一附加资源文件为被标记损坏的情况下，向服务器发送获取请求，根据所述索引文件重新获取所述第一附加资源文件。

可选的，在运行所述文件包队列之前，还包括：

将校验失败的必要资源文件通过索引文件从服务器重新获取并覆盖。

可选的，将校验失败的附加资源文件进行标记损坏包括：

获取所述校验失败的附加资源文件在所述索引文件中对应的索引信息；

将所述校验失败的附加资源文件的索引信息中的标识字段标记为未下载。

可选的，根据所述索引文件重新获取所述被标记损坏的附加资源文件之后，还包括：

将重新获取的所述第一附加资源文件添加在所述文件包队列的末尾，并覆盖被标记为损坏的所述第一附加资源文件。

可选的，在生成文件包队列之后，还包括：

从所述服务器获取必要资源文件更新包；

根据用户信息从服务器获取附加资源文件更新包中的至少一个附加资源文件更新分包；

获取索引补丁文件，根据所述索引补丁文件对所述索引文件进行更新。

可选的，在根据所述索引补丁文件对所述索引文件进行更新之后，还包括：

将获取到的所述必要资源文件更新包和获取到的所述至少一个附加资源文件更新分包添加至所述文件包队列的末尾，得到更新后的文件包队列；

运行所述更新后的文件包队列。

可选的，在运行所述更新后的文件包队列之后，还包括：

根据更新的用户信息通过更新后的索引文件从所述服务器获取对应的至少一个与更新的用户信息对应的附加资源文件更新分包；

将所述与更新的用户信息对应的附加资源文件更新分包添加至所述更新后的文件包队列的末尾。

可选的，所述用户信息包括用户的指令、用户的等级信息或用户的角色信息。

可选的，根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验包括：

采用信息摘要算法对所述必要资源文件进行校验；

采用32位循环冗余校验方法或信息摘要算法对所述附加资源文件分包进行校验。

可选的，在待加载的第一附加资源文件为被标记损坏的情况下包括：

接收到用户读取所述被标记损坏的第一附加资源文件的指令或确定用户即将读取所述被标记损坏的第一附加资源文件。

本申请还提供了一种文件处理***，包括：

获取模块，被配置为从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件；

所述获取模块还被配置为根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件；

执行模块，被配置为根据获取的必要资源文件包和附加资源文件分包，生成文件包队列；

校验模块，被配置为根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验，将校验失败的附加资源文件进行标记损坏；

第一修复模块，被配置为运行所述文件包队列，在待加载的第一附加资源文件为被标记损坏的情况下，向服务器发送获取请求，根据所述索引文件重新获取所述第一附加资源文件。

可选的，还包括：

第二修复模块，被配置为将校验失败的必要资源文件通过索引文件从服务器重新获取并覆盖。

可选的，所述校验模块包括：

索引单元，被配置为获取所述校验失败的附加资源文件在所述索引文件中对应的索引信息；

标记单元，被配置为将所述校验失败的附加资源文件的索引信息中的标识字段标记为未下载。

可选的，还包括：

追加模块，被配置为将重新获取的所述第一附加资源文件添加在所述文件包队列的末尾，并覆盖被标记为损坏的所述第一附加资源文件。

可选的，还包括：

第一更新模块，被配置为从所述服务器获取必要资源文件更新包；

所述第一更新模块还被配置为根据用户信息从服务器获取附加资源文件更新包中的至少一个附加资源文件更新分包；

所述第一更新模块还被配置为获取索引补丁文件，根据所述索引补丁文件对所述索引文件进行更新。

可选的，还包括：

第一整理模块，被配置为将获取到的所述必要资源文件更新包和获取到的所述至少一个附加资源文件更新分包添加至所述文件包队列的末尾，得到更新后的文件包队列；

运行模块，被配置为运行所述更新后的文件包队列。

可选的，还包括：

第二更新模块，被配置为根据更新的用户信息通过更新后的索引文件从所述服务器获取对应的至少一个与更新的用户信息对应的附加资源文件更新分包；

第二整理模块，被配置为将所述与更新的用户信息对应的附加资源文件更新分包添加至所述更新后的文件包队列的末尾。

可选的，所述校验模块包括：

第一校验单元，被配置为采用信息摘要算法对所述必要资源文件进行校验；

第二校验单元，被配置为采用32位循环冗余校验方法或信息摘要算法对所述附加资源文件分包进行校验。

可选的，所述第一修复模块包括：

修复触发单元，被配置为接收到用户读取所述被标记损坏的第一附加资源文件的指令或确定用户即将读取所述被标记损坏的第一附加资源文件。

本申请还提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述文件处理方法的步骤。

本申请还提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述文件处理方法的步骤。

本申请提供的一种文件处理方法及***、计算设备及存储介质，通过将文件***内的文件划分为必须下载的必要资源文件包和可以进行选择性下载的附加资源文件包，并将所述附加资源文件包分为为多个附加资源文件分包，任一客户端可以根据用户信息从服务器获取多个附加资源文件分包中一个或几个附加资源文件分包，便于客户端的定制、管理和文件的删除，同时，在对文件***进行修复时，仅对所述必要资源文件进行强制修复，而对于所述附加资源文件进行标记损坏并推迟修复，并在客户端判断用户需要使用该被标记损坏的附加资源文件时再进行修复，从而减少了需要获取的数据量和等待时间，加快了文件修复的速度并降低了文件***崩溃的可能性，并且客户端在进行附加资源文件修复的过程中可以继续保持游戏的运行，提高了用户的体验，适用于未来的大型游戏。

附图说明

图1是本申请实施例的计算设备的框架示意图；

图2是本申请实施例的文件处理方法的流程图；

图3是本申请另一实施例的文件处理方法的流程图；

图4是本申请另一实施例的文件处理方法的流程图；

图5是本申请另一实施例的文件处理方法的流程图；

图6是本申请实施例的文件处理***的结构示意图；

图7是本申请另一实施例的文件处理***的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本申请中，提供了一种文件处理方法，在下面的实施例中逐一进行详细说明。

图1是示出了根据本说明书一实施例的计算设备100的结构框图。该计算设备100的部件包括但不限于存储器110和处理器120。处理器120与存储器110通过总线130相连接，数据库150用于保存数据。

计算设备100还包括接入设备140，接入设备140使得计算设备100能够经由一个或多个网络160通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备140可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备100的上述部件以及图1中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图1所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备100还可以是移动式或静止式的服务器。

其中，处理器120可以执行图2所示方法中的步骤。图2是示出了根据本申请一实施例的文件处理方法的示意性流程图，应用于客户端，包括步骤201至步骤205。

步骤201：从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件。

步骤202：根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件。

本申请实施例中，所述服务器可以是网络游戏的服务器，在所述服务器内存储有游戏资源文件，在游戏资源文件的目录下包括必要资源文件夹和附加资源文件夹，所述必要资源文件夹内包括维持游戏正常运行的必要文件资源，例如逻辑配置数据文件、登录场景资源数据文件、基本角色数据文件、基本UI数据文件和新手村地图资源文件等，所述附加资源文件夹内包括游戏运行中的附加文件资源，例如地图资源、角色资源、NPC资源、音效音乐资源、高清贴图资源等。

游戏开发人员在服务端侧根据配置表对游戏资源文件通过打包工具进行打包，最终得到一个完整的游戏资源包，该游戏资源包中包括必要资源文件包、附加资源文件包和索引文件，其中所述必要资源文件包中集中压缩存储有多个必要资源文件，所述附加资源文件包包括多个附加资源文件分包，每个附加资源文件分包中集中压缩存储有特定的附加资源文件，所述索引文件中记录有存储在游戏资源包中的文件与存储在游戏资源文件中的所有文件的映射关系，使得在上层***向本申请的文件***传递特定文件的路径信息的情况下，本申请文件***能够准确返回数据给上层***。

本申请实施例中，所有客户端均需要在安装时下载所述必要资源文件，用户可以进行手动选择附加资源文件包中对应的至少一个附加资源文件分包进行下载，或者由每个客户端根据玩家的特性，例如等级、职业或门派等，自动下载附加资源文件包中对应的至少一个附加资源文件分包，使得每个客户端之间所下载的资源文件分包的个数和/或种类可以不一样。

步骤203：根据获取的必要资源文件包和附加资源文件分包，生成文件包队列。

本申请实施例中，所述客户端将获取到的必要资源文件包和附加资源文件分包生成一个文件包队列，即客户端初始的游戏文件列表，所述客户端通过加载该文件包队列从而使得用户能够进行游戏。

步骤204：根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验，将校验失败的附加资源文件进行标记损坏。

本申请实施例中，遍历索引文件中的所有条目分别去校验每个条目对应数据的正确性，对于校验失败的第一附加资源文件，客户端暂时不进行修复而是将该校验失败的第一附加资源文件标记损坏，在修复完所有必要资源文件中的数据后，用户即可启动游戏。

可选的，所述客户端可以采用信息摘要算法(MD5)对所述必要资源文件进行校验，例如，从服务器侧拉取对应的MD5校验文件，所述MD5校验文件中包含必要资源文件的预设散列值(MD5校验值)，同时所述客户端对获取的所述必要资源文件执行散列运算得到计算散列值，通过将所述预设散列与计算散列值极性比较从而对所述必要资源文件进行校验，如果得到的如果两个值相同，则说明传输的数据完整无误、没有被篡改过。

可选的，所述客户端可以采用循环冗余校验(CRC)方法对附加资源文件分包进行校验，例如，每个附加资源文件均包含有一个附加的数据头，所述数据头中保存了该附加资源文件的32位CRC校验值，当客户端尝试打开附加资源文件时，所述客户端会快速计算本地文件数据的32位CRC数值，并将其与所述数据头保存的32位CRC校验值进行对比，若附加资源文件的32位CRC数值与所述数据头保存的32位CRC校验值保持一致，则判定附加资源文件无损，若附加资源文件的32位CRC数值与所述数据头保存的32位CRC校验值不一致，则判定该附加资源文件损坏。

当然，采用32位CRC校验值只是本申请用于进行文件损坏自检的优选实施例之一，作为其他优选实施例，还可选用MD5值取代32位CRC校验值来进行比较自检，或者其他方式进行自检。

步骤205：运行所述文件包队列，在待加载的第一附加资源文件为被标记损坏的情况下，向服务器发送获取请求，根据所述索引文件重新获取所述第一附加资源文件。

本申请实施例中，当游戏程序向文件***请求读取被标记损坏的第一附加资源文件的情况下，所述文件***根据所述索引文件从服务器端的游戏资源文件重新获取所述第一附加资源文件，完成实际的修复。其中，游戏程序向文件***请求读取被标记损坏的第一附加资源文件的判断标准可以包括两种：一种是在游戏中，客户端向底层请求读取附加资源文件时，可能会读取到被标记为损坏的第一附加资源文件；另一种是在游戏的资源管理器中下载资源的时候也可能触发被标记损坏的第一附加资源文件。

在本申请的另一个实施例中，在运行所述文件包队列之前，还包括：

将校验失败的必要资源文件通过索引文件从服务器重新获取并覆盖。

本申请实施例中，对于校验失败的必要资源文件，客户端直接从服务器拉取对应的必要资源文件并进行修复。

在本申请的另一个实施例中，如图3所示，将校验失败的附加资源文件进行标记损坏包括步骤301至步骤302。

步骤301：获取所述校验失败的附加资源文件在所述索引文件中对应的索引信息。

本申请实施例中，所述索引文件包括文件的位置信息、文件的远端位置信息、文件大小和标记字段等，所述文件的位置信息即每个必要资源文件在必要资源文件包中的位置信息或每个附加资源文件在附加资源文件包中的位置信息，所述文件的远端位置信息即每个必要资源文件或每个附加资源文件记录在服务器侧中的位置，所述标记字段即改文件是否在本地或是否压缩等。

步骤302：将所述校验失败的附加资源文件的索引信息中的标识字段标记为未下载。

本申请实施例中，文件***将校验失败的附加资源文件标记损坏，而不马上将其修复，在待加载的附加资源文件为被标记损坏的情况下再进行延迟修复，其中，所述在待加载的第一附加资源文件为被标记损坏的情况下包括接收到用户读取所述被标记损坏的第一附加资源文件的指令或确定用户即将读取所述被标记损坏的第一附加资源文件。例如，一个被标记损坏的附加资源文件记录了游戏中某处的地图信息，当用户的游戏角色未进入该处区域时，文件***不修复该附加资源文件，当所述文件***收到用户进入该处地图的指令或确定用户即将进入该处区域时，即开始进行该附加资源文件的修复。

在本申请的另一个实施例中，根据所述索引文件重新获取所述第一附加资源文件之后，还包括：

将重新获取的所述第一附加资源文件添加在所述文件包队列的末尾，并覆盖被标记为损坏的所述第一附加资源文件。

在本申请的实施例中，所述文件***采用追加模式，文件***并不立即删除被标记损坏的资源文件分包而是将其标记损坏，然后将重新获取的所述第一附加资源文件添加在所述文件包队列的末尾，并覆盖被标记为损坏的所述第一附加资源文件，从而区别于现有技术中将新增文件填充到原文件的对应位置处的处理方式，采用追加形式的文件结构减小了客户端内部产生的内存碎片的可能性，同时，整个修复过程仅耗费约几十毫秒，使得客户端能够在游戏的进行过程中同步执行文件修复。

可选的，所述用户信息包括用户的指令、用户的等级信息或用户的角色信息。

本申请通过将文件***内的文件划分为必须下载的必要资源文件包和可以进行选择性下载的附加资源文件包，并将所述附加资源文件包分为为多个附加资源文件分包，任一客户端可以根据用户信息从服务器获取多个附加资源文件分包中一个或几个附加资源文件分包，便于客户端的定制、管理和文件的删除，同时，在对文件***进行修复时，仅对所述必要资源文件进行强制修复，而对于所述附加资源文件进行标记损坏并推迟修复，并在客户端判断用户需要使用该被标记损坏的附加资源文件时再进行修复，从而减少了需要获取的数据量和等待时间，加快了文件修复的速度并降低了文件***崩溃的可能性，并且客户端在进行附加资源文件修复的过程中可以继续保持游戏的运行，提高了用户的体验，适用于未来的大型游戏。

本申请的另一个实施例中，处理器120还可以执行图4所示方法中的步骤。图4是示出了根据本申请一实施例的文件处理方法的示意性流程图，包括步骤401至步骤406。

步骤401：从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件。

步骤402：根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件。

本申请实施例中，所述服务器可以是网络游戏的服务器，在所述服务器内存储有游戏资源文件，在游戏资源文件的目录下包括必要资源文件夹和附加资源文件夹，所述必要资源文件夹内包括维持游戏正常运行的必要文件资源，例如逻辑配置数据文件、登录场景资源数据文件、基本角色数据文件、基本UI数据文件和新手村地图资源文件等，所述附加资源文件夹内包括游戏运行中的附加文件资源，例如地图资源、角色资源、NPC资源、音效音乐资源、高清贴图资源等。

游戏开发人员在服务端侧根据配置表对游戏资源文件通过打包工具进行打包，最终得到一个完整的游戏资源包，该游戏资源包中包括必要资源文件包、附加资源文件包和索引文件，其中所述必要资源文件包中集中压缩存储有多个必要资源文件，所述附加资源文件包包括多个附加资源文件分包，每个附加资源文件分包中集中压缩存储有特定的附加资源文件，所述索引文件中记录有存储在游戏资源包中的文件与存储在游戏资源文件中的所有文件的映射关系，使得在上层***向本申请的文件***传递特定文件的路径信息的情况下，本申请文件***能够准确返回数据给上层***。

本申请实施例中，所有客户端均需要在安装时下载所述必要资源文件，用户可以进行手动选择附加资源文件包中对应的至少一个附加资源文件分包进行下载，或者由每个客户端根据玩家的特性，例如等级、职业或门派等，自动下载附加资源文件包中对应的至少一个附加资源文件分包，使得每个客户端之间所下载的资源文件分包的个数和/或种类可以不一样。

步骤403：根据获取的必要资源文件包和附加资源文件分包，生成文件包队列。

本申请实施例中，所述客户端将获取到的必要资源文件包和附加资源文件分包生成一个文件包队列，即客户端初始的游戏文件列表，所述客户端通过加载该文件包队列从而使得用户能够进行游戏。

步骤404：从所述服务器获取必要资源文件更新包。

步骤405：根据用户信息从服务器获取附加资源文件更新包中的至少一个附加资源文件更新分包。

本申请实施例中，游戏开发人员从服务端侧配置游戏资源更新补丁，所述游戏资源更新补丁包括与所述必要资源文件包对应的必要资源文件更新包和与附加资源文件包对应的附加资源文件更新包，其中附加资源文件更新包包括与所述附加资源文件分包对应的附加资源文件更新分包，所述必要资源文件包为强制更新的文件，所述附加资源文件更新包为非强制更新的文件，故所述附加资源文件更新包不会被直接下载到本地，而是存储在服务器侧。

步骤406：获取索引补丁文件，根据所述索引补丁文件对所述索引文件进行更新。

本申请实施例中，所述游戏资源更新补丁还包括索引补丁文件，在每次更新的最后通过所述索引补丁文件对所述索引文件进行更新，使得所述必要资源文件夹和附加资源文件夹中文件的变化情况能够更新到所述索引文件中。

可选的，所述用户信息包括用户的指令、用户的等级信息或用户的角色信息。

本申请的另一个实施例中，在根据所述索引补丁文件对所述索引文件进行更新之后，还包括步骤501至步骤504。

步骤501：将获取到的所述必要资源文件更新包和获取到的所述至少一个附加资源文件更新分包添加至所述文件包队列的末尾，得到更新后的文件包队列。

步骤502：运行所述更新后的文件包队列。

步骤503：根据更新的用户信息通过更新后的索引文件从所述服务器获取对应的至少一个与更新的用户信息对应的附加资源文件更新分包。

本申请实施例中，用户可以选择附加资源文件包中自己的更新数据量，极端情况下可以在必要资源文件包更新结束后直接进入客户端，由游戏的IO***决定加载更新特定的附加资源文件更新分包，例如，某个附加资源文件更新分包记录了游戏中某处的地图信息，当玩家未进入该处区域时，不更新该附加资源文件分包，在当游戏程序检测到玩家进入该处地图的指令或通过计算判断玩家极有可能进入该处区域的情况下，即开始进行更新该附加资源文件分包。

步骤504：将所述与更新的用户信息对应的附加资源文件更新分包添加至所述更新后的文件包队列的末尾。

本申请通过更新索引文件，对于游戏资源文件只强制更新必要资源文件包，附加资源文件包可以不强制更新，并且附加资源文件更新包以分包的结构发布，同时每个版本的更新都会在服务器上存放完整的游戏资源更新补丁，使得客户端产生了跨版本更新的可能，从而减少了客户端的更新数据量和资源文件的冗余。

本申请的文件处理方法，旨在化整为零，减少因更新或修复而打断游戏运行的时间，在进行文件修复与更新时，***自动根据用户的需要进行选择性的修复和更新，而不是和现有技术那样进行全部修复或更新，从而进一步提高了修复以或更新的针对性以及效率。

与上述方法实施例相对应，本说明书还提供了文件处理***的实施例，图6和7示出了本说明书一实施例的文件处理***的模块图。如图6所示，该文件处理***包括：

获取模块601，被配置为从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件。

所述获取模块601还被配置为根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件。

执行模块602，被配置为根据获取的必要资源文件包和附加资源文件分包，生成文件包队列。

校验模块603，被配置为根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验，将校验失败的附加资源文件进行标记损坏。

第一修复模块604，被配置为运行所述文件包队列，在待加载的第一附加资源文件为被标记损坏的情况下，向服务器发送获取请求，根据所述索引文件重新获取所述第一附加资源文件。

在本申请的实施例中，还包括：

第二修复模块605，被配置为将校验失败的必要资源文件通过索引文件从服务器重新获取并覆盖。

在本申请的实施例中，所述校验模块603包括：

索引单元，被配置为获取所述校验失败的附加资源文件在所述索引文件中对应的索引信息。

标记单元，被配置为将所述校验失败的附加资源文件的索引信息中的标识字段标记为未下载。

在本申请的实施例中，还包括：

追加模块606，被配置为将重新获取的所述第一附加资源文件添加在所述文件包队列的末尾，并覆盖被标记为损坏的所述第一附加资源文件。

在本申请的另一个实施例中，如图7所示，本申请的文件***还包括：

第一更新模块701，被配置为从所述服务器获取必要资源文件更新包。

所述第一更新模块701还被配置为根据用户信息从服务器获取附加资源文件更新包中的至少一个附加资源文件更新分包。

所述第一更新模块701还被配置为获取索引补丁文件，根据所述索引补丁文件对所述索引文件进行更新。

在本申请的实施例中，还包括：

第一整理模块702，被配置为将获取到的所述必要资源文件更新包和获取到的所述至少一个附加资源文件更新分包添加至所述文件包队列的末尾，得到更新后的文件包队列。

运行模块705，被配置为运行所述更新后的文件包队列。

在本申请的实施例中，还包括：

第二更新模块703，被配置为根据更新的用户信息通过更新后的索引文件从所述服务器获取对应的至少一个与更新的用户信息对应的附加资源文件更新分包。

第二整理模块704，被配置为将所述与更新的用户信息对应的附加资源文件更新分包添加至所述更新后的文件包队列的末尾。

可选的，所述用户信息包括用户的指令、用户的等级信息或用户的角色信息。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述文件处理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的文件处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述文件处理方法的技术方案的描述。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

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

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (22)

1.一种文件处理方法，其特征在于，应用于客户端，包括：

从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件；

根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件；

根据获取的必要资源文件包和附加资源文件分包，生成文件包队列；

根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验，将校验失败的附加资源文件进行标记损坏；

运行所述文件包队列，在待加载的第一附加资源文件为被标记损坏的情况下，向服务器发送获取请求，根据所述索引文件重新获取所述第一附加资源文件。

2.根据权利要求1所述的方法，其特征在于，在运行所述文件包队列之前，还包括：

将校验失败的必要资源文件通过索引文件从服务器重新获取并覆盖。

3.根据权利要求1所述的方法，其特征在于，将校验失败的附加资源文件进行标记损坏包括：

获取所述校验失败的附加资源文件在所述索引文件中对应的索引信息；

将所述校验失败的附加资源文件的索引信息中的标识字段标记为未下载。

4.根据权利要求1所述的方法，其特征在于，根据所述索引文件重新获取所述第一附加资源文件之后，还包括：

将重新获取的所述第一附加资源文件添加在所述文件包队列的末尾，并覆盖被标记为损坏的所述第一附加资源文件。

5.根据权利要求1所述的方法，其特征在于，在生成文件包队列之后，还包括：

从所述服务器获取必要资源文件更新包；

根据用户信息从服务器获取附加资源文件更新包中的至少一个附加资源文件更新分包；

获取索引补丁文件，根据所述索引补丁文件对所述索引文件进行更新。

6.根据权利要求5所述的方法，其特征在于，在根据所述索引补丁文件对所述索引文件进行更新之后，还包括：

将获取到的所述必要资源文件更新包和获取到的所述至少一个附加资源文件更新分包添加至所述文件包队列的末尾，得到更新后的文件包队列；

运行所述更新后的文件包队列。

7.根据权利要求6所述的方法，其特征在于，在运行所述更新后的文件包队列之后，还包括：

根据更新的用户信息通过更新后的索引文件从所述服务器获取对应的至少一个与更新的用户信息对应的附加资源文件更新分包；

将所述与更新的用户信息对应的附加资源文件更新分包添加至所述更新后的文件包队列的末尾。

8.根据权利要求1或者5-7任意一项所述的方法，其特征在于，所述用户信息包括用户的指令、用户的等级信息或用户的角色信息。

9.根据权利要求1所述的方法，其特征在于，根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验包括：

采用信息摘要算法对所述必要资源文件进行校验；

采用32位循环冗余校验方法或信息摘要算法对所述附加资源文件分包进行校验。

10.根据权利要求1所述的方法，其特征在于，在待加载的第一附加资源文件为被标记损坏的情况下包括：

接收到用户读取所述被标记损坏的第一附加资源文件的指令或确定用户即将读取所述被标记损坏的第一附加资源文件。

11.一种文件处理***，其特征在于，包括：

获取模块，被配置为从服务器端获取必要资源文件包和索引文件，所述必要资源文件包中包括多个必要资源文件；

所述获取模块还被配置为根据用户信息从服务器获取附加资源文件包中对应的至少一个附加资源文件分包，每个附加资源文件分包中包括多个对应的附加资源文件；

执行模块，被配置为根据获取的必要资源文件包和附加资源文件分包，生成文件包队列；

校验模块，被配置为根据所述索引文件对所述文件包队列中的必要资源文件和附加资源文件进行校验，将校验失败的附加资源文件进行标记损坏；

第一修复模块，被配置为运行所述文件包队列，在待加载的第一附加资源文件为被标记损坏的情况下，向服务器发送获取请求，根据所述索引文件重新获取所述第一附加资源文件。

12.根据权利要求11所述的***，其特征在于，还包括：

第二修复模块，被配置为将校验失败的必要资源文件通过索引文件从服务器重新获取并覆盖。

13.根据权利要求11所述的***，其特征在于，所述校验模块包括：

索引单元，被配置为获取所述校验失败的附加资源文件在所述索引文件中对应的索引信息；

标记单元，被配置为将所述校验失败的附加资源文件的索引信息中的标识字段标记为未下载。

14.根据权利要求11所述的***，其特征在于，还包括：

追加模块，被配置为将重新获取的所述第一附加资源文件添加在所述文件包队列的末尾，并覆盖被标记为损坏的所述第一附加资源文件。

15.根据权利要求11所述的***，其特征在于，还包括：

第一更新模块，被配置为从所述服务器获取必要资源文件更新包；

所述第一更新模块还被配置为根据用户信息从服务器获取附加资源文件更新包中的至少一个附加资源文件更新分包；

所述第一更新模块还被配置为获取索引补丁文件，根据所述索引补丁文件对所述索引文件进行更新。

16.根据权利要求15所述的***，其特征在于，还包括：

第一整理模块，被配置为将获取到的所述必要资源文件更新包和获取到的所述至少一个附加资源文件更新分包添加至所述文件包队列的末尾，得到更新后的文件包队列；

运行模块，被配置为运行所述更新后的文件包队列。

17.根据权利要求16所述的***，其特征在于，还包括：

第二更新模块，被配置为根据更新的用户信息通过更新后的索引文件从所述服务器获取对应的至少一个与更新的用户信息对应的附加资源文件更新分包；

第二整理模块，被配置为将所述与更新的用户信息对应的附加资源文件更新分包添加至所述更新后的文件包队列的末尾。

18.根据权利要求11或者15-17任意一项所述的文件***，其特征在于，所述用户信息包括用户的指令、用户的等级信息或用户的角色信息。

19.根据权利要求11所述的***，其特征在于，所述校验模块包括：

第一校验单元，被配置为采用信息摘要算法对所述必要资源文件进行校验；

第二校验单元，被配置为采用32位循环冗余校验方法或信息摘要算法对所述附加资源文件分包进行校验。

20.根据权利要求11所述的***，其特征在于，所述第一修复模块包括：

修复触发单元，被配置为接收到用户读取所述被标记损坏的第一附加资源文件的指令或确定用户即将读取所述被标记损坏的第一附加资源文件。

21.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述指令时实现权利要求1-10任意一项所述方法的步骤。

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