软件开发中对图片的加工处理的一些个人思考和总结

前言：

最近在公司做项目的时候，有一个业务场景就是同一张图片，在不同的位置上展示的效果是不一致的，其实理解起来也很简单，就以大家熟悉的微信头像而言，我们在正常使用的情况下，一个微信头像的大小假设为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头像不是圆形的吗？然后我们上传的是方形的图片，那我们是不是要进行一个手动的选择裁剪，这种的话就是前端来做的，然后的话，那些对于缩略图啊，以及一些那个大小尺寸的压缩，这些的话就是用后端来做。