Share
En god forståelse av iOS SDK er nøkkelen når du utvikler native iOS-applikasjoner. Ikke bare vil det hjelpe deg med å velge de riktige verktøyene for å takle et bestemt problem, det vil også sørge for at du ikke går deg vill i de dusinvis av rammer som er inkludert i iOS SDK. I denne artikkelen zoomer vi inn på iOS-arkitekturen og finner ut hva som driver iOS-applikasjoner under hetten.
Jeg er ganske sikker på at selv noen erfarne iOS-utviklere ville ha det vanskelig å definere iOS SDK i en setning. Akronymet SDK står for Software Development Kden. IOS SDK inneholder verktøy og ressurser for å utvikle innfødte iOS-programmer, noe som betyr at SDK gjør at utviklere kan utvikle, installere, kjøre og teste programmer i iOS-simulatoren og på fysiske enheter.
De to drivkreftene som driver native iOS-programmer, er Objective-C og de innfødte iOS-systemene. I forrige artikkel undersøkte vi Objective-C programmeringsspråket. I denne artikkelen vil jeg utforske rammene som driver innfødte iOS-applikasjoner.
Dette inkluderer høyt nivå rammer, for eksempel UIKit og Kartsett rammebetingelser, men også rammer som er nært knyttet til maskinvaren, for eksempel Akselerere og Kjerneplassering rammer.
Du vet nå hva iOS SDK er, men hva gjør et program kvalifisert som et innfødt iOS-program? Det enkle svaret er at et iOS-program er et program som kjører på en iOS-enhet. Dette er imidlertid bare halv sannheten. Hva med webprogrammer som kjører i Safari-nettleseren?
Et iOS-program er et kakao-program utviklet for iOS-plattformen. Flott. Hva er en kakao søknad? En kakao applikasjon er litt vanskeligere å definere. Er det språket der søknaden er skrevet? Ikke egentlig. Er det verktøyene som en kakao applikasjon er bygget på? Nei. Det er mulig å utvikle en kakao-applikasjon uten hjelp av Xcode.
Apple definerer en kakaoapplikasjon som et program som består av objekter som til slutt arver fra NSObject, en rotklasse erklært i stiftelsesrammen, og det er basert på mål-C-kjøretiden.
I denne artikkelen vil jeg fokusere på rammene som brukes til å lage native iOS-programmer. Hvis du er interessert i å lære mer om Objective-C-kjøretiden, anbefaler jeg at du tar en titt på Apples Objective-C Runtime Reference eller les Objective-C Runtime Programmering Guide.
Stiftelsesrammen gir en andre rotklasse, NSProxy. Du vil imidlertid sjelden, om noensinne, bruke den i noen av prosjektene dine.
En annen forskjell med webprogrammer som kjører i Safari-nettleseren, er at de innfødte programmene samhandler direkte med iOS-operativsystemet og de innfødte iOS-systemrammene. Operativsystemet fungerer som en mediator mellom applikasjonen og den underliggende maskinvaren. En viktig fordel ved denne mekling eller abstraksjon er at innfødte programmer ikke trenger å bekymre seg for fremtidige maskinvareendringer eller enhetsspesifikasjoner.
Operativsystemet gir native programmer den nødvendige informasjonen om maskinvarefunksjonene (Har enheten et kamera?) Og enhetsspesifikasjoner (Skal programmet kjøre på iPhone eller iPad?).
IOS-arkitekturen kan deles opp i fire forskjellige lag:
Denne lagdelte arkitekturen illustrerer at abstraksjonsnivået, med høyere nivåer lagre mer abstraherte og lavere nivå lagene mer grunnleggende og nært knyttet til maskinvaren. Det står selvsagt at høyere nivå lagene stole på lavere nivå lag for noen av deres funksjonalitet.
Apple anbefaler å bruke rammene på høyere nivå så mye som mulig, fordi de ofte er objektorienterte abstraksjoner av lavere nivåer. Med andre ord påvirker de høyere nivåene lag indirekte med maskinvaren gjennom lagene på lavere nivå, som iboende er mer komplekse. Selvfølgelig er det fortsatt mulig å falle tilbake til rammene på lavere nivå hvis rammene på høyere nivå ikke tilfredsstiller dine behov.
Som en påminnelse er et rammeverk en katalog som inneholder et dynamisk delt bibliotek og ressursene knyttet til det, for eksempel headerfiler, bilder, etc. Rammer er tilgangspunkter til forskjellige systemgrensesnitt, for eksempel iOS adresseboken, enhetens kamera rulle og musikkbiblioteket.
I forrige artikkel skrev jeg om Cocoa Touch og dens forhold til Objective-C. I denne artikkelen vil jeg gjerne diskutere Cocoa Touch fra et mer funksjonelt synspunkt, hvordan applikasjoner er avhengige av Cocoa Touch-laget, og hvilken rolle det er i iOS-arkitekturen.
Cocoa Touch-laget er det øverste laget av iOS-arkitekturen. Den inneholder noen av de viktigste rammene som native iOS-applikasjoner stole på, med den mest fremtredende å være UIKit rammeverk.
Cocoa Touch-laget definerer grunnleggende applikasjonsinfrastruktur og gir en rekke vitale teknologier, for eksempel multitasking og touch-basert inngang.
Som jeg nevnte, er iOS-applikasjoner avhengig av UIKit-rammen. Native iOS-programmer kan ikke fungere hvis de ikke er koblet til UIKit og Foundation-rammene.
UIKit-rammen eller UIKit er skreddersydd for iOS-plattformen. Det er et tilsvarende rammeverk for OS X-plattformen som heter Søkesett eller AppKit rammeverk. UIKit gir infrastrukturen for grafiske, hendelsesdrevne iOS-applikasjoner. Det tar også vare på andre kjerneaspekter som er spesifikke for iOS-plattformen, for eksempel multitasking, push meldinger og tilgjengelighet.
Cocoa Touch-laget gir utviklere et stort antall funksjoner på høyt nivå, for eksempel automatisk oppsett, utskrift, gjenkjenningsmidler og dokumentstøtte. I tillegg til UIKit inneholder den blant annet Kart Kit, Event Kit og Message UI rammer.
For en komplett liste over alle rammene av Cocoa Touch-laget, vil jeg gjerne henvise til Apples IOS Technology Overview Guide.
Grafikk, lyd og video håndteres av medielaget. Dette laget inneholder et antall sentrale teknologier, som Core Graphics, OpenGL ES og OpenAL, AV Foundation og Core Media.
Medielaget inneholder et stort antall rammer, inkludert Assets Library-rammeverk for tilgang til enhets bilder og videoer, Core Image-rammen for bildemanipulering via filtre, og Core Graphics-rammen for 2D-tegning.
Ta en titt på Apples IOS Technology Overview Guide for en komplett liste over alle rammene i Media lag.
Core Services-laget har ansvaret for å administrere de grunnleggende systemtjenestene som native iOS-applikasjoner bruker. Cocoa Touch-laget er avhengig av Core Services-laget for noen av funksjonene. Core Services-laget gir også en rekke uunnværlige funksjoner, for eksempel blokkobjekter, Grand Central Dispatch, In-App Purchase og iCloud Storage.
En av de mest velkomne tilleggene til Core Services-laget er ARC eller ENutomatic Reference Counting. ARC er en kompilatorenivåfunksjon, introdusert i 2011 med utgivelsen av iOS 5. ARC forenkler prosessen med minnehåndtering i Objective-C.
Minnehåndtering er et emne vi ikke har dekket i denne serien, men det er viktig at du forstår grunnleggende om minnehåndtering når du utvikler kakaoapplikasjoner. Automatisk referansetelling er et flott tillegg, men det er viktig at du vet hva ARC gjør for deg.
Du kan lese mer om minnehåndtering i The Objective-C Programming Language guide og jeg anbefaler på det sterkeste at du gjør det.
Stiftelsens rammeverk eller stiftelse er et annet viktig rammeverk for iOS- og OS X-applikasjoner. I neste artikkel vil vi utforske dette rammeverket mer detaljert. Stiftelsens rammeverk er mer enn en samling av nyttige klasser, for eksempel NSArray, NSDictionary, og NSDate.
Stiftelsen gir NSObject root class, som gir et grunnleggende grensesnitt til Objective-C runtime, og det introduserer også flere paradigmer, for eksempel retningslinjer for objekt eierskap. Like Core Foundation (se nedenfor), gjør Foundation det mulig for de forskjellige biblioteker og rammer å enkelt dele data og kode.
Et annet viktig rammeverk av Core Services-laget og nært knyttet til Foundation-rammen er C-basert Core Foundation rammeverk eller Core Foundation. I likhet med stiftelsens rammeverk gjør det det mulig for de ulike bibliotekene og rammene å dele data og kode.
Core Foundation har en funksjon referert til som Tollfri bro, som gjør det mulig å bytte ut kakaoobjekter for Core Foundation-objekter i funksjonsparametere og omvendt.
For en komplett liste over alle rammene i Core Services-laget, vil jeg gjerne henvise til iOS Technology Overview Guide.
Det meste av funksjonaliteten som tilbys av de tre høyere nivå lagene er bygd på Core OS lag og dets lavt nivå funksjoner. Core OS-laget gir en håndfull rammer som søknaden din kan bruke direkte, som for eksempel akselerasjons- og sikkerhetsrammene.
Core OS-laget encapsulates også kjerne miljøet og UNIX-grensesnitt på lavt nivå som programmet ikke har tilgang til av åpenbare sikkerhetsgrunner. Men gjennom libSystem bibliotek, som er C-basert, kan mange lavnivåfunksjoner nås direkte, for eksempel BSD-stikkontakter, POSIX-tråder og DNS-tjenester.
Din nærmeste allierte når du utvikler native iOS-programmer, er dokumentasjonen inkludert i iOS SDK. For det meste er dokumentasjonen enestående, og det vil hjelpe deg med å få fart på en ny teknologi eller rammeverk med liten innsats.
Selv om dokumentasjonen er tilgjengelig på Internett, bruker de fleste utviklere dokumentasjonsleseren som er inkludert i Xcode. I Xcode 5 kan du finne dokumentasjonsleseren ved å velge Dokumentasjon og API-referanse fra Xcode er Vindu Meny.
Siden du bruker dokumentasjonen i stor grad, vil du kanskje lære noen få snarveier for å finne det du leter etter i dokumentasjonen. Som nevnt i forrige avsnitt, gir dokumentasjonsleseren enkel tilgang til dokumentasjonen. For raskt å få tilgang til dokumentasjonen, trykk Skift + Kommando + 0 i Xcode 5.
Mens du skriver kode i Xcode's kodeditor, kan det raskt bli tungvint å bytte frem og tilbake mellom kodeditoren og dokumentasjonsleseren hver gang du trenger å slå opp en klasse eller metode.
Det er to løsninger for effektiv surfing av dokumentasjonen. Når du plasserer markøren på et klasse- eller metodenavn i Xcode's kodeditor, Hurtig hjelpinspektør i høyre sidefelt viser et sammendrag av den respektive klassen eller metoden. Sammendraget inneholder flere nyttige koblinger som tar deg til dokumentasjonsleseren.
Fordi jeg vanligvis skjuler høyre sidefelt når jeg jobber i kodeditoren, bruker jeg en alternativ metode for å vise dokumentasjonen for en klasse eller metode. Når du trykker på Alternativ tast og svever over et klasse- eller metodenavn, endres markørene til et spørsmålstegn og klassen eller metodenavnet er uthevet. Ved å klikke på et klasse- eller metodenavn med spørsmålet, vises et nytt vindu som inneholder samme oppsummering som Hurtig hjelpinspektør. Ved å klikke på en av koblingene i vinduet, går du til dokumentasjonsleseren. Dette er en rask og enkel måte å bytte mellom kodeditoren og dokumentasjonsleseren, spesielt når du arbeider med to skjermer.
Du bør nå ha en god forståelse av iOS SDK og de ulike lagene i iOS-arkitekturen. De to kjernerammene for en iOS-applikasjon, UIKit og Foundation, er fokus for de neste to delene av denne serien.
Ikke bare er disse rammene uunnværlige for alle iOS-applikasjoner, de inneholder dusinvis av klasser som du vil finne deg selv ved å bruke ofte når du utvikler native iOS-programmer.
Accentsconagua