Klik på 'Upload', og udviklerværktøjet viser en rød linje: Hovedpakkestørrelsen overstiger 2MB-grænsen. Versionen kan ikke uploades, og kravene venter stadig på kø.
Denne artikel forklarer ikke en teoretisk gennemgang, men lister kun metoder til at presse hovedpakken under 2MB, sorteret efter 'hvor meget der kan spares' og 'hvor lidt der skal ændres'.
Først forstå: hvad begrænser 2MB?
WeChat har to hårde øvre grænser for kodepakker:
| Begrænsning | Øvre grænse |
|---|---|
| Hovedpakke (inkl. app.js, tabBar-sider, fællesressourcer osv.) | 2MB |
| Enkel underpakke | 2MB |
| Samlet størrelse for alle pakker i appen | 20MB |
Vær opmærksom på, at 'størrelsen' her er den uploadede kodepakkestørrelse, ikke kun JS. Alle filer i projektmappen, der bliver pakket ind, tæller: .js, .wxml, .wxss, ., skrifttyper, lyd og – typisk den største andel – billeder.
Dette er en hård begrænsning, hvor du ikke kan presse ned, før versionen ikke kan udgives. Det er ikke en 'optimering der gør det bedre', så det første trin er ikke at gribe ind, men først at se, hvor pengene bruges.
Trin 0: Se, hvad der fylder hovedpakken
I WeChat-udviklerværktøjet kan du se den samlede størrelse af den lokale kodepakke i højre hjørne under 'Detaljer → Grundlæggende oplysninger'; for mere detaljeret information kan du bruge 'Kodeafhængighedsanalyse' i værktøjslinjen, som viser størrelsen efter fil og markerer filer, der ikke bliver refereret af nogen side.
De fleste projekter opdager det samme, når de ser på denne tabel: statiske ressourcer som billeder og skrifttyper fylder meget mere end forretningskoden. JS kan skrives i hundredvis af linjer, men en ubehandlet banner-billede kan allerede fylde hundredvis af KB, og en images/-mappe kan nemt spise halvdelen af hovedpakken.
Nedenfor er rækkefølgen efter indflydelse fra stor til lille.
Metode 1: Slet filer, der ikke bruges
Den nemmeste metode, som ofte overses.
- Filer markeret som 'ikke refereret' i 'Kodeafhængighedsanalyse': Gamle ikoner fra tidligere versioner, forladte sider, testbilleder – bare slet dem.
- Filer, der ikke skal i pakken: Designskisser, README,
.psd, oprindelige materialer, Mock-data. Flyt dem ud af projektmappen; hvis det ikke er muligt, kan du brugepackOptions.ignoreiproject.config.til at udelukke dem:
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Helt bibliotek af komponenter importeret: Det er almindeligt at importere hele UI-biblioteket, selvom man kun bruger tre komponenter. Skift til import på kravbasis og behold kun de komponentmapper, der bruges.
Metode 2: Underpakker – flyt ikke-førsteside-sider ud af hovedpakken
Dette er den officielle løsning. Hovedpakken skal kun indeholde startside, tabBar-sider og deres nødvendige fælles kode; resten af siderne kan deles op i underpakker baseret på forretningskrav:
{
"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"] }
}
}
Nogle punkter:
- Ressourcer følger med siden: Billeder og komponenter, som en underpakkeside bruger, skal placeres i underpakke-mappen. Hvis de ligger i den fælles
images/i hovedpakken, tæller underpakke-opdelingen stadig hovedpakken som størrelse. preloadRulefor forhåndsinlæsning af underpakker: Når man kommer ind på startsiden, kan man hente den underpakke, man sandsynligvis skal bruge næste gang, så brugeren ikke mærker forsinkelsen.- Uafhængig underpakke (
"independent": true): Passer til aktivitetssider, landningssider og andre sider, der kan åbnes uafhængigt af hovedpakken uden at afhænge af den ved opstart. - Asynkron underpakker: Når man refererer komponenter eller JS kryds underpakker, kan man bruge pladsholdere og
require.asyncfor at undgå, at man skal løfte koden tilbage til hovedpakken for at dele den.
Prisen for underpakker er, at man skal ændre mappestruktur og navigationsstier. Det kan være en stor opgave at splitte ældre projekter op, hvilket er grunden til, at det er værd at gøre følgende trin først – ofte er hovedpakken allerede under 2MB efter det.
Metode 3: Komprimer billeder (mindst ændringer, mest direkte gevinst)
Billeder er den del af hovedpakken, der oftest er 'overflødige'. Designere eksporterer PNG-filer med ekstra datablokke, og JPG bruger ofte højere kvalitetsparametre. Disse bytes kan brugeren ikke se, men hver eneste af dem tæller i 2MB.
Hvilke billeder skal være i pakken
Ikke alle billeder kan flyttes til CDN:
- TabBar-ikoner:
iconPath/selectedIconPathkan kun være lokale stier, de understøtter ikke netværksbilleder. - Startside, første skærm Logo, fallback-pladsholdere: Skal stadig kunne vises under svag netværk eller offline.
- Lille ikoner, der bruges ofte: At hente dem hver gang via netværk er ikke økonomisk.
Disse billeder kan kun være i pakken, så den eneste metode er at gøre dem mindre.
Undgå en fælde: baggrundsbilleder i wxss
Brug af background-image til at referere til lokale billeder i .wxss virker ikke på rigtige enheder. Den almindelige løsning er at konvertere til base64 inline. Men base64-kodning vil få størrelsen til at udvide med ca. en tredjedel, og den gemmer sig i stil-filen, så den er ikke så tydelig i afhængighedsanalysen. Hvis det kan ændres til <image>-komponent eller et netværksbillede, så gør det; hvis det ikke kan undgås, så komprimer originalbilledet først.
Brug ImgZilla til at komprimere hele ressourcer-mappen på stedet
Det værste ved at arbejde med Mini Program er, at man skal rette stier efter komprimering – i wxml, wxss, JS-konfiguration, tabBar-konfiguration osv. Mange værktøjer gemmer som xxx-min.png eller kræver, at man eksporterer til en anden mappe, hvilket kræver manuel udskiftning og dobbelttjek efterfølgende.
ImgZilla er et billedkomprimeringsværktøj til macOS, der gør komprimering på stedet:
- Filnavn, sti og format ændres ikke.
icon-home.pngforblivericon-home.png, så ingen ændringer i koden er nødvendig. - Træk hele mappen ind. Den scanner rekursivt alle undermapper og hopper automatisk over skjulte filer og
node_modules. Trækimages/,static/eller hele projektet ind, og se størrelsesændringen direkte i udviklerværktøjet. - Originalfilen flyttes til papirkurven som standard. Hvis du ikke er tilfreds med et billede, kan du højreklikke på det for at 'flytte tilbage'. Hvis projektet er i Git, er der en ekstra sikkerhedslag.
- Kører lokalt, ikke over nettet. Materialer til virksomhedsprojekter forlader aldrig din computer, og der er ingen grænser for antal billeder eller størrelse på online-komprimeringssider.
Når det gælder billedkvalitet, håndteres forskellige formater forskelligt:
- PNG: Bruger oxipng til uden tab-komprimering; ingen pixel ændres. Mange ikoner og beskæring i Mini Program er PNG, så dette kan trygt komprimeres.
- SVG: Rydder op i unødvendige mærker, også uden tab.
- JPG / WebP / GIF osv.: Er omkodning med tab; parametrene er indstillet til at være visuelt uden tab – det er svært for øjet at se forskel. Du behøver ikke stole på tro, men der er et indbygget sammenligningsvindue (
⌘D) for at se billederne side om side og forstørre til pixels.
To andre punkter er værd at vide:
- Det komprimerer ikke billeder, der allerede er komprimeret til bunden: Filer med en komprimeringsrate under 0,4 % markeres som 'allerede minimal', og beholder originalen, så den ikke bliver sløret for at få et bedre tal. Så hvis dine billeder allerede er blevet korrekt optimeret, kan denne metode ikke spare meget – det er normalt, og det viser, at man bør skifte til underpakker.
- Det ændrer ikke format eller opløsning. PNG forbliver PNG efter komprimering, og størrelsen er uændret. Hvis du vil ændre til WebP eller reducere 3x-billeder til 2x, er det en anden sag, der skal håndteres separat.
Hvor meget der kan spares, afhænger af, hvordan billederne blev eksporteret. Vi giver ikke et generelt procenttal. Som reference har vi udført to offentlige tester: En gruppe JPG, der allerede var komprimeret før indsamling til en hjemmeside, sparte 46,8 % ved en ekstra gang; en gruppe direkte fra kameraet sparte 76,8 % (se 'ImgZilla-test-serien'). Billeder i Mini Program er ofte direkte eksporteret fra designværktøjer og er typisk ikke blevet korrekt komprimeret, så det er værd at køre igennem en gang.
ImgZilla er i øjeblikket kun til macOS (macOS 12.3 eller nyere) og kan downloades fra Mac App Store. Du kan komprimere 10 billeder gratis om dagen. Hvis du udvikler på Windows, er principperne herfra stadig gyldige, så bare brug et andet værktøj, der også 'beholder filnavn'.
Metode 4: Flyt store billeder til CDN
Efter komprimering er der stadig billeder, der er meget store – såsom aktivitets-bannere, lange detaljesider, store produktbilleder – som egentlig ikke bør være i pakken. Upload dem til objektlagring eller CDN, og brug netværksadressen i koden. Hovedpakken bliver straks lettere.
Men det er ikke gratis:
- Den første indlæsning skal gå over nettet, og der kan være en tom periode under svagt netværk; det er bedst at bruge pladsholdere eller skelett-skærme.
- Man skal vedligeholde en proces for upload, caching og opdatering.
- CDN betales baseret på trafik. Hvert billede, der indlæses, koster penge. Trafikomkostninger svarer lidt til 'billedstørrelse × antal visninger'. Så det er også værd at komprimere billederne, før de flyttes til CDN – én komprimering, og hver gang de indlæses, sparer du trafik.
Metode 5: Slut med kodensign
Når billeder og struktur er håndteret, kan de sidste resterende plads hentes ud af koden:
- I udviklerværktøjet kan du markere 'Komprimer script, stil, WXML ved upload' under 'Detaljer → Lokale indstillinger'.
- Slå
"lazyCodeLoading": "requiredComponents"til iapp.(on-demand injection). Dette forbedrer primært starthastigheden snarere end pakkestørrelsen, men da man alligevel optimerer ydeevne, er det godt at slå det til samtidig. - Tjek
miniprogram_npm: Er der npm-pakker, der importeres som helhed, men kun bruger en eller to funktioner? - Overvej at ændre store mængder statiske data (bygge-liste, konfigurationstabeller) til at blive hentet via API.
En tabel til opsummering
| Metode | Hvor meget der kan spares | Hvor meget der skal ændres | Anbefalet rækkefølge |
|---|---|---|---|
| Slet ubrugte filer | Afhænger af projektets historie | Lidt | 1 |
| Komprimer billeder på stedet | Jo flere billeder, jo mere sløst eksporteret, jo mere der kan spares | Næsten intet, stier ændres ikke | 2 |
| Underpakker | Kan være meget | Må ændre mapper og ruter | 3 |
| Flyt store billeder til CDN | Mange | Skal ændre referencer og vedligeholde upload-proces | 4 |
| Kodekomprimering og on-demand import | Lidt | Afhængig af situationen | 5 |
Logikken er simpel: Gør først ændringer, der er små, så gør ændringer, der er store. Sletning af filer og komprimering af billeder rører ikke forretningskoden; efterfølgende kan man se, hvor meget der stadig mangler i hovedpakken – hvis den allerede er under 2MB, kan versionen udgives i dag; hvis ikke, kan man gå til underpakker og CDN, og har en klar plan.
Hovedpakkegrænsen overskrides ofte lige før lanceringen, når der er travlt. Sæt billedkomprimering ind i den daglige proces – komprimer alt nyt billede, før det lægges ind – så skal man ikke mere være bekymret for den røde tekst ved fristen.