Costrutti/modelli JavaScript da evitare su iOS Safari?

Question

Ho un'app Web che contiene un'enorme quantità di JavaScript generato. Il consumo di memoria varia di un fattore 6 tra l'esecuzione dell'applicazione Web in Chrome su un desktop rispetto all'esecuzione dell'applicazione Web in un UIWebView su un iPad (aggiornato).

Quali costrutti o modelli dovrei evitare di ottenere il consumo di memoria su iOS alla pari con quello di Chrome?

Caratterizzazione del JavaScript generato:

• Il codice è generato da Haxe.
• Il codice è "orientato agli oggetti" in quanto fa un uso pesante di prototype, ma in un civilized way.
• Il codice fa un uso pesante degli indici denominati sugli oggetti JavaScript per implementare le tabelle hash.
• Ci sono molte stringhe, ma quasi nessuna concatenazione di stringhe.

Non sembrano esserci perdite di memoria; l'eccessivo consumo di memoria su iOS viene visualizzato immediatamente dopo la costruzione degli oggetti Javascript (set fisso di).

Answer 1

Un potenziale modo per provare a ottimizzare il codice è tramite GWT (il cui compilatore, credo, è un compilatore più ottimizzato rispetto al compilatore js di haxe).

Vorrei prima compilare tutto il codice haxe in java, quindi convertirlo in js tramite GWT e verificare se i requisiti di memoria rimangono ugualmente alti.

Se si converte in java, quindi in GWT è troppo difficile, un'approssimazione ravvicinata consiste nell'utilizzare il compilatore di chiusura di google sul javascript risultante generato tramite haxe. Non sono sicuro che haxe sia in grado di emettere javascript in un modo compatibile con la modalità ADVANCED_OPTIMIZATION (https://developers.google.com/closure/compiler/docs/compilation_levels#advanced_optimizations), che è ciò che dovresti fare (in caso contrario, la chiusura non è migliore di un semplice minimizzatore di codice).

Answer 2

Hai detto che sta usando molto del prototipo. Questo potrebbe essere un motivo: se pensi che i tuoi oggetti possano condividere lo stesso prototipo, prova a farlo; Per esempio:

baz.Bar = function() { 
    // constructor 
}; 

baz.Bar.prototype = { 
    fooProp: ["bar", "foo"], 
    foo : function(){ 
     //method 
    } 
}; 

baz.Bar2.prototype = baz.Bar.prototype; 

Si noterà baz.Bar2.prototype sta puntando baz.Bar.prototype. Con questo concetto, è possibile salvare la memoria da allocare da baz.Bar2 perché condivide da baz.Bar.

Answer 3

Dato che il codice funziona bene sul desktop, probabilmente è un po 'sottinteso in iOS. Quale dubito che tu possa aggiustare usando un modo di programmazione più orientato agli oggetti. Certo questo potrebbe ridurre l'occupazione di memoria un po ', ma non di un fattore 6.

UIWebView è abbastanza noto per la creazione di perdite di memoria si potrebbe tentare di utilizzare la più recente (iOS 8+) WKWebView ha molto meglio garbage collection.

Apple WKWebView Reference

Answer 4

il mio suggerimento è che si guarda nella parte DOM della vostra applicazione. Non penso ci sia molta ottimizzazione che può essere fatta nella tua struttura JavaScript. Il collegamento debole in mobile/tablet è solitamente il processo di rendering. Se il tuo obiettivo è ridurre il consumo di memoria, puoi cambiare il modo in cui il tuo DOM funziona. cerca di mantenere come minimo i nodi DOM possibili, nascondi il contenuto (nodo-contenuto) di nodi DOM nascosti. questo tipo di manipolazioni DOM, mi ha aiutato in passato a rendere la mia app Web più reattiva e a mantenere l'utilizzo della memoria il più basso possibile.

virtuale di scorrimento, è qualcosa di utile per mantenere il DOM più piccolo possibile, virtual-scroll