Ich baue eine große Website mit starker Javascript-Nutzung, mein gesamter Inhalt wird über ajax geladen, er ist Facebook sehr ähnlich, und da es viele verschiedene Seiten gibt, brauche ich viel Javascript, also was ich Ich dachte daran, mein Skript in Abschnitte zu unterteilen. Jede Seite hätte eine eigene Skriptdatei.

Jetzt ist das Laden einfach, ich lade einfach eine neue Datei mit jeder Seite, aber meine Sorge ist, was passiert, wenn der Benutzer 100 verschiedene Seiten durchläuft und 100 verschiedene Skriptdateien lädt?

Im Moment hat meine Website nicht so viele Seiten, aber ich bin mir ziemlich sicher, dass sie irgendwann in Zukunft auf fast 100 einzigartige Seiten anwachsen wird.

Was würde also mit dem Benutzer mit einem langsameren Computer passieren? Ich vermute, es würde sich langsam verlangsamen, da es keine Aktualisierung geben würde. Nach dem, was ich gelesen habe, ist es unmöglich, einfach alle Ereignisse und Daten aus der geladenen Skriptdatei auf einfache Weise zu entladen, und wenn ich das versuchen würde, könnte es mich viel Zeit und Mühe kosten, dies zu tun.

Meine Frage wäre also, sollte ich es einfach so lassen, wie es ist, oder versuchen, etwas dagegen zu tun? Ich verwende derzeit jquery mit wenigen Plugins, und wenn ich raten müsste, dass die durchschnittliche Datei etwa 50-200 Codezeilen mit hauptsächlich click Ereignissen und ajax Aufrufen enthält.

Beachten Sie, dass jedes Seitenobjekt für jede Klasse ein eigenes Präfix hat, zum Beispiel: home_header, login_header

Es sollte also keine Konflikte zwischen onClick Ereignis-Listenern und ähnlichen Dingen geben.

BEARBEITEN Ich setze Kopfgeld für diese Frage, ich würde gerne mehr Meinungen hören.

14
Linas 8 Okt. 2012 im 01:02

3 Antworten

Beste Antwort

Nur weil Sie AJAX verwenden, bedeutet dies nicht automatisch Alarmglocken in Bezug auf die Speichernutzung. Sie sollten sich mehr Gedanken über die Art von Dingen machen, die Speicherlecks verursachen, und sicherstellen, dass Sie die Dinge richtig zerstören und konstruieren:

In der Regel erstelle ich in jedem großen System einen Hilfskonstruktor, der alle Elemente verfolgt, die ich zu einem späteren Zeitpunkt oder beim Entladen der Seite (Ereignis-Listener, große Attribute oder Objektstrukturen) zerstören möchte. alle durch einen Namespace indiziert. Wenn ich mit einem bestimmten Abschnitt oder einer bestimmten Entität fertig bin, bitte ich das Hilfesystem - ich nenne es GarbageMonkey :) - einen bestimmten Namespace zu löschen.

  1. Für Ereignisse löst es sich
  2. Für Attribute wird es deaktiviert
  3. Bei Arrays / Objekten wird jeder Schlüssel gescannt und deaktiviert, und dies kann auch für Unterelemente erfolgen
  4. Bei Elementen werden Inhalte so weit wie möglich entfernt und bereinigt

Damit dies funktioniert, müssen Sie natürlich vorsichtig sein, wenn Sie Variablen herumliegen lassen, die einen Verweis auf die Daten enthalten, die Sie löschen möchten. Dies bedeutet also, sich darüber im Klaren zu sein, was Garbage Collection ist Schließungen sind; und wie zwischen ihnen können sie eine Variable für immer am Leben erhalten !! ..oder zumindest bis der Browser / Tab zerstört ist. Es bedeutet auch, Objektstrukturen anstelle von Vars zu verwenden, da Sie Schlüssel in jedem Bereich löschen können, der Zugriff auf das Objekt hat, dies jedoch nicht für Vars.

Also mach das:

var data = {}, methods = {}, events = {};

methods.aTestMethod = function(){
  /// by assigning properties to an object, you can easily remove them later
  data.value1 = 123;
  data.value2 = 456;
  data.value3 = 789;
}

An Stelle von:

var value1, value2, value3;

var aTestMethod = function(){
  value1 = 123;
  value2 = 456;
  value3 = 789;
}

Der Grund dafür ist, dass Sie oben Folgendes tun können:

var i;
for( i in methods ){ delete methods[i]; }
for( i in data ){ delete data[i]; }

Aber das kannst du nicht machen:

delete value1;
delete value2;
delete value3;

Offensichtlich schützt Sie das Obige nicht vor einer Referenz, die direkt auf ein Unterelement von entweder methods oder data verweist. Wenn Sie jedoch nur die Objekte methods und data in Ihrem Code weitergeben und beim Anhängen von Methoden als Ereignis-Listener aufgeräumt bleiben, sollte dies nur dann verweisen, wenn Sie eine unerwünschte Referenz haben zu einem leeren Objekt (nachdem Sie dessen Inhalt gelöscht haben) .

7
Community 23 Mai 2017 im 12:24

Es gibt zwei verschiedene Dinge, um die man sich kümmern muss:

-Speichernutzung

- Speicherlecks

Bei lang laufenden Webanwendungen sollten Speicherlecks unbedingt vermieden werden, da sonst Browserabstürze auftreten können. Um die Speichernutzung zu überwachen, können Sie den Prozess-Explorer herunterladen: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Deaktivieren Sie alle Browser-Plugins, verwenden Sie dann Ihre App und führen Sie sich wiederholende Aufgaben aus. Wenn die Speichernutzung zunimmt, treten Lecks auf. IE7 - IE8 lecken viel leichter als moderne Browser und sind viel schwieriger zu debuggen. Daher ist es hilfreich zu wissen, wie gering die Browserkompatibilität ist.

Bei der Speichernutzung können einige Dinge dazu beitragen, das Gewicht Ihrer App zu verringern:

  • Verwenden Sie die Ereignisdelegierung, anstatt dom-Elemente zu durchlaufen und Ereignishandlerfunktionen anzuhängen. ED ist hier wirklich eine goldene Waffe.

  • Für IE 7/8 war eine var-Aufhebung erforderlich, und ich denke, es hilft immer noch für moderne Browser (muss getestet werden). Dazu müssen Sie auch Ihre Funktionen benennen, damit Sie sie aus dem Speicher entfernen können. (Weitere Informationen hierzu finden Sie in den Antworten auf Kieselsteine.)

  • Behalten Sie die Kontrolle über die Domgröße. Wenn Knoten für ein Feature hinzugefügt werden, sollten sie auch entfernt werden, wenn dieses Feature nicht mehr verwendet wird.

  • Fügen Sie all Ihren Komponenten eine Teardown () -Methode hinzu, die das Entladen übernimmt.

Ok, sorry ich bin hier etwas zu schnell, aber es wäre schön zu wissen:

  1. Was ist Ihr Mindestbrowser?

  2. wenn Sie Lecks festgestellt haben

  3. wenn ED eine ausreichende Lösung ist (oft ist es)

2
Olivvv 10 Okt. 2012 im 14:31

Wenn Sie Variablen recyceln und den globalen Bereich nicht verschmutzen, sind Sie auf dem richtigen Weg. Bei Ihrer Frage sollten Sie jedoch zuerst herausfinden, ob es sich um ein praktisches Problem handelt.

Dies kann mit einem Profiler überprüft und überwacht werden - sofort einsatzbereit Chrome ist dafür ziemlich anständig Geben Sie about:memory in die URL ein. Dadurch erhalten Sie eine Aufschlüsselung pro Tab und können sogar die Speichernutzung zwischen Browsern vergleichen. Wenn Sie einige automatisierte Testszenarien eingerichtet haben (oder bereit sind, manuell durch 100 Seiten zu navigieren), zeigt Ihnen eine solche Profilerstellung, ob mit Ihrer Website ein schwerwiegender Fehler vorliegt.

6
o.v. 7 Okt. 2012 im 23:57