主题

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

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

图片压缩源码https://github.com/Curzibn/Luban
视频压缩源码https://github.com/fishwjy/VideoCompressor

整个优化经历了两个阶段

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();

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