ImageIO是Apple提供的上层框架，用于处理常见图像格式的编解码支持。这篇文章主要讲述了三个子话题：WebP/AVIF的支持进展，IOSurafce和硬件解码优化50%内存开销，以及CGImageSource机制变化导致的线程安全问题

ImageIO的定位是上层的支持框架，其封装了诸多的苹果的底层解码器，开源编解码器，硬件HEVC/ProRes加速器等等底层细节，致力于提供和上层UI框架（如UIKit/CoreGraphics）的可交互性。

在早些年的时候，我写过一系列文章，介绍了其API使用的基本流程（参考：《iOS平台图片编解码入门教程（Image/IO篇）》），以及有关其惰性解码的机制（参考：《主流图片加载库所使用的预解码究竟干了什么》）。

实话说，自从重心从iOS开发，转移到做LLVM工具链相关工作之后，我本以为不会再写这些上层iOS框架的文章了，但是SDWebImage这个开源库依旧没有合我预期的新Maintainer，来作为交接，因此现在还是忍不住先写这一篇吐槽和说明文章。

这篇文章会介绍，自iOS 13时代之后，苹果在ImageIO上做的一系列优化（“机制变化”），以及对开发者生态带来的影响。

WebP/AVIF新兴图像格式支持

自从HEVC/HEIF在苹果高调提供支持之后，由于硬件解码器的加持，本以为苹果会对其他竞争的媒体格式不再抱有兴趣，但实际上并非如此

WebP

WebP作为Google主导的无专利费的图像格式，其诞生后就一直跟随Chrome推广到各大Web站点，如今已经占据了互联网的一大部分（虽然其兄弟的WebM视频编码并没有这么热门）。

早在iOS 11时代，我就呼吁并提Radar希望Apple的ImageIO能够支持原生的WebP，而最终，时隔3年，在iOS 14上，ImageIO终于迎来了其内置的WebP支持，并且能够在Mac，iPhone上的各种原生系统应用中，预览WebP图像了。

那么，ImageIO对WebP的支持到底如何呢？答案其实很简单，ImageIO直接内置了开源的libwebp的一份源码和VP8的支持，并且去掉了编码的能力支持，所以能够以软件解码的形式支持WebP，不支持硬件解码。

换言之，使用这个ImageIO的系统解码器解码WebP，和使用我写的SDWebImageWebPCoder没有本质上的巨大差异（最多是一些编译器优化导致的差异），而后者还支持WebP编码（虽然耗时很慢）

AVIF

AVIF是基于AV1视频编码的新兴图像格式，作为HEVC的无专利费的竞争对手。AVIF与AV1，HEIF和HEVC，这两大阵营的关系一直是在相互竞争中不断发展的。而各大视频站如YouTube，Netflix，以及国内的Bilibli都在积极的推广这一视频格式，减少CDN带宽和专利费的成本。

而随着Apple在2018年加入AOM-Alliance for Open Media之后，我就预测有朝一日能够看到苹果拥抱这一开源标准。在2021年WebKit的开源部分曾经接受了PR并支持AVIF软件解码。而在2022的今年，iOS 16/macOS 13搭载的Safari 16，已经正式宣布支持了AVIF

虽然目前没有在其他系统应用中可以直接预览AVIF，但是我们已经看到这一趋势。在ImageIO的反编译结果中也看到了对.avif的处理和UTI的识别，虽然目前其本身只是会fallback到AVCI（AVC编码的HEIF，并不是AV1），但是我相信，后续OS版本一定会带来其对应的原生SDK和应用层的整体支持，甚至未来可以看到新iPhone搭载AV1的硬件解码器。

PS：广告时间，我之前也尝试过一些利用开源AV1解码器实现的AVIF解码库，以及macOS专用的Finder QuickLook插件，在未来到来之前，依旧可以发挥其最后的功用：）

1

brew install avifquicklook

IOSurface和硬件解码优化

IOSurface，作为iOS平台上古老的一套在多进程，CPU与GPU之间共享内存的方案，在早期iOS 4时代就已经诞生，但是一直仅仅作为系统私有的底层XPC通信用的数据格式

而从iOS 13之后，苹果对硬件解码的支持的图像格式的上屏渲染，大量使用了IOSurface，抛弃了原有的“主线程触发CGImage的惰性解码”的模式。

也就是说，《主流图片加载库所使用的预解码究竟干了什么》这篇文章关于ImageIO的部分已经彻底过时了，至少对于JPEG/HEIF而言是这样。

如何验证这一点呢？可以从一个简单的Demo，我们这里有一个4912*7360分辨率的JPEG和HEIC图（链接），使用UIImageView渲染上屏，开启Instruments，对比内存占用

IOSurface：

1
2
3

// JPEG/HEIF格式限定，iOS 13，arm64真机限定
let image = UIImage(contentsOfFile: largeJpegUrl.path)
self.imageView.image = image

CGImage：

1
2
3
4
5

// JPEG/HEIF格式限定，iOS 13，arm64真机限定
let source = CGImageSourceCreateWithURL(data as CFURL, nil)!
let cgImage = CGImageSourceCreateImageAtIndex(source, 0, nil)!
let image = UIImage(cgImage: cgImage)
self.imageView.image = image

数据较多，直接看IOSurface的结果，可以发现，除了峰值上HEIC出现了翻倍，最终稳定占用都为51.72MB

而直接用CGImage（或者你换用模拟器而不是真机），则结果为137.9MB（RGBA8888）

• JPEG（IOSurface）

• HEIC（IOSurface）

备注：

1. 在iOS 15+之后，这部分的Responsible Library会变成CMPhoto，iOS 15+新增的UIImage.preparingForDisplay()也利用了它的能力
2. 使用UIImage(contentsOfFile:)和这里的UIImage(data:)，在iOS 15上并无明显差异，但是在低版本如iOS 13/14上，可能出现UIImage(data:)对于HEIC格式，无法利用IOSurface的Bug，因此更推荐使用文件路径的接口

50%内存开销的奥秘

反编译可以发现，苹果系统库的内部流程，已经废弃了CGImage来传递这种硬件解码器的数据Buffer，而直接使用IOSurface，以换取更小的内存开销，达到同分辨率下RGBA8888的内存占用的37.5%（即3/8），同分辨率下RGB888的内存占用的50%（即1/2）

你可能会表示很震惊，因为数学公式告诉我们，一个Bitmap Buffer的内存占用为：

1

Bytes = BytesPerPixel * Width * Height

而要实现这个无Alpha通道的50%内存占用，简单计算就知道，意味着BytesPerPixel只有1.5，也就是说12个Bit，存储了3个256（2^8）色彩信息，换句话说0-255的数字用4个Bit表示！

你觉得数学上可能吗？答案是否定的，因为实际上是用了色度采样，并不是完整的0-255的数字，学过数字图像处理的同学都应该有所了解。

打开调试器，给IOSurface的initWithProperties:下断点，发现这个创建的IOSurface很有意思，PixelFormat = 875704438('420v')，即kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange，看来使用了YUV 4:2:0的采样方式

因此，这里应该对应有两个Plane，分别对应了Y和U两个采样的平面，最终由GPU渲染时进行处理。这里不采取YUV 4:4:4的原因是，大多数JPEG/HEIF的无透明度的图像，在肉眼来看，采样损失的色度人眼差异不大，这一优化能节省50%内存占用，无疑是值得的。

值得注意的是，这里苹果处理具体采样的逻辑也是和原图像编码有关的，如果YUV 4:4:4编码的，则最终CMPhoto可能依旧会采取YUV 4:4:4进行解码并直接上屏，苹果专门的策略类来进行处理。

IOSurface和跨进程Buffer

不过，除了这一点，为什么只有真机能支持色度采样呢？答案和Core Animation的跨进程上屏有关。

之前有文章分享过之前，iOS的UI渲染是依赖于SpringBoard进程的中的CARenderServer子线程来处理的，因此这就有一个问题，我们如何才能将在App进程的Bitmap Buffer传给另一个进程的CARenderServer呢？

在iOS 13之前我们的方案，就是利用mmap，直接分配内存。但是mmap的问题在于，在最终Metal渲染管线传输时，我们依旧要经过一次额外的把Bitmap Buffer转为Texture并拷贝到显存的流程，因此这一套历史工作的横竖还有一些局限性。

在A12+真机的设备上，这一步借助IOSurface来实现跨CPU内存和GPU显存的高效沟通。

参考苹果的文档以及一些相关资料

• Transferring Data Between Connected GPUs
• Cross-process Rendering

IOSurface的资源管理本质上是Kernel-level而不是User-level的mmap的buffer，Kernel已经实现了一套高效的传输模型，借助Lock/Unlock来避免多个进程或者CPU/GPU之间发生资源冲突，因此这是上述优化的一个必要条件。

1
2
3
4
5
6

let surface: IOSurface
surface.lock(options: .readOnly, seed: nil)
defer { surface.unlock(options: .readOnly, seed: nil) }

// Use surface.baseAddress to read the pixel data
// Make sure to step by bytesPerRow for each row

开发者的痛，我的Public API呢？

现在揭秘了苹果优化JPEG和HEIF硬件解码内存开销之后，下一个问题是：

作为开发者，我如果加载一个JPEG/HEIF网络图，有办法也利用这个优化吗？

答：可以，但是使用时需要遵守以下几个原则：

1. 对JPEG/HEIF网络图，如果仅有内存中的数据，则优先考虑使用UIImage(data:)
2. 如果能够将数据下载到本地存储产生文件路径，则优先考虑使用UIImage(contentsOfFile:)加载
3. 如果直接使用ImageIO接口，需要注意，调用CGImageSourceCreateImageAtIndex返回的是惰性解码的占位CGImage，而CGImageSourceCreateThumbnailAtIndex返回的是解码后的CGImage（也就根源上无法利用IOSurface优化）
4. 如果要进行预解码，在iOS 15之后，请不要使用老文章写的，使用CGContext提取Bitmap Buffer的方案，优先调用UIImage.preparingForDisplay()，甚至是如果仅有CGImage的情况下，也推荐创建一个临时UIImage再来调用。其原理是，对于上文提到的，惰性解码的占位CGImage，CMPhoto能间接进行IOSurface的创建（利用后文讲到的CGImageGetImageSourcce)，达到偷梁换柱的作用，而手动创建CGContext并没有这样的能力（可以参考#3368）

如果遵守以上几点，那么我们依旧可以利用到这个优化，节省内存占用。否则会退化到传统的RGBA8888的内存开销上。尤其是关于第4点，苹果这个设计本想让开发者淡化IOSurface和CGImage的差异，但是我感觉反而增加了理解成本和性能优化成本。

另外，ImageIO和UIKit并没有提供更详细的IOSurface的公开API，只有其内部流程，本质间接使用了以下私有接口：

• -[UIImage initWithIOSurface:]
• CGImageSourceCreateIOSurfaceAtIndex

诚然，我们都知道能够直接调用任意的Objective-C/C API的姿势，这里也不再展开，只是需要注意，上文提到的这些优化，都存在特定iPhone硬件（A12+）和格式（JPEG/HEIF）的限定，需要注意检查可用性。

此外，从实践来看，苹果UIKit和ImageIO的上层接口，都更推荐文件路径的形式（因为可以优化为mmap读取，文件扩展名的Hint等逻辑），如果我还继续维护SDWebImage下去的话，未来也许会提供基于URLSessionDownloadTask以及文件路径模式的解码方案，或许就能更好地支持这一点。

不再安全的ImageIO

曾经，在我的最佳设计模式观念里，一个Producer，产出的Product，永远不应该反向持有Producer本身。但是这个想法被ImageIO团队打破了

从一个崩溃说起

在iOS 15放出后的很长一段时间里，SDWebImage遇到一个奇怪的崩溃问题#3273，从堆栈来看是典型的多线程同时访问了CFData（CFDataGetBytes）导致的野指针。起初我对此并没有在意，以为又是小概率问题，并且@kinarobin提了一个可能的CGImageSource过度释放的修复后，我就关闭了这个问题。但是随后越来越多用户依旧反馈这个崩溃，因此重新打开仔细看了一下，发现了其背后的玄机。

玄机在于，iOS 15之后，Core Animation在主线程渲染CGImage时，会调用一个新增的奇怪的接口CGImageGetImageSource。如果带着疑问进一步追踪调用堆栈，发现在调用CGImageSourceCreateImageAtIndex时，ImageIO会通过CGImageSetImageSource绑定一个CGImageSource实例，到CGImage本身的成员变量（实际来说，是绑定到了其结构体指针存储的CGImageProperty字典）。随后，Core Animation会通过获取到这个CGImageSource，后续在渲染时间接调用CGImageSource的相关接口。持有链条为 UIImage -> UIImageCGContent -> CGImageSource

崩溃的背后

这一机制改变，同时带来了一个隐患是：ImageIO它不再线程安全了。而且开发者不能修改Core Animation代码来强制加锁。

主要原因是，CGImageSource支持渐进式解码，而第三方自定义UIImage的子类时，有可能自己创建并持有这个渐进式解码的CGImageSource，并不断更新数据。在SDWebImage本身的设计中，我们通过加锁来保证，所有的对渐进式解码的调用，以及更新数据的方法，均能被同一把锁保护。

而当我们产出的CGImage，传递给了Core Animation，它无法访问这一把锁，而直接获取CGImageSource，并调用其相关的解码调用，就会出现多线程不安全的崩溃问题。

总而言之，这一设计模式的打破，即把Product和本不应该关心的Producer一起交给了外部用户，但是外部用户无法保障Producer的生命周期和调用，最终导致了这样的问题。

Workaround方案

最终，针对这个问题，SDWebImage提供了两套解决思路，第一个思路是直接通过CGContext提取得到自己的Bitmap Buffer，得到一个新的CGImage，切断整个持有链，最简单粗暴的修复，代价是全量关闭惰性解码无法用户控制，可能带来更高的内存占用（#3387，修复在5.13.4版本上）

第二个思路是，通过抹除掉CGImage持有的这些额外信息，采取通过CGImageCreate重新创建一个复制的CGImage，但是依旧保留了惰性解码的可选能力（#3425，方案在5.14.0版本上）。顺便提一句，通常动图（GIF/AWebP）都不支持硬件解码且切换帧频率较高，关闭惰性解码依旧是小动图的最佳实践。

PS：对感兴趣的小伙伴详细解释一下，第二个解决思路利用了CGImageProperty（类似于CGImage上存储的一个字典，按Key-Value形式存取）的时机特性，使用CGImageCreate重建CGImage时会完全丢失所有CGImageProperty（只有CGImageCreateCopy能够保留）。

而上文提到的CGImageGetImageSource/CGImageSetImageSource这些私有接口，本质上是操作这个com.apple.ImageIO.imageSourceReadRef的Key（全局变量kImageIO_imageSourceReadRef），Value存储了ImageIO的C++对象，并可以还原回一个CGImageSourceRef指针。一旦我们把CGImageProperty丢失掉，那么就能打断这个持有链条。

总结起来，ImageIO Team做出如此重大的设计模式改变，并没有在任何公开渠道同步过开发者，也没有提供公开接口能够控制这个行为，或者至少，没有暴露对应的CGImageSetImageSource接口，导致第三方开发者不得不采取曲线救国的解决方案去Workaround，这一点很值得让人吐槽。

总结

这篇文章看似讲了三个话题，其实背后有着一贯的缘由背景：

早期的ImageIO和各种上层框架的设计，是针对iPhone的低内存的机型做了深入优化，希望能尽量利用惰性解码，mmap缓存，换取较低内存开消，并且对各种无硬件解码的开源格式完全不感兴趣。

而最近几年，随着苹果芯片团队的努力，高内存，M1的统一内存，以及高性能芯片的诞生，苹果已经有充足的能力能够通过软件解码，共享内存，越来越多硬件解码器技术来满足主流的多媒体图像支持，本身这是一件好事。

不过问题在于历史遗下来的API，依旧保持了之前的设计缺陷，Apple团队却一直在，通过越来越Trick和Hack的方式解决问题，并没有给开发者可感知的新机制和手段来跟进优化（除开这一点吐槽，AppKit上的NSImage的NSImageRep这种代理对象设计，比UIImage的私有类UIImageContent设计要适宜的多，也灵活的多）

个人看法：软硬件一体加之闭源，会导致开源社区的实现，永远无法及时跟上其一体的私有集成，最终会捆绑到开发者和用户（开发者越强依赖苹果API和SDK，就会越强迫用户更新OS版本，进而捆绑硬件换代销售），这并不是一个好的现象🙃

招募

SDWebImage开源项目如今缺少长久维护的Maintainer，如果你对iOS/macOS框架开发感兴趣，对图像渲染和Apple平台有所涉猎，对Swift/Objective-C大型开源项目贡献有所期待，可以在我的GitHub上，以Email，Twitter私信等方式联系我。

这篇文章讲的是有关近期自己参与的几个开源项目的经历以及感受，不过巧合的是内容都和APNG和WebP这两种图像格式相关，阅读前建议先简单略读一下之前写的一篇文章：客户端上动态图格式对比和解决方案

SDWebImage

SDWebImage是iOS平台上非常著名的图片下载、缓存库，而今年发布的SDWebImage 4.0在架构、接口变动并带来性能优化的同时，还支持了Animated WebP，因此我就高兴地去实验了一下，本想着可以替代之前使用的YYImage。但是一测试就发现渲染不正常，追回去看源码，发现SDWebImage的实现可以说是Too naive，压根没有按照WebP规范实现，大部分Animated WebP动图渲染都挂了，完全不可用（连测试都过不了，更别说生产环境了）。演示Demo在此：AnimatedWebPDemo

总结出来的具体问题有以下几个：

1. SD绘制每帧的canvas大小不正确，在代码中，直接取得当前帧frame的大小，而非整个canvas的大小。这就导致最后生成的所有帧图片的数组中，每帧的图像大小不一致。这样渲染就会出现Bug（把所有帧拉伸到最大的那个图像大小上）。
2. SD的实现没有考虑过WebP Disposal Method，这个在很多动图中都会用到，因为能够重复利用前一帧的画布，来大幅减少最后生成动图的体积。常见的动图格式如GIF、APNG生成工具一般都采用这种Disposal，不然最终文件体积较大（但Google提供的WebP工具暂时没有自带这种优化的方式，一般使用第三方工具处理）。
3. UIKit自带的UIImage.animatedImages是非常弱的，SD并没有提供额外的抽象，而是直接用的这个接口。这带来的最大的问题，是UIImage需要提供一个图片数组和总时长，但是会对数组中每个图片平均分配时长。这与Animated WebP的规范就是不同的，后者允许对每帧设置一个不同的持续时长。
4. UIImageView直接设置image属性，是不支持设置循环次数的，会默认无限循环播放。而有些Animated WebP图片需要有循环次数。

既然知道这么多坑，想着SD毕竟是主流框架，就赶紧提了Issue，但是过了一周多，SD社区依然没有任何回应。于是尝试自己一个个解决。最后的成果也比较好，上述4个问题都得到了解决。

Canvas大小问题

这个问题，可以直接通过libwebp的API，修改来使用canvas大小而不是frame大小，确保每帧最后的图像大小相同。其中，为了优化性能，对于透明的且frame比canvas要小的帧，绘制出来等价于将frame平移，然后所有剩余部分填充透明值。在使用CGBitmapContext的时候，可以直接在要传入的Bitmap矢量数据上做变换，减少绘制带来的开销（不过CGBitmapContext本身应该有优化，对于这个开销影响不大，但参考YYImage里面有这一步处理）

Disposal Method支持

在绘制每帧时，按照Animated WebP规范，共享一个全局的CGContext当作canvas，根据每帧不同的Disposal Method，如果为Disposal Background，则在绘制完当前帧后清空CGContext，否则的话不处理，保留到下一帧继续绘制，最终测试和YYImage行为一致。

每帧持续时长相等问题

这个问题相对比较麻烦，因为你无法改动UIKit实现方式。最后想了一个比较Trick的方式。思路也简单，考虑这样的情况：第1帧持续时间：50ms，第2帧持续时间：100ms，第3帧持续时间：150ms，总共时长300ms。在依然使用UIImage的接口情况下（即数组每帧时长平均分配），那就可以提供一个[1, 2, 2, 3, 3, 3]（元素表示帧的编号）的图像数组，总时长300ms。这样的话平均分到每个元素是50ms，表面上看是6帧但实际渲染是3帧，也能达到最后的显示效果。这样实现的话，只要求一个所有帧持续时间的gcd，然后对每帧图像，按该帧所占的比例重复添加多次就可以了。

循环次数问题

由于SD的接口问题（用到了UIImageView的sd_setImageWithURL），是直接设置到UIImageView.image上的，而不是animationImages。而直接设置image会无视掉animationRepeatCount这个本来用于设置循环次数的属性。但如果SD框架自动设置animationImages 属性的话，可能对使用者现有代码有影响（因为使用者还是用的image属性而不是animationImages属性），因此最后的解决方案，是在UIImage的扩展中，单独提供了一个sd_webpLoopCount的属性来获取循环次数，使用者可以自行设置UIImageView的属性，来实现指定循环次数。

举个例子，一般情形下（显示的动图超过循环次数后停到最后一帧上）就可以这样子用。

1
2
3
4
5
6
7

[imageView sd_setImageWithURL:webpURL completed:^(UIImage * _Nullable image, NSError * _Nullable error, SDImageCacheType cacheType, NSURL * _Nullable imageURL) {
    imageView.image = image.images.lastObject;
    imageView.animationDuration = image.duration;
    imageView.animationRepeatCount = image.sd_webpLoopCount;
    imageView.animationImages = image.images;
    [imageView startAnimating];
}];

这也算是一个解决方式吧。

感受

在写完这些，跑过单元测试，提交了Pull request之后，回头来看，才能真正感到YYImage的实力。

YYImage通过一个抽象层YYImageFrame，来把GIF、APNG和Animated WebP三种格式统一到一起，并且提供了Encoder和Decoder可以在三种格式来互相转换（这是重点）。关于绘制部分，还使用到了Accelerate Framework，通过vImage的GPU加速的Bitmap变换来替代部分CGBitmapContext绘制。在缓存上，由于SD的抽象层存在，他使用了ImageIO来直接缓存CGImageSource（SD采用的是缓存了WebP的rawData），效率提升了很高也减少缓存大小（速度对比的话，可以从那个Demo工程看到，checkout到fix_sd_animated_webp_canvas_size分支上运行）。想想还是挺佩服ibireme这个人的，看来以后还要多使用YYKit并多学习。

apng2webp

apng2webp是一个转换APNG到Animated WebP图片的命令行工具，使用Python脚本 + 外部命令行工具来实现。在之前的工作需求中，使用到来优化APNG的大小，并且产出Animated WebP来让客户端使用。

为什么要转换APNG到Animated WebP呢，其实是因为APNG这个规范由于没有进入到PNG标准规范中，一直处于一个不温不火的地步，网上的APNG动图数量也不多，很多网页的PNG图片上传也不支持。虽然如今各大浏览器都对APNG提供了支持（Chrome 59正式支持了APNG，iOS很早从8.0支持，FireFox就是亲爹一直推动），但是客户端上，Android端没有相对靠谱的解码和渲染组件能够使用。反倒是Animated WebP借助Google亲爹推动，成为Android天生支持的图像格式，并且iOS上也有YYImage来提供支持。随着WebP的流行，越来越多设备估计都会支持WebP和Animated WebP，甚至最终超越GIF这个广为流行，但是已有30年历史，只支持256色和1位alpha通道的古老动图格式。

这次对apng2webp项目，主要是贡献了两个功能。

1. Windows的支持，即现在三大桌面端命令行均可使用
2. CI自动Build和Test

Windows的支持

由于整个外部命令行工具(有四个工具，其中cwebp和webpmux是Google官方提供的，有Windows Build，另两个是源码编译）都是UNIX工具链下的，依赖几个C++库也挺常见，但是尝试过使用VS 2015源码编译跪了，使用vcpkg这个非常新的Windows上的C++包管理工具，又爆了一堆link error。对于我这种C++菜鸟来说，最后只好选择了直接上Mysys2和MinGW-w64，一键pacman -S安装依赖，cmake makefile可用，跑了一遍测试也没问题，确实非常方便。由于MinGW-w64的编译产物，会依赖于libgcc，winpthreads，为了使最后的分发方便，于是在Windows上改用静态链接。

CI和单元测试

关于Python的单元测试，由于这是一个简单的命令行工具，最后就通过引入pytest，直接对main函数和外部工具进行了测试，写起来也特别简单（自动匹配文件名和类名这点挺好）。用起来感觉比起Objective-C和Java的工具要好用多了。

在CI Build上，对于Linux和macOS的话，一般都会使用GitHub官方合作的Travis CI，配置使用yml语法，再加上一系列的Bash命令。而Windows上使用的Appveyor也非常好用，自带了VS 2012,2015,2017，Msys2，MinGW-w64，cmake等一系列工具，上手开箱即用。配置的话注意要使用CMD或者PowerShell，如果不熟悉，甚至可以用Msys2装一些UNIX工具来搞定（好处之一）。

感受

总体来说，这个项目主要是苦力活，不过也算熟悉了一下UNIX工具在Windows上移植的一种手段，而且还学习到了pytest和开源项目的CI Build方式，也算有点意思吧。

iSparta

iSparta是一个图形化的APNG和WebP转换工具，包含了很多功能（APNG合成，WebP转换，图片压缩等），虽说是开源项目，但是上一次提交已经是三年前了。而我最希望的APNG转换Animated WebP功能却没有实现（这也难怪，三年前Animated WebP规范还没出来）。大概看了一眼，使用的是NW.js（其实用的是改名前叫做node-webkit的东西），是一个和Electron类似的，使用前端技术栈来构建跨平台应用的框架，本质上都是一个Chromium的运行环境来提供渲染，再加上node.js来提供JS Runtime。上手相对容易。

基本上的目标，是为了提供更好的GUI工具，因此主要就参考了一下iSparta的Issue，解决这几个问题：

1. 支持APNG转换Animated WebP
2. 支持i18n国际化

由于我并不是专业前端出身（大二学过一段时间前端基本知识和Node.js简单应用，也接触过React Native），经过近两天的奋斗，才终于磕磕碰碰完成。期间遇到过各种问题（NW.js的问题，node第三方库的问题，跨平台行为不一致的问题等等），不过在这里略过说一下重点吧。

APNG支持Animated WebP

关于这个功能，自然可以想到上面的apng2webp命令行工具，不过由于apng2webp本身是Python写的脚本来调用外部工具，没必要在NW.js里打包一个Python环境。因此最后就决定直接在JS里，实现了相同逻辑的脚本来完成。不过实话说这部分花费的时间不长，在GUI布局上才是重头。大体框架参考了项目中的已有写法，但CSS的部分由于实在生疏（原项目有一些布局Hack），最后使用了flexbox布局来搞定的。

i18n国际化

在网页端支持i18n国际化，这是确实是以前未接触过的地方。考虑到这个项目有大量散落的HTML文本中硬编码了中文文字，而又没有使用类似于Angular、React这种先进的技术来支持模板，因此就需要自行解决。最开始思考了使用服务端渲染的解决方案（即NW.js当作浏览器，本地起node使用express当作服务端，来返回渲染好对应国际化后的HTML），但是遇到了问题，当作纯浏览器后，NW.js无法再使用node端的本地包，这也就意味着无法调用外部的命令行工具（相当于RPC了）。因此这种方案不可行。

再经过尝试后，最后使用的解决方案，是引入了node-i18n和模板引擎（这里用的是doT）。在项目目录下准备好i18n的文本资源（框架支持的是JSON格式）。然后在NW.js应用启动时加载一个空body的页面，执行JS来获取i18n后的字符串，再将这些字符串渲染到只有body的模板中，最后把国际化完成后的HTML body插入到原始的页面的body中。整个过程没有多余的开销（避免了模板未渲染前被显示出来，而且可以缓存模板结果，因为实际上给定一种locale，模板生成的HTML是固定的）。

感受

其实现在看看自己平时用到的应用，Atom、VS Code、GitKraken、钉钉，这些看起来已经足够复杂，也都能够用这种前端技术栈构建起来了。以前自己如果提到跨平台桌面客户端应用，第一反应就是Qt，不过现在看来，如果对前端技术栈有所了解，对性能和实时性要求不高，是可以使用Electron或者NW.js这种框架来构建。虽然曾经见过有人批判这些框架（体积庞大-打包了Chromium和Node；内存占用高，效率低下-WebKit渲染而不是原生UI组件），reddit上甚至有讨论说这是新一代的Adobe Flash。

但我个人看来，不排斥这样的框架，只是感觉如今的解决方案并不是十分完美，这些前端栈技术写的客户端最大的问题其实是代码复用问题，基本上是各家有自己的一套组件，而且很多解决方案很Trick。我觉得更为理想的情况，是能够提供一套完整的解决方案，包含了开箱即用的UI组件（并非指Bootstrap这种通用Web UI组件，而是专门针对桌面客户端优化的，符合客户端的交互方式），能够开发，构建，测试，打包一站式自动处理，足够多的Native桥接（这也是一大痛点，见过一些应用又回过头在Electron里面使用Flash），更多的优化，比如共享Chromium容器-不必每个应用的带上200MB的运行环境。

总体来说，Electron或者NW.js这些框架的前途还是比较光明的，毕竟传统意义上的桌面应用开发成本还是太高，尤其是互联网公司的产品，追求跨平台的情况下，在成本，人力还有技术难点考虑来看，也是一个不错的选择。

总结

其实，这三个开源项目都是属于一时兴起才去贡献的，并不是为了而去专门寻找的，至于为什么都是WebP相关，或许真的是巧合吧。参与这些开源项目，虽然花费了一定的时间精力，但是获得的知识面上的提升确实非常大，包括但不限于：WebP规范、Accelerate Framework、跨平台C++移植、Python单元测试、CI配置、NW.js和前端i18n。

说实话，参与开源项目的时候，你会发现一些社区是很有意思的，你能够和不认识的人去合作，还能够直观感受到其他人对项目的关注，更能够接触很多你之前从没有接触过的技术栈。我不能说自己是一个愿意花费大量个人时间去贡献开源事业的人，但是其实很多项目参与门槛不是那么高，无论是你自己平时用到的软件、类库，甚至是一个小工具、脚本、翻译、教程，都可以试着参与一下。我觉得程序员的知识，并不是为了单纯为了打工搬砖，能够把自己的想法与他人分享也是一个相当大的乐趣，不是吗？

对各种客户端来说，无论是Web还是移动端，图片占据的容量和传输资源一定是非常大的。对于静态图，我们常见的PNG和JPEG格式在压缩率和画质无损上都存在着不尽如人意的地方，而动图格式的GIF更是存在着很多问题，比如因此，在很多情况下，我们需要迁移到新的图片格式。

GIF

为什么我们不用GIF呢，GIF由于时代限制，存在的天生的问题。GIF的规范最新版本是在1989年制定的，一个24位色都没有普及的时代，因此，GIF规范只支持256色索引颜色，并且只能通过抖动、差值等方式模拟较多丰富的颜色。更为悲剧的是，它的alpha通道只有1bit，换言之，一个像素要么完全透明，要么完全不透明，而不像现在PNG的RGBA的8bit alpha通道，alpha值也可以和RGB一样都有255个透明值。这导致了所有GIF的图片带上透明度以后，边缘会出现明显的锯齿。所以如果你的客户端需要展示带透明度的动图，GIF基本上可以不考虑

实际的在线Demo，建议用Safari或者Chrome+插打开：http://apng.onevcat.com/demo

APNG

APNG是Mozilla在2008年发布的图片格式，本质上是在PNG的基础上加上一个扩展，而且非常简单即可实现。因此能够完全支持RGBA。规范可以参见APNG Specification。

虽然这个规范没有加入PNG开发组，但是很多浏览器已经支持了APNG。
最主推的是Apple的Safari（OS X 10.10以后的Safari，以及iOS 8以后的Safari和内置WebView），已经完全支持。Firefox亲儿子当然一直是支持的。Chrome桌面端已经从Chrome 59开始支持，现在就差Edge了。具体支持程度参见浏览器兼容性。

APNG的优势，在于时间比较长，各种动图制作工具，优化工具都有相应的项目来支持。而且在iOS上的WebView里面是除GIF外，唯一官方支持的动图格式，因此如果做移动端开发需要WebView页引入动图，APNG还是必不可少的。

当然，APNG终究是在PNG的基础上扩展，并没有引入特别出色的压缩算法，而且遗憾的是，短期内APNG还没有引入到Chrome，也就意味着Android平台的WebView也没有原生支持，因此，移动开发又会面临两端兼容性问题，这个后话再说。

相关APNG工具

APNG图形化制作工具和在线预览:iSparta
APNG大小优化:APNG Optimizer
APNG Chrome插件:APNG for Chrome

WebP

WebP是Google在2010年发布的图片格式，完全开源，使用了VP8（就是WebM视频所用到的解码器）作为帧压缩编码器，而且在Chrome，Android上得到了原生的支持，具体规范参见:WebP

同样的支持RGBA，而且静态WebP的压缩率比起同质量PNG平均要高上20%左右。现在各大App厂商已经有开始迁移WebP。除了静态的WebP，还有动态WebP格式(Animated WebP)支持，不过动态WebP需要libwebp 0.4以后才正式支持，并需要mux和demux模块，如果自行编译需要注意。

Google官方提供了libwebp这个解码库在各个平台的二进制版本和Makefile，并且可以定制开启的功能。不过由于不像APNG那样基于PNG扩展，相关的工具很欠缺，基本全靠WebP Project提供的工具。

cwebp:PNG/JPEG -> WebP
dwebp:WebP -> PNG/JPEG
vwebp:WebP命令行预览工具
webpmux:多张WebP制作动态WebP
gif2webp:GIF -> 动态WebP

WebP工具

基本上来说，手动制作WebP会比较麻烦，因为Google没有提供WebP Optimizer之类的东西，如果我有100帧基本无差别的图使用webpmux合成动图，最终输出的文件大小会比较大。因此，一般推荐的做法，是先通过PNG制作APNG（比如iSparata），经过APNG Optimizer之后，再从APNG转换到动态WebP，这个流程可以用这个项目来一键搞定。
同时，也可以使用ffmpeg来转换视频到Animated WebP，一般使用MOV封装格式（UE常用的Pr导出的MOV可以支持alpha通道）。不过经过测试转换出来的Anmimated WebP大小相对比较大的（尤其同样的lossless下），不如PNG->APNG->Animtated Webp这个流程效果好。

apng2webp:APNG -> Animated WebP
ffmpeg:MOV -> Animated WebP

其他粗暴的解决方案

像国内的微博桌面版，提供的动图是通过PNG配合CSS Spirit，靠着不断JS轮播切换PNG子图所拼出来的，这个带来的带宽消耗会是非常高的，因为完全是多张图片混合，除非有着兼容性包袱（IE之类），一般不推荐使用。

APNG和WebP各平台实现

Web

APNG 浏览器支持
WebP 浏览器支持，注意Animated WebP支持

iOS

APNG:

• YYImage
• APNGKit

Animated WebP:

• YYImage

WebP:

• SDWebImage，注意SD使用的libwebp并没有加入mux和demux，故无法支持Animated WebP

WebView:

• UIWebView，WKWebView和SafariViewController均只支持APNG（iOS 8以后），不支持Webp和Animated WebP

YYImage，对显示动态图，使用了一个UIImageView的子类YYAnimatedImageView，通过直接插入了一个CALayer来作为图片的渲染layer，并用CADisplayLink这个帧定时器来刷新动图帧，通过异步线程处理解码，还有一些C的动态分配和回收内存来避免非常高的内存占用，保证了性能。并且自动处理了从视图消失以及滚动（可以切换到RunLoopCommonMode来滚动时候依然显示动图而不暂停）情况的问题，实现也非常有意思，有兴趣的人可以看一看。

Android

APNG:

• APNG View

Animated WebP:

• Fresco

WebView:

• Android 4.3以后才支持带lossless和alpha的WebP

Android基本上对APNG可以说是没有什么支持的，所以如果是移动开发两个平台兼顾，建议同时准备APNG（for iOS WebView）和Animated WebP，客户端上建议都是用Animated WebP，因为VP8的解码速度相对于APNG有一些优势。

存在的坑

Web和移动端对于APNG和Animated WebP循环次数不同

这个是一个非常大的坑，在Safari for iOS（Safari for macOS正常）和Chrome预览APNG和Animated WebP的时候，动图的循环次数为对应原图的loop+1。比如Animated WebP有100帧，loop为2，那么Chrome会循环总计展示300帧

刚开始我以为是移动端实现库的问题，毕竟Google和Apple这种大厂一般不会出现问题。但是再参阅了APNG和Animated WebP的规范，发现确实是Safari和Chrome本身的问题，可以参考APNG规范中的num_plyas字段，和WebP规范的loop_count字段

1
2
3

Loop Count: 16 bits (uint16)
The number of times to loop the animation. 0 means infinitely.
This chunk MUST appear if the Animation flag in the VP8X chunk is set. If the Animation flag is not set and this chunk is present, it SHOULD be ignored.

规范提到的伪代码描述也表示，loop count为0表示无限循环展示首帧到尾帧，而loop count >= 1，展示首帧到尾帧loop count次。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

assert VP8X.flags.hasAnimation
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
         background color ANIM.background_color.
loop_count ← ANIM.loopCount
dispose_method ← ANIM.disposeMethod
if loop_count == 0:
    loop_count = ∞
frame_params ← nil
assert next chunk in image_data is ANMF
for loop = 0..loop_count - 1
    clear canvas to ANIM.background_color or application defined color
    until eof or non-ANMF chunk
        frame_params.frameX = Frame X
        frame_params.frameY = Frame Y
        frame_params.frameWidth = Frame Width Minus One + 1
        frame_params.frameHeight = Frame Height Minus One + 1
        frame_params.frameDuration = Frame Duration
        #......
        Show the contents of the canvas for
            frame_params.frameDuration * 1ms.

同样的，APNG对应的num_plays字段意思是一样的，大家可以使用这个在线测试用例，Safari表现错误而多循环了一次：https://philip.html5.org/tests/apng/tests.html#num-plays-1

解决办法：
由于不能更改浏览器的实现，部分情况也不好引入JS来手动实现，因此，对于APNG，一般只用在iOS的WebView上，因此可以直接制作APNG图的时候，把循环减一。而Animated WebP，可以在客户端实现加一个Hack，如果loop不是0手动减一，保持和Web一致性（当然，也可以专门提供一个loop count加一的图给Chrome/Android的WebView），希望之后两大浏览器是否可以把这个Bug修复了（当然，不排除联合一起更改了规范的可能性）

总结

GIF作为一个动图格式已经太过于古老了，尤其是当前移动和Web站需要引入各种动态表情，头像的时候，GIF的透明问题已经是不可接受的。WebP长期发展也是比较看好（相比APNG没有进入PNG开发组，基本不再活跃），开源外加无授权费用，或许能够和WebM一样，成为互联网下首选的图片和视频格式。而移动客户端，在很多种需求下（动态表情，用户标志，广告）等上面，采用这种APNG和Animated WebP就能够轻松解决。