? ? ? 最近為某個愛好俱樂部做了一個小程序旭贬，功能里面有一個模塊叫做精彩圖集。這個模塊比較有意思搪泳，讓我第一次比較深入的去處理圖片流文件稀轨。期間遇到過一些有意思的事情，也遇到了一些感覺到驚訝的事情岸军。
? ? ? ?最初奋刽，做這個功能沒想那么多。圖片上傳就直接傳到文件服務器艰赞，然后生成鏈接存入表里杨名。前端通過接口獲取到鏈接放入img標簽直接顯示就完成了。然后發(fā)現(xiàn)客戶給的測試圖片基本都是10m以上一張的圖猖毫，如果列表直接加載原圖台谍，非常久并且流量傷不起。那么在圖片上傳的時候制作縮略圖顯得格外重要吁断。
? ? ? ?然后當上傳原圖的時候趁蕊，我用Thumbnails工具生成縮略圖保存。用Thumbnails存在一個很嚴重的缺陷仔役，對于某些手機拍照的圖片會變色掷伙，變成類似膠片一樣。所以當時就在尋找其他的解決辦法又兵。最終選擇了Graphics2D去描圖任柜。發(fā)現(xiàn)效果特別好。因為縮略圖不用考慮放大去看沛厨，因為放大就是查看原圖宙地，所以縮略圖的規(guī)則可以制定的非常簡單，一般手機屏幕看縮略圖長和寬不超過500大小的圖就非常清晰了逆皮，所以不管原圖是多么超清的圖宅粥，我們就按照最后壓出來的圖片長或者寬小于500即可撒璧，測試結果為：無論原圖多大掺喻，壓出來的圖片控制在30k。如下圖拯辙，我做了一個操作就是圖片裁剪剿牺。邏輯很簡單：如果圖片過長企垦，則2邊裁剪掉過長的一半。過高同理晒来。
? ? ? ?在圖片處理期間钞诡，我同事給我的手機圖片上傳之后在img里顯示會翻轉，但是通過瀏覽器直接訪問又是正常的。第一次看到這種情況覺得非常奇怪臭增，圖片是如何轉動了。最后總結：圖片除了本身看得見的圖案之外竹习，還存在很多看不見的信息誊抛。比如之前我發(fā)現(xiàn)我的iphone6p手機是如何顯示出來我曾經(jīng)拍的照的地點信息，這部分信息存在于exif里整陌。讓圖片旋轉的就是Orientation屬性拗窃。目前我的認知圖片所占用的空間包含exif和圖片效果本身。再加上客戶的圖片基本都是6000x4000的規(guī)格泌辫，大小在16m左右随夸，直接手機打開原圖還是太大。積累種種因素最后的做法是：查看圖片Orientation是否旋轉震放，如果旋轉過先糾正過來用Graphics2D按照原圖比例畫一版出來宾毒。畫出來的圖片大小大概能縮小10倍。就是10m的圖用畫筆畫出來就只有1m殿遂，最讓我驚訝的是我用肉眼看不出清晰度有任何變化诈铛。在我寫這邊文章的時候我還是沒想明白為何體積縮小了10倍清晰度卻為減少，大概只能猜想代碼生成的圖片墨礁，可能底層的表達手法優(yōu)化了幢竹，同時也去掉了圖片exif節(jié)省了空間吧。
????????由于圖片太過于清晰恩静，并且發(fā)現(xiàn)如果把此圖用qq的方式去傳焕毫，qq實際上也會壓縮，并且壓縮的比我壓縮的還小5分之一驶乾。所以我決定這張圖片還可以壓縮邑飒，因為手機屏幕比pc端小的多。最后我的邏輯改為级乐，如果圖片的清晰度是3000x30000以上規(guī)格的我就壓縮0.625倍幸乒。通過這么壓縮發(fā)現(xiàn)跟qq壓縮體積差不多。圖片看起來還是很清晰唇牧。就算方案通過了罕扎。（一張16m的圖片壓縮出來的高清圖956k，約1m的高清圖可接受）丐重。
? ? ? ? 然后客戶需要做圖片拼接分享,如下圖：
處理邏輯為：先試驗得出一個可以接受的清晰度腔召，比如我設置的width是固定的比如1600。如果是寬6000的圖就先給等比例縮小到寬1600.比如海報頭部圖片只有1000.那么就放大到1600.總之圖片就是要控制等寬扮惦。然后最下面的圖片通過維護的字段以及二維碼動態(tài)生成出來的臀蛛，也是設置1600寬。最后把圖片拼接起來即可。
最后附上代碼工具類鏈接：工具類鏈接（包括圖片旋轉處理浊仆，高清處理客峭，縮略圖處理以及圖片拼接處理）
