本文旨在探究js压缩图片的两种方式： 改变图片长宽 ， 改变图片质量 ，和结合了以上两者的 最终方案 。
首先，阅读本文需要知道canvas的两个方法
这两个方法具体的说明可以在MDN上查看，关于图片压缩，也有很多现成的博客可以直接用。但是那些博客都有个问题，并没有关心之后图片的压缩质量。
我试着用一个现成的例子去跑了一下，一个1.7M的图片压缩到了23k，堪称像素级毁灭性破坏。
假如一张大图可能包含着很多文字等关键信息，必须上传之后使用方能清晰辨认。所以要压缩之后质量尽可能接近500k的。500k像素以内，就是若一张图宽度为1024，则高度不能超过500。因为图片有其他的信息，也是要占大小的。即不得大于 1024*500 。
所以，根据需求，上传图片不能超过500k的情况下尽可能保留图片的清晰度。当然如果可以的情况下用上面提到的 canvas.toDataURL 设置压缩程度为0.9，0.8试试看，图片质量可以接受，大小会有大幅度的缩小。
如果不压缩，靠调整图片长宽去控制上传大小呢？
原理很简单，就是靠不断地缩小限定的最大宽高，直到最终长宽的积小于规定的大小。
这种方法有可能最后得出的图片的大小会略大于规定大小，原因上文也提到过了，如果想使用这种方法，可自行再调整一下。
上面的方法有个问题，就是改变了图片的原始长宽。如果一个图的长宽足够大，压缩图片质量，糊一点但是内容看得清也是ok的嘛。所以，跟上面同理，我们可以不断调整图片的质量设定直到大小合适，那么，如何在图片上传之前知道图片的大小呢？
首先，需要知道的一点是，压缩之后拿到的base64字符串会转成blob对象，然后传给服务端。
可以查阅文档，blob对象有个属性是size
这个size就是上传之后实际的文件大小。
参照上面的思路，可以每次改变 canvas.toDataURL('image/' + fileType, level)level的值，去调整压缩图片质量，然后用blob对象的size去验证是否满足500k以内的需求。
关于 canvas.toDataURL 的level到底是怎么计算的，MDN文档里也没说，写了个循环一次减少0.1的level压缩了几个图片
用加减乘除算了一下，没找到规律，数学不好放弃了（这个东西好像也不是能观察出来的，看结果跟初始大小没啥关系）。
这里要注意的是，有可能遇到超大图片，0.1的level可能不足以压缩到500k，所以小于0.1的时候，改变level递减的差值继续压缩下去
在开始接收到图片的时候给一个loading增加用户的耐心好了，loading万岁~
其实单纯的压缩质量遇到稍大的图片，会导致页面高频计算，然后页面基本就用不了了- -。有尝试过用iphone的一个屏幕截图（10M左右），压的时候稍过一会，整个手机都在发烫，只能杀进程。
所以，若对长度没有特殊的限制，可以做一个缩放，去加快压缩的进度，提高能压缩的图片大小上限。
页面到了ios上还是不行- -，可以看到最后图片level为0.001，最长边为764。
问题还是循环次数还是过多，计算频率太高。从图中可看出，对于大图来说，初始设定的level和图片尺寸过于宽松，可以优化一下初始level和尺寸。
有的时候还会遇到一张图片无论如何也压不到500k，就是上一次和这次的压缩后大小没有变化，这种情况需要抛错，不让循环继续。
大图片的等待时间稍长，可以给用户先预览一个base64的图片增加等待耐心，方法名为 getImgBase64 ,这里都一并给出了
解决的隐患：上面这个方案会出现我需要一个500k的照片，压到了520k之后，再压了一次。有时候这最后的一次会特别夸张，直接将图片弄到了几十k。
参考了： https://github.com/WangYuLue/image-conversion
这个库里面有个方法 compressAccurately ,这个方法可以比较精准地压缩。偷偷翻了一下源码。
其实上一个方案的痛点就在于，如何在每一个压缩循环里处理尺寸和压缩比例。
总结
如有纰漏，欢迎指正
