Ohjelmointi

Swift vs. Objective-C: 10 syytä, miksi tulevaisuus suosii Swiftia

Ohjelmointikielet eivät kuole helposti, mutta hiipuviin paradigmoihin kiinnittyvät kehityskaupat kuitenkin. Jos kehität sovelluksia mobiililaitteille etkä ole tutkinut Swiftia, ota huomioon: Swift ei vain syrjäytä Objective-C: tä Mac-, iPhone-, iPad-, Apple Watch- ja tuleville laitteille tarkoitettujen sovellusten kehittämisessä. mutta se korvaa myös C: n sulautetun ohjelmoinnin kannalta Apple-alustoilla.

Usean keskeisen ominaisuuden ansiosta Swiftistä voi tulla todellinen ohjelmointikieli mukaansatempaavien, reagoivien ja kuluttajille suunnattujen sovellusten luomiseen tuleviksi vuosiksi.

Applella näyttää olevan suuria tavoitteita Swiftille. Se on optimoinut kääntäjän suorituskyvyn ja kehityskielen ja viittaa siihen, että Swift on "suunniteltu skaalautumaan" hei, maailma "koko käyttöjärjestelmäksi" Swiftin dokumentaatiossa. Vaikka Apple ei ole vielä ilmoittanut kaikkia kielelle asetettuja tavoitteitaan, Xcode 6: n, Playgroundsin ja Swiftin lanseeraukset kertovat yhdessä Applen aikomuksesta tehdä sovelluskehityksestä helpompaa ja lähestyttävämpää kuin missään muussa kehitystyökaluketjussa.

Tässä on 10 syytä päästä eteenpäin pelillä aloittamalla työskennellä Swiftin kanssa nyt.

1. Swift on helpompi lukea

Objektiivi-C kärsii kaikista syylistä, joita voit odottaa C-kielelle rakennetulta kieleltä. Erottaaksesi avainsanat ja tyypit C-tyypistä, Objektiivi-C otti käyttöön uudet avainsanat @ -merkillä. Koska Swift ei ole rakennettu C: lle, se voi yhdistää kaikki avainsanat ja poistaa lukuisat @ -merkit jokaisen Objective-C-tyypin tai objektiin liittyvän avainsanan edessä.

Swift drop -perintökäytännöt. Siksi et enää tarvitse puolipisteitä rivien tai sulkujen lopettamiseksi ehdollisten lausekkeiden ympäröimiseksi if / else-lauseiden sisällä. Toinen suuri muutos on, että menetelmäpuhelut eivät pesää toisiinsa, mikä johtaa suluihin - hei-hei, [[[ ]]]. Menetelmä- ja funktiokutsut Swiftissä käyttävät alan standardien pilkuilla erotettua parametriluetteloa sulkeissa. Tuloksena on puhtaampi, ilmeikkäämpi kieli yksinkertaistetulla syntaksilla ja kieliopilla.

Swift-koodi muistuttaa lähinnä luonnollista englantia muiden nykyaikaisten suosittujen ohjelmointikielten lisäksi. Tämä luettavuus helpottaa nykyisten ohjelmoijien JavaScriptiä, Java-, Python-, C #- ja C ++ -sovellusta omaksumaan Swiftin työkaluketjuunsa - toisin kuin ruma ankanpoikanen, joka oli Objective-C.

2. Swift on helpompi ylläpitää

Perintö pidättää Objective-C: tä - kieli ei voi kehittyä ilman C: n kehittymistä. C vaatii ohjelmoijia ylläpitämään kahta kooditiedostoa suoritettavan sovelluksen luomisen rakennusajan ja tehokkuuden parantamiseksi, vaatimus, joka siirtyy Objective-C: lle.

Swift pudottaa kahden tiedoston vaatimuksen. Xcode ja LLVM-kääntäjä voivat selvittää riippuvuudet ja suorittaa inkrementaaliset koontiversiot automaattisesti Swift 1.2: ssa. Tämän seurauksena toistuva tehtävä erottaa sisällysluettelo (otsikkotiedosto) rungosta (toteutustiedosto) on menneisyyttä. Swift yhdistää Objective-C-otsikon (.h) ja toteutustiedostot (.m) yhdeksi kooditiedostoksi (.swift).

Objective-C: n kaksitiedostojärjestelmä asettaa lisätyötä ohjelmoijille - ja työ häiritsee ohjelmoijat suuremmasta kuvasta. Tavoite-C: ssä sinun on synkronoitava menetelmien nimet ja kommentit tiedostojen välillä manuaalisesti, toivottavasti käyttämällä tavanomaista käytäntöä, mutta tätä ei voida taata, ellei tiimillä ole sääntöjä ja koodiarvosteluja.

Xcode ja LLVM-kääntäjä voivat tehdä työtä kulissien takana vähentääkseen ohjelmoijan työmäärää. Swiftin avulla ohjelmoijat suorittavat vähemmän kirjanpitoa ja voivat käyttää enemmän aikaa sovelluslogiikan luomiseen. Swift keskeyttää kattilalevytyön ja parantaa tuettujen koodien, kommenttien ja ominaisuuksien laatua.

3. Swift on turvallisempi

Yksi mielenkiintoinen näkökohta Objective-C: ssä on tapa, jolla osoitimia - erityisesti nolla (nolla) osoittimia - käsitellään. Objective-C: ssä mitään ei tapahdu, jos yrität kutsua menetelmää osoittimen muuttujalla, joka on nolla (alustamaton). Koodilausekkeesta tai rivirivistä tulee toimimaton (no-op), ja vaikka se saattaa tuntua hyödylliseltä, että se ei kaadu, se on ollut valtava virhelähde. Kieltäytyminen johtaa ennakoimattomaan käyttäytymiseen, mikä on ohjelmoijien vihollinen, joka yrittää löytää ja korjata satunnaisen kaatumisen tai pysäyttää virheellisen käyttäytymisen.

Valinnaiset tyypit tekevät nollavalinnaisen arvon mahdollisuudesta hyvin selvän Swift-koodissa, mikä tarkoittaa, että se voi tuottaa kääntäjävirheen kirjoittaessasi huonoa koodia. Tämä luo lyhyen palautesilmukan ja antaa ohjelmoijien koodata tarkoituksella. Ongelmat voidaan korjata, kun koodi kirjoitetaan, mikä vähentää huomattavasti aikaa ja rahaa, jonka vietät osoitinlogiikkaan liittyvien virheiden korjaamiseen Objective-C: stä.

Perinteisesti Objektiivi-C: ssä, jos arvo palautettiin menetelmästä, ohjelmoijan vastuulla oli dokumentoida palautetun osoittimen muuttujan käyttäytyminen (käyttämällä kommentteja ja menetelmien nimeämiskäytäntöjä). Swiftissä valinnaiset tyypit ja arvotyypit tekevät nimenomaisesti selväksi menetelmän määrittelyssä, onko arvo olemassa tai onko se mahdollinen olla valinnainen (eli arvo voi olla olemassa tai se voi olla nolla).

Ennakoitavan käyttäytymisen tarjoamiseksi Swift laukaisee ajonaikaisen kaatumisen, jos käytetään nollaa valinnaista muuttujaa. Tämä kaatuminen antaa tasaisen käyttäytymisen, mikä helpottaa virheenkorjausprosessia, koska se pakottaa ohjelmoijan korjaamaan ongelman heti. Swift-ajonaikainen kaatuminen loppuu koodiriville, jossa on käytetty nolla valinnaista muuttujaa. Tämä tarkoittaa, että virhe korjataan ennemmin tai vältetään kokonaan Swift-koodissa.

4. Swift on yhdistetty muistinhallintaan

Swift yhdistää kielen tavalla, jota Objective-C: llä ei koskaan ole. Automaattisen viittauslaskennan (ARC) tuki on täydellinen menettelytapojen ja olio-orientoitujen koodipolkujen välillä. Tavoite-C: ssä ARC: tä tuetaan Cocoa-sovellusliittymissä ja olio-koodeissa; se ei kuitenkaan ole käytettävissä menettelylliselle C-koodille ja sovellusliittymille, kuten Core Graphics. Tämä tarkoittaa, että ohjelmoijan vastuulla on käsitellä muistin hallintaa työskennellessään Core Graphics -sovellusliittymien ja muiden iOS: ssä saatavien matalan tason sovellusliittymien kanssa. Ohjelmoijan tavoite-C: ssä valtavat muistivuodot ovat mahdottomia Swiftissä.

Ohjelmoijan ei pitäisi joutua miettimään jokaisen luomansa digitaalisen objektin muistia. Koska ARC hoitaa kaiken muistinhallinnan kääntöhetkellä, aivovoima, joka olisi mennyt kohti muistin hallintaa, voidaan sen sijaan keskittyä sovelluksen ydinlogiikkaan ja uusiin ominaisuuksiin. Koska Swiftin ARC toimii sekä menettely- että olio-koodeissa, se ei vaadi enää henkisiä kontekstikytkimiä ohjelmoijille, vaikka he kirjoittavat koodia, joka koskettaa alemman tason sovellusliittymiä - ongelma Objective-C: n nykyisessä versiossa.

Automaattinen ja suorituskykyinen muistinhallinta on ratkaistu ongelma, ja Apple on osoittanut, että se voi lisätä tuottavuutta. Toinen sivuvaikutus on se, että sekä Objective-C että Swift eivät kärsi roskakorin puhdistamisesta käyttämättömälle muistille, kuten Java, Go tai C #. Tämä on tärkeä tekijä kaikilla ohjelmointikielillä, joita käytetään reagoivassa grafiikassa ja käyttäjän syötteissä, erityisesti kosketuslaitteessa, kuten iPhone, Apple Watch tai iPad (missä viive on turhauttavaa ja saa käyttäjät havaitsemaan sovelluksen olevan rikki).

5. Swift vaatii vähemmän koodia

Swift vähentää toistuvien lauseiden ja merkkijonojen manipulointiin tarvittavan koodin määrää. Objective-C: ssä tekstimerkkijonojen kanssa työskenteleminen on hyvin yksityiskohtaista ja vaatii monia vaiheita kahden tiedon yhdistämiseksi. Swift käyttää nykyaikaisia ​​ohjelmointikieliominaisuuksia, kuten kahden merkkijonon lisääminen yhdessä + -operaattorin kanssa, joka puuttuu Objective-C: stä. Tämäntyyppisten merkkien ja merkkijonojen yhdistämisen tuki on olennaista kaikille ohjelmointikielille, jotka näyttävät tekstiä käyttäjälle näytöllä.

Swiftin tyyppijärjestelmä vähentää koodilausekkeiden monimutkaisuutta - koska kääntäjä voi selvittää tyypit. Esimerkiksi Objective-C vaatii ohjelmoijia muistamaan erityiset merkkijonotunnukset (% s, % d, %@) ja anna pilkuilla erotettu muuttujalista, joka korvaa jokaisen tunnuksen. Swift tukee merkkijonojen interpolaatiota, mikä poistaa merkkien muistamisen tarpeen ja antaa ohjelmoijille mahdollisuuden lisätä muuttujia suoraan käyttäjän suuntaiseen merkkijonoon, kuten tarra tai painikkeen otsikko. Tyyppijärjestelmä ja merkkijonojen interpolointi lieventävät tavallisten C: n yhteisten kaatumisten lähteitä.

Objective-C: n kanssa tilauksen sekoittaminen tai väärän merkkijonon käyttäminen saa sovelluksen kaatumaan. Tässä Swift vapauttaa sinut jälleen kirjanpitotyöstä ja kääntää vähemmän kirjoitettavaksi koodiksi (koodi, joka on nyt vähemmän virhealtinen), koska se tukee tekstimerkkijonoja ja tietoja.

6. Swift on nopeampi

Vanhojen C-käytäntöjen pudottaminen on parantanut huomattavasti Swiftia konepellin alla. Swift-koodin suorituskyvyn vertailuarvot viittaavat edelleen Applen omistautumiseen nopeuden parantamiseksi, jolla Swift voi ajaa sovelluslogiikkaa.

Suositun GeekBench-suoritustyökalun valmistajien Primate Labsin mukaan Swift lähestyi C ++: n suorituskykyominaisuuksia laskentaan sidotuissa tehtävissä joulukuussa 2014 käyttäen Mandelbrot-algoritmia.

Helmikuussa 2015 Primate Labs havaitsi, että Xcode 6.3 Beta paransi Swiftin GEMM-algoritmin - muistiin sidotun algoritmin, jolla on peräkkäinen pääsy suuriin matriiseihin, - suorituskykyä kertoimella 1,4. Alkuperäisellä FFT-toteutuksella - muistiin sitoutuneella algoritmilla, jolla on suurten matriisien satunnainen käyttöoikeus - suorituskyky parani 2,6-kertaiseksi.

Parannuksia havaittiin Swiftissä soveltamalla parhaita käytäntöjä, mikä johti 8,5-kertaiseen lisäykseen FFT-algoritmin suorituskykyyn (jolloin C ++: lle oli vain 1,1-kertainen suorituskyvyn kasvu). Parannusten ansiosta Swift pystyi myös ylittämään Mandelbrot-algoritmin C ++: n kertoimella vain 1,03.

Swift on melkein samalla tasolla kuin C ++ sekä FFT- että Mandelbrot-algoritmeilla. Primate Labsin mukaan GEMM-algoritmien suorituskyky viittaa siihen, että Swift-kääntäjä ei pysty vektorisoimaan koodia, jonka C ++ -kääntäjä voi - tämä on helppo suorituskyvyn voitto, joka voidaan saavuttaa Swiftin seuraavassa versiossa.

7. Vähemmän nimitörmäyksiä avoimen lähdekoodin projektien kanssa

Yksi Objective-C-koodia vaivannut asia on muodollisen tuen puute nimitiloille, mikä oli C ++: n ratkaisu koodinimien törmäyksiin. Kun tämä nimen törmäys tapahtuu Objective-C: ssä, se on linkkivirhe, eikä sovellus voi toimia. Kiertotavat ovat olemassa, mutta niillä on mahdollisia kaatumisia. Yleinen käytäntö on käyttää kahden tai kolmen kirjaimen etuliitteitä erottaakseen Objective-C -koodin, jonka esimerkiksi Facebook on kirjoittanut omaan koodiin.

Swift tarjoaa implisiittisiä nimitiloja, jotka sallivat saman kooditiedoston olemassaolon useissa projekteissa aiheuttamatta rakennusvirhettä ja vaatimatta nimiä, kuten NSString (seuraava vaihe - Steve Jobsin yritys Apple-potkut), tai CGPoint (Core Graphics). Viime kädessä tämä Swiftin ominaisuus pitää ohjelmoijat tuottavampana ja tarkoittaa, että heidän ei tarvitse suorittaa Objective-C: ssä olevaa kirjanpitoa. Voit nähdä Swiftin vaikutuksen yksinkertaisilla nimillä, kuten Array, Dictionary ja String NSArrayn, NSDictionaryn ja NSStringin sijaan, jotka syntyivät nimitilojen puutteesta Objective-C: ssä.

Swiftin avulla nimitilat perustuvat kohteeseen, johon kooditiedosto kuuluu. Tämä tarkoittaa, että ohjelmoijat voivat erottaa luokat tai arvot käyttämällä nimitilan tunnistetta. Tämä muutos Swiftissä on valtava. Se helpottaa suuresti avoimen lähdekoodin projektien, kehysten ja kirjastojen sisällyttämistä koodiin. Nimitilojen avulla eri ohjelmistoyritykset voivat luoda samat kooditiedostonimet huolimatta törmäyksistä avoimen lähdekoodin projekteja integroitaessa. Nyt sekä Facebook että Apple voivat käyttää objektikooditiedostoa nimeltä FlyingCar.swift ilman virheitä tai virheitä.

8. Swift tukee dynaamisia kirjastoja

Suurin muutos Swiftissä, joka ei ole saanut tarpeeksi huomiota, on siirtyminen staattisista kirjastoista, jotka päivitetään tärkeimmissä julkaisuissa (iOS 8, iOS 7 ja niin edelleen) dynaamisiin kirjastoihin. Dynaamiset kirjastot ovat suoritettavia koodinpaloja, jotka voidaan linkittää sovellukseen. Tämän ominaisuuden avulla nykyiset Swift-sovellukset voivat linkittää Swift-kielen uusimpiin versioihin sen kehittyessä ajan myötä.

Kehittäjä lähettää sovelluksen yhdessä kirjastojen kanssa, jotka molemmat ovat digitaalisesti allekirjoitettuja kehitystodistuksella eheyden varmistamiseksi (hei, NSA). Tämä tarkoittaa, että Swift voi kehittyä nopeammin kuin iOS, mikä on vaatimus modernille ohjelmointikielelle. Kaikki kirjastojen muutokset voidaan sisällyttää App Storen sovelluksen uusimpaan päivitykseen, ja kaikki yksinkertaisesti toimii.

Dynaamisia kirjastoja ei ole koskaan tuettu iOS: ssä ennen Swiftin ja iOS 8: n julkaisua, vaikka dynaamisia kirjastoja on tuettu Macissa jo pitkään. Dynaamiset kirjastot ovat sovelluksen ulkopuolisia, mutta ne sisältyvät App Storesta ladattuun sovelluspakettiin. Se pienentää sovelluksen alkuperäistä kokoa, kun se ladataan muistiin, koska ulkoinen koodi linkitetään vain, kun sitä käytetään.

Mahdollisuus lykätä lataamista mobiilisovelluksessa tai sulautetussa sovelluksessa Apple Watchissa parantaa käyttäjän havaittua suorituskykyä. Tämä on yksi eroista, jotka saavat iOS-ekosysteemin tuntemaan reagoivamman. Apple on keskittynyt vain resurssien, resurssien lataamiseen, ja nyt koottu ja linkitetty koodi on lennossa. Lennon aikana lataaminen lyhentää ensimmäisiä odotusaikoja, kunnes resursseja todella tarvitaan näyttämiseen näytöllä.

$config[zx-auto] not found$config[zx-overlay] not found