La detección de recursos locales es un análisis completo de los recursos estáticos lanzados por UWA. Puede detectar completa y automáticamente varios recursos, códigos y configuraciones en el proyecto estático del proyecto, y puede ayudar al equipo del proyecto a formular estándares de código y recursos razonables, descubrir posibles problemas de rendimiento y errores anormales a tiempo, y establecer especificaciones de desarrollo efectivas. Entre ellos, la función de "reglas personalizadas" es particularmente favorecida por los desarrolladores, ¡porque se ha satisfecho una gran cantidad de necesidades de detección específicas o complejas!
A continuación, usamos un ejemplo para presentar los pasos de operación de la función "Detección de recursos locales de UWA: reglas personalizadas", ¡y solo toma 10 minutos aprenderlo!
1. Construya un marco
Para convertir los requisitos de detección en reglas en la detección de recursos locales, debemos seguir especificaciones específicas al usar la función de "reglas personalizadas" para garantizar el funcionamiento normal de las reglas de detección y la visualización normal de la información de recursos problemáticos en los informes.
Primero, necesitamos crear un nuevo archivo de script C# en cualquier directorio del Editor en el proyecto.
A continuación, abra el archivo para editarlo. Encontraremos que hay algunos códigos que no involucran la implementación de la lógica de detección, estos códigos se pueden copiar directamente de acuerdo con la figura a continuación. Estos incluyen un espacio de nombres al que se debe hacer referencia, una interfaz que se debe implementar y cuatro métodos que se deben implementar .
un espacio de nombres
"usando xxx": Puede entenderse simplemente como algún tipo de declaración de uso. Cuando usamos algunas funciones que existen en él más adelante, el programa puede encontrar el espacio de nombres correspondiente a la función de acuerdo con estas declaraciones, para garantizar el uso normal. de la función
"UwaProjScan.ScanRule.CustomRules": Es un espacio de nombres al que se debe hacer referencia cuando se utiliza la función "Reglas personalizadas".
implementar la interfaz
"ICustomRule" es una interfaz que debe implementarse para usar la función "Regla personalizada". Puede verificar aún más el conocimiento relevante y las diferencias entre "herencia de clase" e "implementación de interfaz" en C#.
Cuatro métodos de implementación
La "Descripción", "Id", "Prioridad" y "Ejecutar" aquí son los cuatro métodos que deben implementarse para usar la función "Reglas personalizadas". La función principal de estos cuatro métodos es determinar las reglas personalizadas editadas y diversa información clave en el informe de detección de recursos locales, incluido el nombre de la regla, la identificación, la prioridad y la visualización de los recursos problemáticos.
Hasta ahora, se ha completado el marco para usar la función "Reglas personalizadas".
2. Visualización del contenido del informe
En la primera parte, hemos mostrado en detalle el "marco" que se construirá para el uso normal de la función de "reglas personalizadas", y puede reutilizarlo directamente en sus propios scripts.
Pero encontraremos que en el método public bool Run(out bool hasTable, out RuleDataTable table){} en la figura, el código del cuerpo principal de la función no se muestra. Esto se debe a que en el informe de detección de recursos locales, hay dos situaciones en las que se muestran los resultados de la detección de reglas y las explicaremos por separado.
No es necesario mostrar la tabla de estadísticas de información en el informe
Generalmente se aplica a elecciones binomiales simples, como juzgar si una opción está habilitada o deshabilitada. O hay un valor fijo en alguna parte.
Como se muestra en la figura, hemos implementado una regla personalizada para juzgar "si el nombre de la empresa es UWA en el proyecto del proyecto". en:
- La configuración de los dos parámetros hasTable=false y table=null determina que el resultado de la detección de esta regla no mostrará la tabla de estadísticas de información en el informe;
- El valor de retorno de return es true o false , lo que determina si la detección de la regla personalizada actual se muestra como "aprobado" o "fallido";
- " PlayerSettings.companyName " es una interfaz existente proporcionada en UnityEditor, que puede obtener directamente el valor en Editar-Configuración del proyecto-Nombre de la empresa en el proyecto de Unity. Tanto Unity como C# proporcionan una gran cantidad de interfaces de este tipo. Al editar la lógica de detección, podemos llamar directamente a muchas de las funciones que queremos lograr a través de estas interfaces, ahorrando así mucha energía y tiempo.
En este punto, cuando el Nombre de la empresa sea igual al valor esperado "UWA" que configuramos, el informe de la prueba se mostrará de la siguiente manera:
Y cuando el nombre de la empresa no coincida con las expectativas que establecimos, el informe de la prueba se mostrará de la siguiente manera:
Necesita mostrar la tabla de estadísticas de información en el informe
Cuando filtramos un lote de recursos y códigos que no cumplen con los requisitos según ciertas condiciones, el informe debe mostrar la información estadística correspondiente en una tabla, como el nombre del recurso, la ruta, el tamaño, la selección específica de alguna opción múltiple. atributos, etc., para que sea conveniente para los miembros del proyecto ubicar y modificar de acuerdo con el mapa.
Como se muestra en la figura, todavía es necesario realizar el juicio de "si el nombre de la empresa es UWA en el proyecto del proyecto" mediante reglas personalizadas, pero esperamos que cuando encontremos que el nombre de la empresa es inconsistente, podamos obtener detalles relevantes. información del informe:
- crear formulario
La configuración de parámetros de table y hasTable aquí determina que el resultado de detección de esta regla mostrará la información relevante del recurso problemático en forma de tabla en el informe.
Entre ellos, table =new RuleDataTable (parámetro 1, parámetro 2, parámetro N), el valor y la cantidad de los parámetros determinarán el número de columnas en la tabla y el nombre de cada columna en el informe. Los parámetros son al menos 2 y como máximo 6;
- API de utilización
Muchas funciones han sido prefabricadas en Unity, lo cual es conveniente para que todos puedan llamar de manera flexible cuando sea necesario. Aquí obtenemos el nombre de la empresa, el nombre del producto y el número de versión en el proyecto del proyecto a través de las funciones existentes en el espacio de nombres "UnityEditor" y "UnityEngine", por lo que al comienzo del archivo, debemos seguir "usando xxx" El estilo escribe referencias a estos dos espacios de nombres.
- llenar formulario
table.AddRow (parámetro 1, parámetro 2, parámetro N), este método puede agregar una nueva fila a la tabla estadística, con al menos 2 parámetros y como máximo 6 parámetros.
Tenga en cuenta aquí: la cantidad de parámetros de AddRow debe ser consistente con la cantidad de parámetros de RuleDataTable , de lo contrario, se informará el siguiente error.
- pantalla de informe
De esta forma, hemos completado la preparación para la visualización estadística de los recursos problemáticos en el informe. En este ejemplo, cuando el nombre de la empresa del proyecto no coincide con el real, podemos ver información más detallada en el informe:
3. Construcción e implementación de la lógica de detección
Diseño lógico: de grande a pequeño
En el ejemplo de la parte anterior, simplemente juzgamos y obtuvimos información como el nombre de la empresa. En el uso real, la descripción de muchos requisitos de detección puede ser muy simple, pero la realización de la función real es más complicada. Teniendo en cuenta la escena, el entorno, atributos y muchos otros factores, para descartar correctamente recursos o códigos problemáticos, etc.
Por ejemplo, hay un problema con un conjunto de recursos que introdujimos al comienzo del proyecto, incluidas texturas, sistemas de partículas, prefabricados, etc. Nuestro requisito de detección es descubrir todo este conjunto de recursos. En este momento, podemos considerar el diseño lógico de "de grande a pequeño" y descomponer el objetivo final de "encontrar todos los recursos en el proyecto" en pequeños procesos u objetivos intermedios fáciles de lograr.
De esta forma, transformamos los grandes objetivos más abstractos en pequeños objetivos concretos. En términos de implementación lógica, es mucho más simple lograr cada pequeño objetivo de forma independiente: por ejemplo, usar ciertas palabras clave conocidas en el naming para filtrar texturas, o filtrar Prefabs según el formato fijo (como la fecha xxxx_xx_xx) en el nombre, etc. . . En consecuencia, en la implementación del código de cada objetivo pequeño, ya sea buscando API existentes o creando métodos, también podemos tener una idea más clara.
Escritura de código: apalancamiento razonable
Para principiantes con base cero, puede tomar un poco de esfuerzo escribir código para realizar "c = a + b". Por lo tanto, antes de que tengamos suficiente conocimiento acumulado para escribir fácilmente implementaciones de funciones, podemos hacer un uso completo de las interfaces funcionales que se han implementado en Unity/C#, para reducir en gran medida la presión de escribir código e implementar las "reglas personalizadas". funcionar lo antes posible En pruebas reales.
Tanto Unity como C# tienen una gran cantidad de interfaces listas para usar, que son convenientes para que el equipo del proyecto obtenga y opere información sobre recursos y configuraciones de ingeniería. Aquí damos un ejemplo simple: "Encuentre los recursos de imagen de gran tamaño en el proyecto".
De acuerdo con el diseño lógico mencionado anteriormente, debemos descomponerlo en pequeños objetivos que sean fáciles de entender y lograr: "buscar recursos", "filtrar recursos" y "mostrar recursos".
Pensando más allá, también podemos dibujar aspectos más detallados:
- El objetivo es un recurso de imagen Para lograr la búsqueda correspondiente, puede considerar si desea especificar un rango de búsqueda;
- La característica es que el tamaño de la imagen es demasiado grande, por lo que debemos establecer un umbral para facilitar la comparación y el cribado posteriores;
- Obtener la información de ancho y alto de la imagen, para realizar la comparación con el umbral;
- El resultado en el informe final debe ser conveniente para que los miembros busquen, por lo que debe haber información como el nombre del recurso, la ruta, el ancho y la altura.
De esta manera, podemos seguir buscando documentos relevantes de Unity/C# para ver si hay una interfaz API correspondiente que pueda satisfacer nuestras necesidades y finalmente realizar el código en la figura a continuación.
Entre ellos:
Primero, establezca el contenido de salida de la tabla en el informe, incluido el nombre, la ruta, la altura y el ancho del recurso.
En segundo lugar, AssetDatabase.FindAssets es una interfaz API existente en Unity (recuerde escribir usando UnityEditor al principio), que puede filtrar recursos de un tipo específico según una ruta de archivo dada. Cabe señalar aquí que lo que encuentra es el GUID del recurso, por lo que el GUID del recurso se almacena en la matriz GuidPath, no la información intuitiva, como el nombre del recurso.
En tercer lugar, necesitamos obtener la información correspondiente y comparar los tamaños de cada objeto en la matriz GuidPath, por lo que escribimos un ciclo aquí.
En cuarto lugar, la adquisición de información como la ruta, el nombre, el ancho y la altura de los recursos de imagen se realiza mediante el uso de las interfaces existentes de Unity/C#, lo que ahorra en gran medida nuestra inversión en la escritura de código. Aquí, todos deben recordar escribir el correspondiente "usando xxx" al comienzo del archivo para garantizar el uso normal de estas funciones.
A veces, una función puede implementarse mediante múltiples interfaces diferentes, pero debemos elegir la más adecuada de acuerdo con las necesidades reales. Por ejemplo, System.Drawing.Imaging.Metafile.FromFile en la figura puede obtener el tamaño de la imagen original. Pero en el uso real, necesitamos obtener el tamaño de la imagen importada por Unity, para que el resultado de la detección esté más en línea con los requisitos. En este punto, podemos obtener los datos de ancho y alto de la imagen a través de "Texture2D texture = AssetDatabase.LoadAssetAtPath(path)".
En quinto lugar, el siguiente juicio si es principalmente para comparar la información de ancho y alto de la imagen obtenida con el umbral establecido, y generar la información de recursos de la imagen que no cumple con los requisitos del umbral para el informe, por lo que no entraré en detalles aquí.
A través de las funciones proporcionadas por todos los códigos anteriores, hemos encontrado los "recursos no calificados" ocultos en el proyecto:
Esta guía para principiantes espera permitirle comenzar rápidamente con el uso de la función de "reglas personalizadas" de detección de recursos locales. También puede comunicarse con UWA y enviar comentarios sobre sus necesidades adicionales para esta función, a fin de beneficiar a más desarrolladores.
Más referencias sobre la función de detección de recursos locales: ¡
Tengo la última palabra sobre las reglas! | Se inician las reglas personalizadas y
se inicia la función de configuración de umbral múltiple de regla única.
Se inicia la "Reparación automática".