Kotlin riskli, RxJava güncel değil ve Android yerel geliştirmenin statükosu
Nihayet belirli bir çerçeveyi veya aracı öğrendiğinizde ve onu yararlı bulduğunuzda, eski hale gelebilir.
Yazar | Vasiliy Zukanov, çeviri yetkisi
Çevirmen | Luo Zhaocheng, Android Geliştiricisi; Sorumlu Editör | Tang Xiaoyin
Resmi mühürleyin | CSDN ödendi indir Doğu IC'den
Üretildi | CSDN ( İD: CSDNhaberler)
Çoğu Android geliştiricisi bana sık sık soruyor, iyi bir Android mühendisi olmak için ne öğrenmeliyim? Bu problem için açıklamaları biraz farklıdır. Ancak genel olarak mükemmel bir Android mühendisi olmak için hepimizin bir dizi beceri öğrenmesi gerekiyor.
Android yerel geliştirme ekosistemi çok hızlı değişiyor. En azından son beş yılda Android'de birçok değişiklik yaşadım ve bunlara katılmak için çok zaman harcadım. Geçtiğimiz birkaç yıl içinde Google, her iki ila üç yılda bir Android yerel geliştirme için resmi yönergeler olarak yeni bir kitaplık ve çerçeve seti başlatacak. İyi veya kötü olanı bulmayı umarak, son birkaç yıldaki değişiklikleri gözden geçirmek için çok zaman harcadım. Benim gibi pek çok Android geliştiricisi olduğuna inanıyorum.
Geçtiğimiz yıl çok sayıda içerik eklendi, atıldı veya silindi, belgeler değiştirildi, yeni resmi yönergeler getirildi vb. Bu konulara Android yerel geliştirme ekosisteminin standartlarına göre baksam bile, yaşananlar çılgınca. Bunları düşünmeye başladığımda artık zihnimde eksiksiz ve detaylı bir Android geliştirme ortamı tarif edemiyordum.
Bu nedenle, bu makaleyi yazmadan önce bu içerikleri düzenlemek için biraz zaman ayırmaya karar verdim. Bu yazıda yapacağım Android yerel geliştirme ekosisteminde neler olduğunu özetlemeye çalışın ve yerel geliştirmenin gelecekteki yönü hakkında bazı tahminlerde bulunun. Düşüncelerimi anlatmak için farklı bölümlere ayıracağım Bu içerikler için belirli bir sıra yok ama en tartışmalı içerikleri yazının sonuna koyacağım.
Umarım bu makalem size biraz ilham ve yardımcı olabilir, ancak bu makalenin tüm içeriği içermeyebileceğini, birçok önemli noktayı gözden kaçırabileceğini ve bu makalenin içeriğinde beni de içerebilir. Bazı kişisel önyargılar.
AndroidX
Google'ın bir buçuk yıl önce resmi olarak AndroidX'in bir önizleme sürümünü yayınladığını söylemek biraz çılgınca. Ve bir yıl önce, AndroidX kitaplığı zaten çok kararlıydı.Aynı zamanda Google, eski kitaplığı artık desteklemeyeceğini ve geliştirmeyeceğini resmi olarak duyurdu. (Bu cümleyi yazarken StackOverflow'da sorduğum bir soruyu hatırladım: Neden yeni API'yi SDK yerine Support kütüphanesine koyuyorsunuz?)
AndroidX kitaplığını tanımlamak için "kararlı" ifadesini kullanmak ironik. Artık AndroidX ile ilgili herhangi bir şey kararsız. Google, ad alanı olarak androidx'i kullanarak AndroidX altında yeni kitaplıklar ve çerçeveler eklemeye devam ediyor. Birçok "eski" API (şu anda bir yıldan daha kısa bir süre önce) çok hızlı bir şekilde gelişiyor.
Şimdiye kadar iki uygulamayı AndroidX'e taşıdım. Her şey yolunda gitti, bu sürecin bana ne kadar "sürpriz" getirdiğini hatırlayamıyorum. Google ayrıca bir araç sağlar, Jetifier, çok kullanışlı bir araç olan eşdeğer AndroidX paketine güvenmek için destek kitaplığına bağlı kitaplığı taşıyabilir. Ancak, küçük bir proje bile "tek tıklamayla geçiş" sağlayamaz.
Ben de AndroidX'e geçiş yapmayan (proje AndroidX'e geçmeyi planlamayan) bir projeye katıldım ve şu anda bir sorun yok, bu nedenle AndroidX'i taşımamak da bazı durumlarda uygulanabilir bir çözüm.
Neticede, Yeni Android projesinde, Önermek Doğrudan AndroidX'i kullanın. Ve eski projeler için, plana AndroidX'e geçişi de dahil etmenizi tavsiye ederim. , Yine de artık AndroidX'i taşıdıktan sonra herhangi bir avantaj göremiyorsunuz. Her durumda, AndroidX'i belirli bir zamanda taşımanız muhtemeldir, bu nedenle 6 ay sonra yeni bir AndroidX kitaplığı kullanmanız gerektiğinde acilen değil, kendi hızınızda geçiş yapmanız daha iyidir. göç.
Jetpack
AndroidX tartışıldıktan sonra Jetpack'ten bahsedilmelidir. Benim izlenimime göre, Jetpack başlangıçta "mimari bileşenler" için bir şemsiye olarak piyasaya sürüldü. Ancak daha sonra, AndroidX ile ilgili neredeyse tüm API'ler tanıtıldı. Şimdi baktığımızda, Pazarlama ve Halkla İlişkiler (pazarlama ve halkla ilişkiler) dışında AndroidX ile arasında herhangi bir fark göremiyoruz.
Jetpack ana sayfasına baktığınızda, bu sayfanın bir teknik dokümantasyon sayfası olmadığını göreceksiniz. Bu daha çok erken bir SaaS sayfası gibidir.
Örneğe bakın, geliştirici "övüyor":
Geliştirici övgü
Veya "güvenilen uygulamalar" listesi:
Güven uygulaması
Bunlar piyasa PR düzeyinde daha popüler Dikkat , Jetpack 2020'de bağımsız bir halka arz için başvurursa şaşırmam.
Ancak, gerçekten, API fikrini kendi ekosistemimdeki geliştiricilere "satmaya" çalışırken, bazı sorunlar olduğunu düşünüyorum, örneğin, kimin görmek isteyeceği aramak İlk çıkan, ViewModel reklamı mıydı?
Android ViewModel
Sonuç olarak, Jetpack yalnızca AndroidX kitaplığının bir toplamıdır, bu nedenle daha önce yazılan AndroidX içeriği Jetpack için de büyük ölçüde geçerlidir. Aşağıdaki içerikte, bu API'lerden bazılarını ayrı ayrı ele alacağım.
Arka plan işi
Android uygulaması ön planda mantık yürütmediğinde, arka planda çalışmayı gerçekleştirmenin birçok yoluna sahip olabilirsiniz, bu aynı zamanda Android dinamiklerinin kullanım örneklerinden biridir. Doze, SyncAdapter, CGMNetworkManager, FirebaseJobDispatcher, JobScheuler ve en son WorkManager'ı tanıtmazsanız, elde etmek için normal başlangıç hizmetini (bağlantısız hizmet) kullanabilirsiniz. Bunların hepsi Google tarafından sağlanan API'ler ve bunları kullanmanın tüm yollarını söyleyebilirim. Elbette, Android-Job gibi kullanılabilecek bazı üçüncü taraf kitaplıkları vardır.
Ancak Google kısa süre önce WorkManager çevresinde arka plan görev planlamasını birleştireceklerini duyurdu. Kulağa harika geliyor, artık çok fazla arka plan planlama bilgisi öğrenmek zorunda değilim, ama nedenini bilmiyorum, bu cümleyi daha önce duymuş gibiyim ...
WorkManager'ı gelecekte tek tip olarak kullanıp kullanmayacağımızdan bağımsız olarak, WorkManager'ın hala güvenilirlik gibi bazı sorunları vardır. Nedenini bu makalede açıklamak istemiyorum, ancak uygulamanızda arka plan işlerini uygulamak için WorkManager'ı kullanmak istiyorsanız dontkillmy'yi okumalısınız. uygulama .com Her şey açık ve kapalı Dikkat İşte WorkManager ile ilgili Google sorunlarının bir listesi.
Android'in arka plan işleri, parçalanma ve diğer nedenlerden dolayı dağınık ve aynı zamanda çok güvenilmez.
Geçmişte, her zaman verileri ve diğer arka plan işleme türlerini mümkün olduğunca senkronize etmeyi savundum. SyncAdapter'ın son hayranı olabilirim. Bugün güvenilirlik konusuna bakıldığında, ben Önermek , Mümkün olduğunca arka planda çalışan işlerden kaçının. Patronunuz bu özelliği kullanmakta ısrar ederse, lütfen onlara yukarıdaki bağlantıyı gönderin ve arka plandaki işin başarılması için yüzlerce saatlik çalışma gerektirebileceğini ve bundan daha fazla soruna neden olacağını söyleyin. Faydaları çoktur.
Çoğu durumda, arka plan işlemlerine ihtiyaç kaçınılmazdır. Ancak çoğu durumda kullanamazsınız. Bazen kullanıcılara biraz rahatsızlık verse de, bu şimdiye kadarki en iyi çözüm olabilir.
veri tabanı
SQLite ORM'lerle ilgili içerikte şaşırtıcı bir şey yok - Oda her şeyi yönetiyor. Oda, 2.2.0'dan başlayarak artımlı açıklama analizi için destek ekler. Ancak, uygulamanızın mimarisinin kullandığınız ORM çerçevesini önemsememesi gerektiğini lütfen unutmayın. Odadan bahsetmişken, "Mimari bileşen" de teknik bir rol değil, sadece bir pazarlama terimidir.
Android ORM çerçevesinde, SQLDelight esas olarak Room ile rekabet etmektedir. Bu, Room'dan çok daha eski bir kütüphane. Ama bildiğim kadarıyla, Geçtiğimiz yıl neredeyse tamamen yeniden yazıldı. Ancak SQLDelight'ın yeni sürümü yalnızca Kotlin içindir. Öte yandan SQLDelight, Kotlin Multiplatform'u da destekliyor, bu nedenle Kotlin kullanımı arttıkça SQLDelight'ın benimsenme oranının artmasını bekliyorum.
Bu arada, AndroidX ad alanı altında, SQLite'ın bir ayna görüntüsü de var. Bunun ne kadar yararlı olacağını bilmiyorum, ancak SQLite'ı doğrudan uygulamanızda kullanırsanız, bununla ilgili derinlemesine bir çalışma da yapabilirsiniz.
Ayrıca Realm, Parse, Firebase, ObjectBox vb. İlişkisel olmayan veritabanlarını da unutmamalıyız (bazıları çekirdekte SQLite kullanılarak uygulanmaktadır) Doğru hatırlıyorsam bu ilişkisel olmayan veritabanları arasında büyük Çoğu (veya hatta tümü) otomatik veri senkronizasyonu işlevine sahiptir. Daha önce bir süre çok popülerdi. Ama şimdi, bildiğim kadarıyla artık popüler değil. Yani kısa vadede devam edeceğim Dikkat İlişkisel olmayan veritabanı.
Geçen yıl, bir Parse servisine yerleştirilmiş çok karmaşık bir uygulama yazdım. Bu Uygulama Tam çevrimdışı destek, sunucu yerelleştirme, kullanıcı tanımlı sistem ve dil ayarları, karmaşık multimedya sistemi ve diğer işlevlere sahiptir. Android tarafında Parse'ın SDK'sını kullandım. Bazı küçük WTF'ler dışında, diğer deneyimler harika. Şirketinizde çok sayıda arka uç geliştiricisi varsa veya çok sayıda sunucu tarafı mantığı uygulamanız gerekiyorsa, bu en iyi çözüm olmayabilir. Ancak yalnızca basit CRUD işlemlerini gerçekleştirmesi gereken girişimler için bu iyi bir seçim olabilir.
Bir uyarı: Hizmet olarak veritabanı çözümü (Firebase gibi) kullanmayı planlıyorsanız, lütfen şunları yaptığınızdan emin olun: Dikkat Uzun süreli kullanımın maliyeti ve etkisi.
Harici depolama
Android harici depolamada "ilginç" bir değişiklik var.
Eğer gelişiyorsan Uygulama O sırada Hedef API 29 ve üzeri olarak ayarlandı. SD kart dosyalarını elde etmenin önceki yöntemleri şu anda kullanılamıyor ve istisna istenmeyecek. Şimdi, daha ayrıntılı dosya erişimi için Android depolama erişim çerçevesini kullanmanız gerekir. Ne yazık ki, Android depolama erişim çerçevesinin çalışma prensibi önceki okuma yönteminden tamamen farklıdır.Yeni dosya erişimi ve okumayı uygulamak için kodu çok fazla yeniden düzenlemeniz gerekebilir.
Google, başlangıçta Android 10'daki tüm uygulamalara dosya erişimini kısıtlamayı ve dosya erişimi için Android depolama erişim çerçevesinin kullanımını teşvik etmeyi umuyordu. Ancak bu değişiklik toplulukta güçlü protestolara neden olduğu için Google bu özelliğin lansmanını ertelemeye karar verdi. Bu nedenle, uygulamanız Target API 29 ve üzerinde olsa bile, "Legacy" modunda dosyaları okuyacak şekilde ayarlayabilirsiniz. Ancak, Android'in bir sonraki sürümünde, ne kadar Hedef API ayarladığınız önemli değil, uygulamanın yeni kapsam erişim modunu kullanması kısıtlanabilir.
Şimdiye kadar, uygulamamın dosya erişim yöntemini güncellemedim. Bununla birlikte, İnternetteki tartışmaya göre, yeni dosya erişim yöntemlerini uygulamak çok zor bir görevdir. Uygulamanız "Eski" modda olmasına rağmen, bir anormallik yok, ancak ben Önermek Kontrol edilemeyen şeylerin olmasını önlemek için bundan sonra kodu yeniden düzenlemeye ve test etmeye başlamanız iyi olur.
Paylaşılan Tercihler
Birkaç hafta önce, AndroidX ailesi yeni bir kitaplık ekledi. Bu kaydetme mesajı şöyle:
Yeni kitaplık, Paylaşılan Tercihlerin yerine kullanılmaktadır. Yeni kitaplığın adı henüz belirlenmemiştir. Bu gönderi yalnızca inceleme ve tasarım belgeleri içindir (lütfen tasarım belgeleri için kendiniz başvurun).
Şimdi endişelenecek bir şey yok. fakat, Uzun vadede, Paylaşılan Tercihler kullanımdan kaldırılacak ve benzer işlevleri elde etmek için yeni bir kitaplıkla değiştirilecektir.
SharedPreferences'ın aksine, bu yeni kitaplık varsayılan olarak eşzamansız yöntemler kullanır. Başka bir deyişle, bir değer almanız gerekiyorsa, bir geri arama uygulamanız gerekir ve değer bu geri arama yoluyla elde edilebilir.
Bu eşzamansız geri arama prensibiyle ilgileniyorsanız, bu yanıtı StackOverflow'da kontrol edebilirsiniz. Reddit kullanıcısı Tolriq, Uygulama Aylık 10.000 aktif kullanıcıdan birini etkileyen bir SharedPreferences hatasıyla karşılaştım. Genel uygulamalar için, bu sorunun belirgin bir etkisi yoktur. Bununla birlikte, yüksek güvenilirlik gerektiren bazı uygulamalarda çok güvenilmezdir. Örneğin bir Android arabada ise uygulamanın tepkisizliği ve çarpması sürücünün dikkatinin dağılmasına ve bu da trafik kazasına neden olabilir.
Bağımlılık ekleme
Bağımlılık enjeksiyonu alanında en büyük haber Dagger-Android'in kullanımdan kaldırılmasıdır.Vurgulanması gereken iki nokta var Öncelikle bahsettiğim kullanımdan kaldırma resmi bir açıklama olmadığı için resmi bir kullanımdan kaldırma değil. İkinci olarak, Dagger-Android, Dagger 2 çerçevesinin tamamına değil, yalnızca nispeten yeni kısmına atıfta bulunur. Ayrıntılar için lütfen diğer makaleme bakın.
Android alanında başka bağımlılık enjeksiyon çerçeveleri var, ancak bunların Dagger'dan daha iyi olacağını düşünmüyorum. Koin'in iyi bir bağımlılık enjeksiyon çerçevesi olduğunu belirtmekte fayda var, ancak yine de çok fazla eğilime neden olacağını düşünmüyorum. Bu iki nedenden dolayı benimsenmiştir: Birincisi, Dagger'dan çok daha iyi belgelere sahip olması, bu da öğrenme maliyetini düşürmesidir. İkincisi, Kotlin temel alınarak yazılmış olmasıdır, Kotlin'in popülaritesi nedeniyle, aynı zamanda Dikkat . Şimdiye kadar Kotlinin çılgınlığı neredeyse tamamen geçti, bu yüzden Koin'in Dikkat Yavaş yavaş azalacak.
Bu çerçeveler nasıl gelişirse gelişsin, manuel bağımlılık enjeksiyonunun gelişimi yavaş olacaktır.
Google şunu iddia ediyor: Uygulama büyüdükçe, manuel bağımlılık ekleme maliyeti de katlanarak artacak. Ama sanmıyorum, Google'ın ne "indeks" in anlamını anladığını ne de aslında hiçbir şeyi "ölçmediğini" düşünüyorum. Bu ifadenin içeriği yanlış ve umarım Google artık topluluğu bu şekilde yanıltmayacaktır.
Aslında, bu tür manuel bağımlılık enjeksiyonu arka uçta daha yaygındır (özellikle mikro hizmetlerde, her hizmette enjeksiyon çerçevesine bir bağımlılık eklemek istemezsiniz) ve normal şekilde çalışabilir. Arka uçta genellikle yansıma kullanılır, bu nedenle arka uç bağımlılık enjeksiyon çerçevesinin derleme zamanı kodunu ayrıştırmasına gerek yoktur.
Android'de çözüm arka uçtan biraz farklıdır. Yansıma şemasının bağımlılık ekleme çerçevesini neredeyse hiç kullanmıyoruz, bu nedenle geriye yalnızca Dagger kalıyor. Aslında, yansıtma performansı etkileyebilse de çoğu projede kullanılabilir. Demek istemiyorum Önermek Yansıma şemasının bağımlılık enjeksiyon çerçevesini kullanıyorsunuz.Bu seçim siyah beyaz değil, gereksinimlerinize göre seçim yapmanız gerekiyor.
Her durumda, Android alanında, Dagger, bağımlılık enjeksiyon çerçevesinin mevcut standardıdır ve hepimiz bunu kullanıyoruz. Google, Dagger'ı tanıtımda kullanmanın maliyetini göstermek için güzel yeşil grafikler kullansa da, Dagger'ı kullanmanın maliyeti aslında zamanla hızla artacaktır. Daha fazla kod, derlemek ve oluşturmak daha fazla zaman alır; ne kadar çok geliştiriciniz olursa, kod o kadar çok derlenir. Tabii ki, tüm geliştiricilerin, başlı başına büyük bir maliyet olan Dagger'ı nasıl kullanacaklarını öğrenmeleri gerekir.
Diğer bir deyişle, Dagger, projede yazılan kodu azaltabilse de, yeni gelenleri eğitmek ve derlemeye daha fazla zaman harcamak daha fazla zaman alır. Bu nedenle, büyük projeler için Dagger kullanmak daha fazla zaman alıcı olacaktır.
Büyük ölçekli bir projede, zaman alan derleme yavaş yavaş bir üretkenlik darboğazı haline gelecektir. Elbette, Dagger ayrıca derleme süresini optimize etmenize yardımcı olacak pek çok mükemmel yeni özellik de sağlar, ancak öncül, bu araçları nasıl kullanacağınızı bilmeniz gerektiğidir. Bunu okuduktan sonra, manuel bağımlılık enjeksiyonu ile çok ilgileneceğinizi düşünüyorum.
Bağlanma verileri
Bir Android geliştiricisi olarak, mizanpaj yazarken genellikle findViewById yöntemini çağıracağınızı bilirsiniz. DataBinding, bu şablon yönteminin yerini almak için doğdu. Dürüst olmak gerekirse, findViewById'i kullanırken herhangi bir sorunla karşılaşmadım, ondan kurtulmayı umut etsem de, DataBinding'i kullanmanın daha makul bir yol olduğunu düşünmüyorum. İyi haberler var Yakında, DataBinding kullanmadan findViewById'den kurtulmak için ViewBinding'i kullanabileceğiz.
Dürüst olmak gerekirse DataBinding'e inanmıyorum. Bu çözüm, çözmek istediği sorun için çok karmaşık. DataBinding'i kullanırken, kod mantığını XML düzenine koymanız gerekir ki bu kulağa harika geliyor, ancak deneyimli geliştiriciler bunu yapmayacak Bu yaklaşım, Veri Bağlamasının başka bir dezavantajıdır.
Kasım 2016 gibi erken bir tarihte, Google hâlâ DataBinding'i hipotezi kullanıyordu. StackOverflow'un cevabında şu tahminleri yaptım:
Büyük bir güvenle tahmin edebilirim: DataBinding bir endüstri standardı olmayacak. DataBinding kısa vadeli faydalar sağlayabilir, ancak uzun vadede kodu sürdürülemez hale getirecektir. Veri bağlama uzun bir süre kullanıldığında, eksiklikleri ortaya çıkacak ve gelecekte kesinlikle terk edilecektir.
DataBinding'i kullanan projeleri saymadım, ancak bunun bir endüstri standardı haline gelmediği açık. Bunu kendi projelerimde hiç kullanmadım ve diğer geliştiricilerin onu kullandığını nadiren görüyorum. Tahminime göre, ViewBinding olgunlaştığında ve yaygın olarak benimsendiğinde, DataBinding "geleneksel" bir çerçeve olarak kullanılacak ve geniş çapta alıntı yapılacak.
Devlet koruması
ViewModel mimari bileşeninin kullanıma sunulmasından bu yana, Android uygulamalarında konfigürasyon değiştiğinde, durumu kaydetme ve geri yükleme mantığı kimsenin yönetemeyeceği bir karmaşa haline geldi. Bunu söylemek biraz fazla olsa da, bence en nazik ifade tarzım bu.
Gabor Varadi (Zhuinden olarak da bilinir) Reddit forumunda ViewModel'in tanıtılmasının neden olduğu sorunları anlattı, tekrar yazmaya ihtiyacım yok. Yine, onRetainCustomNonConfigurationInstance kullanılması tavsiye edilmez, ViewModel kullanılması önerilir.
Gönderinin sonunda Gabor bazı tahminlerde bulundu:
biliyor musun? Parça durumu kaydetme yöntemi kullanımdan kaldırıldı.
Kanımca, Parça durumu korumasını atmak çok iyi bir fikirdir. İyi bilinen , Fragment'ın onAttach ve onDetach yöntemleri durum korumayı desteklemek içindir, şimdi durum koruma yöntemi terk edilmiştir, daha sonra bu iki yöntem de atılabilir ve bu, Fragment'ın yaşam döngüsünü basitleştirebilir. bulundum Önermek Fragments durumu kaydedilmez ve onAttach ve onDetach yöntemleri yok sayılır, bu da daha önce yazdığım Framgent yaşam döngüsü yöntemiyle tutarlıdır.
Fragment'in durum korumasının atılması gerektiğini belirtmek için birçok neden olsa da, onRetainCustomNonConfigurationInstance'de atılması imkansız. Ben öyle söylemedim, ama Jake Wharton. Gabor'un yukarıdaki gönderisinde yanıtı en çok beğeni aldı. Jake'in söylediklerine katılmasam da, kendimi ikna etmek için daha iyi bir neden bulamıyorum. Bu yöntem, ViewModel'in arkasındaki ilke ile tamamen aynıdır ve onu atmak için hiçbir neden yoktur.
Peki bu terk edilmiş yöntemleri nasıl ele almalıyız? Bu yöntemlerin teknik çözümleri ve avantajları ne olursa olsun, Google tüm Andorid uygulamalarını ViewModel'e geçmeye zorlar. Bu çözümler ViewModel'in kendisinden daha iyi olsa bile, pes etmeye isteklidirler. Biraz komplo teorisine benziyor.
Yapılandırılmamış durumu kaydetmekten gerçekten hoşlanmıyorum ve atmanın benim üzerimde bir etkisi yok, çünkü onu hiç kullanmadım. Aslında çoğu uygulama bu yöntemlere ihtiyaç duymaz ve elbette ViewModel'in de bunlara ihtiyacı yoktur. Durum değişikliklerini halletmemizin tek yolu onSaveInstanceState (Bundle) yöntemidir. Bu yöntem çok basit ve nettir ve aynı anda kaydetme ve geri yükleme mantığını kaldırabilir. Dolayısıyla devlet bu şekilde kurtarılabildiği sürece, bu yöntemi kullanan tek kişinin ben olmadığına inanıyorum. Google, ViewModel üzerinde pek çok pazarlama promosyonu gerçekleştirmiş olsa da, birçok deneyimli geliştirici için ViewModel hala çok karmaşıktır. Durum depolamasını idare etmek için daha basit ve daha etkili bir yolumuz var.
Google'ın gizli nedenleri varsa ve tüm projeleri ViewModel kullanmaya zorlamak istiyorsa, onSaveInstanceState (Bundle) yöntemini de kullanımdan kaldıracaktır. Kulağa biraz tuhaf geliyor, gelecekte böyle gelişirse temel teorimin doğru olduğu anlamına gelir.
Android'in bellek yönetim mekanizması göz önüne alındığında, Google'ın kararlı bir çözüm olmadan onSaveInstanceState'i (Bundle) terk etmesi imkansızdır. "Neyse ki", ilgili işi tamamlamak için ViewModel'i zaten kullanabiliriz.
Sanırım bir veya iki yıl içinde teorimin doğru olup olmadığını görebilirim.
Sonuç olarak, bu bölümün başında da belirtildiği gibi, Android durumunun korunması bir karmaşa haline gelecektir. ViewModel mimarisinin zararlı bileşenleri hakkında iki yıldan daha uzun bir süre önce bir makale yazdığımda, ViewModel'in kaydetme ve geri yükleme durumu üzerinde biraz etkisi olacağını tahmin etmiştim. Tahmin ettiğim şey bir gerçek oldu ve durum bir zamanlar tahmin ettiğimden daha kötü.
Eşzamanlı
Android eşzamanlı programlamada, önemli bir API AsyncTask'tır, ancak artık kullanımdan kaldırılmıştır. Daha önce ayrıntılı bir makale yazdım ve analiz ettim, bu yüzden burada tekrar etmeyeceğim.
Aşağıda söylemek istediğim içerik birçok okuyucuyu üzebilir, ancak lütfen benden "nefret etmeyin".
RxJava, Andorid'de yaygın olarak kullanılan çok iş parçacıklı bir çerçevedir. Ama şimdi yavaş yavaş tarih sahnesinden çekilecektir. StackOverflow'un trend grafiğinden görülebilir:
RxJava kullanım eğilimleri
Birçok geliştirici bu ifadeyi sorguladı ve bu verilerin temsili olmadığını ve grafikte ne olduğunu açıklamak için başka nedenler bulabileceğimizi reddettiler. Söyledikleri doğru olabilir ve ben de bir veri bilimcisi değilim. Ancak RxJava ve AsnycTask'ın aynı eğime sahip olduğunu şekilden görebiliyoruz.
RxJava'yı nasıl kullanacağınızı öğrenmek için zamanınız yoksa ve projenizde RxJava'yı kullanmadıysanız, ben Önermek Projelerinizde RxJava kullanmamalısınız. Aslında, RxJava'yı asla tavsiye etmedim ve şimdi görüşümü destekleyen veriler var.
Projenizde RxJava kullanırsanız paniğe kapılmanıza gerek kalmaz ve projenizi acilen yeniden düzenlemenize gerek yoktur. Projenizde tek sizseniz veya tüm proje ekibi değişmeyecekse, sadece projenin statükosunu koruyun. Ama hatırlaman gerek Gelecekte, RxJava geliştirme deneyimine sahip kişileri işe almak gittikçe daha zor olacak ve yeni işe alınanların RxJava'yı kullanmayı öğrenmeleri gerekebilir. RxJava'yı yoğun bir şekilde kullanan projeler, tıpkı bugün hala AsyncTask ve Loader kullanan projeler gibi gelecekte de "havalı" olarak değerlendirilmez.
Birçok RxJava geliştiricisinin RxJava'nın sıkı hayranları olduğunu biliyorum.RxJava'yı öğrenmek için birkaç hafta harcadılar ve takım arkadaşlarını projelerinde RxJava'yı kullanmaya ikna etmek için büyük çaba harcadılar. Şimdi RxJava'nın modası geçmiş olduğunu söylemek için buradayım. Sadece bunun benim kişisel görüşüm olmadığını söyleyebilirim, sadece mevcut durumu analiz ediyorum ve gördüklerime dayanarak tahminler yapıyorum. Ben de yanılıyor olabilirim. İki ordu savaşıyor ve onları kesmeyin, lütfen bana "saldırmayın".
Kotlin'de, eşzamanlılık birden çok eşzamanlılık elde etmek için kullanılır. Son zamanlarda, coroutines kullanarak bazı basit kullanım durumları uyguladım.Karmaşık, kararsız ve hatta bazı hatalar buldum.
Herkes, eşgüdümlerin eşzamanlılığın karmaşıklığını azaltabileceğini ve eşzamanlılığı kullanmayı kolaylaştırabileceğini söylüyor. Bu cümleye asla inanmıyorum çünkü eşzamanlılığın temelde karmaşık olduğunu biliyorum. Bazı test senaryolarını yazdıktan sonra, deneyimlerime göre, size güvenle söyleyebilirim ki, eşyalar basitleştirilemez. Koroutinin karmaşıklığı artıracağını düşünüyorum, ben Önermek Onları dikkatli kullanıyorsun.
Kotlin'de, çoklu iş parçacığını işlemek için varsayılan yol olarak eş yordamlar kullanılacaktır.Kotlin'de geliştirmeye başladıysanız, eşgüdümlerin nasıl kullanılacağını öğrenmek için bir dakikanızı ayırmalısınız.
Bildiğim kadarıyla, coroutine'lere dayanan ve akış operatörleri ekleyen bir Flow çerçevesi de var. Birkaç ay önce stabildi. Yani şimdi değerlendirecek bir şey yok.
Kotlin
Şimdi Kotlin'in Android alanındaki statükosunu tartışalım. Kişisel deneyimlerime göre, bu çok hassas Ne kadar adil ve objektif söylersem söyleyeyim, bazı hayranlar söylediklerimin "bok" olduğunu söyleyecekler. Ancak profesyonel bir bakış açısıyla, Kotlin konusu atlanamaz, bu yüzden bu içeriklerin sadece kişisel görüşlerim olduğunu ve sadece referans amaçlı olduğunu vurgulamak istiyorum.
Android geliştirmede Kotlin kullanarak, Çok Derleme sürenizi artırın.
Başka bir yazımda Kotlin'i kullandıktan sonra derleme süresinin arttığını saydım. Sonuç olarak, tam derleme durumunda, zaman tüketimini yaklaşık% 18, artımlı derleme durumunda ise, zaman tüketimini yaklaşık% 8 artıracaktır.
Uber ve JetBrains, Kotlin'in proje derleme süresine etkisi ile ilgili raporlarını ortaklaşa yayınladılar.Makalede gösterilen sonuçlar oldukça kötümser. IDE'de not işlemcilerini etkinleştirmezseniz ve Kotlin projesini başlatmazsanız derleme ve derleme süresinin yaklaşık dört kat artacağını, not işlemcileri etkinleştirilirse derleme ve derleme süresinin de% 50 ~% 100 artacağını söylediler.
Uber'in sonuçları, OkHttp Kotlin'e geçtikten sonra elde edilen sonuçlarla tutarlıdır ve her ikisi de derleme süresini 4 kat arttırmıştır.
Merak etmeyin, bu sonuç şaşırtıcı olsa da sizin suçunuz değil, birçok kişi Kotlin'i sizin gibi kullanıyor. Bu sorun, çok önemli olmasına rağmen, Dikkat . Sanırım Google da bu sorunu çözmeye çalışıyor. Bir keresinde alakalı Google geliştiricilerine sordum ve derinlemesine alışverişler yaptım. Bu soruya verdikleri yanıt şuydu: "Bu çok zor bir soru, yapmamayı tercih ederim."
Kotlin, derleme süresinin artırılmasına ek olarak, geçen haftaya kadar artımlı açıklama işlemeyi desteklemiyordu, Java ise 10 ay önce destekledi.
İki yıl önce sizi uyarmak için bir makale yazdım, Kotlin'i çok erken kullanmak çok riskli . Yorumlardan da görebileceğiniz gibi uzun süredir "Kara Kotlin hayranıyım".
Gerçek çalışmanızda, yukarıdaki verilerle karşılaştırıldığında Kotlin'in sorunlarının bundan çok daha fazlası olduğunu göreceksiniz. Büyük bir Android projesinde, derlemek ve inşa etmek için gereken süre projenin gelişimini ciddi şekilde engelleyecektir. Bugün bile Kotlin iki yıldır resmi olarak kullanılıyor, Kotlin derleme verimliliği hala Java'dan çok daha kötü. Kotlin'in size getireceği avantaj ne olursa olsun, derleme süresi problemi onu kullanmamanıza neden olabilir.
Her halükarda Google, tüm Android geliştirme ekosisteminde ilk tercih edilen dil olarak Kotlin'i tanıttı.Şimdi Kotlin giderek daha fazla kullanılıyor ve takip etmemiz gerekiyor. Şahsen ben projelerimde Kotlin kullanmadım. Çünkü Kotlin yeterince olgun değil ve müşterilerim çalışmalarım için para ödemeyecek ve Kotlin'de zaman kaybetmek istemiyorum. Ama bundan sonra Kotlin yavaş yavaş istikrara kavuştu ve bunu iyi olduğum projelerde de denedim ve yeni projelerde de geliştirme için kullanmayı düşüneceğim. Bazı geliştiriciler "Kotlin'in yeni projelerde geliştirme için kullanılması gerektiğini" düşünüyor. Bu görüşe katılmıyorum. Bunun bir değiş tokuş olduğunu düşünüyorum. Kotlin artık önemli bir seçenek haline geldi. Mevcut proje için uygun olduğu sürece, En iyi dil.
Mevcut bir projeyi Kotlin'e taşıyıp taşımama konusunda size iyi bir fikir veremem Önermek . Projenize göre belirli konuları analiz etmeniz gerekir. Geçiş yapmaya karar verirseniz, bu makalede listelenen olası sorunlardan bazıları size yardımcı olabilir.
sonuç olarak
Lütfen son iki yılda yaşadıklarımı açıklamak için bir Android geliştiricisinin arka planını kullanmama izin verin:
Son iki yılda üç proje başlattım ve bunlardan en az birinin geliştirilmesine katkıda bulunmaya çalışıyorum. Bu mevcut projelere tekrar baktım ve bu projelerin ilk aşamalarında alınan teknik kararların tüm proje üzerindeki etkisini analiz ettim. Bu makaleyi yazdım, ayrıca Android geliştirme üzerine birçok ileri düzey kurslar yaptım ve internette Android ile ilgili konuları tartışmak için çok zaman harcadım.
Öyle olsa bile, bugün hala tüm Android ekosistemindeki değişikliklere ayak uyduramadığımı hissediyorum. Deneyimsiz ve rehberliğe ihtiyaç duyan Android geliştiricilerinin ne kadar umutsuz olduğunu tahmin edebilirsiniz. Şimdi hayal edemiyorum ve şimdi Android'i sıfırdan öğrenmek gibi geliyor. Nihayet belirli bir çerçeveyi veya aracı öğrendiğinizde ve onu yararlı bulduğunuzda, eski hale gelebilir. Şimdi Android geliştirme ailesine katılmanın en kötü zamanı olabilir. Google, "kapsayıcılık" konusunda hoşnut değil, ancak tüm bunlar yeni başlayanlar için son derece acı verici.
Google'ın Android çerçevesinde yaptıkları çok fazla zaman kaybına neden olacaktır. Bırakın projede tüm değişiklikleri okumak birkaç saatimizi alıyor. Her şeyden vazgeçmek yerine değer yaratmak için zaman harcamayı tercih ederim.
Bu yazıda Android geliştirmenin mevcut durumunu özetlemeye ve gelecek için bazı tahminler yapmaya çalışıyorum. Makale hatalar içerebilir ve bazı önemli bilgiler içermeyebilir. Lütfen aşağıdaki yorumlarda bana bildirmekten çekinmeyin. Makalenin içeriği objektif, tartışmalı bazı noktalar öne sürmeme rağmen haklı olduğuma inanıyorum.
Ayrıca yazıda daha önce yazdığım birçok gönderiden alıntı yaptım ve gösteriş yapmak istemedim. Bunun yerine, önceki tahminleri okumanıza ve mevcut durumla karşılaştırmanıza olanak tanır.O zamanlar okumak çılgınca olsa da, şu anda bu makaleyi okuduğunuz gibi, tahminlerim çok doğru. Tabii ki şunu da söylemek istiyorum: "Bak, haklıyım." Yayınladığım içeriğin tartışmalı olduğu düşünüldüğünde, okuyucuları yanıltmadığını öğrenince de çok rahatlardım. Bazen tahminimin yanlış olmasını tercih ederim, Google geliştiriciler hakkında düşünüyor. Ancak şimdiye kadar durum böyle değil.
Her zamanki gibi okuduğunuz için teşekkür ederim. Aşağıya gidebilirsin mesaj bırakın Yorumlar ve sorular.
https: // stackoverflow .com / Questions / 29197821 / neden-aosp-add-new-apis-to-support-libraries-without-without-sdk
https://developer.android .com / jetpack
https: //android-developers.googleblog .com /2019/11/unifying-background-task-scheduling-on.html
https://issuetracker.google .com / sorunlar / 122098785
https://youtu.be/UnJ3amzJM94
https: //android-review.googlesource .com / c / platform / çerçeveler / destek / + / 1169184/3 / uygulama Licationpreferences / src / main / java / androidx / uygulama licenseationpreferences / ApplicationPreferences.java
https: // stackoverflow .com / a / 37551254/246 30 35
https: // www. teknoloji .com / hançer-android-ölü /
https: // stackoverflow .com / a / 30 6285 30 / 246 30 35
https: // www. reddit .com / r / androiddev / yorumlar / b908fr / can_someone_explain_to_me_why_aac_is_trying_to /
https: //android-review.googlesource .com / c / platform / çerçeveler / destek / + / 1159084
https: // www. teknoloji .com / android-fragment-yaşam döngüsü
https: // www. teknoloji .com / android-viewmodel-architecture-component-zararlı /
https: // www. teknoloji .com / asynctask-kullanımdan kaldırıldı /
https: // www. teknoloji .com / kotlin-coroutines-in-complex-scenarios /
https: // www. teknoloji .com / migrate-android- uygulama lisanslar-kotlin-ile-dikkatli /
İngilizce: Yerel Android Geliştirme Durumu
Bağlantı: https: // www. teknoloji .com / the-state-of-native-android-development-november-2019 /
Yazar: Vasiliy Zukanov, bağımsız Android geliştiricileri ve yazılım danışmanı
Çevirmen: Luo Zhaocheng, Android Geliştiricisi
