android文件上传优化分享（切片上传）

灰太狼 2022-05-17 08:44 348阅读 0赞

我重点看的是切片上传的原理。

原文链接：[https://www.jianshu.com/p/b4c453649d92][https_www.jianshu.com_p_b4c453649d92]

========================================================

主题

记录安卓端上传模块优化的经历。通过本次分享，咱们可以知道

1.  一个文件经历了几个步骤才能从手机上传到服务端
2.  能知道媒体文件压缩的原理

整个优化经历了两个阶段

1.  第一阶段是上传模块重构，并且通过UI和数据的分离，提升了扩展性，逐步被运用到产品的各个模块中
2.  第二阶段是上传尺寸的优化，通过对视频文件的压缩，大幅减少用户的上传等待时间。

# chapter 1.上传框架重构 #

评估现有模块表现

1.  使用中低配置手机运行apk，查看上传模块实际表现
2.  使用[Charles][]抓包工具，观察每个上传文件体积是否被压缩到合理范围、对上传模块发送的http请求按照功能对其分类，检查是否可以合并同类请求
3.  退出上传，查看上传后续步骤是否被停止；大文件重新上传是否跳过已上传的数据块
4.  查看上传后的结果是否正常播放、是否失真、音频异常

上传模块现存问题

*  UI和上传代码耦合在一起，难以拓展维护
 *  停止上传后仍然继续上传，说明流程控制有问题
 *  在上传时，对每个文件会进行尺寸压缩、计算md5值，比较费时
 *  每个文件上传前都会发送一次存在校验（根据文件md5值），导致在上传的场景中会发送多次http请求校验文件存在
 *  视频文件没有做压缩，导致上传费时

整体设计思路

![Image 1][]

上传设计思路.png

1.  数据UI分离：使用观察模式，抽离UI部分代码。*使用弱引用设置观察者，避免生命周期不一致引起的内存泄漏。*
2.  费时操作前置：在选择图片的步骤，开启异步线程压缩图片、计算md5，将费时操作提前处理掉*（此步骤在mx4 pro上处理拍照的图片耗时100~200ms，基本上选择图片后就已经完成好了计算）*
3.  将文件上传成功的md5值保存在内存中，避免重复处理。
4.  分次请求合并：向服务端开发者申请批校验的接口，将多个文件存在的http请求被合并成一个。

优化后 逻辑UML

![Image 1][]

上传步骤.png

文件切片

文件切片将一个大文件切成若干小文件进行上传，在上传失败的情况下，可以跳过已上传的小文件。  
切片代码底层使用JDK的`RandomAccessFile`对文件提供数据读取  
经测试，上传的瓶颈在于上行带宽，所以切片、上传时单线程任务，不会出现10个切片一起上传的情况。  
切片目前设定为10MB一片，上传时，把当前的块的数据读取到内存中进行上传

切片步骤

1.  对文件md5计算，向服务端校验文件是否已存在，是则提前结束
2.  对文件进行切片，计算每片的md5值用于校验是否已上传。比如38mb的视频，限定每片最大10mb，切出4片，最后一片8mb，其余10mb。

FileChannel fc = new RandomAccessFile(mSourceFile, "r").getChannel();
                        MappedByteBuffer byteBuffer;
    
                        for (int i = 0; i < mBlockCount; i++) {
                            long leftBlockSize = Math.min(mSourceFile.length() - i * mBlockSize, mBlockSize);
                            byteBuffer = fc.map(FileChannel.MapMode.READ_ONLY, i * mBlockSize, leftBlockSize).load();
                            mResultArray.add(new BlockInfoModel("", MD5Util.md5(byteBuffer), i));
                        }
                        fc.close();

1.  批校验文件的切片md5值， 记录没有被上传过的切片下标，循环从源文件读取对应数据切片进行上传。*切片数据流读到内存中性能最佳，但是需要谨慎考虑OOM问题；数据流保存到磁盘中，再循环每次1MB的读取比较稳健，但是性能稍差。本次重构提供了这两种切片方式都可以选择*
2.  所有数据切片上传成功后，向服务端发起一次文件合并请求，成功则结束，否则跳到步骤3。

# chapter 2.媒体压缩 #

> 对于媒体资源来说，压缩就是在保证用户体验的情况下，尽可能地抹去用户感官之外的细节，达到降低文件尺寸的目的  
> 1.音频的无损格式ape、flv 压缩到有损格式的Mp3，就是抹去了人听觉之外的音频细节  
> 2.图片视频经过压缩，虽然放大N倍看细节会变得模糊，但是正常浏览下是可以接受的

举个例子  
针对 1920\*1080的屏幕截图，经过压缩后尺寸不变，但是降低采样率，文件体积从1MB降低到了200KB

![Image 1][]

图片压缩.png

![Image 1][]

压缩前.png

![Image 1][]

压缩后.png

图片压缩

压缩算法参考[鲁班][Link 1]  
通过等比例降低图片的采样率、分辨率、压缩质量等关键因素，大幅度减少输出的像素点数量，达到降低图片的体积的目的  
在不影响浏览体验的前提下，能很大比例压缩图片体积

![Image 1][]

鲁班跑分.png

视频压缩

通过降低视频的分辨率、码率等关键因素，降低视频的体积。  
压缩方案可选1：第三方so库`FFmpeg`软解 2：使用安卓原生`MediaCodec` 硬解  
因为压缩效率、引入体积等问题，我们选择了`MediaCodec`方案  
我们采用的压缩策略是分辨率450\*800，码率是1.5M

![Image 1][]

视频压缩UML.png

在选择微信作为对比标杆的情况下，我们达到了这个标准

![Image 1][]

压缩结果.png

视频压缩UI

![Image 1][]

视频压缩1.png

![Image 1][]

视频上传1.png

总结

通过这两个阶段的重构，安卓端的上传模块初步形成了一个完整的体系，能够满足产品的使用需求，被广泛的应用到各个产品线的业务模块中。

备注

> **码率**  
> 码率是数据传输时单位时间传送的数据位数,一般我们用的单位是kbps即千位每秒。  
> 通俗一点的理解就是取样率，单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件  
> 1920x1080分辨率的视频，码率应该在8Mb以上。  
> 1080x720的分辨率，应该在5Mb左右  
> 720x576分辨率，应该在3Mb左右  
> 640x480分辨率，应该在1.5Mb左右  
> 320x240的分辨率，应该在600Kb左右。

作者：雷霆之喜  
链接：https://www.jianshu.com/p/b4c453649d92  
來源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

[https_www.jianshu.com_p_b4c453649d92]: https://www.jianshu.com/p/b4c453649d92
[Charles]: https://link.jianshu.com?t=https://www.charlesproxy.com
[Image 1]: 
[Link 1]: https://link.jianshu.com?t=https://github.com/Curzibn/Luban