oss-android和ios-sdk多線程的實現原理是什么

這篇文章主要介紹了oss-android和ios-sdk多線程的實現原理是什么的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇oss-android和ios-sdk多線程的實現原理是什么文章都會有所收獲，下面我們一起來看看吧。

實現原理 
策略 
oss有分片上傳的功能，阿里云斷點續(xù)傳就是基于分片上傳的幾個api接口進行的封裝，主要由InitiateMultipartUpload，UploadPart，CompleteMultipartUpload，AbortMultipartUpload，ListParts這幾個組成。 

細節(jié) 
斷點續(xù)傳是一個大任務，又3部分來完成，分別是獲取uploadId，分片上傳，完成上傳，這一整個連續(xù)的步驟統一在一個線程中進行。 
獲取uploadId這塊需要先對本地緩存文件進行獲取，如未拿到，就會直接重新生成新的uploadId直接去進行分片上傳，否則會對記錄的id進行之前上傳了多少片進行還原，繼續(xù)原來的位置繼續(xù)上傳。 
分片上傳部分，采用多線程并發(fā)上傳機制，目前線程開啟數量最多5條，根據cpu的核數進行判斷，如果核數<5 會采用核數進行配置， 分片的個數最多5000。 
完成上傳，對上傳的part進行排序，需要按照自然順序1～n 的順序進行上傳。 
文件校驗，通過文件的md5等其他信息進行校驗，分片上傳中每一片也會跟服務器做md5校驗。 
進度回調機制，目前進度回調算是最基礎版，目前回調原理是根據每一個分片來回調的，即當分片上傳成功回調一次。 
使用方式 
在本地持久保存斷點記錄的調用方式：

android:

String recordDirectory = Environment.getExternalStorageDirectory().getAbsolutePath() + "/oss_record/";
File recordDir = new File(recordDirectory);
// 要保證目錄存在，如果不存在則主動創(chuàng)建
if (!recordDir.exists()) {
    recordDir.mkdirs();
}
// 創(chuàng)建斷點上傳請求，參數中給出斷點記錄文件的保存位置，需是一個文件夾的絕對路徑
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進行上傳，如果任務失敗并且可以續(xù)傳，利用同一個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) {
           // 該任務無法續(xù)傳，需要獲取新的uploadId重新上傳
       }
     } else {
         NSLog(@"Upload file success");
     }
     return nil;
}];

性能統計 
數據分析 
android/ios 端的分片上傳改為并發(fā)后的測試與之前對比，上傳分片的網絡請求速度 多線程 和 單線程是一樣的使用時間，這個主要是取決于帶寬速度， 多線程相較于單線程主要是提高了讀取文件的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資源都吃滿，并發(fā)下性能提高平均有30%左右(上傳時間減少)

關于“oss-android和ios-sdk多線程的實現原理是什么”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“oss-android和ios-sdk多線程的實現原理是什么”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道。