Klicka på "Uppdatera" och utvecklarverktygen visar en röd text: Huvudpaketets storlek överskrider 2MB-gränsen. Versionen kan inte laddas upp och kraven väntar fortfarande på kö.
Denna artikel går inte in i djupet av alla principer, utan listar metoder för att trycka ned huvudpaketet till under 2MB i ordning efter "spara mest, ändra minst".
Först förstå: vad exakt begränsar 2MB
WeChat har två hårda gränser för kodpaketet för Mini Program:
| Begränsning | Maxgräns |
|---|---|
| Huvudpaket (inkl. app.js, flikars sidor, gemensamma resurser etc.) | 2MB |
| Enstaka underpaket | 2MB |
| Alla paket för hela Mini Program till samman | 20MB |
Observera att "storlek" här är kodbundet storlek efter uppladdning, inte bara JS. Alla filer i projektmappen som kommer med i paketet räknas: .js、.wxml、.wxss、.、teckensnitt, ljud, och framför allt bilder.
Detta är en hård gräns som "inte går att trycka ned utan att versionen inte kan släppas ut", inte "optimera lite för att det ska bli bättre". Så det första steget är inte att göra något, utan att först se var pengarna går.
Steg 0: Se vad som tar plats i huvudpaketet
I WeChat-utvecklarverktygen högst upp till höger kan du se "Detaljer → Grundläggande information" för att se den totala storleken på det lokala kodpaketet; mer detaljerad information finns i verktygsfältets "Kodberoendeanalys", där filer kan listas efter storlek och markeras som orefererade.
När de flesta projekt tittar på denna tabell upptäcker de samma sak: statiska resurser som bilder och teckensnitt är betydligt större än affärs-koden. JS kan skrivas i tiotusentals rader men bara bli några hundra KB, medan en bannerbild som inte har optimerats kan vara över hundra KB, och en images/-mapp kan enkelt äta upp halva huvudpaketet.
Här följer en lista sorterad efter nytta från störst till minst.
Metod 1: Ta bort filer som inte används alls
Det enklaste och mest ofta glömda.
- Filer markerade som "orefererade" i "Kodberoendeanalys": gamla ikoner från tidigare versioner, föråldrade sidor, testbilder, ta bort dem direkt.
- Filer som inte borde ingå i paketet: designskisser, README,
.psd, ursprungliga material, Mock-data. Om möjligt flytta dem ut från projektmappen; om det inte går, användpackOptions.ignoreiproject.config.för att exkludera dem:
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Fullmängd-import av komponentbibliotek: det är vanligt att hela UI-biblioteket slås in i huvudpaketet fast man bara använder tre komponenter. Ändra till on-demand import och behåll bara de komponentmappar som faktiskt används.
Metod 2: Underpaket – Flytta sidor som inte är startsidan ut från huvudpaketet
Detta är den officiella "rätta" lösningen. Låt huvudpaketet bara innehålla startsidan, flikars sidor och deras nödvändiga gemensamma kod; dela upp resten av sidorna efter affärslogik i underpaket:
{
"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"] }
}
}
Några punkter att tänka på:
- Resurser följer med sidan: bilder och komponenter som en underpaketssida använder måste placeras i underpaketets mapp. Om de ligger i en gemensam
images/-mapp i huvudpaketet räknas deras storlek oavsett hur underpaketen delas upp. preloadRuleför förhandsladdning av underpaket: när man går in på startsidan kan man ladda ner de underpaket som sannolikt kommer att behövas nästa steg, så att användaren nästan inte märker fördröjningen när de klickar.- Oberoende underpaket (
"independent": true): lämpligt för aktivitetssidor eller landningssidor som kan öppnas separat utan att bero på huvudpaketet vid start. - Asynkronisering av underpaket: när man refererar till komponenter eller JS som ligger i olika underpaket kan man använda platshållarkomponenter och
require.asyncför att undvika att behöva lyfta tillbaka koden till huvudpaketet bara för att dela den.
Priset för underpaket är att man måste ändra mappstruktur och navigeringsvägar. Att dela upp gamla projekt kan vara mycket arbete, vilket är varför det är värt att göra följande steg först – ofta räcker det att göra det så att huvudpaketet redan är under 2MB.
Metod 3: Komprimera bilder (minst ändring, mest direkt nytta)
Bilder är den del i huvudpaketet som lätt blir "vita och feta". Designern exporterade PNG-filer med extra datablock, JPG använder en för hög kvalitetsparameter, dessa byte syns inte för användaren men varje enskild bit räknas mot 2MB.
Vilka bilder måste vara i paketet
Alla bilder kan inte flyttas till CDN:
- TabBar-ikoner:
iconPath/selectedIconPathmåste vara lokala sökvägar, nätverksbilder stöds inte. - Startsida, startsida-logo, reservbilder: de måste visas även vid svaga nätverksanslutningar eller offline-läge.
- Små ikoner som visas ofta: att hämta dem varje gång via nätverksförfrågan är inte värt besväret.
Dessa bilder kan bara vara kvar i paketet, så den enda metoden är att göra dem mindre.
Undvik en fälla: bakgrundsbilder i wxss
Att använda background-image i .wxss för att referera till lokala bilder fungerar inte på riktig enhet; en vanlig lösning är att konvertera dem till inbäddad base64. Men base64-kodning gör att storleken expanderar med ungefär en tredjedel, och den är gömd i stilmallen, så den är inte särskilt uppenbar i beroendeanalysen. Om det går att ändra till <image>-komponent eller nätverksbild, gör det; om det inte går, komprimera originalbilden först innan du konverterar.
Använd ImgZilla för att komprimera hela resursmappen "på plats"
Det som ofta är jobbigt med att komprimera bilder är att man måste ändra sökvägar senare – i wxml, wxss, JS-konfiguration, TabBar-konfiguration, etc. Många verktyg sparar som xxx-min.png eller kräver att man exporterar till en annan mapp, och sedan måste man manuellt byta ut och dubbelkolla att man inte glömt något.
ImgZilla är ett macOS-verktyg för bildkomprimering som gör in-place compression:
- Filnamn, sökvägar och format ändras inte.
icon-home.pngförbliricon-home.png, ingen ändring av referenser i koden krävs. - Dra hela mappen in. Den skannar rekursivt alla undermappar och hoppar automatiskt över dolda filer och
node_modules. Dra inimages/,static/eller till och med hela projektmappen, och efter komprimeringen ser du direkt storleksändringen i utvecklarverktygen. - Originalet flyttas till papperskorgen som standard. Om du inte är nöjd med en bild kan du högerklicka på "Återställ" för att få tillbaka den. Om projektet är i Git finns det dessutom en extra säkerhetsnivå.
- Kör helt lokalt, ingen uppladdning till nätverket. Projektets material lämnar aldrig din dator, och det finns inga gränser för antal bilder eller storlek på online-komprimeringssajter.
Gällande bildkvalitet är hanteringen olika beroende på format, så här är det tydligt:
- PNG: använder oxipng för förlustfri komprimering, pixlar förblir oförändrade. I Mini Program finns det många ikoner och klipp som är PNG, så det kan komprimeras med gott samvete.
- SVG: rensar redundant markup, också förlustfri.
- JPG / WebP / GIF etc.: är kodad med förlust, parametrarna är justerade för visuellt förlustfria intervall – det är svårt att se skillnad med ögat. Det är inte nödvändigt att lita på förtroende; ett inbyggt jämförelsefönster (
⌘D) kan visa bilderna uppdelade och zoomade in till enskilda pixlar för att dubbelkolla.
Två andra punkter är också värd att veta:
- Det kommer inte att tvinga komprimera bilder som redan är komprimerade till max: filer med en komprimeringsgrad på under 0,4% markeras som "redan minst" och behålls oförändrade, så att bilden inte blir suddig bara för att siffran ska se bra ut. Så om dina bilder redan har optimerats noga, kan denna steg kanske inte spara så mycket – det är normalt, och visar att det är dags att skifta till underpaket.
- Det ändrar inte format eller upplösning. PNG förblir PNG efter komprimering, storleken på bilden ändras inte. Om du vill byta till WebP eller sänka en 3x-bild till en 2x-bild, är det en annan sak som måste hanteras separat.
Hur mycket man kan spara beror på hur bilderna exporterades ursprungligen, så vi ger inga generella procenttal. Som referens har vi gjort två offentliga tester: en batch JPG som redan var komprimerad vid webbplatsinläggning sparade ytterligare 46,8%; en batch JPG direkt från kameran sparade 76,8% (se "ImgZilla testade"-serien). Bilder i Mini Program är ofta exporterade direkt från designverktyg och har oftast inte blivit noga komprimerade, så det är värt att köra igen först.
ImgZilla finns för närvarande endast för macOS (macOS 12.3 och senare), kan laddas ner från Mac App Store, 10 bilder per dag är gratis. För studenter som utvecklar på Windows är tanken i detta avsnitt densamma, bara byt ut verktyget mot ett som också kan "behålla originalets filnamn".
Metod 4: Flytta stora bilder till CDN
Efter att ha komprimerat dem är det fortfarande stora bilder – till exempel aktivitets-bannrar, långa bilder på detaljsidor, stora produktbilder – som inte borde ligga i paketet. Ladda upp dem till objektlagring eller CDN och byt ut lokala adresser mot nätverksadresser i koden, så blir huvudpaketet omedelbart lättare.
Men det är inte gratis:
- Första gången man laddar måste gå via nätverket, det kan uppstå en lucka vid svaga nätverksanslutningar, så det är bäst att kombinera med platshållarbilder eller skelettsskärmar.
- Man måste underhålla en process för uppladdning, cache och uppdatering.
- CDN debiteras per trafik. Varje gång en bild laddas kostar det, trafikavgiften är ungefär "bildstorlek × antal visningar". Så innan man flyttar till CDN är det värt att komprimera bilderna först – komprimera en gång, och sedan sparar det trafik vid varje efterföljande visning.
Metod 5: Slutförande på kodnivå
När bilder och struktur är hanterade kan den återstående små biten frigöras från koden:
- I utvecklarverktygen kolla "Detaljer → Lokala inställningar" och markera "Komprimera skript, stil, WXML vid uppladdning".
- Aktivera
"lazyCodeLoading": "requiredComponents"iapp.(on-demand injection). Det förbättrar främst starttiden snarare än paketstorlek, men eftersom vi redan gör prestanda-optimering, kan vi aktivera båda. - Kolla
miniprogram_npm: om det byggda npm-paketet har en fullmängds-import fast man bara använder ett par funktioner. - Stora mängder statisk data skrivna hårt in i JS (stadslistor, konfigurationstabeller) kan övervägas att ändra till att hämtas via API.
Sammanfattning i en tabell
| Metod | Hur mycket kan sparas | Hur mycket ändring krävs | Rekommenderad ordning |
|---|---|---|---|
| Ta bort onödiga filer | Beror på projektets historik | Nästan ingenting | 1 |
| In-place komprimering av bilder | Ju fler bilder och desto slarvigare exporterade, desto mer kan sparas | Nästan ingenting, sökvägar förblir desamma | 2 |
| Underpaket | Kan vara mycket | Mappstruktur och router måste ändras | 3 |
| Flytta stora bilder till CDN | Mycket | Måste ändra referenser och underhålla uppladdningsprocess | 4 |
| Kodkomprimering och on-demand import | Mindre | Beror på situation | 5 |
Logiken bakåt är enkel: gör först de mindre ändringarna, sedan de större. Att ta bort filer och komprimera bilder rör nästan inte affärskoden. Gör det först och se hur stort huvudpaketet är – om det redan är under 2MB kan versionen släppas idag; om det inte räcker än, gå sedan vidare med underpaket och CDN, så vet du också var du står.
Att huvudpaketet överskrider gränsen händer ofta precis innan lanseringen. Att lägga till bildkomprimering i den dagliga processen – komprimera alltid innan du lägger till en ny bild – så behöver du inte oroa dig för den röda texten precis innan deadline nästa gång.