整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
己寫自定義組件的時(shí)候，找到幾個(gè)圖標(biāo)，放在項(xiàng)目目錄下，但在使用的時(shí)候發(fā)現(xiàn)小程序里面顯示不出來(lái)。
微信小程序里面這樣：
看網(wǎng)上的文章說(shuō)要改成絕對(duì)路徑，但我在在back-audio里面根本就沒有發(fā)現(xiàn)play.png這個(gè)文件，那么怎么改src都不可能顯示出來(lái)。除非放在static里面，但我想把組件獨(dú)立出來(lái)使用。
無(wú)意中看到別人寫的自定義組件，里面也有使用圖標(biāo)，試了下，可行！
三個(gè)控制播放圖標(biāo)代碼：
<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來(lái)生成圖標(biāo)的變量對(duì)象，記得使用相對(duì)路徑，也就是圖標(biāo)相對(duì)于當(dāng)前頁(yè)面的路徑，然后使用v-model與src綁定。
查看微信小程序可以發(fā)現(xiàn)這些圖標(biāo)其實(shí)是被uniapp轉(zhuǎn)換成了Data URI scheme。
網(wǎng)頁(yè)圖片中的src可以是一個(gè)圖片對(duì)象，這樣可以減少請(qǐng)求。
在 Data URI scheme 中：
data 表示取得數(shù)據(jù)的協(xié)定名稱；
image/png 是數(shù)據(jù)類型名稱；
base64 是數(shù)據(jù)的編碼方法，逗號(hào)后面就是這個(gè)image/png文件base64編碼后的數(shù)據(jù)。
原來(lái)，Data URI scheme支持的類型有不少。
data: 文本數(shù)據(jù) data: text/plain, 文本數(shù)據(jù)
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圖片數(shù)據(jù)
data: image/png;base64, base64編碼的png圖片數(shù)據(jù)
data: image/jpeg;base64, base64編碼的jpeg圖片數(shù)據(jù)
data: image/xicon;base64, base64編碼的icon圖片數(shù)據(jù)這下再也不怕什么路徑問題了，直接就嵌入到頁(yè)面中了。
另外，有些初學(xué)者在uniapp使用傳統(tǒng)img，容易出問題，在uniapp里，使用image來(lái)顯示圖片。
我是@愛玩的安哥，關(guān)注我獲取更多有用知識(shí)
Image 對(duì)象
Image 對(duì)象代表嵌入的圖像。
<img> 標(biāo)簽每出現(xiàn)一次，一個(gè) Image 對(duì)象就會(huì)被創(chuàng)建。
Image 對(duì)象屬性
W3C: W3C 標(biāo)準(zhǔn)。
| 屬性 | 描述 | W3C |
|---|---|---|
| align | 設(shè)置或返回與內(nèi)聯(lián)內(nèi)容的對(duì)齊方式。 | Yes |
| alt | 設(shè)置或返回?zé)o法顯示圖像時(shí)的替代文本。 | Yes |
| border | 設(shè)置或返回圖像周圍的邊框。 | Yes |
| complete | 返回瀏覽器是否已完成對(duì)圖像的加載。 | No |
| height | 設(shè)置或返回圖像的高度。 | Yes |
| hspace | 設(shè)置或返回圖像左側(cè)和右側(cè)的空白。 | Yes |
| longDesc | 設(shè)置或返回指向包含圖像描述的文檔的 URL。 | Yes |
| lowsrc | 設(shè)置或返回指向圖像的低分辨率版本的 URL。 | No |
| name | 設(shè)置或返回圖像的名稱。 | Yes |
| src | 設(shè)置或返回圖像的 URL。 | Yes |
| useMap | 設(shè)置或返回客戶端圖像映射的 usemap 屬性的值。 | Yes |
| vspace | 設(shè)置或返回圖像的頂部和底部的空白。 | Yes |
| width | 設(shè)置或返回圖像的寬度。 | Yes |
Image 對(duì)象事件
| 事件 | 描述 | W3C |
|---|---|---|
| onabort | 當(dāng)用戶放棄圖像的裝載時(shí)調(diào)用的事件句柄。 | Yes |
| onerror | 在裝載圖像的過程中發(fā)生錯(cuò)誤時(shí)調(diào)用的事件句柄。 | Yes |
| onload | 當(dāng)圖像裝載完畢時(shí)調(diào)用的事件句柄。 | Yes |
標(biāo)準(zhǔn)屬性和事件
Image 對(duì)象同樣支持標(biāo)準(zhǔn)的 屬性 和 事件。
如您還有不明白的可以在下面與我留言或是與我探討QQ群308855039，我們一起飛！
言：對(duì)于大多數(shù)前端工程師來(lái)說(shuō)，圖片就是UI設(shè)計(jì)師(或者自己)切好的圖，你要做的只是把圖片丟進(jìn)項(xiàng)目中，然后用以鏈接的方式呈現(xiàn)在頁(yè)面上，而且我們也經(jīng)常把精力放在項(xiàng)目的打包優(yōu)化構(gòu)建上，如何分包，如何抽取第三方庫(kù)……..有時(shí)我們會(huì)忘了，圖片才是一個(gè)網(wǎng)站最大頭的那塊加載資源(見下圖)，雖然圖片加載可以不不阻礙頁(yè)面渲染，但優(yōu)化圖片，絕對(duì)可以讓網(wǎng)站的體驗(yàn)提升一個(gè)檔次。
如果效果真的需要圖片來(lái)表現(xiàn)，那么選擇圖片格式是優(yōu)化的第一步。我們經(jīng)常聽到的詞語(yǔ)包括矢量圖、標(biāo)量圖、SVG、有損壓縮、無(wú)損壓縮等等，我們首先說(shuō)明各種圖片格式的特點(diǎn)
圖片格式壓縮方式透明度動(dòng)畫瀏覽器兼容適應(yīng)場(chǎng)景JPEG有損壓縮不支持不支持所有復(fù)雜顏色及形狀、尤其是照片 漸進(jìn)式吃cpuGIF無(wú)損壓縮支持支持所有簡(jiǎn)單顏色，動(dòng)畫PNG無(wú)損壓縮支持不支持所有需要透明時(shí)，但是體積太大APNG無(wú)損壓縮支持支持FirefoxSafariiOS Safari需要半透明效果的動(dòng)畫WebP有損壓縮支持支持ChromeOperaAndroid ChromeAndroid Browser復(fù)雜顏色及形狀瀏覽器平臺(tái)可預(yù)知SVG無(wú)損壓縮支持支持所有（IE8以上）簡(jiǎn)單圖形，需要良好的放縮體驗(yàn)需要?jiǎng)討B(tài)控制圖片特效
壓縮圖片可以使用統(tǒng)一的壓縮工具 — imagemin，它是一款可以集成多個(gè)壓縮庫(kù)的工具，支持jpg，png，webp等等格式的圖片壓縮，比如pngquant，mozjpeg等等，作為測(cè)試用途，我們可以直接安裝imagemin-pngquant來(lái)嘗試png圖片的壓縮
npm install imagemin
npm install imagemin-pngquant
``
先安裝imagemin庫(kù)，再安裝對(duì)應(yīng)的png壓縮庫(kù)
```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一項(xiàng)決定壓縮比率，65-80貌似是一個(gè)在壓縮率和質(zhì)量之間實(shí)現(xiàn)平衡的數(shù)值
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選項(xiàng)，這可以將圖片轉(zhuǎn)換為漸進(jìn)式圖片，關(guān)于漸進(jìn)式圖片，它允許在加載照片的時(shí)候，如果網(wǎng)速比較慢的話，先顯示一個(gè)類似模糊有點(diǎn)小馬賽克的質(zhì)量比較差的照片，然后慢慢的變?yōu)榍逦恼掌?/p>
漸進(jìn)式圖片 Progressive JPEG
Progressive JPEG文件包含多次掃描，這些掃描順尋的存儲(chǔ)在JPEG文件中。打開文件過程中，會(huì)先顯示整個(gè)圖片的模糊輪廓，隨著掃描次數(shù)的增加，圖片變得越來(lái)越清晰。這種格式的主要優(yōu)點(diǎn)是在網(wǎng)絡(luò)較慢的情況下，可以看到圖片的輪廓知道正在加載的圖片大概是什么。在一些網(wǎng)站打開較大圖片時(shí)，你就會(huì)注意到這種技術(shù)。
非漸進(jìn)式的圖片(Baseline JPEG)
這種類型的JPEG文件存儲(chǔ)方式是按從上到下的掃描方式，把每一行順序的保存在JPEG文件中。打開這個(gè)文件顯示它的內(nèi)容時(shí)，數(shù)據(jù)將按照存儲(chǔ)時(shí)的順序從上到下一行一行的被顯示出來(lái)，直到所有的數(shù)據(jù)都被讀完，就完成了整張圖片的顯示。如果文件較大或者網(wǎng)絡(luò)下載速度較慢，那么就會(huì)看到圖片被一行行加載的效果，這種格式的JPEG沒有什么優(yōu)點(diǎn)，因此，一般都推薦使用Progressive JPEG。
基本JPEG和漸進(jìn)JPEG該什么時(shí)候使用？
當(dāng)您的JPEG圖像低于10K時(shí)，最好保存為基本JPEG（估計(jì)有75％的可能性會(huì)更?。?對(duì)于超過10K的文件，漸進(jìn)式JPEG將為您提供更好的壓縮（在94％的情況下） Chrome + Firefox + IE9瀏覽器下，漸進(jìn)式圖片加載更快，而且是快很多，至于其他瀏覽器，與基本式圖片的加載一致，至少不會(huì)拖后腿。
漸進(jìn)式圖片也有不足，就是吃CPU吃內(nèi)存。
總結(jié)一下兩者的區(qū)別：
漸進(jìn)式j(luò)peg(progressive jpeg)圖片及其相關(guān) 簡(jiǎn)單來(lái)說(shuō)，漸進(jìn)式圖片一開始就決定了大小，而不像Baseline圖片一樣，不斷地從上往下加載，從而造成多次回流，但漸進(jìn)式圖片需要消耗CPU去多次計(jì)算渲染，這是其主要缺點(diǎn)。 當(dāng)然，交錯(cuò)式png也可以實(shí)現(xiàn)相應(yīng)的效果，但目前pngquant沒有實(shí)現(xiàn)轉(zhuǎn)換功能，但是ps中導(dǎo)出png時(shí)是可以設(shè)置為交錯(cuò)式的。
那我們?cè)趺床榭磮D片是漸進(jìn)式還是基本的呢
通過對(duì)比保存的圖片格式（格式在線分析：https://exif.tuchong.com/）
也有一些網(wǎng)上推薦的轉(zhuǎn)化工具
https://www.imgonline.com.ua/eng/compress-image.php
http://www.imagemagick.org/script/download.php
說(shuō)了這么多，是不是感覺很啰嗦,接下來(lái)我們?cè)趯?shí)際項(xiàng)目中如何操作
實(shí)際項(xiàng)目中，總不能UI丟一個(gè)圖過來(lái)你就跑一遍壓縮代碼吧？幸好imagemin有對(duì)應(yīng)的webpack插件，在webpack遍地使用的今天，我們可以輕松實(shí)現(xiàn)批量壓縮：
先安裝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
同時(shí)我們推薦幾種比較好用的圖片壓縮工具
1. docsmall在線圖片壓縮
https://docsmall.com/
國(guó)內(nèi)公司開發(fā)在線圖片壓縮工具
服務(wù)器在國(guó)內(nèi)，上傳速度很快
頁(yè)面簡(jiǎn)潔無(wú)廣告，美觀大方
壓縮率很好，基本能壓縮到原來(lái)的一半以下
壓縮出的圖片畫質(zhì)很清晰，跟原圖幾乎沒有差別
對(duì)png、jpg格式的支持都很好
還有針對(duì)PDF的壓縮功能
2. tinypng
https://tinypng.com/
國(guó)外團(tuán)隊(duì)開發(fā)的在線圖片壓縮網(wǎng)站，有口皆碑
唯一的問題就是上傳速度不夠快，畢竟是國(guó)外的
界面全英文，對(duì)英語(yǔ)不好的朋友來(lái)說(shuō)不夠友好
3. 智圖
https://zhitu.isux.us/
騰訊的一個(gè)團(tuán)隊(duì)出品
可以自定義壓縮比例，如果壓出來(lái)的體積不夠小，你還可以選擇一個(gè)更高的壓縮率
保證圖片體積夠小
圖片按需加載是個(gè)老生常談的話題，傳統(tǒng)做法自然是通過監(jiān)聽頁(yè)面滾動(dòng)位置，符合條件了再去進(jìn)行資源加載，我們看看如今還有什么方法可以做到按需加載。
使用強(qiáng)大的IntersectionObserver IntersectionObserver提供給我們一項(xiàng)能力：可以用來(lái)監(jiān)聽元素是否進(jìn)入了設(shè)備的可視區(qū)域之內(nèi)，這意味著：我們等待圖片元素進(jìn)入可視區(qū)域后，再?zèng)Q定是否加載它，畢竟用戶沒看到圖片前，根本不關(guān)心它是否已經(jīng)加載了。 這是Chrome51率先提出和支持的API，而現(xiàn)在，各大瀏覽器對(duì)它的支持度已經(jīng)有所改善(除了IE，全線崩~) 廢話不多說(shuō)，上代碼： 首先，假設(shè)我們有一個(gè)圖片列表，它們的src屬性我們暫不設(shè)置，而用data-src來(lái)替代：
<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>
這樣會(huì)導(dǎo)致圖片無(wú)法加載，這當(dāng)然不是我們的目的，我們想做的是，當(dāng)IntersectionObserver監(jiān)聽到圖片元素進(jìn)入可視區(qū)域時(shí)，將data-src”還給”src屬性，這樣我們就可以實(shí)現(xiàn)圖片加載了:
const observer=new IntersectionObserver(function(changes) {
changes.forEach(function(element, index) {
// 當(dāng)這個(gè)值大于0，說(shuō)明滿足我們的加載條件了，這個(gè)值可通過rootMargin手動(dòng)設(shè)置
if (element.intersectionRatio > 0) {
// 放棄監(jiān)聽，防止性能浪費(fèi)，并加載圖片。
observer.unobserve(element.target);
element.target.src=element.target.dataset.src;
}
});
});
function initObserver() {
const listItems=document.querySelectorAll('.list-item-img');
listItems.forEach(function(item) {
// 對(duì)每個(gè)list元素進(jìn)行監(jiān)聽
observer.observe(item);
});
}
initObserver();
運(yùn)行代碼并觀察控制臺(tái)的Network，會(huì)發(fā)現(xiàn)圖片隨著可視區(qū)域的移動(dòng)而加載，我們的目的達(dá)到了。
IntersectionObserver
瀏覽器兼容
還是Chrome的黑科技——loading屬性
從新版本Chrome(76)開始，已經(jīng)默認(rèn)支持一種新的html屬性——loading，它包含三種取值:auto、lazy和eager(ps: 之前有文章說(shuō)是lazyload屬性，后來(lái)chrome的工程師已經(jīng)將其確定為loading屬性，原因是lazyload語(yǔ)義不夠明確)，我們看看這三種屬性有什么不同：
這個(gè)現(xiàn)象跟chrome的lazy-loading功能的實(shí)現(xiàn)機(jī)制有關(guān)：
首先，瀏覽器會(huì)發(fā)送一個(gè)預(yù)請(qǐng)求，請(qǐng)求地址就是這張圖片的url，但是這個(gè)請(qǐng)求只拉取這張圖片的頭部數(shù)據(jù)，大約2kb，具體做法是在請(qǐng)求頭中設(shè)置range: bytes=0-2047，
而從這段數(shù)據(jù)中，瀏覽器就可以解析出圖片的寬高等基本維度，接著瀏覽器立馬為它生成一個(gè)空白的占位，以免圖片加載過程中頁(yè)面不斷跳動(dòng)，這很合理，總不能為了一個(gè)懶加載，讓用戶犧牲其他方面的體驗(yàn)吧？這個(gè)請(qǐng)求返回的狀態(tài)碼是206，表明：客戶端通過發(fā)送范圍請(qǐng)求頭Range抓取到了資源的部分?jǐn)?shù)據(jù)，詳細(xì)的狀態(tài)碼解釋可以看看這篇文章
然后，在用戶滾動(dòng)到圖片附近時(shí)，再發(fā)起一個(gè)請(qǐng)求，完整地拉取圖片的數(shù)據(jù)下來(lái)，這個(gè)才是我們熟悉的狀態(tài)碼200請(qǐng)求。
可以預(yù)測(cè)到，如果以后這個(gè)屬性被普遍使用，那一個(gè)服務(wù)器要處理的圖片請(qǐng)求連接數(shù)可能會(huì)變成兩倍，對(duì)服務(wù)器的壓力會(huì)有所增大，但時(shí)代在進(jìn)步，我們可以依靠http2多路復(fù)用的特性來(lái)緩解這個(gè)壓力，這時(shí)候就需要技術(shù)負(fù)責(zé)人權(quán)衡利弊了
要注意，使用這項(xiàng)特性進(jìn)行圖片懶加載時(shí)，記得先進(jìn)行兼容性處理，對(duì)不支持這項(xiàng)屬性的瀏覽器，轉(zhuǎn)而使用JavaScript來(lái)實(shí)現(xiàn)，比如上面說(shuō)到的IntersectionObserver：
if ("loading" in HTMLImageElement.prototype) {
// 支持loading
} else {
// .....
}
當(dāng)網(wǎng)速慢的時(shí)候，圖片還沒加載完之前，用戶會(huì)看到一段空白的時(shí)間，在這段空白時(shí)間，就算是漸進(jìn)式圖片也無(wú)法發(fā)揮它的作用，我們需要更友好的展示方式來(lái)彌補(bǔ)這段空白，有一種方法簡(jiǎn)單粗暴，那就是用一張占位圖來(lái)頂替，這張占位圖被加載過一次后，即可從緩存中取出，無(wú)須重新加載，但這種圖片會(huì)顯得有些千篇一律，并不能很好地做到preview的效果。
這里介紹另一種占位圖做法——css漸變色背景，原理很簡(jiǎn)單，當(dāng)img標(biāo)簽的圖片還沒加載出來(lái)，我們可以為其設(shè)置背景色，比如:
<img src="a.jpg" style="background: red;"/>
這樣會(huì)先顯示出紅色背景，再渲染出真實(shí)的圖片，重點(diǎn)來(lái)了，我們此時(shí)要借用工具為這張圖片"配制"出合適的漸變背景色，以達(dá)到部分preview的效果，我們可以使用 https://calendar.perfplanet.com/2018/gradient-image-placeholders/ 這篇文章中推薦的工具GIP進(jìn)行轉(zhuǎn)換 ，這里附上在線轉(zhuǎn)換的地址 https://tools.w3clubs.com/gip/
經(jīng)過轉(zhuǎn)換后，我們得到了下面這串代碼：
background: linear-gradient(
to bottom,
#1896f5 0%,
#2e6d14 100%
)
我們經(jīng)常會(huì)遇到這種情況：一張?jiān)谄胀üP記本上顯示清晰的圖片，到了蘋果的Retina屏幕或是其他高清晰度的屏幕上，就變得模糊了。
這是因?yàn)?，在同樣尺寸的屏幕上，高清屏可以展示的物理像素點(diǎn)比普通屏多，比如Retina屏，同樣的屏幕尺寸下，它的物理像素點(diǎn)的個(gè)數(shù)是普通屏的4倍(2 * 2)，所以普通屏上顯示清晰的圖片，在高清屏上就像是被放大了，自然就變得模糊了，要從圖片資源上解決這個(gè)問題，就需要在設(shè)備像素密度為2的高清屏中，對(duì)應(yīng)地展示一張兩倍大小的圖。
而通常來(lái)講，對(duì)于背景圖片，我們可以使用css的@media進(jìn)行媒體查詢，以決定不同像素密度下該用哪張倍圖，例如：
.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的圖
}
}
這么做有兩個(gè)好處，一是保證高像素密度的設(shè)備下，圖片仍能保持應(yīng)有的清晰度，二是防止在低像素密度的設(shè)備下加載大尺寸圖片造成浪費(fèi)。
那么如何處理img標(biāo)簽?zāi)兀?/p>
我們可以使用HTML5中img標(biāo)簽的srcset來(lái)達(dá)到這個(gè)效果，看看下面這段代碼：
<img width="320" src="bg@2x.png" srcset="bg.png 1x;bg@2x.png 2x"/>
這段代碼的作用是：當(dāng)設(shè)備像素密度，也就是dpr(devicePixelRatio)為1時(shí)，使用bg.png，為2時(shí)使用二倍圖bg@2x.png，依此類推，你可以根據(jù)需要設(shè)置多種精度下要加載的圖片，如果沒有命中，瀏覽器會(huì)選擇最鄰近的一個(gè)精度對(duì)應(yīng)的圖片進(jìn)行加載。 要注意：老舊的瀏覽器不支持srcset的特性，它會(huì)繼續(xù)正常加載src屬性引用的圖像。
要同時(shí)適配不同像素密度、不同大小的屏幕，應(yīng)該怎么辦呢？
<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>
就要用到標(biāo)簽。它是一個(gè)容器標(biāo)簽，內(nèi)部使用和，指定不同情況下加載的圖像。
上面代碼中，標(biāo)簽內(nèi)部有兩個(gè)標(biāo)簽和一個(gè)標(biāo)簽。
標(biāo)簽的media屬性給出媒體查詢表達(dá)式，srcset屬性就是標(biāo)簽的srcset屬性，給出加載的圖像文件。sizes屬性其實(shí)這里也可以用，但由于有了media屬性，就沒有必要了。
瀏覽器按照標(biāo)簽出現(xiàn)的順序，依次判斷當(dāng)前設(shè)備是否滿足media屬性的媒體查詢表達(dá)式，如果滿足就加載srcset屬性指定的圖片文件，并且不再執(zhí)行后面的標(biāo)簽和標(biāo)簽。
標(biāo)簽是默認(rèn)情況下加載的圖像，用來(lái)滿足上面所有都不匹配的情況。
上面例子中，設(shè)備寬度如果不超過500px，就加載豎屏的圖像，否則加載橫屏的圖像。
除了響應(yīng)式圖像，標(biāo)簽還可以用來(lái)選擇不同格式的圖像。比如，如果當(dāng)前瀏覽器支持 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>
上面代碼中，標(biāo)簽的type屬性給出圖像的 MIME 類型，srcset是對(duì)應(yīng)的圖像 URL。
瀏覽器按照標(biāo)簽出現(xiàn)的順序，依次檢查是否支持type屬性指定的圖像格式，如果支持就加載圖像，并且不再檢查后面的標(biāo)簽了。上面例子中，圖像加載優(yōu)先順序依次為 svg 格式、webp 格式和 png 格式。
使用CDN對(duì)圖片自動(dòng)進(jìn)行優(yōu)化，我在國(guó)外的CDN提供商處很少見到這類服務(wù)，倒是國(guó)內(nèi)的兩大新秀CDN七牛和又拍在這方面都做了大量工作。其工作方式為，向CDN請(qǐng)求圖片的URL參數(shù)中包含了圖片處理的參數(shù)（格式、寬高等），CDN服務(wù)器根據(jù)請(qǐng)求生成所需的圖片，發(fā)送到用戶瀏覽器。
七牛云存儲(chǔ)的圖片處理接口極其豐富，覆蓋了圖片的大部分基本操作，例如：
圖片裁剪，支持多種裁剪方式（如按長(zhǎng)邊、短邊、填充、拉伸等） 圖片格式轉(zhuǎn)換，支持JPG, GIF, PNG, WebP等，支持不同的圖片壓縮率 圖片處理，支持圖片水印、高斯模糊、重心處理等
當(dāng)然其他cdn對(duì)于圖像處理也有很豐富的處理，相關(guān)文檔里也介紹很詳細(xì)，可以參考cdn文檔
阿里云
騰訊
我們通過如下URL請(qǐng)求，裁剪正中部分，等比縮小生成200x200縮略圖：
http://qiniuphotos.qiniudn.com/gogopher.jpg?imageView2/1/w/200/h/200
七牛cdn
首先復(fù)習(xí)一下Base64的概念，Base64就是一種基于64個(gè)可打印字符來(lái)表示二進(jìn)制數(shù)據(jù)的方法，編碼過程是從二進(jìn)制數(shù)據(jù)到字符串的過程，在web應(yīng)用中我們經(jīng)常用它來(lái)做啥呢——傳輸圖片數(shù)據(jù)。HTML中，img的src和css樣式的background-image都可以接受base64字符串，從而在頁(yè)面上渲染出對(duì)應(yīng)的圖片。正是基于瀏覽器的這項(xiàng)能力，很多開發(fā)者提出了將多張圖片轉(zhuǎn)換為base64字符串，放進(jìn)css樣式文件中的“優(yōu)化方式”，這樣做的目的只有一個(gè)——減少HTTP請(qǐng)求數(shù)。但實(shí)際上，在如今的應(yīng)用開發(fā)中，這種做法大多數(shù)情況是“負(fù)優(yōu)化”效果，接下來(lái)讓我們細(xì)數(shù)base64 Url的“罪狀”：
當(dāng)你把圖片轉(zhuǎn)換為base64字符串之后，字符串的體積一般會(huì)比原圖更大，一般會(huì)多出接近3成的大小，如果你一個(gè)頁(yè)面中有20張平均大小為50kb的圖片，轉(zhuǎn)它們?yōu)閎ase64后，你的css文件將可能增大1.2mb的大小，這樣將嚴(yán)重阻礙瀏覽器的關(guān)鍵渲染路徑：
css文件本身就是渲染阻塞資源，瀏覽器首次加載時(shí)如果沒有全部下載和解析完css內(nèi)容就無(wú)法進(jìn)行渲染樹的構(gòu)建，而base64的嵌入則是雪上加霜，這將把原先瀏覽器可以進(jìn)行優(yōu)化的圖片異步加載，變成首屏渲染的阻塞和延遲。
或許有人會(huì)說(shuō)，webpack的url-loader可以根據(jù)圖片大小決定是否轉(zhuǎn)為base64(一般是小于10kb的圖片)，但你也應(yīng)該擔(dān)心如果頁(yè)面中有100張小于10kb的圖片時(shí)，會(huì)給css文件增加多少體積。
假設(shè)你的base64Url會(huì)被你的應(yīng)用多次復(fù)用，本來(lái)瀏覽器可以直接從本地緩存取出的圖片，換成base64Url，將造成應(yīng)用中多個(gè)頁(yè)面重復(fù)下載1.3倍大小的文本，假設(shè)一張圖片是100kb大小，被你的應(yīng)用使用了10次，那么造成的流量浪費(fèi)將是:(100 1.3 10) - 100=1200kb。
這是比較次要的問題，dataurl在低版本IE瀏覽器，比如IE8及以下的瀏覽器，會(huì)有兼容性問題，詳細(xì)情況可以參考這篇文章。
無(wú)論哪張圖片，看上去都是一堆沒有意義的字符串，光看代碼無(wú)法知道原圖是哪張，不利于某些情況下的比對(duì)。 說(shuō)了這么多 既然這種方案缺點(diǎn)這么多，為啥它會(huì)從以前就被廣泛使用呢？這要從早期的http協(xié)議特性說(shuō)起，在http1.1之前，http協(xié)議尚未實(shí)現(xiàn)keep-alive，也就是每一次請(qǐng)求，都必須走三次握手四次揮手去建立連接，連接完又丟棄無(wú)法復(fù)用，而即使是到了http1.1的時(shí)代，keep-alive可以保證tcp的長(zhǎng)連接，不需要多次重新建立，但由于http1.1是基于文本分割的協(xié)議，所以消息是串行的，必須有序地逐個(gè)解析，所以在這種請(qǐng)求“昂貴”，且早期圖片體積并不是特別大，用戶對(duì)網(wǎng)頁(yè)的響應(yīng)速度和體驗(yàn)要求也不是很高的各種前提結(jié)合下，減少圖片資源的請(qǐng)求數(shù)是可以理解的。
但是，在越來(lái)越多網(wǎng)站支持http2.0的前提下，這些都不是問題，h2是基于二進(jìn)制幀的協(xié)議，在保留http1.1長(zhǎng)連接的前提下，實(shí)現(xiàn)了消息的并行處理，請(qǐng)求和響應(yīng)可以交錯(cuò)甚至可以復(fù)用，多個(gè)并行請(qǐng)求的開銷已經(jīng)大大降低，我已經(jīng)不知道還有什么理由繼續(xù)堅(jiān)持base64Url的使用了。
圖片優(yōu)化的手段總是隨著瀏覽器特性的升級(jí)，網(wǎng)絡(luò)傳輸協(xié)議的升級(jí)，以及用戶對(duì)體驗(yàn)要求的提升而不停地更新迭代，幾年前適用的或顯著的優(yōu)化手段，幾年后不一定仍然如此。因地制宜，多管齊下，才能將其優(yōu)化做到極致！
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
