Home Türkçe Xamarin.Android : Şapkadaki Tavşan

Xamarin.Android : Şapkadaki Tavşan

by Fatih Boy
5 comments

   Xamarin makalelerine son hızla devam ederken şöyle bir bakınca dördünce makaleye gelmişiz bile. Son makalemde sizlerle arka planda gerçekleşenleri, mimariyi paylaşmıştım. Buna biraz daha devam etmek faydalı olacaktır. Makalelerde en zorlandığım şey başlığı seçmek; madem bir öncekinde sihirbazın sırrı dedik, içeriği nedeniyle buna da benzer bir şey seçmek nedense çok mantıklı geldi 😉

   Bu makalemde de yine sizinle Xamarin.Android mimarisi ile ilgili detayları paylaşacağım; ama bu defa uygulama paketlerimiz, APK’lar, hakkında…

Archive-zip   Daha öncede belirtmiştim, Xamarin.Android tarafından üretilen apk paketleri de aynı diğer Android paketleri gibi aslında zip dosyalarıdır. APK dosyası sıkıştırılmamış IL assembly’leri, çalışılan platforma özel Mono çalışma zamanı (armeabi, armeabi-v7a, x86 v.b.) ve Android işletim sisteminin uygulamayı başlatabilmesi için gerekli Android Callable Wrapper’lardan oluşmaktadır. Bu bilgi her ne kadar doğru olsa da eksik. Xamarin.Android apk’ları release modunda bu şekilde bir yapıya sahiptir. Peki debug modunda derlendiğinde fark ne? Öncelikle gelin debug ve release modunda derledikten sonra çıktı klasörleri neye benziyor bir görelim;

Debug Klasörü;

Debug Klasörü

Release Klasörü;

Release Klasörü

   Hemen dikkatinizi çekecektir, iki klasördeki APK dosyalarının boyutları farklı, hem de oldukça farklı…

  Bu farklılık Xamarin.Android’in mimarisi ve debug sürecinin optimizasyonu ile alakalı. En baştan, Android işletim sisteminde C# kodlarımızın Mono çalışma zamanı üzerinde çalıştığı kabul edelim ve bu çalışma zamanının Android işletim sisteminde varsayılan olarak bulunmadığını unutmayalım. Bu durumda Mono çalışma zamanının Android’de bulunabilmesinin tek yolu, kaçınılmaz olarak, onu uygulamamızla birlikte paketleyerek dağıtmak olacaktır. Dolayısıyla bir kaç kilobyte’lık bir uygulama bile yapsak bunu release modunda derleyip dağıtacağımız zaman paketimizin boyutu anında bir kaç megabyte’ı bulabiliyor.

  Ok, detaylarına daha sonra inmek kaydıyla, release modundaki paketimizin boyutunun böylesine büyük olmasını bir önceki satırda açıkladık. Peki debug modunda oluşan paket neden bu kadar düşük boyutlu?

  Bunun cevabı aslında “Merhaba” makalesinde saklı. Hatırlarsanız oluşturduğumuz emulator’de ilk kez hata ayıklama oturumu başlatılırken öncelikle Mono Shared Runtime’ın ve API versiyonuna bağlı kurulumun yapıldığından bahsetmiştim. Bir kerelik kurulan bu Shared Runtime ve Shared Platform paketleri, içerisinde uygulamamızın bağımlı olduğu Mono çalışma zamanı ile BCL’i (Base Class Library-Temel sınıf kütüphanesi) barındırmaktadırlar. Dolayısıyla da debug paketimizide/APK’mızda bunların bulunmasına gerek kalmıyor. Bu durum, paket boyutunda önemli bir düşmeye sebep olmasının yanında paketin emulator’e atılarak hata ayıklama oturumunun başlatılmasını da önemli ölçüde hızlandırmakta.

   İki paket arasındaki bu farkın nedenini netleştirebildiğimi umuyorum. Şimdi yeniden release paketine dönelim; çünkü burada olup biten başka optimizasyonlar da söz konusu.

Trash   Release paketinden bahsederken, içerisinde Shared Runtime ve Shared Platform paketlerinin içeriklerinin bulunduğundan bahsetmiştim. Sizin de tahmin edebileceğiniz gibi tüm Mono paketi ve kütüphanelerinin kullanıldığı bir uygulama çok nadir, hatta hiç yoktur. Dolayısıyla da hepsinin kullanılmasalar bile uygulamamızla birlikte dağıtılmasına hiç gerek yok. Şanslıyız ki Xamarin.Android geliştiricileri de bizimle aynı fikirdeler ve bunun için de yaptıkları optimizasyonlar söz konusu. Relase paketi için derleme sırasında yapılan Link işlemi doğrudan kullanılmayan tüm kodları kaldırır. Bu durumu Xamarin’inin de deyimiyle Garbage Collection işlemi sırasında heap-allocated memory (Türkçesi denir bilemedim 🙂 ) için yapılan işleme benzerdir; ama işlem nesnelerle gerçekleştirilir ve kodunuz üzerinde yapılır. Dolayısıyla da bu optimizasyon sonucunda doğrudan kullanılmayan kodlar temizlenerek daha düşük boyutlu bir paket ortaya çıkar. Şüphesiz ki BCL kütüphaneleri de bu temizliğe tabidirler. Tabi bu açıklama arkasından eminim ki fark etmişsinizdir; BCL’den kullandığınız her bir kod ile birlikte paketiniz biraz daha büyüyebilir…

Şu Yazıları da Sevebilirsiniz

5 comments

ibrahim 3 Haziran 2013 - 21:53

bu konuda bu kadar hızlı ve doğru bilgiye ulaşmamızı sağladığınız için ayrıca teşekkürler.

Reply
Mahmut 23 Haziran 2013 - 23:46

Merhaba Fatih bey öncelikle yazınız için çok teşekkürler giriş mahiyetinde çok iyi oldu.
Acaba bu konuda ilgi dersler yapmayı ve bunları paylaşmayı düşünüyormusunuz (türkçe kaynak için).. Takip deyim

Reply
Fatih Boy 24 Haziran 2013 - 21:06

Merhaba Mahmut, şu an için bu konuda makalelerimle Türkçe içerik sunmaya devam etmeyi planlıyorum. Doğrusu ders konusu pek aklımda yok; ama olursa duyuracağıma emin olabilirsin.

Reply
Abdurrahman GUREL 27 Haziran 2013 - 23:19

Fatih Bey yazı dizinizi dikkatle takip ediyorum. Öncelikle teşekkürler.
Merak ettiğim bir konu var. Xamarin ile geliştirdiğimiz android uygulamalar, normal olarak geliştirdiğimiz android uygulamalardan daha mı yavaş çalışır ? Bu konuda çok fazla söylenti duydum ancak net bir bilgi bulamadım. Açıklayabilirseniz sevinirim.

Reply
Fatih Boy 29 Haziran 2013 - 22:02

Merhaba Abdurrahman,
Bu aslında cevabı zor bir soru; çünkü ortada çok fazla test sonucu yok. Xamarin tarafından olaya baktığımızda yazılan kodlar doğrudan native binary haline dönüştürülmekte ve sadece kodumuzun üzerine eklenen 2.5mb’lık bir ek bulunmakta (bknz. : http://xamarin.com/faq#q3). Dolayısıyla da performans açısından standart bir uygulamadan farksız olmalı. Öte yandan pek çok kullanıcı yaptığı testlerde Intel platformlarında Xamarin.Android’in java uygulamalarından daha performanslı çalıştığını; fakat ARM platformunda durumun tam tersi olduğunu söylemekte. Bu noktada yapılan testlerin detayını bilmediğim için karşılaştırmaların ne kadar gerçekçi olduğunu söylemek zor; ama Mono tabanlı olması nedeniyle Xamarin.Android’in Intel tabanlı sistemler daha performanslı olması bana mantıklı geliyor.

Reply

Leave a Comment

* Bu formu kullanarak, verilerinizin bu web sitesi tarafından saklanması ve kullanılmasını kabul ediyorsunuz.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Bu web sitesi deneyiminizi geliştirmek için çerezleri kullanır. Bunu kabul ettiğinizi varsayacağız, ancak isterseniz vazgeçebilirsiniz. Kabul Et Daha Fazla Bilgi