Unter den vielen Techniken zur Optimierung der Programmcodegröße umfassen die meisten das Entfernen unnötiger Elemente aus dem Code. Visual Basic entfernt beim Kompilieren einer Anwendung automatisch bestimmte Elemente. Es gibt keine Begrenzung für die Länge oder Anzahl der Bezeichnernamen, Kommentare und Leerzeilen. Wenn die Anwendung als .EXE-Datei ausgeführt wird, haben diese Elemente keinen Einfluss auf die von der Anwendung belegte Speichergröße. Andere Elemente wie Variablen, Formulare und Prozeduren beanspruchen etwas Speicherplatz. Es ist besser, sie zu rationalisieren, um sie effizienter zu machen. Im Folgenden werden sechs Methoden vorgestellt, mit denen Sie den von der Anwendung benötigten Speicher und die Codegröße reduzieren können. Ich hoffe, dass sie für Anfänger hilfreich sind.
1. Reduzieren Sie die Anzahl der Ladeformulare und Steuerelemente und verwenden Sie Beschriftungen anstelle von Textfeldern
Jedes geladene Formular, ob sichtbar oder nicht, belegt eine bestimmte Menge an Speicher (die Menge variiert je nach Art und Anzahl der Steuerelemente auf dem Formular, der Größe der Bitmap auf dem Formular usw.). Laden Sie das Formular nur, wenn Sie es anzeigen müssen, und entladen Sie es, wenn es nicht mehr benötigt wird (anstatt das Formular auszublenden). Denken Sie daran, dass jeder Verweis auf die Eigenschaften, Methoden oder Steuerelemente eines Formulars oder auf eine mit New deklarierte Formularvariable dazu führt, dass Visual Basic das Formular lädt.
Wenn Sie zum Entladen eines Formulars die Unload-Methode verwenden, kann nur ein Teil des vom Formular belegten Speicherplatzes freigegeben werden. Um den gesamten Speicherplatz freizugeben, verwenden Sie das Schlüsselwort Nothing, um die Referenz des Formulars ungültig zu machen:
Beim Entwerfen einer Anwendung sollten Formulare möglichst wenige Steuerelemente verwenden. Der tatsächliche Grenzwert hängt von der Art des Steuerelements und dem System ab. In der Praxis wird ein Formular mit einer großen Anzahl von Steuerelementen jedoch langsam ausgeführt. Eine verwandte Technik besteht darin, beim Entwerfen wann immer möglich Arrays von Steuerelementen zu verwenden, anstatt eine große Anzahl von Steuerelementen desselben Typs auf dem Formular zu platzieren. Ein Steuerelementarray ist eine Gruppe von Steuerelementen mit einem gemeinsamen Namen und Typ. Auch ihr Ablauf ist derselbe. Zur Entwurfszeit verbraucht das Hinzufügen von Steuerelementen mithilfe eines Steuerelementarrays weniger Ressourcen als das direkte Hinzufügen mehrerer Steuerelemente desselben Typs zum Formular. Steuerelementarrays sind auch nützlich, wenn mehrere Steuerelemente Code gemeinsam nutzen sollen. Das Beschriftungssteuerelement „Label“ beansprucht weniger Windows-Ressourcen als das Textfeld „Textbox“. Daher sollte nach Möglichkeit eine Beschriftung anstelle eines Textfelds verwendet werden. Wenn beispielsweise ein ausgeblendetes Steuerelement in einem Formular Text enthalten muss, ist die Verwendung von Beschriftungen effektiver.
2. Verwenden Sie Festplattendateien oder Ressourcen und Organisationsmodule
Daten, die zur Entwurfszeit direkt in die Anwendung eingefügt werden (z. B. Literalzeichenfolgen und Werte in Eigenschaften oder Code), erhöhen den von der Anwendung zur Laufzeit belegten Speicher. Das Laden von Daten aus Festplattendateien oder Ressourcen zur Laufzeit reduziert die Speichernutzung. Dies ist besonders wertvoll für große Bitmaps und Strings. Ressourcendateien bestehen tatsächlich aus einer Reihe unabhängiger Zeichenfolgen, Bitmaps oder anderen Elementen, von denen jedes über eine eindeutige Kennung verfügt. Ressourcendateien können mit einem Texteditor und einem Ressourcencompiler erstellt werden, die denen in Microsoft Visual C ähneln. Kompilierte Ressourcendateien haben die Erweiterung .res.
Visual Basic lädt Module nur bei Bedarf, d. h. wenn Code eine Prozedur im Modul aufruft, wird das Modul in den Speicher geladen. Wenn eine Prozedur in einem bestimmten Modul nie aufgerufen wird, lädt Visual Basic das Modul nie. Versuchen Sie daher, verwandte Prozeduren im selben Modul unterzubringen und Visual Basic das Modul nur bei Bedarf laden zu lassen.
3. Erwägen Sie das Ersetzen des Variant-Datentyps
Der Datentyp Variant ist äußerst flexibel einsetzbar, benötigt jedoch mehr Speicher als andere Datentypen. Wenn Sie überschüssigen Speicherplatz in Ihrer Anwendung komprimieren möchten, sollten Sie erwägen, Variant-Variablen durch andere Datentypen zu ersetzen, insbesondere Variant-Variablen-Arrays.
Jede Variante belegt 16 Bytes, während Integer 2 Bytes und Double 8 Bytes belegt. Zeichenfolgenvariablen variabler Länge belegen 4 Bytes plus 1 Byte für jedes Zeichen in der Zeichenfolge. Jede Variante, die eine Zeichenfolge enthält, belegt jedoch 16 Bytes plus 1 Byte für jedes Zeichen in der Zeichenfolge. Aufgrund ihrer Größe sind Variant-Variablen besonders ärgerlich, wenn sie als lokale Variablen oder Argumente für Prozeduren verwendet werden, da sie zu schnell Stapelspeicherplatz verbrauchen. In einigen Fällen verringert die Verwendung anderer Datentypen anstelle von Variant jedoch die Flexibilität, und es muss mehr Code hinzugefügt werden, um die verlorene Flexibilität auszugleichen. Das Ergebnis ist keine wirkliche Größenreduzierung.
4. Verwenden Sie dynamische Arrays und geben Sie beim Löschen Speicher frei
Verwenden Sie dynamische Arrays anstelle fester Arrays. Wenn die Daten des dynamischen Arrays nicht mehr benötigt werden, verwenden Sie Erase oder ReDimPReserve, um die unnötigen Daten zu verwerfen und den vom Array verwendeten Speicher zurückzugewinnen. Verwenden Sie beispielsweise den folgenden Code, um den von einem dynamischen Array verwendeten Speicherplatz zurückzugewinnen:
Hier löscht Erase das Array vollständig, während ReDimPreserve das Array nur verkürzt, ohne seinen Inhalt zu verlieren:
Durch das Löschen eines Arrays mit fester Größe wird nicht der vom Array belegte Speicherplatz zurückgefordert – es wird lediglich der Wert aus jedem Element des Arrays gelöscht. Wenn es sich bei den Elementen um Zeichenfolgen oder Varianten handelt, die Zeichenfolgen oder Arrays enthalten, wird durch das Löschen des Arrays der von diesen Zeichenfolgen oder Varianten belegte Speicher wiederhergestellt, nicht der vom Array selbst belegte Speicher.
5. Gewinnen Sie den von String- oder Objektvariablen verwendeten Speicherplatz zurück
Wenn der Prozess endet, kann der von (nicht statischen) lokalen String- und Array-Variablen verwendete Speicherplatz automatisch zurückgewonnen werden. Globale String- und Array-Variablen auf Modulebene bleiben jedoch bis zum Ende des gesamten Programms bestehen. Wenn Sie möchten, dass Ihre Anwendung so klein wie möglich ist, müssen Sie den von diesen Variablen verwendeten Speicherplatz so weit wie möglich zurückgewinnen. Durch das Zuweisen einer Zeichenfolge mit der Länge Null zu einer Zeichenfolgenvariablen wird deren Speicherplatz zurückgewonnen:
Ebenso wird durch das Setzen einer Objektvariablen auf Nothing ein Teil (aber nicht der gesamte) des vom Objekt verwendeten Speicherplatzes zurückgewonnen. So löschen Sie beispielsweise eine Formularobjektvariable:
Auch wenn Sie keine expliziten Formularvariablen verwenden, sollten Sie darauf achten, nicht mehr verwendete Formulare zu entladen, anstatt sie einfach auszublenden.
6. Beseitigen Sie toten Code und nutzlose Variablen
Wenn Sie Ihre Anwendung entwickeln und ändern, bleibt möglicherweise toter Code zurück – ein ganzer Prozess in Ihrem Code, der nirgendwo aufgerufen wird. Möglicherweise sind auch einige nicht verwendete Variablen deklariert. Obwohl Visual Basic beim Erstellen von .exe-Dateien tatsächlich nutzlose Konstanten löschen kann, kann es keine nutzlosen Variablen und toten Code löschen. Überprüfen Sie Ihren Code sorgfältig, um nutzlose Variablen und toten Code zu finden und zu entfernen. Beispielsweise wird die Debug.Print-Anweisung beim Ausführen von .exe ignoriert, sie erscheint jedoch häufig in .exe-Dateien.
Beim Erstellen einer .exe-Datei werden Debug.Print-Anweisungen, die Zeichenfolgen und Variablen als Parameter enthalten, nicht kompiliert. Aber für die Debug.Print-Anweisung, die eine Funktion als Parameter enthält, wird sie selbst vom Compiler ignoriert und die Funktion wird kompiliert. Während die Anwendung läuft, wird die Funktion zwar aufgerufen, der Rückgabewert wird jedoch ignoriert. Denn wenn die Funktion in der .exe-Datei als Parameter von Debug.Print erscheint, nimmt sie Speicherplatz und CPU-Zykluszeit in Anspruch. Daher ist es am besten, diese Anweisungen vor dem Generieren der exe-Datei zu löschen.
Verwenden Sie den Befehl „Suchen“ im Menü „Bearbeiten“, um nach Verweisen auf eine bestimmte Variable zu suchen. Oder wenn jedes Modul eine OptionExplicit-Anweisung enthält, können Sie schnell herausfinden, ob die Variable verwendet wird, indem Sie die Deklaration der Variablen löschen oder kommentieren und die Anwendung ausführen. Wenn diese Variable verwendet wird, tritt in Visual Basic ein Fehler auf. Wenn kein Fehler auftritt, wird die Variable nicht verwendet. ->