前端图片压缩与上传OSS组件

2019-05-18 13:33:59
1697次阅读
0个评论
前端需求
实现一个 React 上传组件,文件上传到阿里云 OSS 私人空间(上传后的链接有时效性,防止客户的隐私图片泄漏);
可限制上传文件大小、个数,可配置,实时显示上传进度;
为节省如果上传图片超过了限制的大小,要在上传之前 压缩图片。如果压缩后还是超过限制大小,报错提示;
支持在 input 里 Ctrl + V 直接上传剪贴板截图;
如果文件已经在 OSS 中存在,实现 秒传(参考网盘的秒传功能);
整体流程与技术方案

大多数上传方案一般是应用服务端给前端开一个上传接口,文件流可能是: 


但这种方案有三个缺点:

上传慢。先上传到应用服务器,再上传到 OSS,网络传送多了一倍。如果数据直传到 OSS,不走应用服务器,速度将大大提升,而且 OSS 是采用 BGP 带宽,能保证各地各运营商的速度;
扩展性不好。如果后续用户多了,应用服务器会成为瓶颈;
费用高。由于 OSS 上传流量是免费的。如果数据直传到 OSS,不走应用服务器,可以省下几台应用服务器;
所以,既然文件是存到 OSS,其实文件流没必要经过应用服务器, 前端直接传到 OSS 即可。这既解决了以上问题,节省了不必要的网络流量,又能将集中式变成分布式,为应用服务器分担压力。

但这也带来了几个问题:

实现秒传,基本原理实际就是计算本地文件的 MD5,如果远程 OSS 已存在相同的文件(MD5 比对),就不用再上传一遍了。前端如何计算文件 MD5 呢?
前端如何实现图片的压缩?
安全如何保证?
首先解决安全问题。如果采用客户端直接签名有一个很严重的安全隐患,OSS AccessId/AccessKey 暴露在前端页面,其他人可以随意拿到 AccessId/AccessKey 然后上传文件,这是非常不安全的做法。 解决方案:这里采用基于 session 的服务端签名后直传的方案:


剩下的两个问题:前端计算 MD5、实现图片压缩,下面我们逐个搞定。 最终的整体流程时序图如下(省略了服务端与 OSS 交互细节): 



前端计算 MD5
spark-md5
这个可以帮到我们:spark-md5。要实现在浏览器端计算 MD5,需要浏览器支持 FileAPI 才可以(具体兼容性可以看这里)。 实现原理:

利用 FileReader 的 readAsArrayBuffer( ) 方法,将 file.slice() 分片后的数据读到一个数组中(每个数组项代表一个字节),切分成更小的二进制数据块(chunk),逐块处理。MD5 算法支持流式计算,读一块算一块,最后再一次性生成完整 hash。因此,即使读取大文件,内存也占用很少,性能优异。
MD5 算法的基本原理是将任意长度字符串,通过使用函数转换为新的字符串,并且这种运算不可逆转。它以 16 个 32 位子分组即 512 位分组来提供数据杂凑,经过一系列处理,生成 4 个 32 位分组,最后联合起来成为一个 128 位散列。一般 128 位二进制的 MD5 散列被表示为 32 位十六进制数字,这就是我们通常看到的计算结果。
具体可以看spark-md5 源码实现,以及我的使用方式。官方还提供了一个在线 demo。

性能
你一定想知道,在浏览器里读文件流计算 MD5,性能好吗?如果读大文件,浏览器会不会卡死崩溃?这也是我之前担心的,如果浏览器为此而 crash,那体验太差了。

md5 算法有很多种实现。spark-md5 是基于 Joseph’s Myers 的 JKM md5 实现,这也是目前最快的实现。性能对比。 经过在不同环境中简单测试,可以放心了。结果如下:

虚拟机千牛环境(低配):Windows 10;cpu:i7,2.2GHz,4 核;内存:2G;浏览器:Chrome/44.0.2403.155 Aef/3.16
宿主机环境(高配):MacOS 10.12.5;cpu:i7,2.2GHz;内存:16G;浏览器:Chrome/59.0.3071.115

文件大小
虚拟机计算 MD5 耗时(ms)
MacOS 计算 MD5 耗时(ms)
291K
14
8
4.1M
168
88
27.5M
932
542
52.6M
1792
976
82.6M
2621
1473
880.7M
26740
15501

在浏览器异步计算 MD5 的过程中,仍可以进行其他操作,浏览器不会卡死和 block;
即使电脑是较低的配置,只要文件不大于 100M,MD5 计算时间一般也不超过 3 秒。
所以看业务场景,如果经常有大于 100M 文件的场景,为了良好体验,建议给用户一个 loading 或提示。

前端压缩图片
传统的方案一般是前端原样上传文件,由应用服务器来做图片压缩处理。但现在图片大小动辄就有几 MB,有些场景下为了节省流量和存储空间,更好的做法是在上传之前就进行一次压缩。有了 canvas 之后,前端对图片的处理也能游刃有余。

原理
前端压缩图片的原理:

利用 Canvas 2D Context 的 drawImage( ) 方法传入原始图片,绘制新的图片,设置绘制的图片的 width、height;
然后通过 canvas 的 toDataURL( ) 方法,设置压缩比率,生成压缩后的 dataURI ( MIME + base64 字符串);
最后将 dataURI 转换成 Blob (二进制 jpeg 文件)。
部分核心代码:



function html5ImgCompress(file) {
    let cvs = document.createElement('canvas');
    let ctx = cvs.getContext('2d');
    let img = new Image();
    let fileURL = window.URL.createObjectURL(file);
    img.src = fileURL;
    img.onload = () => {
        cvs.width = img.width;
        cvs.height = img.height;
        ctx.drawImage(img, 0, 0, cvs.width, cvs.height); // 绘制新图片
        dataURI = cvs.toDataURL('image/jpeg', 0.6); // 设置压缩比率
        window.URL.revokeObjectURL(img.src); // 为了性能最好主动释放
    };
    let newImg = convertToBinary(dataURI, { type: 'image/jpeg' });
    resolve(newImg);
}






代码说明:

window.URL.createObjectURL( ) 方法,接收一个 Blob 或 File 对象,创建一个 DOMString。这个方法经常用来在页面上预览本地图片。
canvas 的 toDataUrl() 方法可以将内容导出为 base64 编码格式的图片,此方法可以指定压缩比率(默认 0.92),但是用 base64 编码后,将比源文件大 33.3%。为什么 base64 编码后数据量会变大:

Base64 编码的思想是是采用 64 个基本的 ASCII 码字符对数据进行重新编码。它将需要编码的数据拆分成字节数组。以 3 个字节为一组。按顺序排列 24 位数据,再把这 24 位数据分成 4 组,即每组 6 位。再在每组的的最高位前补两个 0 凑足一个字节。这样就把一个 3 字节为一组的数据重新编码成了 4 个字节。当所要编码的数据的字节数不是 3 的整倍数,也就是说在分组时最后一组不够 3 个字节。这时在最后一组填充 1 到 2 个 0 字节。并在最后编码完成后在结尾添加 1 到 2 个”=”。( 注 BASE64 字符表:ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/)
从以上编码规则可以得知,通过 Base64 编码,原来的 3 个字节编码后将成为 4 个字节,即字节增加了 33.3%,数据量相应变大。所以 20M 的数据通过 Base64 编码后大小大概为 20M * 133.3% = 26.67M。
Blob 对象简介:Blob 对象可以看做是存放二进制数据的容器,允许我们可以通过 js 直接操作二进制数据。一个 Blob 对象就是一个包含有只读原始数据的类文件对象。File 接口基于 Blob,继承了 Blob 的功能,并且扩展支持了用户计算机上的本地文件。
最后一步 convertToBinary() 方法的实现可以看这里。
压缩效果
明白基于 canvas 压缩图片原理之后,有没有已经实现了的压缩工具呢?还真有:html5ImgCompress(demo)。 有一点遗憾的是作者没有发 npm 包,但是提供了几个 js bundle,可以作为项目 vendor 资源使用。

如果想看到不同压缩比率下的效果,我也做了一个简单的 demo,可以输入不同的质量参数,在线看到压缩后的效果:canvas-compressor demo 




对一个大小 4.5MB,尺寸 2387 × 3264 的原图进行压缩,如果限制宽度最大 1000px,不同压缩比率下,生成文件大小对比如下:



压缩比率
文件大小(KB)
0.1
22
0.5
63
0.8
117
0.92(默认)
203
0.95
273
1
1029

上传功能
上传功能基于 plupload 封装。参考阿里云 OSS web 直传 demo。plupload 可以帮我们做分片上传、文件过滤、队列管理、防止重复上传、异常报错等事情。
在 input 里 Ctrl + V 直接上传剪贴板截图:给 input 绑一个 paste 事件即可。
注意一点,阿里云 OSS 的 bucket 必须设置 Cors(Post 打勾),不然不能上传。
UI 和功能分离
初期刚完成这个上传组件的时候,UI 和功能代码耦合度比较高,复用性很差。后来对 UI 和功能进行了分离,使业务和功能尽量解耦。

所以现在提供两个组件:

@alife/react-oss-upload:抽出底层的计算 MD5、图片压缩、上传等功能,可以看做是一个 SDK,没有 UI 样式。
@alife/qn-upload:基于上面组件进行的业务封装。增加了千牛业务的 UI,指定了业务接口地址。
其他业务如果想用这个组件,可以参考这个实现,在 @alife/react-oss-upload 这个 SDK 层之上,加入自己想要的 UI,让服务端遵循里面的接口字段约定,很快就能封装出来。

后续完善
其实上传 SDK 层还可以再做拆解。现在这种方案仍对接口的返回格式有要求,后续考虑能更灵活一点,加一个接口适配层,允许开发者自定义配置。
对比业界类似的上传组件,看还有哪些欠缺。例如百度的 Web Uploader。

收藏00

登录 后评论。没有帐号? 注册 一个。