我没有意识到这一限制。虽然在您的提供商可能按字节收费的蜂窝数据服务上禁用潜在的数据量较大的对象或嵌入标签是有意义的,但如果这是原因,那么它仍然可以在3G上工作,而不是在GPRS上工作是没有意义的。
也许问题是基本数据吞吐量之一?如果你自己(或我自己)没有iphone,就很难测试你同事的陈述。
请记住,GPRS比Wi-Fi或3G慢得多。根据维基百科的说法,GPRS将提供56到114 Kbps的全双工吞吐量,并非所有这些都在下载方向上。您已经可以看到,这还不够快,无法立即传输一个典型的128 kbps MP3,即使您获得了最佳吞吐量,并将其全部作为下载速度。
看着
this forum discussion
作为一个在谷歌上出现的例子,GPRS用户(不使用Telestra的用户,这是该领域的一个边缘供应商)获得了大约40Kbps的速度。因此,如果正如问题所暗示的那样,你被困在Edgeland中,而不是3gland或任何介于两者之间的东西,播放30秒的MP3需要大约20秒的缓冲时间。当你使用一个行为模糊的标签,比如object或者embed时,不能保证浏览器会如何解释它,以及它是否会尝试智能地传输文件,而不是在开始之前下载整个文件。
所以,很有可能你的同事只是没有等足够长的时间,看他作为测试选择的任何嵌入式媒体是否开始播放(假设他没有在那里使用你的17kb测试MP3)。也有可能iPhone确实有这种局限性,尽管我认为Google会比我的快速搜索更乐于接受,因为人们已经对其他他们不喜欢的关于iPhone的事情有了足够的发言权。另一种可能是,目前iPhone随附的Safari版本存在局限性,未来版本或其他浏览器可能会对其进行更改。
最终,问题是,您真正想要什么样的用户体验?在GPRS上加载嵌入式音频需要很长的时间,如果要开始在网页上播放,用户将不会享受这种体验,甚至可能根本体验不到这种体验,在他们离开之前,它也不会加载。在这种情况下,这可能不是一个值得努力的目标。