Android下,rxJava+retrofit 并發(fā)上傳文件和串行上傳文件的效率為什么差不多?
問(wèn)題描述
有個(gè)功能需要同時(shí)上傳N個(gè)文件。代碼如下:
ApiService as = ApiManager.getApiService(); final ExecutorService es = Executors.newFixedThreadPool(9);final int count = Bimp.tempSelectBitmap.size();final CountDownLatch finishedLatch = new CountDownLatch(count);final long start = System.currentTimeMillis();for (int k = 0; k < count; k++) { final String fp = Bimp.tempSelectBitmap.get(k).getImagePath(); RequestBody fbody = RequestBody.create(MediaType.parse('image/*'), new File(fp)); as.uploadAttach(fbody) .subscribeOn(Schedulers.from(es)) .observeOn(Schedulers.computation()) .subscribe(new Subscriber<UploadAttachJSON>() {@Overridepublic void onCompleted() {}@Overridepublic void onError(Throwable e) { finishedLatch.countDown(); Log.e('UPLOAD FAILED -------->', fp);}@Overridepublic void onNext(UploadAttachJSON uploadAttachJSON) { finishedLatch.countDown(); sb.append(uploadAttachJSON.url).append(','); Log.e('UPLOADED IMAGE URL -->', uploadAttachJSON.url); h.post(new Runnable() {@Overridepublic void run() { pd.setMessage('正在上傳... ' + (count - finishedLatch.getCount()) + '/' + count);} });} });}try { finishedLatch.await();} catch (InterruptedException e) { e.printStackTrace();}long end = System.currentTimeMillis();Log.e('IMAGE UPLOAD COMPLETED', (end - start) + '');es.shutdown();
以上為并行的寫(xiě)法。從線程池中拿出N個(gè)線程來(lái)同時(shí)上傳這N個(gè)文件。
串行寫(xiě)法: .subscribeOn(Schedulers.io()) 或者 用Observable.merge來(lái)合并這些請(qǐng)求。
結(jié)果發(fā)現(xiàn)并行和串行所花費(fèi)的時(shí)間幾乎都差不多。。 是不是和android底層有關(guān)?這些網(wǎng)絡(luò)請(qǐng)求其實(shí)最后都被底層給block了,然后串行出去?
問(wèn)題解答
回答1:設(shè)備的網(wǎng)速是不是有限制
回答2:有很多因素需要考慮1.自己的代碼實(shí)現(xiàn)2.設(shè)備底層的傳輸實(shí)現(xiàn)3.服務(wù)器接收數(shù)據(jù)的代碼實(shí)現(xiàn)
任何一個(gè)部分不是并發(fā)的,最后的結(jié)果就不是并發(fā)的
相關(guān)文章:
