前言
- 移动端现状
随着移动端设备的硬件水平的不断提高,如今的cpu,内存等方面都大大的超过了一般的pc电脑,因此在现今的程序中,合理的使用多线程去完成一些事情是非常有必要的。 -
多线程上传的好处
- 进一步占满网络资源。
- 进一步占满I/O资源。
实现原理
- 策略
oss有分片上传的功能,阿里云断点续传就是基于分片上传的几个api接口进行的封装,主要由InitiateMultipartUpload,UploadPart,CompleteMultipartUpload,AbortMultipartUpload,ListParts这几个组成。 - 流程
- 细节
- 断点续传是一个大任务,又3部分来完成,分别是获取uploadId,分片上传,完成上传,这一整个连续的步骤统一在一个线程中进行。
- 获取uploadId这块需要先对本地缓存文件进行获取,如未拿到,就会直接重新生成新的uploadId直接去进行分片上传,否则会对记录的id进行之前上传了多少片进行还原,继续原来的位置继续上传。
- 分片上传部分,采用多线程并发上传机制,目前线程开启数量最多5条,根据cpu的核数进行判断,如果核数<5 会采用核数进行配置, 分片的个数最多5000。
- 完成上传,对上传的part进行排序,需要按照自然顺序1~n 的顺序进行上传。
- 文件校验,通过文件的md5等其他信息进行校验,分片上传中每一片也会跟服务器做md5校验。
- 进度回调机制,目前进度回调算是最基础版,目前回调原理是根据每一个分片来回调的,即当分片上传成功回调一次。
使用方式
在本地持久保存断点记录的调用方式:
android:
ios:
性能统计
数据分析
android/ios 端的分片上传改为并发后的测试与之前对比,上传分片的网络请求速度 多线程 和 单线程是一样的使用时间,这个主要是取决于带宽速度, 多线程相较于单线程主要是提高了读取文件的io时间。数据如下:
总体来看比之前有提升,单线程随着片的个数的增加时间耗时越来越高,而多线程下,时间基本是一样的,按照目前默认配置的part size 256kb ,单线程下网络资源与I/O资源都吃满,并发下性能提高平均有30%左右(上传时间减少)
小结
移动端下,网络资源与I/O资源一般都比较紧缺,多线程不会提高网络的总带宽:比如,在跑满某个资源下载策略分配一个连接供给带宽2000Kb/s的时候,本地单线程 能够同时吃满 2000Kb/s,这里就到达了一个峰值;但是如果某个资源连接带宽是2000Kb/s,但是单线程请求带宽 已经达到 2000Kb/s,那么就是本地网络带宽 Block了上传速度,也就是说开再多线程,再多连接也都无济于事;但,如果本地网络带宽 吃完2000Kb/s 的同时还有很多的网络资源剩余,假如还有2000Kb/s的提升空间,那么这时再建立一个连接 将这 2000Kb/s 也吃满,那么此时的速度就可以达到 4000Kb/s,这时提速很明显,I/O资源同理。
后续计划
- 增加crc64编码方式进行文件正确性校验,服务端与客户端进行交互验证。
- 分片上传的多线程数量改为可配置,用户可以根据自己的实际需求进行设置。
- 进度回调优化,对进度的粒度进一步的细化,支持回调频率可配置等。