Programmēšanas valodas nemirst viegli, bet attīstības veikali, kas turas pie izbalinošām paradigmām, to dara. Ja jūs izstrādājat mobilajām ierīcēm paredzētas lietotnes un neesat izpētījis Swift, ņemiet vērā: Swift ne tikai aizstās Objective-C, izstrādājot lietotnes Mac, iPhone, iPad, Apple Watch un nākamajām ierīcēm, bet tas arī aizstās C iegulto programmēšanu Apple platformās.
Pateicoties vairākām galvenajām iezīmēm, Swift ir potenciāls kļūt par de facto programmēšanas valodu, lai nākamajos gados izveidotu visaptverošas, atsaucīgas un patērētājiem piemērotas lietojumprogrammas.
Apple, šķiet, ir Swift lielie mērķi. Tas ir optimizējis kompilatoru veiktspējai un valodas attīstībai, un tas atsaucas uz to, ka Swift ir Swift dokumentācijā “paredzēts mērogot no“ sveiki, pasaule ”uz visu operētājsistēmu”. Lai gan Apple vēl nav norādījis visus savus valodas mērķus, Xcode 6, Playgrounds un Swift izlaišana kopā norāda uz Apple nodomu padarīt lietotņu izstrādi vieglāku un pieejamāku nekā ar jebkuru citu izstrādes rīku ķēdi.
Šeit ir 10 iemesli, kā sasniegt spēli, sākot strādāt ar Swift tagad.
1. Swift ir vieglāk lasāms
Objective-C cieš visas kārpas, kuras varētu sagaidīt no valodas, kas veidota uz C. Lai atšķirtu atslēgvārdus un veidus no C tipiem, Objective-C ieviesa jaunus atslēgvārdus, izmantojot simbolu @. Tā kā Swift nav veidots uz C, tas var apvienot visus atslēgvārdus un noņemt daudzos simbolus @ katra objekta C tipa vai ar objektu saistītā atslēgvārda priekšā.
Swift pilieni mantojuma konvencijas. Tādējādi jums vairs nav nepieciešami semikoli, lai beigtu rindas vai iekavas, lai ieskautu nosacītās izteiksmes if / else paziņojumos. Vēl viena liela izmaiņa ir tā, ka metožu izsaukumi nav ligzdo viens otra iekšienē, kā rezultātā rodas iekavu elle - uz redzēšanos, [[[ ]]]. Metodes un funkciju izsaukumi programmā Swift iekavās izmanto nozares standarta ar komatiem atdalītu parametru sarakstu. Rezultāts ir tīrāka, izteiksmīgāka valoda ar vienkāršotu sintaksi un gramatiku.
Papildus citām mūsdienu populārajām programmēšanas valodām Swift kods vairāk atgādina dabisko angļu valodu. Šī lasāmība ļauj esošajiem programmētājiem no JavaScript, Java, Python, C # un C ++ vieglāk uzņemt Swift savā rīku ķēdē - atšķirībā no neglītā pīlēna, kas bija Objective-C.
2. Swift ir vieglāk uzturēt
Mantojums ir tas, kas kavē Objective-C - valoda nevar attīstīties bez C attīstīšanās. C prasa, lai programmētāji uzturētu divus koda failus, lai uzlabotu izpildāmās lietotnes izveidošanas laiku un efektivitāti - prasība, kas tiek pārnesta uz C mērķi.
Swift atceļ divu failu prasību. Xcode un LLVM kompilators var izdomāt atkarības un automātiski veikt papildinošus veidojumus Swift 1.2. Tā rezultātā atkārtots uzdevums atdalīt satura rādītāju (galvenes failu) no pamatteksta (ieviešanas faila) ir pagātne. Swift apvieno Objective-C galveni (.h) un ieviešanas failus (.m) vienā koda failā (.swift).
Object-C divu failu sistēma uzliek papildu darbu programmētājiem - un tas ir tas, kas novērš programmētāju uzmanību no kopējās ainas. Objektīvā C jums manuāli jāinhronizē metožu nosaukumi un komentāri starp failiem, cerams, izmantojot standarta konvenciju, taču tas netiek garantēts, ja komandā nav ieviesti noteikumi un kodu pārskati.
Xcode un LLVM kompilators var paveikt darbu aizkulisēs, lai samazinātu programmētāja darba slodzi. Izmantojot Swift, programmētāji veic mazāk grāmatvedības uzskaites un var pavadīt vairāk laika, veidojot lietotņu loģiku. Swift pārtrauc katlu darbu un uzlabo atbalstīto kodu, komentāru un funkciju kvalitāti.
3. Swift ir drošāks
Viens no interesantajiem C-mērķa aspektiem ir veids, kā tiek apstrādāti rādītāji, īpaši nulles (nulles) rādītāji. Objektīvā-C nekas nenotiek, ja mēģināt izsaukt metodi ar rādītāja mainīgo, kas ir nulle (neinicializēts). Koda izteiksme vai rindiņa kļūst par bezdarbību (no-op), un, lai arī var šķist izdevīgi, ka tas neizdodas, tas ir bijis milzīgs kļūdu avots. Bez opcijas rodas neprognozējama rīcība, kas ir programmētāju ienaidnieks, kas mēģina atrast un novērst nejaušu avāriju vai apturēt nepareizu rīcību.
Pēc izvēles veidiem nulles izvēles vērtības iespēja Swift kodā ir ļoti skaidra, kas nozīmē, ka, rakstot nepareizu kodu, tas var radīt kompilatora kļūdu. Tas rada īsu atgriezenisko saiti un ļauj programmētājiem kodēt ar nodomu. Problēmas var novērst, rakstot kodu, kas ievērojami samazina laika un naudas daudzumu, ko tērēsiet kļūdu novēršanai, kas saistītas ar rādītāja loģiku no C mērķa.
Tradicionāli Objective-C gadījumā, ja vērtība tika atgriezta no metodes, programmētāja pienākums bija dokumentēt atgrieztā rādītāja mainīgā darbību (izmantojot komentārus un metožu nosaukšanas konvencijas). Programmā Swift izvēles veidi un vērtību veidi metodes definīcijā skaidri norāda, vai vērtība pastāv vai ja tā var būt neobligāta (tas ir, vērtība var pastāvēt vai arī tā var būt nulle).
Lai nodrošinātu paredzamu uzvedību, Swift izraisa izpildlaika avāriju, ja tiek izmantots nulles izvēles mainīgais. Šī avārija nodrošina konsekventu rīcību, kas atvieglo kļūdu novēršanas procesu, jo tas liek programmētājam nekavējoties novērst problēmu. Swift izpildlaika avārija apstāsies koda rindā, kur tika izmantots nulles izvēles mainīgais. Tas nozīmē, ka kļūda tiks novērsta ātrāk vai tiks pilnībā novērsta Swift kodā.
4. Swift ir apvienots ar atmiņas pārvaldību
Swift valodu apvieno tā, kā C-mērķim nekad nav bijis. Automātiskās atsauču skaitīšanas (ARC) atbalsts ir pabeigts visos procesuālajos un objektorientētajos kodu ceļos. Objektīvā-C ARC tiek atbalstīts Cocoa API un objektorientētajā kodā; tomēr tas nav pieejams procesuālajam C kodam un API, piemēram, Core Graphics. Tas nozīmē, ka tā kļūst par programmētāja atbildību rīkoties ar atmiņu, strādājot ar Core Graphics API un citām iOS zema līmeņa API. Lielas atmiņas noplūdes, kas programmētājam var būt Objective-C, Swift nav iespējams.
Programmētājam nevajadzētu domāt par atmiņu katram viņa radītajam digitālajam objektam. Tā kā ARC apkopo visu atmiņas pārvaldību kompilēšanas laikā, smadzeņu spēku, kas būtu bijis domāts atmiņas pārvaldībai, tā vietā var koncentrēt uz galveno lietotņu loģiku un jaunām funkcijām. Tā kā Swift ARC darbojas gan ar procesuālo, gan uz objektu orientēto kodu, programmētājiem vairs nav nepieciešami mentāla konteksta slēdži, pat tad, kad viņi raksta kodu, kas skar zemāka līmeņa API - problēma ar pašreizējo mērķa C versiju.
Automātiska un augstas veiktspējas atmiņas pārvaldība ir atrisināta problēma, un Apple ir pierādījusi, ka tā var palielināt produktivitāti. Otra blakusparādība ir tā, ka gan Objective-C, gan Swift necieš atkritumu savācējs, kurš attīra neizmantoto atmiņu, piemēram, Java, Go vai C #. Tas ir svarīgs faktors jebkurai programmēšanas valodai, kas tiks izmantota atsaucīgai grafikai un lietotāja ievadei, it īpaši tādai taustes ierīcei kā iPhone, Apple Watch vai iPad (kur kavēšanās ir nomākta un liek lietotājiem uztvert, ka lietotne ir bojāta).
5. Swift prasa mazāk koda
Swift samazina koda daudzumu, kas nepieciešams atkārtotiem paziņojumiem un virkņu manipulācijām. Objective-C darbs ar teksta virknēm ir ļoti daudzbalsīgs un prasa daudz darbību, lai apvienotu divas informācijas daļas. Swift izmanto modernas programmēšanas valodas funkcijas, piemēram, pievienojot divas virknes kopā ar operatoru “+”, kas trūkst Objective-C. Atbalsts šādu rakstzīmju un virkņu apvienošanai ir būtisks jebkurai programmēšanas valodai, kas lietotājiem ekrānā parāda tekstu.
Swift tipa sistēma samazina kodu priekšrakstu sarežģītību - jo sastādītājs var izdomāt veidus. Piemēram, Objective-C prasa, lai programmētāji iegaumētu īpašas virknes žetonus (% s, % d, %@) un sniedziet ar komatu atdalītu mainīgo sarakstu, lai aizstātu katru marķieri. Swift atbalsta virkņu interpolāciju, kas novērš nepieciešamību iegaumēt žetonus un ļauj programmētājiem ievietot mainīgos tieši rindā, kas vērsta uz lietotāju, piemēram, etiķeti vai pogas virsrakstu. Tipa secināšanas sistēma un virkņu interpolācija mazina kopēju avāriju avotu, kas ir izplatīts C mērķī.
Izmantojot Objective-C, pasūtījuma sajaukšana vai nepareiza virknes marķiera izmantošana izraisa lietotnes avāriju. Šeit Swift atkal atbrīvo jūs no grāmatvedības, pārtulkojot mazāk rakstāmā koda (kods, kas tagad ir mazāk pakļauts kļūdām), jo tajā ir iekļauts teksta virkņu un datu manipulācijas atbalsts.
6. Swift ir ātrāks
Atmetot mantotās C konvencijas, Swift ir ievērojami uzlabojies zem pārsega. Swift koda veiktspējas etaloni joprojām norāda uz Apple centieniem uzlabot ātrumu, kādā Swift var palaist lietotņu loģiku.
Saskaņā ar Primate Labs, populārā GeekBench veiktspējas rīka veidotājiem, Swift 2014. gada decembrī, izmantojot Mandelbrot algoritmu, tuvojās C ++ veiktspējas raksturlielumiem skaitļošanas saistītos uzdevumos.
2015. gada februārī Primate Labs atklāja, ka Xcode 6.3 Beta ar koeficientu 1,4 uzlaboja GEMM algoritma - ar atmiņu saistīta algoritma ar secīgu piekļuvi lieliem blokiem - veiktspēju. Sākotnējā FFT ieviešana - ar atmiņu saistīts algoritms ar lielu masīvu nejaušu piekļuvi - uzlaboja veiktspēju 2,6 reizes.
Lietojot labāko praksi, Swift tika novēroti turpmāki uzlabojumi, kā rezultātā FFT algoritma veiktspēja tika palielināta 8,5 reizes (C ++ atstājot tikai 1,1 reizes lielāku veiktspēju). Uzlabojumi arī ļāva Swift pārspēt Mandelbrot algoritma C ++ ar koeficientu tikai 1,03.
Gan FFT, gan Mandelbrota algoritmiem Swift ir gandrīz līdzvērtīgs C ++ līmenim. Saskaņā ar Primate Labs teikto, GEMM algoritma veiktspēja liecina, ka Swift kompilators nevar vektorizēt kodu, ko var C ++ kompilators - tas ir viegls veiktspējas pieaugums, ko varētu sasniegt nākamajā Swift versijā.
7. Mazāk vārdu sadursmju ar atvērtā koda projektiem
Viens objektīvā C koda jautājums ir oficiāla atbalsta trūkums nosaukumvietām, kas bija C ++ risinājums koda failu nosaukumu sadursmēm. Kad šī vārda sadursme notiek mērķī C, tā ir saistītāja kļūda, un lietotni nevar palaist. Risinājumi pastāv, taču tiem ir iespējamas kļūmes. Parasti tiek lietots divu vai trīs burtu prefikss, lai atšķirtu C objektīvo kodu, kuru, teiksim, raksta Facebook, salīdzinot ar jūsu pašu kodu.
Swift nodrošina netiešas nosaukumvietas, kas ļauj vienam un tam pašam koda failam pastāvēt vairākos projektos, neizraisot būvēšanas kļūmi un pieprasot tādus nosaukumus kā NSString (Next Step - Steve Jobs uzņēmums pēc atlaišanas no Apple) vai CGPoint (Core Graphics). Galu galā šī Swift funkcija uztur programmētājus produktīvākus un nozīmē, ka viņiem nav jāveic grāmatvedība, kas pastāv Objective-C. Jūs varat redzēt Swift ietekmi ar vienkāršiem nosaukumiem, piemēram, Array, Dictionary un String, nevis NSArray, NSDictionary un NSString, kas ir radušies, jo trūkst nosaukumvietu Objective-C.
Izmantojot Swift, nosaukumvietu pamatā ir mērķis, kuram pieder koda fails. Tas nozīmē, ka programmētāji var atšķirt klases vai vērtības, izmantojot nosaukumvietas identifikatoru. Šīs izmaiņas Swift ir milzīgas. Tas ievērojami atvieglo atvērtā koda projektu, ietvaru un bibliotēku iekļaušanu jūsu kodā. Vārdvietas ļauj dažādiem programmatūras uzņēmumiem izveidot vienus un tos pašus koda failu nosaukumus, neuztraucoties par sadursmēm, integrējot atvērtā koda projektus. Tagad gan Facebook, gan Apple bez kļūdām vai būvēšanas kļūmēm var izmantot objekta koda failu ar nosaukumu FlyingCar.swift.
8. Swift atbalsta dinamiskas bibliotēkas
Lielākās Swift izmaiņas, kurām nav pievērsta pietiekama uzmanība, ir pāreja no statiskām bibliotēkām, kuras tiek atjauninātas galvenajos izlaidumos (iOS 8, iOS 7 un tā tālāk), uz dinamiskām bibliotēkām. Dinamiskās bibliotēkas ir izpildāmi koda fragmenti, kurus var saistīt ar lietotni. Šī funkcija ļauj pašreizējām Swift lietotnēm izveidot saiti ar jaunākām Swift valodas versijām, kad tā laika gaitā attīstās.
Izstrādātājs iesniedz lietotni kopā ar bibliotēkām, kuras abas ir digitāli parakstītas ar izstrādes sertifikātu, lai nodrošinātu integritāti (sveiki, NSA). Tas nozīmē, ka Swift var attīstīties ātrāk nekā iOS, kas ir prasība mūsdienīgai programmēšanas valodai. Izmaiņas bibliotēkās var iekļaut jaunākajā lietotnes atjauninājumā App Store, un viss vienkārši darbojas.
Dinamiskās bibliotēkas iOS nekad nav atbalstītas līdz Swift un iOS 8 palaišanai, kaut arī dinamiskās bibliotēkas Mac ir atbalstītas ļoti ilgu laiku. Dinamiskās bibliotēkas ir ārpus izpildāmās lietotnes, taču tās ir iekļautas no App Store lejupielādētajā lietotņu komplektā. Tas samazina sākotnējo lietotnes lielumu, kad tā tiek ielādēta atmiņā, jo ārējais kods ir saistīts tikai tad, kad tiek izmantots.
Spēja atlikt ielādi mobilajā lietotnē vai iegultā lietotnē Apple Watch uzlabos lietotāja uztverto veiktspēju. Šī ir viena no atšķirībām, kas ļauj iOS ekosistēmai justies atsaucīgākai. Apple ir koncentrējies tikai uz aktīvu, resursu ielādi, un tagad ir apkopojis un saistījis kodu lidojumā. Lādēšana lidojumā samazina sākotnējo gaidīšanas laiku, līdz faktiski ir nepieciešams resurss, lai parādītu ekrānā.
