Android Geliştiricilerinin Yaptığı En Yaygın 10 Hata: Bir Programlama Eğitimi
Yayınlanan: 2022-03-11Android. Bu platformda sevilmeyen şey nedir? Ücretsizdir, özelleştirilebilir, hızla büyüyor ve yalnızca telefonunuzda veya tabletinizde değil, akıllı saatinizde, TV'nizde ve arabanızda da mevcut.
En son Lollipop güncellemesi ile Android programlama gelişmeye devam ediyor. Platform, ilk AOSP sürümünden bu yana biraz olgunlaştı ve kullanıcı beklentileri çıtasını oldukça yüksek tuttu. Yeni Materyal tasarım deseninin ne kadar iyi göründüğüne bakın!
Farklı ekran boyutlarına, çip mimarilerine, donanım konfigürasyonlarına ve yazılım sürümlerine sahip binlerce farklı cihaz var. Ne yazık ki, segmentasyon, açıklık için ödenmesi gereken bir bedeldir ve uygulamanızın, gelişmiş bir Android programcısı olsa bile farklı cihazlarda başarısız olmasının binlerce yolu vardır.
Bu kadar büyük segmentasyondan bağımsız olarak, hataların çoğu aslında mantık hataları nedeniyle ortaya çıkar. Temel bilgileri doğru aldığımız sürece bu hatalar kolayca önlenebilir!
İşte Android geliştiricilerinin yaptığı en yaygın 10 hatayı ele alan bir Android programlama eğitimi.
Yaygın Hata 1: iOS için Geliştirme
Büyük bir zevkle, bu Android hatası günümüzde çok daha az yaygın (kısmen müşteriler, Apple'ın tüm tasarım standartlarını belirlediği günlerin çoktan geride kaldığını fark etmeye başladıkları için). Ama yine de, arada bir iOS klonu olan bir uygulama görüyoruz.
Beni yanlış anlama, ben bir Android programlama müjdecisi değilim! Mobil dünyayı bir adım ileriye taşıyan her platforma saygı duyuyorum. Ancak yıl 2014 ve kullanıcılar bir süredir Android kullanıyorlar ve platforma alıştılar. iOS tasarım standartlarını onlara zorlamak korkunç bir strateji!
Kuralları çiğnemek için çok iyi bir neden olmadıkça, bunu yapmayın. (Google bunu her zaman yapar ama asla kopyala-yapıştır ile yapmaz.)
İşte bu Android hatasının en yaygın örneklerinden bazıları:
- Statik sekmeler yapmamalısınız ve bunlar en alta ait değil (Sana Instagram'ı gösteriyorum).
- Sistem bildirim simgelerinin rengi olmamalıdır.
- Uygulama simgeleri, yuvarlatılmış bir dikdörtgenin içine yerleştirilmemelidir (eski facebook'taki gerçek logonuz değilse).
- Açılış ekranları, ilk kurulum/tanıtmanın ötesinde gereksizdir. Bunları başka senaryolarda kullanmayın.
- Listelerde şapka olmamalıdır.
Bunlar, kullanıcı deneyimini mahvedebilecek diğer birçok küçük şeyden sadece birkaçı.
Yaygın Hata #2: Android Cihazınızı Geliştirmek
Tek bir tablet için bir kiosk/promosyon uygulaması oluşturmuyorsanız, Android uygulamanızın her cihazda iyi görünmeme ihtimali vardır. İşte hatırlamanız gereken birkaç Android programlama ipucu:
- Yoğunluktan bağımsız pikseller (dp), normal piksellerden (px) farklıdır.
- Kaynaklar, farklı yoğunlukları ve yönelimleri hesaba katmak için birden çok kez dahil edilmiştir.
- 9 yamalı çekmeceler ekrana sığacak şekilde uzatılmıştır.
Kelimenin tam anlamıyla binlerce olası senaryo var, ancak bir süre sonra hepsini bir avuç vakayla örtmek için bir his geliştiriyorsunuz.
Binlerce cihazınız yok mu? Problem değil. Android Emulator, fiziksel cihazları kopyalamada süper iyidir. Daha da iyisi, Genymotion'u deneyin, ışık hızındadır ve birçok farklı popüler ön ayarlı cihazla birlikte gelir.
Ayrıca, cihazınızı döndürmeyi denediniz mi? Kıyamet kopabilir…
Yaygın Hata #3: Amaçları Kullanmamak
Amaçlar, Android'in temel bileşenlerinden biridir. Uygulamanın farklı bölümleri veya daha da iyisi sistemdeki farklı uygulamalar arasında veri aktarmanın bir yolu.
Diyelim ki bazı resimlerin indirme bağlantısını SMS yoluyla paylaşabilen bir galeri uygulamanız var. İki seçenekten hangisi daha mantıklı görünüyor?
Seçenek 1:
SEND_SMS iznini isteyin.
<uses-permission android:name="android.permission.SEND_SMS" />
-
SmsManager
kullanarak SMS göndermek için kendi kodunuzu yazın. - Kullanıcılarınıza galeri uygulamanızın neden maliyetli olabilecek hizmetlere erişmesi gerektiğini ve uygulamanızı kullanmak için neden bu izni vermeleri gerektiğini açıklayın.
Seçenek 2:
Bir SMS Amacı başlatın ve işi SMS için tasarlanmış bir uygulamanın yapmasına izin verin
Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);
Herhangi bir şüpheniz varsa, en iyi çözüm 2. seçenek!
Bu yaklaşım hemen hemen her şeye uygulanabilir. İçerik paylaşma, fotoğraf çekme, video kaydetme, kişileri seçme, etkinlik ekleme, yerel uygulamalarla bağlantı açma vb.
Özel bir uygulama yapmak için iyi bir neden olmadıkça (ör. filtre uygulayan bir kamera), bu senaryolar için her zaman Amaçları kullanın. Size çok fazla programlama süresi kazandıracak ve AndroidManifest.xml
gereksiz izinlerden arındıracaktır.
Yaygın Hata #4: Parçaları Kullanmamak
Bir süre önce Honeycomb'da Android, fragman kavramını tanıttı. Bunları, bir Aktivite içinde bulunan kendi (oldukça karmaşık) yaşam döngülerine sahip ayrı yapı taşları olarak düşünün. Çeşitli ekranlar için optimizasyon konusunda çok yardımcı oluyorlar, ana etkinlikleri tarafından kolayca yönetiliyorlar, yeniden kullanılabilirler, birleştirilebilirler ve istendiğinde konumlandırılabilirler.
Her uygulama ekranı için ayrı bir etkinlik başlatmak son derece verimsizdir, çünkü sistem onları olabildiğince uzun süre bellekte tutmaya çalışacaktır. Birini öldürmek, diğerlerinin kullandığı kaynakları serbest bırakmaz.
Android çekirdeğinin derinliklerine inmek ve parça kullanımını savunan bu makaleyi okumak istemiyorsanız, mümkün olduğunda parçaları kullanmalısınız. Temel olarak, parçaların ve imleç yükleyicilerin iyi bir amaca sahip olduğunu, ancak uygulamanın zayıf olduğunu söylüyor.
Yaygın Hata #5: Ana Konuyu Engellemek
Ana iş parçacığının tek bir amacı vardır: kullanıcı arayüzünü duyarlı tutmak.
Gözlerimizin/beynimizin algılayabileceği kare hızını ölçmenin ardındaki bilim karmaşık olmasına ve birçok faktörden etkilenmesine rağmen, genel bir kural, 24 fps'nin altındaki ve 100 ms'den fazla gecikmeli herhangi bir şeyin sorunsuz olarak algılanmayacağıdır.
Bu, kullanıcının eylemlerinin gecikmeli bir geri bildirime sahip olacağı ve programladığınız Android uygulamasının yanıt vermeyi durduracağı anlamına gelir. Kullanıcının uygulama üzerindeki kontrolünü elinden almak hayal kırıklığına yol açar, sinirli kullanıcılar çok olumsuz geri bildirim verme eğilimindedir.
Daha da kötüsü, ana iş parçacığı bir süreliğine bloke edilirse (Etkinlikler için 5 saniye, Yayın Alıcıları için 10), ANR gerçekleşir.

Bu, Android 2.x'te o kadar yaygındı ki, daha yeni sürümlerde sistem, ana iş parçacığında ağ aramaları yapmanıza izin vermiyor.
Ana iş parçacığının engellenmesini önlemek için, her zaman için çalışan/arka plan iş parçacıklarını kullanın: 1. ağ çağrıları 2. bitmap yükleme 3. görüntü işleme 4. veritabanı sorgulama 5. SD okuma / yazma
Yaygın Hata #6: Tekerleği Yeniden Keşfetmek
“Tamam, ana konuyu kullanmayacağım. Bir arka plan dizisinde sunucumla iletişim kuran kendi kodumu yazacağım.”
Numara! Lütfen bunu yapma! Ağ aramaları, resim yükleme, veritabanı erişimi, JSON ayrıştırma ve sosyal oturum açma, uygulamanızda yaptığınız en yaygın şeylerdir. Sadece sizinki değil, oradaki her uygulama. Daha iyi bir yol var. Android'in bir platform olarak nasıl olgunlaştığını ve büyüdüğünü hatırlıyor musunuz? İşte hızlı bir örnek listesi:
- Bir yapı sistemi olarak gradle kullanın.
- Şebeke aramaları için Güçlendirme / Volley kullanın.
- Resim yüklemek için Picasso'yu kullanın.
- JSON ayrıştırması için Gson / Jackson kullanın.
- Sosyal oturum açma için ortak uygulamaları kullanın.
Uygulanan bir şeye ihtiyacınız varsa, zaten yazılmış, test edilmiş ve yaygın olarak kullanılmaktadır. Kendi kodunuzu yazmadan önce biraz temel araştırma yapın ve bazı Android programlama eğitimlerini okuyun!
Yaygın Hata #7: Başarıyı Varsaymamak
Harika. Uzun süredir devam eden görevleri yerine getirmenin daha iyi bir yolu olduğunu öğrendik ve bu amaç için iyi belgelenmiş kitaplıklar kullanıyoruz. Ancak kullanıcının yine de beklemesi gerekecek. Bu kaçınılmaz. Paketler anında gönderilmez, işlenmez ve alınmaz. Gidiş-dönüş gecikmesi var, ağ hataları var, paketler kayboluyor ve hayaller yok oluyor.
Ama bütün bunlar ölçülebilir. Başarılı ağ aramaları, başarısız olanlardan çok daha olasıdır. Peki neden başarılı isteği işleme koymadan önce sunucu yanıtını bekleyesiniz? Başarıyı varsaymak ve başarısızlıkla başa çıkmak sonsuz derecede daha iyidir. Bu nedenle, bir kullanıcı bir gönderiyi beğendiğinde, beğeni sayısı hemen artar ve olası olmayan bir durumda aramanın başarısız olması durumunda kullanıcıya bilgi verilir.
Bu modern dünyada anında geri bildirim bekleniyor. İnsanlar beklemeyi sevmezler. Çocuklar, gelecekte getirisi belirsiz olan bilgileri elde etmek için bir sınıfta oturmak istemezler. Uygulamalar, kullanıcının psikolojisine uygun olmalıdır.
Yaygın Hata #8: Bitmapleri Anlamamak
Kullanıcılar içeriği sever! Özellikle içerik iyi biçimlendirilmiş ve güzel göründüğünde. Örneğin görseller, özellikle görsel başına bin kelime taşıma özelliklerinden dolayı son derece güzel içeriklerdir. Ayrıca çok fazla bellek tüketirler. Çok fazla hafıza!
Ekranda görüntülenmeden önce belleğe yüklenmesi gerekir. Bitmap'ler bunu yapmanın en yaygın yolu olduğundan, tüm süreç için bir Android programlama kılavuzu sağlayacağız:
Diyelim ki kameranızla az önce çektiğiniz bir görüntüyü ekranınızda görüntülemek istiyorsunuz. Bunun için gereken toplam bellek aşağıdaki formülle hesaplanır: memory_needed_in_bytes = 4 * image_width * image_height;
neden 4 En yaygın/önerilen bitmap yapılandırması ARGB_8888
. Bu, çizdiğimiz her piksel için, onu düzgün bir şekilde görüntülemek için bellekte alfa, kırmızı, açgözlülük ve mavi kanal için 8 bit (1 bayt) tutmamız gerektiği anlamına gelir. RGB_565
yapılandırması gibi, ARGB_8888
daha fazla bellek gerektiren, ancak saydamlığı ve renk hassasiyetini kaybeden (belki de yeşil bir renk tonu eklerken) alternatifler vardır.
Diyelim ki full HD ekranlı ve 12 MP kameralı yepyeni bir cihazınız var. Az önce çektiğiniz resim 4000x3000 piksel büyüklüğünde ve onu görüntülemek için gereken toplam bellek: 4 bytes * 4000 * 3000 = 48 MB
Sadece tek bir görüntü için RAM'inizin 48 megabaytı!? Bu çok fazla!
Şimdi ekran çözünürlüğünü dikkate alalım. 1920x1080 piksele sahip bir ekranda 4000x3000 bir görüntü göstermeye çalışıyorsunuz, en kötü senaryoda (görüntüyü tam ekran olarak gösteriliyor) 4 * 1920 * 1080 = 8.3 MB
bellekten fazla ayırmamalısınız.
Bitmap'leri verimli bir şekilde görüntülemek için her zaman Android programlama ipuçlarını izleyin:
- Resimlerinizi gösterdiğiniz görünümü ölçün.
- Büyük resmi uygun şekilde ölçekleyin / kırpın.
- Yalnızca neyin görüntülenebileceğini gösterin.
Yaygın Hata #9: Derin Görünüm Hiyerarşisini Kullanma
Düzenlerin Android'de bir XML sunumu vardır. İçerik çizmek için XML'in ayrıştırılması, ekranın ölçülmesi ve tüm öğelerin buna göre yerleştirilmesi gerekir. Optimize edilmesi gereken, kaynak ve zaman alan bir süreçtir.
ListView (ve daha yakın zamanda RecyclerView) bu şekilde çalışır.
Bir düzen bir kez şişirilmişse, sistem onu yeniden kullanır. Ama yine de, düzeni şişirmek bir noktada gerçekleşmelidir.
Diyelim ki resimlerle 3x3 bir ızgara yapmak istiyorsunuz. Bunu yapmanın bir yolu, her biri eşit ağırlıkta 3 ImageViews
içeren, eşit ağırlıkta 3 LinearLayout
içeren dikey bir LinearLayout
.
Bu yaklaşımla ne elde ederiz? "İç içe ağırlıklar performans için kötü" uyarısı.
Android programlama dünyasında az önce uydurduğum bir söz vardır: "Az bir çabayla tüm hiyerarşi düzleştirilebilir" .
Bu durumda, RelativeLayout
veya GridLayout
, iç içe LinearLayouts
verimli bir şekilde değiştirecektir.
Yaygın Hata #10: minSdkVersion'ı 14'e Ayarlamamak
Pekala, bu bir hata değil, ama kötü bir uygulama.
Android 2.x, bu platformu geliştirmede büyük bir kilometre taşıydı, ancak bazı şeylerin geride bırakılması gerekiyor. Daha eski cihazları desteklemek, kod bakımı için daha fazla karmaşıklık ekler ve geliştirme sürecini sınırlar.
Rakamlar net, kullanıcılar ilerledi, geliştiriciler geride kalmamalı.
Bunun eski cihazlara sahip bazı büyük pazarlar (ör. Hindistan) için geçerli olmadığının farkındayım ve minSdkVersion
Facebook Uygulamasında 14'e ayarlamak, birkaç milyon kullanıcıyı favori sosyal ağlarından mahrum bırakmak anlamına geliyor. Ancak, yeni başlıyorsanız ve kullanıcılarınız için güzel bir deneyim yaratmaya çalışıyorsanız, geçmişi ortadan kaldırmayı düşünün. Kaynakları olmayan veya cihazlarını/işletim sistemlerini yükseltme ihtiyacı hisseden kullanıcılar, Android uygulamanızın üstün bir sürümünü deneme ve nihayetinde bunun için para harcama teşvikine sahip olmayacaktır.
Sarmak
Android, hızla gelişen güçlü bir platformdur. Kullanıcıların hıza ayak uydurmasını beklemek makul olmayabilir, ancak Android geliştiricilerinin bunu yapması çok önemlidir.
Android'in sadece telefonlarımızda veya tabletlerimizde olmadığını bilmek daha da önemlidir. Bileklerimizde, oturma odalarımızda, mutfaklarımızda ve otomobillerimizde. Genişlemeye başlamadan önce temel bilgileri doğru almak çok önemlidir.