Klicken Sie auf "Hochladen" und die Entwicklungstools zeigen eine rote Zeile an: Die Größe des Hauptpakets überschreitet das 2MB-Limit. Die Version kann nicht hochgeladen werden und die Anforderungen warten noch in der Schlange.
Dieser Artikel behandelt nicht den allgemeinen Theorie-Überblick, sondern listet nur die Methoden auf, um das Hauptpaket unter 2MB zu drücken, sortiert nach "viel sparen, wenig ändern".
Zuerst klären: Was genau klemmt bei 2MB
WeChat hat zwei harte Obergrenzen für den Code-Paket-Größenbeschränkung:
| Limit | Obergrenze |
|---|---|
| Hauptpaket (inkl. app.js, TabBar-Seiten, öffentliche Ressourcen usw.) | 2MB |
| Einzelnes Teilpaket | 2MB |
| Gesamtgröße aller Pakete der Mini-Programms | 20MB |
Achten Sie hier auf die "Größe", die es ist, die nach dem Hochladen berechnet wird, nicht nur JS. Alle Dateien im Projektwurzelverzeichnis, die in das Paket gepackt werden, zählen: .js, .wxml, .wxss, ., Schriftarten, Audio und – meist der Hauptanteil – Bilder.
Dies ist eine harte Grenze, die "nicht drücken, nicht veröffentlichen" bedeutet, nicht "optimieren, besser". Also ist der erste Schritt nicht das Handwerker, sondern erst zu sehen, wo das Geld hingeht.
Schritt 0: Sehen, was im Hauptpaket Platz beansprucht
In den Entwicklungstools von WeChat können Sie rechts oben auf "Details -> Grundinformationen" klicken, um die Gesamtgröße des lokalen Pakets zu sehen; detaillierter ist "Code-Abhängigkeitsanalyse" in der Werkzeugleiste, das Dateien nach Größe auflisten und markieren kann, welche Dateien von keiner Seite referenziert werden.
Nachdem die meisten Projekte diese Tabelle angesehen haben, stellen sie dieselbe Sache fest: Statische Ressourcen wie Bilder und Schriftarten sind viel größer als der Geschäftscode. JS mit einigen Zehntausend Zeilen sind nur einige hundert KB, eine unkomprimierte Banner-Grafik kann bereits mehrere hundert KB betragen, ein images/-Verzeichnis frisst problemlos die Hälfte des Hauptpakets.
Unten ist die Reihenfolge nach abnehmendem Nutzen aufgeführt.
Methode 1: Löschen Sie komplett nutzlose Dateien
Der einfachste Weg und am häufigsten übersehene.
- Dateien, die als "nicht referenziert" in der "Code-Abhängigkeitsanalyse" markiert sind: Alte Symbole aus früheren Versionen, veraltete Seiten, Testbilder – einfach löschen.
- Dateien, die nicht ins Paket gehören: Design-Skizzen, README,
.psd, Rohmaterialien, Mock-Daten. Wenn sie aus dem Projektwurzelverzeichnis verschoben werden können, tun Sie das; wenn nicht, verwenden SiepackOptions.ignoreinproject.config., um sie auszuschließen:
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Vollständige Einführung von Komponentenbibliotheken: Es ist üblich, eine gesamte UI-Bibliothek in das Hauptpaket zu packen, obwohl nur drei Komponenten verwendet werden. Ändern Sie sie auf bedarfsorientierte Einführung und behalten Sie nur die verwendeten Komponentenordner.
Methode 2: Teilpakete – Nicht-Startseiten aus dem Hauptpaket herausnehmen
Dies ist die offizielle Lösung. Das Hauptpaket sollte nur die Startseite, TabBar-Seiten und den dazugehörigen öffentlichen Code behalten; die restlichen Seiten sollten je nach Geschäftlogik in Teilpakete aufgeteilt werden:
{
"pages": ["pages/index/index", "pages/mine/mine"],
"subPackages": [
{ "root": "packageOrder", "pages": ["list/list", "detail/detail"] },
{ "root": "packageActivity", "pages": ["index/index"] }
],
"preloadRule": {
"pages/index/index": { "network": "all", "packages": ["packageOrder"] }
}
}
Einige Punkte:
- Ressourcen folgen der Seite: Bilder und Komponenten, die von der Teilpaketseite selbst verwendet werden, müssen in den Teilpaketordner verschoben werden. Wenn sie im öffentlichen
images/des Hauptpakets liegen, zählt die Größe immer noch auf das Hauptpaket. preloadRuleTeilpaket-Vorabladen: Laden Sie beim Betreten der Startseite das Teilpaket herunter, das mit hoher Wahrscheinlichkeit als Nächstes verwendet wird, sodass der Nutzer kaum eine Verzögerung spürt, wenn er darauf klickt.- Unabhängiges Teilpaket (
"independent": true): Geeignet für Aktivitätsseiten, Landing Pages und andere Seiten, die unabhängig vom Hauptpaket geöffnet werden können, ohne beim Start vom Hauptpaket abhängig zu sein. - Asynchronisierung von Teilpaketen: Wenn Komponenten oder JS von einem Teilpaket in einen anderen referenziert werden, können Platzhalterkomponenten und
require.asyncverwendet werden, um zu verhindern, dass Code aufgrund von "Shared Usage" wieder in das Hauptpaket zurückgezogen wird.
Der Preis für Teilpakete ist, dass das Verzeichnisstruktur und die Sprungpfade geändert werden müssen. Bei alten Projekten ist die Arbeit zur Aufteilung erheblich, weshalb es sich lohnt, den folgenden Schritt zuerst zu machen – oft reicht die Durchführung aus, um das Hauptpaket unter 2MB zu bringen.
Methode 3: Bilder komprimieren (geringste Änderung, direktester Nutzen)
Bilder sind der einfachste Teil im Hauptpaket, der "fett" herumläuft. Designer exportieren PNGs mit zusätzlichen Datenblöcken, JPGs verwenden Parameter mit hoher Qualität; diese Bytes sehen Nutzer nicht, aber jedes einzelne zählt zu den 2MB.
Welche Bilder müssen im Paket bleiben
Nicht alle Bilder können auf CDN verschoben werden:
- TabBar-Symbole:
iconPath/selectedIconPathmüssen lokale Pfade sein, keine Netzwerkbilder unterstützt. - Startseite, Logo der Startseite, Platzhalterbilder: Sie müssen auch bei schwachem Netzwerk oder Offline angezeigt werden können.
- Kleine Symbole, die häufig vorkommen: Jedes Mal eine Netzwerkanfrage zu machen, ist nicht lohnenswert.
Diese Bilder müssen im Paket bleiben, also ist die einzige Methode, sie kleiner zu machen.
Vermeiden Sie versehentlich ein Loch: Hintergrundbilder in wxss
Die Verwendung von background-image in .wxss, um lokale Bilder zu referenzieren, funktioniert auf dem echten Gerät nicht; die häufigste Umgehung ist die Umwandlung in Inline-Base64. Aber Base64-Codierung macht die Größe um etwa ein Drittel größer, und sie versteckt sich in der Stylesheet-Datei, was in der Abhängigkeitsanalyse weniger auffällt. Wenn es zu <image>-Komponenten oder Netzwerkbildern geändert werden kann, lassen Sie es nicht inline; wenn es zwingend inline sein muss, komprimieren Sie zuerst das Originalbild und konvertieren Sie dann.
Nutzen Sie ImgZilla, um den gesamten Ressourcenordner lokal zu komprimieren
Das, was Mini-Programm-Entwickler am meisten fürchten, ist, dass nach der Komprimierung noch Pfadänderungen im Code erforderlich sind – in wxml, wxss, JS-Konfiguration, TabBar-Konfiguration. Viele Komprimierungstools speichern es als xxx-min.png ab oder erfordern, dass Sie es in einen anderen Ordner exportieren, und nach der Komprimierung müssen Sie manuell ersetzen und noch einmal prüfen, ob etwas vergessen wurde.
ImgZilla ist ein macOS-Bildkomprimierungstool, das lokal komprimiert:
- Dateiname, Pfad und Format bleiben unverändert.
icon-home.pngbleibt nach der Komprimierungicon-home.png, keine Änderung im Code erforderlich. - Der gesamte Ordner kann per Drag & Drop hineingezogen werden. Es scaniert rekursiv alle Unterordner und überspringt automatisch versteckte Dateien und
node_modules. Verschieben Sieimages/,static/oder sogar den gesamten Projektordner hinein; nach der Komprimierung können Sie direkt die Paketgröße in den Entwicklungstools überprüfen. - Die Originalbilder werden standardmäßig in den Papierkorb verschoben. Wenn Sie unsicher sind, klicken Sie mit der rechten Maustaste auf "Zurückstellen", um sie wiederherzustellen. Wenn das Projekt in Git ist, haben Sie eine zusätzliche Sicherheitsschicht.
- Lokale Ausführung ohne Internet-Upload. Die Ressourcen von Firmengeheimnissen verlassen Ihren Computer nicht, und es gibt keine Einschränkungen pro Bild oder pro Stapel wie bei Online-Komprimierungsdiensten.
Was die Bildqualität betrifft, verfahren die verschiedenen Formate unterschiedlich; hier ist es klar:
- PNG: Nutzt oxipng für verlustfreie Komprimierung, Pixel werden nicht geändert. Viele Symbole und Schnitte in Mini-Programmen sind PNG, diese können hier sicher komprimiert werden.
- SVG: Bereinigung redundanter Markierungen, auch verlustfrei.
- JPG / WebP / GIF usw.: Gehören zur verlustbehafteten Neukodierung; die Parameter wurden für jedes Format auf das Bereich "visuell verlustfrei" kalibriert – visuell kaum unterscheidbar. Keine Notwendigkeit, blind zu vertrauen; das integrierte Vergleichsfenster (
⌘D) kann links/rechts geteilt und auf tatsächliche Pixel vergrößert werden, um Seite an Seite zu prüfen.
Zwei weitere Punkte sind erwähnenswert:
- Es drückt keine Bilder hart weiter, die bereits komprimiert sind: Wenn die Komprimierungsrate unter 0,4% liegt, wird die Datei als "bereits minimiert" markiert und unverändert beibehalten, um das Bild nicht unnötig zu verschlechtern. Wenn Ihre Bilder bereits sorgfältig optimiert wurden, kann dieser Schritt wenig sparen – das ist normal und zeigt, dass es an der Zeit ist, zu Teilpaketen zu wechseln.
- Es ändert nicht das Format oder die Auflösung. Nach der Komprimierung bleibt es PNG, die Größe ändert sich nicht. Wenn Sie Bilder in WebP ändern oder 3x-Bilder in 2x-Bilder reduzieren möchten, ist das eine andere Sache, die separat behandelt werden muss.
Wie viel gespart werden kann, hängt davon ab, wie die Bilder ursprünglich exportiert wurden, wir geben keine pauschalen Prozentangaben. Als Referenz haben wir zwei öffentliche Tests durchgeführt: Eine Reihe von JPGs, die bereits einmal beim Web-Upload komprimiert wurden, wurde noch einmal komprimiert und sparte 46,8%; eine Reihe von direkt aus der Kamera exportierten JPGs sparte 76,8% (siehe "ImgZilla Tests"-Serie). Bilder in Mini-Programmen sind oft direkt aus Design-Tools exportiert, werden selten sorgfältig komprimiert, daher lohnt es sich, einmal zu laufen zu sehen.
ImgZilla ist derzeit nur macOS verfügbar (macOS 12.3 und höher), über den Mac App Store herunterzuladen, mit 10 kostenlosen Komprimierungen pro Tag. Für Studenten mit Windows können Sie den Ansatz aus diesem Abschnitt ebenfalls anwenden und ein Tool mit ähnlichen "Originaldateinamen beibehalten"-Funktionen wählen.
Methode 4: Große Bilder auf CDN verschieben
Nach der Komprimierung sind Bilder immer noch sehr groß – z. B. Banner für Aktivitäten, lange Bilder auf Detailseiten, große Produktbilder – sie passen eigentlich nicht ins Paket. Hochladen auf Objektspeicher oder CDN und Ersetzen der Pfade mit Netzwerkadressen macht das Hauptpaket sofort leichter.
Aber das ist nicht kostenlos:
- Die erste Ladung muss über das Netzwerk laufen, bei schwachem Netzwerk gibt es eine weiße Leere; am besten wird dies mit Platzhalterbildern oder Skelettbildern kombiniert.
- Ein Prozess zum Hochladen, Caching und Aktualisieren muss aufrechterhalten werden.
- CDN wird nach Traffic berechnet. Jedes Mal, wenn ein Bild geladen wird, kostet es Geld; die Traffic-Gebühr entspricht ungefähr "Bildgröße × Zugriffe". Daher ist es auch vor dem Verschieben auf CDN sinnvoll, die Bilder zuerst zu komprimieren – einmal komprimieren, und jede weitere Anfrage spart Traffic.
Methode 5: Code-Ebene Abschluss
Nachdem Bilder und Struktur bearbeitet wurden, können Sie den verbleibenden Platz aus dem Code herausnehmen:
- In den Entwicklungstools "Details -> Lokale Einstellungen" und aktivieren Sie beim Hochladen die Komprimierung von Skripten, Styles, WXML.
- Aktivieren Sie
"lazyCodeLoading": "requiredComponents"inapp.(bedarfsorientierte Injektion). Es verbessert hauptsächlich die Startgeschwindigkeit statt die Paketgröße, aber da wir die Leistung optimieren, können wir es zusammen einschalten. - Überprüfen Sie
miniprogram_npm: Gibt es im gebauten npm-Paket eine vollständige Einführung, obwohl nur ein paar Funktionen verwendet werden? - Große Mengen statischer Daten, die fest im JS stehen (Stadtlisten, Konfigurationstabellen), sollten in APIs ausgelagert werden.
Zusammenfassung in einer Tabelle
| Methode | Wie viel kann gespart werden | Wie viel muss geändert werden | Empfohlene Reihenfolge |
|---|---|---|---|
| Löschen nutzloser Dateien | Je nach Projektvergangenheit | Wenig | 1 |
| Lokale Bildkomprimierung | Je mehr Bilder, desto willkürlicher der Export, desto mehr wird gespart | Fast null, Pfade unverändert | 2 |
| Teilpakete | Viel | Verzeichnis und Routen müssen bewegt werden | 3 |
| Große Bilder auf CDN | Viel | Referenzen müssen geändert, Upload-Prozess muss gepflegt werden | 4 |
| Code-Komprimierung und bedarfsorientierte Einführung | Weniger | Je nach Situation | 5 |
Die Logik der Reihenfolge ist einfach: Führen Sie zuerst Änderungen mit wenig Aufwand durch, dann die großen Änderungen. Löschen von Dateien und Komprimieren von Bildern berühren kaum den Geschäftscode; prüfen Sie nach Abschluss, wie viel das Hauptpaket noch fehlt – wenn es bereits unter 2MB ist, kann die Version heute veröffentlicht werden; wenn nicht, bewegen Sie dann Teilpakete und CDN, und Sie haben eine klare Vorstellung.
Die Überschreitung des Hauptpakets passiert oft genau dann, wenn es kritisch wird vor der Veröffentlichung. Setzen Sie die Bildkomprimierung in Ihren täglichen Prozess ein – jedes Mal, wenn Sie ein neues Bild hinzufügen, komprimieren Sie es zuerst – damit Sie sich das nächste Mal nicht beim Deadline-Zeitpunkt mit der roten Zeile herumschlagen müssen.