Inizio Blog User Interface (YUIBlog)

Mobile Browser Limiti Cache: Android, Ios, e webOS

Aggiornamento (12 luglio 2010): Mentre i risultati descritti in questo articolo sono accurate per le pagine HTML, nuovi test hanno rivelato cache di limiti differenti per molto e JS risorse CSS. I risultati aggiornati sono descritti nel Mobile Browser limiti della cache, Revisited .

All'inizio del 2008, Wayne Shea e Tenni Theurer ha scritto un post sul blog di YUI su Cache per iPhone in cui hanno condiviso i risultati della ricerca in varie caratteristiche e le limitazioni di cache di Safari Mobile di iPhone OS 1.x. Tra le altre cose, hanno scoperto che i singoli componenti più grande di 25KB non sono stati memorizzati nella cache, e che vi era una dimensione massima di cache complessiva compresa tra 475kb e 500KB.

Molto è cambiato da allora. Abbiamo visto due nuove uscite principali ea molte minor release di iPhone OS (ora IOS), e molti altri dispositivi mobili dotati di browser in grado altamente sono apparsi per sfidare l'iPhone. Stoyan Stefanov trovato, alla fine del 2009, che limita la cache iPhone l'aveva cambiato (purtroppo in peggio). Ma dove stanno le cose ora? E per quanto riguarda i browser non-IO?

Sfondo

I browser sono due tipi di cache che siamo interessati ai fini di queste prove:

• La cache componente, o un oggetto di cache, i file singoli negozi. HTML, CSS, JavaScript, e le immagini vanno tutte nella cache del componente. Ogni volta che ha bisogno di uno di questi componenti, il browser prima controlla la cache prima di fare una richiesta di rete.
• La cache di pagina, nota anche come la parte posteriore / cache avanti, negozi di una pagina intera e tutti i suoi componenti, nonché il loro stato attuale. Quando si utilizza il tasto indietro o in avanti, il browser carica la pagina dalla cache della pagina se possibile.

La cache dell'applicazione HTML5 è un altro tipo di cache che è ampiamente supportato dai browser mobili. i produttori di browser già fare un buon lavoro di documentare i limiti della cache dell'applicazione, quindi non ha incluso nel mio test. Maggiori informazioni sulla cache di applicazione in seguito.

Dispositivi testati

Ho testato il browser mobile seguenti combinazioni di piattaforma:

• Android 2.1 (Nexus One)
• Safari Mobile su iOS 3.1.3 (iPhone prima generazione)
• Safari Mobile su iOS 3.2 (iPad)
• Safari Mobile su iOS 4.0 (iPhone 3G)
• Safari Mobile su iOS 4.0 (iPhone 4)
• webOS 1.4.1 (Palm Pre Plus)

Nota: Con l'eccezione di Safari Mobile su iOS 4.0, ho provato un solo dispositivo in ogni categoria. Se ci sono variazioni tra i singoli dispositivi o le differenze sulla base di software installato al di là del sistema operativo, il mio test non rilevare tali variazioni. Questi dispositivi sono stati testati soprattutto perché sono quelli che ho avuto accesso, non perché li considerano più importante di altri dispositivi.

Metodologia

test Cache è noioso, ma relativamente semplice.

Ho scritto un piccolo app Sinatra ( forcella sul GitHub! ) che genera una risposta consistente in un numero minimo di alfanumerici e spazi byte pseudocasuali. Le risposte possono essere serviti sia gzip o non compresso. Il seguente lontano futuro intestazioni di risposta di scadenza sono inviate per garantire che tutte le risposte sono considerati cacheable:

 Cache-Control: max-age = 315360000
 Scade: Fri, 1 maggio 2020 03:47:24 GMT

Sopra la mia rete locale, ho poi eseguita manualmente le seguenti operazioni su ogni dispositivo per testare la cache del componente:

1. Caricare la pagina di test della cache dell'indice.
2. Toccare un collegamento a un componente di una particolare dimensione, che vanno da 5 KB a 20 MB, e attendere che sia terminato il caricamento.
3. Toccare il pulsante Indietro.
4. Toccare il collegamento stesso. Osservare se i caratteri casuali sono gli stessi, e se il server console stampe una voce di registro per una richiesta, per determinare se il componente è stato memorizzato nella cache al punto 2.
5. Ripetere e regolare le dimensioni del componente necessario per determinare la dimensione massima dei componenti che verranno memorizzati nella cache.

Per testare la cache di pagina, mi sono esibito in sostanza la stessa procedura solo che invece di toccare di nuovo il link al punto 4, ho sfruttato pulsante Avanti del browser, facendo in modo da utilizzare la cache della pagina, piuttosto che la cache del componente.

Il supporto per ETag e Last-Modified è stato determinato dal ritocco dei server per inviare la appropriato ETag o Last-Modified header di risposta (in test separati), e di omettere il futuro scadenza headers-lontano. Poi ho controllato le intestazioni richiesta ricevuta dal server per verificare che il browser ha l'atteso If-None-Match o If-Modified-Since header al punto 4.

Risultati

Ho provato con gzip sia attivato e disattivato, ma ho scoperto che gzip ha avuto alcun effetto sul cacheability su qualsiasi dispositivo. Il formato non compresso componente è ciò che conta in ogni caso, indipendentemente dal fatto che tale componente è servita gzip. In quanto tale, tutte le dimensioni dei componenti qui menzionati non sono compressi dimensioni.

La tabella sottostante illustra i miei risultati complessivi.

Android

Il browser di Android esibito il comportamento migliore cache di tutti i dispositivi testati. Mentre sembra imporre alcun limite alle dimensioni dei singoli componenti, la dimensione della cache totale sembra essere limitato a circa 2 MB, il che significa che i singoli componenti siano effettivamente limitate a 2MB pure.

La cache di pagina è apparso a non porre alcun limite alle dimensioni delle singole pagine, felicemente caching ogni byte ho buttato a farlo finché la RAM disponibile è stata esaurita e il browser si è bloccato.

Sono stato piacevolmente sorpreso di scoprire che la cache componente Android è sopravvissuto sia riavvio del browser e cicli di potenza, una prodezza nessuno dei dispositivi iOS è stato in grado di eguagliare.

Possibile avvertimento: Una rassegna di source WebKit albero Android mi porta a credere che i suoi limiti cache può adattare in base alla quantità di RAM e / o la memoria flash disponibile sul dispositivo specifico per il quale è in esecuzione. Se fosse vero, questi numeri possono essere applicabili al Nexus One. Infatti, se la dimensione della cache si adatta in base alla memoria inutilizzata piuttosto che di memoria totale, questi numeri possono essere applicabili alla mia Nexus One.

Potrei sbagliarmi, ma le differenze di 4,0 iOS risultati dei test su l'iPhone 3GS e iPhone 4 supportano questa teoria. (Android e Mobile Safari sono entrambi i browser WebKit-based, in modo che questo comportamento può avere in comune.) Se si ha familiarità con la fonte di WebKit e può far luce su questo, si prega di mettersi in contatto con me.

iOS

Risultati varia selvaggiamente tra i tre più recenti versioni di IOS. Sorprendentemente, Mobile Safari 3.1.3 a Ios non ha componenti di cache di qualsiasi dimensione, nonostante l'apparentemente illimitata dimensione della cache di pagina. Questo è preoccupante perché significa iOS 3.1.3 gli utenti possono ottenere una ottimale esperienza di navigazione, soprattutto se non si utilizza wifi. La dimensione della cache illimitato pagina fa poco bene qui, dal momento che entra in gioco solo per la parte posteriore / navigazioni in avanti. Questo comportamento è un cambiamento significativo da ciò che gli altri osservato nelle precedenti versioni di IOS e non riesco ad immaginare alcuna buona ragione per farlo, quindi ho il sospetto che questo può essere un bug.

Safari Mobile su iOS 3.2 (che è disponibile solo sul iPad) non presenta questo bug. Il suo limite componente 25.6KB e ~ 281.6KB limite di cache totale sono meglio di niente, ma loro sembrano ancora irrisorio rispetto agli altri dispositivi testati. Unica tra iOS dispositivi, il iPad sembra limitare le dimensioni delle pagine nella cache di pagina a 25.6KB, lo stesso che il suo limite di dimensione dei componenti.

Safari Mobile su iOS 4,0 esposti diversi limiti sul iPhone 3GS e su iPhone 4, il che implica che i limiti di adattare sulla base di RAM disponibile (l'iPhone 3G ha 256MB mentre l'iPhone 4 ha 512 MB, entrambi i dispositivi testati avevano 32GB di memoria flash) . Sulla iPhone 3GS, IOS 4.0 ha una 51.199KB limite di dimensione e di una componente ~ 1.05MB componente dimensione totale della cache.

Su iPhone 4, il limite di dimensione dei componenti era quasi esattamente due volte il limite per l'iPhone 3GS, a 102.399KB. Il totale dimensione della cache del componente è stata di circa 1.9MB. Forse perché iOS 3,2 e 4,0 iOS sono stati sviluppati separatamente, ma ramificata da un antenato comune, IOS 4,0 dimensione della cache pagina sembra essere limitata solo dalla RAM disponibile su entrambi i dispositivi testati, proprio come iOS 3.1.3.

Nessuno dei dispositivi iOS conservato il contenuto della cache del browser attraverso riavvio forzato o cicli di alimentazione del dispositivo, anche se ha mantenuto la cache quando solo le applicazioni di commutazione senza realmente uccidere il browser.

webOS

I miei risultati dei test su webOS erano così inconsistenti che ho poca fiducia in loro. Ho incluso quel poco che i dati sono riuscito a raccogliere puramente per motivi di completezza. Si prega di prendere con un grano di sale pesante.

Il più vicino sono stato in grado di determinare, webOS potrebbe avere un limite di dimensione individuale componente di circa 1 MB, con una pagina limite di dimensione corrispondente nella cache di pagina. Non sono riuscito a convincere If-None-Match o If-Modified-Since header di richiesta di webOS, il che implica che non supporta ETag e Last-Modified .

In alcuni test, è risultato che gli componente webOS dimensione massima è superiore a 1 MB, ma questo è stato inconsistente. Per quanto posso dire, webOS sembra avere un brutto bug dove, dopo un certo punto, forse quando la dimensione massima della cache totale è raggiunto, la cache del proprio completamente smette di funzionare del tutto fino a quando il telefono è spento e riacceso. In alcuni casi, anche in bicicletta potere non ha fissato la rottura di cache, per cui alla fine ho rinunciato a stabilire la causa esatta del problema e gli esatti limiti della cache webOS.

Raccomandazioni

Sulla base di questi risultati, offro le seguenti raccomandazioni per chiunque lo sviluppo di applicazioni web per i dispositivi testati:

• Usare lontano futuro headers scadenza della cache. Questo eviterà che il browser di dover inviare una richiesta GET condizionale e migliorerà cacheability in webOS, che non supporta ETag or Last-Modified .
• Almeno fino a quando iOS 4,0 arriva sul iPad, cercano di limitare le dimensioni dei singoli componenti a 25.6KB o meno, non compresso. E sollecitare gli utenti iPhone per eseguire l'aggiornamento a 4,0 iOS il più presto possibile.
• Se il tuo sito web deve supportare iOS 3.1.3 utenti (il che è probabile), se lo richiede componenti più grande di 25.6KB, o se la dimensione totale di tutti i componenti è più grande di 281.6KB, considerare l'uso della cache dell'applicazione HTML5, localStorage , o archiviazione di database per memorizzare i vostri componenti. Alex Kessinger recente post sul blog di YUI, un'introduzione all'uso di YUI 3 in applicazioni off-line , potrebbe essere di interesse per YUI 3 sviluppatori di considerare questo approccio.
• Fate il vostro test personale. Non dare per scontato che questi risultati si applicano a qualsiasi versione futura di uno dei browser testati o dispositivi. Utilizzare questi risultati come punto di partenza, ma verificare voi stessi prima di prendere importanti decisioni basate su ipotesi relative limitazioni cache mobile. Il cellulare cambia browser mondo a un ritmo fulmine, per cui questa ricerca avrà una durata molto breve.

Ho fatto il mio codice di prova disponibili su GitHub e vi incoraggio ad usarlo, forcella, e condividere ciò che si impara.

Invito a presentare documentazione

i produttori di browser, si prega di prendere in considerazione la documentazione e la pubblicazione dei limiti cache del browser. Nel mondo desktop in cui tali limiti sono tipicamente così alto da essere un non-problema, la documentazione non era necessario. Nel mondo mobile, i limiti della cache del browser sono informazioni vitali che gli sviluppatori web devono avere, al fine di creare siti web performanti con caratteristiche interessanti.

I limiti di nuove caratteristiche come localStorage e la cache di applicazione sono in genere ben documentate. La prego di estendere questo livello di documentazione alla cache componente pure.

Trova conversazioni: bloglines | technorati

Condividi e ampliare: Bookmark con del.icio.us | digg it! | reddit!