做过3D项目的人几乎都绕不开纹理压缩这个问题。一张4096x4096的RGBA贴图，如果以未压缩格式放进显存，要占用整整64MB，一个场景几十张贴图，显存瞬间就爆了。而且纹理带宽的消耗还会直接影响移动设备的发热和续航。GPU专用的压缩格式就是为了解决这个问题而生的：纹理在显存中保持压缩状态，GPU采样时按需解压，内存占用可以降到原来的四分之一甚至更少，同时解码由硬件完成，几乎不增加采样开销。市面上常见的格式名词很多，DXT、BCn、ETC、PVR、ASTC常常让人混淆，这篇文章就把它们的关系理清楚，并给出实际项目中的选择思路。
纹理压缩的基本原理：为什么不能用JPG代替
首先要明确一点，DXT、BC、ASTC这类格式和JPG、PNG是完全不同的两类东西。JPG是一种面向存储和传输的流压缩，GPU渲染时必须先把它完整解压成RGBA位图再上传显存，显存占用一点没省，只是减小了安装包体积。而GPU纹理压缩是固定压缩比的块压缩方案：把纹理切分成4x4的小块，每一块独立编码，解码由GPU硬件在采样时实时完成。
固定压缩比带来两个关键好处。第一，显存占用可预测且大幅降低，比如DXT1固定4bpp（每像素4比特），相当于未压缩RGBA的八分之一。第二，因为是块级随机访问，GPU不需要解压整张纹理就能采样任意一个像素，这使得压缩纹理可以直接渲染，不需要任何预处理步骤。这也是为什么所有主流图形API，包括DirectX、OpenGL、Vulkan、Metal，都原生支持这类格式的原因。
块压缩的代价是有损。每4x4像素块只有极少的数据预算来描述16个像素的颜色，所以渐变平滑的贴图容易出现块状伪影，法线贴图的精度损失则会影响光照质量。不同格式之间的差异，本质上就是在"如何用有限的数据预算描述一个像素块"这件事上采用了不同的编码策略。
DXT与BC格式家族：PC平台的主力军
DXT是DirectX早期的叫法，BC（Block Compression）是DirectX 10之后的规范名称，两者本质是一回事。DXT1就是BC1，DXT3就是BC2，DXT5就是BC3，后来的BC4、BC5、BC6H、BC7则是新增的格式。BC1每像素4比特，用一个16位颜色端点加上每像素2比特的插值索引来编码，适合不透明的漫反射贴图（Albedo/Diffuse）。带Alpha通道的贴图可以用BC3，它在BC1基础上增加了一条压缩过的Alpha通道，每像素8比特。
工程上更值得关注的几个进阶格式：BC5专门为法线贴图设计，把法线的X、Y分量分别存在两个单通道块里，解码时用sqrt(1 - x*x - y*y)重建Z分量，精度远高于BC1，是法线贴图的标准选择。BC6H针对HDR浮点贴图，BC7则是质量最好的通用格式，每像素8比特，支持单独的Alpha通道、多分区编码和更精细的端点插值，压缩质量接近原始贴图，代价是编码速度慢、体积和BC3相当。
实际项目中常见的配置思路是：Albedo用BC1或BC7，法线用BC5，金属度粗糙度这类 Mask 贴图打包成单通道后用BC4，HDR环境贴图用BC6H。需要注意的是，如果贴图通道打包不当，比如把高精度数据放进BC1，会出现严重的色带和渗色问题，因为BC1的端点插值是在RGB空间线性进行的，相邻块之间容易产生不连续。
ASTC：移动端与跨平台的新标准
ASTC（Adaptive Scalable Texture Compression）由Khronos制定，可以说是目前设计最灵活的块压缩格式。它最大的特点是块尺寸可选：从4x4到12x12共十几种组合，同样数据预算下块越大压缩比越高、质量越低，开发者可以在体积和质量之间自由权衡。4x4是8bpp的高质量档，6x6约3.56bpp接近BC1的体积但质量更好，8x8只有2bpp，适合远距离观察的贴图。
ASTC还支持很多BC家族没有的特性：完整的HDR浮点支持、每通道独立的精度配置、法线贴图的专用编码模式（3分量相关编码，Z分量不额外占空间）、以及sRGB和LDR的统一处理。这些能力让ASTC可以用一套格式覆盖几乎所有贴图类型，不再需要针对不同贴图挑选不同格式。苹果从A8芯片开始全面支持ASTC，安卓侧从OpenGL ES 3.2和 Vulkan 起也将其列为核心特性，可以说除了一些老旧设备，现代移动GPU都具备硬件解码能力。
ASTC的缺点主要在编码端：编码算法复杂，高质量编码非常耗时，一张4K贴图用 exhaustive 质量档可能要编几分钟。工具方面，ARM提供的astcenc是官方参考实现，支持精细的质量和速度档位；美术资源管线中通常建议离线批处理，用中间质量档平衡时间与效果。
平台选择建议与工具链实践
不同平台对格式的硬件支持决定了最终选择。PC上DirectX和 Vulkan 全面支持BC系列，优先使用BC7和BC5的组合。移动端优先ASTC，iOS全设备线支持，安卓需要注意部分低端老设备只支持ETC2，发布前要确认目标设备分布。WebGL场景比较特殊：WebGL 2.0保证支持ETC2，但ASTC、BC都依赖扩展，实际项目通常的做法是服务端根据浏览器上报的扩展信息动态下发对应格式，或者统一降级到ETC2。
格式转换工具链方面，常用的是NVIDIA Texture Tools、Compressonator、以及命令行的astcenc和compressonatorcli。以astcenc为例，一条典型命令如下：
astcenc -cl input.png output.astc 6x6 -medium -normalmap
这条命令把PNG转成6x6块的ASTC，使用中等质量档，并启用法线贴图专用编码。参数里的-cl表示压缩模式和质量档，-medium是速度与质量的折中，批量处理时可以先用-fast预览，最终出包再切换到-thorough。转换完成后务必在目标设备上实际查看效果，特别是天空盒、渐变这类容易出块伪影的内容，必要时对贴图做轻微噪点抖动来打散色带。
最后给一个可以落地的默认配置：PC项目统一用BC7处理彩色贴图、BC5处理法线；移动项目统一用ASTC 6x6起步，UI和近距离贴图提升到4x4，远处环境和天空盒降到8x8甚至10x10；跨平台引擎内通过贴图后缀或命名约定区分用途，管线自动分配合适格式。纹理压缩没有银弹，理解每种格式的编码原理，再针对内容类型和目标平台做取舍，才能在画质、内存和包体之间拿到最优解。