我們可愛的應用程序從我們的服務器下載mp3到手機上的本地文件，然後從該文件播放被拒絕使用過多的帶寬。iPhone應用程序因「傳輸過量的數據」而被拒絕
我明白拒絕（我們正在下載而不是流式傳輸），並且不要以他們的決定狡辯......我們的首要任務是用戶體驗質量。
我只是想知道......我現在該做什麼？
有沒有硬性規定......蘋果公司只是說：「蘋果公司的合理判斷絕不能過度使用或不適當地加重網絡容量或帶寬」。
任何人都有關於Apple認爲合理的數據傳輸速率的數據？
我應該在短時間內填滿緩衝區文件嗎？應該以恆定的速率傳輸文件（以及如何限制應用內的傳輸速率？）
任何和所有的建議，歡迎。
感謝
我已經和蘋果開發者支持進行了交流，而且只是供參考。您只能通過蜂窩網絡每分鐘傳輸1 MB。支持建議您使用以下方式測試您的應用程序：
「基本測量方法是關閉所有後臺更新（特別是郵件的自動郵件下載和日曆更新），重置」設置：常規：使用情況：「，然後啓動您的應用程序，讓它運行一段固定的時間（五分鐘是合理的），然後退出您的應用程序。完成測試後，」Cellular Network Data「（移動網絡數據）設置：一般：使用：「你應該專注於減少。」
使用我剛剛描述的內容，我建議每5分鐘創建4.8 MB，以確保您的應用程序符合我們的帶寬要求。
希望至少有一點幫助。
在一個更嚴重的是，它是什麼想幹什麼？在美國以外的地區，iPhone的市場很多，這些市場對於手機來說並沒有很好的下載速度，也沒有很好的下載上限，所以有一款應用做大量的下載並不是什麼好事。
你可能會降低你的mp3或一些這樣的數據速率？使它成爲可選的下載警告，它會使用你的下載？
我同意我們應該更加關注帶寬問題......但看到youTube，潘多拉和其他一些流媒體應用程序可以買到它，我只是不認爲我們會被拒絕，因爲如果它。 確實如果每個開發人員都淹沒網絡......使用其他服務（如網頁瀏覽）將受到影響。這就是爲什麼我正在尋找一種負責任的方式來做到這一點，並仍然給予用戶良好的體驗。 – 2009-08-06 04:04:36
您是否考慮過HTTP Live Streaming？它內置於OS 3.0中。
基本上，你把你的媒體分成小的（比如10秒）片段並放到標準的網絡服務器上。然後你用EXTM3U格式創建一些文本'元描述符'文件，指出這些位的位置。有趣的是，您可以創建多個版本，每個片段以不同的比特率。因此，如果您的帶寬良好，iPhone播放器會動態選擇較高的比特率，但當它較低時，會自動切換到片段的較低比特率版本。它可以在飛行中適應不斷變化的條件。
因此，如果您將MP3分成多個10秒位，比如說3種不同的比特率，那麼當用戶通過WiFi連接時，他們會獲得高質量的東西，但如果他們在3G或EDGE上，逐漸降低質量（和更小尺寸）的內容。
如果這違反了您的可下載媒體概念，那麼也許您可以使用相同的技巧併爲每種連接類型保留多個大小文件。然後，如果您使用的是WiFi（或者通過心跳線ping服務器快速週轉），請下載大文件與中小尺寸文件。
Here's a decent step-by-step關於分割內容。他們專注於視頻，但它也應該與音頻內容一起工作。
您對分割文件的第一個建議似乎很多工作，但也許這將是我們必須走的路。這些文件大約需要30分鐘，因此每個文件需要180個文件。 我們在我們自己的播放器中播放文件，而無需用戶離開應用程序..這仍然是一個選擇3.0 HTTP直播流？ 蘋果給開發者一些基準會變得如此簡單。 – 2009-08-06 04:08:20
從WiFi到3G移動到gprs時，內容質量的下降聽起來像一個絕妙的想法... – Spence 2009-08-06 04:56:56
我鏈接到的那篇文章中列出的工具會自動爲您進行分割和播放列表創建。到目前爲止，我只玩過視頻文件，但音頻應該也起作用。流媒體客戶端本質上是可嵌入式視頻播放器。說到視頻內容，它會全屏顯示，但仍然是嵌入式的（即在播放過程中不會退出您的應用程序）。由於它是一個官方認可的框架，你可能會有更好的運氣讓你的應用程序通過。 – Ramin 2009-08-06 10:40:10
你不能下載mp3，除非你是無線的，並告知他們。如果你的mp3太重要了，那就告訴他們它只能在無線上使用，或者在設備上包含一些mp3。但30分鐘的mp3是荒謬的，那是關於什麼，30meg ....想想看，30兆只是太多了。
這些文件是應用程序的核心，範圍從5Mb到16.7Mb。這並不可笑。 – 2009-08-06 13:09:15
我會建議在連接到蜂窩網絡時抑制網絡/ http請求上的帶寬，並且在wifi上沒有節流。
使用Reachability檢測網絡狀態並使用CFNetwork實現您的http請求並進行睡眠，直到下一秒，只要您已經下載儘可能多的每秒允許，就應該到達那裏。
你應該檢查這個項目，無論是使用，或者只是看到一個例子，如何編寫這口井：
http://allseeing-i.com/ASIHTTPRequest
的ASIHTTPRequest類實現這一點，利用舊或2.0版本的可達性，並且還提供了一個類級別的限制，所以即使你有多個併發下載和上傳，只要他們都通過ASIHTTPRequest，它們將被正確地整合在一起並適當調整。
有點更多關於如何這個在這裏使用： http://allseeing-i.com/ASIHTTPRequest/How-to-use#bandwidth_throttling
很多好東西在這個（不，我不是任何它的作者）。
我最終這樣做了。但是，我已經增加了後續更新的數據傳輸速率，但不會受到懲罰（至今） – 2010-01-30 17:30:59
非常有趣。我們通過添加油門來完成審查 - 我必須看到關於油門限制的提升...... – 2010-02-01 22:42:37
這是最有幫助的答案了......謝謝。我們現在正好每5分鐘觸碰4.8 mb（恰巧）。 – 2009-08-25 00:57:50
我們有更多關於此的最新信息嗎？ – Jonny 2010-11-04 11:40:20
你還想知道什麼？ – postalservice14 2010-12-01 16:41:42