我有一个为 iOS 和 Android 编写的移动应用程序，它使用一个 Web 服务来返回数据。此服务返回的数据大约每天更改一次或当用户更改位置时。我目前正在下载一条大消息（大约 700kb）并使用用户会话所需的所有数据填充应用程序。
问题是初始消息需要大约 30 秒才能将所有数据处理到本地数据库 (sqlite) 表中。这导致我考虑下载较小的数据块并根据需要处理数据？这可能会导致应用内每次点击的等待时间较短。
基于性能的最佳方法是什么，这反过来又转化为我上面解释的场景类型的最佳用户体验？
我见过其他类似的问题，但他们缺乏明确的答案。 请提供任何答案/意见，然后请投票，这样我们就可以平息这个论点！
当然，从响应时间的角度来看，一个连接一个获取请求更好。在移动环境中，几乎没有 DNS 缓存、保持活动检查等（所有这些让我们在 PC 上的生活更轻松的小事情），因此每次连接建立（握手）需要相当长的时间，有时甚至长达一秒钟案例。因此，如果您将提要拆分为不同的连接，则必须汇总所有握手。
在您的情况下，您声明存在处理延迟问题，因此，将此进程放入后台线程并分块填充数据可能是个好主意吗？我的意思是，您以 100 步（例如）下载整个提要并启动处理例程，并获得一些回报。
一般来说，由于 whiteagle 给出的原因，一个 HTTP 请求是最好的。但是如果对于第一个 Activity 只有少量数据有用，你应该考虑拆分下载。仅直接加载最初需要的内容并使用此信息更新（！）第一个屏幕。
请求返回后立即开始在一个后续请求中下载所有其他内容。如果第一个屏幕的信息有用，则用户将至少花一小段时间才能进入下一个视图。
当然，您应该注意通常的最佳实践：
在后台进行所有下载。
向用户展示一些东西，即使下载尚未完成 - 然后在下载后更新 UI。
尽量减少下载，因为只下载真正新的内容。
最重要的是：积极缓存。