Mantener el tamaño del archivo de la app construida a un mínimo a menudo es importante, especialmente para dispositivos móviles o para tiendas de apps que imponen un limite de tamaño. El primer paso en reducir el tamaño es determina qué assets contribuyen más a esto, ya que estos assets son los candidatos más probables para la optimización. Usted puede encontrar esta información del Editor Log (Registro del Editor) justo después de que usted ha realizado la construcción (seleccione Open Editor Log del menú panel pequeño en la esquina derecha de la ventana de la Consola).
El registro proporciona un resumen de assets clasificados por el tipo y luego escucha a todos los assets en individual en orden de su contribución al tamaño. Típicamente, cosas como texturas, música y videos tomará la mayoría de espacio mientras que scripts, niveles y shaders son insignificante. Tenga en cuenta que el File Headers (encabezado del archivo) mencionado en el resumen no son assets en sí. Los headers (encabezados) son en realidad datos extra que son agregados a los archivos assets “raw” (crudos) para almacenar referencias y ajustes. Los headers normalmente hacen muy poca diferencia al tamaño del asset pero el valor puede ser más grande si usted tiene un número de assets grandes en la carpeta Resources.
El log (registro) le ayuda a usted identificar assets que usted podría querer quitar o optimizar pero usted debería considerar lo siguiente antes de trabajar:
Unity re-programa los assets importados a sus propios formatos internos, por lo que la opción del tipo de fuente de asset no es relevante. Por ejemplo, si usted tiene una textura multi-capa de Photoshop en el proyecto entonces será aplanado y comprimido antes de construir. Al exportar la textura como un archivo PNG no va hacer diferencia al tamaño de construcción, por lo que debe atenerse al formato que sea más conveniente para usted durante el desarrollo.
Unity despoja la mayoría de los assets no utilizados durante la construcción, por lo que usted no gana nada al quitar los assets manualmente del proyecto. Los únicos assets que no son quitados son los scripts (por lo por lo general son muy pequeños igual) y los assets en la carpeta Resources (ya que Unity no puede determina cuáles de esto serán necesitados y cuáles no). Con esto en mente, usted debería asegurarse que los assets en la carpeta Resources solo son aquellos que realmente se necesitan en el juego. Usted podría remplazar los assets en los Resources con AssetBundles para cargar los assets dinámicamente y por lo tanto reducir el tamaño del reproductor.
En la mayoría las texturas ocupan el mayor espacio en la construcción. La primera cosa para hacer es utilizar formatos de texturas comprimidos (DXT(Desktop platforms) o PVRTC) dónde usted pueda.
Si eso no hace que el tamaño disminuya, intente reducir el tamaño de las texturas. El truco aquí es que usted no necesita modificar el contenido actual de la fuente. Simplemente seleccione la textura en la vista del Proyecto y configure el Max Size de los Import Settings (Ajustes de Importación). Es una buena idea acercarse en un objeto que utiliza la textura, luego ajustar el Max Size hasta que comience a verse peor en la Scene View.
La siguiente tabla muestra qué tanto espacio del formato de la imagen toma en bytes por pixel:
Compresión | Consumo de Memoria (bytes/pixel) |
---|---|
Standalone & WebGL | |
RGB Crunched DXT1 | variable |
RGBA Crunched DXT5 | variable |
RGB Compressed DXT1 | 0.5 bpp |
RGBA Compressed DXT5 | 1 bpp |
RGB 16bit | 2 bpp |
RGB 24bit | 3 bpp |
Alpha 8bit | 1 bpp |
RGBA 16bit | 2 bpp |
RGBA 32bit | 4 bpp |
iOS | |
RGB Compressed PVRTC 2 bits | 0.25 bpp (bytes/pixel) |
RGBA Compressed PVRTC 2 bits | 0.25 bpp |
RGB Compressed PVRTC 4 bits | 0.5 bpp |
RGBA Compressed PVRTC 4 bits | 0.5 bpp |
RGB 16bit | 2 bpp |
RGB 24bit | 3 bpp |
Alpha 8bit | 1 bpp |
RGBA 16bit | 2 bpp |
RGBA 32bit | 4 bpp |
Android | |
RGB Compressed DXT1 | 0.5 bpp (bytes/pixel) |
RGBA Compressed DXT5 | 1 bpp |
RGB Compressed ETC1 | 0.5 bpp |
RGB Compressed PVRTC 2 bits | 0.25 bpp (bytes/pixel) |
RGBA Compressed PVRTC 2 bits | 0.25 bpp |
RGB Compressed PVRTC 4 bits | 0.5 bpp |
RGBA Compressed PVRTC 4 bits | 0.5 bpp |
RGB 16bit | 2 bpp |
RGB 24bit | 3 bpp |
Alpha 8bit | 1 bpp |
RGBA 16bit | 2 bpp |
RGBA 32bit | 4 bpp |
La formula para el tamaño total de almacenamiento de imagen es width * height * bpp. Si usted está utilizando mipmaps entonces el almacenamiento será tres veces más grande que una sola imagen.
Por defecto Unity comprime todas las texturas cuando se importe. Para un flujo de trabajo rápido en el editor, usted puede apagar la compresión desde las Preferences (preferencias) pero todas las texturas serán comprimidas en la construcción sin importar acerca de este ajuste.
Meshes y los Clips de Animación importados pueden ser comprimidos para que tomen menos espacio en el archivo de su juego. Las compresiones pueden prenderse en los ajustes de importación del Mesh.
La compresión Mesh y de Animaciones utiliza quantization (cuantización), lo cual significa que toma menos espacio pero la compresión puede introducir algunas imprecisiones. Experimente con qué nivel de compresión es aceptable para sus modelos.
Tenga en cuenta que la compresión mesh solamente produce archivos de datos pequeños y no utiliza menos memoria en tiempo de ejecución. La reducción de keyframe de animación produce archivos de datos más pequeños y utiliza menos memoria en tiempo de ejecución y generalmente usted siempre debería tenerlo activado.
Por defecto, Unity incluye solamente los siguientes DLLs en el reproductor construido:
Cuando se construya un reproductor, usted debería evitar cualquier dependencia en System.dll o System.Xml.dll. Unity no incluye estas en el reproductor construido por defecto pero si usted utiliza sus clases, entonces serán incluidas. Estos DLLs van a agregar aproximadamente un megabyte al tamaño de almacenamiento del reproductor. Si usted necesita parse XML en su juego, usted puede utilizar una librería como Mono.Xml.zip como una pequeña alternativa a las librerías del sistema. Mientras que la mayoría de los contenedores genéricos son contenidos en mscorlib, Stack<> y otros pocos están en System.dll, por lo que usted debería evitar estos como sea posible.
Unity soporta dos niveles de compatibilidad de API .NET para algunos dispositivos móviles: .NET 2.0 y un sub-conjunto de .NET 2.0. Usted puede seleccionar el nivel apropiado para su construcción en los Player Settings.
El perfil de API .NET 2.0 es muy similar al API completo .NET 2.0. La mayoría de rutinas de librerías están completamente implementadas por lo que esta opción ofrece la mejor compatibilidad con código .NET pre-existente. Sin embargo, para muchos de los juegos, la librería completa no se necesita y el código superfluous toma un espacio de memoria valioso.
Para evitar memoria desperdiciada, Unity también soporta el perfil de API que es sub-conjunto de .NET 2.0. Este es muy similar al perfil Mono “monotouch”, por lo que muchas limitaciones del perfil “monotouch” también aplica al perfil del sub-conjunto .NET 2.0 de Unity. (Más información acerca de las limitaciones del perfil “monotouch” puede encontrarse aquí). Muchas library routines que no son comúnmente necesitadas en los juegos son dejadas afuera de este perfil con el fin de ahorrar memoria. Sin embargo, esto también significa que el código con dependencias en esas routines no van a funcionar correctamente. Esta opción puede ser una optimización útil pero usted debería revisar que ese código existente todavía funciona después de que es aplicado.