己寫自定義組件的時候，找到幾個圖標，放在項目目錄下，但在使用的時候發現小程序里面顯示不出來。

微信小程序里面這樣：

看網上的文章說要改成絕對路徑，但我在在back-audio里面根本就沒有發現play.png這個文件，那么怎么改src都不可能顯示出來。除非放在static里面，但我想把組件獨立出來使用。

無意中看到別人寫的自定義組件，里面也有使用圖標，試了下，可行！

圖片、圖標使用require導入

三個控制播放圖標代碼：

<template>
    <view class="audio-warp">
        <view class="audio-time" v-if="showTime">{{ audioTimeUpdate }}</view>
        <view class="control-btns">
            <image :src="backIcon" @click="backClick()" :class="{disabled: backDisabled}"></image>
            <view class="" @click="audioPlayPause()">
                <image :src="pauseIcon" v-if="play"></image>
                <image :src="playIcon" v-else></image>
            </view>
            <image :src="forwardIcon" @click="forwardClick()" :class="{disabled: forwardDisabled}"></image>
        </view>
    </view>
</template>
...
        data() {
            return {
                playIcon: require('./icons/play.png'),
                pauseIcon: require('./icons/pause.png'),
                backIcon: require('./icons/player_back.png'),
                forwardIcon: require('./icons/player_forward.png'),

在data中使用require來生成圖標的變量對象，記得使用相對路徑，也就是圖標相對于當前頁面的路徑，然后使用v-model與src綁定。

查看微信小程序可以發現這些圖標其實是被uniapp轉換成了Data URI scheme。

網頁圖片中的src可以是一個圖片對象，這樣可以減少請求。

在 Data URI scheme 中：

data 表示取得數據的協定名稱；

image/png 是數據類型名稱；

base64 是數據的編碼方法，逗號后面就是這個image/png文件base64編碼后的數據。

原來，Data URI scheme支持的類型有不少。

data: 文本數據 data: text/plain,  文本數據 
data: text/html,  HTML代碼 
data: text/html;base64,  base64編碼的HTML代碼 
data: text/css,  CSS代碼 
data: text/css;base64,  base64編碼的CSS代碼
data: text/javascript,  Javascript代碼 
data: text/javascript;base64,  base64編碼的Javascript代碼 
data: image/gif;base64,  base64編碼的gif圖片數據 
data: image/png;base64,  base64編碼的png圖片數據 
data: image/jpeg;base64,  base64編碼的jpeg圖片數據 
data: image/xicon;base64,  base64編碼的icon圖片數據

這下再也不怕什么路徑問題了，直接就嵌入到頁面中了。

另外，有些初學者在uniapp使用傳統img，容易出問題，在uniapp里，使用image來顯示圖片。

我是@愛玩的安哥，關注我獲取更多有用知識

言：對于大多數前端工程師來說，圖片就是UI設計師(或者自己)切好的圖，你要做的只是把圖片丟進項目中，然后用以鏈接的方式呈現在頁面上，而且我們也經常把精力放在項目的打包優化構建上，如何分包，如何抽取第三方庫……..有時我們會忘了，圖片才是一個網站最大頭的那塊加載資源(見下圖)，雖然圖片加載可以不不阻礙頁面渲染，但優化圖片，絕對可以讓網站的體驗提升一個檔次。

1.選擇圖片格式

如果效果真的需要圖片來表現，那么選擇圖片格式是優化的第一步。我們經常聽到的詞語包括矢量圖、標量圖、SVG、有損壓縮、無損壓縮等等，我們首先說明各種圖片格式的特點

圖片格式壓縮方式透明度動畫瀏覽器兼容適應場景JPEG有損壓縮不支持不支持所有復雜顏色及形狀、尤其是照片 漸進式吃cpuGIF無損壓縮支持支持所有簡單顏色，動畫PNG無損壓縮支持不支持所有需要透明時，但是體積太大APNG無損壓縮支持支持FirefoxSafariiOS Safari需要半透明效果的動畫WebP有損壓縮支持支持ChromeOperaAndroid ChromeAndroid Browser復雜顏色及形狀瀏覽器平臺可預知SVG無損壓縮支持支持所有（IE8以上）簡單圖形，需要良好的放縮體驗需要動態控制圖片特效

2.從圖片大小開始優化

壓縮圖片可以使用統一的壓縮工具 — imagemin，它是一款可以集成多個壓縮庫的工具，支持jpg，png，webp等等格式的圖片壓縮，比如pngquant，mozjpeg等等，作為測試用途，我們可以直接安裝imagemin-pngquant來嘗試png圖片的壓縮

1. png壓縮

  npm install imagemin
  npm install imagemin-pngquant
``

先安裝imagemin庫，再安裝對應的png壓縮庫
```js
    const imagemin=require('imagemin');
    const imageminPngquant=require('imagemin-pngquant');

    (async ()=> {
        await imagemin(['images/*.png'], 'build/images', {
            plugins: [
                imageminPngquant({ quality: '65-80' })
            ]
        });

        console.log('Images optimized');
    })();

quailty一項決定壓縮比率，65-80貌似是一個在壓縮率和質量之間實現平衡的數值

2. PG/JPEG壓縮與漸進式圖片 壓縮jpg/jpeg圖片的方式與png類似，imagemin提供了兩個插件：jpegtrain和mozjpeg供我們使用。一般我們選擇mozjpeg，它擁有更豐富的壓縮選項:

npm install imagemin-mozjpeg

    const imagemin=require('imagemin');
    const imageminMozjpeg=require('imagemin-mozjpeg');

    (async ()=> {
        await imagemin(['images/*.jpg'], 'build/images', {
            use: [
                imageminMozjpeg({ quality: 65, progressive: true })
            ]
        });

        console.log('Images optimized');
    })();
    

注意到我們使用了progressive:true選項，這可以將圖片轉換為漸進式圖片，關于漸進式圖片，它允許在加載照片的時候，如果網速比較慢的話，先顯示一個類似模糊有點小馬賽克的質量比較差的照片，然后慢慢的變為清晰的照片：

漸進式圖片 Progressive JPEG

Progressive JPEG文件包含多次掃描，這些掃描順尋的存儲在JPEG文件中。打開文件過程中，會先顯示整個圖片的模糊輪廓，隨著掃描次數的增加，圖片變得越來越清晰。這種格式的主要優點是在網絡較慢的情況下，可以看到圖片的輪廓知道正在加載的圖片大概是什么。在一些網站打開較大圖片時，你就會注意到這種技術。

非漸進式的圖片(Baseline JPEG)

這種類型的JPEG文件存儲方式是按從上到下的掃描方式，把每一行順序的保存在JPEG文件中。打開這個文件顯示它的內容時，數據將按照存儲時的順序從上到下一行一行的被顯示出來，直到所有的數據都被讀完，就完成了整張圖片的顯示。如果文件較大或者網絡下載速度較慢，那么就會看到圖片被一行行加載的效果，這種格式的JPEG沒有什么優點，因此，一般都推薦使用Progressive JPEG。

基本JPEG和漸進JPEG該什么時候使用？

當您的JPEG圖像低于10K時，最好保存為基本JPEG（估計有75％的可能性會更?。?對于超過10K的文件，漸進式JPEG將為您提供更好的壓縮（在94％的情況下） Chrome + Firefox + IE9瀏覽器下，漸進式圖片加載更快，而且是快很多，至于其他瀏覽器，與基本式圖片的加載一致，至少不會拖后腿。

漸進式圖片也有不足，就是吃CPU吃內存。

總結一下兩者的區別：

漸進式jpeg(progressive jpeg)圖片及其相關 簡單來說，漸進式圖片一開始就決定了大小，而不像Baseline圖片一樣，不斷地從上往下加載，從而造成多次回流，但漸進式圖片需要消耗CPU去多次計算渲染，這是其主要缺點。 當然，交錯式png也可以實現相應的效果，但目前pngquant沒有實現轉換功能，但是ps中導出png時是可以設置為交錯式的。

那我們怎么查看圖片是漸進式還是基本的呢

通過對比保存的圖片格式（格式在線分析：https://exif.tuchong.com/）

也有一些網上推薦的轉化工具

https://www.imgonline.com.ua/eng/compress-image.php

http://www.imagemagick.org/script/download.php

說了這么多，是不是感覺很啰嗦,接下來我們在實際項目中如何操作

實際項目中，總不能UI丟一個圖過來你就跑一遍壓縮代碼吧？幸好imagemin有對應的webpack插件，在webpack遍地使用的今天，我們可以輕松實現批量壓縮：

先安裝imagemin-webpack-plugin

npm install imagemin-webpack-plugin

    import ImageminPlugin from 'imagemin-webpack-plugin'
    import imageminMozjpeg from 'imagemin-mozjpeg'

    module.exports={
      plugins: [
        new ImageminPlugin({
          plugins: [
            imageminMozjpeg({
              quality: 100,
              progressive: true
            })
          ]
        })
      ]
    }

接著在webpack配置文件中，引入自己需要的插件，使用方法完全相同。具體可參考github的文檔imagemin-webpack-plugin

同時我們推薦幾種比較好用的圖片壓縮工具

1. docsmall在線圖片壓縮

https://docsmall.com/

國內公司開發在線圖片壓縮工具

服務器在國內，上傳速度很快

頁面簡潔無廣告，美觀大方

壓縮率很好，基本能壓縮到原來的一半以下

壓縮出的圖片畫質很清晰，跟原圖幾乎沒有差別

對png、jpg格式的支持都很好

還有針對PDF的壓縮功能

2. tinypng

https://tinypng.com/

國外團隊開發的在線圖片壓縮網站，有口皆碑

唯一的問題就是上傳速度不夠快，畢竟是國外的

界面全英文，對英語不好的朋友來說不夠友好

3. 智圖

https://zhitu.isux.us/

騰訊的一個團隊出品

可以自定義壓縮比例，如果壓出來的體積不夠小，你還可以選擇一個更高的壓縮率

保證圖片體積夠小

3.通過圖片按需加載減少請求壓力

圖片按需加載是個老生常談的話題，傳統做法自然是通過監聽頁面滾動位置，符合條件了再去進行資源加載，我們看看如今還有什么方法可以做到按需加載。

使用強大的IntersectionObserver IntersectionObserver提供給我們一項能力：可以用來監聽元素是否進入了設備的可視區域之內，這意味著：我們等待圖片元素進入可視區域后，再決定是否加載它，畢竟用戶沒看到圖片前，根本不關心它是否已經加載了。 這是Chrome51率先提出和支持的API，而現在，各大瀏覽器對它的支持度已經有所改善(除了IE，全線崩~) 廢話不多說，上代碼： 首先，假設我們有一個圖片列表，它們的src屬性我們暫不設置，而用data-src來替代：

    <li>
      <img class="list-item-img" alt="loading" data-src='a.jpg'/>
    </li>
    <li>
      <img class="list-item-img" alt="loading" data-src='b.jpg'/>
    </li>
    <li>
      <img class="list-item-img" alt="loading" data-src='c.jpg'/>
    </li>
    <li>
      <img class="list-item-img" alt="loading" data-src='d.jpg'/>
    </li>

這樣會導致圖片無法加載，這當然不是我們的目的，我們想做的是，當IntersectionObserver監聽到圖片元素進入可視區域時，將data-src”還給”src屬性，這樣我們就可以實現圖片加載了:

    const observer=new IntersectionObserver(function(changes) {
      changes.forEach(function(element, index) {
       // 當這個值大于0，說明滿足我們的加載條件了，這個值可通過rootMargin手動設置
        if (element.intersectionRatio > 0) {
          // 放棄監聽，防止性能浪費，并加載圖片。
          observer.unobserve(element.target);
          element.target.src=element.target.dataset.src;
        }
      });
    });
    function initObserver() {
      const listItems=document.querySelectorAll('.list-item-img');
      listItems.forEach(function(item) {
       // 對每個list元素進行監聽
        observer.observe(item);
      });
    }
    initObserver();

運行代碼并觀察控制臺的Network，會發現圖片隨著可視區域的移動而加載，我們的目的達到了。

IntersectionObserver

瀏覽器兼容

還是Chrome的黑科技——loading屬性

從新版本Chrome(76)開始，已經默認支持一種新的html屬性——loading，它包含三種取值:auto、lazy和eager(ps: 之前有文章說是lazyload屬性，后來chrome的工程師已經將其確定為loading屬性，原因是lazyload語義不夠明確)，我們看看這三種屬性有什么不同：

1. auto：讓瀏覽器自動決定是否進行懶加載，這其中的機制尚不明確。
2. lazy：明確地讓瀏覽器對此圖片進行懶加載，即當用戶滾動到圖片附近時才進行加載，但目前沒有具體說明這個“附近”具體是多近。
3. eager：讓瀏覽器立刻加載此圖片

這個現象跟chrome的lazy-loading功能的實現機制有關：

首先，瀏覽器會發送一個預請求，請求地址就是這張圖片的url，但是這個請求只拉取這張圖片的頭部數據，大約2kb，具體做法是在請求頭中設置range: bytes=0-2047，

而從這段數據中，瀏覽器就可以解析出圖片的寬高等基本維度，接著瀏覽器立馬為它生成一個空白的占位，以免圖片加載過程中頁面不斷跳動，這很合理，總不能為了一個懶加載，讓用戶犧牲其他方面的體驗吧？這個請求返回的狀態碼是206，表明：客戶端通過發送范圍請求頭Range抓取到了資源的部分數據，詳細的狀態碼解釋可以看看這篇文章

然后，在用戶滾動到圖片附近時，再發起一個請求，完整地拉取圖片的數據下來，這個才是我們熟悉的狀態碼200請求。

可以預測到，如果以后這個屬性被普遍使用，那一個服務器要處理的圖片請求連接數可能會變成兩倍，對服務器的壓力會有所增大，但時代在進步，我們可以依靠http2多路復用的特性來緩解這個壓力，這時候就需要技術負責人權衡利弊了

要注意，使用這項特性進行圖片懶加載時，記得先進行兼容性處理，對不支持這項屬性的瀏覽器，轉而使用JavaScript來實現，比如上面說到的IntersectionObserver：

    if ("loading" in HTMLImageElement.prototype) {
      // 支持loading
    } else {
      // .....
    }

4.通過占位圖解決網速較慢視覺空白問題

當網速慢的時候，圖片還沒加載完之前，用戶會看到一段空白的時間，在這段空白時間，就算是漸進式圖片也無法發揮它的作用，我們需要更友好的展示方式來彌補這段空白，有一種方法簡單粗暴，那就是用一張占位圖來頂替，這張占位圖被加載過一次后，即可從緩存中取出，無須重新加載，但這種圖片會顯得有些千篇一律，并不能很好地做到preview的效果。

這里介紹另一種占位圖做法——css漸變色背景，原理很簡單，當img標簽的圖片還沒加載出來，我們可以為其設置背景色，比如:

<img src="a.jpg" style="background: red;"/>

這樣會先顯示出紅色背景，再渲染出真實的圖片，重點來了，我們此時要借用工具為這張圖片"配制"出合適的漸變背景色，以達到部分preview的效果，我們可以使用 https://calendar.perfplanet.com/2018/gradient-image-placeholders/ 這篇文章中推薦的工具GIP進行轉換 ，這里附上在線轉換的地址 https://tools.w3clubs.com/gip/

經過轉換后，我們得到了下面這串代碼：

background: linear-gradient(
      to bottom,
      #1896f5 0%,
      #2e6d14 100%
    )

5.響應式圖片的實踐

我們經常會遇到這種情況：一張在普通筆記本上顯示清晰的圖片，到了蘋果的Retina屏幕或是其他高清晰度的屏幕上，就變得模糊了。

這是因為，在同樣尺寸的屏幕上，高清屏可以展示的物理像素點比普通屏多，比如Retina屏，同樣的屏幕尺寸下，它的物理像素點的個數是普通屏的4倍(2 * 2)，所以普通屏上顯示清晰的圖片，在高清屏上就像是被放大了，自然就變得模糊了，要從圖片資源上解決這個問題，就需要在設備像素密度為2的高清屏中，對應地展示一張兩倍大小的圖。

而通常來講，對于背景圖片，我們可以使用css的@media進行媒體查詢，以決定不同像素密度下該用哪張倍圖，例如：

.bg {
    background-image: url("bg.png");
    width: 100px;
    height: 100px;
    background-size: 100% 100%;
}
@media (-webkit-min-device-pixel-ratio: 2),(min-device-pixel-ratio: 2)
{
    .bg {
        background-image: url("bg@2x.png") // 尺寸為200 * 200的圖
    }
}

這么做有兩個好處，一是保證高像素密度的設備下，圖片仍能保持應有的清晰度，二是防止在低像素密度的設備下加載大尺寸圖片造成浪費。

那么如何處理img標簽呢？

我們可以使用HTML5中img標簽的srcset來達到這個效果，看看下面這段代碼：

<img width="320"  src="bg@2x.png" srcset="bg.png 1x;bg@2x.png 2x"/>

這段代碼的作用是：當設備像素密度，也就是dpr(devicePixelRatio)為1時，使用bg.png，為2時使用二倍圖bg@2x.png，依此類推，你可以根據需要設置多種精度下要加載的圖片，如果沒有命中，瀏覽器會選擇最鄰近的一個精度對應的圖片進行加載。 要注意：老舊的瀏覽器不支持srcset的特性，它會繼續正常加載src屬性引用的圖像。

要同時適配不同像素密度、不同大小的屏幕，應該怎么辦呢？

<picture>
  <source media="(max-width: 500px)" srcset="cat-vertical.jpg">
  <source media="(min-width: 501px)" srcset="cat-horizontal.jpg">
  <img src="cat.jpg" alt="cat">
</picture>

就要用到標簽。它是一個容器標簽，內部使用和，指定不同情況下加載的圖像。

上面代碼中，標簽內部有兩個標簽和一個標簽。

標簽的media屬性給出媒體查詢表達式，srcset屬性就是標簽的srcset屬性，給出加載的圖像文件。sizes屬性其實這里也可以用，但由于有了media屬性，就沒有必要了。

瀏覽器按照標簽出現的順序，依次判斷當前設備是否滿足media屬性的媒體查詢表達式，如果滿足就加載srcset屬性指定的圖片文件，并且不再執行后面的標簽和標簽。

標簽是默認情況下加載的圖像，用來滿足上面所有都不匹配的情況。

上面例子中，設備寬度如果不超過500px，就加載豎屏的圖像，否則加載橫屏的圖像。

標簽的type屬性

除了響應式圖像，標簽還可以用來選擇不同格式的圖像。比如，如果當前瀏覽器支持 Webp 格式，就加載這種格式的圖像，否則加載 PNG 圖像。

<picture>
  <source type="image/svg+xml" srcset="logo.xml">
  <source type="image/webp" srcset="logo.webp"> 
  <img src="logo.png" alt="ACME Corp">
</picture>

上面代碼中，標簽的type屬性給出圖像的 MIME 類型，srcset是對應的圖像 URL。

瀏覽器按照標簽出現的順序，依次檢查是否支持type屬性指定的圖像格式，如果支持就加載圖像，并且不再檢查后面的標簽了。上面例子中，圖像加載優先順序依次為 svg 格式、webp 格式和 png 格式。

6.自動優化：CDN

使用CDN對圖片自動進行優化，我在國外的CDN提供商處很少見到這類服務，倒是國內的兩大新秀CDN七牛和又拍在這方面都做了大量工作。其工作方式為，向CDN請求圖片的URL參數中包含了圖片處理的參數（格式、寬高等），CDN服務器根據請求生成所需的圖片，發送到用戶瀏覽器。

七牛云存儲的圖片處理接口極其豐富，覆蓋了圖片的大部分基本操作，例如：

圖片裁剪，支持多種裁剪方式（如按長邊、短邊、填充、拉伸等） 圖片格式轉換，支持JPG, GIF, PNG, WebP等，支持不同的圖片壓縮率 圖片處理，支持圖片水印、高斯模糊、重心處理等

當然其他cdn對于圖像處理也有很豐富的處理，相關文檔里也介紹很詳細，可以參考cdn文檔

阿里云

騰訊

我們通過如下URL請求，裁剪正中部分，等比縮小生成200x200縮略圖：

http://qiniuphotos.qiniudn.com/gogopher.jpg?imageView2/1/w/200/h/200

七牛cdn

7.對Base64Url的反思

首先復習一下Base64的概念，Base64就是一種基于64個可打印字符來表示二進制數據的方法，編碼過程是從二進制數據到字符串的過程，在web應用中我們經常用它來做啥呢——傳輸圖片數據。HTML中，img的src和css樣式的background-image都可以接受base64字符串，從而在頁面上渲染出對應的圖片。正是基于瀏覽器的這項能力，很多開發者提出了將多張圖片轉換為base64字符串，放進css樣式文件中的“優化方式”，這樣做的目的只有一個——減少HTTP請求數。但實際上，在如今的應用開發中，這種做法大多數情況是“負優化”效果，接下來讓我們細數base64 Url的“罪狀”：

第一、讓css文件的體積失去控制

當你把圖片轉換為base64字符串之后，字符串的體積一般會比原圖更大，一般會多出接近3成的大小，如果你一個頁面中有20張平均大小為50kb的圖片，轉它們為base64后，你的css文件將可能增大1.2mb的大小，這樣將嚴重阻礙瀏覽器的關鍵渲染路徑：

css文件本身就是渲染阻塞資源，瀏覽器首次加載時如果沒有全部下載和解析完css內容就無法進行渲染樹的構建，而base64的嵌入則是雪上加霜，這將把原先瀏覽器可以進行優化的圖片異步加載，變成首屏渲染的阻塞和延遲。

或許有人會說，webpack的url-loader可以根據圖片大小決定是否轉為base64(一般是小于10kb的圖片)，但你也應該擔心如果頁面中有100張小于10kb的圖片時，會給css文件增加多少體積。

第二、讓瀏覽器的資源緩存策略功虧一簣

假設你的base64Url會被你的應用多次復用，本來瀏覽器可以直接從本地緩存取出的圖片，換成base64Url，將造成應用中多個頁面重復下載1.3倍大小的文本，假設一張圖片是100kb大小，被你的應用使用了10次，那么造成的流量浪費將是:(100 1.3 10) - 100=1200kb。

第三、低版本瀏覽器的兼容問題

這是比較次要的問題，dataurl在低版本IE瀏覽器，比如IE8及以下的瀏覽器，會有兼容性問題，詳細情況可以參考這篇文章。

第四、不利于開發者工具調試與查看

無論哪張圖片，看上去都是一堆沒有意義的字符串，光看代碼無法知道原圖是哪張，不利于某些情況下的比對。 說了這么多 既然這種方案缺點這么多，為啥它會從以前就被廣泛使用呢？這要從早期的http協議特性說起，在http1.1之前，http協議尚未實現keep-alive，也就是每一次請求，都必須走三次握手四次揮手去建立連接，連接完又丟棄無法復用，而即使是到了http1.1的時代，keep-alive可以保證tcp的長連接，不需要多次重新建立，但由于http1.1是基于文本分割的協議，所以消息是串行的，必須有序地逐個解析，所以在這種請求“昂貴”，且早期圖片體積并不是特別大，用戶對網頁的響應速度和體驗要求也不是很高的各種前提結合下，減少圖片資源的請求數是可以理解的。

但是，在越來越多網站支持http2.0的前提下，這些都不是問題，h2是基于二進制幀的協議，在保留http1.1長連接的前提下，實現了消息的并行處理，請求和響應可以交錯甚至可以復用，多個并行請求的開銷已經大大降低，我已經不知道還有什么理由繼續堅持base64Url的使用了。

總結

圖片優化的手段總是隨著瀏覽器特性的升級，網絡傳輸協議的升級，以及用戶對體驗要求的提升而不停地更新迭代，幾年前適用的或顯著的優化手段，幾年后不一定仍然如此。因地制宜，多管齊下，才能將其優化做到極致！