RigidBody<\/strong><\/li>\n<\/ul>\nLos Rigidbody, se utilizan normalmente para a\u00f1adir peso a un objeto. Si un objeto tiene un RigidBody adjunto, puede verse afectado por la f\u00edsica, como la gravedad y otras fuerzas.<\/p>\n
Es importante tener en cuenta que tener demasiados objetos Rigidbody dentro de su juego afectar\u00e1 negativamente al rendimiento. Reducirlos a la cantidad m\u00ednima que necesita es el primer paso. Tambi\u00e9n puedes mejorar el rendimiento de los Rigidbodies que est\u00e1 utilizando determinando cu\u00e1ndo deben dormir o kinematic.<\/p>\n
Optimizar el c\u00f3digo<\/h2>\n
Cuando creamos nuestro juego, Unity empaqueta todo lo necesario para ejecutar nuestro juego en un programa que puede ser ejecutado por nuestro dispositivo objetivo. Las CPU solo pueden ejecutar c\u00f3digo escrito en lenguajes muy simples conocidos como c\u00f3digo m\u00e1quina o c\u00f3digo nativo; no pueden ejecutar c\u00f3digo escrito en lenguajes m\u00e1s complejos como C #. Esto significa que Unity debe traducir nuestro c\u00f3digo a otros idiomas. Este proceso de traducci\u00f3n se llama compilaci\u00f3n.<\/p>\n
El c\u00f3digo que a\u00fan no se ha compilado se conoce como c\u00f3digo fuente. El c\u00f3digo fuente que escribimos determina la estructura y el contenido del c\u00f3digo compilado.<\/p>\n
En su mayor parte, el c\u00f3digo fuente bien estructurado y eficiente dar\u00e1 como resultado un c\u00f3digo compilado bien estructurado y eficiente. Sin embargo, es \u00fatil para nosotros saber un poco sobre el c\u00f3digo nativo para que podamos entender mejor por qu\u00e9 algunos c\u00f3digos fuente se compilan en un c\u00f3digo nativo m\u00e1s eficiente.<\/p>\n
En primer lugar, algunas instrucciones de la CPU tardan m\u00e1s en ejecutarse que otras. Un ejemplo de esto es calcular una ra\u00edz cuadrada. Este c\u00e1lculo requiere m\u00e1s tiempo para que la CPU se ejecute que, por ejemplo, multiplicar dos n\u00fameros. La diferencia entre una sola instrucci\u00f3n de CPU r\u00e1pida y una sola instrucci\u00f3n de CPU lenta es muy peque\u00f1a, pero es \u00fatil para nosotros entender que, fundamentalmente, algunas instrucciones son simplemente m\u00e1s r\u00e1pidas que otras.<\/p>\n
Saque el c\u00f3digo de los bucles cuando sea posible<\/h2>\n
Los bucles son un lugar com\u00fan para que se produzcan ineficiencias, especialmente cuando est\u00e1n anidados. Las ineficiencias pueden sumarse si est\u00e1n en un bucle que se ejecuta con mucha frecuencia, especialmente si este c\u00f3digo se encuentra en muchos GameObjects de nuestro juego.<\/p>\n
En el siguiente ejemplo simple, nuestro c\u00f3digo itera a trav\u00e9s del ciclo cada vez que se llama a Update() , independientemente de si se cumple la condici\u00f3n.<\/p>\n
void Update()\r\n{\r\n for (int i = 0; i < myArray.Length; i++)\r\n {\r\n if (ejemploBool)\r\n {\r\n EjemploFuncion(myArray[i]);\r\n }\r\n }\r\n}<\/pre>\nPodemos mejorar el c\u00f3digo, itera a trav\u00e9s del ciclo solo si se cumple la condici\u00f3n.<\/p>\n
void Update()\r\n{\r\n if (ejemploBool)\r\n {\r\n for (int i = 0; i < myArray.Length; i++)\r\n {\r\n EjemploFuncion(myArray[i]);\r\n }\r\n }\r\n}<\/pre>\nEste es un ejemplo simplificado, pero ilustra un ahorro real que podemos hacer. Deber\u00edamos examinar nuestro c\u00f3digo en busca de lugares en los que hemos estructurado mal nuestros bucles.<\/p>\n
Considere si el c\u00f3digo debe ejecutar cada fotograma<\/h2>\n
Update () es una funci\u00f3n que Unity ejecuta una vez por fotograma. Update () es un lugar conveniente para colocar el c\u00f3digo que debe llamarse con frecuencia o el c\u00f3digo que debe responder a cambios frecuentes. Sin embargo, no es necesario que todo este c\u00f3digo ejecute todos los fotogramas. Sacar el c\u00f3digo de Update () para que se ejecute solo cuando sea necesario puede ser una buena forma de mejorar el rendimiento.<\/p>\n
Ejecute c\u00f3digo solo cuando las cosas cambien<\/h2>\n
Veamos un ejemplo muy simple de optimizaci\u00f3n de c\u00f3digo para que solo se ejecute cuando las cosas cambien. En el siguiente c\u00f3digo, Ense\u00f1arScore () se llama en Update () . Sin embargo, es posible que el valor de la puntuaci\u00f3n no cambie con cada fotograma. Esto significa que estamos llamando innecesariamente a Ense\u00f1arScore () .<\/p>\n
private int score;\r\npublic void SubirScore(int scoreExtra)\r\n{\r\n score += scoreExtra;\r\n}\r\nvoid Update()\r\n{\r\n Ense\u00f1arScore(score);\r\n}<\/pre>\nCon un simple cambio, ahora nos aseguramos de que Ense\u00f1arScore () se llame solo cuando el valor de la puntuaci\u00f3n haya cambiado.<\/p>\n
private int score;\r\npublic void SubirScore(int scoreExtra)\r\n{\r\n score += scoreExtra;\r\n Ense\u00f1arScore(score);\r\n}\r\n\r\n<\/pre>\nUsar almacenamiento en cach\u00e9<\/h2>\n
Si nuestro c\u00f3digo llama repetidamente a funciones costosas que devuelven un resultado y luego descarta esos resultados, esta puede ser una oportunidad para la optimizaci\u00f3n. El almacenamiento y la reutilizaci\u00f3n de referencias a estos resultados puede resultar m\u00e1s eficaz. Esta t\u00e9cnica se conoce como almacenamiento en cach\u00e9 .<\/p>\n
En Unity, es com\u00fan llamar a GetComponent () para acceder a los componentes. En el siguiente ejemplo, llamamos a GetComponent () en Update () para acceder a un componente de Renderer antes de pasarlo a otra funci\u00f3n. Este c\u00f3digo funciona, pero es ineficaz debido a la llamada repetida a GetComponent () .<\/p>\n
void Update()\r\n{\r\n \u00a0 Renderer myRenderer = GetComponent<Renderer>();\r\n \u00a0 ExampleFunction(myRenderer);\r\n}<\/pre>\nEl siguiente c\u00f3digo llama a GetComponent () solo una vez, ya que el resultado de la funci\u00f3n se almacena en cach\u00e9. El resultado almacenado en cach\u00e9 se puede reutilizar en Update () sin m\u00e1s llamadas a GetComponent () .<\/p>\n
private Renderer myRenderer;\r\nvoid Start()\r\n{\r\n myRenderer = GetComponent<Renderer>();\r\n}\r\nvoid Update()\r\n{\r\n ExampleFunction(myRenderer);\r\n}<\/pre>\nDeber\u00edamos examinar nuestro c\u00f3digo en busca de casos en los que hacemos llamadas frecuentes a funciones que devuelven un resultado. Es posible que podamos reducir el costo de estas llamadas utilizando el almacenamiento en cach\u00e9.<\/p>\n
Usar Object Pooling<\/h2>\n
Por lo general, es m\u00e1s costoso crear una instancia y destruir un objeto que desactivarlo y reactivarlo. Esto es especialmente cierto si el objeto contiene c\u00f3digo de inicio, como llamadas a GetComponent () en una funci\u00f3n Awake () o Start (). Si necesitamos generar y deshacernos de muchas copias del mismo objeto, como balas en un juego de disparos, entonces podemos beneficiarnos de la Object Pooling .<\/strong><\/p>\nEl object Pooling<\/strong> es una t\u00e9cnica en la que, en lugar de crear y destruir instancias de un objeto, los objetos se desactivan temporalmente y luego se reciclan y reactivan seg\u00fan sea necesario. Aunque es una t\u00e9cnica muy conocida para administrar el uso de la memoria, object pooling<\/strong> tambi\u00e9n puede ser \u00fatil como t\u00e9cnica para reducir el uso excesivo de la CPU.<\/p>\n
![\"\"](\"https:\/\/www.espai.es\/blog\/wp-content\/uploads\/2021\/09\/Profiler.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/www.espai.es\/blog\/wp-content\/uploads\/2021\/09\/textureatlas.png\")
<\/a><\/p>\n