前言
在好几个平台上看到有应用 avif 格式的图片了，AVIF 在这篇【第2908期】现代图片性能优化及体验优化指南中略有介绍。今日前端早读课文章由 @杨一沐、@李代琛、@甄玉美、@DCjanus 分享，公号：哔哩哔哩技术授权。
正文从这开始～～
背景
图片库加载服务是为 bilibili 打造的移动端一站式解决方案，集图像加载、显示、处理、监控于一体，以高可用、高性能、可高度定制、数据服务、省流量五大核心优势被公司各个业务接入使用，经过长期的迭代与维护，已成熟稳定。
在如今越来越看重体验的大环境下，对图片库的要求也日益攀升。从成本的角度来看，使用 AVIF 格式可以节省大量的网络带宽和存储空间，减少网站加载时间，并且可以改善用户体验，进而提高网站的效率和收益，从而节约大量的费用。
AVIF 格式能够带来许多优势，首先，AVIF 格式具有明显的压缩率优势，可以比其他常用图片格式（如 JPEG、PNG）节省更多的存储空间，减少图片加载所需时间和带宽，提高网站加载速度，提高访问者的体验；其次，AVIF 格式丰富的特性支持，可以支持更多的设备和浏览器，提高图片的可用性，并可以免专利费的优势；最后，AVIF 格式支持图片的质量优化，可以保证图片的质量，同时节省更多的容量。
一、AVIF 图片格式研究
1、图片格式编解码研究
图片格式 AVIF 编解码详解进行 AVIF 图片格式的研究，AVIF 格式相比其他图片格式，有着更高的压缩比，可以支持更多的色彩深度，支持 alpha 通道，支持更多的图片尺寸，支持动态图片，支持更多的压缩选项，可以更有效地利用计算资源，支持多层编码，支持非码率压缩，支持虚拟化和硬件加速，支持缩略图和视频帧等。
2、AVIF 在 B 站落地的调研
2022 年以前，B 站主流图片格式为 WebP，在对基础设施成本做回顾的过程中，定位到静态资源 CDN 成本是重要的组成部分。随着业界技术的逐渐成熟，经过相关调研，我们认为 AVIF 在 B 站大规模落地存在可行性。
在相同格式相同编码器下，可以简单的认为编码速度、图像质量与图片体积构成一个不可能三角，需要通过调整编码速度参数（下称 speed）与图像质量参数（下称 quality），在三者之间做取舍。
我们选取了三百万线上真实的缩略图请求，于实验环境进行回放，尽可能贴近 B 站实际使用场景。对同一个缩略请求，我们会使用线上现有编码参数，生成 PNG 和 WebP 两个版本，并用几个不同档位的 speed 和 quality，生成若干个 AVIF 版本，其中 PNG 被认为是无损格式，用作比较基准。
PSNR 可以被用于衡量原图与编码后图片的差异大小，一般大于 30 dB 即可认为人眼较难察觉出图像差异，大于 20 dB 被认为人眼观感差异不明显。PSNR 不能代替人类主观评价，但定量实验中，我们需要一个客观指标。无特别描述的前提下，下文提及 WebP/AVIF 的图像质量时，指的是 PSNR (PNG → WebP) 和 PSNR ( PNG → AVIF ) 的数值大小。
经过持续数天的流量回放实验，我们有以下定性结论：
speed 对编码耗时影响显著，对图像质量与图片体积影响不大。
相同 speed/quality 的前提下，图片越大，AVIF 相对 WebP 的体积优势越明显。
相同 speed / 图片大小 的前提下，质量 (quality) 越高，AVIF 相对 WebP 的体积优势越明显。
对齐图像质量（PSNR 差值不超过 1）的前提下，我们有以下定量结论：
B 站主流缩略图场景下，AVIF 相比 WebP 平均体积优化在 35% 左右。
B 站主流缩略图场景下，AVIF 相比 WebP 耗时增长 4 ~ 5 倍，图片越大，耗时增长越明显，视频预览图等超大图场景，耗时增长 20 倍以上。
B 站主流缩略图场景下，AVIF 4 线程编码耗时约为单线程的 73%，CPU 开销是单线程的 115%，且进一步增大并发度的收益不高。
浏览器兼容性角度，caniuse.com（
实际根据对 B 站网页端访问日志的分析，目前超过 50% 的用户浏览器支持 AVIF。
二、分端实现
图片库的管理以及服务的部署，进行图片的加载、显示、处理等操作。
1、服务端架构
B 站图片服务底层使用 ImageMagick 作为核心的图片处理库，ImageMagick 设计上是针对桌面场景手动处理图片，着眼于功能的丰富性。我们在落地服务端的过程中，修改了部分代码，以适配在线服务的性能与稳定性需求，因定制化较强，遗憾未能回馈上游。在 AVIF 处理方面，我们使用 libheif 集成 libaom 编码 AVIF。
从前文可以看出，相比 WebP，AVIF 编码耗时显著增长。我们在 B 站概念版客户端进行了较长时间的 AVIF 灰度实验，用户侧八十分位图片加载耗时等埋点指标显著劣化，预期会对用户留存有较大影响，无法满足业务需求。多次尝试优化 AVIF 编码器后，没有获得编码速度上的显著提升，AVIF 推进进度暂时搁置。
某次重构线上代码时，发现历史上曾有用户将动图伪装成普通 PNG 上传，绕过业务限制，获得了酷炫的动图头像（该漏洞已被修复）。受此启发，图片服务架构从纯在线架构演进到了在离线混合架构，以下是相关解释：
1、背景：简化后的缩略图链路为 用户 ↔ 第三方 CDN ↔ B 站内网 CDN ↔ 图片服务 ↔ 原图存储，其中 CDN 主要通过 HTTP Response 中的 Cache-Control 头决定资源缓存多久，默认是一个极长的数值。
2、前提：第三方浏览器和 B 站 APP，均可以根据响应内容而非 URL 后缀名决定所需图片解码格式，且 B 站场景下，图片资源的访问有较大聚集性。
3、思路：某个 AVIF 缩略图请求首次请求时，图片服务返回一个缓存有效期较短的 WebP 资源。
a. 同时触发离线任务，产出对应的 AVIF 缩略图，推送到 Boss 中，配合一个较长的缓存有效期。
b. 同一请求重新穿透到内网时，直接命中 Boss 中的 AVIF 资源并返回。
Boss 是 B 站自研对象存储，相关实现介绍：https://www.bilibili.com/read/cv16653640
4、验证：
a. 体验视角，回收概念版实验数据后，确认 AVIF 加载耗时于 WebP 无显著劣化。
b. 成本视角，AVIF 请求中降级所用的 WebP 流量占 2%，带宽成本收益不受影响。
5、成本：
a. 额外的存储成本，但相比 CDN 带宽收益，可以忽略不计（存储成本占带宽收益 1% 以下）。
b. 额外的计算成本，多出了用于降级的 WebP 资源需求，相比 AVIF 的 CPU 需求，不算特别显著（ 计算成本增长不超过 20%）
附，源站架构简图：
2、Web 端实现
通过分析线上页面的埋点信息，我们发现在 B 站 Web 端请求中，约有一半的浏览器不支持 AVIF 格式，主要是 Edge 浏览器。为了兼容这部分用户，我们需要一个合适的自动降级方案。
最初，我们计划所有用户使用相同的 URL，并根据 HTTP 请求头中 Accept 字段智能协商图片格式（WebP 或 AVIF）。但由于 B 站图片资源同时使用多个第三方 CDN 厂商，在标准实现细节上存在差异，难以保证该方案可靠性。
后来，我们采用 HTML picture 标签提供若干 source 元素，并让浏览器根据其支持的图片格式自动选择对应的 URL：优先请求 AVIF 格式；如果浏览器不支持，则降级到 WebP；对于极少数不支持 WebP 的浏览器，则进一步降级到 JPG/PNG 格式。
由于 B 站 Web 端历史积累较多，在短时间内无法完成全量改造。目前已经开发出统一图片组件，并按接入业务优先级逐步推广。首页、播放页等核心场景已经完成了接入工作。
3、移动端处理
解码器选择
客户端本地处理 AVIF 图片解码采用的是开源库 libavif，因为 AVIF 实际上是基于 AV1 格式的视频帧进行处理，所以 libavif 库也有多个可选视频解析库来作为底层能力的提供者。而我们选择 dav1d 的原因如下：
dav1d 是一个 AV1 软件解码器，AV1 是开放媒体联盟在 2018 年发布的一个视频编码标准，用于互联网视频流，包括视频聊天、视频云直播（https://cloud.tencent.com/product/css?from=10680）、云点播 VOD（https://cloud.tencent.com/product/vod?from=10680）等。
dav1d 是一个 VideoLAN 的项目，在 2-clause BSD 许可下开源。dav1d 的目标是快速、高效，包含帧级、tile 级、后处理滤波的多线程，以及平台优化包括 ARM (Neon）, X86 (AVX2/SSSE3)。
VideoLAN 的主席 Jean-Baptiste Kempf 在其博客上透露了 AV1 解码器 dav1d 的最新进展，和 libaom 相比，dav1d 性能普遍提升 100%，最高提升 400%。
dav1d 由 VideoLAN，VLC 和 FFmpeg 联合开发，项目由 AOMedia 赞助
此外，Jean-Baptiste Kempf 还介绍了 dav1d 的其他关键改进：
dav1d 支持所有 spec 和功能以及 8bits 和 10bits 色深
已经完成包括 Film Grain, Super-Res, Scaled References 等功能，并全部支持 8bits 和 10bits 色深，正在开发公有 API
开发工作已经覆盖 99% 的功能，通常一个 issue 会被在几天内搞定。
编译器方面已经支持大部分流行的桌面 CPU，已经开始开发移动端和古老的桌面 CPU 的编译器、
减少了 C 语言代码的体积。
已经准备好了针对 SSE 和 ARM 指令优化，ARMv8 也准备好了。
请求策略
得益于统一的图片框架，我们能够以最小的代码改动覆盖几乎所有应用场景。业务指定图片资源与缩略指令时，统一图片框架会根据服务端动态下发的策略，分业务、分场景决定是否获取对应 AVIF 资源。
监控及降级策略
BiliImage 框架会对图片的解码流程进行详细的监控，包括但不限于内存、磁盘、网络的读取耗时以及解码耗时、图片解析异常等重要数据。
BiliImage 支持自定义解码器，对于一种新的格式的图片处理，我们只需定义好 decoder 并插入到 image pipline 中即可。解码器支持热插拔，我们通过一系列的校验措施来保证 AVIF 图片处理的稳定性。
应用启动时，我们会对本地存储的一张 1x1 的 AVIF 图像进行预解码，若解码失败则禁止该设备在这次生命周期内进行 AVIF 图片请求
配置设备维度的黑名单，由于 AVIF 图片解码对 CPU 性能要求较高，针对线上监控中性能表现不佳的老旧机型，会做特殊处理
踩过的坑及怎么爬出来的
a. Android
fresco 性能问题
主站的图片处理框架基于 Fresco 构建，在添加 AVIF 解码能力的时候，我们发现图片的内存、磁盘读取耗时以及解码耗时相比于同样大小的 WebP 文件均有较大幅度的增长，甚至某些指标达到了近十倍的差距，这与预期不符。通过阅读 Fresco 源码发现，一张图片从请求到展示到用户界面，其数据流会被预定义的各种 producer 和 consumer 进行处理，那么我们就可以通过代码插桩以上两个处理器的所有派生类，来分析具体的耗时瓶颈。最终我们定位到一个高频的调用方法，parseMetadata。在该方法中 Fresco 会预解析图片的信息，而对于不支持的图片格式，则会强制使用系统的 BitmapFactory 进行处理（Android12 以下的版本不支持 AVIF 格式）。通过修改 Fresco 代码，我们修复了这个问题：在执行 parseMetadata 方法前做一个判断，当识别到 AVIF 格式的图片时略过这步处理，图片相关信息从自定义 decoder 中获取。（最新版本的 Fresco 已经支持 setUseCachedMetadata 方法来复用 parseMetadata 的处理结果）
系统区域解码兼容性处理
Android 系统提供了 BitmapRegionDecoder 工具类来处理超大图，支持传入尺寸参数来进行区域解码，但遗憾的是 BitmapRegionDecoder 暂不支持 AVIF 格式的区域解码操作，当尝试进行解码的时候会抛出异常。针对这个问题，我们提供了接口，允许业务方针对大图场景禁用 AVIF 加载，但是这无法杜绝后续业务方的误用。所以我们通过 Ghost 工具 hook 了 BitmapRegionDecoder#newInstance 方法，在执行该方法之前，校验图片文件的前 32 位数据，若为 AVIF 格式，测试版本会直接抛出异常，而发布版本则会进行埋点上报来通知业务方进行修改。
b.iOS
AVIF 支持预乘格式
AVIF 图像格式进行图像处理时，例如缩放、旋转、裁剪等操作，需要将图像标记为 “预乘” 的格式，以确保图像颜色的正确性。在 Conversion（转换）中 AVIF 图像处理，需要将图像标记为预乘格式，以避免颜色失真。对于非预乘的图像格式，需要进行转换，以将其转换为预乘格式，然后再进行处理。这个过程可以通过将颜色值除以 alpha 值来实现，以得到预乘的颜色值。
支持 libavif 0.9.1
支持最新版本的 libavif 编解码库，该库包括了一些新的特性和改进，以提高 AVIF 图像的编解码性能和质量。
avifdec：添加 --dimension-limit，指定应该容忍的图像尺寸限制（宽度或高度）
avifdec 是用于解码 AVIF 图像的工具，可以通过添加 --dimension-limit 参数来指定应该容忍的图像尺寸限制，以避免解码超大尺寸的图像导致内存溢出和程序崩溃。
fix vImageConvert 失败时的双重空闲内存问题
vImageConvert 是苹果开发的一个图像处理函数库，可以用于对图像进行转换和处理。在使用 vImageConvert 进行图像处理时，可能会出现双重空闲内存的问题，导致内存泄漏和程序崩溃。修复这个问题需要进行内存管理的优化和错误处理的改进等方面。
fix ICC 配置文件、缓冲区和 AVIF 编码内存泄漏
ICC（International Color Consortium）是一种用于颜色管理的标准，包括颜色空间和颜色配置文件等。在处理 AVIF 图像时，可能会涉及到 ICC 配置文件和缓冲区的使用，如果处理不当可能会导致内存泄漏。修复这个问题需要对内存管理和 ICC 配置文件处理进行优化。为此移动端 7.8 版本以前客户端会有偶像的解码变成黑白图。
fix 动画 AVIF 解码失败和解码动画图像泄漏
在解码动画 AVIF 图像时，可能会出现解码失败和内存泄漏的问题。修复这些问题需要涉及到 AVIF 解码器的开发，包括内存管理等方面。
经过一段时间的各方面验证，解决 AVIF 图像解码相关的技术问题涉及到图像处理、解码算法、内存管理、错误处理等多个方面。需要对各个方面进行细致的分析和优化，解决这些问题，并提高 AVIF 图像的解码性能和稳定性。
经过一系列的性能优化措施后，我们配合测试部门进行了天马封面图专项自动化测试，双端测试覆盖图片共 15000 张左右，基本涵盖了市面上所有的主流机型。测试结果表明 AVIF 图片在用户视觉体验上相比于其他格式的图片没有明显降低，内存使用、CPU 占用率、平均 FPS 也没有明显的波动。
三、业务落地
对接公司业务，进行图片库的定制，保证服务的可用性及性能。
1.Web 端
完成播放页、首页等核心场景覆盖，伴随日常业务迭代，渐进式推广中。
2. 移动端
移动端落地计划的前置：
在引入 AVIF 之前，评估现有业务中所使用的图片格式，并确定哪些图片可以被 AVIF 替换。在评估中考虑的因素包括：图片类型、图片大小、使用场景、压缩质量和压缩率等。
AVIF 目前在移动端的支持程度够不够完善，确定需要支持的移动端版本型号，硬件等，以便在决定是否使用 AVIF 时考虑到兼容性的问题。
引入 AVIF 后，需要进行性能和效果的评估，以确保引入 AVIF 后能够满足业务需求。这些评估可以包括：页面加载速度、图片渲染速度、内存占用率、CPU 占用率、图像质量和文件大小等。
在确定那些业务和格式使用 AVIF 的图片和支持的系统版本，品牌，可以逐步引入 AVIF。先在哔哩哔哩蓝板（概念版）或新功能中尝试使用 AVIF，以评估 AVIF 的效果和兼容性，然后再逐步应用到其他业务中。
在引入 AVIF 后，需要对其进行监控和优化，以确保其能够持续地满足业务需求。这些监控和优化可以包括：监控页面加载速度、图片渲染速度、内存占用率、CPU 占用率、图像质量和文件大小等，并根据监控结果进行优化。
四、数据监控
1、服务端监控
为观察 AVIF 上线后的各项指标，在既有 QPS、耗时、SLO 外，还针对 AVIF 离线处理的特性，添加了 AVIF 专属监控。
其中 fallback 表示 AVIF 请求降级到 WebP 并触发离线任务，cache_hit 表示当前 AVIF 请求已在之前的请求中完成处理，直接从缓存中获取 AVIF 并响应。
2、移动端监控
图片监控体系
实时数据
展示 AVIF 图片的请求耗时、错误率、访问量、响应包大小等指标。
通过监控数据，定期分析 AVIF 在线运行情况，找出可能的性能瓶颈和问题点。
请求耗时：分析请求耗时的分布，找出请求较慢的原因，如网络延迟、服务器处理能力不足等，进行相应优化。
错误率：观察错误类型和分布，排查可能的故障原因，如图片解码失败、服务器错误等，并采取措施修复。
访问量：分析访问量的变化趋势，预测系统的负载情况，提前做好资源扩展和优化准备。
响应包大小：监控图片大小分布，对于过大的图片，分析原因并优化压缩算法，降低用户的流量消耗。
根据监控数据和分析结果，不断优化 AVIF 的使用策略和性能表现，提高用户体验。同时，将监控指标与业务指标相结合，评估 AVIF 在实际业务场景中的效果，为后续优化提供依据。
大盘带宽
业务告警
3、带宽收益
前期，我们在 B 站移动端完成视频封面场景的全面 AVIF 化，回看 CDN 数据时，可以观察到：在该场景下，AVIF 体积 / WebP 体积 ≈ 63%，每年为公司节约数百万的带宽成本。后续进一步推进 AVIF 覆盖情况，预计可再节约每年数百万的 CDN 带宽成本。
五、优化与维护
1. 推广过程中遇到的问题
a. 在线资源池容量
在 B 站的多个自建 IDC 中，绝大多数容器化业务部署在 K8s 集群中，混部在同一套资源池里，由内部容器平台管理。然而，由于 AVIF 的资源占用显著高于 WebP，在灰度上量的过程中，图片服务占用的资源急剧增加，影响了整体资源池的水位安全。这对于即将到来的重要活动，如跨晚等，可靠性产生了一定的影响。
为解决这一问题，B 站将 WebP 和 AVIF 任务拆分到了两个不同的容器集群中。由于 AVIF 任务是离线任务且对可用性和延迟要求不高，因此每个 AVIF 容器都被配置了一个极低的 CPU request 和一个相对较高的 CPU limit。这样，在低峰期时，图片服务能够尽可能多地利用资源处理 AVIF，而在高峰期时，图片服务进程的优先级较低，从而减少对其他业务的影响。
通过这个策略，我们成功利用 “白嫖” 算力来满足其目前规模下的 AVIF 处理需求。
b. 负载不均导致利用率低
基于实例的任务分发策略导致容器负载不均，影响集群整体利用率的提升。AVIF 落地初期， B 站内部容器平台尚未普及 vCPU 和算力标准化，容器调度以核数为单位。由于不同物理机单核算力不同，同样是 8 核的容器，在新硬件上的处理能力显著强于旧硬件。受限于短板效应，集群整体利用率不高。
注：关于大规模 K8s 集群算力标准化，可以期待 B 站即将公布的分享
为缓解这个问题，我们在离线集群上实验性开启了基于 P2C 算法的分发策略，针对图片处理场景的特性，单机 QPS 较低、请求耗时天然不均，做了一些调优。效果如下图，有一定收益，仍有较大优化空间。
c. 研发资源不足问题
AVIF 图像格式的开发和推广需要大量的技术和人力资源，特别是在进行高级优化和性能调优时，需要具备深厚的图像处理和算法知识。此外，开发和维护 AVIF 格式的软件库和工具也需要大量的资源投入。
图像算法：AVIF 格式的设计和开发需要涉及图像算法和数据结构的知识，例如色彩空间转换、DCT 变换、预测编码等。由于 AVIF 是一种较新的图像格式，可能需要对这些算法进行改进和优化，以提高图像质量和压缩性能。
元数据处理：AVIF 格式包含了大量的元数据，例如色彩空间信息、色彩配置信息、ICC 配置文件等。处理这些元数据需要具备深入的图像处理和计算机视觉知识，并且需要使用一些专门的库和工具来处理和管理这些元数据。
内存分配：
在解码 AVIF 动图时，需要为每个帧分配足够的内存空间，以存储解码后的图像数据。这可能需要大量的内存，特别是在解码高分辨率或高帧率的动图时，需要处理更多的图像数据。为了避免内存占用过高的问题，需要进行适当的内存分配和释放，以确保内存的合理使用。AVIF 动态图（动图）在移动端的解码问题比在桌面端更为复杂和严重。这主要是因为移动设备通常具有较低的计算资源和内存限制，而解码器刚刚支持动图，动图解码对于内存管理很差，移动端上动图解码的内存占用是 webp 的 7-10 倍，完全无法接受的状态。
缓存管理：
在解码 AVIF 动图时，可以使用缓存技术来减少内存占用和提高解码性能。缓存可以在解码后的图像帧中存储一定的图像数据，并在下一帧解码时重用这些数据，从而减少对内存的需求。但是，缓存的大小和管理方式需要根据具体的场景和设备进行优化和调整，以确保缓存的效果和可靠性。
内存释放：
在解码 AVIF 动图后，需要及时释放内存，以避免内存泄漏和内存占用过高的问题。在释放内存时，需要注意内存释放的顺序和方式，以避免内存访问错误和数据损坏的问题。通常可以使用智能指针等技术来自动管理内存释放，以减少手动释放内存的错误。
内存复用：
在解码 AVIF 动图时，可以尝试重用一些已分配的内存，以减少内存分配和释放的次数，从而提高解码性能。例如，可以将多个帧的内存分配到同一块内存中，并在解码后的帧之间重用这些内存。这需要谨慎管理内存的生命周期和使用方式，以确保内存的正确性和可靠性。
并行计算：
AVIF 的编解码过程通常需要进行大量的计算和运算，这可能会导致性能瓶颈。为了提高编解码的速度和效率，需要使用并行计算技术，例如多线程编程和 SIMD（Single Instruction, Multiple Data）指令集等。
AVIF 在动图方面的问题比较多，在实际线上应用中，动图的占比相对较小，一般只有 0.1% 左右，因此暂时不支持动图也不会对整体的应用质量产生太大影响，现在动图会降级为 webp。在使用 AVIF 时，需要根据实际业务场景和用户设备情况进行调整和优化，从而达到更好的性能和用户体验。
六、展望
持续优化与升级
随着 AVIF 格式的普及，我们将持续关注相关技术进展，对解码器、编码器进行升级，以提高图片加载速度、减少解码成本。
跟进不同平台（如 Android、iOS、Web 等）的特性和限制，进一步优化图片加载策略，提升用户体验。
优化缓存管理和内存复用策略，提高系统资源利用率，降低内存占用。
拓展更多图片应用场景
除了当前已实现的图片加载场景，探索 AVIF 在更多业务场景（如广告、社交分享等）的应用，以实现更广泛的性能优化。
研究 AVIF 与其他图片格式（如 WebP、HEIC 等）的混合使用策略，以实现最佳的图片加载体验。
跨平台解决方案研发
针对不同平台，研发统一的图片加载策略，简化业务接入成本，提高开发效率。
深入研究移动端硬件加速特性，探索利用 GPU 等硬件资源优化图片加载性能的可能性。
社区贡献与标准制定
积极参与 AVIF 相关技术标准的讨论与制定，推动图片加载技术的发展。
将在项目中积累的经验和技术成果分享给开源社区，推动 AVIF 技术在业界的普及与应用。
硬件加速方案探索
在已有小流量验证基础上，继续尝试落地 FPGA/VPU 等硬件编码方案，加速服务端编码效率，简化整体架构。
通过以上展望，我们将持续优化 AVIF 图片格式的应用效果，拓展其在更多场景的应用，提升用户体验。同时，我们将积极参与社区贡献，推动 AVIF 技术的发展与普及。
Q&A
AVIF 加载时间没劣化，但解码成本更高应该更耗电？有这方面数据么？
在 WWDC 2018 中，苹果推出了一种新的耗电监控工具 Energy Log。Energy Log 通过定期获取当前应用的线程堆栈信息，并对 CPU 占用率进行监控来识别可能存在的耗电问题。当应用在前台平均三分钟或者后台平均一分钟内 CPU 占用超过 80% 时，系统会将收集到的线程堆栈信息组合成一颗函数调用树形成 Energy Log。
经 Energy Log 的启发，AVIF 耗电分析监控，在应用启动后开启一个检测子线程，检测线程会持续识别当前应用哪个线程的 CPU 占用过高，并将耗 CPU 多的线程的堆栈信息收集起来。当应用 CPU 占用达到阈值时，耗电监控将收集到的堆栈信息组合形成耗电堆栈。在 iPhone 7 Plus 下测试，使用 backtrace () 获得一个线程的堆栈平均耗时是 50 微秒，在实际应用场景中，应用 CPU 占用过高时，一般最多只有 5 个线程的 GPU 占用会超过 5%。在我们现有的 ImageLoad 结构下，引入 AVIF 解码几乎不会带来性能损耗。
针对 AVIF 格式进行了移动端双端的双盲测试，测试结果显示 AVIF 组对耗电量并没有明显增加。同时，也进行了专项自动化测试，包括内存使用、CPU 占用率和平均 FPS 等指标，结果也没有明显波动。在用户视觉体验方面，与其他格式的图片相比，没有明显的降低。
参考
What’s New in Energy Debugging - WWDC18 - Videos - Apple Developer（https://developer.apple.com/videos/play/wwdc2018/228/）
Pixelmator Pro 3.1 adds support for macOS 13, AVIF images, introduces smooth corner style, and more - Pixelmator Blog.（https://www.pixelmator.com/blog/2022/11/02/pixelmator-pro-3-1-adds-support-for-macos-13-avif-images-introduces-smooth-corner-styles-and-more/）
no display of .avif files with dav1d decoder (#21568) · Issues · VideoLAN / VLC · GitLab. （https://code.videolan.org/videolan/vlc/-/issues/21568）GitLab. Retrieved 2021-10-08.
Cimpanu, Catalin (2020-07-09). Chrome and Firefox are getting support for the new AVIF image format | ZDNET. （https://www.zdnet.com/article/chrome-and-firefox-are-getting-support-for-the-new-avif-image-format/）ZDNet. （https://en.wikipedia.org/wiki/ZDNet）Archived（https://web.archive.org/web/20200813185435/https://www.zdnet.com/article/chrome-and-firefox-are-getting-support-for-the-new-avif-image-format/） from the original on 13 August 2020.
BOSS 实现相关介绍 https://www.bilibili.com/read/cv16653640 丨 https://www.bilibili.com/read/cv16703900
Bilibili KV 系统实现 https://www.bilibili.com/read/cv15610515
关于本文
作者：@杨一沐、@李代琛、@甄玉美、@DCjanus
原文：https://mp.weixin.qq.com/s/4HaVDdSCPgsRpT8HhWRsZA
这期前端早读课
对你有帮助，帮” 赞 “一下，
期待下一期，帮” 在看” 一下 。