android文件上传优化分享(切片上传)

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

原文链接:https://www.jianshu.com/p/b4c453649d92

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

主题

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

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

整个优化经历了两个阶段

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

chapter 1.上传框架重构

评估现有模块表现

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

上传模块现存问题

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

整体设计思路

上传设计思路.png

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

优化后 逻辑UML

上传步骤.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

图片压缩.png

压缩前.png

压缩后.png

图片压缩

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

鲁班跑分.png

视频压缩

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

视频压缩UML.png

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

压缩结果.png

视频压缩UI

视频压缩1.png

视频上传1.png

总结

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

备注

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



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

猜你喜欢

转载自blog.csdn.net/u011368551/article/details/81531880