Hizmetlerin% 70'inden fazlası H5 tarafından geliştiriliyor Mobil QQ Hybrid'in mimarisi nasıl optimize edilir ve geliştirilir?
Yazar Tu Qiang
Düzenle Xiaozhi
Ön uç geliştirmenin yükselişiyle, QQ yavaş yavaş Web ve yerel terminallerin karma bir geliştirme modeline dönüştü. QQ, Web dinamik işlem yetenekleri kazanırken, etkileşimli yanıt hızı, arka plan hizmet baskısı ve çok sayıda kullanıcının bant genişliği etkisi açısından daha fazla zorlukla karşı karşıya kaldı. Web işlemlerinin hızlı temposu altında, QQ'ya gömülü üçüncü taraf hizmetlerinin her zaman yüksek kaliteli hizmet durumunda olmasını sağlamak gerekir. Bu sorunlara yanıt olarak, QQ ekibi deneyimi optimize etmek için yalnızca dinamik CDN, arka plan oluşturma ve diğer tam yığın yöntemleri kullanmakla kalmadı, aynı zamanda hizmet kalitesini sağlamak için hız, başarı oranı, sayfa istisnaları ve diğer boyutlar etrafında bir izleme sistemi oluşturdu.
Önüne yaz
Önce kendimi tanıtın, benim adım Tu Qiang. Tencent'e, mobil ve hibrit geliştirmenin popüler olmadığı 2005 yılında katıldım. O zamanlar ağırlıklı olarak QQ'nun PC versiyonunu geliştirdim. Daha sonra, QQ UI motorunun PC versiyonundan sorumlu olduğumda, tarayıcı çekirdeğini PC istemcisine entegre etmek için bazı girişimlerde bulundum.O zaman, H5 ve native'nin karışık gelişimi üzerine bazı çerçeve çalışmaları yaptım. Bundan sonra, mobil terminallerdeki QQ üyelerinin teknolojisinden sorumlu Tencent QQ üye ekibine katıldım.Aynı zamanda çok zor bir görevim vardı: mobil QQ'da H5 hibrit tarafından geliştirilen tüm çerçeveleri, yani WebView bileşeninin teknik çalışmasını korumak.
Eve daha yakın, artık ana akım hibrit hala H5 + yerli. Mobil terminaller için H5 geliştirmenin öneminden bahsetmeye gerek yok, ancak H5'in yereldeki bariz sorunları, uygulamayı açmak için uzun zaman alan sayfa yükleme gibi herkes tarafından görülebilir. Kullanıcı yüklerken kasımpatı transfer arayüzünü kaybedebilir, bu da ürün müdürünün görmek istemediği bir durumdur. Bir diğer nokta ise H5'i her açtığınızda ağ etkileşimi ve dosya indirmeyi içeriyor.Bu işlemler kullanıcının trafiğini tüketecek, trafik çok tüketirse kullanıcı mutsuz olacaktır.
Bugün sizinle paylaşılan içerik esas olarak, sırasıyla sonik ve yeniden şekillendirmenin iki bağımsız teknik çerçevesine karşılık gelen QQ üye ekibinin sayfa açılış süresini ve kullanıcı trafiğini nasıl optimize ettiğini tanıtmak içindir.
Geleneksel sayfa ayırma
Tüm teknik seçimler ve çerçeveler iş formları ile birlikte seçilmelidir.QQ üyelerinin iş formları hakkında basit bir anlayışa sahip olabilirsiniz. Mobil QQ'daki hizmetlerin% 70'inden fazlasının H5 tarafından geliştirildiği söylenebilir, örneğin üyeler için ana alışveriş merkezleri: oyun dağıtım merkezleri, üye ayrıcalık merkezleri ve şu anda sorumlu olduğum kişiselleştirilmiş hizmetler için alışveriş merkezleri. Bu alışveriş merkezlerinin özellikleri açıktır, bunlar UGC tarafından oluşturulan sayfalar değil, sayfada görülebilen ifadeler ve temalar gibi arka planda ürün yöneticisi tarafından yapılandırılan içeriklerdir.
Bu sayfalar nispeten gelenekseldir.Başlangıçta hız ve deneyim ayrımı için geleneksel bir H5 sayfası optimize edilecektir, örneğin sayfanın üst kısmındaki banner ve aşağıda item dediğimiz öğe alanı Bu alanlardaki veriler ürün tarafından belirlenebilir. Yönetici istediği zaman düzenleme ve değiştirme özgürlüğüne sahiptir. Sayfayı yükledikten sonra bir CGI isteği başlatacağız, dataServer'dan verileri alacağız ve sonra bunları birbirine ekleyeceğiz.
Buradaki işlem kabaca şu şekildedir: Kullanıcı WebView'ı başlatmak için tıklamadan başlar. WebView, HTML dosyasını CDN'ye yükler. Sayfa yüklendikten sonra JSON alınır. Bu işlemi hızlandırmak için localStroage önbelleğe alma için kullanılabilir. Tüm süreç Çok geleneksel statik sayfa yükleme işlemi nispeten basittir.
Bununla birlikte, yukarıdaki şemada bazı sorunlar vardır: Örneğin, WebView'ı başlattığımızda, ağ boşta kalır ve bu da zaman kaybına neden olur. Ekibimiz dahili olarak, Android makinesinde WebView'ı başlatmanın 1 saniyeden az sürdüğünü saydı (çünkü mobil QQ çok işlemli bir mimaridir, WebView başka bir işlemde yaşar ve işlem yükleme ve tarayıcı çekirdeği yüklemesine ek olarak WebView bir kez başlar).
İkinci olarak, CDN'de yayınlanan statik sayfa öğe verilerini içermez, bu nedenle kullanıcı önce CDN'den indirilen sayfanın, başlık alanının ve öğe alanının boş olduğunu görür ve bu da kullanıcı deneyimine çok zararlıdır.
Başka bir sorun daha var. Mevcut DOM, sayfa yüklendiğinde, yani JSON çekildikten sonra yenilenmelidir, DOM yapısı eklenir ve ardından yenilenir. QQ kullanıcıları tarafından kullanılan bazı düşük kaliteli Android makinelerde bu uygulamanın da zaman harcayacağını gördük.
Statik düz çıkış + çevrimdışı ön itme
Bu sorunlar karşısında, statik düz + çevrimdışı ön itme modu dediğimiz bazı teknik önlemleri cesurca kabul ettik. Öncelikle WebView ve ağ isteklerinin yüklenmesini paralel hale getirdik.Tüm ağ isteklerimiz WebView çekirdeğinden başlatılmadı, ancak WebView yükleme sürecinde yerel kanal üzerinden kendi HTTP bağlantımızı kurduk ve ardından CDN'den bizimle iletişime geçtik. OfflineServer adlı yer sayfayı alır Bu offlineServer, herkesin duyduğu çevrimdışı paket önbelleğe alma stratejisidir.
Yerelde offlineCache var. HTTP istekleri yaparken, önce offlineCache'de herhangi bir geçerli HTML önbelleği olup olmadığını kontrol ediyoruz.Bu önbellek WebView önbelleğinden izole edilmiştir ve WebView'ın önbelleğe alma stratejisinden etkilenmeyecektir.Tamamen bizim tarafımızdan kontrol edilmektedir.
OfflineCache'de önbellek yoksa, dosyaları senkronize etmek için offlineServer'a gidecek ve aynı zamanda CDN'den güncellemeleri indirecektir. CDN'de sakladığımız HTML, banner ve item gibi tüm verileri statik sayfaya zaten koymuştur. Şu anda, WebView HTML'yi aldığı sürece herhangi bir JS'yi yenilemeye ve yürütmeye gerek yoktur. Sayfanın tamamı doğrudan görüntülenebilir ve kullanıcı da Etkileşim.
Bu çözüm ilk olarak WebView başlatma zamanından tasarruf sağlayacaktır.Bu süre zarfında doğrudan ağ üzerinden iletilebilir.Ayrıca, yerel olarak bir offlineCache varsa, ağ aktarım istekleri bile gerekli değildir, bu da yerel bir sayfanın tamamen yüklenmesine eşdeğerdir. Ancak çoğu durumda, güvende olmak için yine de sayfa yükleme ekliyoruz ve ardından veri tutarsızlıklarını önlemek için yenileme işlemleri yapıyoruz.
Bu mekanizma, yayınlandıktan sonra iyi çalışır, ancak bu H5 yükleme modunu gerçekten uygularsanız, bazı tuzaklarla karşılaşırsınız.Örneğin, ürün yöneticisi tarafından yapılandırılan başlık resmi ve öğe verileri tutarsız birden çok veri sürümüne sahip olabilir.
Ürün yöneticisi, dataServer'daki en son veri bilgilerini yapılandırmalıdır, ancak CDN sayfasındaki yerleşik veriler hala önceki sürümde olabilir. Daha da kötüsü, çevrimdışı paket sunucusu ve offlineServer tarafından oluşturulan HTML başka bir sürümdür. Kullanıcının yerel önbelleği ve sunucusu zamanında senkronize edilmediğinde, bu yaygın bir önbellek yenileme sorunudur ve büyük olasılıkla depolanan veriler başka bir kopya olabilir.
Dolayısıyla, bu sistem gri tonlama denemesini ilk başlattığında, ürün müdürü hızlı bir şekilde bizden şikayet etmemizi istedi: Sayfayı açtığımda bir veri parçası gördüm. Bir saniye sonra gördüğüm içerik farklıydı ve her seferinde Bu, sayfaya girerken olur.
Veriler nasıl birleştirilir
Verinin dört sürümünü de hızlı bir şekilde nasıl birleştirebilirim? Statik düz çıkış modeli için küçük bir otomatik yapı sistemi oluşturduk.Ürün yöneticisi, veri sunucusunu senkronize etmek için yönetim tarafındaki verileri yapılandırdığında, derhal vnues adı verilen dahili oluşturma sistemimizi başlatacağız.
Bu sistem Node.js tabanlıdır. Geliştirme tarafından yazılan kod dosyalarından ve UI malzeme resimlerinden gerçek zamanlı olarak HTML'nin en son sürümünü oluşturacak ve daha sonra CDN'de yayınlayıp offlineServer ile senkronize edecektir. Bu, CDN dosyalarının sorununu çözebilir ve En son veriler tutarsız.
Ancak çevrimdışı paket önbelleği kullanıcının cep telefonuna yerleştirilmiştir Kullanıcının cep telefonundaki çevrimdışı önbelleği en hızlı şekilde nasıl güncelleyebiliriz? Bunu yapabilirsiniz: QQ istemcisinde her oturum açtığınızda, en son offlineServer dosyalarını geri yükleyin, ancak bu çözüm büyük trafik zorluklarıyla karşılaşacaktır.
QQ artık her gün yüz milyonlarca aktif kullanıcıya sahip ve en yüksek oturum açma değeri saniyede neredeyse yüz binler. 100KB çevrimdışı paketin bir güncellemesi her sürümde yüzlerce GB bant genişliği gerektirse bile, maliyet veya teknik düzeyde kabul edilemez. şey.
Çevrimdışı Sunucumuz iki bölüme ayrılmıştır: akış kontrolü ve çevrimdışı hesaplama. Bir sayfanın tüm kaynaklarının çevrimdışı paket hesaplamasıyla paketlenmesi gerektiğinde, tüm kaynakların paketlenmesine ek olarak, çevrimdışı hesaplamanın bu bölümü önceki tüm geçmiş sürümleri de dahili olarak depolar.Aynı zamanda, tüm farklar, geçmiş sürüme ve en son sürüme, yani her Çevrimdışı bir paketin kötü kısmı.
Bu plan aynı zamanda iş formumuza göre de belirlenir, çünkü ürün yöneticisi sayfa verilerini her güncellediğinde, temelde birkaç KB ila 10 + KB aralığındadır, bu nedenle kullanıcıların her çevrimdışı paketi güncellemesine izin vermemize gerek yoktur. Gidin ve tam paketi indirin.
Bir QQ kullanıcısı oturum açtığında, en son paketin indirilip indirilemeyeceğini her seferinde çevrimdışı akış kontrol sunucusuna soracaktır. Geçerli akış kontrol sunucusu tarafından sayılan bant genişliği kabul edilebilir bir maliyete sahipse (şu anda geçici olarak 10GB ila 20GB alan olacak şekilde planlanmıştır), CDN Bant genişliği yeterli olduğunda, en son fark istemciye gönderilir, böylece çevrimdışı paket güncellendiğinde, istemci minimum trafik maliyeti ile yenilenebilir.
Veriler ve etki
Bu sistem aracılığıyla, tüm BG'nin tüm H5 hizmetlerinin çevrimdışı paket kapsamını yaklaşık% 80 ila% 90 arasında tutmak için yalnızca bir düzineden fazla GB bant genişliği harcadık. Bu çalışmadan çok alışılmadık bir şey de bulduk, yani insanlar çevrimdışı paket ön-itmenin bant genişliğini tüketeceğini düşünüyorlar, ancak aslında sadece ara sıra ön-itme çok fazla bant genişliği tüketiyor; yıllarca ve aylarca baskı yapmaya devam ederseniz, aslında bant genişliğini tüketiyor. Çok küçük, çünkü her zaman farklı teslimat durumunda kalır.
Bu çalışmayı yaptıktan sonra, canlı web verilerini topladık ve statik doğrudan çıktı ile geleneksel sayfa modları arasındaki karşılaştırma çok açık. Aşağıdaki şekildeki sayfanın zaman alıcı kısmı, statik düz çıkış sayfası herhangi bir JS yürütme gerektirmediğinden, yalnızca WebView oluşturma gereklidir, bu nedenle statik düz sayfa süresi, geleneksel sayfaya kıyasla yaklaşık 500 milisaniye ile yaklaşık 1 saniyeye düşürülür.
Buradaki ilginç fenomen, çevrimdışı paketlerin maliyet etkinliğidir.Geleneksel sayfalarda çevrimdışı paketlerin kullanılmasının ağda zaman alan kısımda 700 milisaniyeden fazla tasarruf sağladığı görülebilir, ancak çevrimdışı paketleri kullanan statik doğrudan çıkış modu yalnızca yaklaşık 300 milisaniye tasarruf sağlayabilir. Statik doğrudan çıktı kullanılırken, ağ işlemi sırasında güvenilen harici CSS ve JS, doğrudan HTML'ye aktarılmıştır ve ek ağ istekleri gerekmemektedir. Bu nedenle, kendi ağ zaman alıcıları azaltılmıştır. Şu anda, çevrimdışı paketleri kullanmanın faydaları kademeli olarak başlar. düşüş.
Burada bir soru olabilir. Çevrimdışı paketler söz konusu olduğunda ağın statik doğrudan çıktı için 800 milisaniyeden fazla sürmesi neden 800 milisaniyeden fazla sürüyor. Yerel önbelleğin sıfır zaman harcaması gerekmez mi?
Saydığımız ağ süresi, WebView yükleme URL'sinin başlangıcından sayfanın ilk satırına kadar geçen süredir, bu aslında sayfa yüklemesinin bir bölümünü, WebView çekirdeğinin başlangıcını ve ağ bileşenlerinin ve işleme bileşenlerinin yüklenmesini içerir, bu nedenle zaman alıcı nispeten yüksektir.
Burada optimizasyon için yer olmalı, ancak müşteri ekibimiz ağın zaman alan kısmını optimize etmek üzereyken iş formumuz değişti. Geçmişte, ürün yöneticisi hangi sayfanın görüntüleneceğini yapılandırdı ve tüm kullanıcılar aynı içeriği gördü.Şimdi ürün yöneticisi her kullanıcının alışveriş merkezi ana sayfasına girerken gördüğü içeriğin tamamen farklı olduğunu söylüyor.
Örnek olarak aşağıdaki resmi alın: Örneğin, soldaki ana sayfadaki içerik rastgele tavsiye edilir ve sağdaki içerik aslında kullanıcının yüz ifadeleri ve makine öğrenimi yoluyla arka uç öğelerimiz tarafından gönderilen geçmiş davranışlarına ve kullanıcının tercihlerine göre önerilen içeriklere göre hesaplanır ve eşleştirilir.
Her kullanıcı gelir ve farklı içerik görür, bu nedenle statik düz çıkış modeli çalışmaz, çünkü tüm kullanıcı sayfalarını arka planda oluşturup CDN'ye göndermemiz imkansızdır.Ancak bu model de çok basittir. Çözmenin yolu.
Dinamik düz çıkış
HTML'yi CDN'de saklamıyoruz, ancak arka uç Node.js sunucusundaki tüm HTML dosyasını dinamik olarak birleştiriyoruz ve veri kaynağı dataServer'dan çekiliyor.
Bu model, ürüne olan talebi çözmekte ancak yeni problemler ortaya çıkarmaktadır. WebView, html elde etmek için Node.js talep etmeli ve Node.js arka plan sayfasını oluşturmalıdır. Ortadaki ağ zaman alıcı ve arka plan hesaplama süresi düşündüğümüzden daha büyüktür. Bu süreçte sayfanın tamamı render edilemez ve kullanıcı mağazamızın ana sayfasına girip bir boşluk görür, ürün yöneticisi de kabul edemez ve kullanıcı ödeme yapmaz.
Ek olarak, bu modda, WebView önbelleğini kullanmak neredeyse imkansızdır, çünkü arka uç doğrudan çıktı aynı zamanda arka uçta CSS / JS'de yürütülür ve Web Görünümü'nün saf bir statik HTML'yi önbelleğe alması zordur. Yukarıdaki sorunları çözmek için dinamik bir önbellek mekanizması geliştirdik.
Dinamik önbellek
Benzer şekilde, WebView'ın Node.js sunucumuza doğrudan erişmesine izin vermiyoruz. Ortaya, daha önce bahsedilen offlineCache'ye benzer bir ara katman olan sonicBridge'i ekliyoruz. Bu ara katman, ilk olarak HTML'nin tamamını Node.js sunucusundan WebView'a indirecek ve İndirilen içerik yerel olarak tamamen önbelleğe alınır.
Eskiden ağın tamamındaki tüm kullanıcılar için aynı HTML'yi önbelleğe alırdık, ancak şimdi ağın tamamındaki tüm kullanıcılar tarafından önbelleğe alınan içeriğin gerçek sunucudan alınan sayfalar olduğunu düzelttik.
Kullanıcı sayfaya ikinci kez girdiğinde, sonicBridge yerel olarak önbelleğe alınan sayfayı tercihli olarak WebView'a gönderir. Kullanıcı, ağ isteğinin sayfaya girmesini beklemeden içeriği görebilir. Bu, kullanıcı tarafındaki hız deneyimini büyük ölçüde artırır, ancak Başka bir sorun ortaya çıktı.
Aslında, kullanıcının gördüğü içerik, kullanıcının WebView'ı her açışında farklıdır. Node.js tarafından döndürülen veriler en sonuncudur. Bu nedenle, WebView'ın geri çekilen verileri yeniden yüklemesine izin vermeliyiz. Kullanıcı için deneyim: zaten açık. İyi HTML'yi yerel olarak önbelleğe aldım ve içeriği gördüm, ancak çalıştırdıktan sonra sayfanın tamamı yeniden yüklendi. Bazı düşük kaliteli modellerde, WebView yeniden yüklemesi çok zaman alır.Kullanıcılar, yeni içeriği yenilemeden önce WebView H5 sayfasının tamamının boş olduğunu açıkça hissedebilirler.
DOM'nin kısmi yenileme kısmından yukarıda bahsedilen statik doğrudan deneyimle birleştiğinde, ağ iletimi miktarını ve sayfaya gönderilen veri miktarını azaltabiliriz. Yaptığımız ilk şey, çok geç yenilemeyi önlemek için ağ aktarım miktarını azaltmaktır.
Veri iletimini azaltın
Node.js grubunun HTML protokolünü değiştirdik. SonicBridge ikinci kez veri istediğinde, Node.js sunucusu HTML'nin tamamını sonicBridge'e döndürmez, bunun yerine veri adı verilen kısmı bize geri gönderir.
Veri verilerini aldıktan sonra H5 sayfası ile native taraftan sayfanın sabit yenileme fonksiyonunu çağırmak ve veriyi sayfaya iletmek için anlaşma yaptık. Sayfa, kendi DOM düğümünü yerel olarak yenileyecektir, böylece sayfanın yenilenmesi gerekse bile tüm sayfa yeniden yüklenmeyecektir.
Özellikle, veri içeriği süreci perspektifinden, sonicBridge tam HTML'yi döndürmek için sayfayı ilk kez yüklediğinde ve aynı zamanda şablon etiketi adını verdiğimiz kimliği döndürdüğünde, bu şablon etiketi sayfadaki karma değerin statik bölümünü işaretleyecektir. , Bu önlem önbelleği kontrol etmektir. Döndürülen HTML'de, sonicdiff-banner gibi bazı etiketlerimiz de olacaktır.Bu banner, yenileme kimliğini belirler.
İkinci yükleme tarafından döndürülen veriler daha önce görülen HTML'nin tamamı olmadığında, yalnızca yaklaşık 37 KB veri döndürür.Bu veriler aslında bir JSON'dur, ancak sonicdiff-banner'a karşılık gelen DOM yapısını tanımlar. H5'te yürütülen kodu kaydetmek için, DOM düğüm kodunu doğrudan JSON'da yazdık, böylece sayfanın sadece id ile eşleşmesi ve yenilemesi gerekiyor.
Burada 37 KB'lık aktarım verisinden kaçınmak zordur Farklı işletmeler için yenilenen veri miktarının hala farklı olduğunu gözlemledik. Yenilemek için sayfaya gönderilen veri miktarını azaltabilir misiniz? Sonuçta, ürün yöneticisinin her seferinde değiştirdiği veriler çok fazla değildir.
Gönderilen sayfa verilerini azaltın
SonicCache katmanında, daha önce bahsedilenlere ek olarak, tüm HTML ve şablonu önbelleğe alacağız, ancak aynı zamanda dataCache için verileri de çıkaracağız.
Şablona ilk kez erişildiğinde, sonicdiff'teki kimlik bilgisine göre, tüm değişken veriler kalan sayfa çerçevelerinden kaldırılır. Kullanıcı onu ikinci kez yeniden açtığında, şablonu dönen verilere göre şablonla yerel olarak birleştirdiği sürece, tam HTML elde edilebilir.
DataCache'yi her seferinde önbelleğe aldıktan sonra, verilerde de bir fark yaratırız. Örneğin, bu istek 37 KB veri döndürür ve önbelleğe alınan son veri de 37 KB'dir. Gerçekte ne kadar dahili değişiklik yapıldığını belirleyeceğiz ve sonra Yalnızca fark HTML yenilemeye verilir, bu nedenle çoğu senaryoda, sayfamızın tüm sayfayı yenilemek için yaklaşık 9 KB veriyi işlemesi gerekir.
Önbellek ile, kullanıcı yerel olarak çok hızlı bir hızda açabilir.Diferansiyel verilerin iletimi, kullanıcıların yenilenmesi için bekleme süresini de azaltır Son olarak, veri sunumu sırasında farkın eklenmesi, sayfa yenileme aralığını büyük ölçüde düşürür.
Tüm ses modu süreci, daha karmaşık görünen aşağıdaki gibidir, ancak temel ilke, HTML alt şablonunu ve isteğin verilerini Köprü köprüsü üzerinden önbelleğe almaktır.
Burada şüpheler olabilir. Statik ve doğrudan yapılan offlineServer ve offline pre-push stratejileri burada hala yararlı mı? Aslında, daha önce bahsedilen dinamik sayfalar ve statik sayfalar için çevrimdışı önbelleğe alma mekanizmasını kullanmaya devam ediyoruz, çünkü iş sayfalarımızda hala QQ tarafından sağlanan JS API paketi gibi çok sayıda genel JS var ve bazı paylaşılan CSS'ler de çevrimdışı paket stratejisi aracılığıyla yapılıyor. Ön itme, bu aynı zamanda herkes her oturum açtığında bir indirme işlemidir.
Veriler ve etki
Bu modu tamamladıktan sonra, veri etkisi nispeten açıktır. İlk yükleme ve normal HTTP yükleme performansı benzerdir, ancak kullanıcı sayfayı ikinci kez açtığında genellikle sayfayı görmek yalnızca 1 saniye sürer ve bu 1 saniye de içerir İstemci başlatma işleminin ve WebView'ın ek yükü ve yükleme hızımız, ister 2G ister 4G olsun, kullanıcının ağ ortamından artık etkilenmez, yükleme hızı neredeyse aynıdır.
Ayrıca, kullanıcının ağı zayıfsa, örneğin, yerel bir önbelleğe sahip olduğumuz için bağlantı genellikle gerginse bir fayda da sağlar, böylece kullanıcı şu anda bağlantısı kesilmiş olsa bile sayfamız açılabilir.
Şablon güncelleme senaryosundan burada bahsedilmemiştir. Şablon güncellemesi, çıkardığımız şablonun sunucumuzda dinamik olarak değişebileceği anlamına gelir. Şu anda yükleme işlemi daha önce bahsettiğimizden farklıdır. Şablon değiştiğinde , Yine de zaman alıcı nispeten yüksek olan orijinal HTML yeniden yükleme sayfası sürecini takip edin, ancak istatistiklerimiz çoğu kullanıcının hala ikinci açılış olan veri yenileme durumunda olduğunu buldu.
Kalıcı bağlantının kullanılıp kullanılmayacağı
H5 hızlandırma optimizasyonu yaparken, herkesin, sunucunun bağlantısına, DNS'sine ve el sıkışmasına zaman alıcı erişimi önlemek için kalıcı bağlantılar kullanıp kullanmayacağımızı düşünmesi kolaydır.QQ gibi istemcilerin arka uç sunucuyla kalıcı bir bağlantısı vardır. nın-nin. Bu bağlantıyı arka plan sunucusundan bir HTML dosyası istemek ve Web Görünümü'ne teslim etmek için kullanırsanız, geçici olarak bir bağlantı isteği oluşturmaktan daha hızlı olur mu? QQ mesajlaşma arka planından Node.js sunucumuza erişmek için sadece bir ters proxy hizmeti kurmamız gerekiyor.Bu işlem açılabilir, ancak bu modelin tüm senaryolar için uygun olmayabileceğini değerlendiriyoruz.
Gerçekten de sayfaları yüklemek için kalıcı bağlantı kanalını kullanan bazı uygulamalar vardır, ancak mobil QQ üzerinde çalışmak daha zordur, çünkü mobil QQ istemcisi ve sunucu arasındaki kalıcı bağlantı kanalı çok geleneksel bir CS mimarisidir ve bir soket paketi gönderir. , Her istek paketinin gönderilmesi gerektiğinde, yanıt alınana kadar sonraki istek devam etmeyecektir.
Bu yanıt mekanizması, her seferinde bir bekleme sürecine ihtiyaç duyduğunu belirler ve soket paketinin kısıtlamaları, her seferinde iletilecek veri paketinin boyutunun sınırlandırılmasına neden olur, örneğin 30 + KB verilerimizin muhtemelen beş veya altıya bölünmesi gibi Veri paketleri için, kalıcı bağlantı, bağlantının zaman tüketimini azaltmak için kullanılsa da, sunucu ile birçok kez ileri geri iletişim, toplam zaman tüketimini artırır.
Ek olarak, Node.js sunucusundan döndürülen veriler HTTP akışıdır.WebView, oluşturma ve görüntülemeden önce tüm HTML'nin yüklenmesini beklemek zorunda değildir.İletimdeki ilk bayt elde edildiği sürece, belge ayrıştırma ve DOM oluşturma başlatılabilir. .
Kalıcı bir bağlantı kullanmak istiyorsanız, muhtemelen istemci tarafı şifreleme, şifre çözme ve paket gruplama adımlarından geçeceğiz ve görüntülemeden önce tüm HTML indirmesinin tamamlanmasını bekleyeceğiz. Bu sefer performansı yavaşlatacağını düşünüyoruz.
QQHybrid mimarisi
Yukarıdaki girişten sonra, herkes QQHybrid hakkında kabaca sezgisel bir izlenime sahip olabilir: 1. İşin bir kısmını WebScope'un ön uç geliştirmesinde yaptık; 2. Yerel düzeydeki terminal geliştirme öğrencilerimiz köprü köprüleme yaptı ve 3. Geçmişimiz Öğrenciler otomatik entegrasyon ve offlineServer push gibi birçok iş yaptı. Bu bölümün yapısı aşağıdaki gibidir:
Daha sonra, mimari diyagramın sağ tarafında sayfa trafiğini tanıtacağım. Her bir işletmedeki trafik dağılımını saydık.Aşağıdaki şekilde gösterildiği gibi, trafiğin büyük bir kısmının imaj kaynakları üzerinde tüketildiğini açıkça görebiliyoruz.Ancak bu analizi yaptığımızda, iş özelliklerinin imaj tüketimimizi belirleyip belirlemediğine dair şüphelerimiz de vardı. En çok? Mobil QQ'nun diğer H5 hizmetleriyle aynı mı?
Bahar Şenliği sırasında kırmızı zarfların trafik analizi
Tam da bir fırsatımız oldu. 2016 Bahar Şenliği sırasında Mobile QQ, Bahar Şenliği'nde kırmızı zarflar gibi hemen hemen tüm işletmelerin katıldığı bir etkinlik gerçekleştirdi. 2016 Bahar Şenliği gecesi kırmızı zarfları almak için hala ekranı dürtmek gibi bir izleniminiz olabilir. Bu tür bir ulusal karnaval, büyük bir trafik baskısı getiriyor Kullanıcılara her saniye yaklaşık 300.000 hediye paketi gönderiliyor ve kullanıcılara rehberlik eden web trafiği, saniyede yaklaşık yüz binlerce H5 sayfa açılmasıdır. Yoğun trafik 1 TB'ı aşıyor.
İçerideki görüntü trafiğini analiz ettik ve seviyenin neredeyse yarısını kaplıyor.Bunların bir kısmını çevrimdışı paket ön itme yoluyla önceden kullanıcıların cep telefonlarına dağıttık, ancak canlı ağdaki görüntü trafiği etkinlik sırasında hala 200 GB'ı aştı.
Trafik, operatörden satın almak için para harcamakla çözülebilecek bir sorun değil.Bahar Şenliği sırasında neredeyse tek bir alan adı altındaki trafiğin 200 GB'a yakın olduğu bir durumla karşılaştık. O zamanlar CDN yapısı neredeyse başa çıkamayacak kadar fazlaydı.
Hepimiz burada yapılacak çok şey olduğunu düşünüyoruz .. Görüntü trafiği kaydedilebilirse, bant genişliği maliyeti düşürülebilir. Kullanıcının ağ trafiği tüketimi ve cep telefonunun pil deneyimi daha iyi olabilir, bu nedenle ekibimiz görüntü formatıyla ilgili yeni şeyleri kontrol etti.
SharpP uygulaması
Herkes WebP'ye aşinadır ve Android bunu daha iyi destekler ve QQ ekibi dahili olarak SharpP adında bir resim formatı geliştirdi ve bu, WebP'ye kıyasla dosya boyutunun yaklaşık% 10'unu kaydedebilir. Aşağıda, CDN sunucumuzdaki mevcut resimlerden çıkarılan verilerin bir karşılaştırması yer almaktadır.
Resim boyutu baskındır, peki ya kod çözme hızı? Üst düzey, orta uç ve alt uç model analizi kullandık. Ne yazık ki, SharpP gerçekten WebP'den ve hatta JPG'den daha yavaştır. Neyse ki, işletmemizin görüntü boyutu çok büyük değil ve sayfa onlarca daha fazla harcıyor Milisaniyeler de kabul edilebilir, bu da ağı beklerken zamandan tasarruf etmekten daha faydalıdır.
Bu nedenle, SharpP formatını mobil QQ H5 işinde tanıtmayı planlıyoruz, ancak yeni görüntü formatının tanıtımı çok fazla uygulama maliyeti getirecek. Her şeyden önce, resim bağlantılarının çoğu kodda sabit kodlanmıştır ve sayfa, mobil terminalin SharpP formatını çözme yeteneğine sahip olup olmadığını bilmez.
H5 sayfaları, farklı mobil QQ sürümleri için farklı HTML hazırlamalı mı? Veya görüntü kaynağı CDN'de yayınlandığında, farklı formatlarda iki bağlantı üretilir ve ardından terminal sürümüne göre H5'te farklı bağlantılar seçilir? Bu geliştirme maliyeti elbette kabul edilemez.
Görüntü formatı sorununa ek olarak, farklı kullanıcı modellerinde veri israfı olduğunu gördük. UI tasarımımız genellikle iPhone6'nın ekran boyutu için yapılır, varsayılan değer 750px resim malzemesidir. 640px ve 480px gibi küçük ekranlı cep telefonları da 750px resimleri indirir ve ardından işleme sırasında uzaklaştırır.
Bu aslında çok fazla bant genişliğini boşa harcıyor, bu yüzden CDN'nin kullanıcının cep telefonunun ekran boyutuna göre farklı formatlarda resimler sunup sunamayacağını düşünüyoruz.
mimariyi yeniden şekillendirmek
Bu ekran uyarlama stratejisi de benzer bir özel formatın maliyetiyle karşı karşıyadır, çünkü CDN cep telefonlarının durumunu bilmiyor ve sonunda yeniden şekillendirme mimarisini önerdik. Tam resim indirme bağlantısı perspektifinden, kabaca 4 seviyeye ayrılabilir:
-
En alttaki katman CDN kaynak sitesi olarak adlandırılır. Burada bir resim formatı dönüştürme aracı kuruyoruz. İşletme tarafının JPG'yi önemsemesine ve ardından SharpP veya WebP oluşturmasına gerek yok. Sadece resmi CDN kaynak sitesinde yayınlayın ve otomatik olarak ilgili olana dönüştürülecektir. Biçim ve ekran çözünürlüğü;
-
Yukarıda, dosyaları hızlandırmak ve önbelleğe almak için ülke çapında sunucuları dağıtan, kullanıcının cep telefonu tarafından erişilen CDN düğümü bulunmaktadır.
-
SharpP kod çözme formatını tarayıcı çekirdeğine yerleştirmek için tarayıcı ekibiyle işbirliği yaptık, böylece en üstteki iş, mevcut tarayıcının WebP'yi veya sharpP'yi destekleyip desteklemediğini önemsemesine gerek kalmaz.
Sayfa açıldığında, WebView otomatik olarak terminalin ekran boyutunu ve hangi resim formatlarının CDN düğümüne desteklendiğini getirecektir.CDN düğümü daha sonra orijinal siteden en son resimleri alacaktır.Orijinal site çevrimdışı olabilir veya ilgili resimleri gerçek zamanlı olarak oluşturabilir. Yukarı.
SharpP kod çözme kitaplığını entegre etmenin yanı sıra WebView katmanını ayırmak, aşağıdakiler gibi diğer şeyler nispeten basittir:
-
İstek başlığına ek alanlar eklenir, örneğin User-Agent'a "Pixel / 750" eklenir, 480px'lik bir makineyse bu değer 480 olur;
-
SharpP'nin protokol başlığı Accept'e eklenir: image / sharpP
Kaynak sitede 3 * 3 sayıda resim saklanacak ve her işletme resmi yayınlanmak üzere kaynak siteye gönderildiğinde 9 resim üretilecektir. CDN düğümü, WebView'un isteğine göre kaynağa dönerken CDN kaynak sitesinden karşılık gelen resim türünü isteyecektir, ancak istek, iş ve WebView için hala aynı bağlantıdır, böylece mobil QQ'nun tüm H5 sayfalarının herhangi bir ön uç hattına ihtiyacı yoktur. Kodun değiştirilmesi, görüntü formatının getirdiği boyut uyarlamasının ve veri tasarrufunun keyfini çıkarabilirsiniz.
Aşağıdakiler daha canlı bir süreçtir, Kabul Et'e alanlar ekleyin ve ardından ilgili resmi geri getirin:
Bu teknoloji karmaşık değil Kişisel olarak çok derin bir teknik eşiğin olmadığını düşünüyorum. Daha çok istemciden, Web'den CDN arka ucuna tüm zinciri bağlamakla ilgili. Ancak bu süreçte, bazı çukurlara da adım attık: Birçok iOS kullanıcısının, sayfa gri tonlamalı görüntülendiğinde resimlerin görüntülenememesinden şikayetçi olduğunu gördük.
Bu bizi çok şaşırttı, çünkü o zamanlar bu teknoloji iOS'a dağıtılmamıştı, sadece Android kullanılıyordu. CDN kodunu kontrol ettik ve sorun yok, peki neden SharpP resimleri iOS kullanıcılarına dağıtıyoruz?
Daha sonraki analizler, Çin'in farklı bölgelerindeki operatörlerin CDN Cache'e benzer önbellekleme hizmetleri sağlayacağını buldu. Bir Android kullanıcısı ilk kez bir sharpP resmi talep ettiğinde, operatörün sunucusu CDN'mizden bir sharpP biçiminde bağlantı aldı. Aynı alandaki diğer iOS kullanıcıları, önbelleğin etkin döneminde bir talepte bulunduğunda, operatör URL'nin aynı olduğunu bulur ve doğrudan SharpP formatındaki görüntüyü iOS kullanıcısına döndürür.
Bu sorun, genel mimarimizde tam incelemeye gitmediğimiz ve üzerine adım attığımız bir çukurdur. HTTP, bu önbelleğe alma sorununu çözmek için standart bir kurala sahiptir. CDN içeriği dağıtırken, Vary alanı üzerinden önbelleği belirtirken, Accept ve User-Agent alanlarına başvurmak gerekir.Bu Vary'yi ekledikten sonra sorun temelde çözülür.
Bu dava bize ek ilham verdi. Mevcut ağımızda, Piksel alanının üç değeri vardır: 480px, 640px ve 750px. Ekran boyutunu doğrudan User-Aagent'te yazıp yazamayacağımızı dahili olarak tartıştık, böylece gelecekte Android bazı yeni ekran çözünürlükleri yayınlayacak.Ayrıca arka planda daha iyi adaptasyon yapabilir ve her model için farklı formatlar oluşturabiliriz. görüntü.
Bunu gerçekten yaparsak, operatörlere ve kendi CDN önbelleğimize büyük bir başlangıç noktasına dönüş ek yükü getirecektir. Her bir çözünürlük görüntüsü 498px gibi önbelleğe alınmalıdır. Ara operatör bu model önbelleğe sahip değilse, kaynağa dönmek için hizmetimize gidecek, böylece N ekran boyutu bize CDN'nin dönüşünün N katı getirecektir. Kaynak basıncı.
Veriler ve etki
Eve ne kadar yakınsa, nihai veri etkisi de daha belirgindir, aşağıdaki şekil Android gri tonlamalı efekt verilerimizdir. H5 işletmemizin görüntü trafiği 40 + GB'den 20 + GB düştü. Tencent için 20 + GB bant genişliği özellikle yüksek bir maliyet değil, ancak Bahar Festivali etkinlik senaryosunda, iş alanını neredeyse ikiye katlayabilir. Ek fayda, kullanıcının sayfa resmini görmesi için bekleme süresinin nispeten azalması ve kullanıcı tarafındaki trafiğin de yarı yarıya azalmasıdır.
Hızlı işlem sırasında H5'in kararlılığı
Sayfa yükleme hızı ve trafik tüketimi sorununu çözdüğümüzde, hızlı operasyonda H5'in kararlılığını da düşünmeye başladık. Ön uç geliştirmenin, belirli bir sayfanın kodunun değiştirildiği ve diğer işlevlerin anormal olduğu bir durumla karşılaştığına inanıyorum. Hibrit geliştirme kullanımının JS sayfaları için çok sayıda API sağlaması muhtemeldir ve istemci tarafındaki küçük değişiklikler JS API'lerini etkileyerek tüm ağda H5 sayfalarının anormal işlevlerine neden olabilir.
İşlevsel kararlılığın yanında büyük bir sorun daha var.Her gün ön uç sayfalar yayınlıyoruz Sayfaların optimize edilmiş performansı nasıl bozulmaz? Sonunda sayfa yükleme performansını 1 saniyeye düşürmek için zaman ayırdık. Tüm sayfanın performansını düşürecek daha fazla harici JS / CSS bağımlılığı getirilmesi gibi bazı ön uç değişiklikleri olacak mı? Bu sorunları çözmek için bazı araçlar yaptık.
Hızlı Test Otomasyonu
Buna dahili olarak hızlı otomasyon araçları diyoruz. Ön uçtaki tüm test senaryo setlerini otomatik testlere yazacağız ve ardından işlevlerin normal olup olmadığını kontrol etmek için tüm ağın tüm sayfalarında tüm test senaryo setlerini çalıştıracağız.
Web Performans Testi
Web Performans Testi'ni kullanarak Web'in performansını izleyeceğiz Burada ilk gözlemlediğimiz şey, sayfa her açıldığında tüketilen trafiktir, bu nedenle sayfaya yüklenen tüm resimlerin SharpP'ye dönüştürülüp kullanılamayacağını analiz etmek için araçlar kullanacağız. JPG. Bu izleme setiyle, ekibimizin dışındaki H5 geliştiricilerinin sayfalarını optimize etmeleri teşvik edilebilir.
Ön uç genellikle, optimizasyon vb. Sırasında taleplerin sayısını azaltma ihtiyacından bahseder. Bunlar askeri düzenlemeler olarak kabul edilebilir ve test sırasında bunları izleyeceğiz. Daha önce bazı istemci optimizasyon yöntemlerinden ayrıntılı olarak bahsetmemiştim, ancak istemcide WebView'ın zaman alan başlangıcını da izledik.
Ön uç dağıtım süreci
Ayrıca daha titiz bir ön uç sürüm sürecimiz var. Test ortamında yazılan ve test edilen tüm kodlar, resmi ortama yayınlanırsa QTA ve WPT doğrulamasından geçmelidir. Otomatik test başarı oranı% 95'in altındaysa, Göndermeye izin ver.
Resmi ortamda yayınladıktan sonra, harici ağda kapsamlı bir puanlama izleme sistemimiz de var. Birincil izleme göstergesi hız hakkındadır. Sayfa açılma hızını müşterinin zaman alıcı, ağda zaman alıcı ve sayfa harcayan zamana ayırıyoruz. Ayrı ayrı izlenirler.
Günlük hız değişikliklerini gözlemlemek için her gün aşağıdaki izleme raporlarını çıkarıyoruz Burada sadece tüm ağın performansı ile ilgilenmiyoruz, 5 saniyeden fazla geciken kullanıcıların oranı gibi yavaş kullanıcıların deneyimleriyle daha çok ilgileniyoruz.
Bunlara ek olarak, H5 sıklıkla sayfanın anormal olmasına neden olan bazı JS hatalarıyla karşılaşır ve yavaş yükleme kullanıcının beyaz ekranı çok uzun süre görmesine neden olur.Bunları sistematik olarak izliyoruz.
Entegre işletim sistemi
Daha önce bahsedilen içeriğe ek olarak, bir Hata Ayıklama platformu da oluşturduk ve birçok hata ayıklama özelliği önceden tüm mobil QQ terminallerine yerleştirildi. Kullanıcının DNS çözünürlüğünü, hangi sunucunun vurulduğunu, kullanıcının operatör tarafından ele geçirilip geçirilmediğini vb. Kontrol etmek için uzak komutları kullanabiliriz.
Sonuna yaz
Tüm QQHybrid mimarisi temel olarak tanıtıldı.Performans optimizasyonuna ek olarak, CDN mimarisini de ayarladık ve operasyonel izleme araçları yaptık. Bence bu, tüm H5 ve hibrit ekibimizin sayfayı cesurca değiştirmesine ve yeni özellikler yayınlamasına izin verirken, aynı zamanda kararlılık ve güvenilirlik sağlar.
Tüm süreç, hibrit mimarinin daha önce herkesin anladığı gibi olmadığını, ancak müşteri ile ön uç arasındaki işbirliğinin iyi olduğunu ve arka uç teknolojinin de tüm mimari sistemde büyük bir rol oynadığını hissettirdi. CDN dönüşümü için operasyon ve bakım ekibinden de destek istedik.QTA ve WPT'nin de test ve geliştirme ekiplerinin katılımı var. Tüm sistemin kurulmasının tüm pozisyonların yan yana çalışmasının sonucu olduğu söylenebilir.
Bugünün TavsiyesiOkumak için aşağıdaki resme tıklayın
Programcı, istediğiniz teknik lider bu mu?
