本地资源检测自定义规则零基础上手指南

本地资源检测是UWA推出的、面向于静态资源的全量分析。可以全面自动检测项目静态工程内各项资源、代码和设置，能够帮助项目组制定合理的资源与代码标准，及时发现潜在的性能问题和异常错误，建立有效的开发规范。其中“自定义规则”功能特别获得了开发者的好感，因为大量特定或复杂的检测需求得到了满足！

下面我们用示例来介绍“UWA本地资源检测-自定义规则”功能的操作步骤，学会它只是10分钟的事情！

一、搭建框架

为了将检测需求转化为本地资源检测中的规则，我们在使用“自定义规则”功能时，就需要遵循特定的规范，以确保检测规则的正常运行以及报告中问题资源信息的正常展示。

首先，我们需要在项目中任意一个Editor目录下新建一个C#脚本文件。

接着，打开文件进行编辑。我们会发现有部分不涉及到检测逻辑实现的代码，这些代码可以直接按照下图先拷贝进去。其中包括必须引用的一个命名空间、必须实现的一个接口以及必须实现的四个方法。

一个命名空间

“using xxx”：可以简单理解为某种使用声明，当后续我们使用到某些存在其中的功能时，程序就能根据这些声明找到功能所对应的命名空间，从而确保功能的正常使用。

“UwaProjScan.ScanRule.CustomRules”：是使用“自定义规则”功能所必须要引用的一个命名空间。

实现接口

“ICustomRule”，是使用“自定义规则”功能所必须实现的一个接口。大家可以自行进一步查阅C#中，"类的继承"和"接口的实现"的相关知识和区别。

四个实现方法

这里的“Description”、“Id”、“Priority”和“Run”，就是使用“自定义规则”功能所必须实现的四个方法。这四个方法最主要的功能是决定了所编辑的自定义规则，以及在本地资源检测报告中的各类关键信息，包括规则的名称、Id、优先级和问题资源的展示等。

至此，使用“自定义规则”功能的框架已经完成搭建。

二、报告内容展示

在第一部分，我们已经为大家详细展示了正常使用“自定义规则”功能所要搭建的“框架”，大家可以直接复用到自己的脚本中。

但是我们会发现，图中在方法public bool Run(out bool hasTable, out RuleDataTable table){}内，却并没有展示功能主体的代码。这是因为本地资源检测报告中，规则检测结果的展示有两种情况，我们分别讲解一下。

不需要在报告中展示信息统计表格

一般适用于简单的二项选择，比如判断某个选项开了还是没开。或者某个地方有没有设置成固定的数值等。

如图，我们实现了自定义规则关于“项目工程中，公司名称是否为UWA”的判断。其中：

hasTable=false和table=null这两个参数的设置，决定了这条规则的检测结果在报告中不展示信息统计表格；
return的返回值为true或false，决定了当前自定义规则的检测显示为“通过”或者“失败”；
“PlayerSettings.companyName”是UnityEditor中提供的已有接口，可以直接获取Unity工程中，Edit-Project Settings-Company Name中的值。Unity和C#中都大量提供了这类接口，在编辑检测逻辑时，很多想要实现的功能，我们都可以通过这些接口直接调用，从而节省大量精力时间。

此时，当Company Name等于我们设定的期望值"UWA"，检测报告就会如下展示：

而当Company Name和我们设定的期望值不符，检测报告则如下展示：

需要在报告中展示信息统计表格

当我们根据一定条件，筛选出了一批不符合要求的资源、代码时，报告里需要用表格展示出相应的统计信息，比如资源名称、所在路径、大小、某些多选项属性的具体选择等，从而方便项目成员按图索骥，进行定位和修改。

如图，依然是实现自定义规则关于“项目工程中，公司名称是否为UWA”的判断，但是我们希望在发现公司名称不一致的同时，能从报告中获取相关的详细信息：

建立表格

此处table和hasTable的参数设置，决定了这条规则的检测结果会在报告中以表格的形式展示出问题资源的相关信息。

其中table=new RuleDataTable(参数1，参数2，参数N)，参数的值和数量，会决定报告中表格的列数和每一列的名字，参数最少2个，最多6个；

活用API

Unity中已经预制了很多功能，方便大家在需要时灵活调用。这里我们获取项目工程中公司名、产品名和版本号的办法，就是通过命名空间“UnityEditor”和“UnityEngine”中已有的功能来实现的，所以在文件的开头，我们要按照“using xxx”的样式写好对这两个命名空间的引用说明。

填充表格

table.AddRow(参数1，参数2，参数N)，这个方法可以实现往统计表格里加入新的一行，参数最少2个，最多6个。

这里要注意：AddRow的参数数量，一定要和RuleDataTable的参数数量保持一致，不然会有如下报错。

报告展示

如此，我们就完成了报告中问题资源统计展示的准备。以本例来讲，当项目公司名与实际不符时，我们就能在报告中看到更详细的信息：

三、检测逻辑的构建与实现

逻辑设计：由大化小

在上一部分的例子中，我们只是简单地判断和获取公司名称等信息，而在实际使用中，可能很多检测需求的描述很简单，但其实际的功能实现却较为复杂，要考虑到场景、设置、属性等多方面因素，才能正确筛选出问题资源或代码等。

比如我们在项目初期引进的一套资源出了问题，包含纹理、粒子系统、Prefab等各方面，我们的检测需求是把这套资源全部找出来。此时我们就可以考虑“由大化小”的逻辑设计，将“找出项目中这套全部的资源”这个最终目的，分解为一个个小的、容易实现的过程或者中间目标。

这样，我们就把比较抽象的大目标，转化为一个个具象化的小目标。在逻辑实现上，单独实现每一个小目标就能简单得多：比如利用命名中已知的某些关键字去筛选纹理，或者根据名称中带有的固定格式(比如日期xxxx_xx_xx)去筛选Prefab等。相应地，在各个小目标的代码实现上，无论是查找已有API，还是创建方法，我们也能有更清晰的思路。

代码编写：合理借力

对于零基础的初学者而言，编写代码实现“c=a+b”可能也要稍费一番功夫。所以在有足够的知识积累能够轻松编写功能实现之前，我们可以充分利用Unity/C#中已经实现的各项功能接口，以此大幅减轻代码编写的压力，尽早将“自定义规则”功能实现运用到实际检测中。

Unity和C#都有大量的现成接口，方便项目团队对工程资源、设置等进行信息获取和操作。在此我们就举个简单的例子——“找出项目中尺寸过大的图片资源”。

根据在上文提到的逻辑设计，我们要将其分解为易于理解和实现的小目标：“查找资源”、“筛选资源”和“展示资源”。

进一步思考，我们还能得出更详细的方面：

目标是图片资源，要实现相应的查找，可以考虑是否要指定一个查找范围；
特征是图片尺寸过大，所以我们要设置一个阈值便于后续的对比和筛选；
要获取图片的宽、高信息，从而实现和阈值的对比；
最终报告里的输出，要方便成员进行查找，所以要有资源名称、路径、宽、高等信息。

如此，我们就可以进一步查找Unity/C#的相关文档，看看是否存在相应的API接口可以满足我们的需求，最终实现了下图的代码。

这其中：
第一，确立报告中表格的输出内容，包含资源的名称、路径、高度和宽度。

第二，AssetDatabase.FindAssets，是Unity中已有的API接口（要记得在最开头写using UnityEditor），可以根据给定文件路径去筛选指定类型的资源。这里要注意的是，它找到的是资源的GUID，所以数组GuidPath中存放的是资源的GUID，而不是资源名称等直观信息。

第三，我们要对数组GuidPath中的每一个对象，都进行相应的信息获取和尺寸对比，所以在这里写了个循环。

第四，图片资源的路径、名称、宽度、高度等信息的获取，都是利用Unity/C#已有的接口来实现的，大幅节省了我们在代码编写上的投入。这里大家要记得在文件开头写好对应的“using xxx”，确保这些功能的正常使用。

有时一个功能可以有多个不同的接口来实现，但我们需要根据实际需求去选择其中最合适的一种。比如图中的System.Drawing.Imaging.Metafile.FromFile，可以获取原始图片的大小。但在实际使用中，我们要获取Unity导入后的图片大小，这样才能使检测结果更符合要求。此时我们就可以通过"Texture2D texture = AssetDatabase.LoadAssetAtPath(path)"来获取图片的宽高数据。

第五，后面的if判断，主要就是根据获得的图片宽高信息去与设置的阈值进行对比，将不符合阈值要求的图片资源信息输出到报告中，在此不多赘述。

通过上述所有代码提供的功能，我们就找出了潜藏在工程里的“不合格资源”：