移动设备中的常见模式是请求一页数据，然后将页面数据显示为列表，然后为每个项目请求图像URL。因此，如果屏幕上有8个项目，我们可以同时发出8个图像请求。根据它的流行程度，这似乎还可以
不太常见的是发出显示其他类型数据的后续请求。使用上面的例子，如果我们还必须发出HTTP请求来获取描述字段，那么我们总共必须发出16个请求(针对图像和描述(。
我的问题：
- 在延迟/资源使用方面，映像请求和典型的GET之间有区别吗？前者通常会被毕加索这样的图书馆弄糊涂
- 除了增加代码和UI/UX的复杂性之外，对列表中的每个项目进行后续数据请求还有其他缺点吗
映像请求和GET之间的延迟没有区别，因为映像请求就是GET。这是对图像文件的URL的GET。
缺点-滞后。如果您在一个请求中获得了整个数据列表，则可以立即显示所有数据。如果你每个项目收到1个请求，你必须等待显示项目2…n。有时你会注意到应用程序中的一个页面会在文本后的一瞬间加载图像，这是因为他们仍在下载图像。这对图像来说是一个不错的效果，尤其是如果你知道并可以保留尺寸的话。它对大元素更具吸引力和破坏性，尤其是当它迫使其他元素向下移动时。还要记住，web请求可能不会按照发送的顺序返回，这可能会导致列表元素无序填充的奇怪效果。
然后是服务器和数据库的使用情况——与针对1个项目分别执行10个请求相比，执行一个请求并返回10个项目对两者的负载都较小。显然，在某个地方有一个转折点，如果你退回1000件商品，而应用程序只使用了10件，你就浪费了时间来获得其他990件。因此，如果不了解更多关于典型使用模式的细节、生成这些结果需要多少时间等，就不可能给出100%准确的建议