Swift 5 og ABI-stabilitet - den beste tiden å migrere

Swift er et raskt, trygt og et morsomt språk å kode inn med fullt stabelpotensial og en stor samfunnsstøtte. Det er omtrent 2,6 ganger raskere enn Objekt-C ifølge Apple, men noen studier indikerer at forskjellen ikke er så dramatisk. Swift-koden er enklere å vedlikeholde, da det ikke er separate grensesnitt- og implementeringsfiler, syntaks er kortere og språket støtter dynamiske rammer.

Språket har vokst betydelig og har blitt adoptert av et stort antall utviklere. Det er det 6. mest elskede språket i følge StackOverflow Developer Survey 2018. For et språk som ble utgitt i 2014, er adopsjonsfrekvensen fenomenal.

Dette er noen av fordelene med Swift, la oss nå se på ulempene fra et utviklers perspektiv. Swift er fremdeles ikke moden og er som et bevegelig mål med store endringer som blir introdusert med hver nye utgivelse. Et av de viktigste problemene som er utviklet av mange utviklere, er mangelen på bakoverkompatibilitet med eldre språkversjoner og versjonslåsen, noe som betyr at det bare kan være en enkelt versjon av Swift i hele prosjektet og dets eksterne avhengigheter. Følgelig blir utviklere tvunget til å omskrive prosjektene sine fullstendig hvis de vil bytte til den nyeste Swift-versjonen og oppdatere sine eksterne avhengigheter. For utviklere som lager rammer, må de oppdatere rammeverket for hver nye Swift-versjon, og de kan ikke distribuere det som et binært forhåndskompilert rammeverk.

Heldigvis jobber Swift-teamet og Open-Source-samfunnet med dette problemet og forventes å ta opp dette i den neste store utgivelsen av Swift, dvs. Swift 5.0, etter å ha blitt presset frem siden Swift 3.0. ABI Stabilitets manifest viser at de har som mål å oppnå:

  1. Source Compatibility, som betyr at nyere kompilatorer kan sammenstille kode skrevet i en eldre versjon av Swift. Dette fjerner versjonslåsen som er i Swift.
  2. Binært rammeverk og kompatibilitet med runtime, som gjør det mulig å distribuere rammer i en binær form som fungerer på tvers av flere Swift-versjoner. Binær rammekompatibilitet oppnås ved modulformatstabilitet som stabiliserer modulfilen, som er kompilatorens representasjon av de offentlige grensesnittene til et rammeverk og ABI-stabilitet muliggjør binær kompatibilitet mellom applikasjoner og biblioteker kompilert med forskjellige Swift-versjoner.

Hva er ABI?

Under kjøring samhandler Swift-programinariebinarier med andre biblioteker og komponenter. Application Binary Interface er spesifikasjonen som uavhengig kompilerte binære enheter må samsvare med for å være koblet sammen og utført. Disse binære enhetene må være enige om mange detaljer på lavt nivå, for eksempel hvordan man ringer til funksjoner, datarepresentasjon i minnet, og til og med hvor metadataene deres er og hvordan man får tilgang til dem.

Hva er ABI-stabilitet?

ABI-stabilitet betyr å låse ABI til det punktet at fremtidige kompilatorversjoner kan produsere binære filer som er i samsvar med den stabile ABI. Når en ABI er stabil, har den en tendens til å vedvare resten av plattformens levetid.

ABI-stabilitet påvirker bare invarianter av eksternt synlige offentlige grensesnitt og symboler. For eksempel står fremtidige kompilatorer fritt til å endre anropskonvensjoner for interne funksjonssamtaler så lenge de offentlige grensesnittene er bevart.

Forutsetninger for ABI-stabilitet

  1. Typer, for eksempel strukturer og klasser, må ha en definert layout i minnet for forekomster av den typen og dele de samme layoutkonvensjonene.
  2. Type metadata brukes mye av Swift-programmer. Disse metadataene må enten ha et definert minneoppsett eller ha et sett med definerte API-er for å spørre om metadataene av en type.
  3. Hvert eksportert eller eksternt symbol i et bibliotek trenger et unikt navn som binære enheter kan være enige om. Swift gir funksjonsoverbelastning og kontekstuelle navnefelt (for eksempel moduler og typer), noe som betyr at ethvert navn i kildekoden kanskje ikke er globalt unikt. Et unikt navn produseres gjennom en teknikk som heter name mangling.
  4. Funksjoner må forholde seg til anropskonvensjoner, som innebærer blant annet utformingen av anropsstabelen, hvilke registre som er bevart og eierskapskonvensjoner.
  5. Swift-skip med et runtime-bibliotek som håndterer ting som dynamisk casting, referansetelling, refleksjon, etc. Kompilerte Swift-programmer ringer eksterne samtaler til denne runtime. Dermed er Swift runtime API Swift ABI.
  6. Swift-skip med et standardbibliotek som definerer mange vanlige typer, strukturer og operasjoner på disse. For at et standardbibliotek som leveres som skal fungere med applikasjoner skrevet i forskjellige versjoner av Swift, må det eksponere et stabilt API. Dermed er Swift Standard Library API Swift ABI, i tillegg til utformingen av mange av de typene den definerer.
Alle disse oppgavene er utført av Swift-kjerneteamet, men de er ennå ikke utgitt på GitHub. Ser vi på statusen til oppgavene kan vi trygt forvente at den neste store utgivelsen av Swift skal være ABI-stabil.

Fordeler med ABI-stabilitet

  1. Så når Swift er erklært for å være ABI-stabil, vil koden som er skrevet fra dette punktet være kompatibel med de nyere versjonene av språket, og utvikleren trenger ikke å oppdatere alle eksterne avhengigheter til prosjektet mens han flytter til en ny versjon av Fort.
  2. Bibliotekforfatteren kan levere rammeverket som et binært rammeverk når stabiliteten i modulformatet er oppnådd.
  3. Applikasjonens buntstørrelse vil reduseres ettersom den stabile Swift-kjøretiden deretter kan integreres i operativsystemet.
  4. Språket vil fortsette å utvikle seg, men endringene i ABI fra det tidspunktet ville være tilsetningsfulle. ABI-additive endringer kan utnyttes når den minst målrettede Swift-versjonen støtter dem, siden ABI-stabilitet bare låser de eksternt synlige offentlige grensesnitt og symboler. De nyere kompilatorene kan gjøre interne endringer som kan forbedre effektiviteten.

Konklusjon

Swift er helt klart fremtiden for utvikling i Apple-økosystemet, og når det først er ABI-stabilt og modulformatstabilt, vil språket være fritt for de største ulempene. Les gjennom denne artikkelen for en detaljert sammenligning mellom Swift og Objekt-C i 2019.

Hvis du ønsker å konvertere objektiv-C-kodebasen til Swift, er nå det beste tidspunktet å starte. Jeg har skrevet en artikkel som dekker konvertering av SVProgressHUD til IHProgressHUD som er fullstendig skrevet i Swift og er trådsikker med samme API-design som SVProgressHUD ved hjelp av Swiftify for Xcode.

referanser

  1. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md
  2. https://swift.org/abi-stability/
  3. https://www.altexsoft.com/blog/engineering/the-good-and-the-bad-of-swift-programming-language/
  4. https://www.altexsoft.com/blog/engineering/swift-vs-objective-c-out-with-the-old-in-with-the-new/
  5. https://medium.com/swift-india/swift-5-abi-stability-769ccb986d79
  6. https://www.ca.com/en/blog-developers/dynamic-versus-static-framework-in-ios.html
  7. https://www.youtube.com/watch?v=GzP2oaZRi7Q

Du kan kontakte oss på Twitter, Linkedin, Facebook og Github.