最近为某个爱好俱乐部做了一个小程序，功能里面有一个模块叫做精彩图集。这个模块比较有意思，让我第一次比较深入的去处理图片流文件。期间遇到过一些有意思的事情，也遇到了一些感觉到惊讶的事情。
最初，做这个功能没想那么多。图片上传就直接传到文件服务器，然后生成链接存入表里。前端通过接口获取到链接放入img标签直接显示就完成了。然后发现客户给的测试图片基本都是10m以上一张的图，如果列表直接加载原图，非常久并且流量伤不起。那么在图片上传的时候制作缩略图显得格外重要。
然后当上传原图的时候，我用Thumbnails工具生成缩略图保存。用Thumbnails存在一个很严重的缺陷，对于某些手机拍照的图片会变色，变成类似胶片一样。所以当时就在寻找其他的解决办法。最终选择了Graphics2D去描图。发现效果特别好。因为缩略图不用考虑放大去看，因为放大就是查看原图，所以缩略图的规则可以制定的非常简单，一般手机屏幕看缩略图长和宽不超过500大小的图就非常清晰了，所以不管原图是多么超清的图，我们就按照最后压出来的图片长或者宽小于500即可，测试结果为：无论原图多大，压出来的图片控制在30k。如下图，我做了一个操作就是图片裁剪。逻辑很简单：如果图片过长，则2边裁剪掉过长的一半。过高同理。
在图片处理期间，我同事给我的手机图片上传之后在img里显示会翻转，但是通过浏览器直接访问又是正常的。第一次看到这种情况觉得非常奇怪，图片是如何转动了。最后总结：图片除了本身看得见的图案之外，还存在很多看不见的信息。比如之前我发现我的iphone6p手机是如何显示出来我曾经拍的照的地点信息，这部分信息存在于exif里。让图片旋转的就是Orientation属性。目前我的认知图片所占用的空间包含exif和图片效果本身。再加上客户的图片基本都是6000x4000的规格，大小在16m左右，直接手机打开原图还是太大。积累种种因素最后的做法是：查看图片Orientation是否旋转，如果旋转过先纠正过来用Graphics2D按照原图比例画一版出来。画出来的图片大小大概能缩小10倍。就是10m的图用画笔画出来就只有1m，最让我惊讶的是我用肉眼看不出清晰度有任何变化。在我写这边文章的时候我还是没想明白为何体积缩小了10倍清晰度却为减少，大概只能猜想代码生成的图片，可能底层的表达手法优化了，同时也去掉了图片exif节省了空间吧。
由于图片太过于清晰，并且发现如果把此图用qq的方式去传，qq实际上也会压缩，并且压缩的比我压缩的还小5分之一。所以我决定这张图片还可以压缩，因为手机屏幕比pc端小的多。最后我的逻辑改为，如果图片的清晰度是3000x30000以上规格的我就压缩0.625倍。通过这么压缩发现跟qq压缩体积差不多。图片看起来还是很清晰。就算方案通过了。（一张16m的图片压缩出来的高清图956k，约1m的高清图可接受）。
然后客户需要做图片拼接分享,如下图：
处理逻辑为：先试验得出一个可以接受的清晰度，比如我设置的width是固定的比如1600。如果是宽6000的图就先给等比例缩小到宽1600.比如海报头部图片只有1000.那么就放大到1600.总之图片就是要控制等宽。然后最下面的图片通过维护的字段以及二维码动态生成出来的，也是设置1600宽。最后把图片拼接起来即可。
最后附上代码工具类链接：工具类链接（包括图片旋转处理，高清处理，缩略图处理以及图片拼接处理）
