Apa yang dilakukan pengelola unduhan yang tidak dilakukan browser web
File empat gigabyte, sudah sembilan puluh persen, lalu ada telepon masuk — atau sekadar layar terkunci — dan hilang begitu saja. Ini adalah keluhan paling umum tentang mengunduh di iOS, dan ini bukan bug. Ini sistem operasi melakukan persis apa yang dirancang untuknya, dan alasan mengapa ada kelas aplikasi tersendiri untuk ini.
- 30 dtk Kira-kira berapa lama aplikasi yang ditangguhkan tetap berjalan sebelum iOS menghentikannya
- 206 Status HTTP yang membuat melanjutkan unduhan mungkin sama sekali
- 1 byte Berapa banyak transfer yang dilanjutkan dengan benar diunduh ulang
Kenapa transfer berhenti saat kamu berpindah aplikasi
iOS tidak membiarkan sebuah aplikasi terus bekerja hanya karena ia ingin begitu. Saat kamu meninggalkan sebuah aplikasi, ia ditangguhkan dalam hitungan detik, dan aplikasi yang ditangguhkan tidak punya waktu CPU, tidak punya soket jaringan, dan tidak punya cara untuk menyadari bahwa ia telah dihentikan. Semua yang sedang dipegangnya di memori masih ada, tapi beku — dan kalau sistem membutuhkan memori itu, aplikasinya langsung dihentikan sepenuhnya tanpa diberitahu.
Unduhan yang berjalan pada koneksi biasa di dalam aplikasi karenanya berakhir tepat saat gestur pulang. Beberapa aplikasi menyembunyikan ini dengan meminta beberapa detik tambahan waktu latar belakang, itu sebabnya sebuah unduhan kadang bertahan setelah dilatarbelakangkan hanya selama waktu yang dibutuhkanmu untuk menyadari kalau ia tidak bertahan.
Jawaban yang tepat sifatnya berbeda. iOS menyediakan layanan transfer latar belakang: kamu menyerahkan ke sistem sebuah daftar URL dan tujuan, dan sistem itu sendiri yang melakukan pengunduhan, di prosesnya sendiri, dengan jadwalnya sendiri. Aplikasimu bisa ditangguhkan, dihentikan, atau bahkan sama sekali tidak berjalan — transfernya tetap berlanjut, dan aplikasinya dijalankan ulang di latar belakang saat ada sesuatu yang perlu dilaporkan. Inilah mekanisme di balik setiap unduhan yang bertahan meski layar terkunci, dan memakainya adalah keputusan desain yang dibuat sebuah aplikasi sejak awal, bukan pengaturan yang bisa kamu nyalakan.
Empat mekanisme yang menentukan apakah sebuah unduhan bertahan
- Permintaan range
- Permintaan HTTP yang meminta byte mulai dari 5.000.000 dan seterusnya, bukan seluruh file. Kalau servernya menjawab
206 Partial Content, melanjutkan dari tengah itu mungkin; kalau ia menjawab200 OKdan mulai dari awal, itu tidak mungkin — filenya harus diambil ulang dari nol. - Koneksi paralel
- Membagi satu file menjadi beberapa rentang dan mengambilnya secara bersamaan. Ini membantu karena satu koneksi tunggal sering dibatasi oleh server atau dibatasi oleh latensi round-trip, bukan karena internetmu jadi lebih cepat dengan lebih banyak soket terbuka.
- Offset yang sudah dikomit
- Berapa banyak file yang sudah aman tertulis ke disk, dibandingkan dengan yang masih dalam perjalanan. Unduhan yang dilanjutkan dari byte terakhir yang sudah dikomit itu benar; yang dilanjutkan dari apa yang *dikiranya* sudah diterima menghasilkan file rusak yang baru terungkap berjam-jam kemudian.
- Sesi latar belakang
- Transfer yang dijalankan sistem seperti dijelaskan di atas. Ia lebih lambat memulai, tidak bisa diberi logika kustom sembarangan, dan itulah satu-satunya yang tetap berjalan saat aplikasinya tidak.
Kenapa sebuah unduhan gagal, dan bagaimana bentuk setiap kegagalannya
Kebanyakan laporan "unduhan macet" adalah salah satu dari lima ini, dan mudah dibedakan begitu kamu tahu bentuknya.
| Apa yang kamu lihat | Apa yang sebenarnya terjadi | Apa yang membantu |
|---|---|---|
| Berhenti persis saat kamu meninggalkan aplikasi | Transfernya berjalan di dalam proses, bukan di sesi latar belakang. | Tidak ada yang bisa kamu lakukan dari luar — ini persoalan desain aplikasi. |
| Selalu mulai ulang dari 0% setiap kali | Server mengabaikan range request, jadi tidak ada cara untuk melanjutkan dari tengah. | Koneksi yang stabil, atau file yang lebih kecil. Beberapa host mengizinkan rentang hanya untuk tautan yang ditandatangani. |
| Gagal setelah beberapa menit, berulang kali | Tautannya sudah kedaluwarsa. Banyak host menerbitkan URL yang berlaku hanya lima atau sepuluh menit. | Ambil ulang tautannya dari halamannya dan mulai lagi; yang lama tidak akan pernah berfungsi. |
| Terunduh cepat, lalu filenya tidak bisa dibuka | Yang datang adalah halaman error HTML atau halaman login dengan nama file video. | Periksa ukurannya — "film" 14 KB adalah halaman web. Periksa tautannya sebelum berkomitmen padanya. |
| Sangat lambat meski koneksi cepat | Pembatasan per koneksi di sisi server. | Lebih banyak koneksi paralel, kalau servernya mengizinkan. Kalau ia membatasi berdasarkan alamat IP alih-alih soket, tidak ada yang akan membantu. |
Saat sama sekali tidak ada file untuk diunduh
Sebagian besar video di web tidak disampaikan sebagai file. Ia disampaikan sebagai HLS — sebuah playlist .m3u8 yang mendaftar ratusan segmen kecil, masing-masing beberapa detik, sering pada beberapa tingkat kualitas sehingga pemutar bisa berpindah seiring koneksimu berubah. Tidak ada satu URL tunggal yang menyimpan filmnya, karena filmnya hanya ada sebagai sebuah urutan.
Menyimpannya berarti mengambil setiap segmen lalu remux: menulis stream video dan audio ke dalam kontainer MP4 yang normal. Tidak ada yang dienkode ulang, jadi tidak ada yang hilang dan prosesnya hanya butuh beberapa detik, bukan sepanjang durasi filmnya. Hasilnya adalah file biasa yang bisa diputar di mana saja.
Ini juga sebabnya "unduh stream ini" terasa jauh lebih lambat memulai dibanding mengunduh sebuah file: playlist-nya harus diambil dan diurai, tingkat kualitas dipilih, dan baru setelah itu segmen-segmennya bisa mulai berdatangan. Dan ini juga sebabnya beberapa stream sama sekali tidak bisa disimpan — kalau segmen-segmennya dienkripsi di bawah skema DRM, kuncinya memang sengaja tidak bisa didapatkan, dan tidak ada alat yang menghormati hukum yang bisa melewatinya.
Yang membedakan pengelola unduhan sungguhan dari sekadar tombol unduh
Ia bertahan saat aplikasinya ditutup
Transfer latar belakang diserahkan ke sistem, dengan serah terima yang berlanjut dari byte yang sudah dikomit yang sama alih-alih memulai filenya lagi.
Ia memberitahumu apa isi tautan sebelum kamu berkomitmen
Ukuran, jenis, dan apakah servernya mendukung melanjutkan — semuanya bisa diketahui dari satu permintaan HEAD, dan semuanya berguna sebelum kamu menghabiskan empat gigabyte kuota data.
Ia mengantre, bukan membanjiri
Sepuluh file sekaligus lebih lambat daripada tiga sekaligus, karena setiap koneksi mendapat bagian yang lebih kecil dan kegagalannya berlipat ganda. Antrean dengan batas konkurensi yang masuk akal selesai lebih cepat.
Yang mendarat adalah file biasa
Di folder yang bisa kamu lihat, diberi nama yang masuk akal, bisa diputar oleh apa saja — bukan blob database yang hanya bisa dibuka aplikasi itu.
Kebiasaan yang mencegah kebanyakan masalah unduhan
- Mulai file besar di Wi-Fi dan biarkan layar menyala beberapa detik pertama
Serah terima ke sesi latar belakang terjadi lebih awal; setelah itu layarnya tidak lagi penting.
- Jangan antre dua puluh item sekaligus
Tiga sampai lima transfer bersamaan adalah titik ideal di hampir semua koneksi.
- Periksa ruang kosong sebelum, bukan sesudah
Transfer yang memenuhi disk gagal di 98%, dan iOS mungkin sudah menghapus cache-mu dalam upaya memberi ruang.
- Curigai "selesai" yang instan
Film yang selesai dalam dua detik adalah halaman error. Lihat ukuran filenya.
- Ambil ulang tautan yang kedaluwarsa dari halamannya
Mencoba ulang URL bertanda tangan yang sudah mati akan gagal selamanya, tidak peduli berapa kali aplikasinya mencoba ulang.
Bagaimana ini berbeda antar perangkat
Lingkungan paling ketat: penangguhan agresif dan penyimpanan terbatas. Sesi latar belakang di sini bukan optimisasi, itu satu-satunya yang bekerja.
Aturan yang sama, dengan ruang lebih lega untuk berjalan — dan satu-satunya perangkat iOS di mana koleksi besar bisa dengan wajar mendarat di drive eksternal alih-alih penyimpanan internal.
Tanpa penangguhan sama sekali, jadi transfer panjang berperilaku seperti di komputer desktop mana pun. Batas praktisnya adalah server, bukan sistem operasi.
Pertanyaan yang muncul dari ini
Apakah lebih banyak koneksi selalu berarti unduhan lebih cepat?
Tidak. Itu membantu ketika server membatasi kecepatan setiap koneksi individual, yang umum terjadi. Itu tidak membantu apa-apa ketika batasnya adalah koneksimu sendiri, dan bisa memperburuk keadaan ketika sebuah host menghitung soket per alamat IP dan mulai menolaknya. Suatu tempat antara empat dan delapan adalah rentang yang berguna; tiga puluh justru kontraproduktif.
Bisakah unduhan berlanjut saat layar terkunci?
Bisa, kalau ia sudah diserahkan ke layanan transfer latar belakang sistem. Layar kunci tidak relevan bagi layanan itu — yang penting adalah aplikasinya ditangguhkan, dan inti dari mekanisme ini adalah ia tetap berlanjut apa pun yang terjadi.
Kenapa unduhan saya mulai ulang alih-alih dilanjutkan?
Servernya tidak menghormati range request. Kamu bisa tahu karena progresnya kembali ke nol alih-alih melanjutkan. Beberapa host mendukung rentang hanya pada URL unduhan bertanda tangan mereka, beberapa menonaktifkannya sepenuhnya, dan beberapa menghormatinya untuk file kecil tapi tidak untuk file besar.
Apakah mengonversi stream ke MP4 sama dengan mengenkode ulang?
Tidak. Remuxing memindahkan video dan audio yang ada ke dalam kontainer MP4 tanpa disentuh — lossless, dan cukup cepat untuk selesai dalam hitungan detik. Mengenkode ulang membangun ulang gambarnya dengan codec berbeda dan selalu kehilangan kualitas. Kalau menyimpan stream dua jam butuh waktu dua jam, ada sesuatu yang sedang dienkode ulang padahal tidak perlu.
Bagaimana FoxDL mengunduh
Mesinnya punya dua jalur: satu di dalam proses yang cepat selagi aplikasinya di layar, dan sesi latar belakang sistem yang mengambil alih dari byte yang sama saat tidak.
- Potongan paralel untuk satu file, ditulis langsung ke posisi akhirnya di disk alih-alih ke bagian sementara yang harus digabungkan setelahnya.
- Transfer latar belakang yang tetap berlanjut setelah aplikasinya meninggalkan layar, dan melanjutkan dari offset yang sudah dikomit terakhir — bukan dari byte terakhir yang dikira aplikasinya sudah didapat.
- Melanjutkan setelah terputus, restart, atau dipaksa keluar, asalkan servernya menghormati permintaan range. Kalau tidak, FoxDL mengatakannya dengan jelas alih-alih berputar tanpa henti.
- Stream HLS di-remux ke MP4, sehingga yang mendarat di koleksimu adalah file biasa, bukan folder berisi segmen.
- Pemeriksa unduhan yang melaporkan ukuran, jenis, dan dukungan melanjutkan sebenarnya dari sebuah tautan sebelum kamu memulai.
- Semuanya mendarat di folder normal yang bisa dilihat aplikasi Files.
Jatah gratis berbeda per platform: di iPhone dan iPad ada sejumlah kecil kuota yang bisa ditambah dengan video rewarded singkat yang kamu mulai sendiri; di Mac, yang sama sekali tidak ada iklan, jumlah harian tetap. Pro menghilangkan batasnya di semua perangkat.
Pertanyaan umum
- Apakah unduhan tetap berjalan saat saya keluar dari aplikasi?
- Bisakah unduhan yang terputus melanjutkan dari titik terhenti?
- Bisakah FoxDL mengunduh stream HLS (m3u8)?
- Kenapa unduhan saya lambat, dan bisakah dipercepat?
- Berapa banyak unduhan yang bisa saya lakukan di versi gratis?
Baca terus
Apa yang harus terjadi sebelum sebuah halaman web memberimu filenya
Empat cara sebuah halaman menyajikan video, dan kenapa hanya satu yang berupa file yang bisa kamu simpan.
Di mana sebenarnya file kamu tersimpan di iPhone, dan siapa yang bisa melihatnya
Sandbox, ke mana sebenarnya unduhan pergi, dan kenapa mengganti nama file bisa merusak begitu banyak aplikasi.
Kenapa iPhone-mu membuka satu file video dan menolak yang berikutnya
Kontainer, codec, dan tiga cara menonton file yang ditolak iOS.
Koleksimu, akhirnya ada di satu tempat.
Unduh gratis. Tanpa akun, tanpa daftar — semua fitur ada di versi gratis.