在移动设备上以一个大请求或多个小请求下载数据的性能更好吗？答案

【问题标题】：Is it better for performance to download data in one large request or multiple small requests on mobile devices?在移动设备上以一个大请求或多个小请求下载数据的性能更好吗？
【发布时间】：2012-10-30 17:22:01
【问题描述】：

我有一个为 iOS 和 Android 编写的移动应用程序，它使用一个 Web 服务来返回数据。此服务返回的数据大约每天更改一次或当用户更改位置时。我目前正在下载一条大消息（大约 700kb）并使用用户会话所需的所有数据填充应用程序。

问题在于初始消息需要大约 30 秒才能将所有数据处理到本地数据库 (sqlite) 表中。这导致我考虑下载较小的数据块并根据需要处理数据？这可能会导致应用内每次点击的等待时间较短。

基于性能的最佳方法是什么，进而转化为我上面解释的场景类型的最佳用户体验？

我见过其他类似的问题，但它们缺乏明确的答案。 请提供任何答案/意见，然后请投票，这样我们就可以平息这个论点！

【问题讨论】：

看来问题更多的是过程。似乎可以优化。移动设备上的一大网络问题是建立连接的时间很长。我认为最好一次执行更大的提取（使用重试和恢复机制（例如使用范围标头）
您使用什么格式传输数据？
查看 Android 培训 Transferring Data Without Draining the Battery。从硬件的角度来看，下载更少、更大的块而不是更多、更小的块通常更好（最小的总时间和功耗）。这样可以避免打开和关闭无线电。
至少在Android上，进行一次大传输也会减少手机必须唤醒的次数，从而降低功耗。

标签： android ios web-services mobile client-server

【解决方案1】：

由于 whiteagle 给出的原因，通常一个 HTTP 请求是最好的。但是如果对于第一个 Activity 只有少量数据有用，你应该考虑拆分下载。仅直接加载最初需要的内容并使用此信息更新（！）第一个屏幕。

请求返回后，立即开始在一个后续请求中下载所有其他内容。如果第一个屏幕的信息有用，用户将至少需要一段时间才能进入下一个视图。

当然，您应该注意通常的最佳做法：

在后台进行所有下载。
向用户展示一些东西，即使下载尚未完成 - 然后在下载后更新 UI。
尽量减少下载，因为只下载真正新的内容。
最重要的是：积极缓存。

【讨论】：

【解决方案2】：

当然，从响应时间的角度来看，使用一个连接和一个获取请求更好。在移动环境中，几乎没有 DNS 缓存、保持活动检查等（所有这些让我们在 PC 上的生活更轻松的小事情），因此每次连接建立（握手）需要相当长的时间，有时甚至长达一秒钟案例。因此，如果您将提要拆分为不同的连接，则必须汇总所有握手。

在您的情况下，您说存在处理延迟问题，因此，将此进程放入后台线程并分块填充数据可能是个好主意吗？我的意思是，您以 100 步（例如）下载整个提要并启动处理例程，并获得一些回报。

【讨论】：