Introduktion till Android-operativsystem
Operativsystemet Android är ett system med öppen källkod. Många säger att det är Linux, men det är inte helt sant. Även om Android har kärnor som liknar Linux, är det det enda som liknar. Idag kommer vi att ta en djupare titt på insidan av Android-operativsystemet som är processerna, ramverket och andra liknande strukturer. Så låt oss komma igång från grunderna och titta tills den inre roten i Android-operativsystemet.
Efter lanseringen av iPhone och Windows Lumia Series, dvs de Microsoft Windows-relaterade telefonerna, ville Google göra detsamma. Men de ville ha något som kunde vara öppen källkod. Det främsta skälet bakom detta var så att vem som helst kunde felsöka det, ändra det alla ändringar som de ville. Sedan kom idén om Linux. Linux är ett helt öppen källkodssystem och det accepteras allmänt av samhället över hela världen. Det är ett av de operativsystem som används ännu mer än Windows eller Mac OSX. Dessutom har Linux förmågan att köra nästan alla andra saker som kan köras på antingen Mac eller Windows. Således beslutade Google att utveckla ett operativsystem för en mobiltelefon med samma grundläggande inre skal som Linux, så att det är kompatibelt med nästan allt och det yttre skalet skulle utvecklas som, när och även hur det krävs.
Android-operativsystem som ett öppet källkodsprojekt (AOSP)
Android har förmågan att fritt ändra, uppfinna och implementera våra egna enhetsdrivrutiner och funktioner. För att tala om det finns det fem olika lager i ett Android-operativsystem. Det går enligt följande:
Som du kan se i bilden ovan är det första lagret Application Framework, det andra är Binder IPC Proxies, det tredje består av Android System Services, det fjärde är HAL eller hela formen är Hardware Abstraction Layer och den sista är Linux-kärnan. Nu som jag sa tidigare kan du se att den enda delen av Linux som ett Android-operativsystem består av är Linux-kärnan. Låt oss nu titta in dem alla en efter en.
Ram för Android-applikationer
Denna appram används av apputvecklare för Android. Den här delen av Android har åtminstone att göra någonting med hårdvaruskiktet. Android-applikationer är programmerade på Java-språk. Efter att ha programmerat en app hjälper Android SDK-verktyg att sammanställa data och resursfiler som XML-filer, burkfiler, manifestfiler och andra bilder och grejer i ett enda arkivpaket med en "apap "-tillägg. Denna apk-fil kan användas för att installera appen med bara ett enda klick på Android-enheterna. Eftersom Android-operativsystemet uppträder som en Linux-miljö är appbeteendet också detsamma här. Varje app betraktas som en separat användare från den andra och körs i sin egen virtuella maskin. Detta gör att den programmerade koden för appen isoleras och förhindrar också att den smittar från andra såvida det inte uttryckligen anges. Varje annan app har sitt eget ANVÄNDAR-ID och varje annan process har sin egen virtuella maskin.
Ramen för Android-applikationer fungerar enligt principen om minst privilegier. Least Privilege Principle betyder att när en ny app behöver köras, men det inte finns något tillgängligt minne, kommer Android-systemet automatiskt att lämna den gamla applikationen som inte är nödvändig för att köra i bakgrunden. Detta är en av de bästa delarna av Android-operativsystemets säkerhet. Denna princip gör det möjligt att varje app bara har den åtkomst som krävs för att utföra sitt arbete. Således kan en app inte få tillstånd för vad som inte är avsett att göra. Detta skapar i sin tur en mycket säker miljö i själva Android-operativsystemet.
Binder IPC kallas Binder Inter-Process Communication. Detta gränssnitt tillåter en programmerare att skapa en applikation för att kommunicera med andra applikationer. Oftare är det inte applikationerna som kommunicerar, det är processerna. Binder IPC hjälper till att köra flera processer samtidigt på en samtidig nivå. Denna bindemedelsimplementering kommer från kärnan i Android-operativsystemet. Nu har det ställts frågor om varför behöver bindemedlet stanna kvar i kärnan, och varför kan det inte köras från Linux IPC-mekanismerna? Det främsta skälet till detta är att bindemedlet undviker att använda onödig allokering av utrymme till skillnad från andra IPC-mekanismer i Linux-systemet. Om du har hört talas om termen "magi i python", så är det så en Binder IPC skulle se ut för en applikationsutvecklare, eftersom den är helt dold för dem, och det verkar helt enkelt fungera, till skillnad från högnivåramen där du måste få den att fungera exakt. Detta möjliggör faktiskt den höga nivån för att kommunicera med Android-operativsystemtjänster.
Systemtjänster för Android-operativsystem
En tjänst är en sammanställd kodkod som körs under lång tid i bakgrunden till ett Android-operativsystem utan att ge något gränssnitt. Varje applikation, kan det vara användare eller system kan starta en tjänst, men den kommer fortfarande att köra i bakgrunden även om applikationen är stängd. Det finns dock två typer av tjänster:
Startade tjänster
Startade tjänster startar vanligtvis när en applikation kräver det. Men en startad typ av tjänst utför vanligtvis bara en enda operation och returnerar ingenting.
Bundna tjänster
Begränsade tjänster erbjuder ett gränssnitt mellan klient-serverrelationer. Bound service körs tills förgrundsapplikationen körs och sedan stoppas den när applikationsaktiviteten förstörs.
Systemtjänsterna hos Android tillhandahåller nödvändig information till användarapplikationerna för att de ska fungera korrekt. Och denna kommunikation mellan systemtjänsterna och användarapplikationerna sker med hjälp av Binder IPC från Kernel. Nu kan det överraska, men inte alla applikationer i en Android skrivs i Java. Vissa av dem är skrivna i C och C ++. De applikationer som måste vara i nära kontakt med hårdvaran skrivs i C och C ++. Det främsta skälet till detta beror på att systemtjänsterna för det mesta behöver vara i ständig kontakt med hårdvaran. Detta gör det viktigt att det sammanställda kodstycket är extremt snabbt. Och när det gäller maskinvaruacceleration och högprestanda är C mycket snabbare än Java eller något annat språk där ute.
Hårdvaratjänster som används i ständig användning, till exempel: Närhetssensorer, accelerometer eller pekskärm måste skrivas i C. Annan hårdvara som kameran eller ljudet använder sig mest av JNI-samtal. Om du någonsin märker det kommer pekskärmarna alltid att vara snabbare än att starta en kamera eller spela en låt via en musikspelare.
När du skapar en systemtjänst ska du notera att tjänster tenderar att köras i huvudprocessen och att den inte skapar en separat process. Kort sagt, om din kod kommer att göra lite CPU- och GPU-intensivt arbete, till exempel, High Definition-spel, bör du föredra att skapa nya trådar i samma tjänst; annars är det alltid en stor chans att ha dialogrutan ”App svarar inte”.
Rekommenderade kurser
- Utbildning för IT-säkerhetscertifiering
- Komplett Ruby on Rails-kurs
- Professionell CSS-utbildning
- Program på HTML5 och CSS3
Hårdvaraabstraktionslager
HAL eller Hardware Abstraction Layer är specifikt utformat för leverantörer. App-utvecklare har lite eller nästan ingenting att göra här. Detta lager hjälper till att infoga funktionalitet utan att göra några ändringar i systemet. Varje annat system har en annorlunda utformad HAL eftersom de är enhetsspecifika. HAL består av två typiska strukturer: Modul och enhet.
Modulstrukturen i HAL lagras som ett delat bibliotek i .so-format som består av de grundläggande metadata som versionnummer, författare som designade modulen och liknande grejer. Enhetsstrukturen är produktens faktiska hårdvara. Liknar den för modulen, men enhetsstrukturen definierar en mer omfattande version av den generiska maskinvaruinformationen som innehåller pekare och andra liknande saker som är speciella för varje hårdvara.
I Linux kommunicerar applikationer med den underliggande hårdvaran genom systemsamtal. Men i ett Android-operativsystem kommunicerar applikationerna med hårdvaran via Java-API: er.
Linux-kärnan
Att sammanställa en Linux-kärna för ett Android-operativsystem liknar den att kompilera den för ett grundläggande Linux-operativsystem. Den enda skillnaden är att Android-versionen är lite mer avancerad än Linux. Det främsta skälet är att Android-kärnan består av ytterligare funktioner som Wakelocks, dubbelknack för att låsa upp och andra liknande funktioner som är inbäddade i den mobila operativa enheten. Funktioner som wakelock är viktiga eftersom kärnan kommer att fungera på en bärbar enhet och den måste vara lite mer aggressiv när det gäller minne och batterihantering; till skillnad från det grundläggande Linux där energihantering inte är ett problem. Dessa ytterligare krav induceras i kärnan snarare än i systemet eftersom dessa saker inte bör påverka de inbyggda drivrutinerna.
När du hör en person som säger "sin Linux" menar de vanligtvis kärnan eftersom den är den mest grundläggande fortfarande den viktigaste delen av alla operativsystem. Det främsta skälet till att Android är baserat på Linux-kärnan är att den är öppen källkod. Vem som helst kan gå vidare och ändra Linux-kärnan utan någon hårdvarubegränsning eller ens några royaltyfrågor.
Skillnaden mellan Linux och Android
Så nu har vi äntligen nått det mest förvirrande skedet på denna blogg: Linux kontra Android. Folk brukar betrakta Android som en Linux-distribution, men jag skulle säga att de bara har 50% rätt. Närhelst androidoperativsystemet startar, laddar det i princip kärnan som någon annan Linux-distribution, men resten av programvaran är helt annorlunda än Linux. Linux-applikationer körs inte på Android och vice versa såvida de inte är kompilerade i en chroot-miljö. Biblioteken som finns i en Linux-distro och Android skiljer sig helt från varandra. I grund och botten kan du inte få tillgång till rotterminalen i Android på samma sätt som för Linux. Detta är det främsta skälet till att människor vanligtvis installerar Busybox, SuperSU och dess binärer efter rooting så att de har en mer detaljerad kommandorad åtkomst till kärnan och skalet. Det finns inget standardskal i Android, men du kan få ett genom att installera en terminalemulator från google play store. Terminalemulator ser så här ut:
Android-runtime fungerar på en Dalvik Virtual Machine. Denna Dalvik VM är faktiskt en tolk för Java-programmeringsspråket. Hela androidkörningen är skriven i Java i Android, och eftersom alla applikationer av Android skrivs i Java blir det mycket lättare och smidigt för applikationerna att köra i den virtuella miljön. Och eftersom alla applikationer och till och med runtime är skriven i Java blir det mycket lättare för alla utvecklare att anpassa varenda bit av Android-operativsystemet. Android är vanligtvis utformad för att vara ett enda operativsystem (till skillnad från klubban och marshmallow där det kan finnas flera användare.) För att faktiskt göra det enklare, låt mig sätta det i den här formen. Android-applikationer är ingenting annat än Linux-processer i slutet och det är så de tenderar att fungera. Och eftersom jag har sagt ovan att varje app har sin egen process blir det lättare för kärnan att skapa en separat UID för varje process och hantera applikationsfilerna och minnet utan extra ansträngning.
Det finns faktiskt mer än det grunderna för Android-operativsystemet som jag har nämnt ovan. Android har en kärnprocess som kallas 'Zygote' och utmärker sig vad den gör. Denna process startar faktiskt med initialiseringskommandon när Android startar. Jag kommer inte att gå in på mycket detalj här, men jag tror att grunderna i Android-operativsystemet faktiskt är tillräckligt för att du kan komma igång med Android. För att få mer information kan du faktiskt besöka source.android.com och utvecklare.android.com som är den officiella webbplatsen från google för alla uppdateringar på Android.
Rekommenderade artiklar
Här är några artiklar som hjälper dig att få mer information om Android-operativsystemet så bara gå igenom länken.
- HTML5 vs Flash - hur de är olika
- Topp 8 användbara Office Suite-applikationer för din Android
- Topp 5 gratis Android-emulatorer för PC
- Androidintervjufrågor - Topp 10 användbara frågor
- Karriärer inom Android-utveckling
- Topp 33 skillnader mellan iPhone och Android