? ? ? ? ?當(dāng)你上傳一張較大的圖片時(shí)候, 在不同的場(chǎng)景需要展示這張圖片時(shí), 那么你考慮過如何優(yōu)化嗎?還是一直都展示的原圖?以及加載大圖, 原圖對(duì)用戶的體驗(yàn)有什么影響? ?下面在這里就提到縮略圖,與原圖的概念. ?
? ? ? ? ?一般圖片你上傳的方式有多種,我這里用到的是通過base64將圖片傳到后臺(tái), ?后臺(tái)接收base64的值前弯，轉(zhuǎn)換為圖片后存儲(chǔ)返回存儲(chǔ)的url.
? ? ? ? 在你上傳的時(shí)候會(huì)做第一次壓縮（比如說5M的圖片給你壓縮到2M左右,但也保證了清晰度）吝秕，然后把這個(gè)稱呼為上傳的原圖吧。然后在服務(wù)器端會(huì)再進(jìn)行處理,生成其他幾種尺寸的圖片霉囚。即原圖與縮略圖.?客戶端請(qǐng)求的時(shí)候會(huì)返回給你這兩種圖的路徑.
? ? ? ?那么問題來了：?
? ? ? ?什么時(shí)候加載哪種尺寸的圖片呢窒悔？
? ? ? ? 假如在某個(gè)app的個(gè)人中心,你上傳已一張圖片當(dāng)做 圖像, ? 相信大家都知道 類似于QQ ,微信的圖像展示框 都是很小的吧. ? ?那么此時(shí)你就沒有必要去展示原圖了, 因?yàn)槟阏故境煽s略圖,也并不會(huì)影響到清晰度. ? ?至于為什么. 如果需要科普PPi 的話, 請(qǐng)看這篇文章:?
http://www.infoq.com/cn/articles/development-of-the-mobile-web-deep-concept
從 LCD顯示器上一個(gè)6x6個(gè)小點(diǎn)排列成的矩陣(矩陣包含 紅綠藍(lán) 三色), 到不同分辨了下的展示,都介紹的非常清楚, 就類似于一篇科普文章,有興趣的可以讀一下.?
? ? ? ? ? ? 言歸正傳, ?也就是說你的小圖像, 完全可以用縮略圖展示 , ?當(dāng)你需要點(diǎn)擊查看大圖的時(shí)候,此時(shí)再去展示原圖. ? 具體的使用, 你可以根據(jù)你的項(xiàng)目 自行斷定. 前提是 后端 對(duì)你上傳的圖片做了 不同尺寸的處理.?
對(duì)于加載大圖的弊端:
1.原圖太大俯渤，加載速度慢馍忽，浪費(fèi)流量；
2.客戶端渲染耗費(fèi)更多的性能妨猩；
? ? ? ? ? ?之前我一直存在一個(gè)誤區(qū), 就是當(dāng)你上傳完圖片后,后臺(tái)把 不同尺寸的圖片返給你 ,那么不是更加浪費(fèi)流量嗎? ?直接返回原圖不就得了? ? ? ? 哈哈, 這里我再次給大家聲明下, 你上傳圖片后, 后端把你上傳的圖片處理成不同的尺寸, 會(huì)返回給你一個(gè)服務(wù)器路徑. 或者通俗的說, 后臺(tái)給你返回了一個(gè)原圖的url 和一個(gè)縮略圖的url. ?你不去加載顯示, 它就是一串字符串. 怎么會(huì)耗性能渲染,浪費(fèi)流量呢.?
? ? ? ? ? ?然后進(jìn)一步的優(yōu)化就是, 原圖較大比較大的情況下,加載需要耗時(shí),此時(shí)怎么處理,或者大圖加載失敗了怎么處理. 類似于微信,當(dāng)你點(diǎn)擊查看原圖時(shí), 首先是模糊的, 然后過了一會(huì)才變清晰. ? ?這種處理方式就是 當(dāng)你查看原圖的時(shí)候, 默認(rèn)先展示縮略圖, 因?yàn)樵瓐D較大,加載渲染需要消耗一段時(shí)間, 等到原圖加載完畢后,再進(jìn)行替換,此時(shí)你看到的圖片就是清晰的了. ? 具體的實(shí)現(xiàn)也相對(duì)比較簡(jiǎn)單. ?體驗(yàn)效果會(huì)好很多.
? ? ? ? ? 當(dāng)圖片加載失敗的時(shí)候,該怎么處理? ?IOS 用的?SDWebImage 有相關(guān)的處理. ? 以及前端 js 我也是通過自行百度 js處理img標(biāo)簽加載圖片失敗潜叛，顯示默認(rèn)圖片?完美解決的.?
