纹理压缩原理与格式选择：BC7/ASTC实战优化游戏显存带宽

在游戏开发与画质优化这条路上，很多团队都会反复纠结同一件事：显卡已经拼命渲染了，为什么帧率还是上不去？观测指标通常指向两类瓶颈，一类是 GPU 计算单元满载，另一类是显存带宽踩满。后者经常被忽略，而纹理压缩恰恰是针对显存带宽和显存容量最直接的优化手段之一。这次我们直接进入主题，把纹理压缩的原理、格式选择、工具链执行方式和踩坑点全部过一遍，并在最后给出一段 Windows 系统层面的性能优化辅助批处理脚本，方便你拿到手就能用。

先说结论：纹理压缩不是“要不要做”的问题，发布游戏时它几乎是必选项。一个 4K 分辨率、带 mipmap 链的未压缩 RGBA 纹理动辄占用几十 MB 显存，同一张图换成 BC7 或 ASTC 之后，体积能缩小到原来的 1/4 甚至 1/8，而且 GPU 可以直接对其进行过滤采样，不需要像 JPEG 或 PNG 那样先解压到内存。整个替换过程不需要改动渲染管线的整体架构，却能在高分辨率、多纹理场景下换回可观的带宽余量。

这篇文章会从以下角度展开：先讲纹理压缩的性能收益来源，再对比 BC、ASTC、ETC2 等主流格式，然后给出基于 DirectXTex、ASTC Encoder 等工具的完整实操流程，接着补充性能验证方法和 Windows 层级的批处理辅助优化，最后整理常见问题和工程化建议。无论是 PC 独立游戏、Unity 手游还是 UE 项目，这套方法都能直接套用。

1. 纹理压缩：游戏性能优化里的“隐形收益”

纹理压缩与普通图片压缩有本质区别。普通玩家往压缩包塞图片时，常用的是 JPEG、WebP、PNG，这些格式在解码时会一次性还原整张位图，然后交由 CPU 或 GPU 处理；而 GPU 渲染过程中对纹理的读取是高频、随机的，纹理过滤时需要任意访问像素附近的数据，不允许先把整张图片解压到内存再采样。纹理压缩因此采用固定块编码方式：把纹理切成若干小方块，每个方块独立压缩，采样时 GPU 只需要解压对应块，速度极快，内存布局也可预测。

从性能优化角度，纹理压缩带来的收益有三个层面：

第一，降低显存占用。未压缩纹理的体积可以简单用像素数乘字节数计算：

显存占用（未压缩）= 宽度 × 高度 × 通道数 × 字节数/通道 例如 4096×4096 RGBA8：4096 × 4096 × 4 ≈ 64 MB

换成 BC1/DXT1 后，同尺寸下降到原来的 1/8，约 8 MB。现代游戏一个角色、一个关卡场景动辄几十上百张贴图，累计下来的显存差异非常可观，纹理压缩能直接决定 8G 显存的显卡能否稳定运行高分辨率材质包。

第二，缓解显存带宽压力。GPU 每帧要从显存读取大量纹素做采样，纹理数据量越小，单位时间搬运的数据越少。在 4K 输出、多张视图、延迟渲染叠加 G-Buffer 的场景中，带宽下降往往能直接反映为帧率回升。这一点在带宽受限的移动 GPU 上尤其明显。

第三，减少加载时间和磁盘体积。压缩后的纹理文件在安装包、pak、apk 中占用更少空间，读取时的 IO 压力也随之下降，冷启动和关卡切换速度通常会有可感知的改善。

更关键的是，纹理压缩是一种近乎“无感换装”的优化：只要选择与目标平台匹配的格式，API 层对采样接口的调用几乎不变，甚至可以用 DDS、KTX 这类容器直接换文件。适合在渲染优化进入中期时作为高优先级事项处理。

不过这里要特别强调：纹理压缩大多是有损的。不同压缩格式、不同压缩参数会产生不同的画质损失和压缩率。优化不是无脑把所有纹理全部压成最小块，而是要在画质可接受的前提下找到显存、带宽、加载时间三者之间的平衡点。

2. 纹理压缩的核心原理与三大性能收益

选择纹理压缩格式之前，先理解它的编码核心：不把图片看成一整张“照片”，而是拆成若干按固定大小排列的色块。绝大多数格式采用 4×4 像素块的划分，每个块以两种或多种基色加索引表的方式存储，GPU 采样时按索引插值出像素颜色。因为块与块之间互不依赖，所以任意位置都能直接解压，这就是 GPU 纹理随机访问能成立的原因。

块编码带来几项直接收益：

• 固定压缩率，便于预估显存大小。
• 块而独立的编码结构，让 GPU 可以在纹理管线内完成解压。
• 不需要 CPU 参与，加载后保持压缩状态，直到渲染管线采样时才解压对应块。

从游戏性能优化的视角看，纹理压缩的核心价值可以归纳为三个方向。

2.1 纹理压缩不等于普通图片压缩

最常被误解的地方在这里：很多人把纹理压缩理解成“把 PNG 转成 JPG”，认为用 Photoshop 导出一张质量更高的 JPG 就能达到同样效果。实际上纹理压缩和传统图片压缩的实现路径完全不同：

• JPEG/PNG 的目标是尽量节省磁盘空间，解码整张图片通常需要完整读入，缺少按块随机访问能力。
• 纹理压缩的目标是让 GPU 在渲染采样时能按块解压，支持 mipmap，支持三线性过滤，且带宽开销要足够低。

因此，引擎里常见的 Texture Compression 选项和资产管理器里的 JPG/PNG 压缩完全是两码事。发布阶段如果只压缩了源图片格式而忽略纹理压缩，纹理加载进显存后依然是未压缩状态，带宽和显存压力不会得到实质缓解。

2.2 三大性能收益：显存、带宽、加载时间

纹理压缩对游戏性能优化的三大收益，可以拿一个具体场景估算。

假设某个关卡使用了约 1200 张 2048×2048 的 RGBA 纹理，未压缩总大小约 19.2 GB，显然任何消费级显卡都无法全部塞进显存，所以运行时会不断做流送和淘汰，帧率必然不稳定。换用 BC7 后，每张约 4 MB，总大小约 4.8 GB，主流 8 GB 显存能比较轻松地容纳，帧率曲线会平稳很多。

在带宽层面，GPU 在渲染一帧的过程中，每个像素都可能多次采样纹理。纹理体积减少 4 倍，意味着在相同时间内搬运的纹素数据量可以降低到原来的 1/4，那些“显卡利用率已经很高但帧率还是上不去”的带宽瓶颈场景，压缩后通常能拉开明显差距。

如果在项目早期就定义好纹理压缩规范，数据流和加载逻辑可以同时受益：打包体积变小，硬盘读取变少，加载进度条等待时间缩短；进入游戏场景后，显存中能驻留更多纹理，场景切换时也不会频繁出现“突然卡一下”的流送等待。

3. 主流纹理压缩格式对比与选择

纹理压缩格式的选择受目标硬件平台和图形 API 双重约束。PC 端主流的 DDS 格式覆盖 BC1 到 BC7，移动端主流是 ETC2 和 ASTC，主机平台则各有偏好。下面把常用格式列出来，方便在不同目标平台之间对照选择。

3.1 PC 平台的 BC 系列

BC（Block Compression）系列是 Direct3D 10 以后的标准纹理压缩格式，通常封装在 DDS 文件中。常见格式包括：

• BC1/DXT1：4 bit/像素，RGB，不支持 alpha 或只有 1 bit alpha，压缩率最高，适合大多数不透明贴图，比如场景漫反射、地面纹理。
• BC2/DXT3：8 bit/像素，带 4 bit 显式 alpha，适合带有锐利透明边界的贴图，比如树叶、铁栅栏。
• BC3/DXT5：8 bit/像素，带 8 bit 插值 alpha，适合 alpha 渐变平滑的贴图，遮罩和带透明过渡的素材经常用它。
• BC4：单通道格式，适合灰度图、高度图、粗糙度贴图，比如 RMA 合图中的 R 通道。
• BC5：双通道格式，适合法线贴图的 XY 分量，法线重建 Z 分量，质量比 RGBA 整张压缩更高。
• BC6H：HDR 格式，适合需要高动态范围的环境贴图，不适用于普通 LDR 颜色贴图。
• BC7：高质量 RGBA 格式，是目前 PC 端默认的“质量优先”选择，兼容性好，适合高质量漫反射贴图、UI 贴图等。

实际项目里最常见的组合是：漫反射贴图用 BC1 或 BC7，带 alpha 的透明贴图用 BC3 或 BC7，法线贴图单独用 BC5。这样可以在画质和体积之间取得平衡。

3.2 移动平台的 ETC2 与 ASTC

移动端传统格式是 ETC2，OpenGL ES 3.0 和 Vulkan 设备普遍支持。ETC2 支持 RGB 和 RGBA，也支持 BC5 类似的法线处理方式，但压缩质量上限比 BC7 低，高分辨率下的色块和条纹相对明显。

ASTC 是当前更值得优先考虑的格式。ARM 主导设计，支持从 4×4 到 12×12 多种块大小，压缩率从约 8 bit/像素线性降低到不到 1 bit/像素，而且适配范围比 BC 系列更灵活。同一个 ASTC 格式几乎覆盖移动、主机和 PC 平台，只要 GPU 支持 ASTC LDR，就能用同一条管线输出。

ASTC 的质量取决于块大小：

• 4×4：最低压缩率，画质接近 BC7，适合需要保留细节的法线贴图和 UI。
• 6×6：默认推荐档位，在体积与画质之间比较均衡，适用于大多数漫反射贴图。
• 8×8：体积更小，适合背景、墙面这类细节要求不高的纹理。
• 10×10 及以上：主要用于极限压缩，适合大尺度地形、远景天空盒等。

3.3 格式选择速查表

如果是新项目，建议直接从 ASTC 起步；PC 项目继续以 BC 系列为主；如果做 PC 和移动跨平台，可以分别导出 DDS 和 KTX2，或统一用 KTX2 容器配合 ASTC。

4. 基于纹理压缩的游戏优化实操路线

了解格式后，实操层面的流程可以分成三步：梳理现有纹理资产、设定压缩策略、执行批量压缩。

4.1 第一步：梳理纹理资产

在动手压缩之前，先把项目里的纹理资产按用途分类，常见分类如下：

• 漫反射/基础颜色贴图（RGB，一般不带 alpha）
• 透明贴图（RGBA，带 alpha 通道）
• 法线贴图（XY 通道有效）
• 粗糙度/金属度/环境光遮蔽等单通道或双通道贴图
• HDR 环境贴图
• UI 贴图和字体图集
• 地形 Splatmap、Lightmap 等特殊用途贴图

不同用途的贴图应该走不同的压缩格式，不能一刀切。比如 UI 贴图如果直接压成 BC1，文字边缘会出现明显锯齿和色带；法线贴图如果按 RGBA 普通压缩，两个有效通道的精度会被浪费。

4.2 第二步：设定压缩策略

依据目标平台和画质基线，可以给每类贴图设定优先级。一个可供参考的策略模板如下：

• 第一优先级：场景大型漫反射贴图，例如植被、地形、建筑墙面，用中等压缩比格式，保留足够细节。
• 第二优先级：角色贴图和武器贴图，通常更需要画质保障，使用高比特率压缩格式。
• 第三优先级：过场动画专用贴图和 UI，按固定分辨率导出高比特率格式。
• 第四优先级：远景、天空、重复度高的纹理，使用高压缩比格式降低带宽压力。

这里建议额外准备一张格式映射表：

4.3 第三步：压缩资产执行流程

确定格式后，在项目工程中通常有两种执行方式：一种是在 DCC 工具或资产管理器里手动导出，另一种是编写批处理脚本自动转换。生产环境推荐用脚本批量处理，因为项目纹理数量动辄几千张，逐张手动导出既慢又容易漏项。

脚本流程建议按“解析目录 → 按格式转换 → 输出到目标目录 → 生成压缩报告”四步进行，报告里记录每张贴图的原始大小、压缩后大小、格式、耗时和异常状态，方便后续对比优化效果。

5. 纹理压缩工具实操：命令与流程

目前主流的纹理压缩工具有 DirectXTex、ASTC Encoder、PVRTexTool 以及 NVIDIA Texture Tools。下面重点讲 DirectXTex 和 ASTC Encoder 的命令行用法，这两者覆盖 PC 和移动端大部分需求。

5.1 DirectXTex 的 texconv 用法

DirectXTex 是微软提供的纹理处理库，其中 texconv.exe 是最常用的命令行工具，支持 BC 系列格式转换，也可以处理 DDS、TGA、PNG、BMP 等格式输入。

先下载编译好的 texconv.exe，放到独立目录，例如D:\TextureTools\。之后打开 PowerShell 或 CMD，进入输入纹理所在目录，执行下面的命令：

# 将 input.png 转换为 BC7，输出到 output 目录 texconv.exe -f BC7_UNORM -y -o output input.png # 将 input.png 转换为 BC1，并生成 mipmap texconv.exe -f BC1_UNORM -m 8 -y -o output input.png # 将法线贴图转换为 BC5 格式 texconv.exe -f BC5_UNORM -y -o output normal.png

参数说明：

• -f BC7_UNORM：目标格式。BC 系列格式名对应 BC1_UNORM、BC3_UNORM、BC5_UNORM、BC7_UNORM。
• -m 8：生成 8 级 mipmap。根据纹理尺寸和实际需求调整。
• -y：覆盖已存在的输出文件。
• -o output：输出目录。

转换完成后，用图片查看工具或自带调试工具打开生成的 DDS 文件，重点观察色带、边缘纹理和暗部细节。

5.2 ASTC Encoder 实测流程

ASTC Encoder 是 ARM 开源的官方压缩工具，推荐从 GitHub 的 ARM-software/astc-encoder 仓库获取最新 release。它支持多种码率档位，质量参数从-fastest、-fast、-medium到-thorough、-exhaustive不等。质量越高压缩越慢，实际项目中-medium或-thorough已经足够。

# 将 normal.png 压缩为 ASTC 6×6，质量档位 medium astcenc-avx2-x64.exe -i normal.png -o normal.astc 6x6 -medium # 将 albedo.png 压缩为 ASTC 8×8，质量档位 fast astcenc-avx2-x64.exe -i albedo.png -o albedo.astc 8x8 -fast # 压缩为 KTX 容器格式，方便引擎直接加载 astcenc-avx2-x64.exe -i albedo.png -o albedo.ktx 6x6 -medium

输出文件可能是.astc或.ktx容器。Unity 和 Unreal 导入时各有要求，Unity 更推荐直接使用资源导入器中的 ASTC 选项；Unreal 对 ASTC 的支持取决于目标平台，通常需要配置项目设置里的纹理格式后由引擎在打包时转换。

5.3 PVRTexTool 与 GPU 厂商工具

Imagination Technologies 的 PVRTexTool 是历史悠久的纹理压缩工具，支持 PVRTC、ETC2、ASTC、BC 系列格式，GUI 和命令行模式都有。它适合在项目早期快速预览各种格式下的画质差异。

NVIDIA Texture Tools 主要面向 PC 端 BC 格式，附带在 Photoshop 插件中提供可视化对比。做批量生产时，DirectXTex 和 ASTC Encoder 的组合方案已经足够覆盖大多数场景。

5.4 Unity 引擎中的纹理压缩设置

Unity 项目中，导入纹理后选中资源，在 Inspector 的Default和各个平台覆盖页签里设置格式。PC 平台一般选择 BC7 或者 DXT5，移动平台可以选择 ASTC，并指定块大小。需要注意，Unity 的压缩设置在模拟器里经常显示的是编辑器转换结果，最终以真机打包后的表现和 RenderDoc 抓帧结果为准。

6. 纹理压缩后的性能验证方法

纹理压缩做完，必须验证两个维度：显存和带宽是否下降、画质是否可接受。下面给出一套通用验证流程，不依赖特定硬件品牌，任何支持 GPU 性能分析的环境都可以操作。

6.1 显存占用观察

Windows 下可以利用 GPU-Z 的任务管理器，或者 NVIDIA Nsight、PIX for Windows、RenderDoc 抓取帧数据。重点记录以下数值：

• 进程 GPU 专用显存使用量
• GPU 内存带宽利用率
• 纹理缓存命中率
• 单帧 Draw Call 数量和纹理绑定数量

对比同一场景在压缩前后的显存峰值。如果压缩策略正确，峰值显存应该有明显下降，场景切换时的 stutter 出现频率也会降低。

6.2 帧时间与加载时间对比

用 PresentMon 或微软的 PIX 采集一段固定路径的帧时间数据。建议固定一条测试路线，跑 60 秒，对比平均帧、1% Low、加载耗时三个指标。压缩后平均帧不变而 1% Low 明显改善，通常是带宽瓶颈得到缓解的信号；加载时间缩短，说明磁盘读取和资源加载也受益。

测量时需要注意环境变量保持一致：同一系统、同一驱动、同一画质设置、同一帧率上限，关闭后台干扰程序，收集多轮数据取中位数。

6.3 画质对比方法

性能提升如果建立在明显画质损失上，往往得不偿失。对比画质时，推荐在相机视角中放置文字高反差区域、渐变天空、草地、人物面部、金属高光这几类高风险区域，分别截取压缩前后帧，放大到 200% 到 400% 观察：

• 暗部是否出现色块断层。
• 渐变天空是否出现带状条纹。
• 文字边缘是否出现锯齿或模糊。
• 法线贴图细节是否被过度平滑。

如果对比后不确定，可以让团队美术人员盲评，设置“原图/压缩图/原图/压缩图”顺序，记录明显可感知差异的贴图清单，逐张调整压缩档位。

7. Windows 游戏性能优化：批处理辅助脚本

纹理压缩解决的是渲染资源层面的带宽与显存问题。实际游戏运行中，Windows 系统后台服务和电源策略也会干扰帧率表现。如果项目或玩家反馈中经常出现“后台开几个程序后帧率波动”的情况，可以用一段批处理脚本做系统层级的优化辅助。

下面这段脚本覆盖四类通用操作：关闭常见非必要后台服务、调整电源模式为高性能、执行网络延迟基础优化、清理系统临时文件。脚本不会修改关键系统配置，也不会删除用户私人文件，适合在测试机或个人电脑上使用。

@echo off chcp 65001 >nul :: Windows 游戏性能优化辅助脚本 :: 使用方法：右键以管理员身份运行 :: 执行前请保存正在编辑的文档，关闭未保存的工作 echo ======================================== echo Windows 游戏性能优化辅助脚本 echo 适合本地测试或个人游戏运行环境 echo ======================================== echo. :: 1. 检查管理员权限 net session >nul 2>&1 if %errorLevel% neq 0 ( echo [错误] 请右键此脚本，选择"以管理员身份运行" pause exit /b 1 ) :: 2. 调整电源模式为高性能 echo [1/4] 正在设置高性能电源计划... powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c if %errorLevel% equ 0 ( echo 高性能电源计划已激活 ) else ( echo [提示] 电源计划切换失败，可忽略或使用控制面板手动设置 ) :: 3. 清理系统临时文件 echo [2/4] 正在清理临时文件... set TARGET_DIRS=%TEMP% %SystemRoot%\Temp %SystemRoot%\Prefetch for %%D in (%TARGET_DIRS%) do ( if exist "%%D" ( del /f /q "%%D\*.*" >nul 2>&1 for /d %%P in ("%%D\*") do rd /s /q "%%P" >nul 2>&1 ) ) echo 临时文件清理完成，正在被占用的文件已自动跳过 :: 4. 网络基础优化 echo [3/4] 正在刷新 DNS 并重置网络缓存... ipconfig /flushdns >nul 2>&1 netsh int tcp set global autotuninglevel=normal >nul 2>&1 echo 网络缓存已刷新，TCP 自动调整已恢复默认推荐值 :: 5. 关闭常见非必要后台服务（仅测试环境推荐） echo [4/4] 正在关闭非必要服务... for %%S in ( "SysMain" "DiagTrack" "WSearch" ) do ( sc config "%%~S" start= disabled >nul 2>&1 net stop "%%~S" >nul 2>&1 ) echo 相关服务已停止并设置为禁用 echo. echo ======================================== echo 优化辅助脚本执行完毕 echo 部分服务需要重启后完全生效 echo 如需恢复默认，可重新启用对应服务 echo ======================================== pause

脚本里选中的服务不是系统核心依赖，关闭的主要目的是减少硬盘持续读写和后台索引行为。如果你使用的设备不在自己可控范围内，建议先手动确认这些服务的用途再执行。关于 SysMain、DiagTrack、WSearch 这些服务，不同 Windows 版本、不同工作负载下的表现有差异，游戏 PC 上通常可以关闭，办公环境下需要评估是否影响搜索和索引功能。

该脚本应该是“辅助手段”，不是“万能优化”。正式发布项目时，不建议让玩家自行运行此类脚本，而是由引擎在启动时动态检测系统配置，或仅在官方性能指南中提供可选操作。

8. 纹理压缩后的常见问题与排查方法

纹理压缩在工程实践中会遇到不少问题，下面按现象整理一份排查清单。

如果你在压缩后只观察到显存下降，但帧率稳定不变，先别急着否定效果。它说明在当前场景下，GPU 的瓶颈不在纹理带宽，后续优化重点应转向 shader 复杂度、顶点处理或 CPU 提交开销。反过来，如果显存下降的同时 1% Low 帧率也明显回升，那说明此前确实存在资源调度的压力。

9. 纹理压缩最佳实践与工程化建议

纹理压缩优化做得好不好，很多时候取决于项目流程是否规范。下面整理几条长期有效的工程化建议。

第一，建立格式映射白名单。不要让程序员和美术人员在每次导入时自行决定格式。在团队内部维护一张“贴图类型 → 压缩格式 → mipmap 规则 → 最大尺寸”的映射表，并写入资产导入规则或 CI 检查脚本中，减少人工误操作。

第二，压缩前先统一源图标准。源图建议使用无损格式提交，例如 PNG、TGA 或 TIFF，尺寸按分辨率要求设置。压缩环节放到发布构建阶段，而不是让美术在 PSD 里直接导出已经压缩过一轮的图，避免二次质量损失。

第三，保留一套未压缩的高质量版本。原图入库后，压缩版本只是构建产物。这样后续调整压缩参数或者切换平台格式时，可以直接从原始高质量资产重新生成，不需要从已经压缩的图上再次压缩，质量衰减会小很多。

第四，纹理压缩与 mipmap 一起处理。mipmap 链的生成时机最好和压缩在同一流程中完成，避免运行时加载即时生成 mipmap 增加卡顿。远景模糊感强的场景可以减少 mipmap 级数，近景高质量场景可以完整保留。

第五，批量任务必须考虑日志和失败重试。几千张贴图的批量压缩，任何一步失败都不能直接中断。脚本应该输出每张贴图的状态码，失败项单独记录，后续可重试。压缩报告可以包含原始尺寸、目标格式、耗时、压缩后大小、异常原因，方便追溯。

第六，接口化处理压缩任务。如果团队内部有自动化构建系统，可以把纹理压缩封装成命令行或 HTTP 服务，让 CI 流程在构建打包前自动执行。尤其要注意输入输出路径、格式映射参数、版本控制一致性。CI 服务器上如果缺少 GPU，可以选择 CPU 模式运行，虽然速度慢一些，但能把流程完全自动化。

第七，合规与授权提醒。纹理压缩本身不涉及版权问题，但在优化过程中如果使用了第三方素材、游戏截图、人物肖像或商业化美术资源，压缩、发布和分发前都应确认授权范围，尤其是涉及可识别人脸、品牌 LOGO、受版权保护贴图的场景。用于技术测试时尽量使用自建素材或明确标注可自由使用的资源。

第八，先小范围试点，再全量推广。不建议第一天就把项目所有纹理全部批量压缩。正确做法是先选一个代表性关卡，压缩 30 到 50 张贴图，跑性能对比和画质评审，确认格式和参数后，再扩大到全量资产。这样如果发现格式选择不合适，返工成本也可控。

10. 总结与下一步

纹理压缩是游戏性能优化中投入产出比很高的一步：不需要修改核心渲染代码，不需要换引擎，只要把纹理资产格式梳理清楚，就能在显存、带宽、加载时间三个维度同时获得收益。PC 端优先考虑 BC1 到 BC7 的组合，移动端建议重点使用 ASTC 并做好不同块大小的质量验证；工具链上可以先用 DirectXTex 和 ASTC Encoder 的 CLI 跑两批样本，确认格式映射后再接入自动化流程。

最优先要验证的是自己项目里“最大尺寸、最高分辨率”的那几张贴图，对比它们在压缩前后的显存占用和画面差异，同时用 RenderDoc 抓一帧确认实际采样格式确实是压缩格式，而不仅仅是导入器面板里的显示选项。

最容易踩的坑有两个：一是把源图片压缩和纹理压缩混为一谈，二是只做格式设置不做真机验证。前者会导致发布后显存压力没变化，后者会造成移动端实际画质远低于开发期望。

跑通纹理压缩流程之后，可以继续沿着资源优化方向扩展：做更细粒度的 mipmap 裁剪、考虑纹理流送策略、针对不同质量档位准备多套格式预算表，再配合本文末尾的 Windows 系统优化脚本，把运行环境层面的干扰也一并压下来。这套组合做下来，性能曲线通常会有比较明显的改善，值得收藏备用，也建议下一步直接拿到你的真实项目里跑一轮对比测试。