这是我参与「第四届青训营 」笔记创作活动的第11天

在开发视频组件时，考虑到有很多场景需要搞定视频上传。因此为了同时能够实现快速预览效果，避免图片或视频稍大或请求响应较慢。

通过查阅资料了解到上传视频/图片或者其他大文件内容，可以通过下面两个api来完成。

• URL.createObjectURL()

• FileReader.readAsDataURL()

4.1 功能测试

注：这里我们用的是FileReader.readAsDataURL()来尝试上传功能

我们用三个视频来进行测试，在这里我们命名为A，B，C。

• A视频体量最小，10MB的大小

• B视频体量适中，25MB的大小

• C视频体量最大，达到100MB

1. A视频效果

2. B视频效果

3. C视频效果

4. 其他功能

视频的动态拉伸，进度条等功能

4.2 性能测试

在上边我们演示了用FileReader.readAsDataURL(file)，也可以完成上传功能，但是在上面的测试中，我们发现在C视频上传会比前两个视频有明显的延迟。

对比这两个api的区别的特点，可以发现这两个是有明显的区别的。

内存使用

• FileReader.readAsDataURL(file)的返回值是转化后的超长base64字符串(长度与要解析的文件大小正相关)。

• URL.createObjectURL(file)的返回值虽然是字符串，但是是一个url地址。

通过控制台返回结果，得出返回值确实不同。

将C视频更换为URL.createObjectURL(file)来实现获取，速度比起我们之前的效率有着非常明显的提升。

但是URL.createObjectURL(file)虽然性能优越，但是还是存在其他问题。

内存清理

• FileReader.readAsDataURL(file)依照JS垃圾回收机制自动从内存中清理。

• URL.createObjectURL(file)存在于当前doucment内，清除方式只有unload()事件或revokeObjectURL()手动清除 。

执行机制

• FileReader.readAsDataURL(file)通过回调的形式返回，异步执行。

• URL.createObjectURL(file)直接返回，同步执行。

对比上面两者的区别，可以发现在内存处理上URL.createObjectURL(file)显然更繁琐，并且由于

URL.createObjectURL(file)实现只是获取本地的内存地址。因此没办法用接口相关的使用临时预览url。

总体来说

URL.createObjectURL(file)得到本地内存容器的URL地址，方便预览，多次使用需要注意手动释放内存的问题，性能优秀。 FileReader.readAsDataURL(file)胜在直接转为base64格式，可以直接用于业务，无需二次转换格式。

因此在开发时，考虑到会有大文件上传，我们在具体实现时可以先获取视频的大小，对不同大小的文件上传采用不同的策略。