b站怎么离线缓存手机（bilibili-AVIF图片格式落地）

背景

图片库加载服务是为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 ) 的数值大小。

经过持续数天的流量回放实验，我们有以下定性结论：

1. speed 对编码耗时影响显著，对图像质量与图片体积影响不大。

2. 相同 speed/quality 的前提下，图片越大，AVIF 相对 WebP 的体积优势越明显。

3. 相同 speed/图片大小 的前提下，质量(quality)越高，AVIF 相对 WebP 的体积优势越明显。

对齐图像质量（PSNR 差值不超过 1）的前提下，我们有以下定量结论：

1. B 站主流缩略图场景下，AVIF 相比 WebP 平均体积优化在 35% 左右。

2. B 站主流缩略图场景下，AVIF 相比 WebP 耗时增长 4 ~ 5 倍，图片越大，耗时增长越明显，视频预览图等超大图场景，耗时增长 20 倍以上。

B 站主流缩略图场景下，AVIF 4 线程编码耗时约为单线程的 73%，CPU 开销是单线程的 115%，且进一步增大并发度的收益不高。

浏览器兼容性角度，caniuse.com（http://caniuse.com/）提供的数据表明，截止2023年已经有79.81%的浏览器版本支持WebP，具体支持情况如下图所示

实际根据对 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、移动端处理

1. 解码器选择

客户端本地处理 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 的其他关键改进：

1. dav1d 支持所有 spec 和功能以及 8bits 和 10bits 色深

2. 已经完成包括 Film Grain, Super-Res, Scaled References 等功能，并全部支持 8bits 和 10bits 色深，正在开发公有 API

3. 开发工作已经覆盖99%的功能，通常一个 issue 会被在几天内搞定。

4. 编译器方面已经支持大部分流行的桌面 CPU，已经开始开发移动端和古老的桌面 CPU 的编译器、

5. 减少了 C语言代码的体积。

6. 已经准备好了针对 SSE 和 ARM 指令优化，ARMv8 也准备好了。

2.请求策略

得益于统一的图片框架，我们能够以最小的代码改动覆盖几乎所有应用场景。业务指定图片资源与缩略指令时，统一图片框架会根据服务端动态下发的策略，分业务、分场景决定是否获取对应 AVIF 资源。

3.监控及降级策略

BiliImage 框架会对图片的解码流程进行详细的监控，包括但不限于内存、磁盘、网络的读取耗时以及解码耗时、图片解析异常等重要数据。

BiliImage 支持自定义解码器，对于一种新的格式的图片处理，我们只需定义好 decoder 并插入到 image pipline 中即可。解码器支持热插拔，我们通过一系列的校验措施来保证 AVIF 图片处理的稳定性。

a. 应用启动时，我们会对本地存储的一张 1x1 的 AVIF 图像进行预解码，若解码失败则禁止该设备在这次生命周期内进行 AVIF 图片请求

b. 配置设备维度的黑名单，由于 AVIF 图片解码对 CPU 性能要求较高，针对线上监控中性能表现不佳的老旧机型，会做特殊处理

4.踩过的坑及怎么爬出来的

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.移动端

移动端落地计划的前置：

1. 在引入 AVIF 之前，评估现有业务中所使用的图片格式，并确定哪些图片可以被 AVIF 替换。在评估中考虑的因素包括：图片类型、图片大小、使用场景、压缩质量和压缩率等。

2. AVIF 目前在移动端的支持程度够不够完善，确定需要支持的移动端版本型号，硬件等，以便在决定是否使用 AVIF 时考虑到兼容性的问题。

3. 引入 AVIF 后，需要进行性能和效果的评估，以确保引入 AVIF 后能够满足业务需求。这些评估可以包括：页面加载速度、图片渲染速度、内存占用率、CPU占用率、图像质量和文件大小等。

4. 在确定那些业务和格式使用 AVIF 的图片和支持的系统版本，品牌，可以逐步引入 AVIF。先在哔哩哔哩蓝板（概念版）或新功能中尝试使用 AVIF，以评估 AVIF 的效果和兼容性，然后再逐步应用到其他业务中。

5. 在引入 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时，需要根据实际业务场景和用户设备情况进行调整和优化，从而达到更好的性能和用户体验。

六、展望

持续优化与升级

1. 随着AVIF格式的普及，我们将持续关注相关技术进展，对解码器、编码器进行升级，以提高图片加载速度、减少解码成本。
2. 跟进不同平台（如Android、iOS、Web等）的特性和限制，进一步优化图片加载策略，提升用户体验。
3. 优化缓存管理和内存复用策略，提高系统资源利用率，降低内存占用。

拓展更多图片应用场景

1. 除了当前已实现的图片加载场景，探索AVIF在更多业务场景（如广告、社交分享等）的应用，以实现更广泛的性能优化。
2. 研究AVIF与其他图片格式（如WebP、HEIC等）的混合使用策略，以实现最佳的图片加载体验。

跨平台解决方案研发

1. 针对不同平台，研发统一的图片加载策略，简化业务接入成本，提高开发效率。
2. 深入研究移动端硬件加速特性，探索利用GPU等硬件资源优化图片加载性能的可能性。

社区贡献与标准制定

1. 积极参与AVIF相关技术标准的讨论与制定，推动图片加载技术的发展。
2. 将在项目中积累的经验和技术成果分享给开源社区，推动AVIF技术在业界的普及与应用。

硬件加速方案探索

1. 在已有小流量验证基础上，继续尝试落地 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 等指标，结果也没有明显波动。在用户视觉体验方面，与其他格式的图片相比，没有明显的降低。

参考

1. What’s New in Energy Debugging - WWDC18 - Videos - Apple Developer（https://developer.apple.com/videos/play/wwdc2018/228/）

2. 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/）

3. 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.

4. 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.

5. BOSS 实现相关介绍 https://www.bilibili.com/read/cv16653640丨https://www.bilibili.com/read/cv16703900

6. Bilibili KV 系统实现 https://www.bilibili.com/read/cv15610515

本期作者

杨一沐 - 哔哩哔哩资深开发工程师

李代琛 - 哔哩哔哩资深开发工程师

甄玉美 - 哔哩哔哩高级开发工程师

DCjanus - 哔哩哔哩高级开发工程师

来源:微信公众号:哔哩哔哩技术
出处:https://mp.weixin.qq.com/s/4HaVDdSCPgsRpT8HhWRsZA