Çapraz platform geliştirme konusunda deneyimli: küçük programların mevcut ve gelecekteki olasılıkları gözlerimde
Büyük platformlarda küçük programların hızla büyümesiyle, geliştiriciler gittikçe daha fazla platform uyarlama sorunuyla karşılaşıyor. Farklı platformlardaki küçük programların performans optimizasyon yöntemleri de farklı, bununla nasıl başa çıkmalıyız? DCloud CTO'su Cui Hongbao, GMTC Shenzhen 2019'da (Küresel Büyük Ön Uç Teknoloji Konferansı) "Mini Programların Geleceğin Yönü" nü paylaşarak her platformun teknik mimarisini, performans sıkışmış noktalarını ve optimizasyon çözümlerini tanıttı. Mini programların gelecekteki teknolojik değişiklikleri için öneride bulundu. Mini programların gelecekteki olası gelişme yönü. Bu makale konuşmanın içeriğine göre düzenlenmiştir.
Kendimi kısaca, orta yaşlı bir kod çiftçisi ve platformlar arası geliştirme alanında deneyimli bir kişiyi tanıtın. Flip Motorola cep telefonlarının gelişmiş ve modayı temsil ettiği o dönemde platformlar arası Ar-Ge'ye ve "pencere mobil / j2me / symbain" gibi sistemlerin yönetimine katılmaya başladım, belki birçok öğrenci bu cep telefonlarını hiç görmemiş. Daha sonraki mobil İnternet çağında ve mevcut küçük program çağında, buna derinden dahil oldum ve "Hibrit Uygulama" motorunu, ön uç UI kitaplığını (mui) ve küçük programlar için (tekli uygulama) çapraz uç geliştirme çerçevesini çıkarmaya devam ettim. Şu anda DCloud'un CTO'su ve "uni-app" ürün lideri olarak hizmet veriyor.
Roma bir günde inşa edilmedi ve küçük programlar bir günde icat edilmedi. H5 ve Native App arasında özel bir başvuru formu olan Mini Program, keşiften olgunluğa kadar geçti. Önce gözden geçirip sıralayalım. Ardından, mevcut teknik mimariden başlayarak, uygulamanın mevcut ana performans tuzaklarını analiz edin. Bu tuzakları çözmek için her bir uygulama motoru tarafından ne tür iyileştirmeler yapıldı? Örneğin, herkes bilir ki küçük programların temelde web oluşturma ve tamamlayıcı olarak yerel oluşturma vardır .. Yerel görüntülemenin kullanılmaya başlanmasının neden olduğu yeni sorunlar nelerdir? WeChat, bu sorunları çözmek için aynı katman oluşturma şemasını önermiştir.Aynı katman oluşturma teknik olarak nasıl uygulanır? Son olarak, mevcut bilinen problemlerden başlayarak, uygulamanın gelecekteki teknolojik değişiklikleri için, referansınız için düşündüğümüz bazı olası yönleri atacağız.
1. Mini Program Geçmişi
HTML5, iPhone'un piyasaya sürüldüğü yıl olan 2007'de W3C'de piyasaya sürüldü.
Jobs, HTML5'in iPhone'un bir uygulama ekosistemi oluşturmasına yardımcı olmasını bekliyordu. Ancak HTML5'in geliştirme hızı beklendiği gibi değil, IE + Flash tekelini başarılı bir şekilde kırmasına rağmen mükemmel bir mobil internet deneyimi taşıma noktasına gelemedi.
Apple, iPhone'da sağlam bir yer edindikten sonra, yerel mobil İnternet uygulamaları çağını başlatan App Store'u hemen piyasaya sürdü.
Herkes cep telefonunun artık ağırlıklı olarak iOS ve Android olduğunu biliyor.Aslında, ilk günlerde rekabet eden üç büyük sistem vardı.Nokia'nın MeeGo sistemi de var.MeeGo, C + HTML5 çift modlu uygulama ekolojik stratejisini benimsiyor. Bununla birlikte, C'nin geliştirilmesi çok zordu ve HTML5 deneyimi iyi değildi, bu yüzden MeeGo geride kaldı. Buna karşılık, Android, rekabette öne çıkmak için Java teknolojisi ekolojisine güveniyor.
Dolayısıyla, mobil İnternetin ilk günlerinde, uygulama ekolojisi ana fikir geliştirme olarak belirlendi.
Çin'de HTML5'i iyileştirmeye çalışan birkaç tarayıcı üreticisi var. Örneğin Baidu, 2013'teki Baidu Dünya Konferansı'nda hafif bir uygulama yayınladı. Web Görünümü'nün yerel yeteneklerini genişleterek ve JS API'yi tamamlayarak, HTML5 uygulamaları daha fazla işlev gerçekleştirebilir.
Bu tür bir iş geliştirmenin doruk noktası, WeChat tarafından 2015 yılının başlarında piyasaya sürülen WeChat JS SDK'dır. Çin'deki en büyük mobil tarayıcı olan WeChat, tarayıcı çekirdeğini çok sayıda JS API'siyle genişletti ve geliştiricilerin WeChat ödemesini çağırmak için JS'yi kullanmasına olanak tanıdı. , Tarama kodu ve HTML5'in yapamadığı diğer birçok işlev.
Ancak, bu tür bir iş başarılı olamadı HTML5 ile ilgili sorun sadece yetersiz işlevler değil, performans deneyimi daha ciddi bir sorundur. Deneyim sorunu sadece JS yeteneklerini genişleterek çözülemez.
Tarayıcılardan farklı olarak, Hibrit uygulamalar başka bir alt alandır.Geliştiriciler, uygulamaları yazmak için JS kullanırlar.JS uygulamalarını yerel uygulamaların işlevsel deneyimine yaklaştırmak için, bu sektördeki uygulayıcılar birçok girişimde bulunmuştur. DCloud şirketimiz, sektördeki ana Hibrit Uygulama motoru sağlayıcılarından biridir. HTML5'in "performans işlevi" engellerini iyileştirmek için araçlar, motor optimizasyonu ve geliştirme modeli ayarlamaları yoluyla bir çözüm önerdik, geliştiriciler JS aracılığıyla daha yakından yazabilir Yerel Uygulama deneyimi uygulaması.
Çoklu WebView modları, geçiş animasyonlarının yerel olarak devralınması, aşağı açılır yenileme, Sekme sayfalama ve önceden yüklenmiş Web Görünümü ... Çeşitli optimizasyon teknolojileri yinelenmeye devam ederek, Hybrid uygulamalarının performans deneyiminde bir atılım gerçekleştirmesine olanak tanır.
Hibrit uygulamalar ve hafif uygulamalar, WeChat JS SDK ve diğer tarayıcı tabanlı ekleme çözümleri, başka bir büyük fark var: biri İstemci / Sunucu, diğeri Tarayıcı / Sunucu. Basitçe ifade etmek gerekirse, Hibrit uygulamalar JS'de yazılan ve yüklenmesi gereken uygulamalardır, hafif uygulamalar ise çevrimiçi web sayfalarıdır.
C / S uygulamalarının yalnızca sayfa her yüklendiğinde JSON verilerini almak için ağa ihtiyacı vardır; JSON verilerine ek olarak B / S uygulamalarının da her seferinde sunucudan sayfa DOM, stil ve mantık kodunu yüklemesi gerekir, bu nedenle B / S uygulamaları Sayfa yavaş yükleniyor ve deneyim zayıf.
Bununla birlikte, böyle bir C / S uygulaması iyi bir deneyime sahip olmasına rağmen, HTML5'in dinamik yapısını kaybeder. Yine de yüklenmesi ve güncellenmesi gerekir ve hemen veya doğrudan ikincil sayfada kullanılamaz.
Öyleyse C / S uygulamalarının dinamikleri çözülebilir mi? Bu bağlamda DCloud, "akış uygulamaları" konseptinin önerilmesinde başı çekmiştir. Önceki Hybrid uygulamasında istemcide çalışan JS kodu paketlenerek sunucuya yayınlanmış, bir akış yükleme protokolü geliştirilmiş ve mobil motor bu JS kodlarını dinamik olarak yerel konuma indirmiş ve İlk defa daha hızlı yüklenebilmesi için uygulama çalışırken indirilebilir.
Akış sırasında medya akışı gibi, uygulamalar akış sırasında da kullanılabilir.
Bu çözüm kümesinin garantisi altında, önceki sorunlar nihayet çözüldü: JS uygulama işlevi deneyiminin orijinal seviyeye ulaşmasına izin verin ve hemen ve doğrudan ikincil sayfada kullanılabilir.
Sonra WeChat uygulaması var. Orijinal adı aslında WeChat uygulama hesabıydı. Daha sonra uygulama olarak yeniden adlandırıldı. Eylül 2016'da dahili olarak test edildi ve resmi olarak Ocak 2017'de yayınlandı. Bundan sonra Alibaba, Mobile Phone Manufacturers Alliance, Baidu, Toutiao, Art arda kendi mini program platformlarımızı başlattık ve mini programlar dönemi başlıyor.
WeChat, Eylül 2018'de bulut geliştirmeyi başlattı.Bu özelliğin, küçük programların geliştirme tarihinde önemli bir düğüm olduğuna inanıyoruz. Ön uç mühendislerin, ön uç ve arka uç iletişim maliyetlerini, işçilik maliyetlerini ve işletim ve bakımı azaltarak önden arkaya tüm iş kapalı döngüsünü uygulamasına olanak tanır. Maliyet, geliştirme modelinin önemli bir yükseltmesidir. JS / CSS aracılığıyla ön uç kullanıcı arabirimi yazabilen, ancak aynı zamanda "Node.js" aracılığıyla arka uç iş yazabilen önceki ön uç öğrencilerle karşılaştırıldığında, bu tam yığın geliştirme modeli daha iyi avantajlara sahiptir çünkü ön uç öğrenciler DB optimizasyonu, esnek genişleme, saldırı koruması ve felaket kurtarma işlemlerinde hala deneyim eksikliği var, ancak bulut geliştirme bunları kapsıyor ve gerçekten iş gerçekleştirmeye odaklanıyor ve diğer tüm hizmetler bulut satıcılarına emanet.
2. Mini Program Mimarisi
Bu nispeten genel bir küçük program mimarisidir. Şu anda, birkaç küçük program mimarisi tasarımı kabaca aynıdır (hızlı uygulamalar arasındaki fark, görünüm katmanının yalnızca yerel görüntülemeye sahip olmasıdır).
Herkes küçük bir programın mantıksal ve görünüm katmanından ayrılmış bir mimari olduğunu bilir.
Mantık katmanı, yukarıdaki şeklin sol üst köşesidir. Uygulamada geliştirilen tüm sayfa JS kodu, sonunda paketlenecek ve mantık katmanına birleştirilecektir. Geliştiricinin iş JS kodunu yürütmeye ek olarak, mantık katmanı ayrıca uygulama çerçevesinin yerleşik mantığını işlemelidir. Uygulama yaşam döngüsü yönetimi gibi.
Görünüm katmanı, yukarıdaki şeklin sağ üst köşesidir Kullanıcı tarafından görülebilen UI efektleri ve tetiklenebilir etkileşim olayları, görünüm katmanında tamamlanır. Görünüm katmanı, iki tür web bileşeni ve yerel bileşenler içerir. Yani, uygulama, yerel + Web karma oluşturma modudur. Bu daha sonra ayrıntılı olarak tartışılacaktır.
Mantık katmanı nihayet JS CORE veya V8 ortamında çalışır; JS CORE ne DOM ortamı ne de Node ortamıdır. JS'de DOM veya BOM nesnelerini kullanamazsınız. Yalnızca ECMAScript standart spesifikasyonlarını çağırabilirsiniz. Yöntemler.
Ya bir ağ isteği göndermek istiyorsanız? window.XMLHttpRequest kullanılamaz (tabii ki çağrılabilse bile, iOS'un WKWebView'da daha sıkı etki alanları arası kısıtlamalar vardır ve bu da sorunlara neden olur). Şu anda, ağ isteklerinin yerel ağ modülü aracılığıyla gönderilmesi gerekiyor. JS CORE ile yerel arasında, iletişim için bu JS Köprüsü gereklidir.
Üçüncüsü, mimarinin neden olduğu performans çukurları
Bu küçük program mimarisinin en büyük avantajı, yeni sayfa yüklemesinin paralelleştirilebilmesidir, bu da sayfanın daha hızlı yüklenmesini sağlar ve geçiş animasyonunda takılıp kalmaz; ama aynı zamanda bazı performans çukurlarına da neden olur. Bugün esas olarak 3 noktayı tanıtacağım:
1. Mantık katmanı / görünüm katmanı iletişimi engellendi
"Kaydırma" örneğiyle başlayalım. Gereksinim, kullanıcının liste öğesinde sola kaydırması ve sağdaki gizli menünün kullanıcının hareketiyle sorunsuz hareket etmesidir.
Küçük program mimarisinde sorunsuz bir el kayması elde etmek istiyorsanız, bu çok zordur, neden?
Uygulama mimarisine dönüp bakıldığında, uygulamanın çalışma ortamı, sırasıyla iki iş parçacığı tarafından yönetilen bir mantık katmanına ve bir görünüm katmanına bölünür Uygulama, görünüm katmanının iki dizisi ve mantık katmanı arasında bir veri iletimi ve olay sistemi sağlar. Böyle ayrı bir tasarım bariz faydalar sağlar:
Çevre izolasyonu sadece güvenliği sağlamakla kalmaz, aynı zamanda bir performans iyileştirme aracı da sağlar.Mantık ve görünüm ayrılmıştır.İş mantığı çok meşgul olsa bile, görünüm katmanında işleme ve kullanıcı arasındaki etkileşimi engellemeyecektir.
Ama aynı zamanda bariz dezavantajları da beraberinde getiriyor:
Görünüm katmanı (WebView) JS'yi çalıştıramaz ve mantık katmanı JS, DOM sayfasını doğrudan değiştiremez. Veri güncelleme ve olay sistemi yalnızca iş parçacıkları arası iletişime dayanabilir, ancak iş parçacıkları arası iletişimin maliyeti, özellikle sık iletişim gerektiren senaryolarda son derece yüksektir.
Bu mimari tasarıma dayanarak, "kaydırmaya" dönüyoruz ve bir dokunma hareketi işlemini ve uygulamanın dahili yanıt sürecini analiz ediyoruz:
(1) Kullanıcı liste öğesini sürüklediğinde, görünüm katmanı touchmove olayını tetikler ve mantık katmanı, yerel katman aktarımı yoluyla bildirilir (mantık katmanı ve görünüm katmanı doğrudan iletilmez ve yerel aktarım gereklidir), yani aşağıdaki şekilde iki adım ve ;
(2) Mantık katmanı, taşınacak konumu hesaplar ve ardından konum verilerini setData aracılığıyla görünüm katmanına aktarır.WeChat istemcisi (Yerel) ayrıca ortada, yani aşağıdaki şekilde iki adım ve aktarır.
Aslında, kullanıcının kaydırma işlemi sırasında, dokunmatik hareket geri aramaları çok sık tetiklenir ve her geri arama, dört aşamalı bir iletişim süreci gerektirir.Yüksek frekanslı geri aramalar, iletişim maliyetlerinde önemli bir artışa neden olur ve bu da sayfa sıkışmalarına veya titremelere neden olabilir. Neden takıldı? İletişim çok sık olduğu için, görünüm katmanı UI güncellemesini 16 ms içinde tamamlayamaz.
Bu iletişim engelleme problemini çözmek için, her uygulama, WeChat'in WXS'si, Alipay'in SJS'si ve Baidu Filtresi gibi, kademeli olarak karşılık gelen çözümleri sunmaktadır. Bununla birlikte, her uygulamanın destek durumu farklıdır. Ayrıntılar için aşağıdaki tabloya bakın.
Ek olarak, WeChatin "ana kare animasyonu" ve Baidunun "animasyon görünümü" Lottie animasyonu da sık iletişimi azaltmanın bir yoludur.
aslında, İletişim sıkışıklığı endüstride yaygın bir sorundur , Yalnızca küçük programlar değil, "React Native" ve "Weex" de iletişim engelleme sorunları var. Sadece "React Native" ve "Weex" görünüm katmanı yerel oluşturma, uygulama ise Web sunumu. Aşağıda örnek olarak "Weex" alalım.
Hepimizin bildiği gibi, "Weex" in altında kullanılan JS-Native Bridge, JS ve Native arasındaki iletişimi sabit bir performans kaybına neden olur.
Yukarıdaki "kaydırma işlemini" örnek olarak almaya devam edersek, liste öğesi menüsünün kaymasını gerçekleştirmek için genellikle aşağıdaki işlem gereklidir:
(1) Dokunma olayını (veya pan olayını) UI görünümüne bağlayın;
(2) Hareket tetiklendiğinde, Native UI katmanı hareket olayını Bridge üzerinden JS mantık katmanına geçirir, bu da Native UI'den JS mantığına bir iletişim oluşturur; bu, aşağıdaki şekilde iki adım ve olan;
(3) Olayı aldıktan sonra, JS mantığı, aşağıdaki şekilde iki adım olan steps ve olan JS'den Native UI'ye başka bir iletişim oluşturacak olan parmak hareketinin ofsetine göre arayüz değişikliğini yönlendirir.
Benzer şekilde, hareket geri arama olaylarının tetikleme frekansı çok yüksektir ve sık iletişimin getirdiği zaman maliyeti büyük olasılıkla arayüzün 16 ms'de çizimi tamamlayamamasına neden olur ve kekemelik meydana gelir.
"Weex", iletişim engellemesini çözmek için bir "BindingX" çözümü sağlar. Bu, "İfade Bağlama" adlı bir mekanizmadır. Kısa bir giriş:
(1) Hareket olayını alan görünüm için, hareket sırasındaki ofset iki değişken "x, y" ile temsil edilir;
(2) Değişmesi beklenen görünüm (hareketi takip eder), değiştirilen öznitelikler "translateX" ve "translateY" dir ve karşılık gelen değişen ofset "f (x), f (y)" ifadesi ile ifade edilir;
(3) İfadeler biçiminde "etkileşimli davranışı" açıklayın ve bunu önceden Native UI katmanına önceden ayarlayın;
(4) Etkileşim tetiklendiğinde, Native UI ifadeyi yerleşik ifade analiz motoruna göre yürütür ve ifade yürütme sonucuna göre görünüm dönüşümünü yürütür.Bu işlemin JS mantığı ile iletişim kurması gerekmez.
Weex resmi web sitesinden sözde kod alıntı
Kodu kopyala
{anchor: foo_view.ref // ---- > Bu, "hareketi oluşturan görünüm" props: }"React Native" de benzer problemlere sahiptir.Sık iletişimden kaçınmak için "React Native" ekosisteminde "Animated" bileşenleri ve Lottie animasyon desteği gibi ilgili çözümler de vardır. Örnek olarak "Animasyonlu" bileşeni alın. Düzgün bir animasyon efekti elde etmek için, bileşen bildirim temelli bir API kullanır. JS tarafında yalnızca giriş ve çıkış ve belirli dönüştürme davranışı tanımlanır. Gerçek animasyon, Yerel Sürücü aracılığıyla Yerel katmandadır. Uygulama, böylece sık iletişimden kaçınılır. Bununla birlikte, bildirimsel yaklaşım sınırlı davranışları tanımlayabilir ve etkileşimli senaryolarda kullanılamaz.
"Uni-app" ayrıca Uygulama tarafında iletişim engelleme sorunuyla karşı karşıyadır. Mevcut çözümümüz WeChat WXS'ye benzer bir mekanizma kullanmaktır (dahili olarak "renderjs" olarak adlandırılır), ancak aşağıdaki gibi WXS'nin sayfa DOM öğelerini elde edememesi kısıtlamasını kaldırın. Aynı anda hareket eden birden fazla topun tuval animasyonunda, Uygulama tarafındaki "uni-app" uygulaması şu şekildedir:
(1) Canvas nesnesini renderj'lerde alın;
(2) Web tabanlı tuval çizim animasyonu, yerel tuval çizimi değil.
İpuçları: Herkesin tüm sahnelerin daha iyi yerel performansa sahip olmadığına dikkat etmesi gerekir.Aynı anda hareket eden birden fazla topun animasyonu gibi küçük program mimarisi altında, yerel tuval, WXS'de (renderjs) doğrudan Web tuvalini çağırmak kadar iyi değildir.
Aşağıdaki tablo, çapraz uç çerçevenin çözümlerini iletişim engelleme açısından özetlemektedir:
2. Veri / bileşen farkı güncellemesi
Küçük program mimarisinde bir iletişim engelleme sorunu var Bu sorunu çözmek için, üretici "WXS" komut dosyası dilini ve anahtar çerçeve animasyonunu yarattı, ancak bunların tümü üreticinin boyutlarına göre optimize edilmiş çözümlerdir. Küçük program geliştiricileri olarak performans optimizasyonu açısından ne yapabiliriz?
Mini program geliştirme performans optimizasyonu, çekirdek "setData" çağrısıdır, yalnızca iki şey yapabilirsiniz:
- Mümkün olduğunca az "setData" çağırmaya çalışın;
- Her "setData" çağrıldığında, en küçük miktarda veri aktarılır, yani veri farkı güncellenir.
(1) setData için çağrı sayısını azaltın
Birden çok değişkenin değerini değiştirmemiz gerektiğini varsayalım, bir örnek aşağıdaki gibidir:
değişiklik: function () { this.setData ({a: 1}); ... // Diğer iş mantığı this.setData ({b: 2}); ... // Diğer iş mantığı this.setData ({c: 3}); ... // Diğer iş mantığı this.setData ({d: 4}); }Yukarıdaki gibi, "setData" nın 4 kez çağrılması, 4 kez mantık katmanı ve görünüm katmanı veri iletişimine neden olacaktır. Bu senaryoda, geliştiricilerin "setData" nın çok yüksek bir çağrı maliyeti olduğunu ve kodu manuel olarak ayarlamaları, verileri birleştirmeleri ve veri iletişimlerinin sayısını azaltmaları gerektiğini anlamaları gerekir.
Bazı küçük program üçlü çerçevelerinin yerleşik veri birleştirme yetenekleri vardır. Örneğin, "tekli uygulama" Vue çalışma zamanında derinlemesine özelleştirilmiştir. Geliştiricilerin "setData" çağrısının maliyetine dikkat etmeleri gerekmez ve aşağıdaki kodu güvenli bir şekilde yazabilirler:
değişiklik: function () { this.a = 1; ... // Diğer iş mantığı this.b = 2; ... // Diğer iş mantığı this.c = 3; ... // Diğer iş mantığı this.d = 4; }Yukarıdaki 4 atamada olduğu gibi, uni-app, uni-app çalıştırılırken otomatik olarak bir "{" a ": 1," b ": 2," c ": 3," d ": 4}" kaydına birleştirilir, tamamlamak için "setData" çağrısı Tüm veri aktarımı, setData'nın çağrılma sıklığını büyük ölçüde azaltır. Sonuç aşağıdaki gibidir:
Çağrıların sayısını "setData" olarak azaltmak için başka bir not daha vardır: arka plan sayfaları (kullanıcılar tarafından görülemeyen sayfalar) "setData" çağrısından kaçınmalıdır.
(2) Veri farkı güncellemesi
Bir "liste sayfası + yukarı çekme yükleme" senaryomuz olduğunu, ilk liste öğesinin "öğe1 ~ öğe4" olduğunu ve kullanıcının yukarı çıktıktan sonra listeye 4 yeni kayıt "öğe5 ~ öğe8" eklemesi gerektiğini varsayalım. Uygulama kodu aşağıdaki gibidir:
sayfa({ veri:{ liste: }, değişiklik: function () { let newData =; this.data.list.push (... newData); // Liste öğesi için yeni kayıt this.setData ({ list: this.data.list }) } })Yukarıdaki kodda olduğu gibi, değiştirme yöntemi yürütüldüğünde, "öğe1 ~ öğe8" listesindeki tüm 8 liste öğesi, "setData" yoluyla iletilecektir, ancak aslında değiştirilen tek veri "öğe5 ~ öğe8" dir.
Bu senaryoda, geliştiricinin farkı hesaplaması ve değiştirilen verileri yalnızca "setData" aracılığıyla iletmesi gerekir. Aşağıda örnek bir kod verilmiştir:
sayfa({ veri:{ liste: }, değişiklik: function () { // Bir sonraki işlemenin dizinini uzunluğa göre alın let index = this.data.list.length; let newData =; let newDataObj = {}; // değiştirilen veri newData.forEach ((öğe) = > { newDataObj = item; // Liste alt simgesi aracılığıyla değişiklik içeriğini doğru şekilde kontrol edin }); this.setData (newDataObj) // fark verilerini ayarla } })Fark değişim verilerini her seferinde manuel olarak hesaplamak zahmetlidir.Eğer acemi uygulamanın ilkesini anlamazsa, bu performans noktalarını göz ardı etmek ve Uygulama için performans çukurlarını gömmek kolaydır.
Burada, geliştiricilerin, farklı veri hesaplamalarını otomatik olarak kapsülleyen ve geliştiriciler için daha kolay olan olgun üçüncü taraf uygulama çerçevelerini seçmeleri önerilir. Örneğin, "uni-app" "westore JSON Diff" kitaplığından ödünç alır. SetData'yı çağırmadan önce, değişen fark verilerini doğru ve verimli bir şekilde hesaplamak için geçmiş verileri karşılaştırır ve ardından sadece değiştirilen verileri aktarmak için setData'yı çağırır. Bu, iletilen veri miktarını en aza indirebilir ve iletişim performansını artırabilir. Aşağıda örnek bir kod verilmiştir:
varsayılan ver { veri(){ dönüş { liste: } }, yöntemler: { değişiklik: function () { let newData =; this.list.push (... newData) // Doğrudan atayın, çerçeve otomatik olarak fark verilerini hesaplayacaktır } } }İpuçları: Yukarıdaki değişiklik yöntemi yürütüldüğünde, listedeki yalnızca 4 yeni liste öğesi "öğe5 ~ öğe8" aktarılacaktır, bu da setData'nın transfer hacmini büyük ölçüde basitleştirir.
(3) Bileşen farkının güncellenmesi
Aşağıdaki resim bir Weibo listesinin ekran görüntüsüdür:
Şu anda 200 Weibo olduğunu varsayarsak, bir Weibo'yu beğenen kullanıcıların benzer verilerini (durumlarını) gerçek zamanlı olarak değiştirmeleri gerekir; geleneksel modda, bir Weibo'nun benzer değişikliklerinin durumu tüm sayfanın (Sayfa) durumunu değiştirecektir. Verilerin tamamı setData üzerinden geçirilir ve bu tüketim çok yüksektir ve değişiklik verileri önceki giriş yoluyla fark hesaplama yöntemi ile elde edilse bile, Diff geçiş aralığı çok büyük ve hesaplama verimliliği son derece düşüktür.
Weibo'nun beğenilerinden daha yüksek performans nasıl elde edilir? Bu aslında bileşen güncellemeleri için tipik bir senaryodur.
Uygun yol, her Weibo'yu bir bileşene kapsüllemek olmalıdır. Kullanıcı beğendikten sonra, yalnızca mevcut bileşen aralığındaki fark verilerini hesaplayın (Diff aralığının orijinalin 1 / 200'üne düştüğü anlaşılabilir), bu nedenle verimlilik en uzun.
Herkese, küçük programlar için tüm üçlü çerçevelerin özel bileşenler uygulamadığını hatırlatın. Yalnızca özel bileşen modu paketlemesine dayalı çerçevede, performans büyük ölçüde iyileştirilecektir; eğer üçlü çerçeve eski "şablon" şablon paketli bileşenlere dayanıyorsa Geliştirme, performans önemli ölçüde iyileştirilmeyecek ve Diff karşılaştırma aralığı hala Sayfa sayfası düzeyindedir.
3. Karma oluşturma
Hepinizin bildiği gibi, applet-native bileşeninde özel bir tür yerleşik bileşen vardır. Bu tip bileşen, WebView tarafından oluşturulan yerleşik bileşenden farklıdır ve yerel istemci tarafından oluşturulurlar.
Mini programlardaki yerel bileşenler, kullanım açısından temel olarak üç kategoriye ayrılır:
- Yapılandırma öğeleri tarafından oluşturulur: sekmeler, gezinme çubuğu ve aşağı açılır yenileme;
- Kamera, tuval, giriş, canlı oynatıcı, canlı itici, harita, metin alanı, video gibi bileşen adları tarafından oluşturulur;
- API arayüzü aracılığıyla oluşturulur, örneğin: showModal, showActionSheet, vb.
Yukarıda bahsedilenler dışında, diğer her şey temelde Web oluşturma. Bu nedenle, uygulama, Web görüntülemenin ana ve ek olarak yerel oluşturma ile bir karma oluşturma modudur.
(1) Neden hibrit oluşturma kullanılmalı?
Bir sonraki soru, neden yerel işleme getirilmeli? Ve neden yerel geliştirmeler yalnızca bu bileşenler için sağlanıyor? Diğer bileşenler neden yerel olarak uygulanmıyor?
Bu, her bir bileşeni ayrı ayrı analiz etmemizi ve düşünmemizi gerektirir. İşte birkaç örnek:
- sekmeler / gezinme çubuğu: Sayfalar arasında geçiş yaparken beyaz ekranlardan kaçının ve yeni pencerelere girerken kullanıcı deneyimini iyileştirin. Yerel sekme çubuğunu ve gezinme çubuğunu kullanmadan daha esnek bir arayüz oluşturabilseniz de, sayfanın 300 ms'lik kısa geçiş sayfalarında beyaz olmadığından emin olmak istiyorsanız daha hızlı işlenen yerel sekme çubuğunu ve gezinme çubuğunu kullanmanız gerekir;
- video: Tam ekrandan sonra kaydırma kontrolü (ses, ilerleme, parlaklık vb.);
- harita: İki parmakla daha düzgün yakınlaştırma ve konum sürükleme;
- giriş: Web tarafı girişi Klavye açıldığında, yalnızca "Bitir" düğmesi vardır ve klavye "Gönder" ve "İleri" düğmelerini görüntüleyemez.
"Giriş" kontrolünün yerelleştirilmesi söz konusu olduğunda, biraz farklılaşabilirsiniz.
Uygulamalardaki yerel girdi denetimlerinin genel uygulaması, odak elde edilmediğinde bir web denetimi olarak görüntülenmek, ancak odak elde edildiğinde yerel bir girdi çizmek ve bunu web girdisinin üstüne kapatmaktır. Bu sırada, kullanıcının gördüğü klavye yerel girdiye karşılık gelir Yerel açılır klavye, özelleştirilebilir bir düğmedir (yukarıdaki şekilde gösterildiği gibi, sonraki adım, gönder düğmesi). Bu yaklaşımın bir kusuru vardır: Web ve yerel, sonuçta farklı işleme motorları, klavye açılıp kapandığında, karşılık gelen girdi "yer tutucusu" titreyecektir.
Android platformunda, açılır klavye stilini WebKit dönüşümüne dayalı olarak özelleştirmenin başka bir yolu vardır; bu çözümde, klavye açılıp kapandığında, giriş kontrollerinin tümü Web'de uygulanır, böylece "yer tutucu" titreme sorunu olmaz.
(2) Karışık görüntülemenin neden olduğu sorunlar
Yerel bileşenler daha zengin özellikler ve daha iyi performans getirse de, aşağıdakiler gibi bazı yeni sorunları da beraberinde getirir:
- Hiyerarşik sorunlar: Yerel her zaman en üst düzeydedir. Farklı öğelerin düzeyini "z-endeksi" aracılığıyla ayarlamak imkansızdır ve görünüm ve görüntü gibi yerleşik bileşenlerle örtüşemez. "Seçici görünümü", "kaydırmalı görünümü", "kaydırıcıyı" vb. Desteklemez. Bileşenlerde kullanılır;
- İletişim sorunu: Örneğin, bir video bileşeni uzun bir listeye gömülüdür Sayfa kaydırıldığında, yerel video bileşeninin birlikte kaydırılması için bilgilendirilmesi gerekir İletişim engellenir, bu da bileşenin titremesine veya lekelenmesine neden olabilir;
- Yazı tipi sorunu: Android telefonlarda, sistem teması yazı tipini ayarlarsanız, tüm doğal olarak işlenmiş kontrollerin yazı tipleri değişecek, ancak Web'de işlenen yazı tipleri değişmeyecektir. Aşağıdaki şekilde gösterildiği gibi, sistem rom yazı tipi bir "adınız" üçlü yazı tipidir. Ayarlamadan sonra, uygulamanın üst başlığının yazı tipi ve alt sekmenin yazı tipi de değişmiştir, ancak uygulamanın ortadaki içerik alanının yazı tipi değişmeden kalmıştır. Bu karşılaştırmadır. Utanç verici bir durum, bir sayfa, iki yazı tipi.
Elbette, tüm uygulamalarda bu sorun yoktur. Bazı uygulamalar WebView'ın WeChat, QQ, Alipay gibi rom tema yazı tiplerini de kullanabileceğini fark etmek için kendi WebView çekirdeğini değiştirdiler; diğer uygulamalar (Baidu, Toutiao), WebView hala rom tema yazı tipi olarak işlenemiyor.
(3) Karma oluşturma iyileştirme planı
Hibrit render bu problemlere sahip olduğu için bunlara çözüm bulunacaktır.Mevcut çözümler aşağıdaki gibidir.
- Program : Daha yüksek seviyeli bileşenler oluşturun
Diğer bileşenler yerel bileşenlerin üzerine bindirilemediğinden, video veya harita üzerine yerleştirilebilecek yeni bir bileşen oluşturun. "Kapak görünümü / kapak resmi" bu talebe göre oluşturulan yeni bileşenlerdir; aslında bunlar da yerel bileşenlerdir, ancak harita, video, tuval ve kamera gibi yerel bileşenlerin üzerine yerleştirilebilen biraz daha yüksek bir seviyeye sahiptir.
Bayt atımı dışında, diğer bazı küçük programlar zaten "kapak görünümü / kapak resmi" ni desteklemektedir.
Kapak görünümü / kapak resmi, hiyerarşik kapsam sorununu bir dereceye kadar hafifletir, ancak katı iç içe yerleştirme düzeni gibi bazı kısıtlamalar da vardır.
- Program : Katmanlamayı ortadan kaldırın ve aynı katman üzerinde işleyin
Katmanlama ile ilgili bir sorun olduğu için, katmanlamayı ortadan kaldırın ve katman 2'den katman 1'e geçiş yapın. Tüm bileşenler tek katmanda. "Z-endeksi" etkili olmaz mı?
Bu küçük hedeften bahsetmek basit, ancak gerçek gerçekleşme hala çok karmaşık.
4. Aynı katman oluşturma
Uygulamanın mevcut mimarisinin uygulanmasının yanı sıra, hibrit oluşturmaya yönelik en doğrudan çözüm, oluşturma motorunu değiştirmektir; tümü yerel işleme, video / harita ve görüntü / görünüme dayalı, aynı seviyedeki yerel kontrollerdir ve hiyerarşik gizleme sorunu doğal olarak ortadan kalkacaktır. Bu, Uygulama tarafında "tekli uygulama" için önerilen çözümdür.
Ek olarak ana ve yerel işleme olarak web görüntülemeye sahip genel küçük programların mevcut durumu, aynı katman oluşturma nasıl elde edilir?
Analizimize ve araştırmamıza dayanarak, WeChat'in gerçek uygulamasından farklı olabilecek aynı katman oluşturmanın uygulanmasına ilişkin kısa bir açıklama burada verilmiştir (şu anda yalnızca WeChat aynı katman oluşturmayı uygulamıştır).
(1) iOS platformu
Uygulama, iOS tarafında işleme için WKWebView kullanır WKWebView dahili olarak katmanlı oluşturmayı kullanır.Genel olarak, birden çok DOM düğümü işleme için tek bir katman halinde birleştirilir. Bu nedenle, DOM düğümleri ve katmanları arasında bire bir yazışma yoktur. Ancak, bir DOM düğümünün CSS özelliği "overflow: scroll" olarak ayarlandığında, WKWebView bunun için bir WKChildScrollView oluşturur ve WebKit çekirdeği, WKChildScrollView ile diğer DOM düğümleri arasındaki hiyerarşik ilişkiyi işlemiştir. Şu anda DOM düğümü Katmanlarla bire bir yazışma vardır.
Uygulamanın iOS tarafında aynı katman işleme, WKChildScrollView temel alınarak uygulanabilir ve ana işlem aşağıdaki gibidir:
- Bir DOM düğümü oluşturun ve CSS özelliğini taşacak şekilde ayarlayın: scroll;
- DOM düğümüne karşılık gelen yerel WKChildScrollView bileşenini bulması için yerel katmanı bilgilendirin;
- Yerel bileşeni WKChildScrollView düğümüne alt Görünümü olarak bağlayın.
(2) Android platformu
Uygulama, Android tarafında WebView oluşturma katmanı olarak Chromium'u kullanır. İOS'un WKWebView'undan farklı olarak, tek tip olarak oluşturulur ve katmanlarda oluşturulmaz. Ancak Chromium, WebPlugin mekanizmasını destekler. WebPlugin, ayrıştırmak için kullanılabilen tarayıcı çekirdeğinin bir eklenti mekanizmasıdır " < Göm > ". Android tarafında aynı katman oluşturma," < Göm > "Elde etmek için Chromium kernel uzantısını ekleyin, genel süreç şu şekildedir:
- Yerel katman, yerel bir bileşen (video gibi) oluşturur;
- WebView bir " < Göm > "Düğüm ve türünü video olarak belirtin;
- Chromium çekirdeği bir WebPlugin örneği * oluşturur ve bir RenderLayer oluşturur;
- Yerel katman, yerel bileşenin resmini RenderLayer tarafından bağlanan SurfaceTexture'a çizer;
- Chromium, RenderLayer'ı oluşturur.
Bu işlem, WebView'a harici bir eklenti eklemeye eşdeğerdir ve " < Göm > Düğüm gerçek bir DOM düğümüdür ve bu düğüme daha fazla stil uygulanabilir.
Dördüncüsü, gelecek olabilir
Mini programın bir sonraki teknolojik yükseltme yönünü tartışmak istiyorsak, kullanıcı deneyimi ve geliştirme verimliliği olmak üzere iki yönde çok çalışmamız gerektiğine inanıyoruz.
1. Daha iyi kullanıcı deneyimi
Kullanıcı deneyimi sorunu hakkında temelde iki yönden bahsedeyim:
- Önceden analiz edilen öğeler, iletişim tıkanıklığı, hiyerarşik kısıtlamalar gibi mevcut performans çukurlarını çözün, burada tekrar etmeyeceğim;
- Gauss Bulanıklığı gibi daha fazla Uygulama deneyimi, daha özgür ve esnek yapılandırma desteği.
Kendi uygulama motorunuzu hızlı bir şekilde oluşturmak ve yukarıdaki deneyim sorunlarını daha iyi çözmek istiyorsanız ne olur?
Uygulama tarafında yayınlanan Uni-app aslında tam bir uygulama motorudur. DCloud bu motoru yakın gelecekte tamamen açacaktır. Uni-app uygulama SDK'sına dayalı olarak kendi uygulama platformunuzu hızlı bir şekilde oluşturabilirsiniz.
Tekli uygulama uygulama SDK'sı aşağıdaki özelliklere sahiptir:
- Performans: Yerel oluşturmayı destekleyin, WXS'yi genişletin, daha yüksek iletişim performansı;
- Açıklık: daha esnek konfigürasyon, daha fazla Uygulama deneyimini destekler;
- Sınırsız açık kaynak: herhangi bir sözleşme imzalamaya gerek yok, sadece al ve kullan;
- Ekolojik açıdan zengin: WeChat uygulamacıkları için özel bileşenleri destekler, tüm "tek uygulama" eklentilerini destekler ve eklenti pazarında şu anda binlerce olgun eklenti vardır.
2. Geliştirme verimliliği
Geliştirme verimliliği iki boyuttan analiz edilmelidir: çapraz terminal ve çapraz bulut.
(1) Çapraz terminal geliştirmeMevcut küçük programların hepsinin belirgin üretici nitelikleri vardır ve her üretici farklıdır. Örneğin, Ali'nin içinde çok sayıda küçük program (Alipay, Taobao, Dingding, vb.) Vardır Neyse ki, Ali temelde dahili olarak birleşmiştir. Bununla birlikte, Tencent sistemi altında, WeChat ve QQ uygulaması hala iki ekip ve iki dizi özelliktir.
Uygulama cep telefonundaydı. 2019'da 360, PC uygulamasını başlattı.
Sonra, diğer üreticiler kendi mini programlarını başlatacaklar mı? Yeni bir son olacak mı? Örneğin, TV için küçük programlar, araba için küçük programlar?
Herşey mümkün.
Su ve çim üzerinde yaşamak insan içgüdüsüdür ve trafik arayışı hala internetin sihirli silahıdır. Mevcut küçük program ana bilgisayarlarının tümü milyar düzeyindeki trafik portallarıdır ve her birinin farklı trafik politikaları vardır. Örneğin, WeChatın trafiği çok büyük olmasına rağmen, çeşitli kısıtlamaları vardır; Baidu ve Toutiao, reklamları destekler. Reklamcılık yoluyla, çok sayıda daha doğru kullanıcıyı hızlı bir şekilde edinebilirsiniz; Baidu Mini Program ayrıca, Web'in arama trafiği, küçük programların trafiğine dönüştürülür.
Pek çok küçük program platformu ve bunların büyük giriş trafiğiyle karşı karşıya kalan geliştiriciler nasıl tepki veriyor?
W3C'nin küçük program standartlarının birleştirilmesini beklemek kısa vadede gerçekçi değildir. Şu anda, birden çok küçük programa hızlı bir şekilde ulaşmak istiyorsanız, çapraz uçlu bir çerçeve kullanmak tek uygun çözüm olmalıdır.
(2) Çapraz bulut geliştirmeTüm ön uç uygulamaları geliştirilebilmesine rağmen geliştiriciler "tek uygulama" veya diğer çapraz uç çerçeveleri kullanır. Ancak yine de hem arka uç personel maliyetleri hem de ön uç / arka uç iletişim maliyetleri olan PHP veya Java gibi arka uç geliştiricileri işe alması gerekiyor.
Tencent, Alibaba ve Baidu küçük programları art arda bulut geliştirmeyi başlatmış olsalar da, hepsi yalnızca kendi küçük programlarını destekliyor ve çapraz uç kuramıyor ve merkezi olmayan sunucular geliştiriciler için daha da istenmeyen bir durum.
Bu nedenle, satıcılar arası sunucusuzluğun bir sonraki temel gereksinim olduğuna inanıyoruz. Geliştiriciler tüm iş verilerini ve arka uç mantığını bir bulutta depolar ve ardından ön uç uygulamalarını çeşitli uygulama platformlarına dağıtır, bu "tek bulut, birden çok terminal" modeli .
V. Özet
Mini programların mevcut durumuna bağlı olarak, mini programların olası teknik yönlerini özetleyebiliriz:
yazar hakkında: Uni-App ekip lideri DCloud CTO'su Cui Hongbao, on binlerce Github Star ile 2 popüler proje geliştirdi. 10 yıldan fazla Ar-Ge yönetimi deneyimi, platformlar arası motorda zengin pratik deneyim, ön uç kullanıcı arabirimi, mini program performans optimizasyonu vb.
