Yetersiz Kullanılmış Android Kitaplıkları İçin Aşırı Kapsamlı Bir Kılavuz

Herhangi bir deneyimli geliştirici size en iyi kodunun yazdıkları kod olmadığını söyleyecektir. Başka birinin çalışmasından aldıkları kod.

Evet, biz geliştiriciler yenilikçi problem çözücüleriz, ancak karşılaştığımız sorunların çoğu zaten çözüldü ve çözümler herkesin erişebileceği kitaplıklarda paketlenmiştir. Her yerde serbest tekerlekler varken tekerleği neden yeniden icat edelim?

Android bir istisna değildir. Kodun yeniden kullanımı için nihai kaynak, işinizin çoğunu sizin için yapacak harika yapılar ve hizmetlerle birlikte gelen Android SDK'nın kendisidir.

Ancak, SDK'nın yetersiz kaldığı durumlarda, Android topluluğu, sizi tonlarca kodlama işinden kurtarabilecek, yüksek düzeyde ayarlanmış, incelenmiş ve test edilmiş uygulamalarla değiştirebilecek bazı birinci sınıf kitaplıklar oluşturdu. Apaçık kitaplıklardan bahsetmiyorum—Android Destek Kitaplığı, Android Tasarım Destek Kitaplığı, Gson. Bilmediğiniz araçlardan bahsediyorum. Ve yapsanız bile, muhtemelen henüz kullanmıyorsunuzdur.

Yıllardır Android ekipleri geliştiriyor, akıl hocalığı yapıyor ve liderlik ediyorum ve düzinelerce harici araç ve kitaplık okudum ve kullandım. (Uygulama kodlarını okuduğum ve geliştiriciyle içlerini tartıştığım bile biliniyor.) Birçoğu işi bitirmeme yardım etmede oldukça etkili oldu, ancak gerçek şu ki, çoğu değildi.

Bu yüzden bu kılavuzu bir araya getirdim. En iyi kitaplıkları kullandığınızdan emin olmak için benim ve diğer mobil geliştiricilerin deneyimine güvenin. Yedi tane seçtim. Çok yakında favorilerinizden biri olacaklarından şüpheleniyorum.

Doğru Android Kitaplığını Seçme

Bir kitaplık seçerken dört temel özellik ararım:

• Gerçek ve önemsiz olmayan bir sorun için tutarlı ve yüksek kaliteli bir çözüm sağlar.
• Mümkün olduğunca basit bir API kullanır.
• Genel mimarimde herhangi bir değişikliği zorlamaz.
• Geniş bir kullanıcı tabanına ve tercihen aktif bir geliştirici topluluğuna sahiptir.

İlk üç özellik anlaşmaları bozar. Eğer orada değillerse, devam ederim veya elle kodlamaya başlarım.

Aşağıda ele aldığım kütüphaneler dört testi de geçiyor. Ayrıca mobil geliştirmenin en zorlu yönlerinden bazılarını çözüyorlar.

• Bağımlılık ekleme, düzenden Java'ya bağlama, sahte nesneler için iki kitaplık.
• Uygulama içi pub/alt mesajlaşma modeli.
• Güvenli, verimli, kendi kendini kurtaran HTTP iletişim katmanı.
• Görüntü işleme: indirme, önbelleğe alma, yeniden boyutlandırma ve RAM'e yükleme.
• Gerçek zamanlı video akışı.
• Bellek sızıntısı algılama.

ButterKnife: Nihai Bağımlılık Enjeksiyon Aracı

Bu, Android için nihai bağımlılık enjeksiyon kitaplığıdır. Basit, sağlam, süper hızlı (yansıma yok!) ve uygulamanızın ortak kod kodunun çoğunu ortadan kaldırabilir.

findViewById() bir çağrı yoluyla görünümlerinizin her birini doğrudan bağlama ihtiyacı ortadan kalktı; bunun yerine, koda doğrudan erişim sağlayan açıklamalı bir görünüm vardır.ButterKnife ayrıca onClick , onTouch vb. standart kullanıcı arabirimi olaylarına olan ihtiyacı ortadan kaldırır ve bunları otomatik olarak enjekte edilen kodla değiştirir.

Ama yeterince sohbet, kodu görelim.

Alan bağlamayı görüntüle:

 class MyButterKnifeActivity extends Activity { @BindView(R.id.name) TextView name; @BindView(R.id.address) TextView address; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.simple_activity); ButterKnife.bind(this); // MUST BE CALLED BEFORE ACCESSING UI FIELDS name.setText(“etc etc”); } }

Kaynak bağlama:

 class ExampleActivity extends Activity { @BindString(R.string.username) String username; @BindDrawable(R.drawable.graphic) Drawable graphic; @BindColor(R.color.bg_color) int bgColor; @BindDimen(R.dimen.lower_padding) Float lowerPadding; // and no need for getResources().getString()/getDrawable/getColor() }

UI olay bağlama:

 @OnClick(R.id.my_button) public void clickHandler(View view) { // onClick logic goes here }

AndroidAnnotations: Dependency Injection'ı Bir Sonraki Seviyeye Taşımak

Bağımlılık enjeksiyonu söz konusu olduğunda ButterKnife'a yakın bir saniye olan AndroidAnnotations, biraz farklı bir yaklaşım kullanır: Bir kez alıştığınızda son derece basit olan otomatik oluşturulan sınıflar. Daha da kullanışlısı, size “isme dayalı” bağımlılık enjeksiyonuna izin vermesidir. Örneğin, @ViewById ListView myUserList; kitaplığa bu alanı aynı ada sahip bir layoutListView ataması talimatını verir.

AndroidAnnotations da çok hızlı çalışıyor, ancak bunu ButterKnife'dan biraz farklı bir şekilde başarıyor. AndroidAnnotations, çalışma zamanı bağlama bağımlılığı enjeksiyonu yerine, etkilenen tüm etkinliklerin derleme zamanı çoğaltmasını oluşturur ve bağlantı mantığını bunlara aktarır, böylece elle kodlanmış mantıkla elde ettiğiniz performansın aynısını elde etmenize olanak tanır.

Ancak AndroidAnnotations'ın ekleme yetenekleri bundan daha da ileri gider. Bir etkinliğe hem durumu hem de düzeni enjekte edebilirsiniz.

AndroidAnnotations uygulaması:

 @NoTitle @Fullscreen @EActivity(R.layout.my_layout) public class MyActivity extends Activity { @ViewById ListView customerList; // auto-binded to R.id.customerList @App MyApplication app; // auto-binded to app object @AminationRes Animation fadeoutAnimation; @UiThread void updateUI() { // main thread action } }

Son açıklama biraz daha fazla açıklama gerektiriyor: Çok iş parçacıklı bir Android uygulaması için ortak bir görev, arka plan (veya çalışan) iş parçacıklarından, UI bileşenlerine erişime izin veren tek iş parçacığı olan ileri (veya ana veya UI) iş parçacığına geçmektir. . Bu görev, karmaşık olmasa da genellikle gereklidir ve bazı karmaşık kodlamalar içerir:

 new Handler(Looper.getMainLooper()).post(new Runnable() { logic goes here } ); // NO ANNOTATIONS

AndroidAnnotations'da tek yapmanız gereken @UiThread ile işlevinize açıklama eklemektir ve artık her zaman yürütüleceği garanti edilmektedir:

 @UiThread void updateUI() {..} // WITH ANNOTATIONS

Bu açıklamanın standart Android bileşen sınıfları (etkinlikler, hizmetler vb.) için geçerli olduğunu unutmayın. Ama kendi sınıflarıma da açıklama eklemek istersem ne olur?

Burada, AndroidAnnotations, EBean yeni bir konseptiyle karşımıza çıkıyor. Tek yapmanız gereken @EBean kullanarak sınıfınızı bu şekilde işaretlemek ve hazırsınız:

 @EBean public class MyNonComponentClass { @SystemService NotificationManager notifManager; @Bean MyOtherClass dependency; @UiThread void updateUI() { // main thread work goes here } }

EventBus: Bileşenler Arası İletişim Kolaylaştı

EventBus kütüphanesi, Android geliştiricilerinin yıllardır peşini bırakmayan bir sorunu parkta bir yürüyüşe dönüştürüyor. Bileşenler arası iletişim hiç bu kadar kolay olmamıştı—sisteminizin herhangi iki parçası arasında iletişim kurmak için basit bir yayın/alt modeli kullanın.

Arka plan yoklama hizmetinizin artık onları değişiklik olaylarıyla beslemek için parçalarınızın farkında olması gerekmez.

EventBus kullanımı basittir.

a. Olay sınıfları oluşturun. Burada POJO'larla çalışmak en iyisidir:

 class NewUserEvent { String fullname; String address; String role; // add getters and setters }

B. Sınıfta olay işleme yöntemleri oluşturun—bu olaylara abone olmak istediğiniz herhangi bir sınıf:

 class MySubscriber { @Subscribe public void newUserHandler(NewUserEvent event) { // handle NewUserEvent } @Subscribe public void newUserHandler(AnotherEvent event) { // handle AnotherEvent } }

Ama hey, yarı deneyimli herhangi bir Android geliştiricisi bu noktada durup şunu sorar: Bu işleyicilerin iş parçacığı modeli nedir? Ve, örneğin, UI bileşeni erişimini içeriyorsa, bir işleyiciyi ana iş parçacığından çıkmaya zorlayabilir miyim? İyi soru…

Varsayılan olarak, tüm işleyici yöntemleri, EventBus'un kendisi tarafından tahsis edilen ve bakımı yapılan bir iş parçacığı havuzundan alınan bir çalışan iş parçacığında çalışır. Ana iş parçacığında çalıştırmak için bir işleyici yöntemine ihtiyacınız varsa, abonelik ek açıklamalarınızı aşağıdaki gibi genişletin:

 @Subscribe(threadMode = ThreadMode.MAIN) public void runOnMainThreadHandler(AnotherEvent event) { … }

Uyarı: Bu özelliği aşırı kullanmayın! Ana iş parçacığı üzerinde uzun süreli işlemler asla yapılmamalıdır ve hızlı işlemlerde bile dikkatli olun. Ana iş parçacığını ezmek, uygulamanızı yavaş, gergin ve temelde kullanıcılarınız için daha az eğlenceli hale getirmenin en kesin yoludur.

C. Abone sınıfınızın EventBus kayıt yaşam döngüsünü yönetin—yani, veriyoluna ne zaman bağlanıyor ve ne zaman bağlantısı kesiliyor? Bir aktivite için makul bir kayıt akışı şöyle olacaktır:

 class MySubscriberActivity extends Activity { @Override public void onStart() { super.onStart(); EventBus.getDefault().register(this); // START RECEIVING EVENTS HERE } @Override public void onStop() { EventBus.getDefault().unregister(this); // NO MORE EVENTS super.onStop(); } }

Yukarıdakiler elbette sadece bir örnektir. (Un)kayıt işlemini dilediğiniz yerde gerçekleştirebilirsiniz.

D. Ve son olarak, aslında bir olayı ateşleyin:

 EventBus.getDefault().post(new MyEvent(“I'm here”));

EventBus'u kullanma hakkında bilinmesi gereken daha çok şey var: çok noktaya yayın olayları (varsayılan davranış), yapışkan olayları kullanma, teslim dizileri, öncelikler ve daha fazlası. Ancak yukarıdakiler, bu basit ama güçlü teknolojiye başlamanız için yeterlidir.

OkHttp: Android'in Steroidlerdeki HttpClient'i

Android'in HttpClient'i bu şekilde yazılmalıydı. Çok basit, çok akıllı. OkHttp kitaplığı dahili olarak yeniden deneme döngüsü, yük otomatik sıkıştırma, Http/2 desteği, bağlantı havuzu oluşturma ve yanıt önbelleğe alma işlemlerini halleder, böylece gereksiz ağ erişimini önleyebilirsiniz.

OkHttp kullanımı zahmetsizdir.

Http POST:

 OkHttpClient client = new OkHttpClient(); MediaType JSON = MediaType.parse("application/json; charset=utf-8"); RequestBody body = RequestBody.create(JSON, json_str); Request request = new Request.Builder() .url(url) .post(body) .build(); Response response = client.newCall(request).execute(); return response.body().string();

Http GET:

 OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url(urls[0]) .build(); Response responses = client.newCall(request).execute(); String jsonData = responses.body().string();

OkHttp ayrıca asenkron ağ oluşturma, istek yönlendirme rota sorgusu, yerel önbellek sorgusu ve daha fazlası gibi faydalı özellikleri de destekler. Gerektiğinde bunları kullanmaktan çekinmeyin. Çoğu geliştirici, OkHttp'yi Android'in varsayılan HTTP istemcisi HttpURLConnection için daha akıllı bir yedek olarak kullanır. Aslında, bu projenin tamamı HttpURLConnection için özel bir çatal olarak başladı.

Sağlamlığını seviyorum; ağ katmanınıza hemen katkıda bulunuyor.

Picasso: Google'ın da Bunu Kullanmasının İyi Bir Nedeni Var!

Picasso, görüntü indirmeyi, önbelleğe almayı, yeniden boyutlandırmayı ve kırpmayı yönetmenin en basit ve en sağlam yoludur.

Bu açıklama:

 Picasso.with(context).load(url).resize(50,50).centerCrop().into(imageView)

Bunu sizin için yapacak:

• Uzak bir URL'ye bağlanın.
• Bir resim indirin.
• Sizin için de yöneteceği yerel bir LRU önbelleğinde saklayın.
• Orijinal görüntüyü belleğe yüklemeden önce yeniden boyutlandırın.
• Yukarıdakilerin hepsini Picasso tarafından yönetilen bir iş parçacığı havuzunda çalıştırın.
• imageView'ınızı doldurmak için yeniden boyutlandırılmış resmi kullanın.
• Gelecekteki herhangi bir çalıştırmadan önce, bir ağ gidiş dönüşünün gerçekten gerekli olduğundan emin olmak için yerel önbelleği kontrol edin.

Yukarıdaki görev dizisini oluşturmak, usta bir geliştirici için bile saatlerce çalışmayı gerektirir. Ve bu her şeyi hatırladığınızı varsayar. Ya yeniden boyutlandırma kısmını unuttuysanız?

Ortalama bir Android cihazında, bir uygulama 50 ila 60 Megabayttan fazla RAM almaz ve çoğu Android cihaz için piksel-bayt faktörü 4'tür. Bu, SD karttan 13 megapiksellik bir görüntü yüklemeye çalışmak anlamına gelir. 52 Megabayt RAM gerektirir. Başka bir deyişle, uygulamanız hemen çöker.

Bu, Picasso'nun gücünün sadece bir örneğidir. Medya yoğun eski bir projeyi optimize ederken/hata ayıklarken yaptığım ilk şeylerden biri, tüm görüntü yüklemelerini Picasso'ya geçirmek. Bu basit adımın uygulama kalitesi üzerindeki etkisine şaşıracaksınız.

Bu kitaplığın gücünün en güçlü kanıtlarından biri: Google'ın son iki yıldaki kendi Android kod örneklerinin çoğu, resim yükleme için Picasso'yu kullanıyor.

ActiveAndroid: ORM Sans Performans Yükü

Nesne ilişkisel haritalamanın kısaltması olan ORM, J2EE günlerinde popüler hale getirildi. POJO'larınızı ayrı alanlara dönüştürmek zorunda kalmadan bir veritabanında saklamanıza ve bir veritabanından almanıza olanak tanır.

yararlı mı? Çok fazla, herhangi bir SQL deyimini kodlamadan uygulamanızın büyük bir bölümünü yazmanıza izin verdiği için.

Aynı zamanda çok verimli. Eski günlerde, ORM platformları büyük ölçüde yansımaya güveniyordu ve yavaş olmalarıyla ünlüydü. ActiveAndroid de dahil olmak üzere modern platformlar çok daha hızlıdır ve çoğu pratik gereksinim için ham SQL kodlaması üzerindeki performans yüklerinden etkilenmeyecektir.

Kullanım:

a. Özel bir Application sınıfını genişleterek uygulama nesnesinde başlatın:

 public class MyApplication extends extends com.activeandroid.app.Application { … }

B. Veritabanında saklamayı planladığınız kayıtların her biri için sınıflarla bir model sınıfı için türetilen POJO oluşturun. Bu tür POJO'ların her biri kendi tablosunda bulunabilir. Ek açıklamalar, depolanan her üye için DB alanlarının adını belirtmek için kullanılmalıdır:

 @Table(name = "Categories") public class UserDetails extends Model { @Column(name = "Name") public String name; @Column(name = "Address") public String address; @Column(name = "Age") public int age; }

Bir üye için bir dizin ayarlamak isterseniz, aşağıdaki açıklamayı kullanın:

 @Column(name = "ID", index = true) public String userID;

C. Kitaplığın, varsayılan davranış olan en klas başlangıç ​​zamanınızın tümünü yinelemesini önlemek için, aşağıdaki bildirim bölümünde tüm model sınıflarınızı belirtmeniz önemle tavsiye edilir:

 <meta-data android:name="AA_MODELS" android:value=“com.myapp.MyModelA, com.myapp.MyModelB" />

Not: Bu listede görünmeyen model sınıfları ActiveAndroid tarafından tanınmayacaktır.

D. Veritabanına yaz:

 UserDetails usr = new UserDetails(); usr.save(); // RUNS ON A BACKGROUND THREAD

Birden çok yazma gerekiyorsa, bunları tek bir işlemde toplu hale getirmek daha verimli bir yol olacaktır:

 ActiveAndroid.beginTransaction(); try { for (UserDetails u: userList) item.save(); ActiveAndroid.setTransactionSuccessful(); } finally { ActiveAndroid.endTransaction(); }

e. POJO'ları veritabanından okuyun:

 new Select() .from(UserDetails.class) .where("name = ?", usr.getName()) .orderBy("Age") .executeSingle();

ORM, sunucu tarafı geliştiricisi olarak günlerimde sahip olunması gereken bir araçtı. Android alanına biraz geç girdi. Ama sonunda, işte burada: olabildiğince basit veritabanı programlaması. Tadını çıkar.

LibStreaming: Ağrısız Video Akışı

Belgelenmemiş API'ler, çapraz SDK sürüm farklılıkları, yansıma kullanımı ve daha fazlası nedeniyle gerçek zamanlı video akışı eskiden büyük bir sorundu.

Neyse ki, libStreaming, akış karmaşıklıklarının çoğunu içine alarak ve birkaç saat içinde basit bir akış uygulaması yazmanıza olanak tanıyan basit ve kullanıcı dostu bir API sunarak tüm bunları değiştirdi.

H.264 ve AAC için kullanmak için aşağıdakileri yapmanız gerekir:

a. Ana etkinliğinizin onCreate yönteminde bir oturum nesnesini başlatın. Oturum nesneleri, bir eşe medya akışını temsil eder:

 protected void onCreate(Bundle savedInstanceState) { mSession = SessionBuilder.getInstance() .setCallback(this) .setSurfaceView(mSurfaceView) .setPreviewOrientation(90) .setContext(getApplicationContext()) .setAudioEncoder(SessionBuilder.AUDIO_NONE) .setAudioQuality(new AudioQuality(16000, 32000)) .setVideoEncoder(SessionBuilder.VIDEO_H264) .setVideoQuality(new VideoQuality(320,240,20,500000)) .build(); mSurfaceView.getHolder().addCallback(this); }

B. Aslında oturumu başlatın:

 mSession.setDestination(destination_server_url); mSession.start();

C. Tamamlandığında oturumu durdurun:

 mSession.stop();

Şimdi lütfen yanlış anlamayın. Gerçek zamanlı akış doğası gereği dağınıktır ve libStreaming bu karmaşıklığı ortadan kaldırmaz. Ancak, çoğu zaman bunu sizden saklamak gerçekten iyi bir iş çıkarıyor. Bazı durumlarda, eş sinyalleme politikasını seçerken, kamera kodlamasını seçerken (genellikle MediaCodec/yüzeyden arabelleğe kullanmak istersiniz) veya paketleme ile uğraşırken olduğu gibi karmaşıklıkla uğraşmanız gerekecektir.

Yine de, libStreaming'in arkasındaki iyi adamların, bu karmaşıklıkları sorunsuz bir şekilde kullanımı kolay bir API'de birleştirmek için ekstra yol kat ettiğini göreceksiniz.

LibStreaming, H.264, H.263, AAC ve AMR dahil olmak üzere Android uygulamaları tarafından kullanılan çoğu kodlayıcıyı destekler.

Bu kütüphane ile harika sonuçlar elde ettim. En popüler akış uygulamalarından bazıları onu altyapısının bir parçası olarak kullanır. İhtiyaçla karşılaşırsanız, medya akışı deneyiminizi çok daha sorunsuz hale getireceğinden eminim.

LeakCanary: Bir Kod Satırında Bellek Sızıntılarını Tespit Edin

Bu kitaplığın arkasındaki motivasyonla başlayalım: bellek sızıntıları . Özellikle kodlama konusunda dikkatli değilseniz, Android uygulamaları bunlara eğilimlidir. Aslında, bellek sızıntıları oluşturmak çok basittir. Yapmanız gereken tek şey, bir aktivite referansını bağlamının dışında saklamaktır. Aslında, faaliyet bağlamının dışında tek bir görünüm nesnesine bir referans depolamak bile bir sızıntı oluşturacaktır.

Niye ya? Çünkü bir görünüm—aslında tüm görünümler—içerdiği etkinliğe yönelik bir bağlam referansını dahili olarak depolar. Görünüme yapılan bir referans tutulduğu sürece, onun içerme etkinliği - çekmeceler, görünüm hiyerarşisi ve kaynaklar dahil olmak üzere içindekilerle birlikte - çöp toplayıcı tarafından geri alınamaz.

Sızdıran bir aktiviteye referans tutmak, her zaman statik bir parametre olarak açık değildir. Bir iç sınıf oluşturduğunuzda veya bir aktivitenin içinde bir iş parçacığı oluşturduğunuzda, o aktiviteye bir referans oluşturulur ve aktivite, o iç sınıf veya iş parçacığı tamamlanana kadar geri alınamayabilir.

Tek bir kaynak yoğun etkinliğe referans sızdırmak bazen uygulamanızı bir " Yetersiz bellek " istisnasıyla çökertmek için yeterlidir.

Onlara karşı nasıl korunabilirsiniz? Elbette titiz kodlama uygulamalarıyla başlayın. Ancak hepimiz deneyimli Android geliştiricileri değiliz ve deneyimli geliştiriciler bile bazen kuralları unutuyor.

Bellek sızıntılarına vurgu yapan periyodik kod incelemeleri yardımcı olabilir, ancak zaman alır. Ayrıca, bazı sızıntılar gerçekten gizlidir ve yalnızca kod incelemesiyle tespit edilmesi zordur.

DDMS'nin bellek aracını kullanmak, zaman içinde uygulamanızın sızıntı yapıp yapmadığını anlamanın harika bir yoludur. Kesinlikle kullanmalısın. Ancak, sızıntıya neyin neden olduğunu size söylemez.

İşte kaçak Canary kurtarmaya geliyor. Piyasadaki en iyi bellek sızıntısı algılayıcısıdır ve tüm faaliyetleriniz için bir veya iki satır kodda olduğu gibi otomatik sızıntı algılama sağlar.

Bunu kullanmak için, uygulamanızın onCreate() nesnesiyle LeakCanary'yi başlatmanız yeterlidir:

 public class MyApp extends Application { @Override public void onCreate() { super.onCreate(); LeakCanary.install(this); // more initialisations } }

Ve işin bitti. LeakCanary, bellek sızıntılarını izleyecek ve bir tespit ederse bir bildirim gönderecektir.

LeakCanary, tüm etkinliklerinize ActivityRefWatcher adlı bir nesneyi otomatik olarak enjekte ederek ve onDestroy() çağrıldıktan sonra ref sayılarını izleyerek bu sihri başarır. Yok edilen bir aktivitede A > 0 referans sayısı yalnızca bir sızıntı anlamına gelebilir.

Önemli: Sızıntı tespiti yalnızca hata ayıklama modu uygulamaları için çalışır. Bir sürüm modu APK'sında asla sızıntı testi yapmayın (LeakCanary ile değil).

Ama ya sistemimin diğer kısımlarını sızıntılara karşı test etmek istersem? Burada, LeakCanary, aslında başlatma çağrısının dönüş değeri olan refWatcher adlı bir nesne sunar:

 refWatcher = LeakCanary.install(this);

Yakında geri kazanılacak değerleri izlemek için kullanılabilir. Daha doğrusu, yakında geri kazanılacağını düşündüğüm değerler. Bunu yapmak için arayın:

 refWatcher.watch(my_soon_to_be_reclaimed_obj);

Kütüphane, izleme çağrısından kısa bir süre sonra bu nesnenin serbest bırakılmadığını size bildirecektir.

Bu “kısa süre”nin değerini hiçbir yerde bulamadım ama muhtemelen o kadar da önemli değil. LeakCanary ile işler yolunda gider. Paha biçilemez.

Özet

Deneyimli geliştiriciler, bu kitaplıkları kullanarak kodlama ve hata ayıklama aşamalarını günler ve haftalar boyunca keser, bu nedenle aynısını yapmamanız için hiçbir neden yoktur.

Özetlemek gerekirse, benim seçtiğim Android kitaplıkları sizin için şunları yapabilir:

• ButterKnife – Otomatik enjekte edilen kod, uygulamanızın ortak kod kodunun çoğunu ortadan kaldırmanıza yardımcı olur. Android için nihai kod enjeksiyonu. Daha da anlatmalı mıyım?

• AndroidAnnotations – Elle kodlanmış mantığa göre performans cezası olmadan zamandan tasarruf etmek için son derece hızlı otomatik oluşturulan sınıfları ve ad tabanlı kod enjeksiyonunu kullanın.

• EventBus – Daha sağlam kod için bileşenleri ayırın, bileşenler arası iletişim hiç bu kadar kolay olmamıştı.

• OkHttp – Asenkron ağ iletişimi, istek yönlendirme rotası sorgusu, yerel önbellek sorgusu ve daha fazlasını destekleyen HttpURLConnection için akıllı bir alternatif.

• Picasso – O kadar iyi ki akıcı görüntü işleme artık Google tarafından kullanılıyor. Medya ağırlıklı projelerde ve belirli eski projelerde büyük bir zaman tasarrufu sağlar.

• ActiveAndroid – ORM, performans yükü olmadan kolaylaştı.

• LibStreaming – Büyük akış uygulamaları tarafından kullanılan gerçek zamanlı video akışı.

Bunlar zaman ayırmaya değer tek Android kitaplıkları mı? Kesinlikle değil. Ama size söz veriyorum: Bir sonraki projenizde bunlardan herhangi birini kullanmak sizi çok daha iyi bir geliştirici yapacak. Onları çalışırken görmek istiyorsanız GitHub'a bir göz atın.

Halihazırda bunların bir kısmını veya tamamını kullanıyorsanız veya alternatif kütüphaneler kullanıyorsanız, deneyimlerinizi aşağıdaki yorumlarda paylaşmanızı rica ediyorum.