Dosya yapısı android. Android sistemlerinin iç cihazı

Dosya sistemi os android

dolayısıyla, bu makalede, başlıktan tahmin ettiğiniz gibi, genel yapı hakkında konuşacağız. dosya sistemi  android. Ana dizinlerin tanımı, biçimlendirme yöntemleri, yedekleme  Bu yazı özellikle yeni başlayanlara yöneliktir. Umarım geri kalanını okumak ilginç olacaktır.
linux dosya sistemi yapısı

android, normal disklerin çoğuna sahip değildir - örneğin, veya d. Dosya sistemimizin kökü: "". diğer tüm dizinler kök dizine eklenir. Bunlardan bazılarını düşünün:

sistem- ismine göre, sistem dosyalarının burada bulunduğunu tahmin edebilirsiniz (işletim sistemlerinde Microsoft c: windows'dan gördüğümüz gibi). Bu klasördeki dosyalar varsayılan olarak değiştirilemez. İşletim sisteminin çalışması için tasarlanmıştır. Ayrıca burada işletim sistemine yerleşik yerleşik uygulamalar da bulunmaktadır. Kök haklarımız olursa, bu dizinde değişiklik yapabiliriz. Ancak, bunun için dikkatlice yapılmalıdır silinmiş dosyalar  ve klasörler kendiliğinden kurtarılmaz. Bu durumda, sadece bir yanıp sönme veya yedekleme bize yardımcı olacaktır. Klasörde ilginç bir şey bulunabilir systemmedia. Arşivde bootanimation.zip  Cihaz açıldığında animasyonu oluşturan resimler var. Ayrıca bir dosyayı sistem klasörünün kökünde de bulabilirsiniz. build.prop  cihazın açıklamasından ekranın yoğunluğuna kadar birçok ayar içerir (bu yapılandırmayı yapılandırmak için birçok üçüncü taraf uygulamaları).ekran görüntüsü

veri  - Sistemlerin aksine, depolanan dosyalar burada saklanır. Kategoriler altında uygulamanın  Sadece bizim tarafımızdan yüklenen apk programlarını sakladı. ekran görüntüsü

Herhangi bir uygulamanın bir apk dosyasına ihtiyacımız olursa, o zaman kolayca orada bulabiliriz. Ve içinde datadata  bunların verileri yüklü programlar.
mnt  -Bu bölümde, kullanıcı hafızası takılıdır (örneğin bir flash kart taktıysanız). Böylece, eğer txt dosyamızı flash kartın kök dizinine yerleştirirsek, tam yol şöyle görünür " mntsdcard dosyası". Hafıza kartlarını desteklemeyen akıllı telefonlar için dahili disk de buraya monte edilmiştir. ekran görüntüsü

Android silmek (reset) nasıl yapılır

biçimlendirmenin birkaç yolu var. Aşağıdakilerin birkaçı hakkında
1. ayarları ile sıfırlayın. Ayarlar \u003e\u003e geri yükle ve sıfırla \u003e\u003e ayarları sıfırla seçeneğine gidin. Tüm ayarları temizler ve seti ile kaldırır. Bundan önce, ilgili öğeyi işaretleyerek bazı ayarları yedekleyebilirsiniz. Yeniden başlatmanın ardından, cihaz bu verilerin geri yüklenip yüklenmeyeceğini soracaktır.
ekran görüntüsü

2. Kurtarma yoluyla sıfırlayın.  Cihaz açılmadığında faydalıdır. Kök erişimine ve uygun şekilde kurulmuş bir kurtarma işlemine ihtiyacınız olacak. Yüklenen kurtarmaya bağlı olarak, öğelerin konumu değişebilir. Bir noktadan ileri silme var. Bu içerir:
dalvik önbellek  - önbellek biçimlendirme sanal makine  Dalvik.
sistem- sistem bölümünü biçimlendirme.
veri  - Cihazın hafızasındaki tüm üçüncü taraf uygulamaları ve ayrıca kullanıcı ayarlarını sil.
önbellek - önbellek kaldırma
sdcard formatı  - hafıza kartını biçimlendirme. Hafıza kartındakileri silin.
sd-ext formatı- hafıza kartındaki bölümün biçimlendirilmesi (eğer böyle bir bölüm oluşturulmuşsa. Örneğin, karta takıldığında yönlendirme uygulamasının komut dosyasını eklemek için).
3. Servis kodunu kullanarak biçimlendirme.  Çevirirseniz * 2767 * 3855 #. Çevirme işleminden hemen sonra, sıfırlama gerçekleşir. Dikkatli ol.
Örneğin, bir klasörün içeriğini silmek datadata  ayarları ve uygulama verilerini kaldıracağız ancak uygulamaların kendileri değil. Bu aynı zamanda "verileri sil" uygulamasının ayarlarından da yapılabilir. Klasörü sildiğinizde tarih silinir. yüklü uygulamalar.
Dilek, değişiklik, yazıya eklemeler, lütfen yorumlarda veya bana kişisel olarak bırakın. makale eklenmiş olacak. Teşekkürler okuyucular, başarı.
-----------------
  Makale Kataloğu bölümünde yorum bırakabilirsiniz. ara katman, yüksek verimlilik gerektiren yaygın sorunları çözmek için tasarlanmış bir kütüphaneler kümesidir (Kütüphaneler). Diğer bir deyişle, daha yüksek seviyeler için uygulanan algoritmalar sağlamak, dosya formatlarını desteklemek, bilgileri kodlamak ve kod çözmek (örneğin, multimedya kodekleri), grafik çizmek ve çok daha fazlası bu seviyededir. Kütüphaneler C / C ++ dilinde uygulanmakta ve belirli bir bölüm için derlenmektedir. donanım  Üretici tarafından önceden kurulmuş biçimde tedarik edildikleri aygıtlar.

İşte bazı düşük seviyeli kütüphaneler:

1. Yüzey Yöneticisi - Android işletim sistemi Compiz (Linux) gibi bir kompozit pencere yöneticisi kullanıyor, ancak daha ilkel. Grafikleri doğrudan ekran arabelleğine çekmek yerine, sistem gelen çizim komutlarını dışa aktarma arabelleğine gönderir, burada başkalarıyla birlikte toplanır, belirli bir kompozisyon oluşturur ve ardından ekranda kullanıcıya gösterilir. Bu, sistemin ilginç kesintisiz efektler oluşturmasına, pencere şeffaflığını ve yumuşak geçişleri gerçekleştirmesine olanak sağlar.
2. Medya Çerçevesi - PacketVideo OpenCORE temelinde uygulanan kütüphaneler. Yardımları sayesinde sistem ses ve video verilerini kaydedebilir ve oynatabilir, ayrıca statik görüntüler çıkartabilir. MPEG4, H.264, MP3, AAC, AMR, JPG ve PNG dahil olmak üzere birçok popüler biçim desteklenir. Gelecekte, OpenCORE daha basit bir çerçeve olan Stagefright ile değiştirilecektir.
3. SQLite, Android'de ana veritabanı motoru olarak kullanılan hafif ve üretken bir ilişkisel veritabanı motorudur.
4. 3B kitaplıklar - mümkünse donanım ivmesini kullanarak, 3B grafiklerin son derece optimize çizimi için kullanılır. Bunların uygulamaları OpenGL ES 1.0 API'sini temel almaktadır.
5. FreeType, bitmaplerle çalışmak ve yazı tiplerini rasterleştirmek ve üzerinde işlem yapmak için kullanılan bir kütüphanedir. Yazı tipleri ve metin gösterimi için yüksek kaliteli bir motordur.
6. LibWebCore - Masaüstünde de bilinen tarayıcı tarayıcı WebKit'in kütüphaneleri google tarayıcıları  Chrome ve Apple Safari.
7. SGL (Skia Graphics Engine) - 2D grafiklerle çalışmak için açık bir motor. Grafik kütüphanesi Google’ın bir ürünüdür ve genellikle diğer programlarında kullanılır.
8. SSL - OpenSSL'ye dayalı olarak aynı şifreleme protokolünü destekleyen kütüphaneler.
9. libc, küçük aygıtlar için glibc'in (Linux'tan GNU libc) bir analoğu olan standart C dil çağrıları kütüphanesidir. Biyonik denir.

Şek. 1.5.

Aynı seviyede Android Çalışma Zamanı - uygulama çalışma zamanı ortamı. Temel bileşenleri, standart kütüphaneler kümesidir ve sanal makine Dalvik. Android işletim sistemindeki her uygulama Dalvik sanal makinesinin kendi kopyasında çalışır. Böylece, çalışan tüm işlemler işletim sisteminden ve birbirlerinden izole edilir. Android Çalışma Zamanının mimarisi, programların çalışmasının kesinlikle sanal makine ortamı çerçevesinde gerçekleştirileceği şekildedir. Bu nedenle, işletim sisteminin çekirdeği diğer bileşenlerinden gelebilecek zararlardan korunmaktadır. Bu nedenle, hata veya kötü amaçlı yazılım içeren kod Android işletim sistemini ve buna bağlı aygıtı bozamayacaktır. Böyle bir koruyucu işlev, program kodunun yürütülmesiyle birlikte, Android Çalışma Zamanı için anahtarlardan biridir.

Yukarıdaki seviye, bazen uygulama çerçevesi seviyesi olarak adlandırılan Uygulama Çerçevesidir. Geliştiricilerin düşük seviye sistem bileşenleri tarafından sağlanan API'ye erişebildiği uygulama çerçeveleri aracılığıyla gerçekleştirilir. Ek olarak, çerçeve mimarisi sayesinde, erişimine izin verilen diğer uygulamaların zaten uygulanmış yetenekleri ile herhangi bir uygulama sağlanmıştır. Her uygulamanın altında yatan ve çerçevenin bir parçası olan temel hizmet ve sistemler kümesi:

1. Listeler, metin alanları, tablolar, düğmeler ve hatta gömülü bir web tarayıcısı gibi uygulamaların görsel bileşenlerini oluşturmak için kullanılabilecek zengin ve genişletilebilir bir görünüm kümesi (Görünümler).
2. Bazı uygulamaların başkalarına açtığı, bu sayede çalışmaları için kullanabilecekleri verileri yöneten İçerik Sağlayıcıları.
3. Dize verileri, grafikler, dosyalar ve diğerleri gibi kod taşımayan kaynaklara erişim sağlayan bir kaynak yöneticisi (Kaynak Yöneticisi).
4. Tüm uygulamaların, kullanıcı için durum çubuğunda kendi bildirimlerini görüntüleyebildiği Bildirim Yöneticisi.
5. Uygulamaların yaşam döngülerini yöneten Faaliyet Yöneticisi, faaliyetlerle ilgili çalışma geçmişine ilişkin verileri depolar ve ayrıca onlar için bir navigasyon sistemi sunar.
6. Konum Yöneticisi (konum yöneticisi), uygulamaların, cihazın geçerli coğrafi konumu hakkında düzenli olarak güncellenmiş veri almalarını sağlar.

Android yazılım yığınının üst kısmında Uygulamalar seviyesi (Uygulamalar) bulunur. Bu bir dizi içerir temel uygulamalar, Android işletim sistemine önceden yüklenmiştir. Örneğin, bir tarayıcı içerir posta istemcisi SMS, haritalar, takvim, iletişim yöneticisi ve diğerleri göndermek için program. Entegre uygulamaların listesi cihaz modeline bağlı olarak değişebilir. android sürümü  . Ve bu temel dizinin yanı sıra, uygulamaların seviyesi, kullanıcı tarafından yüklenenler de dahil olmak üzere Android platformu için tüm uygulamaları içerir.

Kural olarak, Android uygulamaları Java'da yazılmıştır, ancak C / C ++ ile (Native Development Kit kullanarak) programlar geliştirme fırsatı vardır. Exotics, Basit (basit) kullanarak ve diğer dilleri kullanarak çağrılabilir. Ayrıca App Inventor gibi uygulama tasarımcılarını kullanarak kendi programlarınızı da oluşturabilirsiniz.

1.6. Çekirdek Özellikleri

Çekirdek, Linux işletim sisteminin en önemli parçasıdır ve diğer bölümlerinin aksine, neredeyse tamamen Android işletim sistemine aktarılmıştır. Bununla birlikte, aktarma işleminde çekirdeğe yaklaşık 250 yama uygulanmıştır.

Android işletim sistemi çekirdeğinde, Linux işletim sisteminin işlem içi iletişim araçlarından vazgeçmeye ve bunun yerine Binder adlı tek bir mekanizma oluşturmaya karar verildi. Ciltçi, bir işlemin yöntemlerini başka bir işlemden çağırmanıza, argümanları iletip sonuç elde etmenize olanak sağlar, tıpkı yöntemler aynı süreç içinde çağrıldığı gibi. Binder, bu işi en az bellek kullanımıyla yapar.

Küçük cihazlarda hata ayıklamayı etkinleştirmek için çekirdeğe hata ayıklama bilgileri eklendi. seri port  ve logcat komutu için destek uygulandı.

Büyük değişiklikler hafıza ile işe yaradı. Geleneksel Linux paylaşılan hafıza shmem yerini ashmem almıştır. Aynı problem, ancak fiziksel hafıza düzeyinde, pmem sürücüsü kullanılarak çözülmüştür. Viking Killer adında özel bir bellek işleyicisi eklendi, en basit durumda, sadece süreci öldürüyor, ancak daha karmaşık kurallar belirlenebilir.

Ağ yığına yeni güvenlik ayarları eklendi, çekirdeğe YAFFS2 flash sürücüler için dosya sistemi desteği dahil edildi.

1.7. Java makinesi Dalvik

Dalvik Sanal Makine Android mobil platformun bir parçasıdır. Bu sanal makineDan Bronstein sponsorluğunda. Gibi yayılır özgür yazılım  BSD uyumlu Apache 2.0 lisansı altındadır. Birçok yönden, bu gerçek bir rol oynadı google çözümü Sun'dan lisans almanız gereken JME'yi (Java Micro Edition) terk edin. Bu nedenle amacı açık bir işletim sistemi oluşturmak olan kurum kendi sanal makinesini geliştirdi.

Yığına yönelik çoğu sanal makineden (aynı Java Sanal Makinesi) farklı olarak, Dalvik standart bir çözüm olarak adlandırılamayan kayıt yönelimlidir. Öte yandan, çok yaygın olarak kullanılan ARM işlemcileri içeren RISC mimarisi işlemcileri üzerinde çalışmak için çok uygundur. mobil cihazlarah.

Dalvik, özellikle Android platformu için tasarlandı. Platformun, her biri kendi adres alanında çalışan tüm işlemleri izole edilmiş bir şekilde oluşturduğu gerçeği hesaba katılmıştır. Sanal makine  Düşük bellek tüketimi için optimize edilmiş ve mobil donanım üzerinde çalışmak. Android 2.2'den başlayarak, Dalvik JIT (Tam Zamanında) derlemesini kullanır. Bu özelliklerin sonucu olarak hızlı ve üretken sanal makineGenel olarak uygulamaların çalışmasını etkileyemez.

Dalvik kendi byte kodunu kullanıyor. Bir Android uygulaması geliştirirken, derleyici tarafından özel bir makine bağımsız düşük seviye koduna çevrilir. Bir platformda yürütüldüğünde, Dalvik böyle bir programı yorumlar ve yürütür.

Ek olarak, Dalvik, Java bytecode'larını yerel format kodlarına çevirip sanal ortamında da yürütebiliyor. Program kodu Java dilinde ve her şey derlendikten sonra yazılır. sınıf dosyaları, Android SDK'da bulunan özel dx yardımcı programını kullanarak .dex formatına (Dalvik'teki yorumlamaya uygun) dönüştürülür.

1.8. biyonik

Bionic, BSD lisansı altında dağıtılan standart bir C dili kütüphanesidir (Berkeley Software Distribution? Distribution system yazılım  kaynak kodunda, eğitim kurumları arasında deneyim alışverişi için oluşturulmuş) ve Android için Google tarafından geliştirilmiştir. Biyonikte, tam glibc uygulamasında mevcut olan bazı Android POSIX işlevleri yoktur.

Biyonik ana farklılıklar:

1. BSD lisansı: Android, GNU Genel Kamu Lisansı (GPL) altındaki Linux çekirdeğini kullanır, ancak Google Android uygulamalarını GPL'nin etkilerinden izole etmek istedi. Linux çekirdeği ile yaygın olarak kullanılan GNU libc, uClibc'ye alternatif olarak GNU LGPL lisansı altındadır.
2. küçük boyut: biyonik nesne kodu glibc'den çok daha küçük (yaklaşık 2 kat) ve uclibc'den biraz daha küçüktür.
3. biyonik, nispeten düşük saat hızlarında işlemciler için tasarlanmıştır.
4. pOSIX ipliklerinin kesilmiş ancak etkili bir uygulaması.

1.9. Java Uygulama Programcısı Arayüzlerine Genel Bakış

Android uygulama programcısı için - Java dilinde bir dizi arabirim. Nasıl organize edildiğini düşünün. Setin merkezinde, java.util, java.lang, java.io gibi Java dili standardında bulunan paketler bulunur. Java uygulamalarının çalışabileceği herhangi bir platformdadır ve Android için belirli değildir. Eklentiler, dilin standartlarına dahil olmayan, ancak fiili olarak uzun zamandır standart olan javax.net, javax.xml paketleridir.

Ayrıca Android'de daha az yaygın java uzantıları   - HTTP protokolünün en sağlam uygulaması olan org.apache.http paketi. Org.json paketi, JavaScript nesnelerinin serileştirilmesinden ve AJAX teknolojisinin desteklenmesinden sorumludur. Org.w3c.dom paketi, belge nesnesi modelini sağlar

Android platformuna dayanan bazı tablet modellerinde, yukarıdaki listedeki bazı bileşenler eksik olabilir.

Tüm "android" tabletler, Google’ın mobil işletim sisteminin sürümlerinden biri tarafından kontrol edilir. Ancak, eski sürümler modern uygulamaların bazılarını desteklemeyebilir.

En popüler mobil işletim sisteminin tüm sürümleri ortak bir temele sahiptir. Hayal edebiliyoruz işletim sistemi  Çok katmanlı bir yapı olarak Android. Bilgisayar mühendisleri buna yazılım yığını diyor. Yığının üstündeki elemanlar, kullanıcının işletim sistemiyle etkileşimi sırasında gördüğü şeydir. Yığının altında, işletim sisteminin doğrudan cihazın donanımıyla etkileşime giren kısımları bulunur.

Dolayısıyla, en düşük seviyede donanım bileşenleri kendileridir: işlemciler, sensörler, teller ve baskılı devre kartları. Bir sonraki katman işletim sisteminin çekirdeğidir. Çekirdeğe bazen gömülü (veya özel) yazılım da denir. Daha yaygın olarak bilinen, “firmware” in İngilizce tanımıdır. Bu yazılım, cihazın donanım kaynaklarını kontrol eder, kontrol eder ve dağıtımını kontrol eder.

İşletim sisteminin bu kısmı, kullanıcının uygun bir grafik arayüz vasıtasıyla verdiği komutları donanım bileşenlerinin diline "çevirir". Android için örnek bir çekirdek Linux 2.6 açık kaynaklı işletim sistemidir.

Android kütüphaneleri işletim sisteminin çekirdeğinin üstünde bulunur. Bir cihazın çeşitli veri türlerini işlerken takip ettiği talimatlar kümesidir. Bir örnek, üç boyutlu uzayda yönlendirme kütüphanesidir. Android cihazının uzaydaki konumundaki değişiklikleri tanımak ve bunlara yanıt vermek için ihtiyaç duyduğu tüm talimatları içerir.

Yazılım yığınının aynı seviyesinde, Java dilinde yazılmış uygulamaları desteklemek için ihtiyaç duyulan kök kütüphanelerdir. Java, Sun Microsystems’tan bir programlama dilidir. Daha yakın zamanlarda, Java özellikli telefonlar çok yaygındı. Şu anda, giderek akıllı telefonlar tarafından değiştiriliyor.

Android sanal makine, işletim sistemi yazılımı yığınının aynı seviyesinde bulunur. Bu yazılım parçası, sanal bir çalışma ortamı olarak da adlandırılan sanal bir çalışma ortamı yaratıyor. Sanal bir makine, ayrı bir işletim sistemine sahip fiziksel bir cihazı simüle eder. Google bu katmanı tasarladı, böylece Android işletim sisteminde çalışan her uygulama ayrı bir işlem olarak çalışıyor. Bu nedenle, çalışan işlemlerden biri başarısız olursa, geri kalanı etkilenmeden kalacaktır. Sanal makine aynı zamanda bir hafıza yöneticisi rolünü oynar.

Bir sonraki seviye uygulama çerçevesidir. Tüm uygulamalar "android" cihaz için temelidir. Uygulama altyapısı, uygulamalar ve işletim sisteminin geri kalanı arasındaki bağlantıdır.

Google, geliştiricilerin, arama devi işletim sistemi tarafından geliştirilen uygulama programlama arabiriminin () bir parçası olarak bu katmanla etkileşime giren uygulamalar oluşturmalarını önerir. Geliştiricilerin yalnızca API ile ilgili bu kuralları bilmeleri gerekir. Düşünmeleri gerekmez teknik özellikler  Her "android" tablet.

Yazılım yığınının üst seviyesi kullanıcı arayüzünü ve android tabletin tüm uygulamalarını içerir. İşletim sisteminin bu kısmı kullanıcı tarafından sürekli olarak görülür. Ancak bu çekici ve renkli katmanın arkasında çok sıkıcı gizler var ve yalnızca kod uzmanları için ilginç.

Diğer herhangi bir işletim sistemi ve tabletin diğer donanım kaynakları gibi.

Computer.howstuffworks.com adresine göre

# gerçekler | Android nasıl çalışır?   Oleg Dovbnya

  Hızlı hızlı veya ADB'nin nasıl çalıştığını hiç merak ettiniz mi? Ya da neden bir akıllı telefon altında android çalışan  bir tuğlaya dönüşmek neredeyse imkansız mı? Belki de uzun zamandır Xposed çerçevesinin sihrinin nerede olduğunu ve neden /system/etc/init.d boot scriptlerine ihtiyacınız olduğunu bilmek istediniz. Kurtarma konsolu ne olacak? Android'in bir parçası mı yoksa kendi içindeki bir şey mi ve neden normal kurtarma üçüncü taraf bellenimi kurmak için uygun değil? Tüm bu ve diğer birçok sorunun cevabını bu makalede bulacaksınız.

Android nasıl çalışır?

  Gizli özellikler hakkında bilgi edinin yazılım sistemleri  Yaptıkları işin ilkesini anladıysanız yapabilirsiniz. Bazı durumlarda, bunu yapmak zor, çünkü sistem kodu kapalı olabilir, ancak Android durumunda tüm sistemi yukarı ve aşağı keşfedebiliriz. Bu makalede, Android'in çalışmalarının tüm nüansları hakkında konuşmayacağım ve sadece işletim sisteminin nasıl başladığına ve güç düğmesine basılması ve masaüstünün görünümü arasındaki aralıkta hangi olayların gerçekleştiğine odaklanacağım.

Bu arada, bu olaylar zincirinde neleri değiştirebileceğimizi ve özel üretici yazılımı geliştiricilerin bu özellikleri, işletim sistemi ayarlama, uygulamaları kaydetme alanını genişletme, takas bağlantısı, çeşitli özelleştirmeler ve daha birçok şeyi uygulamak için nasıl kullandıklarını açıklayacağım. Tüm bu bilgiler kendi donanım yazılımınızı oluşturmak ve çeşitli bilgisayar korsanlıkları ve modifikasyonları uygulamak için kullanılabilir.

Bir adım. ABOOT ve bölüm tablosu

  Her şey birincil yükleyici ile başlar. Güç açıldıktan sonra, sistem cihazın kalıcı belleğinde kayıtlı önyükleyici kodunu çalıştırır. Daha sonra, fastboot protokolü için yerleşik destekle kontrol ünitesini önyükleyiciye aktarır, ancak mobil yonga veya akıllı telefon / tablet üreticisinin tadı için başka bir önyükleyici seçme hakkı vardır. Örneğin, Rockchip şirketi, hangisinin özel araçlar kullanması gerektiğini yeniden programlamak ve kontrol etmek için fastboot bootloader ile uyumlu olmayan bir şirket kullanıyor.

Fastboot protokolü ise, önyükleyicinin kilidini açma, yeni çekirdeğin yanıp sönmesi ve kurtarılması, bellenimin kurulması ve diğerleri gibi işlemleri gerçekleştirmenizi sağlayan bir PC önyükleyici yönetim sistemidir. Fastboot'un varlığının anlamı, diğer tüm araçların çalışmadığı durumlarda akıllı telefonu ilk durumuna geri getirebilmek. Deneyler neticesinde, Android içeren NAND belleğin tüm bölümlerini ve kurtarmayı akıllı telefondan silseniz bile, Fastboot yerinde kalacaktır.

Kontrolden sonra, aboot bölüm tablosunu kontrol eder ve kontrolü boot adlı bölüme dikilen çekirdeğe aktarır, daha sonra çekirdeği aynı bölümden RAM görüntüsünü çıkarır ve Android veya kurtarma konsolunu indirmeye başlar. Android cihazlardaki NAND belleği koşullu olarak zorunlu altı bölüme ayrılmıştır:

• boot - genellikle yaklaşık 16 MB boyutunda bir çekirdek ve RAM disk içerir;
• kurtarma - kurtarma konsolu, bir çekirdek, bir dizi konsol uygulaması ve 16 MB boyutunda bir yapılandırma dosyasından oluşur;
• sistem - Android içerir, modern cihazlarda en az 1 GB büyüklüğündedir;
• önbellek - önbellekteki verileri depolamak için tasarlanmıştır, ayrıca OTA güncellemesi sırasında bellenimi kaydetmek için de kullanılır ve bu nedenle sistem bölümünün boyutuna benzer bir boyuta sahiptir;
• userdata - ayarları, uygulamaları ve kullanıcı verilerini içerir, NAND hafızasının kalan tüm alanlarına verilir;
• misc - sistemin hangi modda başlatılacağını belirleyen bir bayrak içerir: Android veya kurtarma.

Bunlara ek olarak, başka bölümler de olabilir, ancak genel işaretleme akıllı telefonun tasarım aşamasında belirlenir ve bir üst üste çıkması durumunda yükleyici koduna dikilir. Bunun anlamı şudur: 1) fastboot oem format komutunu kullanarak her zaman geri yüklenebildiğinden, bölüm tablosu öldürülemez; 2) bölüm tablosunu değiştirmek için, önyükleyicinin kilidini açmanız ve yeni parametrelerle yeniden başlatmanız gerekir. Ancak bu kuraldan istisnalar vardır. Örneğin, aynı Rockchip önyükleyici, NAND belleğinin ilk bloğundaki bölümler hakkındaki bilgileri saklar, böylece değiştirmek için yanıp sönen bir önyükleyiciye ihtiyacınız yoktur.

Bölüm tablosunu tanımlayan yükleyici kodunun bir kısmı​

  Özellikle ilginç bölüm misc. Ana sistem ne olursa olsun, çeşitli ayarları saklamak için başlangıçta oluşturulduğuna dair bir varsayım vardır, ancak bu an sadece bir amaç için kullanılır: Yükleyiciye, sistemin hangi bölümden yüklenmesi gerektiğini gösterir - önyükleme veya kurtarma. Özellikle bu özellik, bellenimin otomatik olarak yüklenmesiyle sistemi kurtarma sırasında otomatik olarak yeniden başlatmak için ROM Manager uygulamasını kullanır. Temelde, Ubuntu Touch çift önyükleme mekanizması kuruludur; bu, Ubuntu önyükleyicisini kurtarma sırasında temizler ve bir sonraki seferde hangi sistemin yükleneceğini kontrol etmenizi sağlar. Çeşitli bölümler - Android yüklendi, verilerle dolu - kurtarma yükleniyor ... yani Ubuntu Touch.

İkinci adım Önyükleme bölümü

  Misc bölümünün kurtarma sırasında bir önyükleme bayrağı yoksa, aboot denetimi önyükleme bölümünde bulunan koda aktarır. Linux çekirdeği gibi bir şey değil; Bölümün başında bulunur ve hemen ardından Android için gerekli dizinleri içeren init sistemi ve diğer araçları içeren cpio ve gzip arşivleyicileriyle dolu bir RAM disk görüntüsü izler. Önyükleme bölümünde dosya sistemi yoktur, çekirdek ve RAM disk birbirini takip eder. RAM diskinin içeriği:

• veri - aynı isimdeki bölümü monte etmek için dizin;
• dev - cihaz dosyaları;
• proc - procfs buraya monte edilir;
• res - şarj cihazı için bir dizi resim (aşağıya bakınız);
• sbin - bir dizi yardımcı araç ve servis aracı (örneğin adbd);
• sys - sysfs buraya monte edilir;
• sistem - sistem bölümünün montajı için dizin;
• şarj cihazı - şarj işlemini görüntülemek için bir uygulama;
• build.prop - sistem ayarları;
• init - başlatma sistemi;
• init.rc - başlatma sistemi ayarları;
• ueventd.rc - init'in bir parçası olan uventd arka planının ayarları.

Bunu söylersem, sistemin iskeleti: NAND-bellek bölümlerinden dosya sistemlerini bağlamak için bir dizinler dizisi ve sistemin yüklenmesiyle ilgili çalışmaların geri kalanını başlatacak bir başlatma sistemi. Buradaki ana unsur init uygulaması ve daha sonra daha detaylı olarak tartışacağım init.rc config. Bu arada, ben dosyaları şarj ve ueventd.rc yanı sıra sbin, proc ve sys dizinleri dikkat çekmek istiyorum.

Şarj cihazı, tek görevi pil simgesini görüntülemek olan küçük bir uygulamadır. Android ile hiçbir ilişkisi yoktur ve cihaz kapalı durumdayken şarj cihazına bağlıyken kullanılır. Bu durumda, Android önyükleme yapmaz ve sistem yalnızca çekirdeği yükler, RAM diskini bağlar ve şarj cihazını başlatır. Sonuncusu, resmi tüm olası durumlarda res dizininin içindeki normal PNG dosyalarında saklanan pil simgesini görüntüler.

Ueventd.rc dosyası, sistem önyükleme aşaması sırasında sys dizinindeki hangi aygıt dosyalarının oluşturulması gerektiğini belirleyen bir yapılandırma dosyasıdır. Çekirdek tabanlı Linux sistemleri  donanıma dev dizini içindeki özel dosyalar aracılığıyla erişilir ve init'in bir parçası olan ueventd daemon, Android'de oluşturmaktan sorumludur. Normal bir durumda, çekirdekten dosya oluşturmak için komutları kabul ederek otomatik olarak çalışır, ancak bazı dosyaların bağımsız olarak oluşturulması gerekir. Ueventd.rc'de listelenirler.

Android hisse senedindeki sbin dizini genellikle bir şey içermez, yani, bir PC'den sistemin hatalarını ayıklamaktan sorumlu olan ADB arka plan programıdır. İşletim sisteminin yüklenmesinin erken bir aşamasında başlar ve olası sorunlar  OS başlatma aşamasında. Bu dizindeki özel ürün yazılımında, bölümlerin ext3 / 4 olarak yeniden biçimlendirilmesi gerekiyorsa gerekli olabilecek mke2fs gibi başka dosyalar da bulabilirsiniz. Modery de sık sık orada yüzlerce Linux komutları çağırabileceğiniz BusyBox koydu.

Linux için proc dizini standarttır, bir sonraki önyükleme adımlarında, init, procfs'i sistemdeki tüm süreçler hakkında bilgiye erişim sağlayan sanal bir dosya sistemi ile bağlar. Sistem, donanım ve ayarları hakkındaki bilgilere erişim sağlayan sys dizini sysfs'e bağlanacaktır. Sysfs kullanarak, örneğin, uykuya daldırmak veya kullanılan güç tasarrufu algoritmasını değiştirmek için bir cihaz gönderebilirsiniz.

Build.prop dosyası, düşük düzeyli depolamak için tasarlanmıştır android ayarları. Daha sonra, sistem bu ayarları sıfırlar ve kullanılmayan sistem / build.prop dosyasındaki değerlerin üzerine yazar.

Set üstü kutusunun kök kısmı OUYA​

İkinci adım, alternatif. Kurtarma bölümü

Misc bölümündeki kurtarma önyükleme bayrağının ayarlanmış olması veya kullanıcının ses seviyesini azaltma tuşunu basılı tutarken akıllı telefonu açması durumunda, aboot, kontrolü kurtarma bölümünün başında bulunan koda aktarır. Önyükleme bölümü gibi, bir çekirdek ve belleğe açılan ve dosya sisteminin kökü haline gelen bir RAM diski içerir. Ancak, RAM diskin içeriği burada biraz farklıdır.

İşletim sistemi önyüklemesinin farklı aşamaları arasında bir geçiş bağı görevi gören önyükleme bölümünün aksine, kurtarma bölümü tamamen kendi kendine yeten ve Android ile ilgili olmayan minyatür bir işletim sistemi içeriyor. Kurtarma işleminin kendi çekirdeği, kendi uygulamaları kümesi (komutları) ve kullanıcının servis işlevlerini etkinleştirmesini sağlayan kendi arayüzü vardır.

Standart (stok) kurtarma işleminde genellikle sadece bu üç işlev vardır: akıllı telefon üreticisi tarafından imzalanan ürün yazılımı imzalı anahtarın takılması, silin ve yeniden başlatılması. ClockworkMod ve TWRP gibi değiştirilmiş üçüncü taraf kurtarma işlemlerinden çok daha fazlası var. Dosya sistemlerini biçimlendirebilir, herhangi bir tuşla işaretlenmiş ürün yazılımını (okuma: özel) yükleyebilir, dosya sistemlerini diğer bölümlere monte edebilir (işletim sistemi hata ayıklama amacıyla) ve ürün yazılımı işlemini ve diğer birçok işlevi otomatikleştiren komut dosyası desteği içerebilir.

Örneğin, komut dosyalarını kullanarak kurtarmayı indirdikten sonra gerekli bellenimi otomatik olarak bellek kartında bulduğundan, yüklediğinden ve Android'de yeniden başlattığından emin olabilirsiniz. Bu özellik, ROM Manager, otomatik flaşör araçlarının yanı sıra CyanogenMod ve diğer bellenimin otomatik güncelleme mekanizması tarafından kullanılır.

Özel kurtarma ayrıca /system/addon.d/ dizininde bulunan yedekleme komut dosyalarını da destekler. Yanıp sönmeden önce, kurtarma komut dosyalarını kontrol eder ve yanıp sönmeden önce bunları yürütür. Bu komut dosyaları sayesinde boşluklar kurulumdan sonra kaybolmuyor. yeni versiyon  firmware.

Üçüncü adım başlatma

Böylece, kontrol alındıktan sonra, çekirdek RAM diskini bağlar ve tüm alt sistemlerini ve sürücülerini başlattıktan sonra, Android başlatma işleminin başladığı init işlemini başlatır. Daha önce de belirttiğim gibi, init, init.rc adlı bir yapılandırma dosyasına sahip ve sürecin sistemi yükseltmek için ne yapması gerektiğini bileceği bir dosya var. Modern akıllı telefonlarda, bu yapılandırma birkaç yüz satırlık etkileyici bir uzunluğa sahiptir ve ayrıca ithalat direktifinin yardımı ile ana hatta bağlanan çeşitli kız yapılandırmalarının bir fragmanı ile donatılmıştır. Bununla birlikte, biçimi oldukça basittir ve aslında bloklara bölünmüş bir komutlar dizisidir.

Her blok, yükleme aşamasını veya Android geliştiricileri dilinde eylemi belirler. Bloklar birbirinden on yönergesi ile ayrılır ve ardından eylemin adı örneğin erken girişte veya fs sonrası. Komut bloğu yalnızca aynı addaki tetikleyici tetiklendiğinde çalıştırılır. Önyükleme başladıkça, init, erken-init, init, f-fs, f-post, f-post'ların ilk açılışını ve önyükleme tetikleyicilerini etkinleştirerek uygun komut bloklarını başlatır.

İnyan.rc config 'in CyanogenMod' den bir kısmı​

  Konfigürasyon dosyası başında listelenen birkaç konfigürasyonu çekerse (ve bu hemen hemen her zaman böyledir), içindeki aynı komut blokları ana konfigürasyon ile birleştirilir, böylece tetikleyici tetiklendiğinde, init tüm komutların karşılık gelen bloklarından komutları çalıştırır. Bu, ana yapılandırma tüm cihazlar için ortak olan komutlar içerdiğinde ve her cihaz için özel olan ayrı dosyalar halinde yazıldığında, birkaç cihaz için yapılandırma dosyaları oluşturmanın kolaylığı için yapılır.

Ek yapılandırmalardan en dikkat çekeni, initrc.device_name.rc olarak adlandırılır, burada aygıt adı ro.hardware sistem değişkeninin içeriğine göre otomatik olarak belirlenir. Bu, belirli bir aygıta özgü komut bloklarını içeren platforma özgü bir yapılandırma dosyasıdır. Çekirdeği ayarlamaktan sorumlu komutlara ek olarak, aşağıdaki komutu da içerir:

mount_all ./fstab.device_name

Bu, init'in şu anda aşağıdaki yapıya sahip olan ./ fstab.device_name içinde listelenen tüm dosya sistemlerini monte etmesi gerektiği anlamına gelir:

device_name (bölüm) mount_point mount_file option_fs diğer seçenekler

Genellikle dosya sistemlerini dahili NAND bölümlerinden / system (OS), / data (application settings) ve / cache (cached data) dizinlerine bağlamak için talimatlar içerir. Ancak, bu dosyayı biraz değiştirerek, sistemi hafıza kartından yüklemeye zorlayabiliriz. Hafıza kartını üç 4 bölüme ayırmak yeterlidir: 1 Gb / ext4, 2 Gb / ext4, 1 Gb / ext4 ve kalan alan yağı32. Daha sonra, / dev dizinindeki hafıza kartı bölümlerinin adlarını belirlemeniz gerekir. farklı cihazlar  farklıdırlar) ve fstab dosyasındaki orijinal cihaz isimlerini değiştirin.

Tipik fstab dosyası içeriği​

  Önyükleme init bloğunun sonunda, büyük olasılıkla class_start default komutuyla karşılaşırsınız; bu, daha sonra varsayılan sınıfla ilgili olan config içinde listelenen tüm hizmetleri başlatmanız gerektiğini size bildirir. Servislerin tanımı servis direktifiyle başlar, ardından servisin adı ve başlatılması gereken komut ile devam eder. Bloklarda listelenen komutlardan farklı olarak, servisler her zaman çalışmalıdır, bu nedenle akıllı telefonun ömrü boyunca init arka planda durur ve göz kulak olur.

Modern Android düzinelerce hizmet içerir, ancak ikisi özel bir statüye sahiptir ve tüm sistem yaşam döngüsünü tanımlar.

Dördüncü Adım Zigot ve app_process

  Belli bir yükleme aşamasında, init, konfigürasyon sonunda bu birime benzer bir şeyle karşılaşacaktır:

servis zigot / sistem / bin / app_process -Xzygote / sistem / bin --zygote - start-system-server
   sınıf varsayılanı
   soket zigot akışı 660 kök sistemi
   onrestart write / sys / android_power / request_state uyandırma
   onrestart yazma / sys / güç / durum açık
   yeniden başlatma medyayı yeniden başlat
   onrestart yeniden başlat netd

Bu, başlatma işleminden sorumlu olan herhangi bir Android sisteminin temel bir bileşeni olan Zygote hizmetinin bir açıklamasıdır. sistem hizmetleri, kullanıcı uygulamalarını ve diğer birçok görevi başlatmak ve durdurmak. Zygote, yukarıdaki yapılandırma parçasında çok iyi görülebilen küçük bir uygulama / sistem / bin / app_process kullanılarak başlatılır. App_proccess görevi, kodu /system/lib/libandroid_runtime.so paylaşılan kütüphanesinde bulunan Dalvik sanal makinesini başlatmak ve ardından Zygote'u çalıştırmaktır.

Tüm bunlar yapıldığında ve Zygote kontrol altına alındığında, çerçevenin tüm Java sınıflarını yükleyerek Java uygulamalarının yürütme ortamını oluşturmaya başlar (şu anda 2000'den fazlası vardır). Ardından, Pencere Yöneticisi, Durum Çubuğu, Paket Yöneticisi ve en önemlisi, gelecekte başlangıç ​​ve bitiş sinyallerini almaktan sorumlu olacak Faaliyet Yöneticisi dahil olmak üzere, üst düzey (Java'da yazılmış) sistem hizmetlerinin çoğunu içeren system_server'ı başlatır. uygulamalar.

Bundan sonra, Zygote soketi / dev / socket / zygote 'u açar ve veriyi bekleyerek uykuya dalar. Şu anda, daha önce başlatılan Etkinlik Yöneticisi, masaüstünü oluşturmaktan sorumlu olan uygulamayı bulmak için Intent.CATEGORY_HOME yayın içeriğini gönderir ve bir soket üzerinden Zygote adını verir. İkincisi, sırayla, uygulamayı sanal makinenin üstüne getirir ve çalıştırır. Voila, Durum Çubuğu hizmetinde system_server tarafından başlatılan bir masaüstüne, bulunan bir Aktivite Yöneticisine, çalışan bir Zigot'a ve bir durum çubuğuna sahibiz. Simgesine dokunduktan sonra, masaüstü bu uygulamanın adı ile bir niyet gönderecek, Etkinlik Yöneticisi tarafından kabul edilecek ve Zygote daemon'a uygulamayı başlatmak için bir komut gönderir

Bütün bunlar biraz anlaşılmaz görünebilir, ancak en önemli şey üç basit şeyi hatırlamaktır:

Sistem hizmetleri ve çekirdek konuları​

bulgular

  Birçok yönden, Android diğer işletim sistemlerinden çok farklıdır ve bunu çözmek imkansızdır. Ancak, her şeyin nasıl çalıştığını anlarsanız, sınırsız imkanlar vardır. İOS’un aksine Windows telefonuGoogle’ın işletim sistemi, kod yazmanıza gerek kalmadan davranışını ciddi şekilde değiştirmenize olanak tanıyan çok esnek bir mimariye sahiptir. Çoğu durumda, gerekli konfigürasyonları ve komut dosyalarını değiştirmek yeterlidir.

• çeviri

Bu yazıda Android uygulamaların mimarisine bakacağız.

Açıkçası, bu konuda resmi Google’ı pek yararlı bulmuyorum. “Nasıl” sorusuna ayrıntılı olarak cevap vererek, ne ve neden olduğunu hiç açıklamıyor. Yani, işte benim versiyonum ve umarım biraz netlik getirecektir. Evet, bu arada, Google makalelerini okumayı tamamen onaylıyorum, çünkü tekrarlamak istemediğim faydalı bilgiler içeriyorlar.

Android işletim sistemi mimarisi - biraz tarih

  BT'de sıklıkla olduğu gibi, pek çok şey, belirli yazılımların ortaya çıkma tarihinden ayrı tutularak açıklanamaz. Bu yüzden Android işletim sisteminin kökenine yönelmeliyiz.

Android işletim sisteminin gelişimi, 2003 yılında genç şirket Android Inc. tarafından başlatılmıştır. 2005 yılında bu şirket Google tarafından satın alındı. Bu dönemde Android mimarisinin temel özelliklerinin belirlendiğine inanıyorum. Bu sadece Android Inc'in kredisi değildir; Google’ın mimari konseptleri ve finansal kaynakları Android’in mimarisi üzerinde belirleyici bir etkiye sahip. Daha sonra birkaç örnek vereceğim.

Hatırlarsanız, 2003-2005 arasında AJAX uygulamalarına gösterilen ilgi artmıştır. Bunun, Android'in mimarisi üzerinde temel bir etkisi olduğunu düşünüyorum: Birçok yönden, tipik bir AJAX uygulamasının mimarisine, Java, C #, C ++, VB vb. İle yazılmış masaüstü GUI uygulamasından daha yakındır.

Neden olduğunu bilmiyorum. Tahminim Google’ın Google Dokümanlar’ın veya Gmail’in ruhuna uygun zengin İnternet uygulamalarının (Zengin İnternet Uygulamaları, RIA) tüm sorunlara çözüm olarak kabul edildiği bir zamanda icat edilen biriydi. Bence bu fikre ne iyi ne de kötü denemez. Sadece Android uygulamalarının masaüstü uygulamalardan çok farklı olduğunu unutmayın.

Eclipse’in mimari felsefesinin etkisi, SWI’dan çok SwT’ye benzeyen GUI uygulama ilkesinin seçiminde göze çarpmaktadır.

Android kodunun tasarım standartlarında, MS duvarları içinde doğmuş bir “Macar notasyonu” vardır. Bu standartları yazan kişinin daha önce Windows'taki geliştirme ile ilgili olduğu varsayılabilir.

Android mimari seviyeleri

  Android işletim sisteminde üç farklı seviye ve birbirinden ayrılan seviye vardır:

1. Önceki makalelerimden birinde bahsettiğim gibi, değiştirilmiş ve kesilmiş bir Linux sürümüne dayanmaktadır.
2. Linux seviyesinin üzerinde, Dalvik sanal makinesini, bir web tarayıcısını, bir SQLite veritabanını, bazı altyapı koltuk değneklerini ve bir Java API'sini içeren uygulama altyapısı katmanı bulunmaktadır.
3. Ve son olarak, Google tarafından yazılan Android uygulamalarının seviyesi. Genel olarak konuşursak, bunlar altyapı seviyesinin bir uzantısıdır, çünkü geliştirici bu uygulamaları veya bir kısmını kendi gelişimi için yapı taşı olarak kullanabilir.

  Bu katmanları tek tek ve daha ayrıntılı olarak düşünün.

Linux seviyesi

  Genç bir şirkette mimar olduğunuzu hayal edin. Yeni bir cihaz türü için bir işletim sistemi geliştirmelisiniz. Ne yapacaksın

Kabaca konuşursak, iki yolunuz vardır: kendi fikirlerinizi uygulamak, sıfırdan başlamak veya mevcut işletim sistemini kullanmak ve bunları cihazlarınıza uyarlamak.

Sıfırdan uygulamak her zaman programcılar için heyecan verici geliyor. Bu anlarda, hepimiz bu sefer her şeyi diğerlerinden daha iyi, hatta kendimizden daha iyi yaptığımıza inanıyoruz.

Ancak, bu her zaman pratik değildir. Örneğin, Linux çekirdeğinin kullanılması, geliştirme maliyetini önemli ölçüde düşürmüştür (belki de zaten çok büyük bir yerde). Kabul ediyorum, eğer biri mevcut durumda Linux çekirdeğine benzer bir şey yaratmaya karar verirse, birkaç milyon dolara ihtiyacı olacaktır.

Android Inc'in sorumlusuysanız, tanım gereği bu kadar paraya sahip olamazsınız. Google’ı çalıştırırsanız, o zaman bu kadar para bulursunuz, ancak büyük olasılıkla kendi işletim sisteminizi oluşturmadan önce iki kez düşüneceksiniz. Ayrıca, şu anki Linux durumuna erişmeden önce birkaç yıl geçireceksiniz; birkaç yıl gecikme piyasaya girmek için çok geç olabilir.

Bu durumda, Apple, Free BSD tabanlı bir Mac OS kurmaya karar verdi. Android Inc, Linux'u Android için temel olarak kullanmaya karar verdi. Hem BSD hem de Linux kaynakları ücretsiz olarak temin edilebilir ve Apple veya Google olsun, herhangi bir gelişme için iyi bir temel sağlar.

Ancak o zaman standart Linux'u mobil bir cihazda başlatmak imkansızdı (şimdi durum böyle değil). Cihazlarda çok az RAM ve kalıcı bellek vardı. İşlemciler, Linux'un yaygın olarak kullanıldığı bilgisayarlardaki işlemcilerle karşılaştırıldığında önemli ölçüde yavaştı. Sonuç olarak, Android geliştiricileri en aza indirmeye karar verdi. sistem gereksinimleri  Linux.

Eğer Linux'u düşünürsek yüksek seviyeo zaman çekirdeğin (kaçınılması mümkün olmayan) ve diğer birçok isteğe bağlı parçanın birleşimidir. Başka bir şey olmadan bir çekirdeği bile çalıştırabilirsiniz. Bu nedenle, Google her durumda Linux çekirdeğini Android işletim sisteminin bir parçası olarak kullanmak zorunda kalır. Ayrıca, isteğe bağlı parçalar değerlendirildi ve en gerekli olanları seçildi. Örneğin, IPTables ağ güvenlik duvarı ve Ash kabuğu eklendi. İkincisinin daha güçlü bir düzen olduğu gerçeğine rağmen, Bash'in değil, Ash'in eklenmesi ilginçtir; Bu karar muhtemelen Ash'in daha az kaynak harcadığı gerçeğine dayanıyordu.

Android geliştiricileri, Linux çekirdeğini değiştirerek, mobil aygıtlarda kullanılan ve daha sık bilgisayarlarda erişilemeyen donanıma destek eklediler.

Linux'un temeli olarak seçilmesi, Android işletim sisteminin tüm yönleri üzerinde büyük bir etki yarattı. Aslında Android'i oluşturmak, Linux oluşturma işleminin bir çeşitlemesidir. Android kodu  git (linux kodunu yönetmek için tasarlanmış bir araç) çalıştırıyor. Ve benzeri.

Her şeyin ilginç olmasına izin verin, ancak hedefiniz Android uygulamaları geliştirmek olana kadar bu belirli anlara asla dokunmayacaksınız. Bunun tek istisnası, ash komutlarını kullanan dosya sisteminin gözden geçirilmesi olabilir. Android için uygulama geliştirirken bilmeniz gereken en önemli şey, uygulama altyapısının seviyesidir.

Yerel bir Android uygulaması geliştirmeniz gerekirse nasıl olunacağını sorabilirsiniz. Google bunu yapmayı kesinlikle önermiyor. Teknik olarak, elbette, bu mümkündür, ancak gelecekte bu uygulamayı normal şekilde dağıtamazsınız. Bu nedenle, tabii ki Android Açık Kaynak Projesi (AOSP) üzerinde çalışmadığınız sürece, yerel Android geliştirmeye başlamadan önce iki kez düşünün, yani. Android işletim sistemi kendisi.

Uygulama Altyapısı Seviyesi

  Bazı benzerliklere rağmen Apple iOS  ve Android işletim sistemi, her iki işletim sisteminin altyapı düzeyinde mimari çözümler arasında önemli farklılıklar vardır.

Apple, Objective-C yazılımını programlama dili ve çalışma zamanı ortamı olarak kullanmaya karar verdi. iOS uygulamaları. Objective-C, Free BSD tabanlı bir işletim sistemi için aşağı yukarı doğal bir seçenek gibi görünüyor. Bazı belirli dilsel yapıları ekleyen özel bir önişlemcili olan Objective-C'yi normal C ++ olarak düşünebilirsiniz. Ücretsiz BSD'nin yazıldığı standart C ++ 'ı kullanmak neden imkansız? Sanırım sebebi Apple’ın her şeyi “Apple” tarzında yapmaya çalışıyor olması.

Temel fikir, iOS uygulamalarının arkasındaki işletim sistemi ile aynı dilde az ya da çok yazılmış olmasıdır.

Android uygulamaları bu anlamda çok farklı. Java ile yazılmıştır ve bu, C ++ 'dan tamamen farklı bir teknolojidir (sözdizimi C ++' dan alınmış olsa da).

Bence asıl sebep, aynı uygulamanın farklı donanımlar üzerinde çalışması gerektiği. Bu sorun yalnızca Android işletim sistemi için oluşur; Apple’dan gelenlerin böyle bir sorunu yok. iOS sadece kendi üretim ekipmanı üzerinde çalışır ve Apple tüm süreci tamamen kontrol eder. Android için bunun tersi geçerli: Google donanım üreticilerini kontrol etmiyor. Örneğin, Android işletim sistemi x86, ARM ve Atom işlemcileri üzerinde çalışır (açıklamalarda x86, Atom'u içerir ve Android, x86, ARM, PPC ve MIPS üzerinde çalışır - çevirmenin notu). İkili seviyede, bu mimariler uyumsuz.

Android işletim sisteminin mimarları Apple'dan gelen mimarlarla aynı yolu seçerse, Android geliştiricileri aynı uygulamanın birkaç sürümünü aynı anda dağıtmak zorunda kalacaktı. Bu, Android projesinin tamamının çökmesine yol açabilecek ciddi bir problem olacaktır.

Aynı uygulamanın farklı donanımlarda çalışması için Google, kapsayıcı tabanlı mimariyi kullandı. Bu mimaride, ikili kod bir yazılım kabı tarafından yürütülür ve belirli donanımın ayrıntılarından izole edilir. Örnekler herkese tanıdık geliyor - Java ve C #. Her iki dilde de ikili kod, belirli donanıma bağlı değildir ve sanal makine tarafından yürütülür.

Tabii ki, ikili kod seviyesinde donanım bağımsızlığı elde etmenin başka bir yolu var. Bir seçenek olarak, QEMU olarak da bilinen donanım emülatörünü kullanabilirsiniz. Örneğin, x86 platformunda ARM işlemcili bir cihazı taklit etmenizi sağlar. Google, emülatörlerde uygulamalar geliştirmek için C ++ 'ı bir dil olarak kullanabilir. Gerçekten de, Google bu yaklaşımı QEMU’ya dayanan Android öykünücülerinde kullanmaktadır.

Bu yolu izlememeleri çok iyi, çünkü o zaman birinin işletim sistemini çok daha fazla kaynak gerektiren bir emülatör üzerinde çalıştırması gerekecek ve bunun sonucunda işin hızı düşecek. Ulaşmak için en iyi performans  Android uygulamalarında bizim durumumuzda öykünme yalnızca önlenemeyen bir yerde kaldı.

Olabildiği gibi, Google uygulamaları geliştirmek ve çevreleri için Java'yı ana dil olarak kullanmaya karar vermiştir.

Android'i şu anda mevcut olan Linux tabanlı mobil işletim sistemlerinin geri kalanından ayırmanın kritik bir mimari çözüm olduğunu düşünüyorum. Bildiğim kadarıyla, hiçbiri uygulama düzeyinde ikili uyumluluğa sahip değil. Örneğin MeeGo atın. C ++ ve Qt çerçevesini kullanır; Qt platformlar arası olmasına rağmen, farklı platformlar için farklı yapılar yapma ihtiyacı ortadan kalkmıyor.

Java'yı seçerek, hangi sanal makineyi (JVM) kullanacağınıza karar vermeniz gerekiyordu. Sınırlı kaynaklar nedeniyle, standart JVM kullanmak zordu. Mümkün olan tek seçenek, mobil cihazlar için geliştirilen bir Java ME JVM kullanmaktı. Bununla birlikte, Google’ın mutluluğu, kendi sanal makinesini geliştirmeden eksik kalır ve Dalvik VM ortaya çıktı.

Dalvik VM, aşağıdaki diğer Java sanal makinelerinden farklıdır:

• Diğer Java sanal makineleri için standart olan JAR ve Pack200 formatlarının aksine, ikili kodları saklamak için özel bir DEX formatı kullanır. Google, DEX ikili dosyalarının JAR'dan küçük olduğunu söyledi. Sanırım Pack200'ü de kullanmış olabilirler ama kendi yollarına gitmeye karar verdiler.
• Dalvik VM aynı anda birden fazla işlemi yürütmek için optimize edilmiştir.
• Dalvik VM, diğer JVM'lerde yığın mimarisine karşı kayıt tabanlı bir mimariyi kullanır, bu da yürütme hızında bir artışa ve ikili boyutların azalmasına neden olur.
• Kendi talimat setini kullanır (standart JVM bayt kodu yerine).
• Tek bir işlemle (gerekirse) birkaç bağımsız Android uygulamasını başlatmak mümkündür.
• Bir uygulamayı çalıştırmak birden fazla Dalvik VM işlemini “doğal bir şekilde” kapsayabilir (daha sonra bunun ne anlama geldiğini tartışacağız). Bunu desteklemek için ekledi:
  • Parsel ve Parcelable sınıflarına dayalı özel bir nesne seri hale getirme mekanizması. İşlevsel olarak, Java Serileştirilebilir ile aynı hedefleri izlerler, ancak sonuç olarak veriler daha küçüktür ve sınıflama sınıfı değişikliklerine potansiyel olarak daha toleranslıdır.
  • Android Arabirim Tanım Dili'ne (AIDL) dayalı işlem arası çağrılar (işlem içi çağrılar, IPC) yapmanın özel bir yolu.
• Android 2.2'den önce Dalvik VM, ciddi bir performans hedefi olan JIT derlemesini desteklemedi. 2.2 sürümünden başlayarak, sık kullanılan uygulamaların yürütme hızı