Introduksjon til Android-operativsystem
Operativsystemet Android er et åpen kildekode-system. Mange sier at det er Linux, men det er ikke helt sant. Selv om Android har kjerner som ligner på Linux, er det det eneste som ligner. I dag skal vi se nærmere på innsiden av Android-operativsystemet som er prosessene, rammeverket og andre lignende strukturer. Så la oss komme i gang helt fra det grunnleggende og se til den indre roten til Android-operativsystemet.
Etter utgivelsen av iPhone og Windows Lumia Series, dvs. Microsoft Windows-relaterte telefoner, ønsket Google å gjøre det samme. Men de ville ha noe som kunne være åpen kildekode. Hovedårsaken bak dette var slik at hvem som helst kunne feilsøke den, endre den eventuelle endringer som de ønsket. Så kom ideen om Linux. Linux er et fullstendig åpen kildekode-operativsystem, og det er allment akseptert av samfunnet over hele verden. Det er et av disse operativsystemene som brukes enda mer enn Windows eller Mac OSX. Dessuten har Linux muligheten til å kjøre nesten alle andre ting som kan kjøres på enten Mac eller Windows. Dermed bestemte Google seg for å utvikle et operativsystem for en mobiltelefon med samme grunnleggende indre skall som Linux, slik at det er kompatibelt med nesten alt og det ytre skallet vil bli utviklet som, når og også hvordan det kreves.
Android-operativsystem som et åpen kildekode-prosjekt (AOSP)
Android har muligheten til fritt å endre, oppfinne og implementere våre egne enhetsdrivere og funksjoner. Nå å snakke om, det er fem forskjellige lag av et Android-operativsystem. Det går som følger:
Som du kan se i bildet over, er det første laget Application Framework, det andre er Binder IPC Proxies, det tredje består av Android System Services, det fjerde er HAL eller den fullstendige formen er Hardware Abstraction Layer, og den siste å være Linux-kjernen. Nå som jeg sa tidligere, kan du se at den eneste delen av Linux som et Android-operativsystem består av er Linux Kernel. La oss se nærmere på dem alle en etter en.
Android Application Framework
Denne apprammen brukes av apputviklere for Android. Denne delen av Android har i det minste å gjøre noe med maskinvarelaget. Android-applikasjoner er programmert på Java-språk. Etter å ha programmert en app, hjelper Android SDK-verktøyene med å samle dataene og ressursfilene som XML-filer, krukkefilene, manifestfiler og andre bilder og sånt i en enkelt arkivpakke med en .apk-utvidelse. Denne apk-filen kan brukes til å installere appen med bare et enkelt klikk på Android-enhetene. Siden Android-operativsystemet oppfører seg som et Linux-miljø, er appens oppførsel også den samme her. Hver app regnes som en egen bruker fra den andre og kjører i sin egen virtuelle maskin. Dette gjør den programmerte koden til appen isolert og forhindrer også at den smittes fra andre med mindre eksplisitt er oppgitt. Hver annen app har sin egen BRUKER-ID, og annenhver prosess har sin egen virtuelle maskin.
Android Application Framework fungerer etter prinsippet om minst mulig privilegium. Least Privilege Principle betyr at når en ny app trenger å kjøres, men det ikke er tilgjengelig minne, vil Android-systemet automatisk avslutte det gamle programmet som ikke er nødvendig å kjøre i bakgrunnen. Dette er en av de beste delene av Android-operativsystemets sikkerhet. Dette prinsippet gjør det mulig at hver app bare har den tilgangen som kreves for å gjøre sitt arbeid. Dermed kan en app ikke få tillatelse til det som ikke er ment å gjøre. Dette skaper på sin side et veldig sikkert miljø i selve Android-operativsystemet.
Binder IPC er kjent som Binder inter-prosesskommunikasjon. Dette grensesnittet lar en programmerer lage et program for å kommunisere med andre applikasjoner. Oftere er det ikke applikasjonene som kommuniserer, det er prosessene. Binder IPC hjelper til med å kjøre flere prosesser samtidig på et samtidig nivå. Denne bindemiddelimplementeringen er hentet gjennom kjernen til Android-operativsystemet. Nå har det blitt stilt spørsmål om hvorfor trenger bindemiddelet å bli i kjernen, og hvorfor kan det ikke løpe fra Linux IPC-mekanismene? Hovedårsaken til det er fordi bindemidlet unngår å bruke unødvendig allokering av plass i motsetning til andre IPC-mekanismer i Linux-systemet. Hvis du har hørt om begrepet 'magi i pyton', er det slik en Binder IPC vil se ut for en applikasjonsutvikler, siden det er helt skjult for dem, og det ser ut til å virke, i motsetning til høynivårammen der må du få det til å fungere eksplisitt. Dette gjør det mulig for høynivårammen å kommunisere med Android-operativsystemtjenestene.
Systemtjenester til Android-operativsystem
En tjeneste er et samlet stykke kode som kjøres i lang tid i bakgrunnen til et Android-operativsystem uten å gi noe grensesnitt. Enhver applikasjon, det kan være bruker eller system kan starte en tjeneste, men den vil fortsatt fortsette å gå i bakgrunnen selv om applikasjonen er lukket. Imidlertid er det to typer tjenester:
Startede tjenester
Startede tjenester starter vanligvis når en applikasjon krever det. Imidlertid utfører en oppstartstype vanligvis bare en enkelt operasjon og returnerer ikke noe.
Bundne tjenester
Begrensede tjenester tilbyr et grensesnitt mellom klient og server. Begrenset tjeneste kjøres til forgrunnen-applikasjonen kjøres, og deretter stoppes den når applikasjonsaktiviteten er ødelagt.
Systemtjenestene til Android gir nødvendig informasjon til brukerapplikasjonene for at de skal fungere ordentlig. Og denne kommunikasjonen mellom systemtjenestene og brukerapplikasjonene gjøres ved hjelp av Binder IPC fra Kernel. Nå kan det komme overraskende, men ikke alle applikasjoner i en Android er skrevet i Java. Noen av dem er skrevet i C og C ++. De applikasjonene som må være i nærkontakt med maskinvaren er skrevet i C og C ++. Hovedårsaken til dette er fordi det meste av tiden systemtjenestene trenger å være i kontinuerlig kontakt med maskinvaren. Dette gjør det viktig at det kompilerte koden er ekstremt raskt. Og når det kommer til maskinvareakselerasjon og høy ytelse, er C mye raskere enn Java eller noe annet språk der ute.
Maskinvaretjenester som er i konstant bruk, for for eksempel: Nærhetssensorer, akselerometer eller berøringsskjerm må skrives i C. Andre maskinvarer som kameraet eller lyden bruker stort sett JNI-samtaler. Så hvis du noen gang legger merke til det, vil berøringsskjermene alltid være raskere enn å starte kamera eller spille en sang via en musikkspiller.
Når du oppretter en systemtjeneste, må du notere at tjenester har en tendens til å kjøre i hovedprosessen, og at den ikke oppretter en egen prosess. Kort sagt, hvis koden din skal utføre noe CPU- og GPU-intensivt arbeid, for eksempel High Definition-spill, bør du foretrekke å lage nye tråder i samme tjeneste; ellers vil det alltid være stor sjanse for å ha dialogboksen “App svarer ikke”.
Anbefalte kurs
- Opplæring i IT-sikkerhetssertifisering
- Fullfør Ruby on Rails-kurs
- Profesjonell CSS-trening
- Program på HTML5 og CSS3
Maskinvareabstraksjonslag
HAL eller Hardware Abstraction Layer er spesielt designet for leverandører. Programutviklere har lite eller nesten ingenting å gjøre her. Dette laget hjelper til med å sette inn funksjonalitet uten å ha noen endringer i systemet. Hvert annet system har en forskjellig designet HAL siden de er laget enhetsspesifikke. HAL består av to typiske strukturer: Modul og enhet.
Modulstrukturen i HAL lagres som et delt bibliotek i .so format som består av de grunnleggende metadataene som versjonsnummer, forfatter som har designet modulen og lignende ting. Enhetsstrukturen er den faktiske maskinvaren til produktet. I likhet med modulen, men enhetsstrukturen definerer en mer omfattende versjon av generisk maskinvareinformasjon som inneholder pekere og andre lignende ting som er spesielle for enhver maskinvare.
I Linux kommuniserer applikasjoner med den underliggende maskinvaren gjennom systemanrop. Men i et Android-operativsystem kommuniserer applikasjonene med maskinvaren via Java API-er.
Linux-kjerne
Å sammenstille en Linux-kjerne for et Android-operativsystem ligner på det å kompilere den for et grunnleggende Linux OS. Den eneste forskjellen er at Android-versjonen er litt mer avansert enn for Linux. Den viktigste grunnen til å være androidkjernen består av tilleggsfunksjoner som wakelocks, dobbelttrykk for å låse opp og andre lignende funksjoner som er innebygd i den mobile driftsenheten. Funksjoner som wakelock er viktige siden kjernen kommer til å fungere på en bærbar enhet og den må være litt mer aggressiv i hukommelse og batteristyring; i motsetning til den grunnleggende Linux der energiledelse ikke er et problem. Disse tilleggskravene induseres i kjernen i stedet for i systemet, siden disse tingene ikke bør påvirke de innebygde driverne.
Når du hører en person som sier "sin Linux", mener de vanligvis kjernen, siden den er den mest grunnleggende fremdeles den viktigste delen av ethvert operativsystem. Hovedårsaken til at Android er basert på Linux-kjernen er at den er åpen kildekode. Alle kan gå foran og endre Linux-kjernen uten maskinvarebegrensning eller til og med noen royaltyproblemer.
Forskjell mellom Linux vs Android
Så nå har vi endelig nådd det mest forvirrende stadiet i denne bloggen: Linux vs Android. Folk ser vanligvis på Android som en Linux-distribusjon, men jeg vil si at de bare har 50% rett. Når Android-operativsystemet starter, laster det i utgangspunktet kjernen som all annen Linux-distribusjon, men resten av programvaren er helt annerledes enn Linux. Linux-applikasjoner kjøres ikke på Android og omvendt med mindre de er samlet i et chroot-miljø. Bibliotekene som er til stede i en Linux-distro og Android er helt forskjellige fra hverandre. I utgangspunktet kan du ikke få tilgang til rotterminalen i Android som for Linux. Dette er hovedgrunnen til at folk vanligvis installerer Busybox, SuperSU og binærene etter at de har forankret seg, slik at de har en mer detaljert kommandolinjeadgang til kjernen og skallet. Det er ikke noe standardskall i Android, men du kan få et ved å installere en terminalemulator fra google play store. Terminal Emulator ser slik ut:
Android-runtime fungerer på en Dalvik Virtual Machine. Denne Dalvik VM er faktisk en tolk for Java-programmeringsspråket. Hele Android-runtime er skrevet i Java i Android, og siden alle applikasjoner av Android er skrevet i Java, blir det mye enklere og smidigere for applikasjonene å kjøre i det virtuelle miljøet. Og siden alle applikasjoner og til og med runtime er skrevet i Java, blir det mye enklere for enhver utvikler å tilpasse hver eneste annen bit av Android-operativsystemet. Android-en ble vanligvis designet for å være et operativsystem med en enkelt bruker (i motsetning til lollipop og marshmallow der det kan være flere brukere.) For å gjøre dette enklere, la meg si det i denne formen. Android-applikasjoner er ikke annet enn Linux-prosesser på slutten, og det er slik de pleier å fungere. Og siden jeg har uttalt over at hver app har sin egen prosess, blir det lettere for kjernen å lage en egen UID for hver prosess og håndtere applikasjonsfilene og minnet uten ekstra krefter.
Det er faktisk mer enn dette grunnleggende om operativsystemet til Android som jeg har nevnt ovenfor. Android har en kjerneprosess som er kjent som 'Zygote' og den utmerker seg hva den gjør. Denne prosessen starter faktisk med initialiseringskommandoer når Android starter. Jeg vil ikke gå i detalj her, men jeg tror at det grunnleggende om operativsystemet til Android faktisk er nok til at du kan komme i gang med android. For å få mer informasjon, kan du faktisk besøke source.android.com og utviklere.android.com, som er den offisielle nettsiden fra google for enhver oppdatering på Android.
Anbefalte artikler
Her er noen artikler som vil hjelpe deg med å få mer detaljert informasjon om operativsystemet Android, så bare gå gjennom lenken.
- HTML5 vs Flash - hvordan de er forskjellige
- Topp 8 nyttige Office Suite-applikasjoner for Android
- Topp 5 gratis Android-emulatorer til PC
- Spørsmål om Android-intervju - Topp 10 nyttige spørsmål
- Karrierer innen Android-utvikling
- Topp 33 forskjeller mellom iPhone og Android