Local resource detection is a full analysis of static resources launched by UWA. It can fully and automatically detect various resources, codes and settings in the static project of the project, and can help the project team formulate reasonable resource and code standards, discover potential performance problems and abnormal errors in time, and establish effective development specifications. Among them, the "custom rules" function is particularly favored by developers, because a large number of specific or complex detection needs have been met!
Below we use an example to introduce the operation steps of the "UWA Local Resource Detection - Custom Rules" function, and it only takes 10 minutes to learn it!
1. Build a framework
In order to convert detection requirements into rules in local resource detection, we need to follow specific specifications when using the "custom rules" function to ensure the normal operation of detection rules and the normal display of problem resource information in reports.
First, we need to create a new C# script file under any Editor directory in the project.
Next, open the file for editing. We will find that there are some codes that do not involve the implementation of the detection logic. These codes can be copied directly according to the figure below. These include a namespace that must be referenced, an interface that must be implemented, and four methods that must be implemented .
a namespace
"using xxx": It can be simply understood as some kind of usage declaration. When we use some functions that exist in it later, the program can find the namespace corresponding to the function according to these declarations, so as to ensure the normal use of the function.
"UwaProjScan.ScanRule.CustomRules": It is a namespace that must be referenced when using the "Custom Rules" function.
implement the interface
"ICustomRule" is an interface that must be implemented to use the "Custom Rule" function. You can further check the relevant knowledge and differences between "class inheritance" and "interface implementation" in C#.
Four implementation methods
The "Description", "Id", "Priority" and "Run" here are the four methods that must be implemented to use the "Custom Rules" function. The main function of these four methods is to determine the edited custom rules and various key information in the local resource detection report, including rule name, Id, priority, and display of problem resources.
So far, the framework for using the "Custom Rules" function has been completed.
2. Display of report content
In the first part, we have shown in detail the "framework" to be built for normal use of the "custom rules" function, and you can directly reuse it in your own scripts.
But we will find that in the method public bool Run(out bool hasTable, out RuleDataTable table){} in the figure, the code of the main body of the function is not displayed. This is because in the local resource detection report, there are two situations in which the rule detection results are displayed, and we will explain them separately.
There is no need to display the information statistics table in the report
It is generally applicable to simple binomial choices, such as judging whether an option is enabled or disabled. Or is there a fixed value somewhere.
As shown in the figure, we have implemented a custom rule to judge "whether the company name is UWA in the project project". in:
- The settings of the two parameters hasTable=false and table=null determine that the detection result of this rule will not display the information statistics table in the report;
- The return value of return is true or false , which determines whether the detection of the current custom rule is displayed as "pass" or "failure";
- " PlayerSettings.companyName " is an existing interface provided in UnityEditor, which can directly obtain the value in Edit-Project Settings-Company Name in the Unity project. Both Unity and C# provide a large number of such interfaces. When editing the detection logic, we can directly call many of the functions we want to achieve through these interfaces, thus saving a lot of energy and time.
At this point, when the Company Name is equal to the expected value "UWA" we set, the test report will be displayed as follows:
And when the Company Name does not match the expectations we set, the test report will be displayed as follows:
Need to display the information statistics table in the report
When we filter out a batch of resources and codes that do not meet the requirements according to certain conditions, the report needs to display the corresponding statistical information in a table, such as resource name, path, size, specific selection of some multi-option attributes, etc. , so that it is convenient for project members to locate and modify according to the map.
As shown in the figure, it is still necessary to realize the judgment of "whether the company name is UWA in the project project" by custom rules, but we hope that when we find that the company name is inconsistent, we can obtain relevant detailed information from the report:
- create form
The parameter settings of table and hasTable here determine that the detection result of this rule will display the relevant information of the problem resource in the form of a table in the report.
Among them, table =new RuleDataTable (parameter 1, parameter 2, parameter N), the value and quantity of the parameters will determine the number of columns in the table and the name of each column in the report. The parameters are at least 2 and at most 6;
- Utilization API
Many functions have been prefabricated in Unity, which is convenient for everyone to call flexibly when needed. Here we get the company name, product name and version number in the project project through the existing functions in the namespace "UnityEditor" and "UnityEngine", so at the beginning of the file, we need to follow the "using xxx" The style writes references to these two namespaces.
- fill form
table.AddRow (parameter 1, parameter 2, parameter N), this method can add a new row to the statistical table, with at least 2 parameters and at most 6 parameters.
Note here: The number of parameters of AddRow must be consistent with the number of parameters of RuleDataTable , otherwise the following error will be reported.
- report display
In this way, we have completed the preparation for the statistical display of problematic resources in the report. In this example, when the project company name does not match the actual one, we can see more detailed information in the report:
3. Construction and implementation of detection logic
Logic Design: From Big to Small
In the example in the previous part, we simply judged and obtained information such as the company name. In actual use, the description of many detection requirements may be very simple, but the actual function realization is more complicated. Considering the scene, setting , attributes and many other factors, in order to correctly screen out problematic resources or codes, etc.
For example, there is a problem with a set of resources we introduced at the beginning of the project, including textures, particle systems, prefabs, etc. Our detection requirement is to find out all this set of resources. At this time, we can consider the logical design of "from big to small", and decompose the ultimate goal of "finding all the resources in the project" into small, easy-to-achieve processes or intermediate goals.
In this way, we transform the relatively abstract big goals into concrete small goals. In terms of logical implementation, it is much simpler to achieve each small goal independently: for example, use certain keywords known in the naming to filter textures, or filter Prefabs according to the fixed format (such as date xxxx_xx_xx) in the name, etc. . Correspondingly, in the code implementation of each small goal, whether it is searching for existing APIs or creating methods, we can also have a clearer idea.
Code writing: reasonable leverage
For beginners with zero foundation, it may take a little effort to write code to realize "c=a+b". Therefore, before we have enough knowledge accumulation to easily write function implementations, we can make full use of the functional interfaces that have been implemented in Unity/C#, so as to greatly reduce the pressure of code writing, and implement the "custom rules" function as soon as possible. In actual testing.
Both Unity and C# have a large number of ready-made interfaces, which are convenient for the project team to obtain and operate information on engineering resources and settings. Here we give a simple example - "Find the oversized image resources in the project".
According to the logical design mentioned above, we need to decompose it into small goals that are easy to understand and achieve: "find resources", "filter resources" and "display resources".
Thinking further, we can also draw more detailed aspects:
- The target is an image resource. To achieve the corresponding search, you can consider whether to specify a search range;
- The feature is that the size of the picture is too large, so we need to set a threshold to facilitate subsequent comparison and screening;
- To obtain the width and height information of the picture, so as to realize the comparison with the threshold;
- The output in the final report should be convenient for members to search, so there should be information such as resource name, path, width, and height.
In this way, we can further search for relevant documents of Unity/C# to see if there is a corresponding API interface that can meet our needs, and finally realize the code in the figure below.
Among them:
First, establish the output content of the table in the report, including the name, path, height and width of the resource.
Second, AssetDatabase.FindAssets is an existing API interface in Unity (remember to write using UnityEditor at the beginning), which can filter resources of a specified type according to a given file path. It should be noted here that what it finds is the GUID of the resource, so the GUID of the resource is stored in the array GuidPath, not the intuitive information such as the resource name.
Third, we need to obtain corresponding information and compare sizes for each object in the array GuidPath, so we write a loop here.
Fourth, the acquisition of information such as the path, name, width, and height of image resources is realized by using the existing interfaces of Unity/C#, which greatly saves our investment in code writing. Here, everyone should remember to write the corresponding "using xxx" at the beginning of the file to ensure the normal use of these functions.
Sometimes a function can be implemented by multiple different interfaces, but we need to choose the most suitable one according to actual needs. For example, System.Drawing.Imaging.Metafile.FromFile in the figure can get the size of the original image. But in actual use, we need to obtain the size of the image imported by Unity, so as to make the detection result more in line with the requirements. At this point, we can get the width and height data of the image through "Texture2D texture = AssetDatabase.LoadAssetAtPath(path)".
Fifth, the subsequent if judgment is mainly to compare the obtained image width and height information with the set threshold, and output the image resource information that does not meet the threshold requirements to the report, so I won’t go into details here.
Through the functions provided by all the above codes, we have found the "unqualified resources" hidden in the project:
This novice guide hopes to let you quickly get started with the use of the "custom rules" function of local resource detection. You are also welcome to communicate with UWA and give feedback on your more needs for this function, so as to benefit more developers.
More references about the local resource detection function:
I have the final say on the rules! | Custom rules are launched, and
the single-rule multi-threshold setting function is launched.
"Automatic repair" is launched.