前言：

? ? ? ? 最近在公司做項目的時候，有一個業務場景就是同一張圖片，在不同的位置上展示的效果是不一致的，其實理解起來也很簡單，就以大家熟悉的微信頭像而言，我們在正常使用的情況下，一個微信頭像的大小假設為80 * 80 格式，而我們在點擊頭像彈出的頭像圖片的格式肯定是大于80 * 80的呀，那么，對于這種同一張圖片渲染為不同規格的需求，我們一開始是直接將該圖片丟給前端，讓前端進行加工渲染，但是這就導致一個很可怕的現象：每次頁面渲染，前端都要對各個圖像都進行一個加工處理，這怎么看都不合理呀！那該怎么搞呢？

---

疑惑：

? ? ? ? 一番沖浪后，我發現了一個針對于圖片的處理庫——Thumbnailator，可以實現圖片的加水印呀，或者說設置指定大小呀或者壓縮縮放等等，然后現在我的業務這邊的話，就涉及了這種對圖片的處理，但是目前我們都是交給前端來處理這個東西，那如果說我在傳輸給前端之前就對這個圖片進行了一個處理，會不會在傳輸的過程之中就能優化他的效率？就是說現在對于圖片的加工，我們現在是用前端來做的，就后端不對圖片進行加工，然后我想，如果說我在后端就已經加工好了，那我以一個更小的體積傳給前端。直接進行渲染會不會效率更高呢？不然的話，不經過加工的話，他的體積肯定是更大的呀，那在傳輸過程之中占用的資源也會更多，既然他們結果都是處理成那樣子，那我在后端處理的話，會不會就是說能讓我傳輸的更加順暢呢？但是。我覺得事情沒有想象的那么理想，但我又想不出這樣子做會有什么壞處

對于該圖片的處理庫，有興趣的伙伴可以看看下面這篇文章：

【Thumbnailator】圖片壓縮、水印、格式修改一網打盡https://blog.csdn.net/weixin_73077810/article/details/134590545?spm=1001.2014.3001.5501

疑惑點1：?同一張圖片，在不同的位置上展示的效果是不一致的業務需求怎么實現才是合理的？

疑惑點2：什么時候是需要前端來進行加工操作，什么時候是需要后端來進行加工操作？

---

大牛解答：?

????????我跟技術總監聊了一下，我發現這類需求好像有一類比較合理的處理方法

解答疑惑點1：

????????實際上對于圖片來說的話，他在上傳后就已經是把它處理好了再進行存儲，比如說我上傳了一張圖片，然后這張圖片分別要用在兩個地方，并且這兩個地方上他是不同大小的，就是說它的尺寸會有所變化，那這樣子我上傳圖片的話，我在后端接收好，我就已經把這兩個圖片裁剪為兩個格式了，然后把這兩個不同格式的同一張圖片以一個跟前端約定好的命名規范，比如說A1 A2這樣子，也就是說我前端上傳圖片后，我在后端已經把他弄成了最終要渲染的格式了，前端最后如果想要拿圖片的話，直接就是通過一個URL拿到那個圖片，直接就進行渲染就行，不需要進行二次加工，最終這種方案的話，他就實現了一種一張圖片，我只需要在上傳保存的時候加工一次，之后的話就不需要再進行二次加工

????????就拿我們微信頭像來說，微信頭像他不是很小的一個縮略圖嗎？然后我們點開它的話，可以讓他放大對吧，然后我本來以為的是他用的是同一張圖片，只不過前端對他進行了一個壓縮處理呀，這樣子的二次加工來進行渲染的，但實際上他就是兩張圖片一大一小的，然后當我們正常展示的時候，前端訪問的是小的圖片，當我們要點擊放大的時候，前端就直接就換了一個URL來獲取大的圖片

????????然后對于這種同一類不同規格的圖片，我們采用一個類型差不多的有規律的命名方式，然后前端只需要把那一個有所變動的路徑位置，把他們作為一個變量，如果說我要訪問一個東西的話，我只需要在變量上操作就行，不需要直接改動我的那個URL了，因為他的變動只是小位置的變動，而不是整個URL的變動

解答疑惑點2：

????????對于這種圖片類的話，實際上基本上都是用后端來進行壓縮呀，加水印或者什么什么的，前端的話僅僅只是做一些基礎的校驗，比如說對圖片大小啊，以及它的那個它的格式啊，如說是那個JPG啊，或者是PNG這些的校驗。還有一種就是說，比如說我們的一些APP頭像不是圓形的嗎？然后我們上傳的是方形的圖片，那我們是不是要進行一個手動的選擇裁剪，這種的話就是前端來做的，然后的話，那些對于縮略圖啊，以及一些那個大小尺寸的壓縮，這些的話就是用后端來做。

---

重點：看需求，不盲目進行優化?

上面這種方案看似比較ok，但是并沒有一個方案是完美的，沒有最好的方案，只有最合適的方案！

上述方案主要是靠后端來實現一些圖片業務優化的操作，而實際上前端也會有很多方案可以進行優化，比如：

頁面圖標的渲染——精靈圖，一張圖包含了所有的圖標，前端只需要定位圖標位置展示即可，這樣子，就可以減少網絡io的次數

對于資源的渲染——懶加載和預渲染

????????懶加載——指在頁面加載時，只加載可視區域內的圖片，而延遲加載其他區域的圖片。其原理是通過監聽滾動事件或者計算圖片與可視區域的相對位置，當圖片進入可視區域時再進行加載。懶加載可以減少初始頁面加載時的網絡請求和資源消耗，提高頁面加載速度和用戶體驗。

????????預渲染——指在頁面加載時，提前加載未被用戶請求的圖片資源。其原理是在頁面加載完成后，通過異步請求或者動態創建<link rel="preload">標簽，預先加載將要用到的圖片資源。預渲染可以減少用戶在瀏覽過程中的等待時間，提高圖片的加載速度和用戶體驗。

---

????????我們也許能實現一個需求的功能，就好像一只飛翔的鳥兒，我們能讓它飛起來，但是我們要追求的應該是怎么才能讓它飛的更加自由，更加輕松！