1

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

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

基于性能的最佳方法是什么,这反过来又转化为我上面解释的场景类型的最佳用户体验?

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

4

2 回答 2

1

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

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

于 2012-10-30T19:33:53.390 回答
1

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

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

当然,您应该注意通常的最佳实践:

  • 在后台进行所有下载。

  • 向用户展示一些东西,即使下载尚未完成 - 然后在下载后更新 UI。

  • 尽量减少下载,因为只下载真正新的内容。

  • 最重要的是:积极缓存。

于 2012-10-30T19:46:41.550 回答