CN111427853A - 一种数据加载方法和相关装置 - Google Patents

Abstract

本申请实施例公开了一种数据加载方法和相关装置，在该方法中，软件中需要加载的数据间具有对应的数据关联关系，该数据关联关系可以体现软件中数据间被读取、执行时的关联。基于此，在获取到标识有软件中目标数据的状态触发请求时，可以根据软件的数据关联关系，并通过单独创建的读写进程，确定与目标数据关联的关联数据。其中，关联数据为加载目标数据后待加载的数据。通过读写进程将关联数据预加载到文件缓存中。该方法通过预测出在加载目标数据后待加载的关联数据，并预加载至文件缓存中，方便后续软件进程在需要读取关联数据时可以直接读取，无需等待关联数据的加载过程，提高了软件数据读取速度，从而解决了读取造成的卡顿问题。

Description

一种数据加载方法和相关装置

技术领域

本申请涉及数据处理领域，特别是涉及一种数据加载方法和相关装置。

背景技术

随着游戏的发展和用户对体验需求的不断提高，游戏的容量也不断提升，单个游戏已经从几k已经发展到了数十G的容量。随着容量变大，对游戏运行流畅度带来了挑战，其中包括游戏加载速度，运行时是否卡顿等因素，游戏运行的不流畅会严重影响用户的体验。

游戏中数据的读写((Input/Output，IO)性能是直接影响游戏运行流畅度的原因之一。常见商业引擎(Unity，Unreal等)使用异步加载来实现数据读写操作。

然而这类相关技术中，仅仅是采用串行的方式进行数据读写，虽然一定程度上加快了数据读写速度，但是针对一些数据需求量大的场景，在用户可忍受时间内一般难以完成读取，导致卡顿现象时有出现。

发明内容

为了解决上述技术问题，本申请提供了一种数据加载方法和相关装置，提高了软件数据读取速度，从而解决了读取造成的卡顿问题。

本申请实施例公开了如下技术方案：

一方面，本申请实施例提供了一种数据加载方法，所述方法包括：

获取状态触发请求，所述状态触发请求用于标识软件中的目标数据；

根据所述软件的数据关联关系，通过读写进程确定与所述目标数据关联的关联数据；所述关联数据为加载所述目标数据后待加载的数据；

通过所述读写进程将所述关联数据预加载到文件缓存中。

另一方面，本申请实施例提供了一种数据加载装置，所述装置包括获取单元、确定单元和预加载单元：

所述获取单元，用于获取状态触发请求，所述状态触发请求用于标识软件中的目标数据；

所述确定单元，用于根据所述软件的数据关联关系，通过读写进程确定与所述目标数据关联的关联数据；所述关联数据为加载所述目标数据后待加载的数据；

所述预加载单元，用于通过所述读写进程将所述关联数据预加载到文件缓存中。

另一方面，本申请实施例提供了一种数据加载设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行上述数据加载方法。

另一方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行上述数据加载方法。

由上述技术方案可以看出，软件中需要加载的数据间具有对应的数据关联关系，该数据关联关系可以体现软件中数据间被读取、执行时的关联。基于此，在获取到标识有软件中目标数据的状态触发请求时，可以根据软件的数据关联关系，并通过单独创建的读写进程，确定与目标数据关联的关联数据。其中，所确定的关联数据为加载目标数据后待加载的数据。通过读写进程将所述关联数据预加载到文件缓存中。该方法中，通过预测出在加载目标数据后待加载的关联数据，并预加载至文件缓存中，方便后续软件进程在需要读取关联数据时可以直接读取，无需等待关联数据的加载过程，提高了软件数据读取速度，从而解决了读取造成的卡顿问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1a为本申请实施例提供的一种数据加载方法的应用场景示意图；

图1b为本申请实施例提供的一种游戏软件展示界面示意图；

图2为本申请实施例提供的一种数据加载方法流程图；

图3为本申请实施例提供的一种文件管理器架构图；

图4a为本申请实施例提供的一种游戏主页面的示意图；

图4b为本申请实施例提供的另一种游戏主页面的示意图；

图5为本申请实施例提供的一种数据读写流程图；

图6a为本申请实施例提供的一种数据加载装置结构图；

图6b为本申请实施例提供的一种数据加载装置结构图；

图7为本申请实施例提供的一种数据处理设备结构图；

图8为本申请实施例提供的一种服务器的结构图。

具体实施方式

下面结合附图，对本申请的实施例进行描述。

目前，软件中常见的商业引擎(Unity，Unreal等)通常使用异步加载来实现数据读写操作。

在异步加载数据的方案中，当软件上层逻辑需要加载一个数据时，会向底层异步加载模块的接口发送数据加载请求。异步加载模块在接收到该请求后，会向读写进程发送读取请求(对应读写指令)，并记录下正在等待读写请求的信息。其中，异步加载模块可以通过单独的线程并行执行。读写进程在收到读取请求后，读取所对应的数据，并将数据加载至内存中。如此，异步加载模块的进程在检查读写请求结果时，若确定数据已经在内存中写好，可以读取该数据，并把该数据从内存中删除。

在读取数据后，异步加载模块还可以进行数据解析等工作，以实现数据对应的功能，如根据数据创建对应的实体对象等。在经过数据解析后如果确定该数据还引用其它相关数据，例如，渲染一个人物(实体对象)需要使用骨骼数据以及啮合(Mesh)材质贴图等数据，则会继续给读写进程发送针对该相关数据的读取请求，直到完成对该数据所有的相关数据的加载。

可见，该种数据加载方式需要等待读写进程完成数据加载后才能读取。而且，该数据加载方式为串行的数据读写方式，对于需要读取的数据是否具有其它相关数据，是需要在加载完该数据并进行解析后才能确定的，且在确定有相关数据后，需要重复上述加载、读取数据的过程以获取相关数据并继续进行解析，由此导致了加载性能不是很高，加载完数据及其相关数据需要等待很长时间。该方式针对一些数据需求量大的场景，在用户可忍受时间内一般难以完成读取，导致卡顿现象时有出现。

例如，针对大型多人在线角色扮演类游戏(Massive Multiplayer Online Role-Playing Game，MMORPG)软件，这类游戏软件的内容非常丰富，软件中各种大大小小的文件在不压缩的情况下可达数十G。而且零散文件非常多，尤其是小文件的总数可达到百万量级。另外，这类游戏项目的后续需求也很多，不仅要实现高性能流畅的用户体验，提高游戏中每个环节的速度，还需尝试制作“微客户端”即很小的安装包，等等。相关技术中的数据读写方式无法满足这类游戏对数据读写性能的要求。

为此，本申请实施例提供了一种数据加载方法，通过预测出在加载目标数据后待加载的关联数据，并对关联数据进行预加载，方便后续软件进程在需要读取关联数据时可以直接读取，无需等待关联数据的加载过程，提高了软件数据读取速度，解决了读取造成的卡顿问题。

首先，对本申请实施例的执行主体进行介绍。本申请提供的数据加载方法可以通过数据处理设备执行。该数据处理设备可以是终端设备，其中，该终端设备中可以部署有软件，终端设备通过执行本申请实施例提供的数据加载方法，以提高软件读取数据的速度。该终端设备例如可以是智能手机、计算机、个人数字助理(Personal Digital Assistant，PDA)、平板电脑、销售终端(Point of Sales，POS)、车载电脑等设备。

该数据加载方法可以应用于区块链中。其中，区块链中可以存储有本申请中软件需要加载的数据，以提高数据安全性。且该数据处理设备可以处于区块链系统中，当数据处理设备需要加载数据时，可以从区块链存储的数据进行加载。

其中，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服-务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

接下来以终端设备作为执行主体，并结合实际应用场景对本申请实施例提供的数据加载方法进行介绍。

参见图1a，该图示出了本申请实施例提供的一种数据加载方法的应用场景示意图。如图1a所示，该应用场景中包括部署软件的终端设备101，终端设备101通过执行本申请实施例提供的数据加载方法，来提高软件的数据读取速度。

需要说明，本申请实施例不限定上述提及的软件的体量，该软件可以是大体量软件或小体量软件。而无论是哪种体量的软件，均可以通过本申请实施例提供的数据加载方法，提高软件的数据读取速度。

还需说明，本申请实施例不限定该软件的种类，该软件可以是部署于计算机中的程序，也可以是部署于智能手机、PDA、平板电脑、POS、车载电脑中的应用(Application，APP)、小程序(Mini Program)等。

另外，该软件可以是任意类型的软件，如办公类软件、游戏类软件等，为了方便理解本方案，下面以游戏软件为例进行说明。

在本申请实施例中，游戏软件中可以具有对应的数据关联关系，数据关联关系可以体现游戏软件中各个数据间被读取、执行时的关联。其中，本申请实施例不限定软件中数据间相关联的涵盖范围，游戏软件中的用于实现同一功能的不同数据间可以相关联，软件中相邻读取、执行的数据间也可以相关联，等等。

例如，如图1a所示，游戏软件具有对应的数据关联关系。其中，用于渲染游戏登陆界面的游戏登陆数据包括用户账户数据、贴图数据1以及背景纹理数据1等，这些数据可以同时被读取以渲染游戏登陆界面，即这些数据之间相关联。另外，在读取游戏登陆数据渲染出游戏登陆界面后，需要读取用于渲染游戏主界面的游戏主界面数据，则，游戏登陆数据也与该用于渲染游戏主界面的游戏主页面数据相关联，等等，不再赘述。

另外，在本申请实施例中，为了提高数据读写速度，终端设备101创建了独立的读写进程，以专用于对软件的数据读写。

接下来，对本申请实施例提供的数据加载方法进行介绍。

在本申请实施例中，在游戏软件的相应功能被触发时，可以生成对应的状态触发请求。其中，该状态触发请求可以体现游戏软件被触发的功能，且该状态触发请求可以标识有游戏软件正在处理(如已完成读取或者需要读取)的数据，记为目标数据。

举例来说，参见图1b，该图示出了本申请实施例提供的一种游戏软件展示界面示意图，如图1b所示，假设终端设备101被触发开启游戏软件，在游戏软件渲染出游戏登陆界面。其中，该游戏登陆界面展示了用户的用户名“abc”和密码“····”。同时，终端设备101生成了对应的状态触发请求。如图1a所示，该状态触发请求标识了游戏登陆数据即目标数据，包括用户账户数据、贴图数据1以及背景纹理数据1等。

终端设备101可以获取该状态触发请求，并根据游戏软件的数据关联关系，通过读写进程来确定与目标数据关联的关联数据。其中，该关联数据可以是在加载目标数据后待加载的数据。

例如，如图1a所示，根据游戏软件的数据关联关系，通过读写进程130可以确定与该目标数据关联的关联数据(即在加载目标数据后待加载的数据)为游戏主页面数据，包括角色实体数据、贴图数据2以及背景纹理数据2等。

从而，终端设备101通过读写进程将关联数据预加载到文件缓存中。如图1a所示，终端设备101通过读写进程将该游戏主页面数据预加载至文件缓存中，以供游戏进程的读取。

如此，参见图1b，当用户在游戏登陆界面中点击了“进入游戏”按键时，基于游戏主页面数据已经预加载至文件缓存中，由此游戏进程可以无需等待游戏主页面数据的加载，可以直接进行读取，并根据游戏主页面数据渲染游戏主界面。

另外，基于数据关联关系能够体现游戏软件中各个数据间在读取、执行时的关联，由此预加载的游戏主页面数据是可以实现渲染游戏主界面的完整数据，即同时预加载了相关联的角色实体数据、贴图数据2以及背景纹理数据2等，避免了在每读取一个数据并进行解析后才确定与其相关的数据，以及进行重复加载和读取的过程。

该方法中，通过预测出在加载目标数据后待加载的关联数据，并预加载至文件缓存中，方便后续软件进程在需要读取关联数据时可以直接读取，而无需等待关联数据的加载过程。另外，由于关联数据是基于软件的数据关联关系所确定的，因此该关联数据中包括了实现相应功能的完整数据，避免了在读取到数据后通过解析确定相关数据，以及进行相关数据重复加载、读取的过程，提高了软件数据读取速度，解决了读取造成的卡顿问题。

接下来，将以终端设备为执行主体，对本申请实施例提供的数据加载方法进行介绍。参见图2，该图示出了本申请实施例提供的一种数据加载方法流程图，所述方法可以包括：

S201：获取状态触发请求。

在本申请实施例中，可以通过独立创建一个读写进程实现该数据加载方法，该读写进程也可以被称为文件管理器。

其中，该文件管理器可以在内部对文件、数据以及线程等进行特别管理。该文件管理器可以使用多线程来读取磁盘数据、进行内存管理、与应用层的指令进行通信，在线程间通过互斥锁以确保同步操作正常，且对指令操作等进行优先级管理。该文件管理器还可以创建各种带命名的管道，以用于与软件进程进行通信，包括文件读写操作、查询操作以及其它一些复杂功能的操作。文件管理器的功能可以通过自定义的应用程序接口(ApplicationProgramming Interface，API)进行封装，以使软件能方便的使用文件管理器的各种功能。

在应用文件管理器为软件进行数据读写之前，可以将软件与文件管理器进行整合，并额外修改终端设备中一些原有的引擎功能，从而通过该文件管理器提高数据读写性能。其中，整合方式可以包括，将引擎底层的文件读写接口替换成文件管理器提供的API，以使上层逻辑直接使用文件管理器提供的功能，替代游戏或编辑器等原有的一些功能。

在本申请实施例中，在应用文件管理器进行数据读写的过程中，当软件中的一些功能被触发时，可以生成对应的状态触发请求，该状态触发请求可以体现软件被触发的功能，且该状态触发请求可以标识有软件正在进行处理的数据，记为目标数据。

需要说明，本申请实施例不限定软件对该目标数据的处理结果，在具体实现中，该目标数据可以是当前已完成读取且被执行以实现相应功能的数据，也可以是当前需要读取还未实现相应功能的数据。

例如，在渲染游戏登陆界面的过程中，目标数据可以是贴图数据。此时如果游戏登陆界面已经被渲染完，即该贴图数据已经被读取且以在游戏登陆界面中完成渲染。如果游戏登陆界面还未被渲染完，该贴图数据可以正在被读取以进行渲染。

S202：根据所述软件的数据关联关系，通过读写进程确定与所述目标数据关联的关联数据。

其中，上述提及的软件的数据关联关系可以体现游戏软件中各个数据间被读取、执行时的关联。

如此，终端设备在获取到状态触发请求后，可以根据软件的数据关联关系，通过文件管理器确定与该目标数据关联的关联数据。所确定的关联数据可以是指在加载目标数据后待加载的数据。

可以理解，当软件的数据关联关系越准确时，以此确定的与目标数据关联的关联数据则可以越全面、准确。由此，为了准确确定软件的数据关联关系，在一种可能的实现方式中，数据关联关系的确定方式包括：

S301：针对所述软件对应的多个内容场景，对所述内容场景中所对应数据进行遍历加载，以确定所述内容场景中数据间的关联关系。

可以理解，软件中可以包括多个内容场景，所述内容场景可以是向用户提供的一种内容类型的场景。软件通过为用户提供不同的内容场景，以为用户提供不同的功能体验。例如，游戏类软件中包括各种各样的内容场景，如关卡中为用户提供的沙漠内容场景，村落内容场景等等。其中，每个内容场景可以通过执行该内容场景对应的数据得到。

在本申请实施例中，可以通过软件进程对软件对应的多个内容场景所对应的数据进行遍历加载，以确定出软件的内容场景中各个数据间的关联关系。

S302：根据针对所述多个内容场景确定的关联关系，确定所述数据关联关系。

需要说明，本申请实施例不限定软件的数据关联关系的确定时机，为使在每次数据读写时可以直接使用，可以预先确定软件的数据关联关系并存储至文件管理器中。

在具体实现中，可以在软件版本更新时、软件补丁包制作时确定软件的数据关联关系，以准确确定出最新版本软件的数据关联关系。另外，也可以在每日测试时确定软件的数据关联关系，且在测试过程中执行该数据加载方法，以实现测试该软件的预加载功能。

下面以游戏类软件为例，对该数据关联关系的确定方式进行介绍。

在该示例中，可以自动遍历游戏中每张地图上的每块区域，对区域内的数据进行加载，且在加载过程中记录所加载的数据、文件等，将相关联的数据以文件列表的形式即表格形式进行存储，生成该游戏的数据关联关系。

其中，对于游戏中的三维树木(SpeedTree)植被信息，也会额外的提取和保存，以实现准确确定与植被信息具有关联关系的数据。对于游戏启动时用到的文件，也会进行记录，以实现预加载。对于独立的资源文件(例如模型数据、材质数据)，可以通过分析可扩展标记语言(Extensible Markup Language，XML)文件的内部内容，以找到相关联的文件名，确定它们之间的关联关系。

可见，该方法通过遍历加载的方式来确定软件的数据关联关系，保证了数据关联关系全面覆盖了软件中的数据，且提高了数据关联关系的准确性。

S203：通过所述读写进程将所述关联数据预加载到文件缓存中。

在本申请实施例中，在确定出关联数据后，终端设备可以通过文件管理器将关联数据预加载到文件缓存中，以供软件进程读取。其中，该文件缓存可以是指对文件、数据等进行交换的缓冲区。

在具体实现中，该文件缓存可以部署于文件管理器中。例如，参见图3，该图示出了本申请实施例提供的一种文件管理器架构图，如图3所示，文件缓存可以配置于文件管理器中，该文件缓存由一块内存(Memory)得到，以存储这些预缓存的关联数据。

该文件缓存的大小可以根据终端设备的内存配置和实时负载等情况动态调节，例如，对于64位系统32GB内存的计算机，可以为该文件管理器的文件缓存设置较大的体量，而对于32位系统的计算机，为该文件管理器的文件缓存设置相对较小(基本为0)的体量，且需要减少触发文件管理器的相关功能如预加载功能等。

需要说明，本申请实施例不限定软件需要加载的数据(如目标数据、关联数据等)来源，该数据可以来自服务器，也可以来自终端设备的本地。

在本申请实施例中，该文件管理器中可以存储软件需要读取的数据，在一种可能的实现方式中，该文件管理器可以配置有多个子文件系统，不同的子文件系统对应不同的数据格式。其中，该子文件系统可以是存储相应数据格式的数据存储结构。数据格式(DataFormat)可以是描述数据保存在文件或记录中的规则。

在具体实现中，可以以插件的形式构建该子文件系统，并开发对应的图形化界面(Graphical User Interface，GUI)的配置工具，以将子文件系统配置在文件管理器中。该种以插件形式接入文件管理器的方式，便于推广到更多的软件引擎如游戏引擎中，增强了数据格式定制化能力。

如图3所示，该文件管理器中配置了多个子文件系统，包括超任(Super Famicom，SFC)子文件系统，用于存储SFC文件；还包括虚拟文件系统(Virtual File System，VFS)子文件系统，用于存储VFS文件；以及包括智能及时分发系统(Intelligent InstantPublishing System，IIPS)子文件系统，用于存储IIPS文件。

在具体实现中，可以将一些体量小的具有关联关系的SFC文件打包后存储在SFC子文件系统中，以使该子文件系统中文件的数目适量且可配置。也可以将用户文件存在SFC子文件系统中，其中，在软件补丁包制作时会考虑用户配置，不会覆盖用户文件。另外，可以在VFS子文件系统中存放空的文件树结构。

以及，对于IIPS数据格式的数据如贴图数据，可以通过数据压缩步骤将其转换成低精度的数据后存储在IIPS子文件系统中，并将高精度的贴图数据放于服务器上，以实现用户的边玩边下载补全。

基于文件管理器中配置的子文件系统，该文件管理器可以根据具体需求(如读取、写入、确定文件名路径、是否有指定标记等)对数据进行相应操作。该文件管理器可以支持如下功能：支持普通的Windows系统文件读写；支持SFC数据包压缩文件的读写；支持VFS压缩包数据格式文件读写(在内部集成有VFS API)；支持IIPS边玩边下数据包(在内部集成有IIPS API)；支持内存、缓存文件读取；支持网络下载的热更新文件读写；支持缓存写入形式文件的延迟写入；支持基于API层面指定的对某个子文件系统进行数据操作；以及，支持数据更新操作，例如若文件的原始版本存在于VFS中，支持对该文件的历史文件信息的查询。

另外，可以预设不同数据格式文件的优先读取顺序，从而按照该优先读取顺序读取。

该方法中，文件管理器兼容了不同数据格式的子文件系统，以便基于实际需求，支持对相应数据格式的数据进行操作。

由上述技术方案可以看出，软件中需要加载的数据间具有对应的数据关联关系，该数据关联关系可以体现软件中数据间被读取、执行时的关联。基于此，在获取到标识有软件中目标数据的状态触发请求时，可以根据软件的数据关联关系，并通过单独创建的读写进程，确定与目标数据关联的关联数据。其中，所确定的关联数据为加载目标数据后待加载的数据。通过读写进程将所述关联数据预加载到文件缓存中。该方法中，通过预测出在加载目标数据后待加载的关联数据，并预加载至文件缓存中，方便后续软件进程在需要读取关联数据时可以直接读取，无需等待关联数据的加载过程，提高了软件数据读取速度，从而解决了读取造成的卡顿问题。

需要说明，本申请实施例不限定生成状态触发请求的具体场景，对于触发软件中功能的任意场景，均可以生成状态触发请求，以执行该数据加载方法，将与目标数据关联的关联数据预加载至文件缓存中。例如，当软件后台自动触发软件中的某些功能时，可以生成状态触发请求。

在实际场景中，软件通常通过功能页面与用户进行交互，且根据用户的触发操作调用对应数据以实现相应功能。为此，在一种可能的实现方式中，所述方法还包括：根据软件运行时打开的功能页面，生成所述状态触发请求。其中，该功能页面可以用于为用户提供软件的各种功能，用户通过在功能页面进行相应操作，以触发软件实现对应的功能。

在本申请实施例中，终端设备可以根据软件运行时打开的功能页面，来生成状态触发请求，且根据功能页面确定该状态触发请求中标识的目标数据。

以游戏类软件为例进行说明，可以在打开游戏登陆界面时生成状态触发请求，所确定的目标数据可以是渲染游戏登陆界面的游戏登陆数据，包括用户账户数据、贴图数据1以及背景纹理数据1等。

该方法中，基于软件通过功能页面为用户提供相应功能的特点，软件需要基于用户在功能页面的触发操作调用对应的数据进行响应。由此，通过根据功能页面生成状态触发请求，实现了根据功能页面及时确定关联数据以及预加载关联数据的目的，可以加快响应用户操作的速度。另外，软件运行时打开的功能页面是通过软件正在处理的数据进行渲染，由此依据功能页面确定的目标数据可以更加准确。

基于上述提及的根据功能页面生成状态触发请求的场景，在一种可能的实现方式中，功能页面中可以提供一个或多个功能对象，该功能对象可以是通过对其触发以读取对应数据实现相应功能的对象，例如功能对象为选择关卡的按键等。

在实际场景中，用户通常会根据自身需求，在功能页面中对希望触发的功能对象进行触发操作，以使软件读取并执行对应的数据，从而实现该功能对象所对应的功能。例如，用户可以通过拖动鼠标，使得光标在功能页面移动至希望进行的关卡按键(功能对象)位置进行触发，实现选择该关卡的功能。如此，用户在功能页面中的操作位置与功能对象间的距离可以体现用户的功能触发需求。

基于此，在本申请实施例中，可以根据操作位置来预测用户希望触发的功能，并将实现这些功能的数据优先预加载，以使软件在需要读取这些数据时能够及时读取。

基于此，所述方法还可以包括：

S401：获取对应所述状态触发请求的操作位置信息。

S402：根据所述操作位置信息所标识操作位置与所述功能页面中功能对象间的距离关系，确定所述关联数据的预加载顺序。

在本申请实施例中，当用户在功能页面上操作时，可以获取该功能页面中的操作位置信息。基于状态触发请求根据该功能页面生成，该操作位置信息也对应于该状态触发请求。其中，该操作位置信息可以体现在功能页面中进行操作的位置信息，该操作位置信息可以标识在功能页面中对应的操作位置。

举例来说，当用户在功能页面的位置A进行操作时，所获取的操作位置信息可以是该位置A在功能页面中的坐标(x，y)，该操作位置信息即坐标(x，y)所标识的操作位置为位置A。

在获取到状态触发请求的操作位置信息后，可以确定操作位置信息所标识的操作位置与功能页面中各个功能对象间的距离关系。从而，根据操作位置与功能页面中各功能对象间的距离关系，确定关联数据的预加载顺序。

其中，该关联数据的预加载顺序可以是针对关联数据中对应于各功能对象的数据而言的，也就是说，该预加载顺序可以是关联数据中各功能对象所对应数据的预加载顺序。

在确定预加载顺序的过程中，当操作位置与功能页面中功能对象间的距离越近时，可以体现用户对该功能对象的功能触发需求越高，则关联数据中对应于该功能对象的数据可以越优先进行预加载。当操作位置与功能页面中功能对象间的距离越远时，可以体现用户对该功能对象的功能触发需求越低，则关联数据中对应于该功能对象的数据可以越靠后进行预加载。

则，上述S203中通过读写进程将关联数据预加载到文件缓存中的方法，可以包括：

S403：通过所述读写进程，根据所述预加载顺序将所述关联数据预加载到文件缓存中。

需要说明，本申请实施例不限定操作位置信息的获取方式。为使获取的操作位置信息可以更充分体现用户的功能触发需求，在一种可能的实现方式中，可以按照预设时间间隔来获取操作位置信息。

在该种操作位置信息的获取方式下，上述S401-S403的方法可以包括，在每获取一个操作位置信息时，可以确定该操作位置信息所标识操作位置与功能页面中各个功能对象间的距离，并根据这些距离关系，确定关联数据中当前未被加载的数据的预加载顺序。然后，可以在该预设时间间隔内，通过文件管理器，并根据预加载顺序将这些数据预加载到文件缓存中，直至获取下一个操作位置信息，并执行确定该操作位置信息所标识操作位置与功能页面中各个功能对象间的距离的步骤。

下面以每隔0.5s来获取操作位置信息的场景为例，并基于图1b对应的示例对该S401-S403的方法进行举例说明。

参见图4a，该图示出了本申请实施例提供的一种游戏主页面的示意图，该游戏主页面即为游戏运行时打开的功能页面。该功能页面中包括三个功能对象，这三个功能对象分别用于在触发后进入游戏中对应的关卡，分别为关卡1、关卡2和关卡3。

在该示例中，假设当前关联数据中未被预加载的数据包括：对应关卡1的贴图数据3和背景纹理数据3，对应关卡2的贴图数据4和背景纹理数据4，对应关卡3的贴图数据5和背景纹理数据5。

如图4a所示，针对当前展示的游戏主界面，可以获取对应鼠标光标410的操作位置信息为坐标(x1，y1)，该操作位置信息标识了在游戏主界面中的位置B。然后，确定该位置B与关卡1、关卡2和关卡3对应按键(功能对象)间的距离分别为d1、d2、d3，确定距离关系为d1<d2<d3。则，以此确定所述关联数据的预加载顺序(从左向右依次加载)可以为：贴图数据3、背景纹理数据3、贴图数据4、背景纹理数据4、贴图数据5、背景纹理数据5。由此，在0.5s时间间隔内，可以根据该预加载顺序，将关联数据中当前未被预加载的数据预加载至文件缓存中。

假设在该0.5s时间间隔内，完成了将贴图数据3预加载至文件缓存。然后，终端设备再一次获取该功能页面上的操作位置信息，参见图4b，该图示出了本申请实施例提供的另一种游戏主页面的示意图，如图4b所示，针对当前展示的游戏主界面，可以获取对应于鼠标光标410的操作位置信息为坐标(x2，y2)，该操作位置信息标识了在游戏主界面中的位置C。然后，确定该位置C与关卡1、关卡2和关卡3对应按键(功能对象)间的距离分别为d1’、d2’、d3’，且确定距离关系为d1’<d2’<d3’。则，以此确定关联数据的预加载顺序(从左向右依次加载)可以为：背景纹理数据3、贴图数据4、背景纹理数据4、贴图数据5、背景纹理数据5。由此，可以根据该预加载顺序，将关联数据中当前未被预加载的数据预加载至文件缓存中。

通过重复执行该方法，直至将关联数据完全预加载至文件缓存中。

该种方式中，基于操作位置与功能对象间的距离关系可以体现用户的功能触发需求，预测软件进程对关联数据中各个数据进行读取的可能性，并以此确定关联数据的预加载顺序，由此可以将软件进程更有可能读取的数据优先预加载至文件缓存中。从而，当软件进程需要读取关联数据中的这部分数据时，保证了及时读取。

在实际场景中，软件需要读取一些只读、体量小、零散、以及对改善游戏性能体验非常重要的数据。而对于这些数据如体量小的数据均需执行一次上述流程进行读取，数据的读写效率较低。

为此，在一种可能的实现方式中，可以提供一个共享内存，并将一些数据作为常驻数据集合存储在该共享内存中，以供软件进程的直接读取。其中，该共享内存可以是供软件进程直接读取的内存，该常驻数据集合可以是存储在共享内存中的各类数据。

需要说明，本申请实施例不限定常驻数据集合所包括的数据内容，可以根据实际需求，将需要的数据作为该常驻数据集合中的一部分存储至共享内存中。在实际场景中，对于软件运行过程中需要经常读取的数据，可以将其存储至共享内存中。

在该种情形下，所述方法还包括：

S501：确定共享内存保存的常驻数据集合中是否包括所述关联数据。若是，执行S502，若否，执行S503。

S502：通过所述软件对应的软件进程，从所述共享内存读取所述关联数据。

S503：通过所述软件对应的软件进程调用所述读写进程，从所述文件缓存中读取已经预加载了的所述关联数据。

也就是说，终端设备在需要读取关联数据时，可以首先确定共享内存保存的常驻数据集合中是否包括该关联数据，若包括，则可以直接通过该软件对应的软件进程，从共享内存中读取该关联数据。若不包括，则可以通过软件进程调用读写进程即文件管理器，以从文件缓存中读取该已完成预加载的关联数据。

仍以游戏类软件为例进行说明，基于图3对应的示例，文件管理器可以创建共享内存，并在其中存放常驻数据集合，以提供给游戏进程访问、读取。

其中，文件管理器中的VFS子文件系统中可以存储针对常驻数据集合的文件信息表，每个文件名的哈希值对应一系列信息，该信息包括：文件的实体类型(存储的子文件系统)、文件的实体位置(例如在压缩包中的字节开始位置至字节结束位置)以及文件的尺寸大小信息等。

软件进程可以通过VFS文件初始化来读取得到该常驻数据集合的文件信息表，并进行保存。当需要读取关联数据时，可以根据保存的该常驻数据集合中的文件名称表，实现快速查询文件名和关联数据的过滤等功能。

而且，对于常驻数据集合，可以通过压缩后再存储，以缩小数据存储空间。当软件进程需要读取共享内存中的数据时，可以通过解压缩后再读取。对于压缩方式，基于LZ4算法的高编解码效率，可以选用该算法对体量小的文件进行压缩。

该方法通过将重要数据、小体量数据、经常读取的数据等添加至共享内存中，便于软件进程可以直接进行读取，而无需再调用文件管理器从文件缓存中进行读取，即省去了不必要的线程轮询、切换和文件管理器的调度，由此进一步提高了数据读取效率。

可以理解，基于软件运行时的内容场景是通过该内容场景对应的数据渲染出的。渲染相同的内容场景一般可以读取较多相同的数据，渲染不同的内容场景所需读取的数据通常有较大差异。例如，对于沙漠内容场景，通常需要读取沙漠贴图数据进行该内容场景下的多帧游戏界面的渲染，而对于村落内容场景，则不需要沙漠贴图数据来渲染村落内容场景下的游戏界面。

如此，在软件运行时内容场景发生切换时，若常驻数据集合仍为切换前的内容场景对应的数据，则其中的部分数据将无法应用于切换后的内容场景中。

为此，在一种可能的实现方式中，所述方法还可以包括：

S601：确定所述软件运行中的内容场景是否发生切换。若是，执行S602。

S602：根据切换后的内容场景确定对应的目标数据集合。

其中，针对该内容场景的介绍如前所述，此处不再赘述。

在本申请实施例中，可以确定软件运行中的内容场景是否发生切换。若是，可以根据切换后的内容场景确定对应的目标数据集合。

其中，目标数据集合可以包括切换后的内容场景对应的数据。

需要说明，本申请实施例不限定该目标数据集合中包括的数据内容，可以根据实际需求来确定目标数据集合中所包括的数据。例如，可以将用于生成切换后的内容场景的、经常需要调用的数据加入目标数据集合中，等等。

S603：将目标数据集合作为所述常驻数据集合对所述共享内存进行常驻数据集合替换。

从而，可以将目标数据集合作为新的常驻数据集合，以替换共享内存中原有的常驻数据集合。

该方法中，基于软件运行时内容场景的切换确定对应的目标数据集合，并以此对共享内存中的常驻数据集合进行更新，实现了令共享内存中及时存储针对已切换的内容场景需要读取的数据，提高了共享内存的利用率。

需要说明，本申请实施例不限定文件管理器的启动时机和关闭时机，在一种可能的实现方式中，文件管理器可以早于软件进程的启动而启动。从而实现软件进程在启动后即可读取预加载的数据，可以提高软件的启动速度。

下面以游戏类软件为例进行说明。

在该示例中，当用户启动游戏时，游戏的登陆器进程随之启动，以渲染出游戏登陆界面，此时游戏进程(即软件进程)还未启动。然后，可以先启动文件管理器，并通过前述提及的数据加载方法，通过文件管理器确定游戏主界面数据(即目标数据对应的关联数据)，以及将关联数据预加载至文件缓存中。接着，游戏进程启动，由此可以通过游戏进程直接读取关联数据，以根据关联数据实现游戏主界面的渲染。

另外，当软件进程关闭时，可以关闭该文件管理器。

需要说明，基于文件管理器没有软件逻辑层的信息，由此可以通过预设的触发方式(如手动触发方式或根据预设时间节点自动触发等)来启动，以使用文件管理器提供的功能如数据预加载以及边玩边下等。

另外，多个软件进程均可以通过文件管理器进行文件的读写管理，以提高文件管理器的利用效率，支持在同一个目录下的软件多功能开发。

接下来，将结合实际应用场景对本申请实施例提供的数据加载方法进行介绍。

如图5所示，该图示出了本申请实施例提供的一种数据读写流程图。如图5所示，所述方法可以包括：

S701：客户端状态触发。

其中，客户端可以是部署有终端设备上的软件。

在该示例中，当用户对该客户端进行触发时，该客户端进行响应，实现对应的状态触发，且可以同时生成状态触发请求，该状态触发请求中可以标识有目标数据。

例如，基于用户对客户端的启动触发，客户端可以进行响应以展示出用户登陆界面。且还可以生成对应的状态触发请求，该状态触发请求中标识了用户登陆界面数据。

S702：通过文件管理器查表和预加载。

可以通过文件管理器获取该状态触发请求，并通过上述实施例中提供的数据加载方法进行查表(对应数据关联关系)，以确定出关联数据，并将确定的关联数据预加载至文件缓存中。

例如，文件管理器根据用户登陆界面数据确定出关联数据即游戏主界面数据，并将其加载至文件缓存中。

S703：客户端发起数据请求。

在该示例中，用户可以通过触发客户端所展示功能页面中的功能对象，以发起数据请求，该数据请求可以用于请求获取实现该触发的功能对象的数据。

例如，用户在游戏登陆界面输入用户名和密码后，可以点击“进入游戏”的按键即功能对象，由此可以发起数据请求，该数据请求可以用于获取游戏主界面数据。

S704：是否在内部缓存中查找到。若是，执行S705，若否，执行S706。

可以通过游戏进程在内部缓存中查找是否存在该数据请求对应的需要获取的数据。

S705：客户端进行数据执行。

若在内容缓存中查找到该数据请求对应的需要获取的数据，可以获取该数据并执行，以实现相应功能。

例如，在内部缓存中查找到游戏主界面数据后，可以获取该数据并根据该数据渲染出游戏主界面。

S706：通过文件管理器读取数据。

若未在内容缓存中查找到数据请求对应的需要获取的数据，可以通过文件管理器在文件缓存中读取对应的数据。

S707：是否在文件缓存中查找到。若是，执行S708。若否，执行S709。

S708：通过文件管理器从文件缓存中读取数据。

S709：通过文件管理器读取磁盘物理文件。

若通过文件管理器在文件缓存中查找到数据请求对应的需要获取的数据，可以从文件缓存中读取数据，并执行S705中数据执行的步骤。若未读取到，可以通过文件管理器读取磁盘物理文件，以在磁盘物理文件中读取数据请求对应的需要获取的数据，并执行S705中数据执行的步骤。

可见，对于游戏开发者，可以在游戏上层逻辑中调用简单的类标准C语言的文件管理器API，即可通过调用文件管理器实现上层数据读写需求，且不会产生卡顿现象，非常方便有效。同时也降低了游戏进程的内存消耗，让32位机器运行大型游戏成为了可能。

基于前述实施例提供的数据加载方法，本申请实施例提供了一种数据加载装置，该数据加载装置可以应用于数据处理设备中，如应用于终端设备中。参见图6a，该图示出了本申请实施例提供的一种数据加载装置结构图，所述装置800包括获取单元801、确定单元802和预加载单元803：

所述获取单元801，用于获取状态触发请求，所述状态触发请求用于标识软件中的目标数据；

所述确定单元802，用于根据所述软件的数据关联关系，通过读写进程确定与所述目标数据关联的关联数据；所述关联数据为加载所述目标数据后待加载的数据；

所述预加载单元803，用于通过所述读写进程将所述关联数据预加载到文件缓存中。

在一种可能的实现方式中，参见图6b，该图示出了本申请实施例提供的一种数据加载装置结构图，所述装置800还包括生成单元804：

所述生成单元804，用于根据所述软件运行时打开的功能页面，生成所述状态触发请求，所述目标数据是根据所述功能页面确定的。

在一种可能的实现方式中，所述获取单元801，还具体用于：

获取对应所述状态触发请求的操作位置信息；

所述确定单元802，还具体用于根据所述操作位置信息所标识操作位置与所述功能页面中功能对象间的距离关系，确定所述关联数据的预加载顺序；

所述预加载单元803，具体用于：

通过所述读写进程，根据所述预加载顺序将所述关联数据预加载到文件缓存中。

在一种可能的实现方式中，所述确定单元802，还具体用于：

针对所述软件对应的多个内容场景，对所述内容场景中所对应数据进行遍历加载，以确定所述内容场景中数据间的关联关系；

根据针对所述多个内容场景确定的关联关系，确定所述数据关联关系。

在一种可能的实现方式中，所述确定单元802，还具体用于：

确定共享内存保存的常驻数据集合中是否包括所述关联数据；

若是，通过所述软件对应的软件进程，从所述共享内存读取所述关联数据；

若否，通过所述软件对应的软件进程调用所述读写进程，从所述文件缓存中读取已经预加载了的所述关联数据。

在一种可能的实现方式中，所述确定单元802，还具体用于：

确定所述软件运行中的内容场景是否发生切换；

若是，根据切换后的内容场景确定对应的目标数据集合；

将目标数据集合作为所述常驻数据集合对所述共享内存进行常驻数据集合替换。

在一种可能的实现方式中，所述读写进程早于所述软件进程的启动而启动。

在一种可能的实现方式中，所述读写进程配置有多个子文件系统，不同的子文件系统对应不同的数据格式。

由上述技术方案可以看出，软件中需要加载的数据间具有对应的数据关联关系，该数据关联关系可以体现软件中数据间被读取、执行时的关联。基于此，在获取到标识有软件中目标数据的状态触发请求时，可以根据软件的数据关联关系，并通过单独创建的读写进程，确定与目标数据关联的关联数据。其中，所确定的关联数据为加载目标数据后待加载的数据。通过读写进程将所述关联数据预加载到文件缓存中。该方法中，通过预测出在加载目标数据后待加载的关联数据，并预加载至文件缓存中，方便后续软件进程在需要读取关联数据时可以直接读取，无需等待关联数据的加载过程，提高了软件数据读取速度，从而解决了读取造成的卡顿问题。

本申请实施例还提供了一种数据加载设备，该数据加载设备即为上述提及的数据处理设备，下面结合附图对数据处理设备(数据加载设备)进行介绍。请参见图7所示，本申请实施例提供了一种数据处理设备结构图，该设备1000还可以是终端设备，以终端设备为手机为例：

图7示出的是与本申请实施例提供的手机的部分结构框图。参考图7，手机包括：射频(Radio Frequency，简称RF)电路1010、存储器1020、输入单元1030、显示单元1040、传感器1050、音频电路1060、无线保真(wireless fidelity，简称WiFi)模块1070、处理器1080、以及电源1090等部件。本领域技术人员可以理解，图7中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图7对手机的各个构成部件进行具体的介绍：

RF电路1010可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1080处理；另外，将设计上行的数据发送给基站。通常，RF电路1010包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，简称LNA)、双工器等。此外，RF电路1010还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobile communication，简称GSM)、通用分组无线服务(GeneralPacket Radio Service，简称GPRS)、码分多址(Code Division Multiple Access，简称CDMA)、宽带码分多址(Wideband Code Division Multiple Access，简称WCDMA)、长期演进(Long Term Evolution，简称LTE)、电子邮件、短消息服务(Short Messaging Service，简称SMS)等。

存储器1020可用于存储软件程序以及模块，处理器1080通过运行存储在存储器1020的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1030可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1030可包括触控面板1031以及其他输入设备1032。触控面板1031，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1031上或在触控面板1031附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1080，并能接收处理器1080发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1031。除了触控面板1031，输入单元1030还可以包括其他输入设备1032。具体地，其他输入设备1032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1040可包括显示面板1041，可选的，可以采用液晶显示器(LiquidCrystal Display，简称LCD)、有机发光二极管(Organic Light-Emitting Diode，简称OLED)等形式来配置显示面板1041。进一步的，触控面板1031可覆盖显示面板1041，当触控面板1031检测到在其上或附近的触摸操作后，传送给处理器1080以确定触摸事件的类型，随后处理器1080根据触摸事件的类型在显示面板1041上提供相应的视觉输出。虽然在图7中，触控面板1031与显示面板1041是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1031与显示面板1041集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1050，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1041的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1041和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1060、扬声器1061，传声器1062可提供用户与手机之间的音频接口。音频电路1060可将接收到的音频数据转换后的电信号，传输到扬声器1061，由扬声器1061转换为声音信号输出；另一方面，传声器1062将收集的声音信号转换为电信号，由音频电路1060接收后转换为音频数据，再将音频数据输出处理器1080处理后，经RF电路1010以发送给比如另一手机，或者将音频数据输出至存储器1020以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1070可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图7示出了WiFi模块1070，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1080是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1020内的软件程序和/或模块，以及调用存储在存储器1020内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1080可包括一个或多个处理单元；优选的，处理器1080可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1080中。

手机还包括给各个部件供电的电源1090(比如电池)，优选的，电源可以通过电源管理系统与处理器1080逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本实施例中，该终端设备所包括的处理器1080还具有以下功能：

获取状态触发请求，所述状态触发请求用于标识软件中的目标数据；

根据所述软件的数据关联关系，通过读写进程确定与所述目标数据关联的关联数据；所述关联数据为加载所述目标数据后待加载的数据；

通过所述读写进程将所述关联数据预加载到文件缓存中。

本申请实施例提供的数据处理设备可以是服务器，请参见图8所示，图8为本申请实施例提供的一种服务器的结构图，服务器1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(Central Processing Units，简称CPU)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在服务器1100上执行存储介质1130中的一系列指令操作。

服务器1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作系统1141，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中的步骤也可以由服务器执行，该服务器可以基于该图8所示的服务器结构。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行前述各个实施例所述的方法。

本申请实施例还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例所述的方法。

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

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

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

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

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质可以是下述介质中的至少一种：只读存储器(英文：read-only memory，缩写：ROM)、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

Claims (15)

1.一种数据加载方法，其特征在于，所述方法包括：

获取状态触发请求，所述状态触发请求用于标识软件中的目标数据；

根据所述软件的数据关联关系，通过读写进程确定与所述目标数据关联的关联数据；所述关联数据为加载所述目标数据后待加载的数据；

通过所述读写进程将所述关联数据预加载到文件缓存中。

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

根据所述软件运行时打开的功能页面，生成所述状态触发请求，所述目标数据是根据所述功能页面确定的。

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

获取对应所述状态触发请求的操作位置信息；

根据所述操作位置信息所标识操作位置与所述功能页面中功能对象间的距离关系，确定所述关联数据的预加载顺序；

所述通过所述读写进程将所述关联数据预加载到文件缓存中，包括：

通过所述读写进程，根据所述预加载顺序将所述关联数据预加载到文件缓存中。

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

针对所述软件对应的多个内容场景，对所述内容场景中所对应数据进行遍历加载，以确定所述内容场景中数据间的关联关系；

根据针对所述多个内容场景确定的关联关系，确定所述数据关联关系。

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

确定共享内存保存的常驻数据集合中是否包括所述关联数据；

若是，通过所述软件对应的软件进程，从所述共享内存读取所述关联数据；

若否，通过所述软件对应的软件进程调用所述读写进程，从所述文件缓存中读取已经预加载了的所述关联数据。

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

确定所述软件运行中的内容场景是否发生切换；

若是，根据切换后的内容场景确定对应的目标数据集合；

将目标数据集合作为所述常驻数据集合对所述共享内存进行常驻数据集合替换。

7.根据权利要求5所述的方法，其特征在于，所述读写进程早于所述软件进程的启动而启动。

8.根据权利要求1-6任意一项所述的方法，其特征在于，所述读写进程配置有多个子文件系统，不同的子文件系统对应不同的数据格式。

9.一种数据加载装置，其特征在于，所述装置包括获取单元、确定单元和预加载单元：

所述获取单元，用于获取状态触发请求，所述状态触发请求用于标识软件中的目标数据；

所述确定单元，用于根据所述软件的数据关联关系，通过读写进程确定与所述目标数据关联的关联数据；所述关联数据为加载所述目标数据后待加载的数据；

所述预加载单元，用于通过所述读写进程将所述关联数据预加载到文件缓存中。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括生成单元：

所述生成单元，用于根据所述软件运行时打开的功能页面，生成所述状态触发请求，所述目标数据是根据所述功能页面确定的。

11.根据权利要求10所述的装置，其特征在于，所述获取单元，还具体用于：

获取对应所述状态触发请求的操作位置信息；

所述确定单元，还具体用于根据所述操作位置信息所标识操作位置与所述功能页面中功能对象间的距离关系，确定所述关联数据的预加载顺序；

所述预加载单元，具体用于：

通过所述读写进程，根据所述预加载顺序将所述关联数据预加载到文件缓存中。

12.根据权利要求9所述的装置，其特征在于，所述确定单元，还具体用于：

针对所述软件对应的多个内容场景，对所述内容场景中所对应数据进行遍历加载，以确定所述内容场景中数据间的关联关系；

根据针对所述多个内容场景确定的关联关系，确定所述数据关联关系。

13.根据权利要求9所述的装置，其特征在于，所述确定单元，还具体用于：

确定共享内存保存的常驻数据集合中是否包括所述关联数据；

若是，通过所述软件对应的软件进程，从所述共享内存读取所述关联数据；

若否，通过所述软件对应的软件进程调用所述读写进程，从所述文件缓存中读取已经预加载了的所述关联数据。

14.一种数据加载设备，其特征在于，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行权利要求1-8任意一项所述的数据加载方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行权利要求1-8任意一项所述的数据加载方法。

Images