Geçmişte, belirli bir işlevin birden fazla terminali kapsadığını söylediğimizde, genellikle bunun PC ve mobil gibi farklı cihaz türleri arasında uygulanabileceği anlamına gelir; veya daha spesifik olarak, çapraz işletim sistemleri kadar büyük olabilen "çapraz platform" anlamına gelir, örneğin Windows, macOS, Linux, iOS ve Android vb., Belirli bir teknolojideki farklı uygulama kitaplıkları kadar küçük olabilir.

Ancak bugün, MVVM mimari modeli boyunca çeşitli ortamlar hakkında senaryolar sunacağız.

Chameleon açık kaynak kodlu bir çapraz terminal çözümüdür.Amaç, MVVM çapraz terminal ortamını birleştirmektir, böylece MVVM mimarisi ile tasarlanan herhangi bir terminal geliştirilebilir ve onu kullanarak çalıştırılabilir.

Böyle bir MVVM ortamında, Weex, React-Native, WebView / browser ve Flutter gibi çeşitli çapraz uç teknolojilerin yanı sıra uyguladıkları WeChat apletleri, hızlı uygulamalar, Alipay apletleri, Baidu gibi belirli iş ürünleri yer alır. Akıllı uygulama, bugünün başlık uygulaması ve diğer çeşitli uygulamalar.

Belki de burada pek çok "mini program" türünden bahsedildiğini keşfetmişsinizdir. WeChat mini programları kavramı ve hatta ilk sürümleri ortaya çıksa da, pek çok popüler olmayan sesler vardı, ancak gelişmeye devam ettikçe popüler hale geldi. Yaşam için vazgeçilmez bir başvuru formu. Ma Huateng, Kasım 2018 itibarıyla 1,5 milyon WeChat mini program geliştiricisi olduğunu, mini program uygulama sayısının 200'den fazla alt sektörü kapsayan 1 milyonu aştığını ve günlük aktif kullanıcıların 200 milyona ulaştığını açıkladı. Bu tür başarılı bir deneyim ve hayatın neredeyse her alanına dokunan devasa trafik girişi, herkes girmek istiyor, böylece diğer şirketlerin benzer küçük program çözümleri verdiklerini görebilirsiniz.

Öte yandan küçük programların çiçek açmasının yanı sıra Xiaomi, Huawei ve OPPO gibi 10 Android cep telefonu üreticisi de 2018 yılında hızlı bir uygulama ittifakı oluşturarak bir dizi hızlı uygulama yayınladı.

Chameleon'un amacı, bu uçları aşmaktır ve giderek daha fazla farklı uygulamayla, çapraz uç senaryolar daha karmaşık hale gelmeye devam etmektedir. Röportaj yaptık Bukalemun kurucusu Zhang Nan , Kendisinden özellikle bu süreçte Bukalemun'un gelişimini okuyucular için paylaşmasını istedi.

Proje adresi: https://github.com/didi/chameleon

Bu makale, Chameleon'un ilk genel uygulama prensibidir!

Aşağıdakiler dahil birçok kuru ürün:

• Terminal geliştirme gelecek geliştirme modeli
• Bukalemun çapraz terminal uygulama prensibi
• Çeşitli çapraz terminal çözümlerinin mevcut ilkelerinin karşılaştırılması (çeşitli küçük programlar, hızlı uygulamalar, vb.)
• Taro ile Karşılaştırma
• Evrim sürecinde karşılaşılan zorluklar ve düşünceler

Neden ilk etapta Chameleon'u geliştirdiniz?

Bu konu endüstri geçmişinden tartışılabilir.

Çin İnternet Ağı Bilgi Merkezi (CNNIC) tarafından yayınlanan "Çin'in İnternet Geliştirme Durumu İstatistik Raporu" na göre, Haziran 2018 itibarıyla Çin'deki İnternet kullanıcılarının sayısı 1 milyar WeChat hesabı, 400 milyon Alipay hesabı ve Baidu aylık hesaplarıyla 802 milyona ulaştı. 330 milyon; Öte yandan 2018'in 3. çeyreğinde Çin'in Android telefonları, aylık yaklaşık 600 milyon ömürle toplam akıllı telefonların% 80'inden fazlasını oluşturdu.

BAT ve Android, Çin İnternetinin gerçek kullanıcı portalları haline geldi. Yüksek trafiğe sahip her giriş seviyesi APP bir platform olmayı, ekolojik bir platform olmayı ve İnternet trafiği girişi olmayı, iş katmanından çok sayıda üçüncü taraf uygulamasına erişmeyi, şirket APP'sinin daha kurumsal çıkarlarla ilişkilendirilmesine ve daha güçlü canlılığa sahip olmasını umar; Teknik seviyeden, "yerel yetenek arayüz katmanı" büyük miktarda kullanıcı verisi toplamak için kullanılabilir Tüketici İnternetinden endüstriyel İnternete, sürüş ve kararlar almak için yaşamın her kesiminden çok sayıda temel kullanıcı verisi ipucu gereklidir.

Böyle bir arka plan altında, bilgisayar teknolojisinin gelişim tarihi ile birleştiğinde, her yeni teknolojinin "özyönetim" aşamasından geçeceğini biliyoruz ve mini program teknolojisinin bir istisna olmadığını, bu nedenle çeşitli diğer mini program platformlarının ortaya çıktığını gördük. .

WeChat Mini Programlarının yaratıcısı olarak, diğer Mini Programlar, teknik uygulama ilkeleri ve arayüz tasarımı açısından kasıtlı olarak taklit edilse de, Mini Programları farklı platformlarda yayınlamak için birinci basamak geliştirici olarak, genellikle geliştirme ve testin tekrarlanması gerekir. Önceki 1 birimin iş yükü N birim iş olur. Ve bu, hızlı uygulamalar gibi diğer girişleri saymaz.

Bu durumda, Didinin Ar-Ge mühendisleri en önemli "kurbanlardan" biridir. Didi Chuxing'in WeChat cüzdan, Alipay ve Android hızlı uygulamalarında ilgili girişleri vardır ve kullanıcı trafiğinin oranı düşük değildir.

Ar-Ge öğrencileri sadece terminalde H5'in esnekliğini takip etmekle kalmaz, aynı zamanda yerel yaklaşan performansı da takip eder. Portalların, ana terminalin, bağımsız terminalin, WeChat uygulamasının, Alipay uygulamasının, Baidu uygulamasının ve Android Satıcı Alliance Hızlı Uygulamasının genişletilmesiyle karşı karşıya kaldığında, her platformda tek bir işlev tekrar tekrar uygulanmalıdır ve geliştirme ve bakım maliyetleri iki katına çıkmıştır. Yalnızca tek bir kod setiyle oluşturulabilen çok girişli bir çözüme acil bir ihtiyaç vardır, bu nedenle gerçekten çok uçlu bir dizi kod çalıştırmaya odaklanan Chameleon (CML, Cameron) gibi bir proje oluşturmaya başladık.

Chameleon'un çekirdeği MVVM mimarisini kullanıyor, neden birden fazla terminalde uygulanabiliyor?

MVVM ayrıca, Görünümün durumunu ve davranışını özetleyen ve görünüm kullanıcı arayüzünü iş mantığından ayıran MVC'nin (Model Görünüm Denetleyicisi) geliştirilmiş bir sürümü olan Model Görünümü ViewModel olarak da adlandırılır. Verinin yansıtıcı görünümleri yönlendirmesine izin veren bir modeldir.Orijinal amacından sapabilir.Daha çok görünüm verileri arasında bir "iletişim protokolü" gibidir ve terminal geliştirmeyi daha basit hale getirir.Bu bir eğilimdir. Geleceğe yönelik çerçeveler bu modeli kullanır.

Facebook açık kaynaklı React 2013'te. React projesinin kendisi bir Web UI motorudur.Sürekli geliştirme ile yerel mobil uygulamalar yazmak için React Native projesini ortaya çıkarmıştır. MVVM modunu çapraz terminal yönüne getiren odur.

Vue.js, 2014 yılı civarında piyasaya sürüldü ve çok sayıda kullanıcı grubunu işgal etti. 2016'da, Alibaba da buna dayalı Weex projesini yayınladı ve Vue ile Native App yazmayı mümkün kıldı.

2018'in sonunda Google, geleceğe yönelik çapraz Android ve iOS Flutter 1.0.0'ı resmi olarak yayınladı.

prensip

Terminal geliştirmenin üç ana unsur-arayüz performansı (yapı, görünüm) katmanı, mantık işleme katmanı ve sistem arayüz katmanından (ağ, depolama ve ortam, vb.) Ayrılamayacağını biliyoruz.

Geliştirici kodu yazdığında, "arayüz sunum katmanı" arayüz modelinin arayüz çizim arayüzü, başlatma aşamasında (yaşam döngüsü) çağrılır.Kullanıcı arayüze dokunduğunda, "arayüz sunum katmanı" olayları kullanıcı "mantık işleme katmanına" gönderir ve bu katmandan geçer. Koşul yargısı işlenir ve kullanıcı arayüzüne geri gönderilir, işleme sürecinin "sistem arayüz katmanını" çağırması gerekebilir ve geri bildirim sürecinin "arayüz sunum katmanı" arayüzünü çağırması gerekir.

İster Web, Android veya iOS üzerinde proje geliştirme olsun, geleneksel terminal geliştirme mimarisi modeli altında, her terminalin çevresel arayüzüne, özellikle arayüzle ilgili model tasarımına büyük ölçüde bağlıdır. İOS sistemi altındaki çizim arayüzü, Objective-C dil ortamı altındaki UIKit çerçevesine dayanmaktadır; Android sistemi altındaki kullanıcı çizim arayüzü Java dil ortamına dayalıdır ve XML yapı hiyerarşi ağacı LayoutInflater tarafından işlenir; web tarafı çizim arayüzünü tanımlamak için DOM modelini ve CSS'yi kullanır.

MVVM'deki anahtar, ViewModel katmanı, arayüzü ve mantık katmanını tamamen ayırır ve arayüz performansı ile mantık işleme katmanının yanıt olayı (güncelleme / bildirme) arasındaki ilişkiden sorumludur. , Bu "izolasyon katmanı" yeterince standartlaştırılmış ve yukarı ve aşağı iletişim kuracak kadar saf.

Model mantığı işleme, herhangi bir dilde uygulanabilen saf bir iş yanıt mantığıdır. Android'in Java'sını veya iOS'un Objective-C'sini kullanabilirsiniz. İyi bir ruh halindeyseniz "dünyanın ilk dili PHP" yi de kullanabilirsiniz. JavaScript'in genel olarak seçilmesinin nedeni büyük ölçüde, bu alanda düşük öğrenme maliyetleri, içsel çapraz uç nitelikler, sanal makineler (V8, JavaScriptCore) ve çeşitli yönlerde daha iyi bileşen yapımı ve aktif ekoloji gibi önemli avantajlara sahip olmasıdır.

Sistem arayüz katmanı daha da basittir, sadece birleştirilmiş temel arayüzü + genişletilebilir arayüz yeteneklerini sıralayın.

Çeşitli MVVM çözümleri

Çeşitli MVVM çözümlerine bir göz atalım.

Hızlı uygulamalar için React Native, Weex ve MVVM

Geliştirici tarafından yazılan kod bir sanal makinede (V8, JavaScriptCore) çalışır ve sanal makine kabı, genişletilmiş bir sistem temel arabirimi içerir. Çalışma zamanında, arayüzü tanımlayan veriler (esas olarak CSS + DSL tarafından açıklanan içerik) iletişim katmanı aracılığıyla Android ve iOS render motorlarına iletilir.Kullanıcı arayüze dokunduğunda, iletişim katmanı aracılığıyla sanal makinedeki iş işleme koduna iletilir. Kod, ağ, depolama ve medya gibi arayüzleri çağırabilir ve son olarak arayüze tekrar geri bildirim sağlayabilir.

Flutter'ın MVVM'si

Flutter ve RN arasındaki en büyük fark, "JavascriptCore / V8 + JS" nin "C ++ tarafından uygulanan motor + Dart tarafından uygulanan Framework + statik tip Dart + tarafından makine koduna derlenmiş" ile değiştirilmesidir.

Flutter'ın planı aşağıdaki şekilde gösterilmektedir:

Hizmet, aslında yerel yetenek arabirim katmanıdır ve Pencere Öğesi ağacı, görünüm katmanı modelidir.

Flutter ve RN tasarım açısından benzerdir. Flutter belgesinde "Flutter'da hemen hemen her şey bir parçacıktır" dan bahseder, parçacığın çağrısı RN'nin JSX'inden Flutter'ın pencere öğesi çağrısına değişti ve kullanıcı arabiriminin görünümü RN'nin CSS'sinden açıklandı ( Metin stili, düzen modeli, kutu modeli) özelleştirilmiş Flutter Widget'ına (textStyle, Layout Widget, Widget).

Özünde, Flutter aynı zamanda bir MVVM mimarisidir.Mantık katmanı, görünüm katmanını setState aracılığıyla güncellemesi için bilgilendirir. Belirli bir dereceye kadar, bu nedenle Flutter bunun bir web çerçevesine dönüştürülebileceğini söyleyebilir. Çekirdek hala bu veriye dayalı görünüm mimarisi modeline dayanmaktadır ve işletme kodu, Her iki uçta da benzersiz bir "görünüm modeli".

Çeşitli küçük programların MVVM'si

Mini Programlar, temelde Weex ve React Native ile aynıdır.Büyük fark, ilkinin hala işleme motoru olarak WebView tarayıcısını kullanması, ikincisinin ise oluşturma motorunu ayrı ayrı uygulamasıdır (bu nedenle çok sayıda CSS mizanpaj modeli bunu desteklemez).

Özellikle, Chameleon'da nasıl uygulanıyor?

Her şeyden önce, herhangi bir uygulama katmanının üst düzey dil kodu bloğu birkaç katmana bölünmüştür: dil katmanı (Dil), çerçeve katmanı (Framewrok) ve kitaplık katmanı (Kitaplık):

• Dil Bir programı uygulamak için gereken temel mantık komutları: mantıksal değerlendirme (if), döngü (for), işlev çağrısı (foo ()), vb.
• Framewrok - Genel olarak konuşursak, yaşam döngüsü (onLoad, onShow), modülerlik ve veri yönetimi gibi bir Uygulama uygulaması etkileşim görevini tamamlamak için gereken özellikler.
• Kitaplık anlaşılır bir şekilde "yöntem paketi koleksiyonu" dur. Örneğin, web ön ucunda, Vue bir çerçeve olarak adlandırılmaya daha uygundur ve jQuery, bir kitaplık olarak adlandırılmaya daha uygundur; Android sistemi altındaki etkinlik yöneticisi + pencere Yöneticisi Görüntüleme Sistemi koleksiyonuna çerçeve denir ve SQLite ve libc, kitaplıklar olarak adlandırılmaya daha uygundur.

Bu, Bukalemun'a karşılık gelir:

Uygulama ilkesine özgü panoramik mimari diyagramı aşağıdaki gibidir:

Chameleon'un "MVVM çapraz uç ortamını birleştirilmiş hale getirme" hedefine ulaşmak için aşağıdakileri yaptığını anlayabilirsiniz:

• Standart Dil (CML DSL), Çerçeve ve Kitaplık (yerleşik bileşenler ve API) protokol katmanlarını tanımlar.
• Çevrimdışı derleme sırasında DSL'i her iki uçta DSL'e çevirin, yalnızca derleyin Dil Seviye, yeterince temel ve kararlı bir koddur.
• Çerçeve, her iki tarafta çalışırken birleştirilir ve ekolojinin kullanımını kolaylaştırmak için her tarafta mümkün olduğunca orijinal çerçeve kullanılır, böylece birçok bileşen doğrudan kullanılabilir.
• Kitaplık (yerleşik bileşenler ve API) her bir uçta çalışırken ayrı ayrı uygulanır.
• Kullanıcılara, yukarıdaki yönlerin genişletilmesini kolaylaştırmak, alt ucun özel niteliklerine ulaşmak ve sürdürülebilirliği artırmak için polimorfik bir protokol sağlayın.

Gerçekleştirme fikri çok basittir.Tüm tasarımlar MVVM standardizasyonu içindir ve yedekli tasarım gerekmez.Bu nedenle, makro açıdan bakıldığında Node.js (libuv) hem Windows hem de macOS sistemlerinde aynı anda çalışarak bir çapraz platform soyutlama katmanı sağlar.

MVVM açısından:

• Görünüm (sunum katmanı)
• Üçüncü Taraf Oluşturma Motoru: Tarayıcının Vue, Webview'deki uygulama motoru, Android'deki React Native / Weex motoru ve hatta Flutter'daki Dart Çerçevesi gibi çeşitli çerçeveler için mevcut çerçeveler vardır.
• Chameleon yerleşik bileşen kitaplığı: Polimorfik protokol, birleşik bileşenler görünümünü, girdiyi, metni, bloğu ve hücreyi vb. Tanımlar. Çoklu karmaşık arabirim işlevlerini türeten arabirim grubu katmanının orijinal temel sınıfıdır.
• ViewModel (ilişkilendirme katmanı) Bukalemun dilbilgisi çevirisi
• Bileşen çağrısı
• döngü
• Koşullu yargı
• Olay geri arama korelasyonu
• Baba-oğul ilişkisi
• ...
• Model (Mantıksal Yanıt Katmanı)
• JavaScript kodu
• CML Runtime çerçevesi
• Chameleon API: Polimorfik protokol, birleşik bir arayüz, cml.request, cml.store, vb. Tanımlar.

Chameleon'un çoklu terminal çözümü geliştiricilere büyük kolaylık getirdi Spesifik performans nedir?

Tek kelimeyle: Bukalemun gelişimine dayalı, Verimlilik artacak ve artacak .

Çeşitli uçların ortaya çıkmasıyla birlikte, başlangıçta 1 olan iş yükü, birden fazla ucun varlığından dolayı N kat oldu. Chameleon ile iş yükü 1,2'ye geri dönecek. Bu ekstra 0,2 iş yükü, aşağıdaki senaryolar gibi her bir uçtaki farklılaştırılmış işlevleri yerine getirmektir:

• Belirli bir iş kolu Chameleon'a taşındığında, "pasaport giriş bileşeni" olmadığı ve çeşitli küçük programlarda şifresiz giriş yapabildiği bulundu.Web'de ve Yerelde, giriş yapmak için giriş kutusu açıldı. Farklı işletme kullanıcıları farklı etkileşim modellerine sahip olduğundan Chameleon bunu sağlamadı. Bileşenler; geliştiricilerin polimorfik protokole dayalı tek bir oturum açma bileşenini genişletmesi gerekir < pasaport/ > Her durumda, oturumun sonunda oturum açtıktan sonra bir geri arama belirteci döndürülür ve harici bileşenin içeride nasıl çalışacağıyla ilgilenmesine gerek yoktur.
• Kullanıcının paylaşım işlevine ihtiyacı vardır ve "paylaşım bileşeni" olmadığını anladı. WeChat Web terminalinin sağ üst köşesinde paylaşıma rehberlik edebilir ve doğrudan uygulamada paylaşabilirsiniz. Farklı iş kullanıcıları farklı etkileşim modellerine sahiptir. Kullanıcıların polimorfik protokole dayalı olarak tek bir oturum açma bileşenini genişletmesi gerekir. < Paylaş/ > .

İşletme biriktikçe, her iki uç arasında büyük farklılıklar olan bu tür bir örnek, her bir iş bileşeninin ayrı bir bakımı haline gelebilir ve geliştirmeyi daha sonra tekrar etmeye gerek yoktur ve ürün deneyimi birleştirilir ve bileşen üç katmanlı yapı " CML çerçevesi yerleşik bileşenleri > CML uzantı bileşeni > İşletme geliştiricileri tarafından genişletilen polimorfik bileşenler "% 100 birleştirme elde edin. Bileşenler gittikçe daha az iş geliştirme iş yükü biriktirdikçe, mühendisler daha anlamlı şeyler yapmaya odaklanabilir, ki bu Chameleon'un amacıdır.

Chameleon projesinin sürekli bakım sürecinde, birleşik bir çapraz terminal soyutlamasına dayalı olarak, Chameleon yeni bir terminal yayınladıktan sonra, iş kodunuz değiştirilmeden sorunsuz bir şekilde yeni bir terminale aktarılabilir. Örneğin, cml-yanxuan projesi geliştirildiğinde, üç terminal desteklendi ve Baidu ve Alipay uygulamaları daha sonra eklendi.Orijinal kod doğrudan beş terminalde çalışabilir ve bir uçta gördüğünüz şey birden fazla uçta gördüğünüzdür.

Geliştirme sırasında yalnızca 3 terminal çalıştırabilir

Orijinal kod, 5 terminali sorunsuz bir şekilde destekler

Ayrıca, büyük şirket ekipleri için güçlü teknik yeteneklere sahiplerse, kendi ellerinde geliştirilen kodu kontrol etmeyi ve çıktı sonuçları üzerinde daha iyi kontrol sahibi olmayı umdukları özellikle vurgulanmaktadır. Aslında, Chameleon'un yerleşik bileşenleri ve yerleşik API'leri değiştirilebilir, bu nedenle tüm bileşenler işletme tarafı tarafından geliştirilir. Bir gün, aşağıda gösterildiği gibi yerel bileşenleri doğrudan dışa aktarmak istemezseniz Chameleon'dan ayrılabilirsiniz:

Birden fazla terminalde mevcut birleşik çözümde Taro daha dikkat çekici.Özellikle Chameleon ve Taro'yu karşılaştırabilir misiniz?

Chameleon ile diğer çözümler arasındaki en büyük farkın, diğer çerçevelerin tümünün küçük program geliştirmeleri olduğunu, yani küçük programlar yazmak için Vue veya React kullanmak olduğunu düşünüyoruz.Bu çerçevelerin resmi örnekleri de WeChat küçük programları çalıştırıyor.

Chameleon'un öncülü MPV'ye (Mini Program Görünümü) daha çok benziyorlar, yani mini program geliştirmenin nasıl geliştirileceğini düşünüyorlar. WeChat Mini Programı 2017'de piyasaya sürüldüğünde, Didi, beyaz listeye alınmış bir kullanıcı olarak, önce ona erişmeye çalıştı ve tekrarlanan geliştirme sorunuyla karşılaştı. Şu anda, MPV adlı bir projeyi tamamlamak için küçük bir proje ekibi oluşturduk. İlk aşamanın amacı, "kullanıcıların performansını etkilememek ve çerçeve ilkesine güvenmeden Web ve WeChat uygulamalarını çalıştırmak için bir dizi kod uygulamaktır."

Çok iyi görünüyor. Web ve uygulama sonlarına ulaşmak için bu çözümü kullanarak, kodun yeniden kullanımının% 90'ından fazlası gerçekten elde edildi. Genel geliştirme verimliliği ve test verimliliği belirli bir dereceye kadar iyileştirildi, ancak gerçek bir çoklu çoklu birleşik değil .

Tek başına Bukalemun ve Taro arasındaki farktan bahsetmişken, genel olarak bu tabloya göre sınıflandırılabilir:

Çapraz uçlu çözümler üretirken tablodaki her bir öğenin dikkate alınması gerekir. Chameleon dışında, diğer çözümlerin sadece uygulamayı geliştirdiğini veya WeChat uygulamasının API ve bileşen arayüz tasarımını taklit ettiğini söylüyoruz. Taro, diğer uçtaki WeChat uygulamasının arayüzlerini ve bileşenlerini simüle etmek için JSX'i küçük bir program şablonuna dönüştürür ve diğer ucu daha çok bir WeChat uygulaması gibi yapar.İş geliştirme sırasında tutarsız alanlar, çevresel değişkenlerin ayrı ayrı çağrılmasını gerektirir ve bu da uç farklılıklara neden olur. Mantık ve çarpım mantığı birbirine karıştırılır.

Ek olarak, mini programın güncellemesini takip etmek zorundadır ve iş tarafı çift bağımlılığa sahip olacaktır; diğer uç ve mini program tutarlı olamaz ve kullanıcıların, bakıma elverişli olmayan çeşitli farklılıklarla uyumlu olması gerekir.

Peki ya Bukalemun? Chameleon bu sorunları dikkate aldı, bu nedenle erken sözde çapraz terminal MiniProgram Görünümü oluşturulduktan sonra sürekli gelişim sürecinde, gerçek bir çapraz çok terminalli çözüme dönüştü.

Önceki tablo, Chameleon'un hem birliği hem de farkı dikkate aldığını ve farkın sürdürülebilirliği etkilemediğini göstermektedir; uçlar arasındaki farklar gerçekten çok büyükse, aynı sayfayı birden çok uca uygulamak için tek bir kod seti kullanmayın ve Birleşik bir ortak bileşendir.

Bu sadece Chameleon ve Taro'nun tesadüflerinin bir karşılaştırmasıdır, ancak Chameleon'un sadece bir ön uç çerçeve olmadığını unutmayın, o:

• Ayrıca birleşik bir Chameleon Yerel SDK'sı da var. Chameleon yalnızca her türden küçük programı birleştirmek istemiyor, aynı zamanda kendi APP'sini de kapsıyor. Küçük programlarla aynı yerel yeteneklere sahip olmayı umarak API'leri ve bileşenleri Yerel SDK aracılığıyla genişletmeye devam edecek. İdeal olarak, bir dizi kod çeşitli küçük programlarda ve şirket içi uygulamalarda sorunsuz ve sorunsuz bir şekilde çalışabilir.
• Henüz açık kaynaklı bir arka uç yönetim sistemi yoktur.
• Açık kaynaklı XEdtior Ar-Ge dışı düzenleyici, doğrudan çapraz terminal sayfalarını düzenleyebilir ve doğrudan yayınlayabilir.

Buna ek olarak, gelecekte aşağıdaki yetenekler getirilecektir:

• Birleşik arka uç arayüzü (mesaj gönderme, paylaşma ve ödeme vb.)
• Birleştirilmiş MVVM standardına dayalı olarak, Flutter'a dayalı daha yerel uygulamalar

Mevcut çeşitli küçük programlar ve Yerel çapraz terminal çerçeveleri, birden fazla tarayıcı varken Safari, Chrome, Firefox, IE 6/7/8/9 ve Android tarayıcılarının hüküm süren dönemine benzer. Bu benzetmede, Chameleon'un arayüz bileşenleri daha çok bir jQuery gibi tasarlanmıştır.

Bazı ağ istekleri XHRHttprequest ve bazıları ActiveXObject'tir. JQuery, kullanıcıların neye ihtiyacı olduğunu düşünür ve alma, postalama vb. Desteği sağlamak için bir ağ isteği arabirimine ihtiyaç duyar. Bu nedenle jQuery, kapsüllenmiş ağ sağlayan ActiveXObject veya XHRHttprequest olmayan bir $ .ajax arabirimi yazar. Arayüz, dahili olarak farklı uçlarda nasıl çağrıldığını umursamanıza gerek yok, jQuery dahili olarak uyumlu hale getirmenize yardımcı olacaktır.

Chameleon da aynı fikre sahip: Tüm arayüz tasarımları, hiçbir fark olmaksızın tüm terminaller arasında gerçekten uyumludur ve yalnızca mevcut terminalin arayüz çağırma kodunu korur: IE yalnızca ActiveXObject'i ve Chrome yalnızca XHRHttprequest'i tutar.

Chameleon'un arayüz tasarımı, sürdürülebilirliği sağlamak için standart bir polimorfik protokol kullandığından jQuery'den daha güçlüdür.Performans açısından, yalnızca mevcut son kod korunur ve polimorfik protokol, kullanıcıların istediklerini genişletmelerine olanak tanıyacak şekilde açığa çıkarılır. API (analog $ .xxx).

Tabii ki, zamanlar değişti.İzleme görünümü artık $ ('# xxx'). Tıklayın (fn) değil, MVVM veriye dayalı görünüm modu, bu nedenle Chameleon iki yönlü bağlama gibi bir VM katmanı sağlandı.

Chameleon'un önceki MPV'sinden bahsetmiştim, bu yüzden Chameleon'un tüm evrim sürecini ayrıntılı olarak paylaşalım.

Doğum: Mini program ortamını çevirmeyi veya simüle etmeyi mi seçin?

Daha önce de belirtildiği gibi, 2017'de MPV adında bir projeyi tamamladık. İlk aşamanın amacı, kullanıcıların performansını etkilememek ve çerçeve ilkesine güvenmeden Web ve WeChat uygulamalarını çalıştırmak için bir dizi kod uygulamaktır.

O zamanlar karşılaşılan en büyük problem mini programlar hakkında bilgi eksikliğiydi (bugün endüstride bu kadar çok çözümden bahsetmiyorum bile) O zamanlar başvurulabilecek tek açık kaynak projesi WEPT idi.WEPT, WeChat mini programları için gerçek zamanlı bir geliştirme ortamıdır. Amaç, küçük programların geliştirilmesi için verimli, istikrarlı, dostane ve sınırsız bir çalışma ortamı sağlamaktır. Tasarım fikri, Web tarafında küçük program ortamının yürütülmesini taklit etmektir.

Bu nedenle, MPV'yi geliştirirken iki uygulama stratejisini değerlendirdik:

1. Web tarafında, WEPT gibi uygulama ortamıyla alay edin; tıpkı WeChat geliştirici aracı gibi, uygulama yürütme ortamı da simüle edilir.WAServie ve WAWebview tarafından sağlanan iki grup ortam kaynak kodu alt katman olarak kullanılır ve sayfada çalıştırmak için üç bağımsız çalışma ortamı açılır WeChat uygulamasının 3 Web Görünümü arasındaki bağlantı ilişkisini simüle etmek için iframe iletişimini kullanın.

2. Kodları tek tek çevirmek küçük programları destekler .. Dezavantajı, ele alınması gereken uç durumlar olabilir ve daha fazla potansiyel hata olacaktır.

Son olarak, WEPT kaynak kodunu ve WeChat geliştirici araçlarını okuduktan sonra, İlk uygulama stratejisini açıkça terk etti Küçük programları desteklemek için kod çevirme yolunu teker teker seçin, çünkü Web tarafında WeChat'in tüm işlevleriyle uyumlu ve boyutu çok büyük.

Üç aylık yoğun bir geliştirmeden sonra, MPV'nin ilk sürümü nihayet gerçekleştirildi:

Birkaç demo uyguladıktan sonra, taşıma planını uygulamaya başlayın:

MPV'nin Webapp üzerindeki nihai uygulama etkisi aşağıdaki gibidir:

Nihai uygulama etkisi oldukça iyidir ve% 90'dan fazla kod yeniden kullanımı gerçekten tamamlanmıştır ve genel geliştirme verimliliği ve test verimliliği önemli ölçüde iyileştirilmiştir.

Ancak takip uygulama sürecinde çok sayıda problemin olduğu tespit edilmiş ve proje ne kadar büyükse problemlerin o kadar öne çıktığı şu şekilde özetlenmiştir:

• Sürdürülebilirlik sorunları için, her uçta ortak kodlar ve farklı kodlar arasında ayrım yoktur. Projede sadece iş mantığı değil, aynı zamanda web ve uygulama ürün fonksiyonlarının farklılaşma mantığı ile karışmıştır. Örneğin, önceki örnekte, paylaşım işlevi Web tarafında (rehber paylaşımı) uygulanamaz, ancak küçük programlar uygulanabilir, bu da çeşitli ortamların tüm vücudu içeren ve ileri geri test etmek zorunda olan çeşitli farklılaştırılmış mantıkları yargıladığı anlamına gelir.
• Yön yanlış. MPV, kullanıcıların açıkça anlamasını zorlaştıran küçük program sözdizimi standardını (küçük programın yaşam döngüsü, API arayüzü vb.) Kullanır.
• Mevcut ekolojik bileşenleri her iki uçta doğrudan kullanamazsınız, yani belirli bir uçta mevcut açık kaynaklı bileşenlere erişmek için standart özelliklerin olmaması. Örneğin, Web tarafındaki pick.js bileşeni bir hızlı erişim belirtiminden yoksundur ve kullanıcıların ya onu yeniden geliştirmesi ya da şablondaki ortam değerlendirme yöntemini ve tanıtılacak js kodunu kullanması gerekir. Sonunda, aynı işlevin farklı uçlarının çağırma yöntemi, girdisi ve çıktısı tutarsızdır.
• İş projesi, MPV çerçevesine dayanır. Çerçeve, birleşik arayüzü genişleten WeChat uygulama arayüzüne (şablon, yaşam döngüsü ve arayüz) dayanır. Örneğin, WeChat Mini Programı wx.request'i güncellediğinde, iş projesi tarafı onu hemen kullanamaz ve çerçevenin güncellenmesini beklemesi gerekir.
• Klasör yapısı dağınık, çok sayıda son kod dosyası karışık ve tanımlama maliyeti yüksek.
• Vuex ve redux gibi verimli veri yönetimi yöntemlerini desteklemez
• Boyut birimi tek tip değil, piksel ve rpx tutarlı değil
• Etrafta çok fazla küçük fark var:
• Protokol tutarsız.Örneğin, web tarafında //:www.didiglobal.com/passenger/create kullanabilirsiniz ve küçük programlar için yalnızca https: //: www.didiglobal.com/passenger/create kullanabilirsiniz.
• Yeni bir sayfa açarken, bağlantılar tek tip değildir.Örneğin, tek bir geliştirme sayfası açarken, web tarafı //:www.didiglobal.com/passenger/create ve uygulama / page / create
• Sayfalar arasında geçiş yaparken parametreler birleştirilmez
• Hata ayıklama maliyetleri yüksektir ve kodu değiştirdikten sonra her iki ucun da test edilmesi gerekir
• Her iki uçtaki arayüz etkileri tutarsızdır ve temel yerleşik bileşenler tek tip değildir
• Mühendislik yapısı geriye dönüktür, örneğin, karaciğer yükü, veri taklidi, kaynak konumlandırma, proxy, çok terminalli birleşik önizleme desteklenmez
• Eksik arayüz tasarımı, yaşam döngüsü, bileşen katmanlama, yerel API tasarımı vb.
• Şablon DSL sözdizimi standartlaştırılmamıştır

Büyüme dönemi: sözde birleşmeden büyük birleşmeye

MPV uygulamasının birikmesiyle, belli bir derecede güven ve kesinlik vardır ve takip planı daha nettir. Nisan 2018'de, çapraz terminal projesinin ölçeğini daha da genişlettik ve gerçek bir çapraz N terminal çözümü yapmak istedik. Amaç, çeşitli terminalleri birleştirmek için standart bir MVVM mimari geliştirme modeli sağlamaktı. Bukalemun burada ortaya çıktı.

Chameleon gerçekten bir dizi kodun birden çok ucu çalıştırmasını istiyor. Özetle, çözülmesi gereken birkaç önemli sorun var:

• Son geliştirmenin tüm detaylarının bütünlüğünü tam olarak tamamlamak için, özellikle arayüz birliğinin yapılması gereken çok şey var.
• Önceki öğeyi tamamlama öncülüğünde farklılaştırılmış özelleştirme alanını düşünün
• Sürekli bakım yapılabilir

Hedeflenen ideal iş formu şudur:

Şeklin üst kısmı, geleneksel geliştirme yöntemidir, Chameleon modelinin alt kısmı, kullanıcı arayüzü oluşturma katmanını ve yerel arayüz yetenek katmanını özetler. İş kodunun bazı basit sayfaları, XEditor (h5Editor'un öncülü) düzenleme aracı tarafından üretilir ve mühendislerin diğer kısmı Chameleon'u kullanır Geliştirme yalnızca terminaller arası sorunları çözmekle kalmaz, aynı zamanda mühendislik geliştirme sürecinin verimliliğini, kalitesini, performansını ve istikrarını iyileştirerek mühendislerin anlamlı işe odaklanmalarına ve daha hızlı büyümelerine olanak tanır.

İlk Yerel işleme motoru seçim uygulama mimarisi, RN / Weex mimarisi

MPV'den Chameleon'a, dış dünyadan en belirgin değişiklik, çapraz terminalden (Web, uygulama) çapraz çoklu terminale (Web, uygulama, Android, iOS) yükseltmedir ve başlangıçta ilk terminal sürümünün oluşturma motoruyla karıştırılmıştır. Uygulama mimarisini veya RN / Weex mimarisini kullanın.

RN / Weex hakkında pek çok bilgi mevcuttur, ancak küçük programlar için değildir. İçerideki hikayeyi bilen bir arkadaşımın açıklamasına göre çok aradıktan ve paylaştıktan sonra belli bir anlayış kazandım.

İşte birkaç etkileyici nokta:

• Mini Program görüntü katmanı, Native ile iletişim kurmak için yerleşik bir JS çerçevesine sahip Webview kullanır ve gerçek iş kodu ayrı bir JS sanal makine konteyner örneğinde yürütülür.
• JS sanal makine konteyner kullanımı, iOS sistemi JavaScriptCore, Android sistemi QQ tarayıcısının X5 çekirdeğini kullanıyor
• Uygulamanın her TAG bileşeni tarafından yönlendirilen veriler, Web Bileşenleridir
• Açıktır ki, bazı yüksek performans gereksinimleri Web görünümüne eklenecek yerel kontrolleri (video, klavye vb.) Kullanır.
• Yerel kontrolün belirli konumu Nasıl Yerel olunur? Cevap, Web görünümüne yerleştirilmiş bir dizi küçük program çerçevesinin yerel katmanı bilgilendirmesidir.
• Yerel kontroller, dahili kaydırılabilir öğelerde (Kaydırma görünümü) normal kaydırmayı nasıl sağlayabilir? Cevap, CSS -webkit-over-scroll: touch olarak ayarlandığında iOS uygulamasının yerel UIScrollView olmasıdır. Native, bazı siyah teknolojiler aracılığıyla görünüm hiyerarşisinde UIScrollView'i bulabilir ve ardından yerel kontrolleri ekleyip işleyebilir; ancak Android doğrudan çizim yapamaz Bunu yap. Şimdi (Nisan itibariyle) yalnızca doğrudan Web görünümünün en dış katmanının kaydırma görünümünün üzerine yerleştirilir ve yerel kontrol konumu, Web görünümünde yerleşik bir dizi JS çerçevesi tarafından kontrol edilir.

Son analiz aşağıdaki gibidir:

Mini program çözümü çok basit görünse de, aslında pek çok detayın çok fazla parlatılması gerekiyor.Çözümün doğrulanmasından çevrimiçi olarak çalıştırılmasına ve yayınlanmasına kadar, yalnızca terminalde harcanan Ar-Ge insan gücü 20P * 6 aydır. WeChat mini program ekibi Amacımız terminaller arası hedefimizden farklı, bu kadar çok maliyete yatırım yapmaları değerli. Çapraz terminal için bu kadar yüksek bir maliyet yatırmamıza gerek yok.

Bu yüzden seçiyoruz Küçük program oluşturma çözümünü terk edin ve açık kaynaklı RN / Weex çözümünü kullanın .

İlk sürüm sonunda Weex kaynak kodu uygulamasını görmek için takım arkadaşları da dahil olmak üzere Weex'i kullandı.

Genel tasarımda, gelecekte daha yüksek ölçeklenebilirlik sağlamak için yalnızca Weex oluşturma işlevi ve dış paketleme arayüzü kullanılır.

Chameleon Yerel SDK

Yerel SDK için üç açıdan çalışma yaptık: yerel yetenek genişletme, performans ve kararlılık.

• Yerel yetenek genişletme: İster Webview ister React Native, Weex veya hatta Flutter olsun, yalnızca işleme yetenekleri (ve en temel yerel arayüzlerden bazılarını) ve işletme işlevlerini (WeChat'e paylaşmak gibi) tamamlamak için gereken daha fazla yerel ortam yetenekleri Android ve iOS gerektirir Yerel, kapsayıcıya genişler. UI arabirimiyle ilgili bileşenler olarak adlandırılan birleşik (oturum açma ve ödeme gibi UI bileşenleri) ve yalnızca yetenek çağrılarıyla ilgili (ağ, depolama, vb.) Birleşik olarak adlandırılan API'ler olmak üzere iki tür yerel yetenek vardır.
• Performans: Arayüz ekranı ve etkileşim zaman alan anahtar, 2 bloğa, kaynak yükleme süresine (kurulum paketindeki kodun paketlenmemiş kısmı), zaman alan yürütmeye bağlıdır
• Kararlılık: Esas olarak gri sürüm (risk kontrol edilebilir) ve çevrimiçi durdurma kaybına odaklanın. Asıl iş, hızlı bir şekilde H5'e indirilebilen kullanıcı gri düzeylerine göre yayınlamaktır.

Aşağıdakiler, performans yönündeki ilk ekran yükleme süresinin optimizasyon verileridir.SSR (Sunucu Tarafı İşleme) kullanan orijinal H5, halihazırda en hızlı Web ilk ekran teknolojisi çözümü olarak kabul edilmektedir (arka uç çoklu modülünün zaman alan BIGPIPE optimizasyonu dikkate alınmadan). 1,5 saniyenin altında tutun ve optimizasyondan sonra yaklaşık 0,5 saniyeye düşer.

Performans optimizasyonunda, yürütme hızı ile ilgili bir TODO planımız var. Aynı zamanda çapraz terminaldir.Flutter'ın Weex ve RN'den daha hızlı olmasının ana nedeni, ilkinin derlenmiş olması ve istemci makinenin çalıştırılmadan önce CPU tarafından zaten tanınabilmesidir; ikincisi yorumlanır, yani istemci çalışmadan önce. Dizeler aynı anda derlenir ve çalıştırılır JIT mümkün olduğunca optimize etmek için yapılsa da, boşluk hala büyüktür. Aslında, farklı CPU mimarileri altında makine kodundaki farkı düzelten bir ara kod vardır; elbette, öncül, geliştirme dilinin burada genişletilmeyen statik bir türe değiştirilmesidir.

Başlangıçta beş kez geliştirilen Web istemcisi, Alipay uygulaması, Kuaiapp, WeChat uygulaması ve Yerel yaklaşık 1,2 kez geliştirildi. En önemlisi, farklılaştırılmış polimorfik bileşenlerin ve çapraz terminal bileşenlerinin iş seviyesinin her iki ucunda birikmesiyle, takip 1.2 iş yükünün de 0.8 olacağıdır. 0.4'ün optimizasyonu temel olarak iki yönden gelir:

• 0.2, ortak çapraz terminal bileşenlerinin birikmesidir ve yeniden kullanım oranı yükselir
• 0.2, oturum açma işlevi gibi çeşitli işletme düzeylerinin farklılaştırılmış bir polimorfik bileşenidir. Web, Yerel ve Mini Programdaki uygulama ve etkileşim tutarsızdır. Şu anda, iş biçimi farklıdır ve tasarım < pasaport > Bileşenler de farklıdır ve yalnızca her iş kolu tarafından paketlenebilir.

Bir sonraki yol haritasını tanıtın.

Nihai hedefimiz, çeşitli terminalleri birleştirmek için standart bir MVVM mimarisi geliştirme modeli sağlamaktır.

Aşağıdaki belirli yol haritası aşağıdaki tabloda gösterilmektedir:

Bize katılma ve birlikte inşa etme ve depoya kendi kodlarını eklemeye yönelik ortak bir vizyonla öğrencileri karşılayın.

Proje adresi: https://github.com/didi/chameleon

Açık kaynak topluluğu OSC başlıkları, yabancı dil çevirisini, yazılım güncellemelerini, teknik blogları ve diğer yüksek kaliteli içeriği kapsayan en son yüksek kaliteli teknik makaleleri günlük olarak yayınlayın. Açık kaynak topluluğundaki OSC başlıklarını takip edin, en son teknik bilgileri günlük olarak alın ve orijinal makaleyi okumak için "Daha Fazla Bilgi" yi tıklayın.

Yazılım GüncellemesiDaha fazla platformu destekleyen Öğrenmek istiyorum kişisel bilgi yönetimi aracı 6.0.5 yayınlandı

Teknoloji Listesi 13 ana araç içi HUD'nin envanteri, özerklik ve lüks arasındaki farkın ayrıntıları nelerdir?

Kablosuz şarj etmeye devam etmek ister misiniz? Resmi olarak bir artı 6 gerçek kamera fotoğrafı ortaya çıktı: metal orta çerçeve + cam gövde + patlama

Yatırım · İstatistikler Nisan NEEQ + Hong Kong hisse senetleri iniyor, borsada işlem gören şirketlerin genel performansı hızla artıyor

Adam sarhoş olduktan sonra otobüsü parçaladı ve soruşturma için polis tarafından götürüldü ve hastaneye kaldırıldı ve öldü.

Hint dininde sığır eti veya domuz eti yemiyorlar, peki ne tür et yiyorlar?

Önümüzdeki altı ay içinde güneyde dört yağmur mevsimi olacak mı? Çin Meteoroloji İdaresi: Yağmur Tanrısı her zaman gidecek

Sekiz nesil Core + 144Hz oyun ekranı Thor'un yeni 911 siyah hayalet oyun dizüstü bilgisayarı incelemesi

Yeni ASUS Flying Fortress FX80 saldırıları, Jingdong rezervasyonları 5999 yuan'dan başlıyor

Yatırım istatistikleri: Nisan ayında fon artırımı yavaş devam ediyor, VC yatırım miktarı yıllık yeni rakamlara ulaştı

Thor Li Yanbing: Thor oyun kitabı iki ateş ve hafiflik çizgisi boyunca aynı anda ilerleyecek

WeChat'in bu temel işlevleri durdurulmalıdır, aksi takdirde gizliliğiniz yabancılara maruz kalacaktır!