Revisado con versión: 2018.1
Textures are an essential part of Unity Projects, and you want to keep an eye on textures size and compression. On mobile and console, it is even more crucial due to the limited runtime memory and disk space. Choosing the correct compression is equally important as to size it correctly to save memory bandwidth.
By automating the Asset audit process, you can avoid accidentally or unknowingly changing asset settings. The AssetAuditor package on Github, covers many aspects of the audit process. Not only does Asset Auditing help recover performance for textures, but you can apply it to a multitude of Asset types in Unity as well. Read more about Asset Auditing in the Understanding Optimisation in Unity best practice guide.
Texture compression offers significant performance benefits when you apply it correctly. On newer mobile devices you should favor ASTC compressed texture formats. If ASTC is not available on your target devices, use ETC2 on Android and PVRTC on iOS.
Unity 4.3 onwards provides support for ASTC compression by ARM was added in Unity 4.3. Significantly beneficial at build time, Unity compresses ASTC faster than ETC2 or PVRTC. On iOS, ASTC is available on A8 chips and later; on Android, ASTC is available on most modern chipsets.
Mali GPUs (Mali T-760 MP8 and up) require ASTC compression over ETC2.
Read details about it in the official ARM documentation in Section 4.2.3 ASTC texture compression.
If the hardware does not support ASTC - on Adreno GPUs, for example - you must choose a fallback, such as ETC2. For additional information about ASTC, the ASTC texture compression for Game Assets article describes the topic well.
PVRTC was the main texture compression format on iOS until Apple added ASTC. If you use PVRTC on Android, you should replace it with ETC2 if possible.
Note: The PVRTC texture format on iOS and ETC format (Android 4.x devices) requires square textures. When compressing a non-square texture, two behaviors can occur:
If no sprite uses the texture and the compressed memory footprint is smaller than it would be if left uncompressed, Unity resizes the texture based on the non-power-of-two (NPOT) texture scale factor.
Otherwise, Unity does not resize the texture and marks it as uncompressed.
Unity uploads a texture directly to the GPU after it finishes loading and does not wait until the texture becomes visible in the Camera frustum.
When a loading thread finishes loading Scenes or Assets, Unity needs to awaken them. Where and how loading happens depends on Unity version and the calls used to initialize the load.
If you load an Asset from AssetBundles, Resources, or Scenes, Unity goes from the preloading thread (disk I/O) to the graphics thread (GPU upload). If use Unity 5.5 or later and enable graphics jobs, Unity goes from the preloading jobs directly to the GPU.
Unity awakes Assets on the main thread directly after awakening all Scene objects. If you use AssetBundle.LoadAsset, Resources.Load or SceneManager.LoadScene to load Assets and Scenes, Unity blocks the main thread and wakes up all Assets. If you’re using the non-blocking, for example AssetBundle.LoadAssetAsync, versions of those calls, Unity uses time-slicing to wake the Assets up.
While loading several textures at once, if either the upload rate is not fast enough or the main thread stalls, you can adjust texture buffers. Changing the default values, though, can lead to severe memory pressure. You can read more about memory restrictions of the texture buffers when using time-slice awake in the RingBuffer section of the Memory Management in Unity guide.
Note: If GPU memory overloads, the GPU unloads the least-recently-used texture and forces the CPU to re-upload it the next time it enters the camera frustum.