複雜性是不可避免的,而且只會隨時間增長,所以在增加特性時一定要為重構和代碼簡化留出時間。真正遇到問題這前先不要擔心性能。iPhone非常強壯,你可能永遠也不會遇到預想的性能問題。 能過互聯網向一個設備傳送音頻時,可以採用兩種傳輸模型:流式傳輸和下載。 對於流式傳輸,音頻伺服器會按音頻的比特率通過網路 ...
複雜性是不可避免的,而且只會隨時間增長,所以在增加特性時一定要為重構和代碼簡化留出時間。真正遇到問題這前先不要擔心性能。iPhone非常強壯,你可能永遠也不會遇到預想的性能問題。
能過互聯網向一個設備傳送音頻時,可以採用兩種傳輸模型:流式傳輸和下載。
對於流式傳輸,音頻伺服器會按音頻的比特率通過網路傳送位元組。例如,如果音頻編碼為64Kbits/s,可以預見,流式傳輸時就會採用這個速率(64kbit/s).有一個連續,不間斷的音樂流時常會採用流式音頻。
如果音頻傳輸採用下載模型,音樂將被劃分為離散的數據塊(例如, 一次傳送一首歌).客戶儘可能快地下載一個數據塊並播放,而且只在第一個數據塊快要完成下載時才開始下載下一個數據塊。
各種模型都有其優缺點。流式傳輸需要有客戶端記憶體開銷更少(數據一旦傳輸就會有消耗),而且客戶實現的複雜性也更低(這要以伺服器端更高的複雜性為代價)。不過從某種程式講,流式傳輸也更容易由於網路延遲和丟包而破壞音頻。另一方面,下載的音頻內容開銷更大(因為音頻段可能相當大),而且客戶端複雜性也更大。但是下載的音頻對網路破壞更有免疫力,因為網路寬頻可以得到充分利用而不是局限於一個固定的量。
為實現這個特性,需要做到3點:瞭解至今為止已經播放了歌曲的多少位元組,在應用終止時保存這個信息,並且在應用啟動時通過開始一個部分下載從退出時的偏移位置恢復中斷的歌曲。
參考資料:《精彩iPhone炫酷開發-七位一線高手的編程和設計範例》