一個初級前端工程師的自我修養，前端工程師

一個初級前端工程師的自我修養，前端工程師

　　前言

　　最佳化！ 又是最佳化！

　　切圖崽們作為整個web應用的紐帶，串連著使用者行為和機器效能。 而 最佳化 的最終意義，在於在這兩者之間取得一個最佳的平衡點。

　　對於圖片資源的載入來說，更是如此。 今天我們就來簡單說說，項目開發中常見的圖片載入最佳化方式。

　　預先載入

　　1.遮罩大法

　　我們都知道， window.onload 實際上是 DOMContentLoaded 事件完成的回調，只是完成了DOM樹的構建。 諸如Css的渲染以及頁面內圖片等資源的下載不一定完成了。所以如果此時呈現頁面，頁面會非常難看。

　　為瞭解決這個問題，為了從設計和行為的角度提高使用者體驗， 我們可以在圖片等重要資源完全下載完之前，對頁面加上較為美觀的遮罩，並且彈出loading提示告知使用者資源正在loading.等到圖片完全載入完，才移除遮罩和載入動畫 .

　　具體的實現思路如下：

　　window.onload調用之後，先彈出蒙板加上loading動畫用來提示使用者正在loading中

　　對頁面中需要預先載入的IMG元素進行下載 var img = new Image（）； img.src="xx.jpg"

　　圖片下載完成會有一個onload的回調 img.onload = function（）{…}

　　在這個回調中移除loading動畫以及遮罩

　　這樣就可以給使用者帶來順滑如絲般的操作體驗了，再也不用擔心使用者看到那些正在下載的未顯示完全的醜的要死圖片了。

　　我們的口號是： 要麼就不給你看，要麼就給你看最好的應用情境： 請在”首屏中存在圖片的動畫，或者和你對接的UI設計師極其強勢”的情況下使用

　　2.有碼大法

　　有碼大法和遮罩大法略微有區別，具體實現思路如下：

　　首先對你需要預先載入的圖片準備兩張，一張是高清一張低清。 比如girl_hd大小為60kb. 另一張是girl, 大小是6kb.

　　html頁面中需要預先載入的image標籤的src地址寫的是低清的地址 <img src="girl.jpg" class="hd-replace">

　　因為低清圖很小，很快就能被載入出來。

　　window.onload調用之後，擷取頁面需要高清替換的img的src（girl.jpg），以此src為基準拼接字串（+’_hd.jpg’）獲得高清圖的地址（girl_hd.jpg），然後用下載該高清圖 var img = new Image（）； img.src=“girl_hd.jpg”

　　圖片下載完成會有一個onload的回調 img.onload = function（）{…}

　　回調中替換掉頁面中img的src, 所以現在頁面上的image標籤為 <img src="girl_hd.jpg" class="hd-replace">

　　我們的口號是： 想看無碼高清，請先看有碼低清應用情境： 請在”首屏中出現大量圖片，且尺寸都不小”的情況下使用

　　懶載入

　　如果你仔細看了上面預先載入的思路，一定往我腦袋上拍磚： 遮罩大法也好，有碼大法也好，這並沒有提高項目的載入速度啊，最後該下載的圖片還不是得下載。 沒錯，懶載入只是改變了使用者的操作感受，實際上項目的載入速度並沒有提高。 但是，現在要說的懶載入，可是實實在在的提高了項目的載入速度哦。

　　什麼是懶載入，一句話來解釋， 就是 圖片按需載入 .

　　大家一定刷過微博，微博的照片牆就是懶載入的最佳樣本。一開始顯示的照片並不多，只有使用者下拉，拉到底部的位置， 照片牆才會被拉長，新的圖片才會被載入。

　　操作思路：

　　監聽 捲軸scroll 事件（當然 touchmove 事件也可以）

　　每次事件觸發的時候，判斷當前照片牆的位置

　　如果照片牆已經被刷到了底部某個臨界位置點

　　Js下載新出現的圖片， var img = new Image（）； img.src="xx.jpg"

　　下載完成有一個onload的回調 img.onload = function（）{…}

　　在下載完成的回調中向頁面中插入已經下載好的圖片

　　當然，根據項目不同，會有各種各樣的懶載入方式。但核心是不變的： 即頁面初始載入的時候，只載入滿足使用者需求的最小數量的資源 . 拿照片牆舉例，可能使用者的微博裡有500張照片，如果你在頁面載入的時候就載入500張，使用者會卡到爆炸（因為後台一直處於圖片下載狀態）。 如果頁面載入的時候只初始載入20張圖片，其他的圖片通過使用者自己的操作（滾動下拉），來按需載入，會極大提升項目啟動並執行流暢程度。

　　結語

　　雖然預先載入還是懶載入實現原理都非常簡單，給我的啟示確是巨大的：

　　預先載入 除了改善使用者的操作感受，其深層次的核心其實在於： 對資源進行片段化載入 , 即預先載入其實可以出現在任何時間段，當使用者滑鼠很長時間沒移動的時候，我可不可以偷偷下載兩張圖片？在使用者目前沒有進行大量運算操作的時候，我可不可以偷偷下載兩張圖片？當使用者當前在一個很精簡的登陸介面的時候，我可不可以偷偷下載他登陸成功跳轉到的頁面的幾張圖片？等等等等

　　懶載入 的深層次核心在於： 按需 , 按需這個詞已經被深深刻在我腦子裡了。 現在回想起來，很多很多最佳化方式都是圍繞著按需來展開的。 按需載入Js , 按需載入圖片 等等

　　首先，我們必須保證項目第一時間的載入速度，能讓使用者在最短的時間內看到頁面和內容。

　　其次，盡量保證當前頁面的精簡程度，不去做無意義的載入。 只有當使用者真正需要時，我們才展現給他。

　　各自的優缺點在於：

　　預先載入：

　　優點：如果提前下好了圖片，等到這張圖片需要用到時，可以秒開。

　　缺點：下載圖片的時候會影響項目的載入完成時間，會影響項目啟動並執行流暢程度

　　懶載入在於：

　　優點： 保證使用者載入的項目是最精簡的，最快的， 所下載資源是最少的

　　缺點： 如果使用者的操作觸發了懶載入，那麼需要等待資源下載到完成的時間，同時資源下載期間，操作流暢度降低

　　說到底，項目的最佳化是沒有銀彈的，這一部分的高效很可能導致另一部分的低效。A項目的最佳化方法照搬來B項目可能一文不值。所以我們切圖崽們能做的，就是深刻理解這些技術的原理，並且在項目中吸收經驗，只有深刻地理解了各項技術的優劣，只有深刻的理解了使用者的需求以及行為習慣，才能針對特定的項目，特定的情境，進行最適合的處理。