Cocos小游戏性能优化：纹理压缩

在游戏开发过程中，性能优化是一个不容忽视的问题。尽管它只是整体优化体系中的一部分，但图片纹理和资源的优化占据了相当大的比重。今天探讨图片纹理压缩。

常用压缩纹理格式

游戏中常用的纹理压缩格式包括PNG和JPG（JPEG）。一张分辨率为1024×1024的图片通常会占用约4M的内存。尽管这些格式具备较高的压缩效率，适合用于数据传输和下载，从而节省磁盘空间，但它们主要是为了在磁盘上高效“存储”图片而设计的。

图片文件无法被GPU直接识别和渲染，必须先由CPU进行读取和解码。首先，CPU从存储设备中读取图片的压缩数据（PNG/JPG的二进制数据）并加载到系统内存中。接下来是解码过程，这是CPU操作中最耗时的步骤之一，其目的是将压缩格式转换为GPU可以直接处理的未压缩位图，即一个包含RGBA等像素信息的像素数组。

GPU专用纹理格式

ASTC (自适应可伸缩纹理压缩)，其压缩块尺寸具有灵活性（4x4至12x12），具备高质量，并且支持HDR。适用于iOS (A8及以上)、Android (OpenGL ES 3.1及以上)系统，在压缩比和质量之间实现了良好的平衡，同时还支持非二次幂（NPOT）纹理。

ETC1(埃里克森纹理压缩1)，是最为基础的格式，应用时间较早，兼容性极为广泛。在Android (OpenGL ES 2.0)系统中，它的兼容性最佳，几乎所有的安卓设备都予以支持，但不支持透明通道。

ETC2 (埃里克森纹理压缩2)，作为ETC1的升级版本，是OpenGL ES 3.0标准的一部分。在Android (OpenGL ES 3.0及以上)系统中，安卓平台广泛兼容，成功解决了ETC1没有透明通道的问题，苹果设备原生支持，并且具有较高的压缩率。

PVRTC (PowerVR纹理压缩)，这是PowerVR GPU专属的格式，用于iOS (PowerVR GPU设备)。它要求纹理的长宽相等且为2的幂次方（POT），非PowerVR GPU无法支持。

专用纹理压缩格式有哪些优势？

块状压缩与随机访问：这些格式将纹理分割成小的像素块（通常为4x4），每个块单独进行压缩。当GPU需要某个像素时，它可以迅速定位到该像素所在的压缩块并进行单独解压，从而实现高效的随机访问。

硬件加速：压缩后的纹理数据可直接传输至GPU，并由GPU内部的硬件解码器实时解压，无需CPU预处理，显著提高了效率。

内存占用大幅降低：纹理在磁盘、内存和显存中始终保持压缩状态。例如，一张1024x1024的图像，使用ASTC 4x4格式可能仅需约170KB的显存，而未经压缩的RGBA32格式则需要占用4MB。

Cocos Creator纹理压缩配置

Cocos Creator 允许用户在编辑器中直接设定纹理的压缩方式，并在项目发布过程中自动执行纹理压缩。该引擎支持在同一平台上导出多种图片格式，会根据设备对压缩纹理格式的支持情况来加载相应的压缩纹理。现在我们的目标平台任然是小游戏平台，除了纹理压缩格式除了支持JPG和PNG外，还支持ASTC、ETC1/ETC2，PVR。

创建了一个名为compressing-demo的游戏项目，并动态加载一张1024×1024像素的图片，文件大小是1.29M。为了对比该图片在启用压缩格式和未启用压缩格式时的发布效果：

1、禁用压缩纹理的远程ZIP构建项目：

2、开启压缩纹理的远程ZIP构建项目：

在资源管理器中选择图片，然后在属性检查器勾选“压缩纹理”即完成压缩配置，如下图所示：

通过远程zip包发布的方式构建项目后remote文件夹是：

然后最终生成了三个压缩纹理，分别是JPG、ETC1和PVR。为什么是三个文件？根据前面的分析，我猜测会是在不同的系统平台加载合适纹理压缩格式以获得最佳性能。例如在Android就加载ETC1，在iOS就加载PVR，如果都不行就读取JPG。

可见即便三种格式的文件，压缩成Zip后，缩小至原来不使用压缩纹理的70%了。而Cocos引擎会根据文件类型自动解析压缩纹理。

配置压缩纹理能在构建项目时将纹理数据转为GPU专用压缩格式，直接用于GPU内存，无需解压，能减少内存占用、降低带宽需求，提升游戏渲染性能和加载速度。