原文地址：mp.weixin.qq.com/s?__biz=Mzg…
上一篇文章我们讲到App启动时间的构成： Time(App总启动时间) = time1(main()之前的加载时间) + time2(main()之后的加载时间)。 time1 = 系统加载app的时间：（系统dylib(动态链接库)和自身App可执行文件的加载） time2 = app加载渲染完成首界面的时间：（主要是构建第一个界面，并完成渲染展示）。
今天我们来看一下time2的耗时花在了哪里？ After-main的启动过程可以分为以下四个阶段： AppDelegate LaunchScreenViewController 首页数据加载 首页构建绘制
页面加载展示加速
在首页构建绘制展示是以首屏的最后一张图片的加载完成为终结。其中，图片的加载的耗时占比较重，约为50%以上，而今天我们来讨论一下针对于图片的优化：改用webp格式的图片进行页面展示的加速200ms以上。
何为WebP？
WebP （发音为“weppy”/(wĕpˈē)/）是 Google 开发的一种图片压缩格式，用于降低图片文件的大小。Google 说图片和照片差不多占到了通过网络传输的数据总量的65% ，这是相当大的份额。这也就可以理解为什么降低每一个图片的大小，可以影响平均的页面大小，进而加快页面的装载速度。
WebP 有损压缩过程
分块（MacroBlocking）
编码器的第一个阶段将图片划分成多个宏块（macro blocks），典型的宏块由一个 16×16 的亮度像素(luma pixel)块和两个 8×8 的色度像素(chroma pixel)块组成。分块越小，预测越准，需要记录的信息也越多。一般来说，细节越丰富的地方，分块越细，即使用 4×4 分块预测。细节相对不丰富的地方使用 16×16 分块。（这一过程相当于 JPEG 编码中的色彩空间转换）
帧内预测
宏块里每个4x4的子块都有一个预测模型。(又名过滤)。在PNG里过滤用得非常多，它对每一行都做同样的事，而WebP过滤的是每一块。它是这样处理的，在一个块周围定义两组像素:有一行在它上面为A，在它左边那一列为L:
利用A和L，编码器会将它们放在一个4x4的测试像素块填满，并确定哪一个生成了最接近原始块的值。这些用不同方法填满的块叫做"预测块"。
Horiz prediction(水平预测)——将块的每列使用左列（L）数据的副本进行填充。 Vertical Prediction(垂直预测)——将块的每行使用上列（A）数据的副本进行填充。 DC Prediction(DC 预测)——将块使用 A 上列的像素与 L 左列的像素的平均值进行填充。 True Motion (TrueMotion 预测)——一种超级先进的模式，比较接近真实数据 下图展示了 4×4 分块的所有帧内预测模型基本流程是我们找到这个快最佳的预测块，并导出过滤结果(剩余误差)，然后送到下个阶段。
使用哪种分块预测模式是动态决定的。编码器会将所有可能的预测模式都计算出来，然后选出错误程度最小的模式。
DCT（离散余弦变换）
将预测部分的原图像数据减去预测出来的数据，得到差值矩阵，最后对差值进行 DCT。此步骤会生成一个频率系数矩阵，左上的系数幅度最大，右下最小。幅度值越小，频率越高。大部分图片信息都在左上区域。这一步的作用就是找出图片的高频和低频区域。
量化
人眼对高频部分不敏感，这一步会将高频部分舍去。对上一步的频率系数表和量化表进行计算，将频率系数表和量化表按位相除，并四舍五入位整数。最终生成一个量化矩阵。
算法编码
WebP使用 Arithmetic entropy encoding，该算法相比JPEG上使用的 Huffman encoding，在压缩表现上更出色。
总结一下，WebP 对图片进行分块，然后对待填充的宏块使用了帧间预测技术，根据其附近已编码宏块的数据，预测出当前块数据。相比 JEPG 对图像原值进行编码，WebP 编码的是预测值和原值的差值，这是 WebP 体积更小的主要原因。最后，WebP 使用了更优秀的算数编码。
iOS对WebP的支持
SDWebImage中支持WebP格式的，可以完成UIImage -> Webp和WebP -> UIImage的转换。直接通过CocoaPods的Podfile文件中加入pod 'SDWebImage/WebP'即可。
SDWebImage/WebP提供了UIImage+WebP的Category里面有个将WebP NSData的数据转换为UIImage的方法：
+ (UIImage *)sd_imageWithWebPData:(NSData *)data;
在Native中使用WebP格式图片
总结
通过测试，JPG 和 PNG 转成 WebP 后，实际体积大概减少如下：
根据测试结果可见，对 PNG 进行 WebP 无损压缩后，体积减少了 31%，这与 Google 宣称的 26% 大体吻合。WebP 有损压缩的减少比例则更大，将图片质量降低到原来的 75% 后，减少体积达 90% 左右。
最终的效果与PM &UE同学验收之后，统一出一个标准,把所有的网络图片按照标准进行输出。这样能整体减少网络间传输图片的体积，加快了首页图片的加载速度，
实际验收时大约节省了200+ms左右。
参考：developers.google.com/speed/webp
关注公众号，学习更多iOS内容
