[iOS/OC]iOS10.3.3上APNG不动
0x0背景
原本是放到自己博客的，不怎么用了，把文章同步过来，原文地址[iOS/OC]iOS10.3.3上APNG不动
问题现象：有1张APNG动图，在其他系统上都OK，单单在iOS10.3.3上不动。特别迷，花了一下午的时间排查这个问题。最终咨询了@DreamPiggy ，才把这个问题搞清楚。
0x1原因
APNG的数据块有IHDR、acTL、fcTL、IDAT、fdAT等类型。每帧APNG的图像由1个FCTL，>=1个(通常是1~2个)IDAT图像组成。其中FCTL是每帧的控制信息，IDAT是图像信息。在iOS10.3.3系统中，当每帧APNG的fdAT>=3时，系统解码会出错，导致解码失败，并取第一帧信息作为解码结果，即展示PNG静图。
简单的说，即：
iOS 10.3.3系统BUG，在APNG较大且较复杂时，APNG解码失败，返回首帧PNG静图。
0x2APNG
分析过程中，第一步就是查询APNG的标准，发现这块文档十分匮乏，尤其是中文文档。在此，按个人理解整理一份。
1.APNG结构
一个流传甚广的图如下。PNG的基本结构是PNG签名(PNG Signature)+图像头(IHDR)+数据块(IDAT)+结束块(IEND)，4部分组成，而APNG则是在此基础上扩展，主要是增加了acTL控制块保存整体动图控制信息，将N张图片的IDAT取出来作为每一帧的信息，并在每一帧增加fcTL控制卡保存每帧图像的控制信息。
[图片上传失败...(image-90acc5-1537881630217)]
2.手工解码APNG
只知道APNG的结构，当出现APNG相关问题的时候，你还是不知道是怎么回事。下面我以上面有问题的APNG为例，手工解码APNG。从结构上分，APNG有PNG签名、数据块，两种类型。
1）PNG签名
整个文件的前8个byte是PNG签名头，为8950 4e47 0d0a 1a0a，将这8个byte转为ascii就是PNG
[图片上传失败...(image-c96bb8-1537881630218)]
2）数据块类型
数据块(chunk)常见类型有：IHDR、acTL、fcTL、IDAT、fdAT、IEND
基本格式如下：
| 序号 | 描述 | 长度(byte) |
|---|---|---|
| 1 | chunk内容长度 | 4 |
| 2 | chunk类型 | 4 |
| 3 | chunk内容 | 由1chunk内容长度决定 |
| 4 | 校验码 | 4 |
其中chunk类型将其由hex转为ascii，即为对应的值，如：
[图片上传失败...(image-e3dd5b-1537881630218)]
①IHDR
| 长度(byte) | 内容 | 意义 |
|---|---|---|
| 4 | 0000 000d | chunk内容长度为13 byte |
| 4 | 4948 4452 | IDHR |
| 13 | 0000 0465 0000 01ea 0806 0000 00 | 见下标 |
| 4 | ad34 f3f4 | 校验码 |
IHDR的内容意义如下：
| 描述 | 长度(byte) | 内容 |
|---|---|---|
| 图片宽度 | 4 byte | 0000 0465 |
| 图片高度 | 4 byte | 0000 01ea |
| 图像深度 | 1 byte | 8 |
| 颜色类型 | 1 byte | 6 |
| 压缩方法 | 1 byte | 0 |
| 过滤方式 | 1 byte | 0 |
| 扫描方式 | 1 byte | 0 |
②acTL
| 长度 | 内容 | 意义 |
|---|---|---|
| 4 byte | 0000 0008 | chunk内容长度为8 byte |
| 4 byte | 6163 544c | acTL |
| 8 byte | 0000 000a 0000 0000 | 前4byte为帧数，10帧；后4byte为循环次数，无限循环； |
| 4 byte | ad34 f3f4 | 校验码 |
③fcTL
| 长度 | 内容 | 意义 |
|---|---|---|
| 4 byte | 0000 001a | chunk内容长度为26 byte |
| 4 byte | 6663 544c | fcTL |
| 26 byte | 00 0000 0000 0004 6500 0001 ea00 0000 0000 0000 0000 0c00 6400 00 | 略 |
| 4 byte | 50 8aec fb | 校验码 |
④IDAT
| 长度 | 内容 | 意义 |
|---|---|---|
| 4 byte | 00 0080 00 | chunk内容长度为32768 byte |
| 4 byte | 4944 4154 | IDAT |
| 32768 byte | 略 | 略 |
| 4 byte | 876e ca46 | 校验码 |
3）数据块类型补充
在动图中，第1帧称为关键帧，其他帧信息在压缩算法下需要有第1帧计算得来。在APNG中，关键帧就是IDAT，第2帧开始为fdAT。
根据数据块类型可知，通常37byte开始，为acTL数据块，可以以此作为是否为APNG的标识。但是这个不是强制的，你也可以自己定义数据块类型，在IHDR之后添加相应信息。
例如，为APNG添加了签名和时间戳后，在Safari下显示是正常的，在Chrome下就无法正常加载。即：Chrome和Safari对于APNG的标准解读不同，且明显Chrome对APNG的标准支持不完善。
3.参考文章
PNG规范中文解读：png的故事：获取图片信息和像素内容
PNG标准英文文档：PNG (Portable Network Graphics) Specification, Version 1.2
APNG标准英文文档：APNG Specification
APNG介绍：APNG那些事
APNG分析网站：https://animatedpngs.com/
HEX转ascii网站：https://www.rapidtables.com/convert/number/hex-to-ascii.html
0x3问题分析
1.分析图片数据
在有以上的对APNG的知识储备后，就可以开始进行正式的问题分析了。
对多组图片手动解码，分析fdAT数据发现，fdAT在同一帧中连续3次或以上，会导致在iOS10.3.3上解码失败。结论以猜测为主，部分证实，暂无实锤。相关数据就不放了。有兴趣的同学可以自己解析一下看看。
2.ImageIO的符号断点
ImageIO有一个LogDebug函数，添加符号断点后，可以断到这个符号，侧面印证了此时系统APNG解码失败。
0x4总结
有必要总结下。各大厂对图片格式的解读是不一致的，尤其是在动图上，在一些特定场景下就会踩坑。目前我已知的有：
1.本文的问题，APNG的fdAT>=3时，苹果系统(iOS/mac os)解码失败，变为静图；
2.APNG添加签名后，Android解码失败，无法展示；
3.安卓和苹果对GIF的循环次数理解不一致，通常可以在苹果解GIF时循环次数加1，以保持多端一致；
其他隐藏的坑不知道还有多少。
