Recoge estos consejos útiles sobre perfilado avanzado
En junio, organizamos un seminario web con expertos de Arm, el equipo de Unity Studio Productions y SYBO Games, el creador de Subway Surfers. La mesa redonda resultante se centró en consejos y estrategias de perfilado para juegos móviles, las implicaciones comerciales de un rendimiento deficiente y cómo SYBO lanzó un juego móvil exitoso con 3 mil millones de descargas hasta la fecha.
Vamos a profundizar en algunas de las preguntas de seguimiento que no tuvimos tiempo de cubrir durante el seminario web. También puedes ver la grabación completa.
Escuchamos mucho sobre el Profiler de Unity en relación con el perfilado de CPU, pero no tanto sobre el Profile Analyzer (disponible como un paquete de Unity). ¿Hay planes para mejorarlo o integrarlo en el conjunto de herramientas del Profiler principal?
No hay planes inmediatos para integrar el Profile Analyzer en el Editor principal, pero esto podría cambiar a medida que nuestros herramientas de perfilado evolucionen.
¿Tiene Unity planes para agregar una opción para que el módulo de GPU Usage Profiler aparezca en porcentajes como lo hace en milisegundos?
Esa es una gran idea, y aunque no podemos decir sí o no en el momento de esta publicación del blog, es una solicitud que se ha compartido con nuestros equipos de I+D para posible consideración futura.
¿Tienes planes para abordar los errores de "Aplicación No Responde" (ANR) que son reportados por la tienda Google Play y no contienen ningún rastro de pila?
Aunque no tenemos planes específicos para rastrear ANR sin rastro de pila en este momento, lo consideraremos para la hoja de ruta futura.
¿Cómo puedo compartir mis comentarios para ayudar a influir en el desarrollo futuro de las herramientas de perfilado de Unity?
Puedes seguir las características próximas y compartir comentarios a través de nuestro tablero de productos y foros. También estamos realizando una encuesta para aprender más sobre la experiencia de nuestros clientes con las herramientas de perfilado. Si has utilizado herramientas de perfilado antes (ya sea a diario o solo una vez) o estás trabajando en un proyecto que requiere optimización, nos encantaría recibir tu opinión. La encuesta está diseñada para no tomar más de 5 a 10 minutos en completarse.
Al participar, también tendrás la oportunidad de optar por una entrevista de seguimiento para compartir más comentarios directamente con el equipo de desarrollo, incluida la oportunidad de discutir prototipos potenciales de nuevas características.
¿Hay una buena regla para determinar qué cuenta como un dispositivo de gama baja viable para apuntar?
Una regla general que escuchamos de muchos desarrolladores de juegos de Unity es apuntar a dispositivos que tengan cinco años de antigüedad en el momento del lanzamiento de su juego, ya que esto ayuda a garantizar la mayor base de usuarios. Pero también vemos equipos reduciendo su alcance de fecha de lanzamiento a dispositivos que solo tienen tres años si buscan una mayor calidad gráfica. Una aplicación 3D visualmente compleja, por ejemplo, tendrá requisitos de dispositivo más altos que una aplicación 2D simple. Este enfoque permite un "mínimo especificado" más alto, pero reduce el tamaño de la base de instalación inicial. Es esencialmente una decisión comercial: ¿Costará más desarrollar y dar soporte a dispositivos antiguos que lo que su juego ganará al ejecutarse en ellos?
A veces, los requisitos técnicos de su juego dictarán sus especificaciones mínimas de destino. Así que si su juego utiliza grandes cantidades de memoria de textura incluso después de la optimización, pero no puede reducir la calidad o la resolución, eso probablemente descarta la ejecución en teléfonos con memoria insuficiente. Si su solución de renderizado requiere sombreadores de cómputo, eso probablemente descarta dispositivos con controladores que no pueden soportar OpenGL ES 3.1, Metal o Vulkan.
Es una buena idea mirar los datos del mercado para su audiencia objetivo prioritaria. Por ejemplo, las especificaciones de dispositivos móviles pueden variar mucho entre países y regiones. Recuerde definir algunos "presupuestos" de destino para que los objetivos de referencia sobre lo que es aceptable se establezcan antes de elegir dispositivos de gama baja para las pruebas.
Para juegos de servicio en vivo que funcionarán durante años, necesitará monitorear su compatibilidad continuamente y adaptarse con el tiempo en función de su base de usuarios real y los dispositivos actuales en el mercado.
¿Es suficiente probar el rendimiento exclusivamente en dispositivos de gama baja para asegurar que el juego también funcionará sin problemas en los de gama alta?
Podría serlo, si tiene una carga de trabajo uniforme en todos los dispositivos. Sin embargo, aún necesita considerar las variaciones entre hardware de diferentes proveedores y/o versiones de controladores.
Es común que los juegos gráficamente ricos tengan niveles de fidelidad gráfica: cuanto mayor sea el nivel visual, más recursos se requieren en dispositivos capaces. Esta selección de niveles puede ser automática, pero cada vez más, los usuarios pueden controlar la elección a través de un menú de configuración gráfica. Para este estilo de desarrollo, necesitarás probar al menos un dispositivo objetivo de "especificaciones mínimas" por cada nivel de característica/carga de trabajo que tu juego soporte.
Si tu juego detecta las capacidades del dispositivo en el que se está ejecutando y adapta la salida gráfica según sea necesario, podría funcionar de manera diferente en dispositivos de gama alta. Así que asegúrate de probar en una variedad de dispositivos con los diferentes niveles de calidad para los que has programado el título.
Nota: En esta sección, hemos especificado si el experto que responde es de Arm o Unity.
¿Tienes algún consejo para detectar el rango de potencia de un dispositivo para soportar configuraciones de calidad automáticas, particularmente para móviles?
Arm: Normalmente vemos a los desarrolladores haciendo una clasificación de capacidades basada en modelos de CPU y GPU, así como en el conteo de núcleos de sombreado de la GPU. Esto nunca es perfecto, pero es "aproximadamente correcto". Muchos estudios recopilan análisis en vivo de dispositivos desplegados, para que puedan complementar la clasificación automatizada con opciones específicas del dispositivo para sortear problemas puntuales donde la clasificación de capacidades no es lo suficientemente precisa.
En relación con la pregunta anterior, para contenido gráficamente rico, vemos una tendencia en móviles hacia menús de configuración donde los usuarios pueden elegir activar o desactivar efectos, permitiéndoles así tomar decisiones de rendimiento que se adapten a sus preferencias.
Unity: La memoria del dispositivo y la resolución de pantalla también son factores importantes para elegir configuraciones de calidad. En cuanto a las texturas, los desarrolladores deben ser conscientes de que Texturas de Renderizado utilizadas por efectos o post-procesamiento pueden convertirse en un problema en dispositivos con pantallas de alta resolución, pero sin mucha memoria para igualar.
Dada la variedad de configuraciones disponibles (CPU, GPU, SOC, memoria, móvil, escritorio, consola, etc.), ¿puedes sugerir una forma de categorizar dispositivos para reducir el número de niveles que necesitas optimizar?
Arm: El número de niveles para los que tu equipo optimiza es realmente una decisión de diseño de juego y de negocio, y debe basarse en cuán importante es impulsar la calidad visual para la propuesta de valor del juego. Para algunos géneros puede no importar en absoluto, pero para otros, los usuarios tendrán altas expectativas sobre la fidelidad visual.
¿Difiere el límite de memoria de textura entre modelos y marcas de dispositivos Android que tienen la misma cantidad de memoria total del sistema?
Arm: Aproximadamente, esperaríamos que la cantidad total de memoria de textura sea similar entre proveedores y generaciones de hardware. Habrá diferencias menores causadas por la disposición de la memoria y las restricciones de alineación, por lo que no será exactamente lo mismo.
¿Es el uso de CPU o GPU el que más contribuye al sobrecalentamiento en dispositivos móviles?
Arm: Depende completamente del contenido. La CPU, la GPU o la DRAM pueden sobrecalentar individualmente un dispositivo de gama alta si se presionan lo suficiente, incluso si ignoras los otros dos por completo. El equilibrio exacto variará según la carga de trabajo que estés ejecutando.
¿Qué consejos puedes dar para el perfilado en dispositivos que tienen estrangulación térmica? ¿Qué margen apuntarías para evitar la estrangulación térmica (es decir, apuntar a 20 ms en lugar de 33 ms)?
Arm: Optimizar el tiempo de cuadro puede ser engañoso en Android porque los dispositivos ajustarán constantemente la frecuencia para optimizar el uso de energía, haciendo que el tiempo de cuadro sea una medida incompleta por sí sola. Preferiblemente, monitorea los ciclos de CPU y GPU por cuadro, así como el ancho de banda de memoria de GPU por cuadro, para obtener un valor que sea independiente de la frecuencia. El objetivo de ciclos que necesitas dependerá del diseño del chip de cada dispositivo, así que necesitarás experimentar.
Cualquier optimización ayuda cuando se trata de gestionar el consumo de energía, incluso si no mejora directamente la tasa de cuadros. Por ejemplo, reducir los ciclos de CPU reducirá la carga térmica incluso si la CPU no es el camino crítico para tu juego.
Más allá de eso, optimizar el ancho de banda de memoria es uno de los mayores ahorros que puedes hacer. Acceder a la DRAM es órdenes de magnitud más costoso que acceder a datos locales en el chip, así que cuida tu presupuesto de triángulos y mantén los tipos de datos en memoria lo más pequeños posible.
Unity: Para limitar el impacto de la frecuencia del reloj de la CPU en las métricas de rendimiento, recomendamos intentar operar a una temperatura constante. Hay un par de enfoques para hacer esto:
- Ejecutar caliente: Ejecuta el dispositivo durante un tiempo para que alcance un estado cálido estable antes de perfilar.
- Ejecutar enfriamiento: Deja el dispositivo enfriar durante un tiempo antes de perfilar. Esta estrategia puede eliminar la confusión y la inconsistencia en las sesiones de perfilado al tomar capturas que probablemente no estén limitadas térmicamente. Sin embargo, tales capturas siempre representarán el mejor rendimiento que un usuario verá en lugar de lo que realmente podría ver después de largas sesiones de juego. Esta estrategia también puede retrasar el tiempo entre las ejecuciones de perfilado debido a la necesidad de esperar primero el período de enfriamiento.
Con algunos hardware, puedes fijar la frecuencia del reloj para métricas de rendimiento más estables. Sin embargo, esto no es representativo de la mayoría de los dispositivos que tus usuarios estarán utilizando, y no reportará un rendimiento real preciso. Básicamente, es una técnica útil si estás utilizando una configuración de integración continua para verificar los cambios de rendimiento en tu base de código a lo largo del tiempo.
¿Alguna opinión sobre Vulkan vs OpenGL ES 3 en Android? Vulkan es generalmente más lento en términos de rendimiento. Al mismo tiempo, muchos dispositivos carecen de soporte para varias características en ES3.
Arm: Los controladores y las versiones de motor recientes han mejorado enormemente la calidad de las implementaciones de Vulkan disponibles; por lo tanto, para una carga de trabajo equivalente, no debería haber una brecha de rendimiento entre OpenGL ES y Vulkan (si la hay, háznoslo saber). El cambio a Vulkan está ganando velocidad y esperamos ver a más personas eligiendo Vulkan por defecto en el próximo año o dos. Si tienes contraejemplos de áreas donde Vulkan no está funcionando bien, por favor contáctanos. Nos encantaría saber de ti.
¿Qué herramientas podemos usar para monitorear el ancho de banda de memoria (RAM <-> VRAM)?
Arm: El Streamline Profiler en Arm Mobile Studio puede medir el ancho de banda entre GPUs Mali y la DRAM externa (o caché del sistema).
¿Deberías dividir los activos gráficos por niveles de dispositivo o resolución de dispositivo?
Arm: Puedes obtener el mejor resultado ajustando los activos, pero es caro hacerlo. Comienza reduciendo la resolución y la tasa de fotogramas, o desactivando algunos efectos de post-procesamiento opcionales.
¿Cuál es la mejor manera de registrar estadísticas de métricas de rendimiento de nuestra versión de desarrollo?
Arm: Puedes usar la herramienta Performance Advisor en Arm Mobile Studio para capturar y exportar automáticamente métricas de rendimiento de las GPU Mali, aunque esto viene con una advertencia: La generación de informes JSON requiere una licencia de Edición Profesional.
Unity: El Unity Profiler se puede usar para ver métricas de renderizado comunes, como el conteo de vértices y triángulos en el Módulo de Renderizado. Además, puedes incluir paquetes personalizados, como System Metrics Mali, en tu proyecto para agregar métricas de GPU Mali de bajo nivel al Unity Profiler.
¿Cuáles son tus recomendaciones para perfilar el código de los shaders?
Necesitas un GPU Profiler para hacer esto. El que elijas depende de tu plataforma objetivo. Por ejemplo, en dispositivos iOS, el GPU Profiler de Xcode incluye el Shader Profiler, que desglosa el rendimiento de los shaders línea por línea.
Arm Mobile Studio soporta Mali Offline Compiler, una herramienta de análisis estático para el código de shaders y núcleos de computación. Esta herramienta proporciona algunas estimaciones de rendimiento generales y recomendaciones para la familia de GPU Arm Mali.
Cuando perfiles, la regla general es probar tu juego o aplicación en el(los) dispositivo(s) objetivo(s). Con la industria moviéndose hacia más tipos de chipsets (Apple M1, Arm, x86 de Intel, AMD, etc.), ¿cómo pueden los desarrolladores perfilar y localizar problemas en las muchas configuraciones de hardware diferentes en un tiempo razonable?
La proliferación de chipsets es principalmente una preocupación en plataformas de escritorio. Hay un número limitado de arquitecturas de hardware para probar en juegos de consola. En móviles, está la serie A de Apple para dispositivos iOS y una gama de arquitecturas Arm y Qualcomm para Android, pero seleccionar una lista manejable de dispositivos móviles representativos es bastante sencillo.
En escritorio es más complicado porque hay una amplia gama de chipsets y arquitecturas disponibles, y comprar Macs y PCs para pruebas puede ser caro. Nuestro mejor consejo es hacer lo que puedas. Ningún estudio tiene tiempo y dinero infinitos para las pruebas. En general, no esperaríamos sorpresas enormes al comparar el rendimiento entre una CPU Intel x86 y un procesador AMD con especificaciones similares, por ejemplo. Mientras el juego funcione cómodamente en tu máquina de especificaciones mínimas, deberías sentirte razonablemente seguro sobre otras máquinas. También vale la pena considerar el uso de análisis, como Unity Analytics, para registrar tasas de fotogramas, especificaciones del sistema y configuraciones de opciones de los jugadores para identificar puntos críticos o configuraciones problemáticas.
Estamos viendo que más estudios se están moviendo a usar al menos algún nivel de pruebas automatizadas para el perfilado regular en el dispositivo, con estadísticas resumidas publicadas donde todo el equipo puede mantener un ojo en el rendimiento a través de la gama de dispositivos objetivo. Con escenas de prueba bien diseñadas, esto generalmente se puede convertir en un proceso mecánico que es adecuado para la automatización, por lo que no necesitas un artista técnico experimentado o un probador de QA ejecutando compilaciones a través del proceso manualmente.
¿Alguna vez ves problemas de rendimiento en dispositivos de gama alta que no ocurren en los de gama baja?
Es poco común, pero lo hemos visto. A menudo, el problema radica en cómo se configura el proyecto, como con el uso de sombreadores elegantes y texturas de alta resolución en dispositivos de gama alta, lo que puede ejercer presión adicional sobre la GPU o la memoria. A veces, un dispositivo móvil de gama alta o una consola utilizará una pantalla de teléfono de alta resolución o salida de TV 4K como un punto de venta, pero no necesariamente tendrá suficiente potencia de GPU o memoria para cumplir esa promesa sin una optimización adicional.
Si utilizas las versiones actuales del Sistema de Trabajo de C#, verifica si hay un costo de programación de trabajos que escala con el número de hilos de trabajo, que a su vez, escala con el número de núcleos de CPU. Esto puede resultar en un código que se ejecuta más lentamente en un Threadripper™ de 64+ núcleos que en una CPU modesta de 4 núcleos o 8 núcleos. Este problema se abordará en futuras versiones de Unity, pero mientras tanto, intenta limitar el número de hilos de trabajo de trabajos configurando JobsUtility.JobWorkerCount.
¿Cuáles son algunos consejos para establecer un buen presupuesto de fotogramas?
La mayor parte del tiempo cuando hablamos de presupuestos de fotogramas, estamos hablando del presupuesto de tiempo general para el fotograma. Calculas 1000/ fotogramas por segundo objetivo (fps) para obtener tu presupuesto de fotogramas: 33.33 ms para 30 fps, 16.66 ms para 60 fps, 8.33 ms para 120 Hz, etc. Reduce ese número en alrededor del 35% si estás en móvil para darle a los chips la oportunidad de enfriarse entre cada fotograma. Dividir el presupuesto para obtener subpresupuestos específicos para diferentes características y/o sistemas probablemente sea excesivo, excepto para proyectos con sistemas muy específicos y predecibles, o aquellos que hacen un uso intensivo de la segmentación temporal.
En general, el perfilado es el proceso de encontrar los mayores cuellos de botella, y por lo tanto, las mayores ganancias potenciales de rendimiento. Así que en lugar de decir, "La física está tomando 1.2 ms cuando el presupuesto solo permite 1 ms", podrías mirar un fotograma y decir, "El renderizado está tomando 6 ms, lo que lo convierte en el mayor costo de CPU del hilo principal en el fotograma." ¿Cómo podemos reducir eso?
Parece que el perfilado temprano y frecuente aún no es un conocimiento común. ¿Cuáles son tus pensamientos sobre por qué podría ser este el caso?
Construir, lanzar, promover y gestionar un juego es un trabajo difícil en múltiples frentes. Así que siempre habrá numerosas prioridades compitiendo por la atención de un desarrollador, y el perfilado puede quedar en el camino. Saben que es algo que deberían hacer, pero quizás no están familiarizados con las herramientas y no sienten que tienen tiempo para aprender. O, no saben cómo encajar el perfilado en sus flujos de trabajo porque están presionados hacia la finalización de características en lugar de la optimización del rendimiento.
Al igual que con los errores y la deuda técnica, los problemas de rendimiento son más baratos y menos arriesgados de abordar al principio, en lugar de más tarde en el ciclo de desarrollo de un proyecto. Nuestro enfoque es ayudar a desmitificar las herramientas y técnicas de perfilado para aquellos desarrolladores que no están familiarizados con ellas. Eso es lo que el e-book de perfilado y su entrada de blog relacionada y webinar pretenden apoyar.
¿Hay alguna manera de excluir ciertos métodos de la instrumentación o incluir solo métodos específicos al usar el perfilado profundo en el Unity Profiler? Al usar muchas tareas async/await, creamos grandes trazas de pila, pero ¿cómo podemos evitar ralentizar tanto al cliente como al Profiler al hacer perfilado profundo?
Puedes habilitar las pilas de llamadas de asignación para ver las pilas de llamadas completas que conducen a asignaciones gestionadas (mostradas en magenta en la vista de línea de tiempo del Unity CPU Profiler). Además, puedes – ¡y deberías! – instrumentar manualmente métodos y procesos de larga duración esparciendo ProfilerMarkers a lo largo de tu código. Actualmente no hay forma de habilitar automáticamente el perfilado profundo o deshabilitar el perfilado por completo en partes específicas de tu aplicación. Pero agregar manualmente ProfilerMarkers y habilitar las pilas de llamadas de asignación cuando sea necesario puede ayudarte a profundizar en áreas problemáticas sin tener que recurrir al perfilado profundo.
A partir de Unity 2022.2, también puedes usar nuestro IgnoredByDeepProfilerAttribute para evitar que el Unity Profiler capture llamadas a métodos. Simplemente agregue el atributo IgnoredByDeepProfiler a clases, estructuras y métodos.
¿Dónde puedo encontrar más información sobre Deep Profiling en Unity?
El Deep Profiling se cubre en nuestra documentación del Profiler. Luego está el recurso más completo y único para información de perfilado, el Guía definitiva para perfilar juegos de Unity e-book, que enlaza a la documentación relevante y otros recursos a lo largo.
¿Es correcto que el Deep Profiling solo es útil para el Allocations Profiler y que distorsiona tanto los resultados que no es útil para encontrar bloqueos en el juego?
El Deep Profiling se puede usar para encontrar las causas específicas de las asignaciones gestionadas, aunque las pilas de llamadas de asignación pueden hacer lo mismo con menos sobrecarga, en general. Al mismo tiempo, el Deep Profiling puede ser útil para investigar rápidamente por qué un ProfilerMarker específico parece estar tardando tanto, ya que es más conveniente habilitarlo que agregar numerosos ProfilerMarkers a sus scripts y reconstruir su juego. Pero sí, distorsiona el rendimiento bastante y no debería habilitarse para el perfilado general.
¿Vale la pena configurar VSync en cada VBlank? Mi juego móvil funciona a un fps muy bajo cuando está deshabilitado.
Los dispositivos móviles obligan a habilitar VSync a nivel de controlador/hardware, por lo que deshabilitarlo en la configuración de calidad de Unity no debería hacer ninguna diferencia en esas plataformas. No hemos oído de un caso donde deshabilitar VSync afecte negativamente el rendimiento. Intente tomar una captura de perfil con VSync habilitado, junto con otra captura de la misma escena pero con VSync deshabilitado. Luego compare las capturas usando Profile Analyzer para intentar entender por qué el rendimiento es tan diferente.
¿Cómo puede determinar si el hilo principal está esperando al GPU y no al revés?
Esto se cubre en la Guía definitiva para perfilar juegos de Unity. También puede obtener más información en la publicación del blog, Detectando cuellos de botella de rendimiento con el Unity Frame Timing Manager.
En términos generales, la señal reveladora es que el hilo principal espera al hilo de Render mientras que el hilo de Render espera al GPU. Los nombres de los marcadores específicos diferirán según su plataforma objetivo y API gráfica, pero debe estar atento a marcadores con nombres como “PresentFrame” o “WaitForPresent.”
¿Hay un proceso sólido para encontrar fugas de memoria en el perfilado?
Utiliza el Profiler de Memoria para comparar instantáneas de memoria y verificar si hay fugas. Por ejemplo, puedes tomar una instantánea en tu menú principal, entrar en tu juego y luego salir, volver al menú principal y tomar una segunda instantánea. Comparar estas dos te dirá si hay objetos/asignaciones del juego que aún están en la memoria.
¿Tiene sentido optimizar y reescribir parte del código para el sistema DOTS, para dispositivos móviles incluyendo VR/AR? ¿Usas este sistema en tus proyectos?
Varios proyectos de juegos ahora utilizan partes del Data-Oriented Technology Stack (DOTS). Contenedores Nativos, el Sistema de Trabajo C#, Matemáticas, y el compilador Burst son todos paquetes totalmente soportados que puedes usar de inmediato para escribir código C# óptimo, paralelizado y de alto rendimiento (HPC#) para mejorar el rendimiento de la CPU de tu proyecto.
Un número menor de proyectos también está utilizando Entidades y paquetes asociados, como el Renderizador Híbrido, Unity Physics, y NetCode. Sin embargo, en este momento, los paquetes listados son experimentales, y usarlos implica aceptar un grado de riesgo técnico. Este riesgo proviene de una API que aún está evolucionando, características faltantes o incompletas, así como la curva de aprendizaje de ingeniería necesaria para entender el Diseño Orientado a Datos (DOD) para aprovechar al máximo el Sistema de Componentes de Entidad (ECS) de Unity. El ingeniero de Unity, Steve McGreal, escribió una guía sobre mejores prácticas de DOTS, que incluye algunos fundamentos de DOD y consejos para mejorar el rendimiento de ECS.
¿Cómo estableces límites en las llamadas a SetPass o en la complejidad de los shaders? ¿Puedes incluso establecer límites de antemano?
El renderizado es un proceso complejo y no hay una forma práctica de establecer un límite estricto en el número máximo de llamadas a SetPass o una métrica para la complejidad de los shaders. Incluso en una plataforma de hardware fija, como una consola única, los límites dependerán del tipo de escena que quieras renderizar y del otro trabajo que esté ocurriendo en la CPU y GPU durante un fotograma.
Por eso la regla sobre cuándo perfilar es "temprano y a menudo." Los equipos tienden a crear una demostración de "corte vertical" al principio de la producción - generalmente un breve estallido de jugabilidad desarrollado al nivel de fidelidad visual previsto para el juego final. Esta es tu primera oportunidad para perfilar el renderizado y averiguar qué optimizaciones y límites podrían ser necesarios. El proceso de perfilado debe repetirse cada vez que se añade una nueva área u otro contenido visual importante.
Aquí hay recursos adicionales para aprender sobre la optimización del rendimiento:
Blogs
- Optimiza el rendimiento de tu juego para dispositivos móviles: Consejos de expertos sobre gráficos y activos
- Optimiza el rendimiento de tu juego para dispositivos móviles: Consejos de expertos sobre física, UI y configuraciones de audio
- Optimiza el rendimiento de tu juego para dispositivos móviles: Consejos de expertos sobre perfilado, memoria y arquitectura de código de los mejores ingenieros de Unity
- Consejos de expertos sobre cómo optimizar los gráficos de tu juego para consolas
- Perfilado en Unity 2021 LTS: Qué, cuándo y cómo
Páginas de cómo hacerlo
- Herramientas de perfilado y depuración
- Cómo perfilar la memoria en Unity
- Mejores prácticas para el perfilado del rendimiento del juego
E-books
- Optimiza el rendimiento de tus juegos de consola y PC
- Optimiza el rendimiento de tu juego para dispositivos móviles
- Guía definitiva para el perfilado de juegos de Unity
Aprender tutoriales
- Perfilando el rendimiento de la CPU en compilaciones de Android con Android Studio
- Perfilando aplicaciones – Hecho con Unity
Contenido técnico aún más avanzado llegará pronto – pero mientras tanto, no dudes en sugerir temas que queramos cubrir en el foro y revisa la grabación completa del seminario web de mesa redonda.