Yükle'ye tıklayınca, geliştirici aracı bir satır kırmızı yazı gösterir: Ana paket boyutu 2MB sınırını aşıyor. Sürüm gönderilemiyor, talepler sıraya giriyor.
Bu makale temel teorinin tamamını anlatmaz; sadece 'daha çok tasarruf edin, daha az değiştirin' sırasına göre ana paketi 2MB'ye indirecek yöntemleri listeler.
Önce netleştirin: 2MB aslında nereyi kısıtlıyor
WeChat, Mini Program kod paketleri için iki katı sınırya sahiptir:
| Sınır | Üst Limit |
|---|---|
| Ana Paket (app.js, tabBar sayfaları, ortak kaynaklar vb.) | 2MB |
| Tek bir alt paket | 2MB |
| Tüm Mini Program paketlerinin toplamı | 20MB |
Buradaki 'boyut' yalnızca yüklenen kod paketi hacmidir, sadece JS değil. Proje dizinindeki pakete alınacak tüm dosyalar sayılır: .js, .wxml, .wxss, ., fontlar, sesler ve -genellikle en büyük kısmı oluşturan- resimler.
Bu 'basınacak olmazsa sürüm yayınlamazsın' gibi sert bir sınırdır, 'biraz daha optimize edilebilir' değildir. Bu yüzden ilk adım dokunmak değil, önce nereye para harcadığını görmektir.
Adım 0: Ana pakette yer kaplayan neyi netleştirin
WeChat geliştirici araçlarının sağ üst köşesindeki 'Detaylar -> Temel Bilgiler', yerel kod paketinin toplam boyutunu gösterebilir; daha detaylı olanı araç çubuğundaki **'Kod Bağımlılık Analizi'**da, dosyaları boyutlarına göre listeleyip hangi dosyaların hiçbir sayfa tarafından kullanılmadığını işaretleyebilir.
Çoğu proje bu tabloyu gördükten sonra aynı şeyi fark eder: Resimler ve font gibi statik kaynaklar, iş kodundan çok daha büyüktür. JS binlerce satır yazsa bile sadece yüzlerce KB olur, işlenmemiş bir banner resmi yüzlerce KB olabilir, bir images/ dizini ana paketin yarısını yiyebilir.
Aşağıda kazanç (tasarruf) büyüklüğüne göre sıralanmıştır.
Yöntem 1: Hiç kullanılmayan dosyaları silin
En az iş ve en çok ihmal edilen yöntem.
- 'Kod Bağımlılık Analizi'da 'kullanılmayan' olarak işaretlenmiş dosyalar: Geçmiş sürüm kalıntıları, iptal edilmiş sayfalar, test resimleri doğrudan silin.
- Pakete girmesi gereken dosyalar değil: Taslak dosyaları, README, .psd, orijinal materyaller, Mock verileri. Proje dizininden çıkarılabilirse çıkarın; çıkarılamıyorsa
project.config.içindepackOptions.ignorekullanarak dışlayın:
{
"packOptions": {
"ignore": [
{ "type": "folder", "value": "design" },
{ "type": "suffix", "value": ".psd" }
]
}
}
- Bütün bileşen kütüphanesini dahil etmek: Sadece üç bileşen kullanıyorsanız bile tüm UI kütüphanesini ana pakete koymak yaygın bir 'görünmez şişmanlık'tır. İhtiyaç üzerine dahil etmeye (on-demand import) çevirin, sadece kullanılan bileşen dizinlerini tutun.
Yöntem 2: Alt paketler - İlk ekran olmayan sayfaları ana paketten çıkarın
Bu resmi olarak verilen doğru çözümdür. Ana pakete sadece giriş sayfasını, tabBar sayfalarını ve gerçekten ihtiyaç duydukları ortak kodu bırakın, geri kalan sayfaları iş mantığına göre alt paketlere bölün:
{
"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"] }
}
}
Bazı noktalar:
- Kaynaklar sayfayla birlikte gider: Alt paket sayfasının kullandığı resimler ve bileşenler alt paket dizinine konmalıdır. Ana paketteki ortak
images/dizinindeyse, alt paket ne kadar bölünse bölünsün, hacim ana pakete yine de yansır. preloadRulealt paket ön yükleme: Giriş sayfasına gittiğinizde, kullanıcı girdiğinde neredeyse gecikme hissetmeyeceği için muhtemel olarak kullanılacak alt paketleri indirin.- Bağımsız alt paket (
"independent": true): Etkinlik sayfaları, açılış sayfaları gibi ana pakete bağımlı olmadan açılabilecek sayfalar için uygundur, başlatılmada ana pakete bağımlı değildir. - Alt paketler arası asenkron kullanım: Bir bileşeni veya JS'yi farklı alt paketlerden kullanırken, 'paylaşım' için kodu ana pakete tekrar çekmemek için yer tutucu bileşenler ve
require.asynckullanabilirsiniz.
Alt paketlerin maliyeti, dizin yapısı ve yönlendirme yollarını değiştirmektir. Eski projeleri bölmek iş yükü doğurur, bu yüzden aşağıdaki adımı önce yapmak değerli -çok zamanında ana paket zaten 2MB'nin altına iner.
Yöntem 3: Resimleri küçültün (En az değişiklik, en doğrudan kazanç)
Ana paketteki 'boş yere şişen' en kolay kısım resimlerdir. Tasarımcının dışa aktardığı PNG'ler gereksiz veri bloklarıyla birlikte gelir, JPG kalite parametreleri çok yüksektir; bu baytlar kullanıcı göremez ama her biri 2MB'ı doldurur.
Pakete kalmak zorunda olan resimler
Tüm resimleri CDN'ye taşıyamazsınız:
- TabBar ikonları:
iconPath/selectedIconPathyalnızca yerel yolları destekler, web resimlerini desteklemez. - Giriş sayfası, ilk ekran Logosu, yedek yer tutucu resimleri: Zayıf ağ veya çevrimdışıyken bile görüntülenmelidir.
- Sıkça görünen küçük ikonlar: Her seferinde ağ isteği yapmak verimsizdir.
Bu resimler pakete kalmak zorunda olduğu için, tek çözüm onları daha küçük yapmaktır.
Bir tuzak: wxss içindeki arka plan resimleri
.wxss içinde background-image ile yerel resim kullanmak gerçek cihazda çalışmaz; yaygın çözüm base64 olarak satır içine almaktır. Ancak base64 kodlaması hacmi yaklaşık %33 artırır ve bu kod, stil dosyasının içinde saklıdır, bağımlılık analizi'nde çok belirgin değildir. <image> bileşenine veya web resmine çevirilebiliyorsa satır içi yapmayın; zorunluysa önce orijinal resmi sıkıştırıp sonra çevirin.
ImgZilla ile tüm kaynak dizinini yerinde sıkıştırın
Mini Program geliştirirken en büyük korku, sıkıştırmadan sonra yolları değiştirmektir - wxml, wxss, JS yapılandırması, tabBar yapılandırmasında, her yerde /images/xxx.png var. Birçok sıkıştırma aracı xxx-min.png olarak kaydeder veya farklı bir klasöre aktarmanızı ister, ardından manuel olarak değiştirmeniz ve eksik olup olmadığını tekrar kontrol etmeniz gerekir.
ImgZilla macOS'da bir resim sıkıştırma aracıdır; yaklaşımı yerinde sıkıştırmaktır:
- Dosya adı, yol, format değişmez.
icon-home.pngsıkıştırıldığında yineicon-home.pngkalır, kodda bir referans değişikliği yapmanıza gerek kalmaz. - Tam dizini sürükleyip bırakın. Tüm alt dizinleri özyinelemeli olarak tarar ve gizli dosyaları ve
node_modules'u otomatik olarak atlar.images/,static/veya hatta tüm proje dizinini sürükleyin, sıkıştırdıktan sonra geliştirici araçlarında paket hacmindeki değişimi doğrudan görün. - Orijinal resimler varsayılan olarak çöp kutusuna taşınır, hangisini beğenmediğinizse sağ tıklayıp 'Eskisine geri koyun'. Git projeniz varsa, ekstra bir katman güvence sağlar.
- Her zaman yerel çalışır, internete yüklenmez. Şirket projelerinin materyalleri bilgisayarınızdan çıkmaz, çevrimiçi sıkıştırma sitelerindeki tek seferlik resim sayısı veya dosya boyutu sınırlaması yoktur.
Kalite konusunda, farklı formatların işlenme şekilleri farklıdır, burada netleştirelim:
- PNG: oxipng kullanılarak kaybızsıkıştırma yapılır, piksellerde hiçbir değişiklik olmaz. Mini Program'deki çok sayıda ikon, kesit resmi PNG'dir, bu kısmı rahatça sıkıştırabilirsiniz.
- SVG: Gereksiz etiketleri temizleyerek de kaybızsıkıştırma yapılır.
- JPG / WebP / GIF vb.: Kayıplı yeniden kodlamadır, parametreler her format için görsel kayıpsız aralığa ayarlanmıştır - gözlere hemen fark edilecek kadar az fark vardır. Güvenmek yerine, iç içe geçmiş pencere (
⌘D) sağa sola bölünür, gerçek piksellere yakınlaştırılarak karşılaştırılabilir.
İki nokta daha da önemlidir:
- Zaten en aza indirilmiş resimler zorla sıkıştırılmaz: Sıkıştırma oranı %0.4'ten düşük olan dosyalar 'en aza indirildi' olarak işaretlenir, orijinal olarak tutulur, sadece iyi görünecek sayılar için resimleri bulandırma.
- Format veya çözünürlük değiştirmez. PNG sıkıştırıldığında yine PNG kalır, boyut değişmez. WebP'e dönüştürmek veya 3 katlı resmi 2 katlıya indirmek başka bir işlemdir, ayrı ayrı yapılması gerekir.
Ne kadar tasarruf sağlayabileceğiniz, resimlerin nasıl dışa aktarıldığına bağlıdır, burada genel bir oran sunmuyoruz. Referans olarak, iki kez açık test yaptık: Bir websitesine yüklenmeden önce sıkıştırılmış bir JPG seti, tekrar sıkıştırıldığında hala %46.8 tasarruf sağladı; bir kamera çıkışı JPG seti %76.8 tasarruf sağladı (ayrıntılar için 'ImgZilla Gerçek Test' serisine bakın). Mini Program'deki resimler genellikle tasarımcı araçlarından doğrudan dışa aktarılır, genellikle ciddiye sıkıştırılmamıştır, bu yüzden önce çalıştırmak değerli.
ImgZilla şu anda sadece macOS sürümü vardır (macOS 12.3 ve üzeri), Mac App Store'dan indirilebilir, günde 10 resim ücretsiz sıkıştırılır. Windows ile geliştirenler için bu bölümün mantığı aynıdır, yine de dosya adını koruyan bir araç bulabilirsiniz.
Yöntem 4: Büyük resimleri CDN'ye taşıyın
Sıkıştırdıktan sonra bile çok büyük olan resimler -örneğin etkinlik banner'ları, detay sayfası uzun resimleri, ürün büyük resimleri- aslında pakete koymak için uygun değildir. Nesne depolama veya CDN'ye yükleyin, kodda web adresiyle değiştirin, ana paket anında hafifler.
Ancak bu ücretsiz değildir:
- İlk yüklemede ağ trafiği gerekir, zayıf ağda boşluk oluşabilir, en iyi çözüm yer tutucu resim veya skelet ekranı ile eşleşir.
- Yükleme, önbellekleme, güncelleme akışını yönetmek gerekir.
- CDN bant genişliği başına ücretlidir. Her resim yüklemede para harcanır, bant genişliği ücreti yaklaşık 'resim hacmi × erişim sayısı''dır. Bu yüzden CDN'ye taşımadan önce resimleri sıkıştırmak değerli -tek seferlik sıkıştırma, her sonraki erişimde bant genişliği tasarrufu sağlar.
Yöntem 5: Kod seviyesinde son dokunuşlar
Resimler ve yapı işlendiğinde, geri kalan ufak boşlukları koddan çıkarmak mümkündür:
- Geliştirici araçlarındaki 'Detaylar -> Yerel Ayarlar'da, yüklemede script, stil, WXML'i sıkıştırma seçeneğini işaretleyin.
app.içinde"lazyCodeLoading": "requiredComponents"(ihtiyaç üzerine dahil etme) açın. Bu aslında başlatma hızını değil, paket hacmini iyileştirir, ancak performans optimizasyonu yapıyorsanız birlikte açın.miniprogram_npmkontrol edin: oluşturulan npm paketinde, sadece birkaç fonksiyonu kullanırken tüm paketi dahil etme durumu olup olmadığına bakın.- JS içinde yazılmış büyük miktarda statik veri (şehir listesi, yapılandırma tabloları) API üzerinden gelmeye dönüştürün.
Özet Tablo
| Yöntem | Ne kadar tasarruf sağlar | Ne kadar değişiklik gerekir | Önerilen Sıra |
|---|---|---|---|
| Kullanılmayan dosyaları silme | Projenin geçmiş yüküne bağlı | Çok az | 1 |
| Resimleri yerinde sıkıştırma | Resimler ne kadar çok, dışa aktarma ne kadar keyfiyse, o kadar tasarruf sağlar | Neredeyse yok, yol değişmez | 2 |
| Alt paketler | Çok fazla olabilir | Dizin ve yönlendirme değişir | 3 |
| Büyük resimleri CDN'ye taşıma | Çok fazla olabilir | Referans değişikliği, yükleme akışı yönetimi gerekir | 4 |
| Kod sıkıştırma ve ihtiyaç üzerine dahil etme | Daha az | Duruma göre | 5 |
Sıralamanın mantığı basittir: Önce az değişiklik, sonra büyük değişiklik. Dosya silme ve resim sıkıştırma neredeyse iş koduna dokunmaz, sonra ana pakette ne kadar eksik olduğunu görün - eğer zaten 2MB'nin altına inmişse, o sürümü bugün yayınlayabilirsiniz; yeterli değilse, alt paketlere ve CDN'ye geçin, net bir planınız olur.
Ana paket sınırlaması genellikle yayın öncesi en stresli anlarda oluşur. Resim sıkıştırmayı günlük iş akışına alın - her yeni resim eklemeden önce sıkıştırın - bir dahaki sefere son teslim tarihine kadar o kırmızı yazıyı düşünmek zorunda kalmazsınız.