虚拟场景中的资源处理方法、装置及电子设备

技术领域

本申请涉及计算机技术，尤其涉及一种虚拟场景中的资源处理方法、装置、电子设备及计算机可读存储介质。

背景技术

随着计算机技术的快速发展，扩展了感知环境以及获取信息的渠道，虚拟场景便是其中一个典型例子。虚拟场景是指利用电子设备输出的区别于现实世界的场景，用户可以对虚拟场景形成模拟现实世界的感知，实现与虚拟场景之间的交互。

虚拟场景往往包括多个资源，如贴图、动画等多种资源。在虚拟场景的开发及运营过程中，可能会由于相关人员错误设置或者虚拟场景的版本更新等原因，导致虚拟场景中某些资源的属性值出现异常。在相关技术提供的方案中，通常是针对每一种待检查属性单独编写一套代码，以判断属性值是否异常。但是，该方案对于代码的维护成本过高，且会导致电子设备的计算资源被过度占用。

发明内容

本申请实施例提供一种虚拟场景中的资源处理方法、装置、电子设备及计算机可读存储介质，能够提升对不同待检查属性的通用性，降低资源处理的实现成本，同时也能够减少电子设备的计算资源占用。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种虚拟场景中的资源处理方法，包括：

响应于在资源处理界面中接收到的策略设置操作，获取针对虚拟场景设置的检查策略；其中，所述检查策略包括待检查属性的名称、以及所述待检查属性对应的属性值条件；

根据所述待检查属性的名称，将所述虚拟场景中的资源的所述待检查属性映射为可调用对象，并通过调用所述待检查属性对应的可调用对象，得到所述资源对应所述待检查属性的属性值；

将所述资源对应所述待检查属性的属性值与所述待检查属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定所述虚拟场景中的异常资源；

根据所述异常资源更新所述资源处理界面。

本申请实施例提供一种虚拟场景中的资源处理装置，包括：

获取模块，用于响应于在资源处理界面中接收到的策略设置操作，获取针对虚拟场景设置的检查策略；其中，所述检查策略包括待检查属性的名称、以及所述待检查属性对应的属性值条件；

映射模块，用于根据所述待检查属性的名称，将所述虚拟场景中的资源的所述待检查属性映射为可调用对象，并通过调用所述待检查属性对应的可调用对象，得到所述资源对应所述待检查属性的属性值；

匹配模块，用于将所述资源对应所述待检查属性的属性值与所述待检查属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定所述虚拟场景中的异常资源；

更新模块，用于根据所述异常资源更新所述资源处理界面。

本申请实施例提供一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的虚拟场景中的资源处理方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的虚拟场景中的资源处理方法。

本申请实施例具有以下有益效果：

根据获取到的检查策略中的待检查属性的名称，将资源的待检查属性映射为可调用对象，并通过调用可调用对象得到待检查属性的属性值，进而根据检查策略中的待检查属性对应的属性值条件对属性值进行检查，以确定虚拟场景中的异常资源，如此，仅需设置检查策略即可实现智能化的资源处理，能够提升对不同待检查属性的通用性，同时也能够降低资源处理的实现成本，对于电子设备来说，能够减少电子设备在资源处理过程中的计算资源占用。

附图说明

图1是相关技术提供的资源处理方案的示意图；

图2是本申请实施例提供的虚拟场景中的资源处理系统的架构示意图；

图3是本申请实施例提供的终端设备的架构示意图；

图4是本申请实施例提供的虚拟场景引擎的示意图；

图5A是本申请实施例提供的虚拟场景中的资源处理方法的流程示意图；

图5B是本申请实施例提供的虚拟场景中的资源处理方法的流程示意图；

图5C是本申请实施例提供的虚拟场景中的资源处理方法的流程示意图；

图5D是本申请实施例提供的虚拟场景中的资源处理方法的流程示意图；

图6是本申请实施例提供的资源处理界面的示意图；

图7是本申请实施例提供的资源处理界面的示意图；

图8A是本申请实施例提供的资源处理界面的示意图；

图8B是本申请实施例提供的资源处理界面的示意图；

图9是本申请实施例提供的资源配置的示意图；

图10是本申请实施例提供的资源处理的示意图；

图11是本申请实施例提供的属性检查的示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。在以下的描述中，所涉及的术语“多个”是指至少两个。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)虚拟场景：利用电子设备输出的区别于现实世界的场景，通过裸眼或设备的辅助能够形成对虚拟场景的视觉感知，例如通过显示屏幕输出的二维影像，通过立体投影、虚拟现实和增强现实技术等立体显示技术来输出的三维影像；此外，还可以通过各种可能的硬件形成听觉感知、触觉感知、嗅觉感知和运动感知等各种模拟现实世界的感知。虚拟场景可以是对真实世界的仿真环境，也可以是半仿真半虚构的虚拟环境，还可以是纯虚构的虚拟环境。虚拟场景可以是二维虚拟场景、2.5维虚拟场景或者三维虚拟场景中的任意一种，本申请实施例对虚拟场景的维度不加以限定。

2)响应于：用于表示所执行的操作所依赖的条件或者状态，当满足所依赖的条件或状态时，所执行的一个或多个操作可以是实时的，也可以具有设定的延迟；在没有特别说明的情况下，所执行的多个操作不存在执行先后顺序的限制。

3)资源：虚拟场景的项目可以包括虚拟场景引擎(如游戏引擎)以及资源两个部分，其中，虚拟场景引擎是为输出虚拟场景的电子设备所设计的、能够被该电子设备识别的代码(指令)集合，用于控制虚拟场景中的资源如何输出；而资源则是需要被输出的内容。虚拟场景往往包括多个资源，本申请实施例对虚拟场景中的资源类型不做限定，例如资源类型包括但不限于贴图(图像)、动画以及声音。此外，虚拟场景可以包括多个模块，每个模块包括多个资源，模块可以根据实际应用场景进行划分，例如在游戏虚拟场景中，可以划分出角色、武器及怪物等多个模块。

值得说明的是，虚拟场景中的资源通常是指静态资源，而电子设备的计算资源通常包括中央处理器(Central Processing Unit，CPU)资源、内存资源及硬盘资源等。

4)属性：指资源具有的本质特性，用于描述资源。一个资源往往具有多种属性，可以根据实际应用场景进行自定义配置，例如对于资源类型为贴图的资源来说，属性可以包括资源路径、资源名称、占用内存及高度等。在本申请实施例中，资源类型不同的资源可以对应相同的属性，也可以对应不同的属性。

5)资源处理界面：用于接收针对虚拟场景设置的相关策略，还可以用于呈现异常资源以提醒相关人员进行修复。资源处理界面可以包括两类，一类独立于虚拟场景存在，例如独立的Web界面；另一类是虚拟场景引擎所提供的引擎界面，如虚拟场景引擎中的编辑器(Editor)组件所提供的用户界面。在本申请实施例中，这两类界面可以任选其一使用，也可以结合使用。

6)策略：又称规则，电子设备可以按照设定的逻辑解析策略，并执行相应操作以实现相应功能，例如电子设备可以根据检查策略执行确定虚拟场景中的异常资源的操作。策略可以由相关人员手动设置，或者通过人工智能(Artificial Intelligence，AI)进行自动设置。

7)反射(Reflection)：在程序的运行状态中，可以将类(如Java类)中的属性、方法及父类等各种成分映射成相应的对象，并支持调用映射的对象的属性和方法，这种动态获取程序信息以及动态调用对象的功能即为反射机制，反射机制是动态语言的关键。在本申请实施例中，可以基于待检查属性的名称进行反射，从而得到待检查属性的属性值。

值得说明的是，上述的对象(Object)是对客观事物的抽象，类(Class)是对对象的抽象，是一种抽象的数据类型。从另一个角度来说，对象是类的实例，类是对象的模板。在本申请实施例中，类可以是指虚拟场景中的资源所属的类，例如可以针对不同资源类型分别定义对应的类。

在相关技术提供的方案中，若需要在虚拟场景中新增一个待检查属性，则需要执行四步操作。如图1所示，第一步是人为编写待检查属性的获取代码，该获取代码用于在被执行时获取待检查属性的属性值；第二步是人为设置属性值条件；第三步是人为编写针对属性值条件的读取代码，该读取代码用于在被执行时读取属性值条件；第四步是人为编写针对属性值条件的检查代码，该检查代码用于在被执行时检查待检查属性的属性值是否异常。同理，若已增加的某个待检查属性的属性值条件需要更新时，同样也会执行类似的四步操作。

相关技术提供的方案至少存在以下问题：四步操作之间的联系较为紧密，代码之间的耦合度(如获取代码、读取代码、检查代码三者之间的耦合度)高，在每次需要更新代码时很容易出现问题，代码的维护成本较高；对于每一个待检查属性，都需要单独编写对应的一套代码(如获取代码、读取代码及检查代码)，导致对不同待检查属性以及不同虚拟场景的通用性差，同时，需要耗费较多的人力成本进行代码编写，电子设备也会耗费较多的计算资源来存储大量的相关代码。

本申请实施例提供一种虚拟场景中的资源处理方法、装置、电子设备和计算机可读存储介质，能够精简资源处理的操作，即无需执行图1中虚线框部分的操作(上述的第三步至第四步操作)，在新增待检查属性时只需在代码中增加获取属性值的方法(例如增加待检查属性的名称)即可，能够解除代码之间的依赖关系，减少新增待检查属性或者更新属性值条件时的代码维护成本。下面说明本申请实施例提供的电子设备的示例性应用，本申请实施例提供的电子设备可以实施为各种类型的终端设备，也可以实施为服务器。

参见图2，图2是本申请实施例提供的虚拟场景中的资源处理系统100的架构示意图，终端设备400通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。

在一些实施例中，以电子设备是终端设备为例，本申请实施例提供的虚拟场景中的资源处理方法可以由终端设备实现，适用于一些完全依赖终端设备400本地的计算能力即可完成虚拟场景的相关数据计算及资源处理的实际应用场景，例如单机版/离线模式的游戏通过终端设备400完成虚拟场景的输出。

作为示例，如图2所示，终端设备400运行客户端410，客户端410在运行过程中呈现资源处理界面500。客户端410响应于在资源处理界面500中接收到的策略设置操作，获取针对虚拟场景设置的检查策略，检查策略可以是由相关人员(即用户)手动设置的，也可以是客户端410在接收到策略设置操作时，通过调用AI自动设置的。

检查策略包括待检查属性的名称、以及待检查属性对应的属性值条件，客户端410可以根据待检查属性的名称，将虚拟场景中的资源的待检查属性映射为可调用对象，并通过调用待检查属性对应的可调用对象，得到资源对应待检查属性的属性值，该过程对应上文的反射机制。然后，客户端410将资源对应待检查属性的属性值与待检查属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定虚拟场景中的异常资源。最终，客户端410根据异常资源更新资源处理界面500，如图2所示，在资源处理界面500中示例性地示出了包括异常资源1、2和3的资源处理结果。

相关人员可以对资源处理界面500中示出的异常资源进行手动修复，或者，也可以由客户端410对异常资源进行自动修复。完成对虚拟场景中的异常资源的修复后，可以提升虚拟场景中的资源有效率，如此在输出虚拟场景时，能够避免输出异常资源(即无用的资源)，提升电子设备(如终端设备400)所耗费的计算资源的实际利用率。

当需要形成虚拟场景的视觉感知时，终端设备400通过图形计算硬件计算显示所需要的数据，并完成显示数据(如虚拟场景中的各个资源)的加载、解析和渲染，在图形输出硬件输出能够对虚拟场景形成视觉感知的视频帧，例如，在智能手机的显示屏幕呈现二维的视频帧，或者，在增强现实/虚拟现实眼镜的镜片上投射实现三维显示效果的视频帧；此外，为了丰富感知效果，终端设备400还可以借助不同的硬件来形成听觉感知(如借助麦克风)、触觉感知(如借助振动器)、运动感知和味觉感知的一种或多种。值得说明的是，终端设备400中用于输出虚拟场景的客户端可以是客户端410，也可以是其他客户端。

在一些实施例中，以电子设备是服务器为例，本申请实施例提供的虚拟场景中的资源处理方法可以由服务器和终端设备协同实现，适用于依赖服务器200的计算能力完成虚拟场景的相关数据计算及资源处理，并在终端设备400输出异常资源及虚拟场景的实际应用场景。

终端设备400可以运行客户端410，客户端410在运行过程中呈现资源处理界面500。客户端410响应于在资源处理界面500中接收到的策略设置操作，获取针对虚拟场景设置的检查策略。然后，客户端410将检查策略发送至服务器200，以使服务器200根据获取到的检查策略对虚拟场景进行资源处理，以确定虚拟场景包括的多个资源中的异常资源。服务器200可以将确定出的异常资源(如异常资源的名称)发送至客户端410，以更新客户端410的资源处理界面500。同理，针对异常资源，服务器200可以根据客户端410接收到的修复指令，对虚拟场景中的异常资源进行修复，即由相关人员手动控制服务器200修复异常资源；或者，服务器200也可以对异常资源进行自动修复。

完成对虚拟场景中的异常资源的修复后，便可输出虚拟场景。以形成虚拟场景的视觉感知为例，服务器200进行虚拟场景相关显示数据(如虚拟场景中的各个资源)的计算并发送到终端设备400，终端设备400依赖于图形计算硬件完成计算显示数据的加载、解析和渲染，依赖于图形输出硬件输出虚拟场景以形成视觉感知。

在一些实施例中，终端设备400可以通过运行计算机程序来实现本申请实施例提供的虚拟场景中的资源处理方法，例如，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(Native)应用程序(APP，Application)，即需要在操作系统中安装才能运行的程序；也可以是小程序，即只需要下载到浏览器环境中就可以运行的程序；还可以是能够嵌入至任意APP中的小程序。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件，例如，可以是嵌入至虚拟场景引擎中的插件。另外，本申请实施例中的虚拟场景可以是游戏虚拟场景，其中游戏可以是军事仿真游戏、多人在线战术竞技(MOBA，Multiplayer Online Battle Arena)游戏或者多人枪战类生存游戏等，对此不做限定，当然，这并不构成对虚拟场景的限定。

在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，例如，云服务可以是资源处理服务，供终端设备400调用，以在虚拟场景包括的多个资源中确定出异常资源。其中，云技术(Cloud Technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。终端设备400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表以及智能电视等，但并不局限于此。终端设备400以及服务器200可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。

以本申请实施例提供的电子设备是终端设备为例说明，可以理解的，对于电子设备是服务器的情况，图3中示出的结构中的部分(例如用户接口、呈现模块和输入处理模块)可以缺省。参见图3，图3是本申请实施例提供的终端设备400的结构示意图，图3所示的终端设备400包括：至少一个处理器410、存储器450、至少一个网络接口420和用户接口430。终端设备400中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统440。

处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口430包括使得能够呈现媒体内容的一个或多个输出装置431，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口430还包括一个或多个输入装置432，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器450可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器450可选地包括在物理位置上远离处理器410的一个或多个存储设备。

存储器450包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器450旨在包括任意适合类型的存储器。

在一些实施例中，存储器450能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统451，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块452，用于经由一个或多个(有线或无线)网络接口420到达其他计算设备，示例性的网络接口420包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

呈现模块453，用于经由一个或多个与用户接口430相关联的输出装置431(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；

输入处理模块454，用于对一个或多个来自一个或多个输入装置432之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图3示出了存储在存储器450中的虚拟场景中的资源处理装置455，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块4551、映射模块4552、匹配模块4553及更新模块4554，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

参见图4，图4是本申请实施例提供的虚拟场景引擎的原理示意图，在虚拟场景是游戏虚拟场景的情况下，虚拟场景引擎可以是游戏引擎。为了便于理解，以游戏引擎为例进行说明，游戏引擎是指一些已编写好的可编辑电脑游戏系统或者一些交互式实时图像应用程序的核心组件，这些系统为游戏设计者提供各种编写游戏所需的各种工具，其目的在于让游戏设计者能容易和快速地做出游戏程式而不用由零开始，同时，游戏引擎也是游戏的发动机，用于控制游戏的运行，即控制游戏虚拟场景的输出。游戏引擎包括但不限于编辑器、渲染引擎(即“渲染器”，含二维图像引擎和三维图像引擎)、物理引擎、特效、音效、脚本引擎、骨骼动画、模型、用户界面(引擎界面)、底层算法、网络引擎以及场景管理。在底层层面上，游戏引擎是一个能够被电子设备识别的代码(指令)集合。一个游戏虚拟场景的项目(如游戏应用程序)可以包括游戏引擎和游戏资源两大部分，游戏资源包括贴图、声音及动画等，游戏引擎则是按游戏设计的要求(即按照设计好的程序代码)有序地调用(加载)这些游戏资源。

本申请实施例提供的虚拟场景中的资源处理方法，可以是由图3中所示出的虚拟场景中的资源处理装置455中的各个模块调用图4所示出的游戏引擎的相关组件所实现的，下面进行示例说明。

例如，获取模块4551用于调用游戏引擎中的用户界面组件，以获取在用户界面(资源处理界面)中针对虚拟场景设置的检查策略，其中，资源处理界面可以是游戏引擎中的编辑器组件或其他组件提供的；映射模块4552用于调用游戏引擎中的底层算法组件和编辑器组件，以将虚拟场景中的资源的待检查属性映射为可调用对象，从而得到资源对应待检查属性的属性值；匹配模块4553用于调用游戏引擎中的底层算法组件和编辑器组件，以将资源对应待检查属性的属性值与待检查属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定虚拟场景中的异常资源；更新模块4554用于调用用户界面组件，以根据异常资源更新资源处理界面。

当然，上述示例并不构成对本申请实施例的限定，游戏引擎包括的各个组件，以及虚拟场景中的资源处理装置455中的各个模块对游戏引擎中的组件的调用关系，均可以根据实际应用场景进行调整。

将结合本申请实施例提供的电子设备的示例性应用和实施，说明本申请实施例提供的虚拟场景中的资源处理方法。

参见图5A，图5A是本申请实施例提供的虚拟场景中的资源处理方法的一个流程示意图，将结合图5A示出的步骤进行说明。

在步骤101中，响应于在资源处理界面中接收到的策略设置操作，获取针对虚拟场景设置的检查策略；其中，检查策略包括待检查属性的名称、以及待检查属性对应的属性值条件。

虚拟场景往往包括多个资源，其中往往包括属性值不符合要求的异常资源，异常资源的产生原因是多种多样的，例如相关人员(如开发人员和美术人员等)在虚拟场景中导入了错误的资源，又如在虚拟场景版本迭代时未对已有资源的属性值进行及时更新等。若输出了包括异常资源的虚拟场景，则会导致电子设备在输出过程中所耗费的计算资源被白白浪费，同时，异常资源也会影响人机交互的效果，降低用户体验。

因此，在本申请实施例中，针对虚拟场景进行资源处理，以确定虚拟场景中的异常资源。首先，呈现资源处理界面，当在资源处理界面中接收到策略设置操作时，获取针对虚拟场景设置的检查策略。其中，资源处理界面可以是独立于虚拟场景的虚拟场景引擎的界面，例如一个独立的Web界面；也可以是由虚拟场景引擎提供的用户界面，例如由虚拟场景引擎的编辑器组件提供的用户界面。

这里，获取到的检查策略至少包括待检查属性的名称、以及待检查属性对应的属性值条件，当然还可以包括其他内容，将在后文进行进一步阐述，其中，属性值条件可以根据实际应用场景进行设定。一个检查策略可以包括待检查属性对应的多个属性值条件，前提是这些属性值条件不能相互冲突，例如一个检查策略同时包括“大于50”的属性值条件和“小于100”的属性值条件。对于一个待检查属性来说，也可以同时对应多个检查策略。

值得说明的是，获取到的检查策略包括有电子设备可解析的内容，电子设备可以根据检查策略执行资源处理操作，从而实现资源处理功能。其中，可以在电子设备中预先部署用于解析检查策略的相关逻辑，例如预先存储用于解析检查策略的代码(如脚本)。在一些实施例中，获取到的检查策略也可以是代码形式，电子设备可以直接执行获取到的检查策略，以实现资源处理功能。

在一些实施例中，步骤101之后，还包括：响应于针对虚拟场景中的任意一种属性的策略复用操作，将检查策略中的待检查属性的名称替换为任意一种属性的名称，并将待检查属性对应的属性值条件作为任意一种属性的属性值条件，以得到新的检查策略。

在获取到待检查属性对应的检查策略后，可以将检查策略复用给区别于待检查属性的属性。举例来说，获取到的检查策略对应的待检查属性为Android操作系统中的贴图高度(为了便于说明，命名为属性A)，检查策略中的属性值条件为“贴图高度小于100像素”。在接收到针对虚拟场景中的任意一种属性(为了便于说明，以属性为iOS操作系统中的贴图高度举例，并命名为属性B)的策略复用操作时，将检查策略中的属性A的名称替换为属性B的名称，并将检查策略中的属性值条件作为属性B的属性值条件，以得到属性B对应的检查策略。至于属性A对应的检查策略，可以继续保留。

为了便于进行策略复用，可以在资源处理界面中呈现多种属性、以及与每种属性分别对应的策略复用选项，并将接收到的针对任意一种属性对应的策略复用选项的触发操作，作为针对该属性的策略复用操作。此外，若已获取到多个检查策略，则可以在接收到策略复用操作时，在资源处理界面中呈现所有的检查策略，并在接收到针对呈现的多个检查策略的选中操作时，根据被选中的检查策略进行策略复用。通过上述方式，能够减少检查策略的设置工作量，节省人力成本。

在步骤102中，根据待检查属性的名称，将虚拟场景中的资源的待检查属性映射为可调用对象，并通过调用待检查属性对应的可调用对象，得到资源对应待检查属性的属性值。

在获取到检查策略之后，即可根据检查策略中的待检查属性的名称，获取虚拟场景中的资源对应待检查属性的属性值。在本申请实施例中，主要基于反射机制实现属性值的获取，例如，可以根据待检查属性的名称，将虚拟场景中的资源的待检查属性映射为可调用对象，并通过调用待检查属性对应的可调用对象，得到资源对应待检查属性的属性值，这里的调用待检查属性对应的可调用对象，可以是指调用可调用对象中的取值方法(取值函数)。

本申请实施例对映射的方式不做限定，例如可以根据PropertyInfo类将虚拟场景中的资源的待检查属性映射为PropertyInfo对象，并通过调用PropertyInfo对象的GetValue方法，来得到资源对应待检查属性的属性值。如此，对于不同的待检查属性来说，只需配置一套根据名称获取属性值的代码即可，无需针对不同的待检查属性进行单独配置。

值得说明的是，可以针对虚拟场景中的每个资源执行步骤102，也可以对虚拟场景中的多个资源进行筛选后得到待检查资源，再对每个待检查资源执行步骤102。举例来说，可以将虚拟场景中具有待检查属性、且待检查属性被设置为生效的资源，作为待检查资源，其他资源则忽略，其中，资源具有的属性可以根据实际应用场景进行设定。在本申请实施例中，属性可以配置是否生效，例如可以在资源处理界面中呈现与属性对应的生效配置选项。当资源的某个属性被配置为未生效时，可以视为该资源不具有该属性。

值得说明的是，本申请实施例中可以借助虚拟场景引擎的能力来获取属性值，也可以根据独立于虚拟场景引擎的工具(如客户端工具)来获取属性值。

在一些实施例中，步骤102之前，还包括：响应于针对虚拟场景中的任意一种资源类型的属性复用操作，将父资源的属性复用至子资源中；其中，父资源为虚拟场景中与任意一种资源类型匹配成功的资源；子资源为虚拟场景中区别于父资源的资源。

除了策略复用外，本申请实施例还可以支持属性复用。例如，当接收到针对虚拟场景中的任意一个资源类型的属性复用操作时，将与该资源类型匹配成功(即符合该资源类型)的资源作为父资源，将区别于父资源的资源作为子资源，并将父资源的属性复用至子资源中，即是使子资源具有被复用的属性。举例来说，可以预先设定资源类型为基础类型的资源，其属性包括名称、路径及内存，当接收到针对基础类型的属性复用操作时，将资源类型为基础类型的资源的所有属性复用至子资源中，例如资源类型为贴图的子资源、资源类型为网格的子资源、以及资源类型为动画的子资源等。值得说明的是，与同一资源类型匹配成功的多个资源的属性通常相同。另外，在确定出父资源后，还可以将区别于父资源的部分资源作为子资源，例如可以人为筛选出一些资源以作为子资源。

当然，在本申请实施例中，可以支持对资源的属性的自定义。例如，在子资源继承了父资源的属性后，可以对子资源的属性进行进一步更新，如增加或删除属性。举例来说，对于资源类型为贴图的子资源，可以进一步增加高度、宽度及是否可读等属性；对于资源类型为网格的子资源，可以进一步增加网格数、顶点数及是否可读等属性；对于资源类型为动画的子资源，可以进一步增加动画曲线、关键帧及导入模式等属性。通过上述方式，能够减少属性设置的工作量，节省人力成本，实现快速、有效地设置。

在一些实施例中，可以通过这样的方式来实现上述的根据待检查属性的名称，将虚拟场景中的资源的待检查属性映射为可调用对象：获取虚拟场景中的白名单资源；根据待检查属性的名称，将位于虚拟场景、且区别于白名单资源的资源的待检查属性映射为可调用对象。

这里，可以获取虚拟场景中的白名单资源，并将区别于白名单资源的资源作为待检查资源，实现资源筛选，即是将白名单资源添加至筛选条件中。然后，根据待检查属性的名称，将待检查资源的待检查属性映射为可调用对象，对于白名单资源则忽略，如此能够有效地减少资源处理的工作量。其中，白名单资源可以根据实际应用场景进行设定，例如将虚拟场景中属性值(指资源的所有属性分别对应的属性值)更新频率小于频率阈值的资源作为白名单资源。

在一些实施例中，可以通过这样的方式来实现上述的根据待检查属性的名称，将虚拟场景中的资源的待检查属性映射为可调用对象：获取虚拟场景中的黑名单资源；根据待检查属性的名称，将黑名单资源的待检查属性映射为可调用对象。

这里，也可以将虚拟场景中的黑名单资源作为待检查资源，同时忽略区别于黑名单资源的资源，即是将黑名单资源添加至筛选条件中。其中，黑名单资源可以根据实际应用场景进行设定，例如将虚拟场景中属性值更新频率大于或等于频率阈值的资源作为黑名单资源。通过上述方式能够提升资源处理的针对性。

在步骤103中，将资源对应待检查属性的属性值与待检查属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定虚拟场景中的异常资源。

在得到资源对应待检查属性的属性值后，将该属性值与待检查属性对应的属性值条件进行匹配处理，并根据匹配结果判断该资源是否为异常资源，判断方式在后文进行阐述。

在本申请实施例中，可以设定检查策略的类型。例如，类型包括但不限于超标检查以及引用丢失检查，对于类型为超标检查的检查策略来说，其内的属性值条件可以是属性值小于某个阈值或大于某个阈值；对于类型为引用丢失检查的检查策略来说，其内的待检查属性可以是引用属性，属性值条件可以是属性值不等于零，其中，若引用属性的属性值为零，则表示出现了引用丢失。

在步骤104中，根据异常资源更新资源处理界面。

在确定出异常资源后，可以根据异常资源更新资源处理界面，例如可以在资源处理界面中呈现异常资源，这里，呈现异常资源可以是指呈现异常资源对应具有标识作用的属性的属性值，如名称属性的属性值及路径属性的属性值中的至少一种。在此基础上，还可以呈现异常资源对应待检查属性的属性值，以提醒相关人员对该属性值进行更新，即实现对异常资源的修复；还可以呈现异常资源的资源类型以及所属模块，便于相关人员快速定位异常资源；还可以呈现用于确定异常资源的检查策略的类型，以便相关人员定位异常原因，如属性值超标或是引用丢失。

除了更新资源处理界面外，在本申请实施例中，还可以根据异常资源进行告警，如以短信或邮件等方式进行告警。

值得说明的是，由于虚拟场景中的资源的属性值可能会不断变化(例如经历版本迭代)，故步骤102至步骤104可以周期性地执行，以对虚拟场景中的异常资源进行实时监测。

在一些实施例中，检查策略的数量包括多个，且每个检查策略对应一种风险等级；步骤101之后，还包括：遍历多个检查策略；其中，遍历到的检查策略用于确定虚拟场景中的异常资源；可以通过这样的方式来实现上述的根据异常资源更新资源处理界面：在资源处理界面中呈现多个异常资源，且对应不同风险等级的异常资源的呈现方式不同；其中，异常资源对应的风险等级为用于确定异常资源的检查策略对应的风险等级。

在本申请实施例中，获取到的检查策略的数量可以包括多个，对于该情况，可以遍历多个检查策略，并根据遍历到的检查策略确定虚拟场景中的异常资源。在此基础上，若每个检查策略对应一个风险等级，则可以将遍历到的检查策略对应的风险等级，作为根据遍历到的检查策略确定出的异常资源对应的风险等级。其中，不同检查策略对应的风险等级可以相同，也可以不同。风险等级可以包括高和低两种，可以根据实际应用场景进行设定。

在遍历完成时，可以在资源处理界面中呈现确定出的所有异常资源，且对应不同风险等级的异常资源的呈现方式不同，以便相关人员进行区分。其中，呈现方式不同可以是指呈现内容、呈现字体、呈现尺寸以及呈现颜色中的至少一种不同。作为示例，本申请实施例提供了如图6所示的资源处理界面的示意图，在图6中，以列表形式呈现了异常资源1至5，其中异常资源1至3的风险等级均为高，异常资源4至5的风险等级均为低，因此异常资源1至3对应的呈现尺寸大于异常资源4至5对应的呈现尺寸。通过上述方式，能够提升对应不同风险等级的异常资源之间的区分度，便于提醒相关人员优先对风险等级更高的异常资源进行修复。

在一些实施例中，可以通过这样的方式来实现上述的根据异常资源更新资源处理界面：在资源处理界面中呈现异常资源、以及虚拟场景中区别于异常资源的资源，且异常资源与区别于异常资源的资源的呈现方式不同。

这里，可以在资源处理界面中仅呈现异常资源，也可以同时呈现异常资源、以及虚拟场景中区别于异常资源的资源(为了便于区分，命名为正常资源)，且异常资源与正常资源的呈现方式不同。同理，这里的呈现方式不同也可以是指呈现内容、呈现字体、呈现尺寸以及呈现颜色中的至少一种不同。作为示例，本申请实施例提供了如图7所示的资源处理界面的示意图，在图7中，以较大的呈现尺寸呈现异常资源1至3，同时以较小的呈现尺寸呈现正常资源4至5。通过上述方式，能够提升资源处理界面中呈现的内容的全面性，同时强化异常资源与正常资源之间的区别，便于相关人员对异常资源进行修复，例如根据正常资源对应待检查属性的属性值，对异常资源对应待检查属性的属性值进行更新。

如图5A所示，本申请实施例根据在资源处理界面中配置的检查策略进行自动化资源处理，能够降低资源处理的实现成本，同时有效减少电子设备在资源处理过程中的计算资源占用。

在一些实施例中，参见图5B，图5B是本申请实施例提供的虚拟场景中的资源处理方法的一个流程示意图，图5A示出的步骤101可以更新为步骤201，在步骤201中，响应于在资源处理界面中接收到的策略设置操作，获取针对虚拟场景设置的检查策略；其中，检查策略包括待检查属性的名称、待检查属性对应的属性值条件、待筛选属性的名称、以及待筛选属性对应的属性值条件。

这里，获取到的检查策略除了包括待检查属性的名称以及待检查属性对应的属性值条件外，还可以包括待筛选属性的名称以及待筛选属性对应的属性值条件，其中，待筛选属性的名称以及待筛选属性对应的属性值条件用于从虚拟场景包括的多个资源中筛选出待检查资源，即作为筛选条件。

在图5B中，基于图5A，在步骤201之后，还可以在步骤202中，根据待筛选属性的名称，将虚拟场景中的资源的待筛选属性映射为可调用对象，并通过调用待筛选属性对应的可调用对象，得到资源对应待筛选属性的属性值。

这里，针对虚拟场景中的每个资源，同样基于反射机制来得到对应待筛选属性的属性值。例如，根据待筛选属性的名称，将虚拟场景中的资源的待筛选属性映射为可调用对象，并通过调用该可调用对象得到资源对应待筛选属性的属性值。

在步骤203中，将资源对应待筛选属性的属性值与待筛选属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定虚拟场景中的待检查资源。

这里，在得到资源对应待筛选属性的属性值后，将该属性值与待筛选属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定该资源是否为待检查资源。

值得说明的是，若存在其他筛选条件，则可以在步骤202之前进行资源筛选，并针对筛选出的每个资源执行步骤202及步骤203；也可以在步骤203之后，对得到的待检查资源进行进一步筛选。

在一些实施例中，检查策略的数量包括多个；步骤201之后，还包括：遍历多个检查策略；其中，遍历到的检查策略用于确定虚拟场景中的待检查资源；步骤203之后，还包括：当根据遍历到的检查策略确定的待检查资源的数量为零时，继续遍历下一个检查策略。

这里，当获取到的检查策略的数量包括多个时，可以遍历多个检查策略，并根据遍历到的检查策略确定虚拟场景中的待检查资源。当根据遍历到的检查策略确定出的待检查资源的数量为零时，直接遍历下一个检查策略，从而提升资源处理的效率，避免无效处理。

在一些实施例中，可以通过这样的方式来实现上述的根据得到的匹配结果确定虚拟场景中的待检查资源：针对虚拟场景中的每个资源执行以下处理：当资源对应待筛选属性的匹配结果为匹配成功时，将资源作为待检查资源；当资源对应待筛选属性的匹配结果为匹配失败时，忽略资源。

这里，针对虚拟场景中的每个资源，当资源对应待筛选属性的匹配结果为匹配成功时，将该资源作为待检查资源；当资源对应待筛选属性的匹配结果为匹配失败时，忽略该资源。举例来说，检查策略中的待筛选属性为材质，待筛选属性对应的属性值条件为“材质为金属”，则确定出的待检查资源对应材质属性的属性值均为金属。通过上述方式，能够提升根据检查策略进行资源筛选的有效性。

当然，这并不构成对本申请实施例的限定，例如也可以是当资源对应待筛选属性的匹配结果为匹配成功时，忽略该资源；当资源对应待筛选属性的匹配结果为匹配失败时，将该资源作为待检查资源。

在图5B中，图5A示出的步骤102可以更新为步骤204，在步骤204中，根据待检查属性的名称，将虚拟场景中的待检查资源的待检查属性映射为可调用对象，并通过调用待检查属性对应的可调用对象，得到待检查资源对应待检查属性的属性值。

在得到待检查资源后，便可仅对待检查资源进行后续处理。例如，针对每个待检查资源，根据待检查属性的名称将待检查资源的待检查属性映射为可调用对象，并通过调用该可调用对象，得到该待检查资源对应待检查属性的属性值

在图5B中，图5A示出的步骤103可以更新为步骤205，在步骤205中，将待检查资源对应待检查属性的属性值与待检查属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定虚拟场景中的异常资源。

对于每个待检查资源，均可得到对应待检查属性的匹配结果，如此即可在所有待检查资源中确定出异常资源，以更新资源处理界面。

如图5B所示，本申请实施例先从虚拟场景包括的所有资源中筛选出待检查资源，再在所有待检查资源中筛选出异常资源，能够有效地减少资源处理的工作量，提升资源处理效率。

在一些实施例中，参见图5C，图5C是本申请实施例提供的虚拟场景中的资源处理方法的一个流程示意图，图5A示出的步骤101可以通过步骤301至步骤303实现，将结合各步骤进行说明。

在步骤301中，在资源处理界面中呈现多种属性。

在本申请实施例中，可以基于选中操作及条件设置操作来获取针对虚拟场景设置的检查策略。首先，在资源处理界面中呈现多种属性，例如可以呈现虚拟场景中的所有属性，也可以呈现筛选后的属性。

在步骤302中，响应于针对多种属性的选中操作，将被选中的属性的名称作为待检查属性的名称。

这里，当接收到针对多种属性的选中操作(如点击操作或长按操作等)时，将被选中的属性作为待检查属性，即是将被选中的属性的名称作为待检查属性的名称。

在步骤303中，响应于针对待检查属性的条件设置操作，获取针对待检查属性设置的属性值条件。

例如，可以呈现待检查属性对应的条件设置界面，并响应于在条件设置界面中接收到的针对待检查属性的条件设置操作，获取针对待检查属性设置的属性值条件。其中，条件设置界面可以独立于资源处理界面存在，也可以在资源处理界面中以窗口形式呈现。

值得说明的是，还可以响应于在条件设置界面中接收到的针对待筛选属性的条件设置操作，获取针对待筛选属性设置的属性值条件，同时也可获取待筛选属性的名称。

在一些实施例中，可以通过这样的方式实现上述的在资源处理界面中呈现多种属性：在资源处理界面中呈现多种筛选条件；其中，筛选条件包括资源类型以及资源所属模块中的至少一种；虚拟场景包括多个模块，且每个模块包括多个资源；响应于针对多种筛选条件的选中操作，呈现与被选中的筛选条件匹配成功的资源的多种属性。

这里，可以在资源处理界面中呈现多种筛选条件，每种筛选条件包括资源类型以及资源所属模块中的至少一种。举例来说，可以在资源处理界面中呈现虚拟场景中的所有资源类型和/或虚拟场景中的所有模块。

其中，虚拟场景包括多个模块，每个模块包括多个资源，例如在游戏虚拟场景中，可以划分出角色(虚拟角色)、武器及怪物等多个模块，其中角色模块包括与角色对应的多个资源，如用于构建角色形象的多个贴图资源，武器模块与怪物模块同理。

当接收到针对呈现的多种筛选条件的选中操作时，将与被选中的筛选条件匹配成功的资源作为待检查资源，并在资源处理界面中呈现待检查资源的多种属性，以便相关人员从多种属性中确定待检查属性。例如筛选条件包括的是贴图类型，则可以将虚拟场景中资源类型为贴图类型的所有资源均作为待检查资源。在上述方式中，被选中的筛选条件即为符合用户需求的筛选条件，通过呈现待检查资源的多种属性，能够减少所需呈现的属性的种类，节省电子设备的计算资源，同时也可便于相关人员快速确定待检查属性。

在一些实施例中，可以通过这样的方式实现上述的根据待检查属性的名称，将虚拟场景中的资源的待检查属性映射为可调用对象：根据待检查属性的名称，将位于虚拟场景、且与被选中的筛选条件匹配成功的资源的待检查属性，映射为可调用对象。

这里，可以将与被选中的筛选条件匹配成功的资源作为待检查资源，并仅获取待检查资源对应待检查属性的属性值，对于其他资源则忽略，从而减少资源处理的工作量。

在此基础上，若检查策略包括待筛选属性的名称以及待筛选属性对应的属性值条件，则可以根据待筛选属性的名称以及待筛选属性对应的属性值条件，对与被选中的筛选条件匹配成功的资源进行进一步筛选，以得到待检查资源。当然，也可以首先根据待筛选属性的名称以及待筛选属性对应的属性值条件，对虚拟场景中的多个资源进行筛选，再根据被选中的筛选条件对筛选后的资源进行进一步筛选，以得到待检查资源。通过上述方式，能够减少资源处理的工作量，提升效率。

如图5C所示，本申请实施例将策略设置操作拆分为选中操作及条件设置操作，能够加强人机交互体验，便于提升设置的检查策略的准确性。

在一些实施例中，参见图5D，图5D是本申请实施例提供的虚拟场景中的资源处理方法的一个流程示意图，图5A示出的步骤103可以通过步骤401至步骤403实现，将结合各步骤进行说明。

在步骤401中，将资源对应待检查属性的属性值与待检查属性对应的属性值条件进行匹配处理。

在得到资源对应待检查属性的属性值后，将该属性值与待检查属性对应的属性值条件进行匹配处理。

在步骤402中，当资源对应待检查属性的匹配结果为匹配成功时，忽略资源。

在步骤403中，当资源对应待检查属性的匹配结果为匹配失败时，将资源作为异常资源。

本申请实施例提供了一种确定异常资源的示例，当某资源对应待检查属性的匹配结果为匹配成功时，忽略该资源；当某资源对应待检查属性的匹配结果为匹配失败时，将该资源作为异常资源。为了便于理解，后文根据该示例进行说明。

当然，这并不构成对本申请实施例的限定，例如也可以是当某资源对应待检查属性的匹配结果为匹配成功时，将该资源作为异常资源；当某资源对应待检查属性的匹配结果为匹配失败时，忽略该资源。

在图5D中，图5A示出的步骤104可以通过步骤404至步骤405实现，将结合各步骤进行说明。

在步骤404中，在资源处理界面中呈现异常资源、以及异常资源的异常修复选项。

在本申请实施例中，除了相关人员对异常资源进行手动修复的方式之外，还提供了自动修复的功能。例如，对于呈现的每一个异常资源，还可以呈现对应的异常修复选项。

在步骤405中，响应于针对异常修复选项的触发操作，对异常资源对应待检查属性的属性值进行更新处理，以使更新后的属性值与待检查属性对应的属性值条件匹配成功。

这里，当接收到针对异常修复选项的触发操作(如点击操作或长按操作等)时，对异常资源对应待检查属性的属性值进行更新处理，以使更新后的属性值与待检查属性对应的属性值条件匹配成功。如此，可以实现对异常资源的自动修复。

举例来说，若属性值条件包括的是单个属性值，则可以将异常资源对应待检查属性的属性值，更新为属性值条件中的属性值；若属性值条件包括的是属性值范围(例如50至100)，则可以将异常资源对应待检查属性的属性值，更新为属性值范围中的任意一个值(如最小值或最大值)。

在一些实施例中，可以通过这样的方式来实现上述的根据异常资源更新资源处理界面：确定异常资源对应待检查属性的属性值与待检查属性对应的属性值条件之间的差异程度；根据差异程度确定异常资源对应的风险等级；在资源处理界面中呈现多个异常资源，且对应不同风险等级的异常资源的呈现方式不同。

在本申请实施例中，对于每个异常资源，可以确定异常资源对应待检查属性的属性值与待检查属性对应的属性值条件之间的差异程度。举例来说，若属性值条件包括的是单个属性值，则可以将异常资源对应待检查属性的属性值与属性值条件中的属性值之间的差值的绝对值，作为该异常资源对应的差异程度；若属性值条件包括的是属性值范围，则可以将异常资源对应待检查属性的属性值与属性值范围中的任意一个属性值(如固定为最小值或固定为最大值)之间的差值的绝对值，作为该异常资源对应的差异程度。

异常资源的差异程度越大，表示该异常资源越为异常，该异常资源对应的风险等级越高，即风险等级与差异程度正相关。为了体现对应不同风险等级的异常资源之间的区别，可以在资源处理界面中呈现多个异常资源，且对应不同风险等级的异常资源的呈现方式不同，如图6所示。其中，呈现方式不同可以是指呈现内容、呈现字体、呈现尺寸以及呈现颜色中的至少一种不同。

如图5D所示，本申请实施例根据待检查属性对应的属性值条件，对异常资源对应待检查属性的属性值进行自动更新，实现了对异常资源的自动修复。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，为了便于理解，以虚拟场景为基于游戏引擎(如Unity游戏引擎)开发的游戏虚拟场景为例进行说明，当然，这并不构成对虚拟场景引擎以及虚拟场景的限定。

本申请实施例提供了如图8A所示的资源处理界面的示意图，在图8A中，以资源处理界面81为Web界面的情况作为示例。响应于针对资源处理界面81中的“资源属性配置”选项的触发操作(如点击操作或长按操作等)，在资源处理界面81中呈现游戏虚拟场景中的多种属性。这里，可以先呈现多种筛选条件，并响应于针对多种筛选条件的选中操作，呈现与被选中的筛选条件匹配成功的资源的多种属性，其中，筛选条件包括资源类型、资源所属模块、以及属性的生效结果(即是否生效)中的至少一种，检查规则对应上文的检查策略。在图8A中，以被选中的筛选条件为筛选条件82为例，筛选条件82中的资源类型为贴图，且筛选条件82中的生效结果同时包括生效和未生效。

在呈现属性时，可以呈现属性的属性名称、属性描述以及生效结果，还可以呈现属性对应资源的资源类型，其中，属性描述用于相关人员了解属性的功能。以图8A中的属性83为例，示出了资源类型为贴图，属性名称为formatiOS，属性描述为贴图iOS格式，生效结果为生效。此外，资源处理界面81中还提供了修改选项84，用于在被触发时对属性进行修改，如修改生效结果，便于相关人员对属性进行自定义。

响应于针对资源处理界面81中的“检查规则配置”选项的触发操作，可以呈现如图8B所示的相关内容。在对检查规则进行配置时，筛选条件可以包括规则分类以及规则级别(对应上文的风险等级)中的至少一种，当然，这里的筛选条件也可以与对资源属性进行配置所用的筛选条件一致，其中，规则分类用于表示检查规则的类型，检查规则的类型包括但不限于超标检查以及引用丢失检查。在图8B中，以被选中的筛选条件为筛选条件85为例，示出了与筛选条件85匹配成功的检查规则对应的属性，其中，筛选条件85中的规则分类为全部(即同时包括检查规则的所有类型)，且筛选条件85中的规则级别也为全部(即同时包括所有的规则级别)。

响应于对图8B示出的多种属性的选中操作(如点击操作或长按操作等)，将被选中的属性作为待检查属性，并呈现相应的规则配置界面(对应上文的条件设置界面)以进行检查规则的配置。在图8B中，以被选中的属性是所属模块的名称为场景、对应的资源类型为动画、且属性名称为动画时长的属性为例，示出了规则配置界面86。在规则配置界面86中，支持对属性对应的检查规则的规则分类及规则级别进行修改，当然也能够支持对检查规则内部进行修改。在本申请实施例中，检查规则可以包括前置规则和扫描规则两部分，其中，前置规则(包括上文的待筛选属性的名称、以及待筛选属性对应的属性值条件)用于筛选出待检查资源，扫描规则(包括上文的待检查属性的名称、以及待检查属性对应的属性值条件)用于判断待检查资源对应待检查属性的属性值是否符合要求。前置规则和扫描规则均包括函数(又称方法)和参数两部分，其中，函数用于表示属性值与参数之间的关系。如图8B所示，前置规则87为空，扫描规则88中的待检查属性为动画时长(单位为秒)，函数为小于，参数为1000，则扫描规则88的含义是资源的动画时长需要小于1000秒，若某资源的动画时长大于或等于1000秒，则将该资源作为异常资源(超标资源)。对于游戏虚拟场景中的一个属性来说，可以配置多个检查规则，每个检查规则中可以配置多个前置规则和多个扫描规则，前提是同一检查规则中的多个前置规则不能互相冲突，同理，同一检查规则中的多个扫描规则也不能互相冲突，例如同一检查规则中不能同时存在“动画时长大于1000秒”的扫描规则和“动画时长小于或等于1000秒”的扫描规则。

值得说明的是，在图8A和图8B中，还示出了“白名单配置”选项，用于在被触发时配置游戏虚拟场景中的白名单资源(即无需检查的资源)和/或白名单属性(即无需检查的属性)；还示出了“模块配置”选项，用于在被触发时配置游戏虚拟场景中的模块、以及模块所包括的资源，可以由相关人员根据实际场景进行自定义；还示出了“资源类型配置”选项，用于在被触发时配置游戏虚拟场景中的资源对应的资源类型，如将某资源的资源类型由贴图修改为动画。

对于配置好的检查规则，可以由游戏引擎或者特定的客户端工具根据检查规则进行资源处理，以确定游戏虚拟场景中的异常资源。

在底层实现上，本申请实施例主要包括属性配置以及检查规则配置两部分，接下来进行分别说明。在属性配置中，可以将对应任意一个资源类型的资源作为父资源，并将父资源的属性复用至子资源中，即实现属性复用(或称属性继承)，其中，子资源是区别于父资源的资源。如图9所示，父资源为属于SingleResData类的资源，其属性包括标识(IdentityDocument，ID)、名称(Name)、路径(AssetPath)以及占用内存(Memsize)，子资源包括贴图资源(即属于TextureDetail类的资源)、网格资源(即属于MeshDetail类的资源)、以及动画资源(即属于AnimationDetail类的资源)。对于子资源来说，属性除了从父资源继承的标识、名称、路径以及占用内存之外，还可以包括额外定义的属性，例如贴图资源的属性还包括宽度(Width)、高度(Height)、以及是否可读(Readable)等；网格资源的属性还包括网格数(Triscount)、顶点数(Vertexcount)、以及是否可读(Readable)等；动画资源的属性还包括动画曲线(Totalcurves)、关键帧(Keyframes)、以及动画导入模式(如Legacy模式)等。对于资源来说，所有的字段均以属性形式获取，上述的属性配置至少具有以下技术效果：可以忽略未生效的属性，仅对生效的属性做处理(如获取属性值)，能够有效避免因属性过多所导致的计算量暴增；统一的配置方案可以有利于对属性进行统一处理，减少代码的维护量，提升代码的优雅度。

在检查规则配置中，可以支持以下配置原则：1)一个待检查属性可以配置多个检查规则；2)检查规则可以仅包括扫描规则(即前置规则为空)，还可以同时包括前置规则和扫描规则；3)支持检查规则的复用，即可以将某个待检查属性的检查规则复用到另一个属性上。

基于配置的检查规则可以进行资源处理，本申请实施例提供了如图10所示的资源处理的示意图，对于某个待检查属性，首先获取该待检查属性对应的检查规则列表，这里以检查规则列表包括多个检查规则为例进行说明。然后，遍历获取到的检查规则列表，根据遍历到的检查规则中的前置规则进行属性检查，即筛选出游戏虚拟场景中的待检查资源。当待检查资源的数量大于零(即前置规则命中)时，继续根据遍历到的检查规则中的扫描规则进行属性检查，即判断待检查资源对应待检查属性的属性值是否超标；当待检查资源的数量等于零(即前置规则未命中)时，遍历检查规则列表中的下一个检查规则。

当根据遍历到的检查规则中的扫描规则确定出待检查资源对应待检查属性的属性值超标(即扫描规则命中)时，可以结束遍历，将待检查资源作为异常资源(即命中结果)，并在资源处理界面中呈现，如以BUG单的形式进行呈现，以提醒相关人员对异常资源对应待检查属性的属性值进行修复；当所有待检查资源对应待检查属性的属性值均未超标(即扫描规则未命中)时，继续遍历检查规则列表中的下一个检查规则。重复上述过程，直至检查规则列表中的所有检查规则均已遍历完毕，即已根据所有检查规则进行了属性检查。

本申请实施例提供了如图11所示的属性检查的示意图，对于某个属性(如前置规则所针对的待筛选属性或者扫描规则所针对的待检查属性)来说，可以基于反射机制获取属性值，并根据检查规则(具体如前置规则或扫描规则)中的函数和参数判断属性值是否超标。如果属性值超标，则命中；如果属性值未超标，则未命中。值得说明的是，在本申请实施例中，基于反射机制获取属性值的目的在于提升对不同属性的通用性和普适性，即无需针对不同属性单独编写一套获取属性值的代码。

本申请实施例至少具有以下技术效果：通过在Web界面配置检查规则，并通过反射机制获取属性值，从而根据检查规则判断属性值是否超标，能够满足不同游戏虚拟场景项目、不同属性、以及不同检查规则的需求，降低游戏虚拟场景项目接入时的代码维护成本，实现即接即用，同时也能够减少电子设备的计算资源(如存储资源)占用。

下面继续说明本申请实施例提供的虚拟场景中的资源处理装置455实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器450的虚拟场景中的资源处理装置455中的软件模块可以包括：获取模块4551，用于响应于在资源处理界面中接收到的策略设置操作，获取针对虚拟场景设置的检查策略；其中，检查策略包括待检查属性的名称、以及待检查属性对应的属性值条件；映射模块4552，用于根据待检查属性的名称，将虚拟场景中的资源的待检查属性映射为可调用对象，并通过调用待检查属性对应的可调用对象，得到资源对应待检查属性的属性值；匹配模块4553，用于将资源对应待检查属性的属性值与待检查属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定虚拟场景中的异常资源；更新模块4554，用于根据异常资源更新资源处理界面。

在一些实施例中，检查策略还包括待筛选属性的名称、以及待筛选属性对应的属性值条件；映射模块4552，还用于根据待筛选属性的名称，将虚拟场景中的资源的待筛选属性映射为可调用对象，并通过调用待筛选属性对应的可调用对象，得到资源对应待筛选属性的属性值；匹配模块4553，还用于将资源对应待筛选属性的属性值与待筛选属性对应的属性值条件进行匹配处理，并根据得到的匹配结果确定虚拟场景中的待检查资源；其中，多个待检查资源用于被检查是否包括异常资源。

在一些实施例中，检查策略的数量包括多个；虚拟场景中的资源处理装置455还包括遍历模块，用于：遍历多个检查策略；其中，遍历到的检查策略用于确定虚拟场景中的待检查资源；当根据遍历到的检查策略确定的待检查资源的数量为零时，继续遍历下一个检查策略。

在一些实施例中，匹配模块4553，还用于：针对虚拟场景中的每个资源执行以下处理：当资源对应待筛选属性的匹配结果为匹配成功时，将资源作为待检查资源；当资源对应待筛选属性的匹配结果为匹配失败时，忽略资源。

在一些实施例中，策略设置操作包括选中操作以及条件设置操作；获取模块4551，还用于：在资源处理界面中呈现多种属性；响应于针对多种属性的选中操作，将被选中的属性的名称作为待检查属性的名称；响应于针对待检查属性的条件设置操作，获取针对待检查属性设置的属性值条件。

在一些实施例中，获取模块4551，还用于：在资源处理界面中呈现多种筛选条件；其中，筛选条件包括资源类型以及资源所属模块中的至少一种；虚拟场景包括多个模块，且每个模块包括多个资源；响应于针对多种筛选条件的选中操作，呈现与被选中的筛选条件匹配成功的资源的多种属性。

在一些实施例中，映射模块4552，还用于：根据待检查属性的名称，将位于虚拟场景、且与被选中的筛选条件匹配成功的资源的待检查属性，映射为可调用对象。

在一些实施例中，匹配模块4553，还用于：针对虚拟场景中的每个资源执行以下处理：当资源对应待检查属性的匹配结果为匹配成功时，忽略资源；当资源对应待检查属性的匹配结果为匹配失败时，将资源作为异常资源。

在一些实施例中，更新模块4554，还用于：确定异常资源对应待检查属性的属性值与待检查属性对应的属性值条件之间的差异程度；根据差异程度确定异常资源对应的风险等级；在资源处理界面中呈现多个异常资源，且对应不同风险等级的异常资源的呈现方式不同。

在一些实施例中，更新模块4554，还用于：在资源处理界面中呈现异常资源、以及异常资源的异常修复选项；响应于针对异常修复选项的触发操作，对异常资源对应待检查属性的属性值进行更新处理，以使更新后的属性值与待检查属性对应的属性值条件匹配成功。

在一些实施例中，检查策略的数量包括多个，且每个检查策略对应一种风险等级；虚拟场景中的资源处理装置455还包括遍历模块，用于：遍历多个检查策略；其中，遍历到的检查策略用于确定虚拟场景中的异常资源；更新模块4554，还用于：在资源处理界面中呈现多个异常资源，且对应不同风险等级的异常资源的呈现方式不同；其中，异常资源对应的风险等级为用于确定异常资源的检查策略对应的风险等级。

在一些实施例中，虚拟场景中的资源处理装置455还包括属性复用模块，用于：响应于针对虚拟场景中的任意一种资源类型的属性复用操作，将父资源的属性复用至子资源中；其中，父资源为虚拟场景中与任意一种资源类型匹配成功的资源；子资源为虚拟场景中区别于父资源的资源。

在一些实施例中，虚拟场景中的资源处理装置455还包括策略复用模块，用于：响应于针对虚拟场景中的任意一种属性的策略复用操作，将检查策略中的待检查属性的名称替换为任意一种属性的名称，并将待检查属性对应的属性值条件作为任意一种属性的属性值条件，以得到新的检查策略。

在一些实施例中，映射模块4552，还用于：获取虚拟场景中的白名单资源；根据待检查属性的名称，将位于虚拟场景、且区别于白名单资源的资源的待检查属性映射为可调用对象。

在一些实施例中，更新模块4554，还用于：在资源处理界面中呈现异常资源、以及虚拟场景中区别于异常资源的资源，且异常资源与区别于异常资源的资源的呈现方式不同。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的虚拟场景中的资源处理方法。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图5A、图5B、图5C及图5D示出的虚拟场景中的资源处理方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。