当您加载多个曲目(使用SPAsyncLoading waitUntilLoaded:timeout:then)时，在加载时间方面，是否有任何指导方针、基准或类似的东西？
我提出这个问题的原因是，我已经尝试过批量加载大约20首曲目，因为曲目元数据将在我的客户端中的整个流中使用(它分为几个步骤，在这些步骤中，除了初始延迟之外，我不希望有任何加载时间，在这种情况下，用户更容易接受)。
例如，一次尝试加载多少条轨道是合理的，"应该"需要多长时间？装载20首曲目"很多"吗？加载一首曲目本身是否会触发大量新的请求来拉入元数据，从而使一次加载多首曲目成为一个非常糟糕的想法除了超时之外，还有什么方法可以找出加载轨道失败的原因吗？
通常情况下(可能十分之一)，加载在默认的20秒超时后失败(我尝试过更长的超时，没有太大区别)。有时所有20条轨道都无法加载，有时只有一条轨道无法加载。我敢说，在这些尝试之间(可能需要一两分钟)，我的互联网连接保持不变(无论如何，尽可能多)。
我意识到这里有很多关于什么是正常的和什么不是等的模糊输入。这显然取决于许多因素，比如你的互联网连接、Spotify服务器的状态等等，但也许可以给出一些提示，告诉你该期待什么，以及Spotify API是否有特定的需要和不需要
通常，规则是：只加载您现在需要向用户显示其元数据的曲目，然后可能预加载下一次显示的曲目。
此外，由于CocoaLibSpotify使用队列，您在库中放置的负载越多，开销就越大。例如，如果你单独SPAsyncLoading一堆东西，它们都会单独排队，但它们的计时器会立即启动。如果你把足够多的东西排队，他们甚至可能在超时触发时还没有开始加载。
然而，由于在内部进行了大量排队，如果您在单个SPAsyncLoading调用中投入大量内容，也会发生这种情况。
为了保持快速，保持轻松，并尽量遵循第一句话中的指导原则。此外，尽量保持效率：
-
SPAlbumBrowse将一次性加载该专辑的曲目元数据，从而减少后端加载和排队时间。 -
与
SPArtistBrowse相同。 -
我相信
SPPlaylist也是如此。