粗略來講，關於下載，簡單的很，無非是得到檔案的源地址，得到檔案流，然後再本地SD卡或者機身記憶體建立一個空File，然後把流中的內容放到檔案中。但實際做起來，實在是麻煩+頭疼的東西。 我的思路，我們需要以下幾個基本的類： 1、一個介面來展示進度--activity/fragment（如果需求需要，notification也是需要的）--activity 2、一個在後臺跑著的，實際上起管理這些下載任務的service--downloadService 3、一個下載Thread，實際上下載內容的執行緒類--downloadTask 4、SQLite資料庫 下面我簡單的分個類，如果說一個下載Thread就是一個下載任務的話，那我就把一個下載任務中承擔多段視訊的下載和單個視訊的下載分別列為兩類，這裡有人可能會說，什麼情況下會在一個下載下載thread中下載多段視訊，是在下載m3u8的時候，那這時候有人又說了，為什麼不開啟多個下載Thread去下載多段的視訊呢，我是這麼考慮的，因為一個m3u8檔案中有成百上千段.ts檔案（這真不是誇大，我曾經下載過一段視訊，一個小時多吧，切了1300多段，還是那個評論，巧(sang)奪(xin)天(bing)工(kuang)），出於這樣的考慮，需要在一個下載Thread中這樣下載一個m3u8，多段.ts（我當時是這麼實現的，但是後來一想，可以用多執行緒的方法，類似於斷點續傳的方式，給多個執行緒分發下載的範圍，貌似也是走的通的，不知道有沒有做過的大神）。 那我們就分開來細說，先說下載多段視訊的，經驗之談，先實現比較複雜的情況，再去實現簡單的情況，因為一般來說簡單的都可以複用複雜的邏輯，反過來卻不行。 一、多段視訊的下載--也就是下載m3u8：

（1）DownloadTask是具體下載任務的Thread，這裡面需要有以下這幾個功能： 1、下載單個檔案，下載多個檔案 2、解析m3u8並儲存m3u8，原理就是替換m3u8檔案中的內容，也就是說建立一個假的m3u8檔案，格式要對，檔案的地址需要換成你的視訊檔案在你SD卡上的儲存地址。 3、廣播--包括通知介面進度更改/下載開始/下載結束/下載暫停，也就是通知展示介面現在下載任務到了什麼進度了。（沒有想到更好的方法，或許可以用回撥的方式實現，但是可能不是很好實現，就沒有用這樣的方式） 4、更新資料庫，開始、暫停、完成的時候都要將狀態/完成百分比/位元組數等等等等寫入到資料庫中 需要注意的：下載檔案的時候需要考慮很多，IOException/網路異常等等都需要做處理，然後給使用者相應的提示；還有，Thread是不好控制的，怎麼控制好Thread的生命週期也是一個麻煩事兒。 （2）實際上起管理作用的downloadService 1、處理從每個介面過來的邏輯，比如： 1.1、展示下載介面過來的--action包括暫停、等待、開始下載等動作，要控制好這些個不同種類的動作也是挺繁瑣的事情。這裡沒有科技含量，但是要細心的處理好邊邊角角。 1.2、點開始下載的時候，也就是剛開始下載的時候過來的。 1.3、等等等等。。。看自己應用的邏輯了 2、保持一個含有正在下載、等待下載的list，用這個list來實際控制到底哪個任務需要下載，哪幾個任務需要等待其他的任務下載完之後再下載。 3、保持對downloadTask的控制 實際上這個類是最複雜的，自己做下載時候時間最多的就是花在了這兒。倒不是多難，主要是因為邏輯複雜，而且還要考慮各種情況，實在是費心神 （3）展示的activity/fragment，這個沒什麼好說的，有廣播接受者來控制介面就好了，無非是起一個會展示的作用。 這裡用了廣播接收者，來接受downloadTask過來的進度變化/暫停/開始的廣播 還要注意的是刪除檔案盒資料庫內容時候的配合，這裡還要細心。 （4）SQLite資料庫，當然了，怎麼儲存下載下來的檔案的資訊呢，還是要用資料庫存下來 資料庫注意的就是記得關cursor，能少呼叫就少呼叫。 然後，總的來說下載還是很麻煩的。實際上已經上線的包括很多有名的app都是同時只能下載一個視訊（當然不能跟迅雷快播之類的專業做下載的比了），其他的都在等待狀態，可能還是考慮到其實也是沒有這個必要，下載完一個就能看，如果多個都在下載的話就不能在最短的時間內觀看下載的視訊了。 （作者原創，轉載請貼連結）