Tecniche per la profilazione della memoria nel desktop Safari e iOS?

Question

Aggiornamento 10/21: Titolo e domanda modificati per poter ottenere una risposta (diversa da "no").

Stiamo riscontrando perdite in Safari (confermato in Windows e Mac, sospetto in iOS). Esistono estensioni Safari che consentono a un profilo di utilizzo della memoria JavaScript/DOM di rilevare potenziali perdite? Ancora meglio, c'è qualche strumento che può essere utilizzato su iOS o nell'emulatore Apple iOS? Quali sono le tecniche suggerite per scoprire cosa potrebbe causare perdite di memoria in JavaScript/DOM in Safari? E qualcuno sa di QUALSIASI modo per accedere alle informazioni sulla memoria per iOS?

Sfondo

Stiamo sviluppando un'applicazione web Safari iOS che utilizza la pagina singola app paradigma, il caricamento di 100s di immagini a schermo intero. Abbiamo superato il normale limite di immagini iOS di 6.5 MB ripristinando la sorgente per i tag immagine, ma ora ci imbattiamo in quella che ritengo sia una perdita di memoria in iOS Safari. Dopo aver caricato ~ 250-300 immagini, iOS Safari interrompe semplicemente il caricamento delle immagini, a causa di ciò che sospettiamo sia una perdita di memoria. Non sorprende, dato che la stessa perdita appare sia in Safari per Windows che in Safari per Mac: su Windows è particolarmente brutto; per ogni nuova immagine ad alta risoluzione a schermo intero, vengono consumati altri 10-15 MB di memoria, se si passa a immagini a bassa risoluzione continua a divorare ~ 5 MB per immagine.

In Windows abbiamo isolato la perdita per il semplice atto di rendering dell'immagine nella finestra del browser: abbiamo una sequenza di immagini e persino con la manipolazione DOM zero, semplicemente traducendo (3d) l'immagine attraverso il viewport , la memoria è allocata e mai rilasciata. Su Windows, il consumo di memoria può aumentare rapidamente a ~ 1,5 GB, a quel punto Safari si blocca semplicemente. Su Mac non è così male, ma la memoria salta facilmente da 100 MB all'inizio a 500 MB e oltre. In confronto, una scheda/processo Chrome che ospita la stessa pagina cresce da circa 33 MB a ~ 120 MB e quindi si stabilizza.

tentato Soluzioni alternative

Abbiamo provato a cancellare i singoli tag immagine e sostituendo l'immagine segnaposto con piuttosto che resettare, ma questo non sembra per alleviare il problema, e causa anche problemi di prestazioni, presumibilmente a causa a DOM churn. È interessante notare che l'eliminazione/scollegamento di TUTTE le immagini funziona - non appena il comando viene eseguito, la memoria viene rilasciata. Tuttavia, questo causa i suoi problemi, la gestione dello stato dell'interfaccia utente e la creazione del backup del carosello richiede anche una notevole quantità di tempo. L'aggiornamento della pagina è un'altra soluzione, ma ciò causa ancora più interruzioni nell'UD.

Aggiornamento 04/10: Solo un aggiornamento su quello che abbiamo finito per fare: iOS 4.2 ha introdotto una limitazione che taglia fuori un 3D trasforma Div a 122,900 pixel. Non so perché, ma ci ha costretti a riprogettare e ad andare con una giostra dinamica al posto della precedente pellicola statica.

In secondo luogo, abbiamo scoperto che l'utilizzo di div con immagini di sfondo funziona meglio delle immagini stesse. Sembra un altro bug in Safari o, al massimo, un'implementazione di limitazione incoerente.

aggiornamento fine

Pensieri? Se hai riscontrato sospetti danni in Safari, qual è stato il tuo approccio a risolverli?

Answer 1

Quando si installa iOS SDK, viene installata anche un'utilità denominata Instruments. Può tenere traccia di tutti i tipi di statistiche di utilizzo, inclusa la memoria (esiste persino un modello "Leaks"). Il bello è che può tenere traccia sia del simulatore iPhone/iPad sia di qualsiasi dispositivo di sviluppo iOS connesso. Naturalmente, può anche essere usato per monitorare l'utilizzo della memoria in Mac OS, quindi può essere d'aiuto anche con Safari. Puoi trovare strumenti in/Sviluppatore/Applicazioni.

Un'altra cosa utile è che ogni volta che sincronizzi il tuo iPad/iPhone con iTunes, sincronizza anche i rapporti sugli arresti anomali dal dispositivo al computer. Possono essere trovati in ~/Library/Logs/CrashReporter/MobileDevice/[Nome dispositivo] /.

Una cosa che abbiamo riscontrato durante lo sviluppo per l'iPad in particolare era che era molto soggetto a crash a causa di problemi di memoria, in particolare in applicazioni pesanti come la nostra. Una cosa che abbiamo imparato è che la semplice rimozione di un elemento DOM non significa che l'elemento sarà spazzato via dal browser. Abbiamo trovato che l'impostazione dell'immagine src (o dell'immagine di sfondo, se si trattava di un div) in una stringa vuota prima di rimuoverla dal DOM ha aiutato immensamente.

Non sono sicuro che tutto ciò sia d'aiuto, ma speriamo che gli strumenti attivi e funzionanti ti forniscano un'idea migliore di dove sta andando tutta quella memoria.