Programmeringssprog dør ikke let, men udviklingsbutikker, der klamrer sig til falmende paradigmer, gør det. Hvis du udvikler apps til mobile enheder, og du ikke har undersøgt Swift, skal du være opmærksom på: Swift erstatter ikke kun Objective-C, når det kommer til at udvikle apps til Mac, iPhone, iPad, Apple Watch og enheder, der kommer, men det vil også erstatte C til indlejret programmering på Apple-platforme.
Takket være flere nøglefunktioner har Swift potentialet til at blive det de facto programmeringssprog til at skabe fordybende, lydhøre og forbrugervendte applikationer i de kommende år.
Apple ser ud til at have store mål for Swift. Det har optimeret kompilatoren til ydeevne og sprog for udvikling, og det henviser til, at Swift er "designet til at skalere fra 'hej verden' til et helt operativsystem" i Swifts dokumentation. Mens Apple endnu ikke har udtalt alle sine mål for sproget, signalerer lanceringerne af Xcode 6, Playgrounds og Swift Apples hensigt om at gøre appudvikling nemmere og mere tilgængelig end med nogen anden udviklingsværktøjskæde.
Her er 10 grunde til at komme foran spillet ved at begynde at arbejde med Swift nu.
1. Swift er lettere at læse
Objective-C lider under alle de vorter, du forventer af et sprog, der er bygget på C. For at skelne mellem søgeord og typer fra C-typer introducerede Objective-C nye søgeord ved hjælp af @ -symbolet. Fordi Swift ikke er bygget på C, kan den samle alle nøgleordene og fjerne de mange @ symboler foran hver Objective-C-type eller objektrelateret søgeord.
Swift dråber ældre konventioner. Således har du ikke længere brug for semikolon for at afslutte linjer eller parenteser for at omgive betingede udtryk inde i if / else-udsagn. En anden stor ændring er, at metodeopkald ikke nestes inde i hinanden, hvilket resulterer i beslag helvede - farvel, [[[ ]]]. Metode- og funktionsopkald i Swift bruger den industristandard kommaseparerede liste over parametre inden for parentes. Resultatet er et renere, mere udtryksfuldt sprog med en forenklet syntaks og grammatik.
Swift-kode ligner mere naturlig engelsk ud over andre moderne populære programmeringssprog. Denne læsbarhed gør det lettere for eksisterende programmører fra JavaScript, Java, Python, C # og C ++ at indføre Swift i deres værktøjskæde - i modsætning til den grimme ælling, der var Objective-C.
2. Swift er lettere at vedligeholde
Arv er det, der holder Objective-C tilbage - sproget kan ikke udvikle sig, uden at C udvikler sig. C kræver, at programmører opretholder to kodefiler for at forbedre byggetiden og effektiviteten af oprettelsen af den eksekverbare app, et krav, der overføres til Objective-C.
Swift slipper kravet om to filer. Xcode og LLVM-compileren kan finde ud af afhængigheder og udføre inkrementelle builds automatisk i Swift 1.2. Som et resultat hører den gentagne opgave med at adskille indholdsfortegnelsen (headerfil) fra kroppen (implementeringsfil) fortiden. Swift kombinerer Objective-C header (.h) og implementeringsfiler (.m) i en enkelt kodefil (.swift).
Objective-C's to-filsystem pålægger programmører yderligere arbejde - og det er arbejde, der distraherer programmører fra det større billede. I Objective-C skal du manuelt synkronisere metodenavne og kommentarer mellem filer, forhåbentlig ved hjælp af en standardkonvention, men dette er ikke garanteret, medmindre holdet har regler og kodevurderinger på plads.
Xcode og LLVM-kompilatoren kan arbejde bag kulisserne for at reducere arbejdsbelastningen på programmøren. Med Swift gør programmører mindre bogføring og kan bruge mere tid på at skabe applogik. Swift udskærer kedelpladearbejde og forbedrer kvaliteten af kode, kommentarer og funktioner, der understøttes.
3. Swift er sikrere
Et interessant aspekt af Objective-C er den måde, hvorpå henvisninger - især nul (nul) pegere - håndteres. I Objective-C sker der intet, hvis du prøver at kalde en metode med en markørvariabel, der er nul (ikke-initialiseret). Udtrykket eller kodelinjen bliver en no-operation (no-op), og selvom det kan synes nyttigt, at det ikke går ned, har det været en enorm kilde til fejl. En no-op fører til uforudsigelig opførsel, som er fjenden til programmører, der prøver at finde og rette et tilfældigt nedbrud eller stoppe uregelmæssig adfærd.
Valgfrie typer gør muligheden for en nul valgfri værdi meget tydelig i Swift-kode, hvilket betyder, at den kan generere en compiler-fejl, når du skriver dårlig kode. Dette skaber en kort feedback-sløjfe og giver programmører mulighed for at kode med hensigt. Problemer kan løses, når koden skrives, hvilket i høj grad reducerer den tid og penge, du vil bruge på at rette bugs relateret til pointerlogik fra Objective-C.
Traditionelt var det i Objective-C, hvis en værdi blev returneret fra en metode, det var programmørens ansvar at dokumentere opførslen for den returnerede markørvariabel (ved hjælp af kommentarer og metode-navngivningskonventioner). I Swift gør de valgfri typer og værdityper det tydeligt klart i metodedefinitionen, om værdien findes, eller hvis den har potentialet til at være valgfri (dvs. værdien kan eksistere, eller den kan være nul).
For at give forudsigelig adfærd udløser Swift et runtime-nedbrud, hvis der anvendes en nul valgfri variabel. Dette nedbrud giver ensartet adfærd, hvilket letter fejlrettelsesprocessen, fordi det tvinger programmøren til at løse problemet med det samme. Swift-runtime-nedbrud stopper på kodelinjen, hvor en nul valgfri variabel er blevet brugt. Dette betyder, at fejlen bliver rettet hurtigere eller helt undgås i Swift-kode.
4. Swift er forenet med hukommelsesstyring
Swift forener sproget på en måde, som Objective-C aldrig har gjort. Support til automatisk referencetælling (ARC) er komplet på tværs af de proceduremæssige og objektorienterede kodestier. I Objective-C understøttes ARC inden for Cocoa API'er og objektorienteret kode; det er dog ikke tilgængeligt for proceduremæssig C-kode og API'er som Core Graphics. Dette betyder, at det bliver programmørens ansvar at håndtere hukommelsesstyring, når man arbejder med Core Graphics API'er og andre API'er på lavt niveau, der er tilgængelige på iOS. De enorme hukommelseslækager, som en programmør kan have i Objective-C, er umulige i Swift.
En programmør skal ikke være nødt til at tænke på hukommelse for hvert digitalt objekt, han eller hun opretter. Da ARC håndterer al hukommelsesadministration på kompileringstidspunktet, kan den hjernekraft, der ville være gået mod hukommelsesadministration, i stedet fokuseres på kernelogik og nye funktioner. Da ARC i Swift fungerer på tværs af både proceduremæssig og objektorienteret kode, kræver det ikke flere mentale kontekstomskiftere for programmører, selvom de skriver kode, der berører API'er på lavere niveau - et problem med den nuværende version af Objective-C.
Automatisk og højtydende hukommelsesstyring er et problem, der er løst, og Apple har bevist, at det kan øge produktiviteten. Den anden bivirkning er, at både Objective-C og Swift ikke lider af en Garbage Collector, der kører oprydning for ubrugt hukommelse, som Java, Go eller C #. Dette er en vigtig faktor for ethvert programmeringssprog, der vil blive brugt til lydhør grafik og brugerinput, især på en taktil enhed som iPhone, Apple Watch eller iPad (hvor forsinkelse er frustrerende og får brugerne til at opleve, at en app er brudt).
5. Swift kræver mindre kode
Swift reducerer den mængde kode, der kræves til gentagne udsagn og strengmanipulation. I Objective-C er arbejde med tekststrenge meget detaljeret og kræver mange trin for at kombinere to stykker information. Swift vedtager moderne programmeringssprogsfunktioner som at tilføje to strenge sammen med en "+" operator, som mangler i Objective-C. Understøttelse af kombination af tegn og strenge som denne er grundlæggende for ethvert programmeringssprog, der viser tekst til en bruger på en skærm.
Typesystemet i Swift reducerer kompleksiteten af kodesætninger - da kompilatoren kan finde ud af typer. Som et eksempel kræver Objective-C, at programmører husker specielle strengetokens (% s, % d, %@) og give en komma-adskilt liste over variabler, der skal erstatte hvert token. Swift understøtter strenginterpolering, hvilket eliminerer behovet for at huske tokens og gør det muligt for programmører at indsætte variabler direkte inline til en brugervendt streng, såsom en etiket eller en knaptitel. Typeinferencesystemet og strenginterpolering afbød en almindelig kilde til nedbrud, der er almindelige i Objective-C.
Med Objective-C får rod i ordren eller ved hjælp af det forkerte strengetoken, at appen går ned. Her fritager Swift dig igen fra bogføringsarbejde og oversætter til mindre kode at skrive (kode, der nu er mindre tilbøjelig til fejl) på grund af dens integrerede understøttelse til manipulation af tekststrenge og data.
6. Swift er hurtigere
At droppe ældre C-konventioner har forbedret Swift under emhætten. Benchmarks for Swift-kodeydelse peger fortsat på Apples dedikation til at forbedre den hastighed, hvormed Swift kan køre applogik.
Ifølge Primate Labs, producenter af det populære GeekBench-præstationsværktøj, nærmede Swift sig præstationsegenskaberne for C ++ til beregningsopgaver i december 2014 ved hjælp af Mandelbrot-algoritmen.
I februar 2015 opdagede Primate Labs, at Xcode 6.3 Beta forbedrede Swifts ydeevne for GEMM-algoritmen - en hukommelsesbundet algoritme med sekventiel adgang til store arrays - med en faktor på 1,4. Den indledende FFT-implementering - en hukommelsesbundet algoritme med tilfældig adgang til store arrays - havde en 2,6 gange forbedring af ydeevnen.
Yderligere forbedringer blev observeret i Swift ved at anvende bedste praksis, hvilket resulterede i en 8,5-fold boost for FFT-algoritmepræstation (hvilket efterlod C ++ med kun en 1,1-gangs præstationsforøgelse). Forbedringerne gjorde det også muligt for Swift at overgå C ++ for Mandelbrot-algoritmen med en faktor på kun 1,03.
Swift er næsten på niveau med C ++ for både FFT- og Mandelbrot-algoritmerne. Ifølge Primate Labs antyder GEMM-algoritmens ydeevne, at Swift-kompilatoren ikke kan vektorisere kode, som C ++ -compileren kan - en let præstationsforøgelse, der kan opnås i den næste version af Swift.
7. Færre navnekollisioner med open source-projekter
Et problem, der har plaget Objective-C-koden, er manglen på formel understøttelse af navneområder, som var C ++ 's løsning på kodefilkollisioner. Når dette navnekollision sker i Objective-C, er det en linkerfejl, og appen kan ikke køre. Løsninger findes, men de har potentielle faldgruber. Den almindelige konvention er at bruge et to- eller tre-bogstavs-præfikser til at differentiere Objective-C-kode, der f.eks. Er skrevet af Facebook versus din egen kode.
Swift leverer implicitte navneområder, der gør det muligt at eksistere den samme kodefil på tværs af flere projekter uden at forårsage en byggefejl og kræve navne som NSString (Næste trin - Steve Jobs 'virksomhed efter fyring fra Apple) eller CGPoint (Core Graphics). I sidste ende holder denne funktion i Swift programmører mere produktive og betyder, at de ikke behøver at foretage den bogføring, der findes i Objective-C. Du kan se Swifts indflydelse med enkle navne som Array, Dictionary og String i stedet for NSArray, NSDictionary og NSString, som blev født på grund af manglen på navneområder i Objective-C.
Med Swift er navneområder baseret på det mål, som en kodefil tilhører. Dette betyder, at programmører kan differentiere klasser eller værdier ved hjælp af navneområdet identifikator. Denne ændring i Swift er enorm. Det letter i høj grad at inkorporere open source-projekter, rammer og biblioteker i din kode. Navneområderne gør det muligt for forskellige softwarevirksomheder at oprette de samme kodefilnavne uden at bekymre sig om kollisioner, når de integrerer open source-projekter. Nu kan både Facebook og Apple bruge en objektkodefil kaldet FlyingCar.swift uden fejl eller opbygningsfejl.
8. Swift understøtter dynamiske biblioteker
Den største ændring i Swift, der ikke har fået tilstrækkelig opmærksomhed, er skiftet fra statiske biblioteker, der opdateres ved større punktudgivelser (iOS 8, iOS 7 osv.), Til dynamiske biblioteker. Dynamiske biblioteker er eksekverbare klumper af kode, der kan linkes til en app. Denne funktion gør det muligt for aktuelle Swift-apps at linke mod nyere versioner af Swift-sproget, når det udvikler sig over tid.
Udvikleren sender appen sammen med bibliotekerne, som begge er signeret digitalt med udviklingscertifikatet for at sikre integritet (hej, NSA). Dette betyder, at Swift kan udvikle sig hurtigere end iOS, hvilket er et krav for et moderne programmeringssprog. Ændringer i bibliotekerne kan alle medtages i den seneste opdatering af en app i App Store, og alt fungerer bare.
Dynamiske biblioteker er aldrig blevet understøttet på iOS indtil lanceringen af Swift og iOS 8, selvom dynamiske biblioteker har været understøttet på Mac i meget lang tid. Dynamiske biblioteker er eksterne end den eksekverbare app, men er inkluderet i den app-pakke, der downloades fra App Store. Det reducerer den oprindelige størrelse på en app, da den indlæses i hukommelsen, da den eksterne kode kun er linket, når den bruges.
Evnen til at udskyde indlæsning i en mobilapp eller en integreret app på Apple Watch vil forbedre den opfattede ydeevne for brugeren. Dette er en af forskellene, der gør iOS-økosystemet mere følsomt. Apple har været fokuseret på kun at indlæse aktiver, ressourcer og nu kompileret og linket kode på farten. On-the-fly-belastningen reducerer de indledende ventetider, indtil der faktisk er behov for en ressource, der skal vises på skærmen.
