整合營(yíng)銷(xiāo)服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
視頻分割軟件哪個(gè)好？
1、視頻編輯大師
視頻編輯大師是一款專(zhuān)業(yè)的視頻編輯軟件，包含視頻合并專(zhuān)家、AVI MPEG視頻合并專(zhuān)家、視頻分割專(zhuān)家、視頻截取專(zhuān)家、RMVB視頻合并專(zhuān)家的所有功能，是視頻愛(ài)好者必備的工具。
2、視頻剪切合并器
軟件名稱(chēng)：
視頻剪切合并器是一款目前剪切視頻速度最快、支持無(wú)損切割視頻、最好用的免費(fèi)視頻剪切合并工具。剪切一個(gè)100MB大小的視頻文件只需要10秒左右時(shí)間，是目前最快的視頻剪切工具。它可以對(duì)AVI、MP4、 FLV、 MOV、 RMVB、3GP、WMV等視頻格式進(jìn)行任意時(shí)間段的剪切，還支持多個(gè)視頻文件的合并。頻剪切合并器操作非常簡(jiǎn)單，只需要將你的視頻文件用視頻剪切合并器打開(kāi)，選擇好你想剪切的視頻起始位置和結(jié)束位置，點(diǎn)擊開(kāi)始剪切按鈕，立刻搞定！支持無(wú)損剪切AVI、 MP4、 FLV、 MOV、RMVB、3GP、WMV等各種視頻格式，剪切后視頻清晰度，畫(huà)面大小等不變。視頻合并支持任意的不同視頻格式之間的合并，比如你可以把FLV格式和MP4格式的視頻合并在一起，功能非常強(qiáng)大。
會(huì)聲會(huì)影(Ulead Video Studio)10是一套功能強(qiáng)大、有趣好用的個(gè)人家庭影片剪輯軟件。通過(guò)它完整強(qiáng)大的編輯模式您可以剪輯出個(gè)人風(fēng)格，點(diǎn)綴個(gè)人影片。和會(huì)聲會(huì)影8比較，會(huì)聲會(huì)影10速度提升了很大，轉(zhuǎn)換和輸入輸出視頻簡(jiǎn)直是得心應(yīng)手！支持更多的格式，采集、編輯、加字幕、輸出、刻盤(pán)...那是相當(dāng)?shù)暮糜冒 ?/p>
4、易杰視頻分割器
易杰視頻分割器是一款功能強(qiáng)大的視頻分割工具，它可以幫助您將幾乎所有的視頻格式，如：RM、RMVB、VOB、DAT、VCD、SVCD、ASF、MOV、QT、MPEG、MPG、WMV、MP4、3GP、M4V、AVI、FLV、MKV、MOD、TOD、MTS、M2TS、TS、F4V、DV等視頻格式按照您設(shè)置的時(shí)間分割成小的視頻文件，可以輸出FLV、AVI、VCD、SVCD、DVD、WMV等多種視頻格式，支持多個(gè)視頻文件批量分割。軟件具有分割簡(jiǎn)單、快速、高畫(huà)質(zhì)等特點(diǎn)，還可以支持分割完成后自動(dòng)關(guān)機(jī)。
接：https://juejin.im/book/5b936540f265da0a9624b04b
《高性能網(wǎng)站建設(shè)指南》的作者 Steve Souders 曾在一篇博客中提到：
我的大部分性能優(yōu)化工作都集中在 JavaScript 和 CSS 上，從早期的 Move Scripts to the Bottom 和 Put Stylesheets at the Top 規(guī)則。為了強(qiáng)調(diào)這些規(guī)則的重要性，我甚至說(shuō)過(guò)，“JS 和 CSS 是頁(yè)面上最重要的部分”。
幾個(gè)月后，我意識(shí)到這是錯(cuò)誤的。圖片才是頁(yè)面上最重要的部分。
我關(guān)注 JS 和 CSS 的重點(diǎn)也是如何能夠更快地下載圖片。圖片是用戶可以直觀看到的。他們并不會(huì)關(guān)注 JS 和 CSS。確實(shí)，JS 和 CSS 會(huì)影響圖片內(nèi)容的展示，尤其是會(huì)影響圖片的展示方式（比如圖片輪播，CSS 背景圖和媒體查詢）。但是我認(rèn)為 JS 和 CSS 只是展示圖片的方式。在頁(yè)面加載的過(guò)程中，應(yīng)當(dāng)先讓圖片和文字先展示，而不是試圖保證 JS 和 CSS 更快下載完成。
這段話可謂字字珠璣。此外，雅虎軍規(guī)和 Google 官方的最佳實(shí)踐也都將圖片優(yōu)化列為前端性能優(yōu)化必不可少的環(huán)節(jié)——圖片優(yōu)化的優(yōu)先級(jí)可見(jiàn)一斑。
就圖片這塊來(lái)說(shuō)，與其說(shuō)我們是在做“優(yōu)化”，不如說(shuō)我們是在做“權(quán)衡”。因?yàn)槲覀円龅氖虑?，就是去壓縮圖片的體積（或者一開(kāi)始就選取體積較小的圖片格式）。但這個(gè)優(yōu)化操作，是以犧牲一部分成像質(zhì)量為代價(jià)的。因此我們的主要任務(wù)，是盡可能地去尋求一個(gè)質(zhì)量與性能之間的平衡點(diǎn)。
2019 年，圖片依然很大
這里先給大家介紹 HTTP-Archive 這個(gè)網(wǎng)站，它會(huì)定期抓取 Web 上的站點(diǎn)，并記錄資源的加載情況、Web API 的使用情況等頁(yè)面的詳細(xì)信息，并會(huì)對(duì)這些數(shù)據(jù)進(jìn)行處理和分析以確定趨勢(shì)。通過(guò)它我們可以實(shí)時(shí)地看到世界范圍內(nèi)的 Web 資源的統(tǒng)計(jì)結(jié)果。
截止到 2018 年 8 月，過(guò)去一年總的 web 資源的平均請(qǐng)求體積是這樣的：
而具體到圖片這一類(lèi)的資源，平均請(qǐng)求體積是這樣的：
當(dāng)然，隨著我們工程師在性能方面所做的努力越來(lái)越有成效，平均來(lái)說(shuō)，不管是資源總量還是圖片體積，都在往越來(lái)越輕量的方向演化。這是一種值得肯定的進(jìn)步。
但同時(shí)我們不得不承認(rèn)，如圖所示的這個(gè)圖片體積，依然是太大了。圖片在所有資源中所占的比重，也足夠“觸目驚心”了。為了改變這個(gè)現(xiàn)狀，我們必須把圖片優(yōu)化提上日程。
時(shí)下應(yīng)用較為廣泛的 Web 圖片格式有 JPEG/JPG、PNG、WebP、Base64、SVG 等，這些格式都是很有故事的，值得我們好好研究一把。此外，老生常談的雪碧圖（CSS Sprites）至今也仍在一線的前端應(yīng)用中發(fā)光發(fā)熱，我們也會(huì)有所提及。
不談業(yè)務(wù)場(chǎng)景的選型都是耍流氓。下面我們就結(jié)合具體的業(yè)務(wù)場(chǎng)景，一起來(lái)解開(kāi)圖片選型的神秘面紗！
在計(jì)算機(jī)中，像素用二進(jìn)制數(shù)來(lái)表示。不同的圖片格式中像素與二進(jìn)制位數(shù)之間的對(duì)應(yīng)關(guān)系是不同的。一個(gè)像素對(duì)應(yīng)的二進(jìn)制位數(shù)越多，它可以表示的顏色種類(lèi)就越多，成像效果也就越細(xì)膩，文件體積相應(yīng)也會(huì)越大。
一個(gè)二進(jìn)制位表示兩種顏色（0|1 對(duì)應(yīng)黑|白），如果一種圖片格式對(duì)應(yīng)的二進(jìn)制位數(shù)有 n 個(gè)，那么它就可以呈現(xiàn) 2^n 種顏色。
關(guān)鍵字：有損壓縮、體積小、加載快、不支持透明
JPG 的優(yōu)點(diǎn)
JPG 最大的特點(diǎn)是有損壓縮。這種高效的壓縮算法使它成為了一種非常輕巧的圖片格式。另一方面，即使被稱(chēng)為“有損”壓縮，JPG的壓縮方式仍然是一種高質(zhì)量的壓縮方式：當(dāng)我們把圖片體積壓縮至原有體積的 50% 以下時(shí)，JPG 仍然可以保持住 60% 的品質(zhì)。此外，JPG 格式以 24 位存儲(chǔ)單個(gè)圖，可以呈現(xiàn)多達(dá) 1600 萬(wàn)種顏色，足以應(yīng)對(duì)大多數(shù)場(chǎng)景下對(duì)色彩的要求，這一點(diǎn)決定了它壓縮前后的質(zhì)量損耗并不容易被我們?nèi)祟?lèi)的肉眼所察覺(jué)——前提是你用對(duì)了業(yè)務(wù)場(chǎng)景。
使用場(chǎng)景
JPG 適用于呈現(xiàn)色彩豐富的圖片，在我們?nèi)粘ｉ_(kāi)發(fā)中，JPG 圖片經(jīng)常作為大的背景圖、輪播圖或 Banner 圖出現(xiàn)。
兩大電商網(wǎng)站對(duì)大圖的處理，是 JPG 圖片應(yīng)用場(chǎng)景的最佳寫(xiě)照：
打開(kāi)淘寶首頁(yè)，我們可以發(fā)現(xiàn)頁(yè)面中最醒目、最龐大的圖片，一定是以 .jpg 為后綴的：
京東首頁(yè)也不例外：
使用 JPG 呈現(xiàn)大圖，既可以保住圖片的質(zhì)量，又不會(huì)帶來(lái)令人頭疼的圖片體積，是當(dāng)下比較推崇的一種方案。
JPG 的缺陷
有損壓縮在上文所展示的輪播圖上確實(shí)很難露出馬腳，但當(dāng)它處理矢量圖形和 Logo 等線條感較強(qiáng)、顏色對(duì)比強(qiáng)烈的圖像時(shí)，人為壓縮導(dǎo)致的圖片模糊會(huì)相當(dāng)明顯。
此外，JPEG 圖像不支持透明度處理，透明圖片需要召喚 PNG 來(lái)呈現(xiàn)。
關(guān)鍵字：無(wú)損壓縮、質(zhì)量高、體積大、支持透明
PNG 的優(yōu)點(diǎn)
PNG（可移植網(wǎng)絡(luò)圖形格式）是一種無(wú)損壓縮的高保真的圖片格式。8 和 24，這里都是二進(jìn)制數(shù)的位數(shù)。按照我們前置知識(shí)里提到的對(duì)應(yīng)關(guān)系，8 位的 PNG 最多支持 256 種顏色，而 24 位的可以呈現(xiàn)約 1600 萬(wàn)種顏色。
PNG 圖片具有比 JPG 更強(qiáng)的色彩表現(xiàn)力，對(duì)線條的處理更加細(xì)膩，對(duì)透明度有良好的支持。它彌補(bǔ)了上文我們提到的 JPG 的局限性，唯一的 BUG 就是體積太大。
PNG-8 與 PNG-24 的選擇題
什么時(shí)候用 PNG-8，什么時(shí)候用 PNG-24，這是一個(gè)問(wèn)題。
理論上來(lái)說(shuō)，當(dāng)你追求最佳的顯示效果、并且不在意文件體積大小時(shí)，是推薦使用 PNG-24 的。
但實(shí)踐當(dāng)中，為了規(guī)避體積的問(wèn)題，我們一般不用PNG去處理較復(fù)雜的圖像。當(dāng)我們遇到適合 PNG 的場(chǎng)景時(shí)，也會(huì)優(yōu)先選擇更為小巧的 PNG-8。
如何確定一張圖片是該用 PNG-8 還是 PNG-24 去呈現(xiàn)呢？好的做法是把圖片先按照這兩種格式分別輸出，看 PNG-8 輸出的結(jié)果是否會(huì)帶來(lái)肉眼可見(jiàn)的質(zhì)量損耗，并且確認(rèn)這種損耗是否在我們（尤其是你的 UI 設(shè)計(jì)師）可接受的范圍內(nèi)，基于對(duì)比的結(jié)果去做判斷。
應(yīng)用場(chǎng)景
前面我們提到，復(fù)雜的、色彩層次豐富的圖片，用 PNG 來(lái)處理的話，成本會(huì)比較高，我們一般會(huì)交給 JPG 去存儲(chǔ)。
考慮到 PNG 在處理線條和顏色對(duì)比度方面的優(yōu)勢(shì)，我們主要用它來(lái)呈現(xiàn)小的 Logo、顏色簡(jiǎn)單且對(duì)比強(qiáng)烈的圖片或背景等。
此時(shí)我們?cè)俅伟涯抗廪D(zhuǎn)向性能方面堪稱(chēng)業(yè)界楷模的淘寶首頁(yè)，我們會(huì)發(fā)現(xiàn)它頁(yè)面上的 Logo，無(wú)論大小，還真的都是 PNG 格式：
主 Logo：
較小的 Logo：
顏色簡(jiǎn)單、對(duì)比度較強(qiáng)的透明小圖也在 PNG 格式下有著良好的表現(xiàn)：
關(guān)鍵字：文本文件、體積小、不失真、兼容性好
SVG（可縮放矢量圖形）是一種基于 XML 語(yǔ)法的圖像格式。它和本文提及的其它圖片種類(lèi)有著本質(zhì)的不同：SVG 對(duì)圖像的處理不是基于像素點(diǎn)，而是是基于對(duì)圖像的形狀描述。
SVG 的特性
和性能關(guān)系最密切的一點(diǎn)就是：SVG 與 PNG 和 JPG 相比，文件體積更小，可壓縮性更強(qiáng)。
當(dāng)然，作為矢量圖，它最顯著的優(yōu)勢(shì)還是在于圖片可無(wú)限放大而不失真這一點(diǎn)上。這使得 SVG 即使是被放到視網(wǎng)膜屏幕上，也可以一如既往地展現(xiàn)出較好的成像品質(zhì)——1 張 SVG 足以適配 n 種分辨率。
此外，SVG 是文本文件。我們既可以像寫(xiě)代碼一樣定義 SVG，把它寫(xiě)在 HTML 里、成為 DOM 的一部分，也可以把對(duì)圖形的描述寫(xiě)入以 .svg 為后綴的獨(dú)立文件（SVG 文件在使用上與普通圖片文件無(wú)異）。這使得 SVG 文件可以被非常多的工具讀取和修改，具有較強(qiáng)的靈活性。
SVG 的局限性主要有兩個(gè)方面，一方面是它的渲染成本比較高，這點(diǎn)對(duì)性能來(lái)說(shuō)是很不利的。另一方面，SVG 存在著其它圖片格式所沒(méi)有的學(xué)習(xí)成本（它是可編程的）。
SVG 的使用方式與應(yīng)用場(chǎng)景
SVG 是文本文件，我們既可以像寫(xiě)代碼一樣定義 SVG，把它寫(xiě)在 HTML 里、成為 DOM 的一部分，也可以把對(duì)圖形的描述寫(xiě)入以 .svg 為后綴的獨(dú)立文件（SVG 文件在使用上與普通圖片文件無(wú)異）。
將 SVG 寫(xiě)入 HTML：
將 SVG 寫(xiě)入獨(dú)立文件后引入 HTML:
<img src="文件名.svg" alt="">
在實(shí)際開(kāi)發(fā)中，我們更多用到的是后者。很多情況下設(shè)計(jì)師會(huì)給到我們 SVG 文件，就算沒(méi)有設(shè)計(jì)師，我們還有非常好用的 在線矢量圖形庫(kù)。對(duì)于矢量圖，我們無(wú)須深究過(guò)多，只需要對(duì)其核心特性有所掌握、日后在應(yīng)用時(shí)做到有跡可循即可。
關(guān)鍵字：文本文件、依賴編碼、小圖標(biāo)解決方案
Base64 并非一種圖片格式，而是一種編碼方式。Base64 和雪碧圖一樣，是作為小圖標(biāo)解決方案而存在的。在了解 Base64 之前，我們先來(lái)了解一下雪碧圖。
前置知識(shí)：最經(jīng)典的小圖標(biāo)解決方案——雪碧圖（CSS Sprites）
雪碧圖、CSS 精靈、CSS Sprites、圖像精靈，說(shuō)的都是這個(gè)東西——一種將小圖標(biāo)和背景圖像合并到一張圖片上，然后利用 CSS 的背景定位來(lái)顯示其中的每一部分的技術(shù)。
MDN 對(duì)雪碧圖的解釋已經(jīng)非常到位：
圖像精靈（sprite，意為精靈），被運(yùn)用于眾多使用大量小圖標(biāo)的網(wǎng)頁(yè)應(yīng)用之上。它可取圖像的一部分來(lái)使用，使得使用一個(gè)圖像文件替代多個(gè)小文件成為可能。相較于一個(gè)小圖標(biāo)一個(gè)圖像文件，單獨(dú)一張圖片所需的 HTTP 請(qǐng)求更少，對(duì)內(nèi)存和帶寬更加友好。
我們幾乎可以在每一個(gè)有小圖標(biāo)出現(xiàn)的網(wǎng)站里找到雪碧圖的影子（下圖截取自京東首頁(yè)）：
和雪碧圖一樣，Base64 圖片的出現(xiàn)，也是為了減少加載網(wǎng)頁(yè)圖片時(shí)對(duì)服務(wù)器的請(qǐng)求次數(shù)，從而提升網(wǎng)頁(yè)性能。Base64 是作為雪碧圖的補(bǔ)充而存在的。
理解 Base64
通過(guò)我們上文的演示，大家不難看出，每次加載圖片，都是需要單獨(dú)向服務(wù)器請(qǐng)求這個(gè)圖片對(duì)應(yīng)的資源的——這也就意味著一次 HTTP 請(qǐng)求的開(kāi)銷(xiāo)。
Base64 是一種用于傳輸 8Bit 字節(jié)碼的編碼方式，通過(guò)對(duì)圖片進(jìn)行 Base64 編碼，我們可以直接將編碼結(jié)果寫(xiě)入 HTML 或者寫(xiě)入 CSS，從而減少 HTTP 請(qǐng)求的次數(shù)。
我們來(lái)一起看一個(gè)實(shí)例，現(xiàn)在我有這么一個(gè)小小的放大鏡 Logo：
它對(duì)應(yīng)的鏈接如下：
https://user-gold-cdn.xitu.io/2018/9/15/165db7e94699824b?w=22&h=22&f=png&s=3680
按照一貫的思路，我們加載圖片需要把圖片鏈接寫(xiě)入 img 標(biāo)簽：
<img src="https://user-gold-cdn.xitu.io/2018/9/15/165db7e94699824b?w=22&h=22&f=png&s=3680">
瀏覽器就會(huì)針對(duì)我們的圖片鏈接去發(fā)起一個(gè)資源請(qǐng)求。
但是如果我們對(duì)這個(gè)圖片進(jìn)行 Base64 編碼，我們會(huì)得到一個(gè)很長(zhǎng)很長(zhǎng)的字符串，我們可以直接用這個(gè)字符串替換掉上文中的鏈接地址。你會(huì)發(fā)現(xiàn)瀏覽器原來(lái)是可以理解這個(gè)字符串的，它自動(dòng)就將這個(gè)字符串解碼為了一個(gè)圖片，而不需再去發(fā)送 HTTP 請(qǐng)求。
Base64 的應(yīng)用場(chǎng)景
上面這個(gè)實(shí)例，其實(shí)源自我們 掘金 網(wǎng)站 Header 部分的搜索欄 Logo：
既然 Base64 這么棒，我們何不把大圖也換成 Base64 呢？
這是因?yàn)?，Base64 編碼后，圖片大小會(huì)膨脹為原文件的 4/3（這是由 Base64 的編碼原理決定的）。如果我們把大圖也編碼到 HTML 或 CSS 文件中，后者的體積會(huì)明顯增加，即便我們減少了 HTTP 請(qǐng)求，也無(wú)法彌補(bǔ)這龐大的體積帶來(lái)的性能開(kāi)銷(xiāo)，得不償失。
在傳輸非常小的圖片的時(shí)候，Base64 帶來(lái)的文件體積膨脹、以及瀏覽器解析 Base64 的時(shí)間開(kāi)銷(xiāo)，與它節(jié)省掉的 HTTP 請(qǐng)求開(kāi)銷(xiāo)相比，可以忽略不計(jì)，這時(shí)候才能真正體現(xiàn)出它在性能方面的優(yōu)勢(shì)。
因此，Base64 并非萬(wàn)全之策，我們往往在一張圖片滿足以下條件時(shí)會(huì)對(duì)它應(yīng)用 Base64 編碼：
Base64 編碼工具推薦
這里最推薦的是利用 webpack 來(lái)進(jìn)行 Base64 的編碼——webpack 的 url-loader 非常聰明，它除了具備基本的 Base64 轉(zhuǎn)碼能力，還可以結(jié)合文件大小，幫我們判斷圖片是否有必要進(jìn)行 Base64 編碼。
除此之外，市面上免費(fèi)的 Base64 編解碼工具種類(lèi)是非常多樣化的，有很多網(wǎng)站都提供在線編解碼的服務(wù)，大家選取自己認(rèn)為順手的工具就好。
關(guān)鍵字：年輕的全能型選手
WebP 是今天在座各類(lèi)圖片格式中最年輕的一位，它于 2010 年被提出， 是 Google 專(zhuān)為 Web 開(kāi)發(fā)的一種旨在加快圖片加載速度的圖片格式，它支持有損壓縮和無(wú)損壓縮。
WebP 的優(yōu)點(diǎn)
WebP 像 JPEG 一樣對(duì)細(xì)節(jié)豐富的圖片信手拈來(lái)，像 PNG 一樣支持透明，像 GIF 一樣可以顯示動(dòng)態(tài)圖片——它集多種圖片文件格式的優(yōu)點(diǎn)于一身。
WebP 的官方介紹對(duì)這一點(diǎn)有著更權(quán)威的闡述：
與 PNG 相比，WebP 無(wú)損圖像的尺寸縮小了 26％。在等效的 SSIM 質(zhì)量指數(shù)下，WebP 有損圖像比同類(lèi) JPEG 圖像小 25-34％。 無(wú)損 WebP 支持透明度（也稱(chēng)為 alpha 通道），僅需 22％ 的額外字節(jié)。對(duì)于有損 RGB 壓縮可接受的情況，有損 WebP 也支持透明度，與 PNG 相比，通常提供 3 倍的文件大小。
我們開(kāi)篇提到，圖片優(yōu)化是質(zhì)量與性能的博弈，從這個(gè)角度看，WebP 無(wú)疑是真正的贏家。
WebP 的局限性
WebP 縱有千般好，但它畢竟太年輕。我們知道，任何新生事物，都逃不開(kāi)兼容性的大坑。現(xiàn)在是 2018 年 9 月，WebP 的支持情況是這樣的：
坦白地說(shuō)，雖然沒(méi)有特別慘（畢竟還有親爹 Chrome 在撐腰），但也足夠讓人望而卻步了。
此外，WebP 還會(huì)增加服務(wù)器的負(fù)擔(dān)——和編碼 JPG 文件相比，編碼同樣質(zhì)量的 WebP 文件會(huì)占用更多的計(jì)算資源。
WebP 的應(yīng)用場(chǎng)景
現(xiàn)在限制我們使用 WebP 的最大問(wèn)題不是“這個(gè)圖片是否適合用 WebP 呈現(xiàn)”的問(wèn)題，而是“瀏覽器是否允許 WebP”的問(wèn)題，即我們上文談到的兼容性問(wèn)題。具體來(lái)說(shuō)，一旦我們選擇了 WebP，就要考慮在 Safari 等瀏覽器下它無(wú)法顯示的問(wèn)題，也就是說(shuō)我們需要準(zhǔn)備 PlanB，準(zhǔn)備降級(jí)方案。
目前真正把 WebP 格式落地到網(wǎng)頁(yè)中的網(wǎng)站并不是很多，這其中淘寶首頁(yè)對(duì) WebP 兼容性問(wèn)題的處理方式就非常有趣。我們可以打開(kāi) Chrome 的開(kāi)發(fā)者工具搜索其源碼里的 WebP 關(guān)鍵字：
我們會(huì)發(fā)現(xiàn)檢索結(jié)果還是挺多的（單就圖示的加載結(jié)果來(lái)看，足足有?200?多條），下面大家注意一下這些 WebP 圖片的鏈接地址（以其中一個(gè)為例）：
<img src="http://img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg_.webp" alt="手機(jī)app - 聚劃算" class="app-icon">
.webp 前面，還跟了一個(gè) .jpg 后綴！
我們現(xiàn)在先大膽地猜測(cè)，這個(gè)圖片應(yīng)該至少存在 jpg 和 webp 兩種格式，程序會(huì)根據(jù)瀏覽器的型號(hào)、以及該型號(hào)是否支持 WebP 這些信息來(lái)決定當(dāng)前瀏覽器顯示的是 .webp 后綴還是 .jpg 后綴。帶著這個(gè)預(yù)判，我們打開(kāi)并不支持 WebP 格式的 Safari 來(lái)進(jìn)入同樣的頁(yè)面，再次搜索 WebP 關(guān)鍵字：
Safari 提示我們找不到，這也是情理之中。我們定位到剛剛示例的 WebP 圖片所在的元素，查看一下它在 Safari 里的圖片鏈接：
<img src="http://img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg" alt="手機(jī)app - 聚劃算" class="app-icon">
我們看到同樣的一張圖片，在 Safari 中的后綴從 .webp 變成了 .jpg！看來(lái)果然如此——站點(diǎn)確實(shí)是先進(jìn)行了兼容性的預(yù)判，在瀏覽器環(huán)境支持 WebP 的情況下，優(yōu)先使用 WebP 格式，否則就把圖片降級(jí)為 JPG 格式（本質(zhì)是對(duì)圖片的鏈接地址作簡(jiǎn)單的字符串切割）。
此外，還有另一個(gè)維護(hù)性更強(qiáng)、更加靈活的方案——把判斷工作交給后端，由服務(wù)器根據(jù) HTTP 請(qǐng)求頭部的 Accept 字段來(lái)決定返回什么格式的圖片。當(dāng) Accept 字段包含 image/webp 時(shí)，就返回 WebP 格式的圖片，否則返回原圖。這種做法的好處是，當(dāng)瀏覽器對(duì) WebP 格式圖片的兼容支持發(fā)生改變時(shí)，我們也不用再去更新自己的兼容判定代碼，只需要服務(wù)端像往常一樣對(duì) Accept 字段進(jìn)行檢查即可。
由此也可以看出，我們 WebP 格式的局限性確實(shí)比較明顯，如果決定使用 WebP，兼容性處理是必不可少的。
css3的animation想必大家都知道吧，那 steps 逐幀動(dòng)畫(huà)你知道嗎？對(duì)于我來(lái)說(shuō)，實(shí)際工作及練習(xí)中也很少用到這種跳躍式變化的動(dòng)畫(huà)，而它start和end的解釋又比較“不說(shuō)人話”，以前用到steps動(dòng)畫(huà)的時(shí)候，常常是靠調(diào)試，來(lái)回設(shè)置start和end，主打的就是瞎貓碰上死耗子。雖然之前也看過(guò)關(guān)于他們區(qū)別的文章，但都是半知半解，過(guò)兩天就剩零知零解了。最近忙里偷閑，我終于打算一探究竟了，我倒要看看start和end到底有什么區(qū)別！ 順便寫(xiě)幾個(gè)小demo造福一方～
animation的工作原理是通過(guò)將元素的CSS樣式從一個(gè)狀態(tài)改變?yōu)榱硪粋€(gè)狀態(tài)時(shí)（我們稱(chēng)為線性變化），瀏覽器會(huì)在每個(gè)關(guān)鍵幀之間插入補(bǔ)間動(dòng)畫(huà)，所以動(dòng)畫(huà)效果是連貫性的，這也就是我們常用的 補(bǔ)間動(dòng)畫(huà)。
而steps()逐幀動(dòng)畫(huà)則是跳躍式變化，如果說(shuō)補(bǔ)間動(dòng)畫(huà)是一個(gè)滑坡式的變化，那么逐幀動(dòng)畫(huà)就是階梯式變化，它的變化沒(méi)有中間過(guò)程。補(bǔ)間動(dòng)畫(huà)就像你看的普通動(dòng)畫(huà)片，而逐幀動(dòng)畫(huà)就像是那種定格動(dòng)畫(huà)。
語(yǔ)法:
animation-timing-function: steps(number, [end | start])參數(shù)說(shuō)明：
什么叫在間隔的起點(diǎn)或終點(diǎn)發(fā)生變化呢？光看文字十有八九看不懂，下面就用示例代碼來(lái)說(shuō)明。
上圖是我ps的一張圖，尺寸為200*750，共5個(gè)色塊，每個(gè)色塊高度150。 在示例代碼中我將以這張圖為背景，每一幀將背景上升一個(gè)色塊的高度。關(guān)鍵代碼如下：
animation: ani 5s 2s steps(5,start) infinite backwards;
@keyframes ani{
100%{
background-position:0px -750px;
}
}在設(shè)置動(dòng)畫(huà)前的初始狀態(tài)：
再直接來(lái)看看動(dòng)畫(huà)末態(tài)的情況： 一個(gè)色塊150px，所以動(dòng)畫(huà)末態(tài)是背景圖片向上移動(dòng)750px。
為了完整的看到動(dòng)畫(huà)效果，我設(shè)置了2秒的動(dòng)畫(huà)延遲
我們?cè)O(shè)置的steps的第一個(gè)參數(shù)number為 5 ，也就是把整個(gè)動(dòng)畫(huà)過(guò)程切割成5個(gè)片段，如下圖：
在實(shí)驗(yàn)之前先來(lái)分析一下，既然是片段，那必然有片段的起點(diǎn)和終點(diǎn)，可以把補(bǔ)間動(dòng)畫(huà)看作點(diǎn)，而逐幀動(dòng)畫(huà)則是面。那么這五個(gè)片段的起點(diǎn)終點(diǎn)是哪呢，如下圖：
你會(huì)發(fā)現(xiàn)，動(dòng)畫(huà)是由6個(gè)點(diǎn)切成段五段，帶著這個(gè)思路開(kāi)始下面的實(shí)驗(yàn)。
先來(lái)看一下設(shè)置 start 的效果:
你會(huì)發(fā)現(xiàn)色塊1怎么不顯示了，甚至在動(dòng)畫(huà)沒(méi)開(kāi)始前，也就是延時(shí)階段直接就顯示了【2】，變化過(guò)程為： 2 - 3 - 4 - 5 - 空
分析一下就可以想到，start是在間隔的起點(diǎn)發(fā)生階越變化，即開(kāi)始直接就發(fā)生變化了，第一段直接階越到了第一段結(jié)束的位置。
再來(lái)看下設(shè)置 end 的效果：
你發(fā)現(xiàn)動(dòng)畫(huà)變正常了，動(dòng)畫(huà)過(guò)程是從【1】到【5】。 再分析一下，因?yàn)閑nd是在間隔終點(diǎn)發(fā)生階越變化，即每一段都會(huì)在其開(kāi)始階段進(jìn)行停留，這一段結(jié)束后才會(huì)發(fā)生變化直接階越到下一段的開(kāi)始狀態(tài)。
總結(jié)：
可以將補(bǔ)間動(dòng)畫(huà)和 steps 逐幀動(dòng)畫(huà)類(lèi)比于點(diǎn)和線的區(qū)別，steps切割開(kāi)的每個(gè)動(dòng)畫(huà)片段就是一條樣式不變的線，而線都有首尾兩個(gè)點(diǎn)。
設(shè)置 start 的 steps 的動(dòng)畫(huà)總是在開(kāi)始發(fā)生變化，即逐幀顯示每一段的終點(diǎn)；
而設(shè)置 end 的 steps 的動(dòng)畫(huà)總是在結(jié)束發(fā)生變化，即逐幀顯示每一段的起點(diǎn)；
其實(shí)很簡(jiǎn)單的道理，為什么總是記不住呢，因?yàn)樗腿说膽T性思維恰好相反。設(shè)置start總覺(jué)得是顯示每一段的開(kāi)頭，可它恰好相反，start是開(kāi)頭發(fā)生變化，顯示的都是每一段的結(jié)尾。
另一種理解思路：
steps(number, [end | start]) 是將動(dòng)畫(huà)分為number段，共有number + 1幀畫(huà)面。start就是拋棄第一幀畫(huà)面執(zhí)行動(dòng)畫(huà)，end就是拋棄最后一幀畫(huà)面執(zhí)行動(dòng)畫(huà)。
注意： 第二個(gè)參數(shù)還有兩個(gè)內(nèi)置值，step-start等同于steps(1,start)，動(dòng)畫(huà)分成1步，2個(gè)節(jié)點(diǎn)，拋棄第一個(gè)節(jié)點(diǎn)，即顯示結(jié)尾節(jié)點(diǎn)的狀態(tài)；同理step-end等同于steps(1,end)。
jump-start：在每個(gè)時(shí)間間隔開(kāi)始的時(shí)候跳1步到下一狀態(tài)位置； jump-end：在每個(gè)時(shí)間間隔結(jié)束的時(shí)候跳1步到下一狀態(tài)位置； jump-both：在每個(gè)時(shí)間間隔開(kāi)始和結(jié)束的時(shí)候跳1步到下一狀態(tài)位置，跳步次數(shù)會(huì)比預(yù)設(shè)的多一次； jump-none：在每個(gè)狀態(tài)位置停留夠一個(gè)時(shí)間間隔才跳到下一位置，跳步次數(shù)會(huì)比與預(yù)設(shè)的少一次
上面我只設(shè)置了動(dòng)畫(huà)100%時(shí)的狀態(tài)，那如果我設(shè)置了多個(gè)關(guān)鍵幀的狀態(tài)呢，那還是以整個(gè)動(dòng)畫(huà)過(guò)程切割成number段嗎？
我們?cè)賮?lái)做幾個(gè)實(shí)驗(yàn)：
我們將動(dòng)畫(huà)時(shí)間由5秒改成10秒（為了方便觀察，我們?cè)O(shè)置steps第二個(gè)參數(shù)為end，放棄第一幀畫(huà)面），然后將原先的動(dòng)畫(huà)末態(tài)改到50%，并在動(dòng)畫(huà)100%時(shí)增加邊框?！?/p>
animation: ani 10s 2s steps(5,end) infinite backwards;
@keyframes ani{
50%{
background-position:0px -750px;
}
100%{
border: 100px solid red;
}結(jié)果如下圖：
觀察后發(fā)現(xiàn)，在10秒的完整動(dòng)畫(huà)期間：background-position的變化過(guò)程是圖像顯示由1到5，再由5到1，共變化了 【10】 次，而我設(shè)置的steps的number參數(shù)是 【5】，這就打破了上面我說(shuō)的以整個(gè)動(dòng)畫(huà)過(guò)程切割成number段的假說(shuō)。
同時(shí)可以觀察到，border的變化過(guò)程共進(jìn)行了5次，因?yàn)槲覀冎辉?00%的時(shí)候設(shè)置了border。
得出結(jié)論： steps的number參數(shù)并不是將整個(gè)動(dòng)畫(huà)過(guò)程切割成number段，而是對(duì)于某個(gè)css樣式來(lái)說(shuō)，每一段關(guān)鍵幀的變化切割成number段。
假想：上面我們只在動(dòng)畫(huà)100%的時(shí)候設(shè)置了100px的boder，如果我們?cè)?0%的時(shí)候也設(shè)置border，并且狀態(tài)恰好是100%的一半，這樣對(duì)于動(dòng)畫(huà)0%到100%是一個(gè)流暢的線性變化。請(qǐng)問(wèn)這時(shí)候動(dòng)畫(huà)還會(huì)被切成5段嗎？
觀察發(fā)現(xiàn)，動(dòng)畫(huà)被切成了10段。
得出結(jié)論： 即使將幾個(gè)關(guān)鍵幀的css變化設(shè)置的具有規(guī)律性，但是steps仍然會(huì)將每段關(guān)鍵幀的變化切割成number段，即只要在這個(gè)關(guān)鍵幀里設(shè)置了某個(gè)css，那么對(duì)于這個(gè)css來(lái)說(shuō)，這個(gè)關(guān)鍵幀就會(huì)被視為steps動(dòng)畫(huà)的端點(diǎn)。
那既然每段關(guān)鍵幀都會(huì)被steps切割成number段，那每段的steps動(dòng)畫(huà)執(zhí)行的時(shí)間怎么劃分呢？其實(shí)想想就能想到，應(yīng)該是按照關(guān)鍵幀占整個(gè)動(dòng)畫(huà)過(guò)程的比例分割整個(gè)動(dòng)畫(huà)時(shí)間。
如下圖設(shè)置boder：【0%-50%】寬度由0到100，【50%-75%】寬度由100到0，【75%-100%】寬度由0到100
很明顯可以觀察到，border寬度變化的時(shí)間為 2:1:1，即驗(yàn)證了我上面的推論。
下面我舉幾個(gè)steps() 動(dòng)畫(huà)的使用場(chǎng)景。
用一張人物動(dòng)作關(guān)鍵幀的長(zhǎng)圖，和上面的案例一樣，通過(guò)修改背景圖片位置，實(shí)現(xiàn)動(dòng)物或人物的動(dòng)作變化。作為一名蒸愛(ài)粉，我給哥哥做了一個(gè)跳舞的動(dòng)畫(huà)：
打字機(jī)的原理是用一個(gè)和文字總寬度一樣的div覆蓋文字，并用這個(gè)div的邊框設(shè)置steps()動(dòng)畫(huà)實(shí)現(xiàn)光標(biāo)效果，然后減小div寬度（每一幀減小一個(gè)文字的寬度），讓下面文字漏出來(lái)就好了～\
點(diǎn)擊運(yùn)行查看效果～
我這里提供了兩種實(shí)現(xiàn)方案，準(zhǔn)確來(lái)說(shuō)是三種：
方案1: var() css變量 + counter-reset計(jì)數(shù)器 + @property規(guī)則 + steps()逐幀動(dòng)畫(huà)
使用css變量和counter-reset計(jì)數(shù)器來(lái)實(shí)現(xiàn)倒計(jì)時(shí)的數(shù)字，只要設(shè)置動(dòng)畫(huà)，在5秒內(nèi)將變量由5變?yōu)?即可實(shí)現(xiàn)倒計(jì)時(shí)，但是變量的變化是不會(huì)被瀏覽器添加補(bǔ)間動(dòng)畫(huà)的，即只會(huì)在5秒后直接變成0，而不會(huì)有中間，5-4-3-2-1-0的過(guò)程，這時(shí)我們?cè)倮聾property關(guān)鍵字為這個(gè)變量配置規(guī)則，實(shí)現(xiàn)數(shù)字變化的動(dòng)態(tài)過(guò)程！
而最后出現(xiàn)的 "Go" 可以利用step-end逐幀動(dòng)畫(huà)，在5秒后將文字修改成 "Go"，或者利用@counter-style關(guān)鍵字自定義計(jì)數(shù)器規(guī)則，在變量變化到0的時(shí)候，定義一個(gè)symbols符號(hào)。
如果你不了解counter-reset、@property和@counter-style，可以查看以下兩篇文章：
CSS counter-reset 屬性
mdn 關(guān)于@property API 說(shuō)明 mdn 關(guān)于@counter-style 說(shuō)明
點(diǎn)擊運(yùn)行查看效果～
方案2: 只用steps()逐幀動(dòng)畫(huà)
其實(shí)這個(gè)就很簡(jiǎn)單了，所有的數(shù)字和最后的 "GO" 都在html里寫(xiě)死并設(shè)置等高，然后就可以向上面移動(dòng)圖片位置一樣移動(dòng)這些數(shù)字進(jìn)行顯示了。
點(diǎn)擊運(yùn)行查看效果～
平常工作中可以用到steps()逐幀動(dòng)畫(huà)的場(chǎng)景也有很多：
原文鏈接：https://juejin.cn/post/7242145254056214583
*請(qǐng)認(rèn)真填寫(xiě)需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
