下載管理程式所做的事情是網頁瀏覽器不會做的
一個四GB的檔案，完成了百分之九十，然後一個電話——或者只是一個鎖定的螢幕——它就消失了。這是在 iOS 上下載時最常見的抱怨，但它不是一個錯誤。這是作業系統完全按照其設計目的進行的操作，也是存在單獨一類App的原因。
- 30s 掛起的App在 iOS 停止之前大約會持續運行多長時間
- 206 讓復原成為可能的 HTTP 狀態
- 1位元組 重新下載了多少正確復原的傳輸
為什麼切換App時傳輸會停止
iOS 不會因為App願意而讓其繼續運作。當您離開某個App時，它會在幾秒鐘內掛起，並且掛起的App沒有 CPU 時間，沒有網路套接字，也無法注意到它已停止。它在記憶體中保存的所有內容仍然存在，但被凍結了——如果系統需要記憶體，App會在沒有通知的情況下直接終止。
在App內的普通連線上執行的下載因此以主頁手勢結束。有些App透過要求額外幾秒鐘的背景時間來隱藏這一點，這就是為什麼下載有時會在背景存活下來，只要您注意到它沒有。
正確的答案是不同的。 iOS 提供了背景傳輸服務：您向系統提供 URL 和目的地列表，系統會按照自己的時間表在自己的進程中自行下載。您的App可以暫停、終止或根本不運行 - 傳輸會繼續，並且當有需要報告的情況時，App會在背景重新啟動。這是每次在鎖定螢幕後仍然存在的下載背後的機制，使用它是App預先做出的設計決策，而不是您可以打開的設定。
決定下載是否存活的四個機制
- 範圍請求
- 請求 5,000,000 位元組以上而不是整個檔案的 HTTP 請求。如果伺服器回答“206 Partial Content”，則可以從中間恢復；如果它回答“200 OK”並從頭開始，則不是 - 檔案必須從零開始再次取得。
- 並行連線
- 將一個檔案分割成多個範圍並同時取得它們。它很有幫助，因為單一連線通常會受到伺服器的限製或受到往返延遲的限制，而不是因為開啟的套接字越多，您的網路速度就越快。
- 承諾偏移量
- 檔案的多少部分已安全寫入磁碟，而不是仍在運作中。從最後提交的位元組恢復的下載是正確的；一個從它「認為」收到的內容恢復的檔案會產生一個損壞的檔案，該檔案僅在數小時後才顯露出來。
- 背景會話
- 系統運作傳輸如上所述。它啟動速度較慢，無法提供任意的自訂邏輯，而且它是App不運行時唯一保持運行的東西。
下載失敗的原因以及每次失敗的情況
大多數「卡住下載」報告都是這五種之一，一旦您了解其形狀，就很容易區分它們。
| 你所看到的 | 到底發生了什麼 | 有什麼幫助 |
|---|---|---|
| 在您離開App時停止 | 傳輸是在進程中運行的，而不是在背景會話中運行。 | 你無法從外部做任何事情——這是一個App設計問題。 |
| 每次都從0%重新啟動 | 伺服器忽略範圍請求，因此無法從中間繼續。 | 穩定的連線，或較小的檔案。某些主機僅允許簽名連結的範圍。 |
| 幾分鐘後反覆失敗 | 連結已過期。許多主機發出的 URL 有效期限為五到十分鐘。 | 從其頁面再次獲取連結並重新開始；舊的永遠不會工作。 |
| 下載速度快，然後檔案打不開 | 到達的是一個 HTML 錯誤頁面或帶有視訊檔案名稱的登入頁面。 | 檢查大小 — 14 KB 的「電影」是一個網頁。在提交之前檢查連結。 |
| 儘管連線速度很快，但速度很慢 | 伺服器端的每個連線限制。 | 更多並行連線（如果伺服器允許）。如果它透過 IP 位址而不是套接字進行限制，則沒有任何幫助。 |
根本沒有檔案可供下載時
網路上大部分的影片不是以檔案形式提供的。它以 HLS 的形式提供 - 一個“.m3u8”播放列表，其中列出了數百個小片段，每個片段幾秒鐘，通常具有多種畫質等級，以便播放器可以隨著連線的變化進行切換。沒有單一的 URL 保存該影片，因為該影片僅作為序列存在。
儲存一個意味著取得每個片段，然後重新混合它們：將視訊和音訊串流寫入普通的 MP4 容器。沒有任何內容被重新編碼，因此沒有任何內容遺失，並且只需要幾秒鐘而不是電影的長度。結果是一個可以在任何地方播放的普通檔案。
這也是為什麼「下載此流」的啟動時間比下載檔案要長得多：必須獲取並解析播放列表，選擇品質級別，然後片段才能開始到達。這就是為什麼有些流根本無法保存的原因——如果片段在 DRM 方案下加密，則故意無法獲取密鑰，並且任何尊重法律的工具都無法克服這一點。
真正的下載管理程式與下載按鈕的差異
App關閉後它仍然存在
背景傳輸交給系統，切換從相同的提交位元組繼續，而不是再次啟動檔案。
它會在您提交之前告訴您連結是什麼
大小、類型以及伺服器是否支援復原 — 所有這些都可以透過單一 HEAD 請求得知，並且在您花費 4 GB 的資料計劃之前都非常有用。
它排隊而不是洪水
一次十個檔案比一次三個檔案慢，因為每個連線獲得的份額較小，且故障會倍增。具有合理並發限制的佇列會更快完成。
落地的是普通檔案
在一個資料夾中，您可以看到，命名合理，可以由任何東西播放 - 而不是只有該App可以打開的資料庫 blob。
防止大多數下載問題的習慣
- 在 Wi-Fi 上啟動大檔案並在前幾秒鐘保持螢幕打開
切換到背景會話會提前發生；之後螢幕就不再重要了。
- 不要一次排隊二十個項目
三到五個並發傳輸是幾乎每個連線的最佳點。
- 檢查之前而不是之後的可用空間
填充磁碟的傳輸在 98% 時失敗，iOS 可能已經清除了您的快取以騰出空間。
- 以懷疑的態度對待瞬間的“完成”
兩秒內看完的電影是一個錯誤頁面。查看檔案大小。
- 從其頁面重新獲取過期鏈接
無論App重試多少次，重試死簽章 URL 將永遠失敗。
這在不同裝置上有何不同
由此提出的問題
更多的連線總是意味著更快的下載嗎？
沒有。當伺服器限制每個單獨連線的速度（這種情況很常見）時，它們會有所幫助。當限制是您自己的連線時，它們什麼也不做，當主機計算每個 IP 位址的套接字數並開始拒絕它們時，它們會使事情變得更糟。有用的範圍在 4 到 8 之間。三十是適得其反的。
螢幕鎖定時可以繼續下載嗎？
是的，如果它被交給系統的背景傳輸服務。鎖定螢幕與該服務無關——重要的是被暫停的App，而該機制的全部要點是無論如何它都會繼續運行。
為什麼我的下載會重新啟動而不是繼續？
伺服器未接受範圍請求。您可以看出，因為進度回到零而不是回升。有些主機僅在其簽署的下載 URL 上支援範圍，有些主機完全停用它們，有些主機支援小檔案但不支援大檔案。
將流轉換為 MP4 與重新編碼相同嗎？
沒有。重新混合將現有視訊和音訊原封不動地移至 MP4 容器中 — 無損且速度足夠快，可在幾秒鐘內完成。重新編碼會使用不同的編解碼器重建影像，並且總是會損失品質。如果保存兩個小時的串流需要兩個小時，則某些內容在不需要時重新編碼。
FoxDL如何下載
這套引擎有兩條路線：App在螢幕上時走的是速度較快的行程內通道，離開螢幕後則由系統的背景傳輸接手，從同一個位元組繼續。
- 單一檔案的平行區塊，直接寫入磁碟上的最終位置，而不是寫入隨後必須連接起來的暫存部分。
- 背景傳輸在App離開螢幕後繼續，並在最後提交的偏移量處接續 - 而不是App以為它擁有的最後一個位元組。
- 只要伺服器接受範圍請求，就能在斷線、重新啟動或強制結束後復原。如果不支援，FoxDL 會直接說明，而不是不斷重試。
- HLS 串流重新封裝為 MP4，因此進入庫中的是普通檔案，而不是由片段組成的資料夾。
- 下載檢查器，在開始之前報告連結的實際大小、類型和復原支援情形。
- 所有內容最終都會放進檔案App看得到的普通資料夾。
免費額度因平台而異：在 iPhone 和 iPad 上，少量通行證由您自己開始的獎勵短影片充值；在 Mac 上，根本沒有廣告，每日固定計數。 Pro 消除了對每台裝置的限制。