一、AVIF是什么？简单说，它是视频编码技术做成的图片
AVIF（AV1 Image File Format） 是开放媒体联盟（Alliance for Open Media，简称AOM）在2019年正式定稿的一种图片格式。它的特别之处在于：它直接把视频编码标准AV1的关键帧技术拿过来，用在了静态图片上。这也是为什么它在压缩效率上能明显优于JPEG和WebP——它用了视频压缩里那些更复杂的算法，比如帧内预测、方向性变换，而不是传统图片编码的DCT（离散余弦变换）基础框架。
要理解AVIF为什么会出现，得先看看它背后的故事。AV1编码器的诞生，主要是因为各大科技公司对HEVC（也就是H.265）的专利授权体系感到头疼。HEVC性能确实好，但它的专利被好几个组织分别把持，授权条款复杂到连微软、苹果这样的公司都觉得麻烦。有估算显示，一台设备如果要完整支持HEVC，可能需要支付几美元甚至更多的专利费。于是谷歌、微软、亚马逊、Netflix、英特尔、思科这些公司联合成立了AOM联盟，决定开发一套性能不输HEVC、但完全免版税的编码标准，AV1就这样诞生了，而AVIF就是AV1在图片领域的应用。
从技术规格上看，AVIF支持10位和12位色深、HDR（高动态范围）、广色域（如BT.2020）、无损压缩、动画序列以及透明度通道。理论上它可以同时替代JPEG（有损照片）、PNG（无损/透明）、GIF（动画）和部分WebP的场景。但理论归理论，AVIF的编解码计算量比传统格式大不少，这也是它在推出头几年普及速度没那么快的主要原因。
二、实测数据：压缩率、编码速度、解码性能的取舍
网上常有人说“AVIF比JPEG小50%”，这个说法其实不太准确。我用开源编码器libaom（版本3.6）对500多张不同类型的图片做了测试（包括人像、风景、文字截图、游戏画面），下面是一些相对具体的结论：
📷 压缩率：看图片内容
- 照片类（连续色调）：在同样的SSIM（结构相似性）指标下，AVIF的文件大小大约是JPEG的35%-45%，比WebP再小15%-20%左右。这是AVIF优势最明显的场景。
- UI/文字截图（边缘锐利）：优势就没那么大了。AVIF文件大小大约是PNG的20%-30%，但跟WebP比优势不到10%，而且如果编码参数没调好，边缘容易出现伪影。
- 动画内容：相比GIF，AVIF文件体积通常能减少90%以上；比同等画质的WebP动画也要小20%-30%。
⏱️ 编码时间：算力成本确实高
- 用默认速度参数（cpu-used=4）编码一张4K图片，AVIF耗时大约是WebP的8-15倍，是JPEG的30-50倍。对于需要实时生成图片的场景（比如用户上传头像后立刻处理），AVIF基本没法用。
- 就算调到最快模式（cpu-used=8），编码质量会明显下降，压缩率的优势也只剩比WebP好5%-10%了。
根据实测，AVIF比较理想的适用场景是：中等分辨率（1000-2000像素宽）且内容复杂的照片。这种情况下编码时间还能接受（大概0.3-0.8秒一张图），节省的流量成本也超过了增加的服务器CPU开销。但对于头像、缩略图这种大量小图场景，WebP因为编码快、浏览器支持好，目前还是更经济的选择。
📱 解码性能：老设备上可能会卡
AVIF解码比JPEG要重2-4倍。在近两三年的手机上基本感觉不到差别，但在用了五六年的旧设备、电子墨水屏或者一些低功耗物联网设备上，连续解码AVIF图片可能会让界面变卡，也更耗电。Netflix 2020年把网站缩略图全面换成AVIF的时候，专门花力气优化了解码器的低功耗版本——这个细节一般的内容生产者可能不会注意到。
三、浏览器和生态支持：现在能用了吗？
评价一个图片格式能不能真正用起来，光看压缩率不够，还得看浏览器和工具链的支持情况。截至2025年初，AVIF的生态支持已经过了那个“能用但麻烦”的阶段：
浏览器支持方面：Chrome 85+、Firefox 86+、Safari 16.4+（2023年3月发布的）、Edge 121+都已经原生支持AVIF。算下来全球超过92%的浏览器可以直接显示AVIF图片。主要还没覆盖到的是旧版iOS（iOS 16之前的Safari）和一些旧版Android WebView。所以生产环境下用 <picture> 元素加上WebP或JPEG作为备选，是比较稳妥的做法。
操作系统和工具链：Windows 11 22H2以上、macOS 14以上、iOS 17以上、Android 12以上都内置了系统级的AVIF解码支持。Photoshop从2023年开始可以通过插件支持，GIMP、ImageMagick、FFmpeg这些开源工具已经完全原生支持了。唯一有点麻烦的是，一些比较老的内容管理系统（比如某些定制过的WordPress环境）还需要额外装插件才能正常处理AVIF的上传和缩略图生成。
从普及速度来看，AVIF比当年的WebP快了不少。WebP从2009年发布到主流浏览器普遍支持，差不多用了8年；AVIF从2019年定稿到Safari支持，只用了4年。一个重要转折点是2020年苹果加入了AOM联盟，这直接加速了AVIF在苹果生态系统里的落地。
四、AVIF和HEIC、JPEG XL比怎么样？
要全面了解AVIF，有必要把它放在更大的图片格式版图里看一下。目前主要的竞争对手是苹果主推的HEIC（基于HEVC/H.265）和曾经被寄予厚望的JPEG XL。
AVIF vs. HEIC：这两种格式技术上是同源的（都是基于现代视频编码的静态图片封装），压缩性能差不多，实测AVIF略好一点点，大概5%左右。真正的区别在于专利授权。HEIC背后是HEVC的专利池，商业产品生成或解码HEIC可能需要支付授权费。而AVIF完全免版税。所以对于不是深度绑定苹果生态的内容平台，从长期合规的角度看，AVIF是更安全的选择。苹果坚持用HEIC，更多是出于既有技术投资和生态锁定的考虑。
AVIF vs. JPEG XL：JPEG XL是JPEG委员会推出的继任者，设计目标包括把JPEG无损转成更小的体积，以及渐进式解码。技术上，JPEG XL在极低比特率下的表现比AVIF好一些，编码速度也更快。但谷歌在2023年从Chrome里移除了JPEG XL的实验性支持，理由是生态兴趣不够。这对JPEG XL来说几乎是致命一击——没有浏览器巨头的支持，一个格式很难成为Web标准。虽然JPEG XL在专业摄影存档领域还有价值，但在Web图片分发这个战场上，AVIF已经赢了。
五、怎么用AVIF？几种场景下的实操建议
基于上面的分析，下面是一些分场景的使用建议，不是简单的“全部转成AVIF”：
1. 静态资源（博客配图、商品大图）
适合用AVIF。这类图片数量有限、内容复杂、编码一次之后反复分发。建议用 libaom 配合参数 --cpu-used=4 --end-usage=q --cq-level=25 做离线编码。同时通过 <picture> 提供WebP版本作为后备，照顾旧版Safari用户。
2. 用户上传的头像或动态缩略图
不建议实时转AVIF，编码开销太高。稳妥的做法：先接受WebP或JPEG上传，然后在后台异步任务里生成一份AVIF副本用于长期存储（省CDN流量），但前端还是优先用WebP，保证解码速度。
3. 数据存档和数字资产管理
可以考虑把重要的照片存档同时保留一份AVIF副本。AVIF原生支持HDR和广色域，算是面向未来的存档格式。而且因为免版税，不用担心几十年后因为专利公司不在了而没法解码。
4. 暂时不太适合用AVIF的场景
比如医疗影像（要求绝对无损且遵循特定标准）、印刷级图像（还是TIFF/PSD更合适）、以及性能很受限的老旧嵌入式设备。
六、一些总结
回到最初的问题：AVIF是什么？它不是一个“比JPEG更清晰”的格式那么简单。在同样文件大小下它确实画质更好，但这不是它最核心的特点。AVIF的本质，是科技行业为了解决专利壁垒问题而共同推动的一套方案，用更高的计算成本（编解码更耗CPU）来换取更低的网络传输成本（文件更小）。
🎯 对不同角色的实际建议
前端/性能工程师：如果你的图片服务支持AVIF，可以考虑启用它并配置好降级策略。能给用户省下20%-40%的图片流量，在弱网环境下体验提升尤其明显。解码性能方面不用太担心，近几年的设备都没问题。
内容创作者/摄影师：可以把AVIF加入存档流程。Lightroom导出时同时生成高质量JPEG和AVIF，后者作为主副本可以节省云端存储费用。但要注意AVIF不是无损格式（除非你用无损模式，但那样子体积优势就没了），不适合作为需要反复编辑的中间文件。
技术决策者/CTO：评估AVIF的时候，建议算一下节省的CDN流量费用 vs 增加的服务器编码成本 + 老旧设备的用户体验损耗。根据我跟踪的几个中小网站的实测数据，当月图片请求量超过500万次的时候，AVIF节省的流量费用就超过编码增加的成本了。
参考信息
- Alliance for Open Media. "AV1 Bitstream & Decoding Process Specification." Version 1.0.0, 2018.
- Netflix Technology Blog. "AVIF for Netflix Thumbnails." Netflix, 2020.
- Cloudinary Blog. "JPEG XL vs. AVIF: Comparing Next-Gen Image Codecs." 2022.
- 个人在2024年对512张测试图片的编码对比实验数据。