8 Kasım 2013 Cuma

Android Kitkat'la gelen en önemli yenilik: ART!

Merhaba,

Android 4.4 Kitkat'ın akıllı cihazlarda kullanılabilir hale gelmesine yakın bir süre kala herkesin gözü yeni özelliklerin neler olduğuna kilitlenmiş durumda. Yazıcı desteği, daha kullanışlı ve etkili yeni efektli geçişler (transitions), tam ekran kapsama modu (full screen immersive mode), hafıza kullanımını analiz eden araçlar, vs... Tamamını buradaki videodan öğrenebilirsiniz. Geneli kitkat'ın kimliğini açıklar nitelikte ancak burada bahsedilmeyen bir özellik daha var: ART!

ART nedir? Neden daha etkili? Nasıl çalışıyor?
2 yıllık gizli bir çalışmanın sonucunda Kitkat ile android kullanıcılarının hizmetine sunulacak olan ART, ilk izlenimlere göre -her ne kadar birlikte çalışma imkanları olsa da- dalvik'in koltuğuna göz dikiyor gibi. Daha hızlı ve verimli çalışacak uygulamalar ile daha uzun pil ömrü de ilk vaatlerinin arasında. Peki neye dayanarak? Belirtildiğine göre ART'ta çalışma zamanında uygulamanın yürütülme süreci (execution handling) Dalvik'teki mekanizmadan tamamen farklı. Bilindiği üzere Dalvik'teki mantık bir JIT compiler desteği ile bytecode'un bir dalvikbytecode'a (dex) çevrilmesi şeklinde ilerliyordu. Geliştirici önce uygulamanın bir kısmını derler (compile eder) ortaya bir apk formatında veri çıkar daha sonra uygulama her çalışacağı sırada mutlaka cihaz tarafından tekrar bir yorumlama sürecinden daha geçirilirdi (ya da geçirilir diyelim şu an ki sistem bu şekilde işliyor çünkü). Bu tekrar tekrar yorumlama hadisesi, hem sürece ek bir yük getirmekte hem de kısmen verimsiz sayılabilmekteyken uygulamanın çeşitli donanım ve mimarilerde daha kolay çalışabilmesini sağlama avantajı bu olumsuz etkileri gözardı etmemize neden oluyordu. ART işte bu noktada, bu süreci uygulama ilk yüklendiğinde bytecode'un direk makine diline compile edilmesini sağlayarak tamamen farklı bir temel üzerinden hareket etmekte ve sonucunda uygulamaları tamamen native hale getiren bir hizmet sunmakta. Bu sürece Ahead-Of-Time Compilation (AOT) adı veriliyor. AOT ile sanal makinenin veya kodun yorumlanması süreci ortadan kaldırılarak açılış ve çalışma süresi çok yüksek oranda artmış oluyor.


Ne kadar daha iyi?
Şu an için Kitkat ile gelecek ilk ART versiyonunda ne gibi verimli kazanımlar olacak ölçümlemek kolay değil dolayısıyla kullanımı yaygınlaşmadan temsili rakamlar söylemek de pek mümkün değil ancak yine şimdiye kadar yapılan testlerde bir çok uygulama için yürütme (execution) sürecinin 2 kat hızlandığı yönünde iddialar mevcut. Bu da demek oluyor ki hem uzunca çalışan ve işlemciyi yoğun düzeyde kullanan işlemler (task) daha hızlı tamamlanacak hem de normal uygulamalardaki dokunma, diğer sensörlere dayalı işlemler veya animasyon gibi olaylar daha hızlı ve göze hoş hale gelmiş olup işlemcinin daha az çalışması sonucu pil ömrü de uzamış olacak.

Dezavantajları neler?
Elbette AOT'un da bazı dezavantajları var fakat getirdiği faydalar yanında bunlar gayet önemsiz kalır nitelikte. Bunlardan ilki her ne kadar çok önemli boyutlarda olmasa dahi (tahminen uygulama başına %10-%20 arası) depolama biriminin daha kolay dolacağı çünkü tümüyle makine koduna çevrilerek derlenmiş kod bytecode'dan daha fazla yer kaplamış olacak. (Bunun nedeni bytecode içindeki her sembolün makine kodunda birden çok komutu temsil edebiliyor olması). Kafalarda APK'ların boyutlarının belirttiğimiz oranda artacağı düşüncesi doğabilir bu noktada şunu hatırlatmakta fayda var depolama birimindeki artıştan bahsederken uygulamanın sadece kod tarafında olacak bir artıştan bahsediyoruz. Örnekle Google+'ın son apk'sının boyutu 28.3MB fakat bunun yalnızca kod kısmı 6.9MB. Bir diğer dezavantaj ise yükleme süresi sorunsalı. Ne kadar uzayacak? Aslına bakılırsa bu da yine uygulamanın boyutuna göre değişecek. Ufak çaplı uygulamalar yüksek ihtimal hiç etkilenmeyecek ancak facebook veya google+ gibi daha yüksek ve karmaşık yapıdaki uygulamalar sizi biraz bekletecek gibi gözüküyor. Ayrıca ART'ı kullanmak için yapacağınız ilk geçişte cihazınızdaki uygulama sayısının çokluğu sizi birazcık sabır imtihanına maruz bırakabilir.

Sonuç
ART her ne kadar heyecan verici ve android team için tünelin ucundaki ışık gibi görünse de henüz ses getirecek lansmanının yapılmamasının bazı nedenleri var. Google hala bu oluşuma deneysel bir yenilik gözüyle bakıyor ve daha da önemlisi sistemin stabil çalışıp çalışmaması konusunda kesinlik yok. ART'ı denemek için Ayarlar > Geliştirici Seçenekleri > Çalışma zamanı ekranına gidip ART'ı işaretleyebilirsiniz. (Bilginiz olsun, bu süreç tüm yüklü uygulamalarınızı ART'a hazırlamak için 10 dakikaya yakın bir süre gerektirebilir.) 

8 Nisan 2012 Pazar

Farklı projelerde JAR library'de tanımlanmış android resource dosyalarını kullanmak

Merhaba, uzun bir aradan sonra yeni bir makaleyle tekrar beraberiz. Başlık biraz garip oldu ama anlatmak istediğim şeyi daha farklı nasıl yazarım bilemedim. Problemimiz şu: Farklı projelerde kullanmak amacıyla kendi library'inizi (jar dosyanızı) oluşturduğunuzu varsayalım. Eğer paket içinde herhangi bir android resource dosyası mevcutsa maalesef bu kütüphaneyi import ettiğinizde hata ile karşılaşacaksınız. Bunun nedeni resource dosyalarının final static olarak tanımlanması ve her projenin "R"esource'unun diğerlerinden farklı olmasından kaynaklanmaktadır. Hemen basit bir örnek.

Diyelim ki kütüphanenizde showToast adinda kendinize özel geliştirdiğiniz bir method var. Bu method adından da anlaşılacağı üzere kullanıcıya mesaj vermek için oluşturduğunuz bir method. Gösterilen mesajda öyleya sadece strings.xml resource'unda tanımlı MESAJ_DESC adındaki parametreye ne tanımlanmışsa onu gösteriyor diyelim. Doğal olarak istediğiniz şey, bu kütüphaneyi kullandığınız her projede strings.xml'deki MESAJ_DESC parametresini özelleştirebilmek olacak. Ancak MESAJ_DESC parametresinin ID'sinde bulunan değer, kütüphanenin oluşturulduğu projenin Resource dosyasında neyse her zaman o olacağından uygulama MESAJ_DESC parametresini bulamayacak, hata verecek ve bu library'i kullanamayacaksınız. İşte bu gibi durumlarda aşağıdaki method ile bu problemin önüne geçmeniz mümkün.
public static int getResourceIdByName(String packageName, String className, String name) {
   Class r = null;
   int id = 0;
try {
    r = Class.forName(packageName + ".R");

    Class[] classes = r.getClasses();
    Class desireClass = null;

    for (int i = 0; i < classes.length; i++) {
        if(classes[i].getName().split("\\$")[1].equals(className)) {
            desireClass = classes[i];

            break;
        }
    }

    if(desireClass != null)
        id = desireClass.getField(name).getInt(desireClass);
} catch (ClassNotFoundException e) {
    e.printStackTrace();
} catch (IllegalArgumentException e) {
    e.printStackTrace();
} catch (SecurityException e) {
    e.printStackTrace();
} catch (IllegalAccessException e) {
    e.printStackTrace();
} catch (NoSuchFieldException e) {
    e.printStackTrace();
}
return id;
}
Kullanımı için
int id = getResourceIdByName(context.getPackageName(), "string", "showToast");
(Kaynak: http://stackoverflow.com/questions/1995004/packaging-android-resource-files-within-a-distributable-jar-file)