Android geliştiricisinin tanrıya giden yolu
Bir Android teknik uzmanının en az 2 ila 3 profesyonel alanı vardır.
Yazar | Vasiliy Zukanov, çeviri yetkisi
Çevirmen | Luo Zhaocheng, Android Geliştiricisi
Editör | Tang Xiaoyin
Üretildi | CSDN (ID: CSDNnews)
Ç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ı aşağı yukarı farklıdır, ancak genel olarak, mükemmel bir Android mühendisi olmak için hepimizin bir dizi beceri öğrenmesi gerekir.
Bana göre böyle bir kafa karışıklığı normaldir. Android devasa ve dinamik bir ekosistemdir. İlgili araç ve kavramlarından bazılarını anlamak ve öğrenmek için birkaç hafta harcamanız gerekebilir, ancak sonunda bunların çoğunun çok önemli olmadığını veya çok yararlı olmadığını göreceksiniz. Bu nedenle, bu yazımda Android geliştirmede kullandığım önemli becerileri paylaşacağım, size yardımcı olmayı umarak, enerjinizi önemli şeylere odaklamanıza izin vereceğim.
Elbette deneyimli bir Android geliştiriciyseniz, bu bilgiyi hepiniz biliyor olabilirsiniz. Çok fazla temel bilgi birikimini gerektiren birçok beceri ve bakış açısı vardır.Yeterli deneyime sahip olmadığınızda bu beceri noktalarını görmek zordur. Bu yazıda, tüm Android geliştiricilerinin ihtiyaç duyduğu becerileri listelemem imkansız. Bu nedenle, bu bilgi noktalarını farklı deneyimlere göre kabaca gruplandırdım. Lütfen bunun yalnızca kaba bir gruplama olduğunu ve çok kesin olmadığını unutmayın.
Önüne yaz
Sadece Android geliştiricisi olmak isteyen ve herhangi bir uygulama yazmamış bir kişiyseniz, bu makale sizin için biraz erken. Bu makale esas olarak geliştiricilerin daha profesyonel bir kişi olmasına yardımcı olmak içindir.
Bu yazıda size birçok öneri vereceğim ve eve eli boş gitmenize izin vermeyeceğim. Makale, kısa sürede nasıl profesyonel bir geliştirici olunacağını listeliyor. Makaleyi okuduktan sonra, kendi başınıza pratik yapmanız ve bu becerileri sık sık görmek için geri dönmeniz gerekir.
Bu makaleye başlamadan önce, Google Play'de bir Android uygulaması yayınladığınızı ve kaynak kod yönetimi için GitHub kullandığınızı varsayacağım.
0-2 yıllık geliştirme tecrübesi
Android çok karmaşık bir çerçevedir ve dik bir öğrenme eğrisine sahiptir. Native Android geliştiricilerinin öğrenmesi gereken bazı karmaşık kavramlar var, ancak diğer kısmı Android'den kaynaklanıyor ve bu da karmaşıklığına neden oluyor.
Mesleğe girdiğinizde, yazılım geliştirme çalışmanıza ek olarak, Android çerçevesini öğrenmeli, dili, mimariyi ve popüler açık kaynak kitaplıklarını unutmalı, temel kavramlara odaklanmalı ve derinlemesine araştırma yapmalısınız.
Özellikle, aşağıdakiler hakkında daha fazla bilgi edinmenizi öneririm:
-
Android bellek yönetimi ve işlem planlaması
"Düşük Bellek Katili" ile karşılaştığınızda, uygulamanızın kararlı ve güvenilir çalışmasını nasıl sağlarsınız? Bu çok karmaşık bir konu. Uzun lafın kısası, kullanıcı başka bir uygulamaya geçtiğinde uygulamanızın yaşam döngüsü kesintiye uğrayacaktır, ancak kullanıcı bir süre sonra geri döndüğünde, kullanıcı, uygulamanızın hiçbir şey olmamış gibi normal şekilde çalışmasını umar. .
Bu yazıda, hafıza yönetiminin herhangi bir detayını tanıtmayacağım, onları anlamak istiyorsanız, bu makaleyi okuyabilirsiniz.
-
Yaşam döngüsü
Biri benden bir Android uygulamasındaki hataların karmaşıklığını ve ana kaynağını söylememi isterse, ona hemen yüksek sesle bunun "yaşam döngüsü" olduğunu söyleyeceğim (sonra yüzümü örtün ve ağlayın).
Uygulama, Etkinlik, Parça, Hizmet, BroadcastReceiver, ContentProvider ve Android çerçevesinin bazı temel bileşenleri karmaşık yaşam döngülerine sahiptir ve yaşam döngüleri aynı değildir. Bunun yeterli olmadığını düşünüyorsanız, Google ayrıca yeni kitaplıklar ve çerçeveler de başlatıyor, bu kitaplıkların kendi karmaşıklıkları ve bağımsız yaşam döngüleri var. Loader, ViewModel ve LiveData bu sorunları çözmek için başlatıldı.
İlginç bir şey, "yaşam döngüsü" tanımını hiç görmedim. Kullanıyoruz ama bu ne anlama geliyor? Bildiğim kadarıyla, bir dereceye kadar, bir yaşam döngüsü grafiği oluşturmak için bazı düğümleri birbirine bağlamanız yeterli. Yaşam döngüsü hakkında çok düşündüm, burada onu tanımlamaya çalışacağım.
Bir bileşenin yaşam döngüsü, soyut bir durum makinesidir. Buradaki özet, bu durum makinelerinin durumlarının önceden tanımlandığı ve aralarındaki geçiş koşullarının da tanımlandığı anlamına gelir. Ancak bu tanımlar eksiktir. Düzgün çalışması için eksik parçaları uygulamanız gerekir. Bu eksik parçalar, "yaşam döngüsü geri çağırmaları" olarak adlandırdığımız bu bileşen yöntemlerinin bir alt kümesidir. Durum makinesinin kendisine ek olarak, bu yaşam döngüsü geri aramalarının birçok örtük kısıtlaması ve kısıtlaması da vardır. Bu kısıtlamalardan bazıları belgelerde yazılıdır, bazıları ise değildir.
Yaşam döngüsü ne kadar karmaşık? Önce bu resme bir göz atalım (biraz eksik ve biraz modası geçmiş). Bu resim biraz korkutucu görünüyor. Ancak panik yapmayın, çoğu Andorid geliştiricisi bu resmi anlamıyor. Aslında, Google'ın Android geliştiricileri bile yaşam döngüsünü anlamıyor. Google, Lifecycle bileşenini yayınladığında, Fragment ile ilgili bazı hatalar ortaya çıkardı ve bunlar sonraki yeni sürüm yayınlanana kadar düzeltilmedi.
Artık Android'in yaşam döngüsünü tam olarak kavramanız gerekmese de bazı önemli ayrıntıları bilmeniz gerekir. Aksi takdirde, kodunuz dağınık hale gelir ve bir dizi zor soruna yatkın hale gelir. Yaşam döngüsünün ayrıntılarını anlatan Etkinlik Yaşam Döngüsü ve Parça Yaşam Döngüsü adlı iki makale yazdım. OnStart ve onResume'u nasıl kullanacağınızı bilmediğinizde, bu iki makaleyi okuyabilirsiniz.
Yaşam döngüsünün temellerini öğrendikten sonra, Android Geliştirmenin On Günahı Gabor Varadi'ye göz atabilirsiniz. Bu makale çoğu geliştiricinin yaptığı hataları listeler. Bu hataların çoğu yaşam döngüsü ile ilgilidir.
Bu arada, görüşmede yaşam döngüsü ile ilgili sorular da sıkça sorulacak. Bu yüzden yaşam döngüsünü iyi incelemelisiniz.
-
Bağlam
Her Android uygulamasında bir veya daha fazla bağlam nesnesi vardır.
Yaşam döngüsü gibi, açıklaması da zor. Bir "Tanrı" gibidir, pek çok yeteneği vardır. Bunu bir veya iki cümle ile net bir şekilde anlatmak bizim için zor. Yine de, Bağlamın sorumluluklarını ve farklı Bağlamlar arasındaki farkı anlamak çok önemlidir.
Bu makalede artık Context ile ilgili içerik yok, StackOverflow'un "Android'de 'Context' nedir? 'Sorusuna verdiği cevabı ve bu cevabı okumanızı öneririm.
-
UI iş parçacığı
Her Android uygulamasının özel bir UI dizisi vardır. Bu iş parçacığı ekranda UI sayfasını çizer. UI iş parçacığını aşırı yüklerseniz, uygulamanız takılı kalır ve yanıt vermez. Olağanüstü durumlarda, UI iş parçacığındaki bir hata, uygulamanın tamamında bir hataya neden olabilir (en azından bir hata gibi görünür).
Konuların ardındaki mekanizma hakkında daha fazla bilgi edinmek istiyorsanız, bu videoyu izleyebilirsiniz. Video, ilgili ayrıntılar ve UI iş parçacıklarının olası sorunları dahil olmak üzere Android'deki çoklu okumayı ayrıntılı olarak açıklamaktadır.
-
Mantıksal bölünme
Genel olarak, Android çerçevesinin kodu çok dağınık. Her biri binlerce satır kod içeren birçok tanrı sınıfı içerir ve uygulamamızı çalıştırmak için bu sınıfları genişletmemiz gerekir. Çoğu durumda, ister Uygulama, Aktivite, Parçalar veya Servis olsun, hepimiz büyük bir sınıftayız ve birçok şey yapıyoruz.
Bu, Andorid geliştirmede yaygın bir uygulama olmasına rağmen, kod mantığımızın uzun vadeli bakımına elverişli değildir. Bu nedenle, bu soruna olabildiğince dikkat etmemiz, kodu yeniden düzenlemek için daha fazla fırsat bulmamız ve mantığı bağımsız sınıflara bölmemiz gerektiğini öneriyorum.
Dürüst olmak gerekirse, küçük bir geliştiricinin mimari ve tasarımda çok fazla iyileştirme yapabileceğini düşünmüyorum. Kod mantığını doğru bir şekilde kapsüllemek ve anlamlı sınıfları çıkarmak, biraz geliştirme deneyimi gerektirir. Tabii ki, kod bölme hakkında düşünmemenizi istemiyorum Kontrol edilemeyen durumlardan kaçınmak için kapasiteniz dahilinde bir şeyler yapabilirsiniz (örneğin, bir Aktivitede 5000 satırdan fazla kod yazılır).
Başlangıçta, bu makalede açıklanan Bağlam ile ilgili mantığı bölmeyi deneyebilirsiniz.
2-4 yıllık geliştirme tecrübesi
Kariyerinizde birkaç yıl çalıştıktan sonra deneyimli bir Android geliştiricisi olursunuz.Araştırma ve öğrenme yoluyla profesyonel olmayan bazı işlevleri kolayca uygulayabilirsiniz. Bundan sonra ne yapmalısın?
Bence şu anda, Android çerçevesinin temellerine zaten aşinasınız ve daha üst düzey beceriler öğrenmeyi deneyebilirsiniz. Bu beceriler Android ile sınırlı değildir, bazı genel yazılım geliştirme becerileridir. Özellikle aşağıdaki konuları inceleyebilirsiniz:
-
Bağımlılık ekleme
Bağımlılık enjeksiyonu bir Dikkat Yapı ayrımının tasarım deseni. Esas olarak uygulamanın iki işlevini ayırmak için kullanılır: uygulama ile çekirdek işlev arasındaki bağlantı ve temel işlev bileşeninin gerçekleştirilmesi.
Bazı açılardan, bağımlılık enjeksiyonunu uygulayan bir kod kütüphanesi bir bilgisayar gibidir: temel bağımlılık enjeksiyon kütüphanesi bir anakart gibidir, diğer işlevsel bileşenler ise CPU, bellek, çevre birimleri vb. Bağımlılık ekleme kodunuzda uygulandığı sürece, kolayca eklemek Yeni işlevler ve diğer bileşenlerin işlevlerini kolayca yeniden kullanabilir ve ayrıca yeni bileşenlerin işlevlerini de kolayca kullanabilir. Bu metafor biraz abartılı olsa da bence bağımlılık enjeksiyonunun arkasındaki fikri çok iyi yansıtıyor.
Ne yazık ki, bağımlılık enjeksiyonu ile ilgili birçok makale yanlış anlaşılıyor ve bu da yeni başlayanlara çok fazla müdahale getiriyor. Bu nedenle, bağımlılık enjeksiyonu hakkında bilgi edinmek istiyorsanız, bu makaleyi okumanızı tavsiye ederim.Bu makalede, bağımlılık enjeksiyonunun birçok "efsanesini" analiz ettim.
-
UI ayrımı
Android çerçevesinin mimarisinden dolayı, geliştirme sürecinde kullanıcı sayfasını uygulamadaki diğer mantıkla birleştirdik. Hemen hemen tüm Android yeni başlayanlar bunu yapar. Bu bağlantı, uygulamanın UI çizimini, ağ işlemeyi, çoklu okuma, uygulama iş mantığını vb. İçeren büyük bir sınıf yazmaya yönlendirecektir.
Tecrübelerime göre, UI mantığı ve diğer mantığın birleştirilmesi, kodun sürdürülebilirliğinin daha da kötüleşmesine neden olacaktır.Er ya da geç, kodun anlaşılması zor ve okunamaz hale gelecektir. Sonunda, işlevdeki küçük bir değişiklik büyük yan etkilere neden olabilir.
UI mantığını diğer mantıktan ayırmak için Model-View-X mimari modelini kullanabilirsiniz. Örneğin: Model-View-Contoller (MVC), Model-View-Presenter (MVP), Model-View = ViewModel (MVVM). Bu mimari desenlerin hepsi aynı tip mimariye aittir ve tabii ki bu tip mimari sadece listelenenleri değil diğer mimari desenleri de içerir. Burada, bu tür bir mimari modeli daha rahat bir şekilde tanımlamak için, bunlardan topluca MVx modeli olarak bahsediyorum.
MVx modelini öğrenirken, lütfen bunların mimari değil, mimari bir desen olduğunu unutmayın. Bu mimari desenler yalnızca UI sunum mantığı için kullanılır. Yani sadece MVx kullanmak size iyi bir mimari vermez, iyi bir mimariye sahip olmak için diğer alanlarda daha fazla çaba sarf etmeniz gerekir.
-
Çoklu kullanım
Deneyimli Android geliştiricileri, çoklu okumayı anlayacak ve uygulamalar üzerindeki etkisini anlayacaktır. AsyncTask, RxJava, coroutines vb. Konularda uzman olduğumu söyleyebilirsiniz. İfade etmek istediğim çoklu okuma, anladığınız şey değil. Çok iş parçacıklı bir çerçeve kullanabilmek, çok iş parçacığını anlamakla aynı şey değildir.
Örneğin, birçok Android geliştiricisi AsyncTask kullanmanın bellek sızıntılarına neden olacağına inanıyor. Bu görünüm, Android Studio'nun varsayılan çok iş parçacıklı tüy bırakma kurallarından gelir. Bu durumda, bu görüş doğru mu? Maalesef bu görüş yanlış. Burada detaylarını açıklamayacağım, AsyncTask hakkında bir çok içeriğe sahip olan bu yazıyı okuyabilirsiniz.
Çok iş parçacıklı programları anlamak için doğru eşzamanlı kod yazmak için Thread'e dayalı olsa bile herhangi bir çok iş parçacıklı çerçeveyi kullanabilmeniz gerektiğini düşünüyorum. Bu hedefe ulaşmak için, yalnızca en sevdiğiniz çok iş parçacıklı kitaplığın API'sini bilmeniz değil, aynı zamanda çok iş parçacıklı okumanın ayrıntılarını da anlamanız gerekir. Bu çok iş parçacıklı kitaplıkların kullanımı kolay olsa da, çok iş parçacıklı çalışmanın temel ayrıntılarını anlamıyorsanız, uygulamanızın çok iş parçacıklı olması sadece bir zaman meselesidir.
Çoklu okumayı öğrenmek istiyorsanız, tüm Android geliştiricilerinin bilmesi gereken temel kavramları ve ilkeleri açıklayan bu videoyla başlayın.
-
otomatik test
Bildiğim kadarıyla birçok Android projesi otomatik test kullanmıyor. Otomatik test kullanan projelerin çoğu, Appium gibi araçlar kullanılarak QA personeli tarafından yapılır. Bu, tüm Android endüstrisinin statükosu, çok üzücü. Otomatik test olmamasının nedeni, bu sorunun Android'in kökenine kadar izlenebilir. Google, Dikkat Üçüncü taraf uygulamaların otomatik testi.
Günümüzde, birim testi ve UI otomasyon testi konusunda deneyime sahip geliştiriciler büyük talep görmektedir. Herhangi bir otomatik test kullanmamış bir şirketle görüşmeye gitseniz bile, testi otomatikleştirebileceğinizi söylerseniz, görüşme için size ekstra puan verecektir. Tersine, otomatik testi yoğun bir şekilde kullanan bir şirkete giderseniz ve otomatik test etme beceriniz yoksa, bu mülakat puanlarınızı düşürecek ve dezavantajlı duruma gelecektir.
Bu nedenle, her Android geliştiricisinin otomatik test hakkında bilgi edinmesini öneririm. Şahsen, birim testini tercih ederim. Ve bazı geliştiriciler UI otomasyon testini sever. Böylece daha çok ilgilendiğiniz bir teknolojiyi seçip deneyebilirsiniz.
4 yıldan fazla deneyim
Android geliştirmede zaten zengin bir deneyime sahipseniz, bazı "meta" becerileri öğrenmenin ve belirli alanlarda derinlemesine araştırma yürütmenin zamanı gelmiştir. Bence aşağıdaki beceriler profesyonel geliştiriciler için çok iyi yönlendirmelerdir.
-
Teknik çözüm değerlendirmesi
Bunu daha önce yapmadıysanız, şimdi başlama zamanı. Her önemli teknik kararın değerlendirilmesi ve tartılması gerekir. Bazen bu kararın sonuçları çok iyi ve hızlıdır. Ancak çoğu zaman sonuçları hemen görmek her zaman mümkün değildir. Normal şartlar altında, karar verme kapsamı ne kadar genişse, ilgili değerlendirme kapsamı o kadar geniş olur Basit karar vermeye ek olarak, çok soyut olan birçok değerlendirilebilir madde vardır ve kısa sürede sonuç alınamaz.
Zengin deneyim seviyenizle ve birçok seçenekle karşı karşıya kalmanız durumunda, en azından dengeyi nasıl bulacağınızı bilmelisiniz. Teknik çözümlerin değerlendirilmesi için faydalı öneriler sunabiliyorsanız, mükemmelsiniz. Bunu tartan teknik çözüm değerlendirmesi çok karmaşık bir beceridir. Genellikle, diğer geliştiricilerle, proje yöneticileriyle ve hatta diğer departmanların çalışanlarıyla tartışırken bir uzlaşma bulabilir ve planı değerlendirebilirsiniz. Bu nedenle, çoğu durumda, yalnızca planı değerlendirme yeteneğinde ustalaşmanız gerekir.
Peki "teknik çözümlerin değerlendirilmesi" ile neyi kastediyoruz? Dürüst olmak gerekirse, ne olduğunu belirtmek zor. Bununla birlikte, geliştirmede neden uygun olmadığını açıklamak için bazı karşı örnekler sağlayabiliriz. Örneğin:
Çoklu kullanım kullanımını AsyncTask yerine RxJava'ya taşımalıyız çünkü AsyncTask bellek sızıntılarına neden olacaktır.
Daha önce de söylediğim gibi, AsyncTask bellek sızıntılarına neden olmaz. Yani yukarıdaki cümle yanlış. Bunu söyleyen geliştiriciler, çoklu iş parçacığını derinlemesine incelememişlerdir. Ayrıca RxJava sorunundan bahsetmedi. Bir projedeki geliştiriciler için, RxJava'nın dik bir öğrenme eğrisi vardır.
Yeni kodumuz için birim testleri yazmalı ve kodumuzun kalitesini sağlamak için tüm kodları kapsayacak uzun vadeli bir hedef belirlemeliyiz.
Bu cümle birkaç önermeyi içeriyor Her şeyden önce, birim testine şimdi başlamamız imkansız. En azından geliştiricilerin bu teknolojiyi öğrenmek için zaman harcamaları gerekiyor. Birim testleri yazmak çok akıllıca bir karardır. Tüm kod için birim testleri yazamayız çünkü bazı kısımlar kararsızdır. Son olarak, belirli bir kapsam hedefine ulaşmak "kaliteyi" otomatik olarak iyileştirmez. Bu örnekte, geliştiriciler birim testini anlamıyorlar ve projede birim testini kullanmanın içerdiği sorunları ve etkileri belirleyemiyorlar.
Umarım "teknik çözüm değerlendirmesi" hakkında genel bir fikriniz vardır. Önemli bir kararınız varsa, gerekli tüm araştırmaları tamamlamanız gerekir. Karmaşık ağı hala tüm değerlendirmede göremiyorsanız, belki Araştırmanız iyi yapılmadı. Bir karar verirken, bazı şeyler teknolojinin kapsamı dışında olabilir ve ayrıca kararınızın diğer bölümlerdeki meslektaşlarınız üzerindeki etkisini de göz önünde bulundurmanız gerekir.
-
profesyonel alan
Bir teknik uzman ile sıradan bir geliştirici arasında nasıl ayrım yapılır? Aşina olduğumuz kavramların sayısı mı? Bana göre, teknoloji açısından uzmanlar arasındaki ayrım esas olarak bilgi derinliğine dayanıyor.
Teknik bir uzman olarak, bir veya daha fazla uzmanlık alanınız olmalıdır. Bu alanların ayrıntılarını, ortalama bir geliştiricinin bildiğinden çok daha fazlasını biliyorsunuz. Profesyonel derinliğinizi sağlamak, profesyonel alandaki en son gelişmeleri anlamak ve yeni araçlar ve teknolojiler sizi şaşırtmamak için sürekli ve derinlemesine araştırmaya ihtiyacınız var. Ek olarak, herhangi bir projede belirli teknolojileri kullanmasanız bile, bu teknolojilerin kullanımıyla ilgili çeşitli maliyetleri incelemeniz gerekir.
Günümüzde kişinin kendi profesyonel alanına sahip olması zordur. Bu sadece blogdan okumak için birkaç iyi makale seçme meselesi değil, sadece birkaç iyi kitap okumak ve birkaç iyi ders almakla ilgili değil. Elbette, bu içerikler aracılığıyla öğrenmek, uzmanlık yolunuz için yararlıdır, ancak kendi profesyonel alanınıza sahip olmanın tek yolu, bu alana aktif olarak katılmak, çalışmak ve çok fazla deneyim kazanmaktır.
Fizikçi Niels Bohr'un sözlerini beğendim:
Uzman, yapılabilecek tüm hataları dar bir alanda yapmış kişidir. (Uzman, yapılabilecek tüm hataları dar bir alanda yapmış kişidir.)
Hangi alanlarda derinlemesine araştırma yapabiliriz? Aslında neredeyse tamamı derinlemesine incelenebilir.Yazılım geliştirme alanında hiçbir alan profesyonel bir hedef olarak belirlenemeyecek kadar küçük değildir. Bu konuda da bazı önerilerim var:
-
UI
-
Sistem oluştur
-
Çevrimdışı çalışmak
-
Eşzamanlı
-
NDK
-
Sürekli entegrasyon
-
verim
-
Mimari
-
monitör
-
Proje Yönetimi
-
Uzmanlık alanları
Çok daha fazlası var. Yukarıda listelediğim bazı içeriklerin kesinlikle teknik alanlar olmadığı unutulmamalıdır. İşvereniniz için değer üretebildiğiniz sürece, istediğiniz herhangi bir alanı seçebilir ve derinlemesine araştırma yapabilirsiniz.
Bir Android teknik uzmanının en az 2 ila 3 profesyonel alanı olduğunu düşünüyorum.Örneğin, benim profesyonel alanım: mimari, birim testi, eşzamanlılık, bağımlılık enjeksiyonu. Yakın gelecekte, mesleki beceriler listeme "ataların kodunu yeniden düzenleme" yi ekleyebileceğime inanıyorum.
Peki, 4 yıldan fazla deneyime sahipseniz, uzmanlık alanınız nedir?
sonuç olarak
Yukarıda, profesyonel bir Android geliştiricisi olarak size önerdiğim beceriler bunlar.
Makalemin başlığının "2020 için Android Geliştirici Becerileri" olduğunu keşfetmiş olabilirsiniz, ancak bu makaledeki hiçbir şey 2020'ye özgü değildir. Bu yazıyı bir veya iki yıl önce yazabilirim, çünkü bu yazının içeriği her zaman için uygun olduğu için temel ve önemli kavramlar pek değişmeyecek.
Şimdi Android ekosisteminin en son gelişmesini merak ediyorsanız benim başka bir yazımı okuyabilirsiniz. 2019 sonunda Android geliştirmenin durumunu özetledim. Son olarak, iyi bir Android geliştiricisi olmak istiyorsanız, lütfen temeller ve önemli şeyler üzerinde derinlemesine araştırma yapmaya odaklanın.
Her zamanki gibi okuduğunuz için teşekkür ederim. Aşağıya yorum ve soru bırakabilirsiniz.
İngilizce: 2020 için Android Geliştirici Becerileri
Bağlantı: https: // www .techyourchance .com / android-geliştirici-becerileri /
Yazar: Vasiliy Zukanov, bağımsız Android geliştiricileri ve yazılım danışmanı
Çevirmen: Luo Zhaocheng, Android Geliştiricisi
