iOS: il browser si arresta in modo anomalo a causa della scarsa memoria

Il mio sito si blocca nel browser a causa della scarsa memoria su iOS. Sto ripetendo un’azione che consuma memoria. Dopo diversi tentativi, il browser si blocca. Tuttavia, quando ho provato lo stesso sito sul mio desktop usando Chrome usando timelime dagli strumenti dev:

  1. Esegui la stessa azione
  2. Raccogli i rifiuti
  3. Tutta la memoria allocata viene raccolta.

Perché il browser si blocca se non ci sono perdite di memoria? C’è un modo per forzare la raccolta dei rifiuti?

Conosci i limiti delle risorse iOS

La tua pagina web che si sta comportando bene sul desktop non garantisce che funzionerà bene su iOS.

1. Tenete presente che iOS utilizza

  • EDGE (larghezza di banda inferiore, latenza più elevata)
  • 3G (maggiore larghezza di banda, maggiore latenza)
  • Wi-Fi (maggiore larghezza di banda, bassa latenza)

per connettersi a Internet.

2. È necessario ridurre al minimo le dimensioni della pagina Web. Compreso

  • immagini non utilizzate o non necessarie
  • CSS
  • JavaScript

che influisce negativamente sul rendimento del tuo sito su iOS.

3. A causa della memoria disponibile su iOS, esistono dei limiti sul numero di risorse che può elaborare:

La dimensione massima per le immagini GIF, PNG e TIFF decodificate

  • 3 megapixel per dispositivi con meno di 256 MB di RAM
  • 5 megapixel per dispositivi con una RAM maggiore o uguale a 256 MB

Ciò garantisce larghezza * altezza ≤ 3 * 1024 * 1024 per dispositivi con meno di 256 MB di RAM

Nota: la dimensione decodificata è molto più grande della dimensione codificata di un’immagine.

La dimensione massima dell’immagine decodificata per JPEG è di 32 megapixel usando il sottocampionamento. Le immagini JPEG possono arrivare a 32 megapixel a causa del sottocampionamento, che consente di decodificare le immagini JPEG in una dimensione che ha un sedicesimo il numero di pixel . Le immagini JPEG di dimensioni superiori a 2 megapixel sono sottocampionate, ovvero decodificate in dimensioni ridotte. Il sottocampionamento JPEG consente all’utente di visualizzare le immagini dalle più recenti fotocamere digitali.

4. La dimensione massima per un elemento canvas è

  • 3 megapixel per dispositivi con meno di 256 MB di RAM
  • 5 megapixel per dispositivi con una RAM maggiore o uguale a 256 MB. L’altezza e la larghezza di un object canvas sono 150 x 300 pixel se non specificato.

5. Tempo di esecuzione di JavaScript

limitato a 10 secondi per ciascun punto di ingresso di livello superiore. Se lo script viene eseguito per più di 10 secondi, Safari su iOS interrompe l’esecuzione dello script in un punto casuale del codice, pertanto potrebbero verificarsi conseguenze indesiderate .

6. Il numero massimo di documenti che possono essere aperti contemporaneamente è

  • otto su iPhone

  • nove su iPad.

Per maggiori informazioni, consultare Sviluppo del contenuto Web per la documentazione di Safari-Apple .

Raccolta dei rifiuti

L’implementazione mobile safari javascript non ha alcun comando come CollectGarbage () in internet explorer per la garbage collection.

Ci sono tre eventi che attiveranno la garbage collection in mobile safari ( Reference ).

  • Scade un timer dedicato alla raccolta dei rifiuti
  • Un’allocazione si verifica quando tutti i CollectorBlocks di un heap sono pieni.
  • Viene assegnato un object con spazio di archiviazione associato sufficientemente grande.

È davvero una ctriggers pratica triggersre la garbage collection. Quello che dovremmo fare è scrivere codici che non perdano memoria.

Si riferiscono alla gestione della memoria in Javascript

Di seguito è la migliore risorsa (con parametri di riferimento) che abbia mai incontrato, che lo spiega: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Mi sono imbattuto in questi ostacoli delle prestazioni poche settimane fa, e tieni presente che iOS non dispone di alcuna garbage collection predefinita (l’articolo spiega perché). È responsabilità dell’app (in questo caso, l’app del browser). Non puoi raccogliere rifiuti tramite la tua app web. Un piccolo consiglio mentre ottimizzi il tuo sito web per iOS (per evitare arresti anomali): evita le transizioni CSS.

Anche se ti consiglierei di prendere una tazza di caffè e leggere l’articolo completo, ma lo incollerò qui sotto:

  • Javascript è troppo lento per l’utilizzo di app per dispositivi mobili nel 2013 (ad esempio per il fotoritouch, ecc.).
    • È più lento del codice nativo di circa 5
    • È paragonabile a IE8
    • È più lento di x86 C / C ++ di circa 50
    • È più lento del lato server Java / Ruby / Python / C # di un fattore di circa 10 se il tuo programma si adatta a 35MB, e degrada esponenzialmente da lì
  • Il percorso più praticabile per farlo diventare più veloce è spingere l’hardware a prestazioni a livello desktop. Questo potrebbe essere praticabile a lungo termine, ma sembra un’attesa piuttosto lunga.
  • Il linguaggio in sé non sembra essere più veloce in questi giorni e le persone che ci stanno lavorando dicono che con il linguaggio e le API attuali, non sarà mai veloce come il codice nativo
  • La raccolta dei dati inutili è esponenzialmente negativa in un ambiente con vincoli di memoria. È molto, molto peggio di quanto non sia negli ambienti desktop-class o server-class.
  • Ogni sviluppatore mobile competente, indipendentemente dal fatto che utilizzi o meno un ambiente GCed, trascorre molto tempo a pensare alle prestazioni della memoria del dispositivo di destinazione
  • JavaScript, così com’è attualmente, è fondamentalmente contrario a consentire anche agli sviluppatori di pensare alle prestazioni della memoria del dispositivo di destinazione
  • Se hanno cambiato idea e hanno permesso agli sviluppatori di pensare alla memoria, l’esperienza suggerisce che si tratta di un problema tecnicamente difficile.