做移动端渲染优化的人迟早得正面刚 ASTC。不管是 Unity 里调纹理格式、Unreal 里改压缩设置还是自研引擎里被 TA 追着要一个“画质不掉但包体变小”的方案最后都会落到同一个开源项目上Arm-astc-encoder。这篇文章不是翻译 README而是我把它当一个大中型 C 工程做源码级排查之后的完整笔记覆盖架构全景、纹理压缩编码器核心流水线、我认为值得关注的源码位置以及真正把 .astc 文件接进图形项目时那些官方文档不会讲的落地细节。如果你正在做移动端纹理优化、对编码器内部机制好奇或者打算二次改造这个编码器这篇应该能帮你省下不少查代码的时间。1. 为什么选 Arm-astc-encoder 做源码级研究ASTC 在纹理压缩里的位置先说背景。ASTCAdaptive Scalable Texture Compression是 ARM 主导制定的纹理压缩标准后来被 OpenGL ES 3.0、OpenGL 4.3、Vulkan 纳为标准功能。它最大的特点是每个 block 固定 128 bit但 block 尺寸可以从 4x4 到 12x12 自由选择也就意味着码率不是死的4x4 是 8 bit/texel6x6 是 3.56 bit/texel8x8 是 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.cppASTC 码流里的整数序列编码/解码。astcenc_partition_tables.cpp预生成的 partition 表。astcenc_threading.cpp内部线程池实现。astcenc_vecmathlib_neon.h / astcenc_vecmathlib_sse4.hSIMD 数学库。我建议第一次接触这个项目的人按“入口 - 分块 - 单块编码 - 码流打包”的顺序读不要一上来就钻 partition 表的细节。代码量看着不小但有明确主线图像被切成若干个 block每个 block 独立走一遍编码流程最后把结果写进 128 bit。2.2 构建和命令行先跑通最小链路构建系统走 CMake几条指令就能编出命令行工具。我常用的构建方式大致是这样mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j8编出来的可执行文件在 Unix 系叫 astcencWindows 下可能是 astcenc-avx2.exe 这类带 ISA 后缀的名字。命令行基本用法很直接# LDR 线性空间纹理6x6 blockmedium 质量 astcenc -cl input.png output.astc 6x6 -medium # sRGB 纹理4x4 blockthorough 质量 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 为例对应调用大致是 glCompressedTexImage2Dinternalformat 要根据 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 SizeBit/texel适合场景注意事项4x48UI、带 alpha 的头像、需要锐利边缘的贴图质量最高包体也最大5x55.12一般角色漫反射、道具贴图均衡选项6x63.56场景地表、大块环境纹理高频细节会有损失8x82大尺度地形、低频噪声类纹理文字、边缘类内容慎用法线贴图和 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 的代码路径然后立刻用诊断模式验证你的理解。这个过程走完后面无论做格式策略还是性能调优心里都会踏实很多。