Kliknij „Wgraj”, a narzędzia deweloperskie wyświetlą czerwoną linijkę: rozmiar pakietu głównego przekracza limit 2 MB. Wersja nie może zostać wgrana, a zgłoszenia czekają.
W tym artykule nie omawiamy przeglądu zagadnień teoretycznych, tylko listę metod zmniejszających rozmiar pakietu głównego poniżej 2 MB, uporządkowaną według „dużo oszczędności, małe zmiany”.
Najpierw ustalcie, co dokładnie blokuje limit 2 MB
WeChat ma dwa twarde limity dla pakietów kodu Mini Programu:
| Ograniczenie | Limit |
|---|---|
| Pakiet główny (w tym app.js, strony tabBar, zasoby publiczne itp.) | 2 MB |
| Poszczególny pakiet podrzędny | 2 MB |
| Suma wszystkich pakietów w całym Mini Programie | 20 MB |
Zwróć uwagę, że tutaj „rozmiar” to wolumen kodu po wgraniu, nie tylko JS. Wszystkie pliki, które zostaną spakowane do projektu, są uwzględniane: .js, .wxml, .wxss, ., czcionki, audio oraz – zazwyczaj stanowiące największą część – obrazy.
Jest to sztywny limit „nie da się go zmniejszyć, więc nie można wydać wersji”, a nie „optymalizacja jest lepsza”. Więc pierwszy krok to nie bycie aktywnym, ale najpierw zrozumienie, gdzie wydawane są pieniądze.
Krok 0: Zobacz, co zajmuje miejsce w pakiecie głównym
W prawym górnym rogu narzędzi deweloperskich WeChat „Szczegóły → Informacje podstawowe” można zobaczyć łączny rozmiar lokalnego pakietu kodu; bardziej szczegółowy jest na pasku narzędzi „Analiza zależności kodu”, który wyświetla wolumen według plików i oznacza te, które nie są żadną stroną odniesienia.
Większość projektów po przejrzeniu tej tabeli zauważy to samo: zasoby statyczne, takie jak obrazy i czcionki, są znacznie większe niż kod biznesowy. JS może mieć dziesiątki tysięcy wierszy i liczyć tylko kilkadziesiąt KB, ale pojedyncza nieprzetworzona banerowa grafika może liczyć setki KB, a katalog images/ łatwo zjada połowę pakietu głównego.
Poniżej lista uporządkowana od największej do najmniejszej korzyści.
Metoda 1: Usuń pliki, których w ogóle nie używasz
Najmniej zmagań, a najczęściej pomijane.
- Pliki oznaczone jako nieprzywoływane w „Analizie zależności kodu”: stare ikony z wersji historycznych, nieaktualne strony, testowe obrazy – usuń je bezpośrednio.
- Pliki, które nie powinny wchodzić do pakietu: szkice projektów, README,
.psd, surowe materiały, dane Mock. Jeśli możesz przenieść je poza katalog projektu; jeśli nie, użyjpackOptions.ignorewproject.config.do wykluczenia:
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Wprowadzanie w całości biblioteki komponentów: często spotykane „niewidzialne grube ciało” – wprowadzasz całą bibliotekę UI, a używasz tylko trzech komponentów. Zmień to na wprowadzanie na żądanie, zachowując tylko używane katalogi komponentów.
Metoda 2: Podpakietowanie – przenieś strony niebędące stroną startową poza pakiet główny
Jest to oficjalnie poprawne rozwiązanie. Pakiet główny zachowaj tylko dla strony startowej, stron tabBar i ich rzeczywiste potrzebne kodu publicznego, resztę stron podziel według wymagań biznesowych do podpakietów:
{
"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"] }
}
}
Kilka kluczowych punktów:
- Zasoby podążają za stronami: obrazy i komponenty używane przez strony w podpakietach muszą zostać umieszczone w katalogu podpakietu. Umieszczenie ich w publicznym
images/w pakiecie głównym oznacza, że mimo podziału, ich wolumen nadal jest liczony w pakiecie głównym. preloadRulepobieranie wstępne podpakietów: gdy wchodzi się na stronę główną, pobierz wstępnie podpakiet, który prawdopodobnie zostanie użyty w następnym kroku, tak aby użytkownik nie czuł opóźnienia, gdy na niego wejdzie.- Podpakiet niezależny (
"independent": true): odpowiedni dla stron takich jak akcje, landing page, które mogą być otwarte niezależnie od pakietu głównego i nie wymagają zależności od pakietu głównego podczas uruchamiania. - Zasynchronizowanie podpakietów: gdy odwołujesz się do komponentów lub JS na przecięciu podpakietów, możesz użyć komponentów zastępczych i
require.async, aby uniknąć ponownego przenoszenia kodu do pakietu głównego tylko po to, aby go „używać wspólnie”.
Koszt podpakietowania polega na konieczności zmiany struktury katalogów i ścieżek przeskoku. Dla starych projektów podział wymaga znacznego nakładu pracy, co sprawia, że warto najpierw wykonać poniższy krok – często po jego zrobieniu pakiet główny wraca poniżej 2 MB.
Metoda 3: Zmniejsz obrazy (najmniejsze zmiany, bezpośrednia korzyść)
Obrazy są częścią pakietu głównego, która najłatwiej „będzie nienaturalnie gruba”. Graficy eksportują PNG z dodatkowymi blokami danych, JPG używa parametrów jakości, które są nieco wyższe – te bajty użytkownik nie widzi, ale każdy z nich jest liczony w 2 MB.
Jakie obrazy muszą zostać w pakiecie
Nie wszystkie obrazy można przenieść do CDN:
- Ikony tabBar:
iconPath/selectedIconPathmogą być tylko ścieżkami lokalnymi, nie obsługują obrazów sieciowych. - Strona startowa, Logo ekranu powitalnego, zastępcze obrazy awaryjne: muszą być wyświetlane również w słabym połączeniu lub offline.
- Często występujące małe ikony: każdorazowe żądanie sieciowe nie ma sensu ekonomicznego.
Te obrazy muszą pozostać w pakiecie, więc jedynym sposobem jest ich zmniejszenie.
Unikaj pułapki w wxss z obrazami tła
Używanie background-image do odwoływania się do obrazów lokalnych w .wxss nie działa na urządzeniach rzeczywistych; typowym obejściem jest konwersja na base64 w wierszu. Ale kodowanie base64 sprawia, że wolumen rośnie o około jedną trzecią, a jest on ukryty w pliku stylów, co nie jest bardzo widoczne w analizie zależności. Jeśli można je zmienić na komponent <image> lub obraz sieciowy, nie używaj wierszy; jeśli to konieczne, najpierw zmniejsz oryginał, a potem przekonwertuj.
Użyj ImgZilla do kompresji całego katalogu zasobów w miejscu
Największą obawą przy Mini Programach jest to, że po kompresji obrazów trzeba zmienić ścieżki – w wxml, wxss, konfiguracji JS, konfiguracji tabBar – wszędzie jest /images/xxx.png. Większość narzędzi kompresyjnych zapisuje jako xxx-min.png lub wymaga wyeksportowania do innego folderu, a po kompresji trzeba ręcznie je zastąpić i sprawdzić, czy nie pominąłeś niczego.
ImgZilla to narzędzie kompresujące obrazy dla macOS, które stosuje kompresję w miejscu:
- Nazwa pliku, ścieżka i format pozostają niezmienione.
icon-home.pngpo kompresji nadal toicon-home.png, nie trzeba zmieniać ani jednego wiersza w kodzie. - Wystarczy przeciągnąć cały katalog. Skanuje rekurencyjnie wszystkie podkatalogi i automatycznie pomija pliki ukryte i
node_modules. Przeciągnijimages/,static/lub nawet cały katalog projektu, a potem sprawdź zmianę wolumenu pakietu w narzędziach deweloperskich. - Oryginalne obrazy są domyślnie przenoszone do kosza, a jeśli któryś Ci się nie podoba, kliknij prawym przyciskiem myszy „Przywróć w oryginale”, aby przywrócić. Jeśli projekt jest w Git, masz jeszcze jedną warstwę zabezpieczeń.
- Cała operacja działa lokalnie, bez przesyłania do sieci. Materiały projektów korporacyjnych nie opuszczają Twojego komputera, a nie ma ograniczeń liczby plików lub rozmiaru pojedynczego pliku, jak w serwisach kompresji online.
Co do jakości, różne formaty mają różne podejścia, oto wyjaśnienie:
- PNG: używa oxipng do bezstratnej kompresji, piksele się nie zmieniają. Duża część ikon i przycięć w Mini Programach to PNG, więc bezpiecznie je kompresuj.
- SVG: czyszczenie zbędnych znaczników, również bezstratne.
- JPG / WebP / GIF itp.: dotyczy kody z utratą, parametry są dostrajane do wizualnie bezstratnego zakresu – trudno zauważyć różnicę gołym okiem. Nie musisz ufać na słowo; wbudowane okno porównania (
⌘D) pozwala na podział na pół ekranu i powiększenie do rzeczywistych pikseli, aby porównać każdy obraz.
Dwa dodatkowe punkty warto wiedzieć:
- Nie wymusza kompresji, jeśli jest już bardzo mała. Pliki o kompresji poniżej 0,4% będą oznaczone jako „już minimalne” i zostaną zachowane w oryginale, nie zmieniając ich w celu lepszego wyglądu liczb. Jeśli Twoje obrazy zostały wcześniej starannie zoptymalizowane, ten krok może nie oszczędzić dużo – to normalne i oznacza, że należy skupić się na podpakietowaniu.
- Nie zmienia formatu ani rozdzielczości. Po kompresji PNG nadal jest PNG, wymiary się nie zmieniają. Jeśli chcesz zamienić obraz na WebP lub obniżyć 3x do 2x, to osobna sprawa, wymagająca osobnego przetworzenia.
Tyle ile możesz oszczędzić, zależy od tego, jak zostały wyeksportowane Twoje obrazy, nie podajemy ogólnego procentu. Jako odniesienie, przeprowadziliśmy dwie publiczne próby: jeden zestaw JPG, które zostały już skompresowane przy indeksowaniu stron internetowych, po ponownej kompresji oszczędzono 46,8%; drugi zestaw JPG wyeksporowany bezpośrednio z aparatu oszczędził 76,8% (szczegóły w serii „Testy ImgZilla”). Obrazy w Mini Programach często są wyeksportowane bezpośrednio z narzędzi projektowych i zazwyczaj nie zostały starannie skompresowane, więc warto je przejrzeć.
ImgZilla jest obecnie dostępny tylko na macOS (macOS 12.3 i nowsze), można je pobrać w App Store, darmowa kompresja 10 plików dziennie. Użytkownicy Windows mogą skorzystać z tego podejścia – wystarczy zmienić narzędzie na to, które również „zachowuje nazwę pliku”.
Metoda 4: Przenieś duże obrazy na CDN
Po zmniejszeniu, obrazy, które wciąż są bardzo duże – takie jak banery akcji, długie obrazy stron szczegółowych, duże obrazy produktów – nie powinny być w pakiecie. Wgraj je na magazyn obiektów lub CDN, a w kodzie zmień na adresy sieciowe, a pakiet główny natychmiast się lżejszy.
Jednak nie jest to darmowe:
- Pierwsze ładowanie wymaga połączenia sieciowego, w słabym połączeniu może wystąpić pusty okres, lepiej połączyć z obrazami zastępczymi lub ekranami szkieletowymi.
- Trzeba utrzymywać proces wgrywania, buforowania i aktualizacji.
- CDN jest rozliczany według ruchu. Każde ładowanie obrazu kosztuje pieniądze, opłata za ruch jest w przybliżeniu równa „wolumenowi obrazu × liczba wyświetleń”. Zanim przeniesiesz na CDN, warto również najpierw zmniejszyć obrazy – raz skompresowane, a przy każdym kolejnym wyświetleniu oszczędzasz ruch.
Metoda 5: Końcowe szlify na poziomie kodu
Po przetworzeniu obrazów i struktury, reszta pustego miejsca może zostać wycięta z kodu:
- W „Szczegóły → Ustawienia lokalne” w narzędziach deweloperskich zaznacz „Kompresuj skrypty, style, WXML podczas wgrywania”.
- W
app.włącz"lazyCodeLoading": "requiredComponents"(wstrzykiwanie na żądanie). Poprawia głównie prędkość uruchamiania, a nie rozmiar pakietu, ale skoro robisz optymalizację wydajności, warto to włączyć razem. - Sprawdź
miniprogram_npm: czy zbudowane pakiety npm mają sytuacje, w których cały pakiet jest wprowadzany, a używane są tylko kilka funkcji. - Duże ilości statycznych danych wpisanych w kodzie JS (listy miast, tabele konfiguracyjne) rozważ zastąpienie wywołaniem interfejsu API.
Tabela podsumowująca
| Metoda | Oszczędność | Zmiany | Zalecana kolejność |
|---|---|---|---|
| Usuwanie niepotrzebnych plików | Zależy od historii projektu | Mało | 1 |
| Kompresja w miejscu obrazów | Im więcej obrazów, im mniej ostrożne eksportowanie, tym więcej oszczędności | Prawie zero, ścieżki niezmienione | 2 |
| Podpakietowanie | Może być dużo | Konieczność zmiany katalogów i tras | 3 |
| Przeniesienie dużych obrazów na CDN | Dużo | Konieczność zmiany odwołań, utrzymania procesu wgrywania | 4 |
| Kompresja kodu i wprowadzanie na żądanie | Mniej | W zależności od sytuacji | 5 |
Logika kolejności jest prosta: najpierw zmiany małe, potem duże. Usuwanie plików i kompresja obrazów prawie nie dotykają kodu biznesowego; po zrobieniu sprawdź, ile jeszcze brakuje do pakietu głównego – jeśli wróciło poniżej 2 MB, wersja dzisiaj może zostać wydana; jeśli nie wystarcza, przejdź do podpakietowania i CDN, i będziesz wiedzieć, o co chodzi.
Przekroczenie limitu pakietu głównego często zdarza się w najtrudniejszym momencie przed wydaniem. Wprowadź kompresję obrazów do codziennego procesu – przed dodaniem każdego nowego obrazu najpierw go skompresuj – a następnym razem nie będziesz się martwił przed terminem, patrząc na czerwoną linijkę.