android - DownloadManager 与后台服务

Question

我有下载多个图像和视频的要求，并且要求需要“一次”下载，因此实际上不需要任何缓存，这就是我不使用 Volley 的原因。视频 Volley 可能很昂贵。

接下来，我偶然发现了内置 Android 的 DownloadManager这似乎促进了队列上的下载，API 总体上看起来还不错，但我想知道它与使用 Service 和 ScheduledThreadPoolExecutor( Commonsware 的帖子之一指定的选项)？

注意:我的用例严格不是为有可能重复请求的网格下载图像。我的请求只能是单次下载。该请求可能包含少量图片和视频。

Service 中的 ScheduledThreadPoolExecutor 能否显着加快？

Answer 1

I was wondering how [DownloadManager] might compare to using a Service with a ScheduledThreadPoolExecutor

DownloadManager 不需要您的进程运行，它会处理重试策略等所有问题。另一方面，DownloadManager:

• 要求下载从一个简单的 URL 开始(即没有 session cookie)

• 通过“下载”应用向用户显示结果

• 只能轻松下载到外部存储

• 一次下载一个项目

• 可能会延迟下载开始一段时间(例如，如果正在下载其他内容)

ScheduledThreadPoolExecutor 不太可能成为进程内解决方案的一部分，尽管 ThreadPoolExecutor 可能。仅当您需要一次尝试下载 N 个视频并且不想使用 HTTP 客户端 API(例如 OkHttp)提供的任何多线程选项时才需要这样做。由于你想在后台下载这些东西(大概)，而你不知道用户在前台做什么，我建议一次只下载一个视频，这样你就不会让用户难以使用互联网不受前台发生的一切影响。

Could the ScheduledThreadPoolExecutor inside Service be significantly faster?

你在比较苹果和小行星。

ScheduledThreadPoolExecutor 和 Service 都不执行 HTTP 下载。进程内 HTTP 客户端 API(HttpUrlConnection、OkHttp、Volley 等)执行 HTTP 下载，一些进程外选项(特别是 DownloadManager)也是如此。 DownloadManager 和以下组合之间的比较比较合适:

• 进程内 HTTP 客户端 API，以及
• 某种形式的服务，即使用户离开您的用户界面也可以继续下载

从纯速度的角度来看，任何 HTTP 客户端 API 都会受到网络的限制，因此性能应该大致相当。 Volley 不太适合大量下载，因为它将整个结果放在内存中，并且您没有视频的堆空间。其他选项可让您将结果流式传输到文件。