Android下,rxJava+retrofit 并发上传文件和串行上传文件的效率为什么差不多?
有个功能需要同时上传N个文件。代码如下:
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>() {
@Override
public void onCompleted() {
}
@Override
public void onError(Throwable e) {
finishedLatch.countDown();
Log.e("UPLOAD FAILED -------->", fp);
}
@Override
public void onNext(UploadAttachJSON uploadAttachJSON) {
finishedLatch.countDown();
sb.append(uploadAttachJSON.url).append(",");
Log.e("UPLOADED IMAGE URL -->", uploadAttachJSON.url);
h.post(new Runnable() {
@Override
public 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();
以上为并行的写法。从线程池中拿出N个线程来同时上传这N个文件。
串行写法:.subscribeOn(Schedulers.io())
或者 用Observable.merge
来合并这些请求。
结果发现并行和串行所花费的时间几乎都差不多。。 是不是和android底层有关?这些网络请求其实最后都被底层给block了,然后串行出去?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
设备的网速是不是有限制
有很多因素需要考虑
1.自己的代码实现
2.设备底层的传输实现
3.服务器接收数据的代码实现
任何一个部分不是并发的,最后的结果就不是并发的
参考资料:Rx: Scheduler: