iOS啓動優化之首屏圖片加載優化

原文地址：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 首頁數據加載 首頁構建繪製

四個階段的耗時預計大概在1:1:3:3，固然每一個具體APP的狀況可能不太一致，不過能夠大體的描述After-main的啓動過程。

頁面加載展現加速

在首頁構建繪製展現是以首屏的最後一張圖片的加載完成爲終結。其中，圖片的加載的耗時佔比較重，約爲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內容