解读阿里云oss-android/ios-sdk 断点续传

前言

• 移动端现状
  随着移动端设备的硬件水平的不断提高，如今的cpu，内存等方面都大大的超过了一般的pc电脑，因此在现今的程序中，合理的使用多线程去完成一些事情是非常有必要的。

• 多线程上传的好处

  1. 进一步占满网络资源。
  2. 进一步占满I/O资源。

实现原理

• 策略
  oss有分片上传的功能，阿里云断点续传就是基于分片上传的几个api接口进行的封装，主要由InitiateMultipartUpload，UploadPart，CompleteMultipartUpload，AbortMultipartUpload，ListParts这几个组成。
• 流程
  
• 细节

1. 断点续传是一个大任务，又3部分来完成，分别是获取uploadId，分片上传，完成上传，这一整个连续的步骤统一在一个线程中进行。
2. 获取uploadId这块需要先对本地缓存文件进行获取，如未拿到，就会直接重新生成新的uploadId直接去进行分片上传，否则会对记录的id进行之前上传了多少片进行还原，继续原来的位置继续上传。
3. 分片上传部分，采用多线程并发上传机制，目前线程开启数量最多5条，根据cpu的核数进行判断，如果核数<5 会采用核数进行配置， 分片的个数最多5000。
4. 完成上传，对上传的part进行排序，需要按照自然顺序1～n 的顺序进行上传。
5. 文件校验，通过文件的md5等其他信息进行校验，分片上传中每一片也会跟服务器做md5校验。
6. 进度回调机制，目前进度回调算是最基础版，目前回调原理是根据每一个分片来回调的，即当分片上传成功回调一次。

使用方式

在本地持久保存断点记录的调用方式：

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编码方式进行文件正确性校验，服务端与客户端进行交互验证。
• 分片上传的多线程数量改为可配置，用户可以根据自己的实际需求进行设置。
• 进度回调优化，对进度的粒度进一步的细化，支持回调频率可配置等。