这篇文章主要介绍了oss-android和ios-sdk多线程的实现原理是什么的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇oss-android和ios-sdk多线程的实现原理是什么文章都会有所收获，下面我们一起来看看吧。
实现原理
策略
oss有分片上传的功能，阿里云断点续传就是基于分片上传的几个api接口进行的封装，主要由InitiateMultipartUpload，UploadPart，CompleteMultipartUpload，AbortMultipartUpload，ListParts这几个组成。
细节
断点续传是一个大任务，又3部分来完成，分别是获取uploadId，分片上传，完成上传，这一整个连续的步骤统一在一个线程中进行。
获取uploadId这块需要先对本地缓存文件进行获取，如未拿到，就会直接重新生成新的uploadId直接去进行分片上传，否则会对记录的id进行之前上传了多少片进行还原，继续原来的位置继续上传。
分片上传部分，采用多线程并发上传机制，目前线程开启数量最多5条，根据cpu的核数进行判断，如果核数<5 会采用核数进行配置， 分片的个数最多5000。
完成上传，对上传的part进行排序，需要按照自然顺序1～n 的顺序进行上传。
文件校验，通过文件的md5等其他信息进行校验，分片上传中每一片也会跟服务器做md5校验。
进度回调机制，目前进度回调算是最基础版，目前回调原理是根据每一个分片来回调的，即当分片上传成功回调一次。
使用方式
在本地持久保存断点记录的调用方式：
android:
String recordDirectory = Environment.getExternalStorageDirectory().getAbsolutePath() + "/oss_record/";
File recordDir = new File(recordDirectory);
// 要保证目录存在，如果不存在则主动创建
if (!recordDir.exists()) {
recordDir.mkdirs();
}
// 创建断点上传请求，参数中给出断点记录文件的保存位置，需是一个文件夹的绝对路径
ResumableUploadRequest request
= new ResumableUploadRequest("<bucketName>", "<objectKey>", "<uploadFilePath>", recordDirectory);
// 设置上传过程回调
request.setProgressCallback(new OSSProgressCallback<ResumableUploadRequest>() {
@Override
public void onProgress(ResumableUploadRequest request
, long currentSize, long totalSize) {
Log.d("resumableUpload", "currentSize: ">
ios:
// 获得UploadId进行上传，如果任务失败并且可以续传，利用同一个UploadId可以上传同一文件到同一个OSS上的存储对象
OSSResumableUploadRequest * resumableUpload = [OSSResumableUploadRequest new];
resumableUpload.bucketName = <bucketName>;
resumableUpload.objectKey = <objectKey>;
resumableUpload.partSize = 1024 * 1024;
resumableUpload.uploadProgress = ^(int64_t bytesSent, int64_t totalByteSent, int64_t totalBytesExpectedToSend) {
NSLog(@"%lld, %lld, %lld", bytesSent, totalByteSent, totalBytesExpectedToSend);
};
resumableUpload.uploadingFileURL = [NSURL fileURLWithPath:<your file path>];
NSString *cachesDir = [NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) firstObject];
resumableUpload.recordDirectoryPath = cachesDir;//记录断点的文件路径
OSSTask * resumeTask = [client resumableUpload:resumableUpload];
[resumeTask continueWithBlock:^id(OSSTask *task) {
if (task.error) {
NSLog(@"error: %@", task.error);
if ([task.error.domain isEqualToString:OSSClientErrorDomain]
&& task.error.code == OSSClientErrorCodeCannotResumeUpload) {
// 该任务无法续传，需要获取新的uploadId重新上传
}
} else {
NSLog(@"Upload file success");
}
return nil;
}];
性能统计
数据分析
android/ios 端的分片上传改为并发后的测试与之前对比，上传分片的网络请求速度 多线程 和 单线程是一样的使用时间，这个主要是取决于带宽速度， 多线程相较于单线程主要是提高了读取文件的io时间。数据如下：
iOS 模拟器测试 100mb大小文件 1000 part num 单线程 104.530217s 多线程 54.528591s 100 part num 单线程 59.306880s 多线程 54.336914s 1.31g 大小文件 100 part num 单线程 746.775666s 多线程 731.940330s 1000 part num 单线程 822.866331s 多线程 733.306236s 2000 part num 单线程 965.428122s 多线程 731.940330s 5000 part num 单线程 1205.379382s 多线程 732.982330s android motoXT1085 双核cpu 100mb文件 100 part num 单线程 70.484s 多线程 53.656s 1000 part num 单线程 104.530217s 多线程54.528591s 1.31g视频文件 135 part num 单线程 869s 多线程 738s 1342 part num 单线程 1079.081s 多线程 732.079s
总体来看比之前有提升，单线程随着片的个数的增加时间耗时越来越高，而多线程下，时间基本是一样的，按照目前默认配置的part size 256kb ，单线程下网络资源与I/O资源都吃满，并发下性能提高平均有30%左右(上传时间减少)
关于“oss-android和ios-sdk多线程的实现原理是什么”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“oss-android和ios-sdk多线程的实现原理是什么”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注本站行业资讯频道。
