WeChat mini programı uzun süredir AppService ile WebView’in ikili iş akışı modeli üzerine kurulmuştur. Resmi “Skyline Render Motoru Tanıtımı”nda kabul edildiğine göre: Web’in ağır geçmiş yükü, mantık ile renderin aynı tip iş akışında bir araya getirilmesi durumunda, arayüzün scriptler tarafından tıkanmasına yol açabilir. Skyline, Layout, Composite ve Paint işlemlerini üstlenen ayrı bir render iş akışını başlatmakta; ayrıca WebView’in eski görevini üstlenen JS ve yapılandırma mantığını AppService içinde ayırarak yerleştirmektedir. Sonuç olarak, sayfaların mantık tarafından daha az sıkışması, her sayfa için yeni bir JS motoru kurmaya gerek kalmaması, sayfalar arasında daha fazla kaynak paylaşımı mümkün hale gelmesi ve çerçeve içi JSBridge trafiğinin azalması sağlanmaktadır. Temel kütüphane 3.0.0’un resmi sürümüyle eş zamanlı olarak sunulan çevrimiçi gözlemlere göre: Tıklama ile tam render (LCP) süresi, WebView’de 2492 milisaniyeden Skyline’da 2052 milisaniyeye düşmüş; bu da yaklaşık %17,6’lık bir azalma demektir. Çerçeve tarafından yapılandırılma sürecinden tam rendera geçen süre ise 626 milisaniyeden 312 milisaniyeye inmiş; bu da yaklaşık %50’lik bir düşüşe karşılık gelmektedir. Bunlar, hali hazırda yayında olan mini programlara ait istatistiklerdir; laboratuvar ortamındaki en yüksek değerler değil; bu nedenle bunlar, sözleşmede garanti edilen değerler olarak değil, taşımada beklenen sonuçlar olarak değerlendirilmelidir.
Birincisi, uyumluluk bir avantaj, kademeli geçiş ise bir disiplindir.
Resmi açıklama şunu vurgulamaktadır: Skyline’nin yeni özelliklerini kullanmayan kod, düşük sürümlerde veya desteklenmeyen platformlarda WebView’e geri dönerek çalışacaktır. WXS, AppService’e taşındıktan sonra, sayfa bilgilerini okuyan arayüzler asenkron hale gelecek; karmaşık animasyonlar ise render iş akışına daha yakın olan Worklet’ler kullanılarak yeniden tasarlanmalıdır. Taşımanın en iyi uygulamaları sırayı kesin olarak belirlemektedir: Önce ihtiyaç duyulan bileşenlerin önyükleme işlemi başlatılmalı ve yan etkiler test edilip kontrol edilmelidir; ardından Skyline tek tek sayfalarda açılmalıdır. Mevcut projelerde öncelikle kritik yollar taşınmalıdır; yeni sayfalar varsayılan olarak Skyline’da açılmalıdır; tamamen yeni projelerde ise bellek tasarrufu amacıyla tüm sistemde Skyline global olarak açılabilmektedir. İlk haftada tüm siteyi birden değiştirmemelisiniz; aksi takdirde, stil optimizasyonundan kaynaklanan hizalama sorunları performans kazanımlarını uyumluluk listesinde kaybedebilir.
1.1 Neden önce ihtiyaç duyulan bileşenlerin önyükleme işlemini yapmalıyız?
Skyline, ihtiyaç duyulan bileşenlerin önyükleme işlemine dayanmaktadır. Bu işlem açıklandığında, bazı sayfaların davranışları değişecektir; resmi açıklama, uyumluluk sorunlarını önceden çözülmesini gerektirmektedir. Pek çok ekip, “paket boyutu optimizasyonu”nu yalnızca görselleri küçültmek olarak algılamakta; buna rağmen ana paketin tüm sayfaların JS’lerini taşımasına devam etmektedir. Ancak ihtiyaç duyulan bileşenlerin önyükleme işlemi ve bölünmüş paketler bir araya geldiğinde, Skyline’nin paylaşılan motor avantajı ortaya çıkabilmektedir: Birden fazla Skyline sayfası aynı render örneği üzerinde çalışırken, genel stiller ve ortak kodlar sayfa başına tekrar kopyalanmak zorunda kalmaz.
İkincisi, bölünmüş paketler ve önyükleme kullanıcıların sabrına bağlıdır.
Ana pakette yalnızca başlangıç ve ana sayfa için gerekli olanlar kalacaktır. Liste, sipariş, benim ve etkinlik sayfaları ayrı ayrı bölünmüş paketler halinde hazırlanacaktır; paylaşım kartından doğrudan ulaşılabilen detay sayfaları da ayrı bölünmüş paket olabilir; ancak app.js ve genel durum gibi unsurların doğrudan okunamamasının bedelini kabul etmek gerekecektir. Önyükleme kuralları, gerçekten sonraki aşamaya geçilecek sayfalara yazılmalı ve mümkün olduğunca Wi‑Fi ağında sınırlanmalıdır. Kullanıcılar, WebView’i önceden ısıtmak gibi bir yöntemle Skyline’yı otomatik olarak önceden ısıtmayacaktır; resmi açıklama kapsamında wx.preloadSkylineView fonksiyonu sunulmaktadır; Skyline sayfasına geçişin muhtemel olduğu yollarda, onShow olayı sırasında çağrı yapılmasını önermektedir; böylece dönüşte yeniden soğuk başlatma maliyeti önlenebilir.
| Konu | |||
|---|---|---|---|
Skyline taşımasının rakibi, WebView değil, “bir seferde düzeltmeyi” hedefleyen bir takvimdir. İhtiyaç duyulan bileşenlerin önyükleme işlemini ilk haftaya, iki kritik sayfayı ikinci haftaya, uzun listeleri ise üçüncü haftaya ayırmak, “tam Skyline dönüşü” adlı çeyreklik bir proje planından daha yakındır ve resmi en iyi uygulamalara daha uygun bir yaklaşım sunar. Kritik yollar stabilize olunca, yeni sayfalar varsayılan olarak yeni motoru kullanmaya başlayacaktır—bu değişikliği kullanıcılar önce parmaklarında hissedecek, sürüm açıklamalarında okumayacak.