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。