JavaScript-Konstrukte/-Muster, die auf iOS Safari zu vermeiden sind?

Question

Ich habe eine Web-App, die eine große Menge an generiertem JavaScript enthält. Der Speicherverbrauch unterscheidet sich zwischen dem Ausführen der Web-App in Chrome auf einem Desktop und dem Ausführen der Web-App in einem UIWebView auf einem (aktualisierten) iPad um den Faktor 6.

Welche Konstrukte oder Muster sollte ich vermeiden, um den Speicherverbrauch von iOS auf Augenhöhe mit dem von Chrome zu bringen?

Charakterisierung des erzeugten JavaScript:

• Der Code wird durch Haxe erzeugt.
• Der Code ist "objektorientiert", da er prototype, aber in einem civilized way stark verwendet.
• Der Code verwendet stark benannte Indizes auf JavaScript-Objekte Hash-Tabellen zu implementieren.
• Es gibt eine Menge Strings, aber kaum String-Verkettungen.

Es scheint keine Speicherlecks zu geben; der übermäßige Speicherverbrauch auf iOS zeigt sich sofort beim Aufbau der (festen Menge) Javascript-Objekte.

Answer 1

Eine Möglichkeit, wie Sie versuchen können, Ihren Code zu optimieren, ist über GWT (dessen Compiler, glaube ich, ein optimierenderer Compiler ist als der js-Compiler von haxe).

Ich würde zuerst alle Ihre haxe-Code in Java kompilieren, dann konvertieren Sie das in js über GWT, und sehen, ob die Speicheranforderungen ähnlich hoch bleiben.

Wenn die Konvertierung zu Java, dann zu GWT zu schwierig ist, ist eine enge Annäherung, den Google-Abschluss-Compiler auf das resultierende Javascript zu verwenden, das über haxe erzeugt wird. Ich bin mir nicht sicher, ob haxe in der Lage ist, Javascript in einer Weise auszugeben, die mit dem ADVANCED_OPTIMIZATION-Modus kompatibel ist (https://developers.google.com/closure/compiler/docs/compilation_levels#advanced_optimizations), was Sie tun müssten (andernfalls ist die Schließung nicht besser als ein einfacher Code-Minimierer).

Answer 2

Sie erwähnten, dass es stark vom Prototyp verwendet. Das könnte ein Grund sein: Wenn Sie glauben, dass Ihre Objekte den gleichen Prototyp teilen können, versuchen Sie es; Zum Beispiel:

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

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

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

Sie werden bemerken, baz.Bar2.prototype zeigt auf baz.Bar.prototype. Mit diesem Konzept können Sie den Speicher, der von baz.Bar2 zugewiesen werden soll, speichern, da er von baz.Bar freigegeben wird.

Answer 3

Da Ihr Code auf dem Desktop gut läuft, ist es wahrscheinlich eine untergeordnete Eigenart in iOS. Was ich bezweifle, kann man mit einer objektorientierten Programmierung beheben. Sicher könnte dies den Speicherbedarf ein wenig, aber nicht um den Faktor 6.

UIWebView zu reduzieren, ist ziemlich berüchtigt für Speicher zu schaffen Lecks Sie könnten versuchen, die neuere (iOS 8+) WKWebView hat viel besser Garbage Collection zu verwenden.

Apple WKWebView Reference

Answer 4

Mein Vorschlag ist, dass Sie das DOM Teil Ihrer Anwendung zu suchen. Ich glaube nicht, dass in Ihrer JavaScript-Struktur viel Optimierung möglich ist. Die schwache Verbindung in Mobile/Tablets ist normalerweise der Rendering-Prozess. Wenn Sie den Speicherverbrauch reduzieren möchten, können Sie die Funktionsweise Ihres DOM ändern. versuchen Sie, so wenig DOM-Knoten wie möglich zu behalten, den Inhalt (Knoten-Inhalt) der versteckten DOM-Knoten auszublenden. Diese Art von DOM-Manipulationen hat mir in der Vergangenheit geholfen, meine Web-App reaktionsfähiger zu machen und die Speichernutzung so gering wie möglich zu halten.

Virtuelle Scroll, ist etwas Nützliches für den dom so klein wie möglich zu halten, virtual-scroll