Android多線程斷點續傳下載文件類設計

   對於Android平臺,很多網友可能考慮開發一個軟件商店,對於Android平臺上如何實現斷點續傳操作呢? 這裏Android123給大家一些思路和原理的介紹,同時在Android手機上要考慮的一些事情。

  1. 流量控制,獲取運營商的接入方式,比如說使用移動網絡接入,儘可能的提示用戶切換WiFi或提示,限制下載的流量以節省話費。

  2. 屏幕鎖控制,屏幕鎖屏後導致應用會被掛起,當然Android提供了PowerManager.WakeLock來控制。

  3. 對於斷點續傳,這要追溯到Http 1.1的特性了,主要是獲取文件大小,如果這個無法讀取的話,那麼就無法斷點續傳了只能使用chunked模式了,當然獲取遠程服務器上文件的大小可以通過Http的響應頭查找Content-Length。

  4. 獲取上次文件的更改時間,對於斷點續傳來說比較有風險的就是 繼續下載的文件和早期下載的在server上有變動,這將會導致續傳時下載的文件版本和原始的不同,一般有兩種解決方法,早期我們配置服務器時通過Last-Modified這個http header獲取文件上次修改時間,不過本次Android開發網推薦使用更爲強大的ETag,ETag一般用於解決同一個URL處理不同返回相應,比如Session認證,多國語言,以及部分黑帽的SEO中。具體的實現大家可以參考RFC文檔。

  5. 考慮服務器的3xx的返回,對於專業的下載文件服務器會考慮到負載平衡問題,這就涉及到重定向問題,處理重定向使用Android的Apache庫處理比較好。

  6. 至於多線程,這裏CWJ提示大家可能存在獨立的線程下載一個文件,和多個線程分塊下載單個文件之分,其中後者需要考慮上次下載數據是否存在問題,同時如果服務器不支持文件大小獲取,則無法通過分段下載數據,因爲不知道如何分段,所以在chunked模式中,只能使用一個線程下載一個文件,而不是多個線程下載一個文件。

  7. 下載後的數據效驗,可以考慮CRC等方式,當然對於一般的傳輸只要邏輯不出現問題,基本上不會有偏差。

  8. 考慮DRM問題,這個問題在國內用的比較少,而國外的受數字保護的音樂和視頻,需要額外的獲取證書等。

  9. 重試次數,對於一個文件可能在本次網絡傳輸中受到問題,尤其是移動網絡,所以可以設置一定的重試次數,讓任務單獨的走下去。

  10. 線程開發方式,這裏如果你的Java基礎比較好,推薦直接使用Java併發庫API比較好,如果過去只做過Java開發使用Thread即可,如果Java技術不過關可以Android封裝的AsyncTask。

  有關完善的多點續傳的示例,Android123將在近期提供源碼。

轉自:http://www.android123.com.cn/androidkaifa/932.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章