纹理格式指南:从PNG到ASTC,内存究竟省在哪

在Unity项目开发中,纹理资源的管理直接影响游戏的包体大小运行时内存渲染性能。面对JPG、PNG、ASTC、ETC2等一系列格式,许多开发者容易混淆它们的作用与适用场景。本文将从核心概念出发,系统梳理各种纹理格式的定位与选型策略,帮助深刻理解纹理格式。

1. 源文件 vs GPU纹理格式

首先必须明确:Unity项目中使用的图片源文件(如JPG、PNG)与游戏运行时GPU实际使用的纹理格式是两套完全不同的体系。

  • 源文件:存放在Assets目录下的原始图片,它们经过压缩(如JPG的有损压缩、PNG的无损压缩)以减小磁盘占用,但GPU无法直接识别。在加载时,CPU需要解压这些文件,还原为完整的像素数据(如RGBA32)后才能上传到显存。
  • GPU纹理格式:游戏打包时,Unity会根据目标平台将源文件转换为GPU原生支持的压缩格式(如ASTC、ETC2等)。这些格式允许纹理在显存中保持压缩状态,GPU通过内置的硬件单元在采样时实时解压小块数据,从而大幅降低显存占用和带宽需求。

理解这一区别,是正确管理纹理资源的基础。

2. 源文件格式的选择

Unity支持多种常见图像格式作为源文件。选择合适的格式可以为后续压缩提供良好基础,同时平衡项目中的源文件存储与版本管理。

格式 特点 适用场景
JPG 有损压缩,体积小,不支持透明通道 3D模型的漫反射贴图、游戏背景等不需要透明的资源。不适合含硬边或文字的图像。
PNG 无损压缩,支持透明通道 UI图标、Sprite精灵图集、需要锐利边缘和透明的纹理。UI和2D游戏的首选源格式。
TGA 无损或轻度压缩,支持Alpha,广泛用于美术流程 需要保留额外通道信息(如光滑度、金属度)的贴图,或从DCC软件(Maya、3ds Max)导出的中间格式。
EXR 高动态范围(HDR),支持浮点像素和多种压缩算法 HDR环境贴图、光照贴图、需要高精度颜色信息的纹理。适合后续使用BC6H压缩。

建议:日常开发中,UI和2D素材优先用PNG,3D漫反射贴图可酌情使用JPG,需要HDR或高精度数据时用EXR。保留原始工程文件在外部管理,利用Unity的导入管线自动处理。

3. 运行时GPU压缩格式详解

1. 为什么压缩格式能减少内存?

纹理内存占用的核心指标是每像素位数(bits per pixel,简称bpp)。未压缩的RGBA32格式每像素占用32位(4字节),一个1024×1024的纹理将占用 4 MB 显存。对于拥有数十张纹理的现代游戏,这个数字会迅速膨胀。

GPU压缩格式通过块压缩、调色板量化等算法大幅降低bpp:

  • ETC2 RGB:4 bpp,同样纹理仅占 0.5 MB(1/8)
  • ASTC 4x4:8 bpp,占用 1 MB(1/4)

压缩的本质是让纹理在显存中保持压缩状态,GPU采样时通过硬件实时解压所需小块。这与PNG/JPG的流程有本质区别:

阶段 PNG/JPG作为源文件 GPU压缩格式(ASTC/ETC2)
磁盘/包体 压缩(小) 压缩(通常比PNG大)
CPU处理 需完全解压为RGBA 几乎不解压,直接传递压缩数据
显存中数据 未压缩的RGBA(大) 压缩后的数据(小)
GPU采样 直接读取RGBA 硬件实时解压小块数据

因此,尽管PNG/JPG在磁盘上更小,但它们无法减少运行时显存占用;而GPU压缩格式正是为了在显存中保持压缩状态而设计,从而显著降低内存压力。

在Unity编辑器中,选中纹理资源后,可以在Inspector面板的压缩格式设置下方查看该纹理在不同压缩格式下的预估内存占用(如图),方便开发者在实际项目中验证内存优化效果。

image

2. 为什么ASTC的包体比PNG大?

这是一个常见的疑问。ASTC的包体(最终应用程序中的大小)通常大于PNG源文件,原因在于两者的设计目标不同:

  • PNG 旨在最小化存储/网络传输体积,采用DEFLATE等通用无损压缩算法,对图像数据进行熵编码,在磁盘上可以压得非常小。
  • ASTC 旨在最小化运行时显存占用并优化GPU采样效率,采用面向GPU的块压缩算法,每个块(如4×4、6×6像素)独立编码为固定的128位数据,便于硬件快速寻址和解压。这种布局的压缩效率通常不如PNG的熵编码,因此包体会更大(通常为PNG的1.5~2倍)。

这是典型的“空间换时间”权衡:用稍大的安装包换来运行时更低的内存占用和更快的加载速度。

4. 主流平台的压缩格式选型指南

1. 桌面与主机平台

  • DXT (BC1/BC3):经典DXTC压缩。
    • DXT1 (RGB):4 bpp,适用于不带透明通道的纹理。
    • DXT5 (RGBA):8 bpp,适用于带透明通道的常规纹理。
  • BC6H:专为HDR纹理设计,8 bpp,基于浮点数。

2. iOS平台

  • ASTC现代iOS设备的首选(A8芯片及以上,iPhone 6及以后)。支持灵活的块大小(4×4 ~ 12×12),可精细控制压缩比(8 bpp ~ 0.89 bpp)。一套资源覆盖所有现代iOS设备。
  • PVRTC仅用于旧款iOS设备(A7及更早,如iPhone 5s及以下)。限制较多,要求纹理为2的幂且最好是正方形,否则质量损失严重。

3. Android平台

Android生态碎片化严重,需根据目标设备层级选择:

  • ASTC现代Android设备的首选,且已成为Vulkan和OpenGL ES应用在Android上最广泛使用的纹理压缩格式。支持范围覆盖自2014-2015年起的主流GPU(Adreno 4xx、Mali-T600系列及更高)。对于现代设备开发,ASTC已是默认选项,而非需要刻意兼容的“较新”格式。
  • ETC2OpenGL ES 3.0设备的标配。自Android 4.3(API 18)起成为强制标准,支持RGBA,压缩率优秀(RGB 4 bpp,RGBA 8 bpp)。所有支持OpenGL ES 3.0的设备均支持ETC2。
  • ETC1仅用于老旧设备。不支持Alpha通道,需通过Split Alpha方案(拆分为两张纹理)处理透明,会增加Draw Call和内存。
平台 首选格式 备选/旧设备格式 关键考虑因素
PC / 主机 DXT1/DXT5 (RGBA), BC6H (HDR) - DXT兼容性最好,BC6H用于HDR
iOS ASTC (4×4 ~ 12×12) PVRTC ASTC灵活且高质量;PVRTC用于A7及更老芯片
Android ASTC ETC2 / ETC1 ASTC已是现代设备标配;ETC2用于兼容旧设备;ETC1需处理Alpha问题

4. 关于纹理尺寸的重要注意事项

关于纹理尺寸(POT vs NPOT),有几个关键点需要特别注意:

  • Mipmap强制POT要求如果启用了Mipmap,纹理尺寸必须为2的幂次方(POT)。若在启用Mipmap的情况下使用NPOT纹理,即使选择了ASTC格式,纹理在真机上也会被回退为未压缩的RGBA32格式,导致内存占用成倍增加(例如ASTC 4x4本应占1MB,回退后将占用4MB)。

  • 回退机制:当为NPOT纹理启用Mipmap时,Unity会在加载时自动将纹理缩放或填充到下一个POT尺寸。这一过程不仅增加了内存开销,还可能导致视觉模糊。

  • 何时可安全使用NPOT:如果不使用Mipmap(例如UI元素、2D Sprite),且目标平台支持NPOT(现代平台均支持),则可以直接使用NPOT纹理,无需填充。

  • 传统格式的特殊限制:对于PVRTC、ETC1等传统格式,即使不启用Mipmap,也可能要求纹理为POT才能正常压缩。

5. 纹理格式选型的核心权衡

通过以上分析可以看出,纹理格式的选择本质上是多维度权衡的结果:

权衡维度 说明
包体大小 vs 内存占用 PNG等源格式在包体中很小,但运行时内存大;ASTC等GPU格式包体稍大,但运行时内存小。这是最核心的取舍。
视觉质量 vs 压缩率 更低的bpp意味着更小的内存占用,但可能带来视觉质量损失。ASTC通过灵活的块大小让开发者可以精细平衡这一关系。
兼容性 vs 格式特性 ETC1兼容老旧设备但功能受限;ETC2兼容性更广且支持透明;ASTC功能最强大,且已成为现代设备标配,无需再作为“先进性”选项进行权衡。
加载速度 vs 包体大小 某些技术可以进一步缩减包体,但会增加加载时的解压开销。

在实际项目中,这些权衡往往需要结合具体场景来决策:

  • UI纹理:UI通常对清晰度要求较高,且多为2D平面显示,但现代ASTC格式在合理块大小(如6×6或8×8)下已能提供接近原图的视觉质量,同时大幅降低内存占用。因此UI纹理同样建议使用ASTC(或目标平台对应的现代压缩格式)。需注意若为UI纹理启用Mipmap(通常不需要),则仍需遵守POT要求。
  • 3D模型贴图:数量多、对内存敏感,应优先使用ASTC、ETC2等高效压缩格式。如需Mipmap,务必确保纹理为POT。
  • 背景图或加载界面:对加载时间不敏感,可使用更高压缩率的选项以减小包体。
  • 法线贴图:需使用专门的压缩优化,避免普通压缩导致法线方向失真。
3赞

爱了,这种龙哥,有谁不爱?

我草,刚看清

通俗易懂 知识进脑子了 :7:

那麽在H5平台呢?

摩多摩多摩多摩多

H5或者小游戏也能用压缩纹理啊

那么 最佳方案 是不是还是用 png jpg最合适 呢

这个公众号是鸭哥的啊,,怎么感觉这么熟悉。。原来是上午看了。。

Unity引擎的话,因为bundle支持lz4压缩,因为压缩纹理格式的数据格式对lz4友好,通常能比jpg/png压得更小(相同质量下),其实这样看来包体能更小
包体大小问题其实是Cocos Creator下的问题

不要生搬硬套。H5平台小游戏文件体积大小更重要, 因为图片都是走网络CDN下载,用户随时玩耍弱网环境差,文件体积越小下载的速度越快加载的越快。实践上可以用webp这类的格式再配置上gzip,至于显存占用,一般的小游戏的规模这里不是瓶颈。 相信我,你的策划运营一定会把游戏数据不好玩家流失快的锅扣到技术头上,说是因为游戏包体太大导致用户还没加载完就跑路,不要给他们任何的借口

原生平台的做成ASTC很方便, 但小游戏这种弄成ASTC的测试太麻烦了 开发工具不支持,要弄两套资源 本来资源空间就紧张,这下好了翻倍了直接