做移动端渲染优化的人，迟早得正面刚 ASTC。不管是 Unity 里调纹理格式、Unreal 里改压缩设置，还是自研引擎里被 TA 追着要一个“画质不掉但包体变小”的方案，最后都会落到同一个开源项目上：Arm-astc-encoder。这篇文章不是翻译 README，而是我把它当一个大中型 C++ 工程做源码级排查之后的完整笔记，覆盖架构全景、纹理压缩编码器核心流水线、我认为值得关注的源码位置，以及真正把 .astc 文件接进图形项目时那些官方文档不会讲的落地细节。如果你正在做移动端纹理优化、对编码器内部机制好奇，或者打算二次改造这个编码器，这篇应该能帮你省下不少查代码的时间。
1. 为什么选 Arm-astc-encoder 做源码级研究：ASTC 在纹理压缩里的位置
先说背景。ASTC（Adaptive Scalable Texture Compression）是 ARM 主导制定的纹理压缩标准，后来被 OpenGL ES 3.0、OpenGL 4.3、Vulkan 纳为标准功能。它最大的特点是每个 block 固定 128 bit，但 block 尺寸可以从 4x4 到 12x12 自由选择，也就意味着码率不是死的：4x4 是 8 bit/texel，6x6 是 3.56 bit/texel，8x8 是 2 bit/texel。这套灵活性在 BC 系列里看不到，BC1/BC3/BC7 的 block 基本都是 4x4，压缩率上限被卡死了。
硬件解码 ASTC 的成本是固定的，GPU 端一看到 ASTC 格式就能直接采样，不需要像 ETC2 那样搞多个扩展分支，也不像 Basis Universal 那样需要运行时解压成目标格式。这也是 ASTC 能成为移动端主流格式的根本原因：压缩率可调，解码端统一，并且支持 LDR、sRGB、HDR、3D 纹理，覆盖面比 ETC2 大很多。
但 ASTC 只规范了解码器和码流格式，编码端怎么做完全开放。ARM 官方开源的 Arm-astc-encoder 就是这个生态里最完整的编码器实现，而且它不是玩具工程，是会被 Vulkan/GL 驱动工具链、各大游戏引擎、内容制作管线直接调用的项目。源码审计这种工程，能挖出不少通用编码器的设计思路：启发式搜索怎么剪枝、SIMD 怎么写才不拖累整体、多线程如何围绕“block 独立编码”展开。这些经验比单纯会用命令行值钱得多。
研究这个项目时要分两个层次看待源码：一个是“使用层”，关注 CLI 和 API 怎么调用、参数怎么传、输出码流怎么接入引擎；另一个是“实现层”，关注阻塞编码器的搜索空间、误差估计、量化策略。对落地项目来说，理解实现层尤其重要，因为很多坑（比如慢、格式不兼容、质量异常）不是工具 bug，而是你选了某个 block size 或质量预设后，编码器内部做了一系列你没意识到的取舍。
2. 代码库全景：构建系统、目录结构与可执行入口
2.1 仓库布局：真正的核心都在 Source 目录
克隆下来之后，第一眼不用慌，Arm-astc-encoder 的工程结构在同类编码器里算清晰的。顶层有 CMakeLists.txt，核心实现全部在 Source 目录下，命名也基本做到了“看文件名就知道职责”。我阅读时重点关注了这么几个文件：
- astcenc_entry.cpp：库 API 入口，外部调用的压缩/解压都经过这里。
- astcenc_compress_symbolic.cpp：核心压缩流程，block 尺度上的主循环。
- astcenc_decompress_symbolic.cpp：对称的解码流程。
- astcenc_compute_variance.cpp：计算 block 内统计信息，用于决定走哪条编码路径。
- astcenc_averages_and_directions.cpp：估算颜色端点和方向。
- astcenc_ideal_endpoints_and_weights.cpp：求解理想端点和权重。
- astcenc_color_quantize.cpp / astcenc_pick_best_endpoint_format.cpp：端点格式选择与量化。
- astcenc_integer_sequence.cpp：ASTC 码流里的整数序列编码/解码。
- astcenc_partition_tables.cpp：预生成的 partition 表。
- astcenc_threading.cpp：内部线程池实现。
- astcenc_vecmathlib_neon.h / astcenc_vecmathlib_sse4.h：SIMD 数学库。
我建议第一次接触这个项目的人按“入口 -> 分块 -> 单块编码 -> 码流打包”的顺序读，不要一上来就钻 partition 表的细节。代码量看着不小，但有明确主线：图像被切成若干个 block，每个 block 独立走一遍编码流程，最后把结果写进 128 bit。
2.2 构建和命令行：先跑通最小链路
构建系统走 CMake，几条指令就能编出命令行工具。我常用的构建方式大致是这样：
mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release make -j8编出来的可执行文件在 Unix 系叫 astcenc，Windows 下可能是 astcenc-avx2.exe 这类带 ISA 后缀的名字。命令行基本用法很直接：
# LDR 线性空间纹理，6x6 block，medium 质量 astcenc -cl input.png output.astc 6x6 -medium # sRGB 纹理，4x4 block，thorough 质量 astcenc -cs input_srgb.png output_srgb.astc 4x4 -thorough # HDR 纹理 astcenc -ch input.hdr output_hdr.astc 5x5 -fast解压验证也很重要，ASTC 编码器做的是有损压缩，你需要一个能把它解回普通图像的途径：
astcenc -tl output.astc decoded.png跑通这条链路之后，再做源码审计就舒服多了：你对输入输出有了感性认识，再看到代码里的中间数据结构，就知道它在为哪个阶段服务。
2.3 API 入口：库形态的调用方式
除了命令行，这个项目也能作为库被其他工具集成，这也是图形项目落地的常用形态。API 的核心抽象是 astcenc_config 和 astcenc_context。一般流程是先 astcenc_config_init 初始化配置，再分配 context，循环调用 astcenc_compress_image 压缩多张图片，最后释放 context。
阅读 astcenc_entry.cpp 时，我建议关注传入的 compression mode：是同步压缩单张图，还是多线程模式。多线程模式下库内部自己管理 job 调度，你不用在外部起线程，但要注意它要求多个压缩调用互斥使用同一个 context，跨线程并发调用同一个 context 是不安全的，需要自己加锁或每个线程一个 context。这一点在接入引擎时特别容易踩。
3. 核心编码流水线逐级拆解：从像素块到 128bit 码流
3.1 先搞懂 ASTC 码流里到底装了什么
ASTC 的一个 block 只有 128 bit，但它要描述的信息不少：分成几个 partition（可以理解成把 block 划成若干区域，每个区域独立用一组颜色端点）、颜色端点格式、权重网格、权重量化等级，等等。这是 ASTC 灵活性的代价：编码器要做的事不是在“固定格式”里选最优参数，而是在一个组合爆炸的搜索空间里找“足够好”的方案。
源码里对应的是 symbolic 中间表示，也就是还没有压缩成最终 128 bit 的符号化表示。编码流程的核心是在符号域里不断尝试各种配置并计算误差，最后把胜出的配置通过整数序列编码写到物理码流里。理解这层区分很重要，因为源码审计的大部分工作都围绕符号域的候选生成和误差排序，而不是直接操作 bitstream。
3.2 单 block 编码的主流程
通读 astcenc_compress_symbolic.cpp，单 block 的编码流程可以简化成下面这条线：
- 读取 block 内像素数据，计算基础统计量。
- 如果 block 内容非常平坦，走单 partition、低开销快速路径，不值得做复杂搜索。
- 对复杂 block，枚举候选 partition 集合，每个 partition 内估算“理想”的颜色端点和权重。
- 根据估算结果选择候选的 color endpoint mode 和量化位数。
- 在候选配置上做实际量化、编码，并反量化回像素空间，计算与原始 block 的误差。
- 选出误差最低的候选，写入 symbolic block，最后转为物理码流。
这里最让我意外的是第 1 步和第 2 步涉及的工作量。很多人以为 ASTC 编码慢是因为后面搜索太多，其实平坦块的快速路径用得极其频繁，真实游戏纹理里大面积平滑渐变、天空、纯色 UI 块非常多，快速路径能直接跳过大部分搜索，对整个编码时间的影响非常大。源码里 astcenc_compute_variance.cpp 的存在感被严重低估。
3.3 启发式搜索：在组合爆炸里做剪枝
ASTC 编码器本质上是一个启发式搜索器。理论上要找到全局最优，就得把 partition、plane、endpoint format、weight quant 的所有组合都试一遍，但那样一个 1024x1024 的图可能要压一年。所以源码里大量做的是“用低成本指标先筛掉明显不行的候选”。
比如 partition 选择阶段，不会每个 block 都把一百多种 partition 全试掉，而是先通过方差、颜色分布等统计量估算一个方向性得分，把候选压缩到几个最可能合适的 partition。权重求解阶段也是先解一个理想连续解，再把它量化到若干离散等级，而不是直接穷举量化组合。
源码审计给我最大的启发是：这种“先连续近似、再离散量化、最后用真实误差函数复查”的三段式策略，是整个编码器性能和质量的平衡点。你别想着把每一步都做成精确最优，计算量撑不住；关键是在初期用便宜的近似砍掉搜索空间，把宝贵的工作量留给最终候选。
3.4 误差计算：感知质量才是裁判
真正的误差计算被放在“编码后”阶段：把候选配置编码成码流再解码头，得到解码后的像素，和原始像素做比较。这里必须强调，ASTC 编码器不是简单算 PSNR，而是有一套感知误差度量逻辑，尤其在 HDR 模式下会调整不同亮度范围的权重。
看代码时你会发现它会在多个误差模型里做切换，比如基于 RGB 空间的误差、基于 HDR 亮度比例的误差等。这意味着你在图形项目里验收质量时，单看 PSNR 不一定能反映编码器的真实取舍。它可能在视觉上更讨喜，但数值上不是最高的。反过来说，你自己做自动化测试时也不要只看一两个指标，最好结合主观对比图。
3.5 诊断工具：源码审计者的利器
这个项目里有个经常被忽略的功能：诊断输出。开编时会根据宏开启 trace，把每个 block 的选择过程（候选数、每个 partition 的尝试、量化前误差、最终误差）都打出来。源码审计时这个功能非常有用，你可以拿一张小图跑一遍，观察编码器在遇到不同内容时到底做了什么决策。
我是这么用的：先裁剪一个 32x32 的小区域，用诊断模式跑一遍，看它选了几个 partition、用了什么 endpoint format，再对比我读代码时的推断，确认没有理解偏差。这个手段比光看代码高效得多，强烈建议做源码审计的人都跑一次。
4. 源码审计重点：SIMD、多线程与边界处理
4.1 性能关键路径和 SIMD 分派
ASTC 编码慢是出了名的，所以项目里对热点代码做了大量 SIMD 优化。vecmathlib 系列头文件就是为此存在的，它封装了 NEON、SSE4/AVX2 的向量运算，上层代码尽量不直接写平台汇编。
我审计时重点看的是误差计算、颜色空间转换、权重求解这几个模块，因为它们在单 block 内会被调用上千次。SIMD 的收益是实打实的，但这带来一个跨平台一致性问题：不同 ISA 下浮点运算顺序可能不同，导致同一张图在不同 CPU 上压出的码流有细微差别。对这个现象不用太担心，因为 ASTC 解码器是纯整数、确定性流程，一旦码流生成，在 GPU 上解码出来的结果是一致的。
4.2 多线程设计：block 独立是最大的并行红利
ASTC 编码天然适合并行：图像切分成 block 之后，每个 block 的编码互不依赖，只有最后写文件时需要按顺序拼码流。astcenc_threading.cpp 里的线程池就是围绕这个模型设计的，任务队列按 block 索引分发，工作线程各自处理，完成后把结果放到对应 slot。
源码审计里值得关注的是内存分配策略。每个 block 编码过程中会产生大量中间 buffer，如果每个线程每次任务都做堆分配，分配器会成为隐形瓶颈。我看代码时注意到项目在 context 内部维护了线程级复用缓冲区，尽量避免反复 malloc。这提醒我接入项目时不要在外层破坏这种设计，比如用外部线程池去并发调用同一个 context，会导致缓冲区互踩。
4.3 边界情况：非 4 倍数尺寸怎么处理
图像宽高不总是 block 的整数倍。源码里这里是 clamp 到边缘处理：block 越界部分的像素用最近边缘像素填充，保持编码器的数学连续性。这个处理看起来简单，但和 GPU 解码时的行为必须对齐。如果你在引擎里加载 ASTC 时把尺寸信息填错了，或者自己处理 padding 时没注意，就会出现边缘条纹。
另外 ASTC 文件头有个容易被忽略的细节：magic number 是 0x5CA1AB13，然后是 block 尺寸 x/y/z，再是纹理尺寸的 24 bit 小端值。图形项目解析这个头时，建议专门写一个单测覆盖非对齐尺寸、3D 纹理、大纹理（尺寸超过 16M texel）的情况。
4.4 可移植性陷阱和代码质量印象
这个项目整体 C++ 风格偏传统，大量使用数组和结构体而非深层继承，阅读负担不大。但有两点我要提醒：一是它依赖编译器对特定内置函数的支持，比如 __builtin_clz、memcpy 优化等，换到不常见工具链时需要注意；二是库 API 的线程模型是显式约定，不满足约定会得到数据竞争而不是报错，这点在接入引擎任务系统时要格外小心。
代码风格上也有些老派的地方，比如部分函数很长、局部状态多，但逻辑还算直白。对审计者来说，建议用 IDE 的调用层级功能，重点跟踪 compress_symbolic_block 一条线的调用路径，不要被外围文件带偏。
5. 图形项目落地：接入方式、推荐参数与质量验收
5.1 离线压缩还是运行时压缩
落地 ASTC 的第一件事是定场景。绝大多数图形项目应该选择离线压缩：在资源导入或构建阶段把 PNG/TGA/HDR 压成 .astc，运行时直接加载压缩数据。这样可以接受几分钟级的压缩耗时，把质量预设开到很高。
运行时压缩只适合极少场景，比如动态生成纹理又不能缓存结果。这种情况下你只能用 fast 甚至 fastest 预设，压缩质量会明显下降，而且移动端 CPU 压力很大。我的建议是：如果能在编辑期解决，绝不要拖到运行时。
5.2 引擎侧的接入方式
把 .astc 接进渲染管线的核心步骤有两步：一是解析文件头得到 block 尺寸和纹理尺寸，二是把压缩数据通过纹理上传 API 喂给 GPU。
以 OpenGL ES 为例，对应调用大致是 glCompressedTexImage2D，internalformat 要根据 block size 选择 GL_COMPRESSED_RGBA_ASTC_4x4_KHR 等格式。Vulkan 则对应 VK_FORMAT_ASTC_4x4_UNORM_BLOCK 或 VK_FORMAT_ASTC_4x4_SRGB_BLOCK。这里最容易出错的是 sRGB 标记：如果原始图是 sRGB，压缩时用了 -cs，上传时却指定 UNORM 格式，采样结果会整体偏亮或偏暗，因为硬件不会自动应用 sRGB 转换。
如果团队里有自研引擎，我建议把 ASTC 的解析和上传封装成一个独立模块，单独提供 mipmap 生成、SRGB 切换、3D 纹理支持三个开关。这样后续升级编码器版本，或者增加新的 block size，只需要改配置表，不需要动渲染管线的纹理创建逻辑。
5.3 block size 怎么选：码率、画质和设备的三角博弈
下面这个表是我在实际项目里的选择逻辑，供参考，不是唯一标准。
| Block Size | Bit/texel | 适合场景 | 注意事项 |
|---|---|---|---|
| 4x4 | 8 | UI、带 alpha 的头像、需要锐利边缘的贴图 | 质量最高，包体也最大 |
| 5x5 | 5.12 | 一般角色漫反射、道具贴图 | 均衡选项 |
| 6x6 | 3.56 | 场景地表、大块环境纹理 | 高频细节会有损失 |
| 8x8 | 2 | 大尺度地形、低频噪声类纹理 | 文字、边缘类内容慎用 |
法线贴图和 HDR 贴图要单独看。法线贴图的精度直接影响光照质量，我通常不压到 6x6 以下，而且会先做通道重映射测试，有些方案会把法线 X/Y 存到 RG，利用 ASTC 的多通道灵活性来保证精度。HDR 贴图（比如环境光照）用 -ch 模式，block size 一般 5x5 或 6x6，配合 Cubemap 打包时要确认引擎是否支持 ASTC 的 cube array 格式。
5.4 mipmap、sRGB 和 3D 纹理的落地细节
mipmap 必须在压缩前生成，绝对不能压缩后再做 mipmap 缩放。压缩数据不能直接滤波，硬件只是采样已解码的 texel，如果 mip 链是压缩后缩出来的，会带来严重的混叠。正确的做法是：解出原始图像 -> 生成完整 mip 链 -> 每一级单独压缩 -> 拼接上传。
sRGB 纹理用 -cs 参数，但要注意编码器的 sRGB 处理和引擎侧的 sRGB 标记是否一致。HDR 纹理建议用 -ch 并且检查目标平台是否把 ASTC HDR 当作可选特性，很多移动 GPU 对 HDR ASTC 的支持并不像 LDR 那样普及。3D 纹理（比如体素数据、体积雾）则要设置 block_depth 大于 1，比如 4x4x4，功耗和带宽会更友好。
5.5 质量验收：不要只盯 PSNR
我建议建立一套自动化验收脚本，对每种 block size 和质量预设生成对比图。最简单的方式是解压回 PNG，然后用 ImageMagick 或 Python 计算 RMSE/PSNR，但结果要结合人工抽检。ASTC 编码器在感知指标上做了优化，有些 PSNR 略低的结果主观看起来反而更干净，所以脚本指标只用来筛选明显劣化，最终拍板交给视觉评审。
6. 实测经验与容易踩的坑
6.1 block size 选大的时候，UI 贴图最容易翻车
我第一次在项目里大规模上 ASTC 时，为了压包体，把所有 UI 纹理统一用了 6x6。结果文字边缘出现明显“毛刺”和色晕，尤其是深色背景上的白字。UI 贴图的内容通常包含高频边缘，并不适合低比特率压缩。后来我把 UI 分类单独设成 4x4，并把带 alpha 的图片全部走 4x4，问题才消失。
建议在资源规范里直接按纹理类型定义格式白名单，而不是给美术一个“选格式”的下拉框，否则后面一定有人为了省包体选错格式。
6.2 alpha 边缘的紫边问题
带 alpha 的纹理，比如头发、树叶、粒子，在低码率下很容易出现边缘异味。原因是颜色和 alpha 共享同一个 128 bit block，压缩时误差会互相挤占，边缘像素的 RGB 可能被“修正”到很奇怪的值，在透明边缘处就表现为紫边。
处理办法有三个：一是提高这类纹理的 block size 到 4x4；二是在压缩时优先保证 alpha 精度；三是在 shader 里对 alpha 阈值做处理，但这只是补救。源码审计角度看，这其实是编码器的误差度量在颜色和 alpha 之间做权重分配的结果，编辑器没有暴露太细的权重配置，所以你只能通过 block size 和主观测试来控制。
6.3 压缩时间预算：thorough 不是默认选项
“提高画质”最容易犯的错就是把所有纹理都开到 -thorough 甚至 -exhaustive。压缩一张 2048x2048 的图，在 medium 下可能只要几十秒，但切到 thorough 后时间会翻好几倍，如果 CI 机是普通配置，整个构建时间直接爆炸。
我的做法是：日常开发用 medium，发布前对关键纹理（角色贴图、UI）单独跑 thorough，而且只跑增量 diff，避免每次全量压缩。编码器提供质量预设的本意是让用户按场景取平衡，不是所有纹理一个预设走天下。
6.4 版本升级后码流变化别慌
不同版本的 astcenc 对同一张图的输出码流可能不同，因为编码器一直在改进启发式搜索策略。这不会导致 GPU 解码兼容问题，因为解码格式是标准化的，但会导致“同一资源在不同版本工程里打包出来的 hash 不一致”。如果团队有资产 hash 校验，升级编码器后要准备好全量重压资源，并把这个成本提前同步给构建负责人。
6.5 多线程配置要和 CI 机内存匹配
库内部的多线程数是可配置的。默认按 CPU 核心数开线程，单个线程的临时内存和峰值内存并不小，在内存受限的容器或 CI 机器上可能 OOM。我遇到过 16 核机器上压缩 4K 纹理连续跑多个任务导致构建机内存吃满的情况，后来把线程数显式限制到合理值，比如物理核数的一半，并限制同时并发的压缩进程数，问题就解决了。
这条经验也适用于本地制作：不要盲目相信“线程越多越快”，编码器的工作集不小，线程多了后缓存命中和内存带宽都会恶化，速度提升并非线性。
6.6 最后的实用技巧：给纹理做预算分配
我目前项目里最有效的一个做法，是给不同用途的纹理做“码率预算表”：角色、UI、载具这类焦点资源给 4x4 或 5x5，环境、地形、远景给 6x6 或 8x8。然后写一个扫描脚本，在构建阶段检查每张纹理实际使用的 block size 和白名单是否匹配，不匹配直接报错。这个流程跑起来之后，包体和画质基本稳定，美术也不再频繁来问“为什么我的贴图糊了”。
ASTC 是个好格式，但它的灵活性也是一把双刃剑。理解编码器的源码、知道它内部如何在质量和速度之间取舍，你才能真正用好它。我的建议是：上手先跑通命令行链路，再花一个下午跟踪 compress_block 的代码路径，然后立刻用诊断模式验证你的理解。这个过程走完，后面无论做格式策略还是性能调优，心里都会踏实很多。
