Hva en nedlastingsbehandler gjør som en nettleser ikke vil
En fire-gigabyte-fil, nitti prosent ferdig, og så et telefonanrop — eller bare en låst skjerm — og den er borte. Dette er den vanligste klagen om nedlasting på iOS, og det er ikke en feil. Det er operativsystemet som gjør nøyaktig det det ble designet for å gjøre, og grunnen til at en egen klasse apper finnes.
- 30s Omtrent hvor lenge en suspendert app fortsetter å kjøre før iOS stopper den
- 206 HTTP-statusen som gjør gjenopptaking mulig i det hele tatt
- 1 byte Hvor mye av en riktig gjenopptatt overføring som lastes ned på nytt
Hvorfor overføringen stopper når du bytter app
iOS lar ikke en app fortsette å jobbe bare fordi den skulle ønske det. Når du forlater en app, suspenderes den innen sekunder, og en suspendert app har ingen CPU-tid, ingen nettverkssockets og ingen måte å legge merke til at den er stoppet. Alt den holdt i minnet er fortsatt der, men frosset — og hvis systemet trenger minnet, avsluttes appen rett og slett uten å bli fortalt.
En nedlasting som kjører på en vanlig tilkobling inni appen tar derfor slutt ved hjem-gesten. Noen apper skjuler dette ved å be om noen ekstra sekunder med bakgrunnstid, som er hvorfor en nedlasting noen ganger overlever å bli bakgrunnet nøyaktig så lenge det tar deg å legge merke til at den ikke gjorde det.
Det riktige svaret er annerledes av natur. iOS tilbyr en bakgrunnsoverføringstjeneste: du gir systemet en liste med URL-er og mål, og systemet gjør selve nedlastingen, i sin egen prosess, på sin egen tidsplan. Appen din kan være suspendert, avsluttet, eller ikke kjøre i det hele tatt — overføringen fortsetter, og appen relanseres i bakgrunnen når det er noe å rapportere. Dette er mekanismen bak hver nedlasting som overlever en låst skjerm, og å bruke den er en designbeslutning en app tar på forhånd, ikke en innstilling du kan slå på.
De fire mekanikkene som avgjør om en nedlasting overlever
- Range-forespørsel
- En HTTP-forespørsel som ber om byte 5 000 000 og utover i stedet for hele filen. Hvis serveren svarer
206 Partial Content, er gjenopptaking fra midten mulig; hvis den svarer200 OKog starter fra begynnelsen, er det ikke det — filen må hentes på nytt fra null. - Parallelle tilkoblinger
- Å splitte én fil i flere områder og hente dem samtidig. Det hjelper fordi én tilkobling ofte strupes av serveren eller begrenses av rundtur-forsinkelse, ikke fordi internettet ditt er raskere med flere sockets åpne.
- Forpliktet offset
- Hvor mye av filen som er trygt skrevet til disk, i motsetning til fortsatt underveis. En nedlasting som gjenopptas fra den sist forpliktede byten er korrekt; én som gjenopptas fra det den *tror* den mottok produserer en korrupt fil som først avslører seg timer senere.
- Bakgrunnsøkt
- Den systemdrevne overføringen beskrevet ovenfor. Den er tregere å starte, kan ikke gis vilkårlig egendefinert logikk, og er det eneste som fortsetter å kjøre når appen ikke gjør det.
Hvorfor en nedlasting feiler, og hvordan hver feil ser ut
De fleste «fastlåst nedlasting»-rapporter er én av disse fem, og de er lette å skille fra hverandre når du kjenner formen.
| Hva du ser | Hva som faktisk skjer | Hva som hjelper |
|---|---|---|
| Stopper i det øyeblikket du forlater appen | Overføringen kjørte inn-prosess, ikke i en bakgrunnsøkt. | Ingenting du kan gjøre utenfra — dette er et appdesignproblem. |
| Starter på nytt fra 0 % hver gang | Serveren ignorerer range-forespørsler, så det er ingen måte å fortsette fra midten. | En stabil tilkobling, eller en mindre fil. Noen verter tillater ranges bare for signerte lenker. |
| Feiler etter noen minutter, gjentatte ganger | Lenken har utløpt. Mange verter utsteder URL-er gyldige i fem eller ti minutter. | Hent lenken på nytt fra siden dens og start på nytt; den gamle vil aldri fungere. |
| Laster ned raskt, men filen vil ikke åpnes | Det som ankom var en HTML-feilside eller en påloggingsside med et videofilnavn. | Sjekk størrelsen — en 14 KB «film» er en nettside. Inspiser lenken før du forplikter deg til den. |
| Veldig treg til tross for en rask tilkobling | Per-tilkobling-struping i serverenden. | Flere parallelle tilkoblinger, hvis serveren tillater dem. Hvis den setter tak per IP-adresse heller enn per socket, vil ingenting hjelpe. |
Når det ikke er noen fil å laste ned i det hele tatt
En stor del av videoen på nettet leveres ikke som en fil. Den leveres som HLS — en .m3u8-spilleliste som lister hundrevis av små segmenter, noen sekunder hver, ofte på flere kvalitetsnivåer så spilleren kan bytte etter hvert som tilkoblingen din endrer seg. Det finnes ingen enkelt URL som holder filmen, fordi filmen bare finnes som en sekvens.
Å lagre én betyr å hente hvert segment og deretter remukse dem: skrive video- og lydstrømmene inn i en vanlig MP4-container. Ingenting re-kodes, så ingenting går tapt og det tar sekunder heller enn lengden på filmen. Resultatet er en vanlig fil som spiller hvor som helst.
Dette er også hvorfor «last ned denne strømmen» tar merkbart lengre tid å starte enn å laste ned en fil: spillelisten må hentes og tolkes, et kvalitetsnivå velges, og først da kan segmentene begynne å ankomme. Og det er hvorfor noen strømmer ikke kan lagres i det hele tatt — hvis segmentene er kryptert under en DRM-ordning, er nøklene bevisst ikke oppnåelige, og ingen verktøy som respekterer loven kommer forbi det.
Hva som skiller en ekte nedlastingsbehandler fra en nedlastingsknapp
Den overlever at appen lukkes
Bakgrunnsoverføringer overlevert til systemet, med en overlevering som fortsetter fra samme forpliktede byte heller enn å starte filen på nytt.
Den forteller deg hva en lenke er før du forplikter deg
Størrelse, type og om serveren støtter gjenopptaking — alt kan vites fra en enkelt HEAD-forespørsel, og alt nyttig før du bruker fire gigabyte av en dataplan.
Den setter i kø heller enn å oversvømme
Ti filer samtidig er tregere enn tre om gangen, fordi hver tilkobling får en mindre andel og feilene mangedobles. En kø med en fornuftig samtidighetsgrense blir ferdig raskere.
Det som lander er en vanlig fil
I en mappe du kan se, fornuftig navngitt, spillbar av hva som helst — ikke en databaseblob bare den appen kan åpne.
Vaner som forhindrer de fleste nedlastingsproblemer
- Start store filer på Wi-Fi og la skjermen være på de første sekundene
Overlevering til bakgrunnsøkten skjer tidlig; etter det spiller skjermen ikke lenger noen rolle.
- Ikke sett tjue elementer i kø samtidig
Tre til fem samtidige overføringer er det søte punktet på nesten enhver tilkobling.
- Sjekk ledig plass før, ikke etter
En overføring som fyller disken feiler ved 98 %, og iOS har kanskje allerede tømt cachen din i et forsøk på å skape plass.
- Behandle en umiddelbar «fullført» med mistanke
En film som ble ferdig på to sekunder er en feilside. Se på filstørrelsen.
- Hent utløpte lenker på nytt fra siden deres
Å prøve en død signert URL på nytt vil feile for alltid, uansett hvor mange ganger appen prøver igjen.
Hvordan dette er ulikt på tvers av enheter
Det strengeste miljøet: suspendering er aggressiv og lagringen er trang. Bakgrunnsøkter er ikke en optimalisering her, de er det eneste som fungerer.
De samme reglene, med mer plass å kjøre — og den ene iOS-enheten der et stort bibliotek rimelig kan havne på en ekstern disk i stedet for intern lagring.
Ingen suspendering i det hele tatt, så lange overføringer oppfører seg slik de gjør på en hvilken som helst datamaskin. Den praktiske grensen er serveren, ikke operativsystemet.
Spørsmål dette reiser
Betyr flere tilkoblinger alltid en raskere nedlasting?
Nei. De hjelper når en server begrenser hastigheten på hver enkelt tilkobling, som er vanlig. De gjør ingenting når grensen er din egen tilkobling, og de kan gjøre ting verre når en vert teller sockets per IP-adresse og begynner å avvise dem. Et sted mellom fire og åtte er det nyttige området; tretti er kontraproduktivt.
Kan en nedlasting fortsette mens skjermen er låst?
Ja, hvis den ble overlevert til systemets bakgrunnsoverføringstjeneste. Låseskjermen er irrelevant for den tjenesten — det er at appen blir suspendert som betyr noe, og hele poenget med mekanismen er at den fortsetter uansett.
Hvorfor starter nedlastingen min på nytt i stedet for å gjenoppta?
Serveren respekterte ikke range-forespørselen. Du kan se det fordi fremdriften går tilbake til null i stedet for å fortsette. Noen verter støtter ranges bare på sine signerte nedlastings-URL-er, noen deaktiverer dem helt, og noen få respekterer dem for små filer men ikke store.
Er å konvertere en strøm til MP4 det samme som å re-kode den?
Nei. Remuksing flytter den eksisterende videoen og lyden inn i en MP4-container urørt — tapsfritt, og raskt nok til å bli ferdig på sekunder. Re-koding bygger bildet på nytt med en annen kodek og mister alltid kvalitet. Hvis det å lagre en to timer lang strøm tar to timer, re-koder noe når det ikke trengte å gjøre det.
Hvordan FoxDL laster ned
Motoren har to spor: ett inn-prosess-spor som er raskt mens appen er på skjermen, og systemets bakgrunnsøkt som overtar fra samme byte når den ikke er det.
- Parallelle biter for én fil, skrevet rett inn i sin endelige posisjon på disk heller enn inn i midlertidige deler som må sammenføyes etterpå.
- Bakgrunnsoverføringer som fortsetter etter at appen forlater skjermen, og fortsetter fra den sist forpliktede offseten — ikke fra den siste byten appen trodde den hadde.
- Gjenoppta etter et fall, en omstart eller en tvungen avslutning, forutsatt at serveren respekterer range-forespørsler. Når den ikke gjør det, sier FoxDL det heller enn å gå i loop.
- HLS-strømmer remukset til MP4, så det som havner i biblioteket er en vanlig fil, ikke en mappe med segmenter.
- En nedlastingsinspektør som rapporterer den ekte størrelsen, typen og gjenopptakingsstøtten til en lenke før du starter.
- Alt havner i en vanlig mappe som Filer-appen kan se.
Gratisgrenser varierer etter plattform: på iPhone og iPad et lite antall pass fylt opp med en kort belønnet video du starter selv; på Mac, der det ikke er annonsering i det hele tatt, et fast daglig antall. Pro fjerner grensen på hver enhet.
Vanlige spørsmål
- Fortsetter nedlastinger når jeg forlater appen?
- Kan en avbrutt nedlasting gjenopptas der den stoppet?
- Kan FoxDL laste ned en HLS (m3u8)-strøm?
- Hvorfor er nedlastingen min treg, og kan jeg gjøre den raskere?
- Hvor mange nedlastinger kan jeg gjøre i gratisversjonen?
Les mer
Hva som må skje før en nettside gir deg filen sin
De fire måtene en side leverer video på, og hvorfor bare én av dem er en fil du kan beholde.
Hvor filene dine faktisk bor på en iPhone, og hvem som kan se dem
Sandkassen, hvor nedlastinger faktisk går, og hvorfor å gi en fil nytt navn ødelegger så mange apper.
Hvorfor iPhonen din åpner én videofil og nekter den neste
Containere, kodeker, og de tre måtene å se en fil iOS nekter å åpne.
Biblioteket ditt, endelig på ett sted.
Gratis nedlasting. Ingen konto, ingen registrering — hele funksjonssettet er i gratisversjonen.