Programování

Swift vs. Objective-C: 10 důvodů, proč budoucnost upřednostňuje Swift

Programovací jazyky neumírají snadno, ale vývojové obchody, které se drží mizejících paradigmat, ano. Pokud vyvíjíte aplikace pro mobilní zařízení a nezkoumali jste Swift, nezapomeňte: Swift nejen nahradí Objective-C, pokud jde o vývoj aplikací pro Mac, iPhone, iPad, Apple Watch a další zařízení, ale také nahradí C pro vestavěné programování na platformách Apple.

Díky několika klíčovým funkcím má Swift potenciál stát se de facto programovacím jazykem pro vytváření pohlcujících, pohotových a spotřebitelských aplikací pro nadcházející roky.

Zdá se, že Apple má pro Swift velké cíle. Optimalizoval výkon kompilátoru a jazyk pro vývoj a zmiňuje se o tom, že Swift je v dokumentaci Swiftu „navržen pro škálování od„ ahoj, svět “po celý operační systém. I když Apple dosud neuvedl všechny své cíle pro daný jazyk, uvedení Xcode 6, Playgrounds a Swift společně signalizují záměr společnosti Apple usnadnit a zpřístupnit vývoj aplikací než v jakémkoli jiném řetězci vývojových nástrojů.

Tady je 10 důvodů, proč dostat náskok před zahájením spolupráce se Swiftem.

1. Swift je čitelnější

Objective-C trpí všemi bradavicemi, které byste očekávali od jazyka postaveného na C. Aby bylo možné odlišit klíčová slova a typy od typů C, zavedl Objective-C nová klíčová slova pomocí symbolu @. Protože Swift není postaven na C, může sjednotit všechna klíčová slova a odstranit četné symboly @ před každým typem Objective-C nebo klíčovým slovem souvisejícím s objektem.

Swift upustí od starších konvencí. Už tedy nepotřebujete středníky k ukončení řádků nebo závorek k obklopení podmíněných výrazů uvnitř příkazů if / else. Další velkou změnou je, že volání metod se do sebe nevnořují, což má za následek pekelné závorky - bye-bye, [[[ ]]]. Volání metod a funkcí v Swiftu používají průmyslový standardní seznam parametrů oddělených čárkami v závorkách. Výsledkem je čistší a expresivnější jazyk se zjednodušenou syntaxí a gramatikou.

Kód Swift se kromě jiných moderních populárních programovacích jazyků více podobá přirozené angličtině. Tato čitelnost usnadňuje stávajícím programátorům z JavaScriptu, Javy, Pythonu, C # a C ++ přijmout Swift do svého řetězce nástrojů - na rozdíl od ošklivého káčátka, kterým byl Objective-C.

2. Swift se snadněji udržuje

Původ je to, co drží Objective-C zpět - jazyk se nemůže vyvíjet, aniž by se vyvíjel C. C vyžaduje, aby programátoři udržovali dva soubory kódu, aby se zlepšila doba sestavení a efektivita vytváření spustitelné aplikace, což je požadavek, který se přenáší do Objective-C.

Swift upustí od požadavku na dva soubory. Xcode a kompilátor LLVM mohou zjistit závislosti a provádět přírůstková sestavení automaticky v Swift 1.2. Výsledkem je, že opakující se úkol oddělit obsah (soubor záhlaví) od těla (soubor implementace) je věcí minulosti. Swift kombinuje záhlaví Objective-C (.h) a implementační soubory (.m) do jednoho souboru kódu (.swift).

Systém dvou souborů Objective-C ukládá programátorům další práci - a je to práce, která odvádí pozornost programátorů od širšího obrazu. V Objective-C musíte ručně synchronizovat názvy metod a komentáře mezi soubory, doufejme, že použijete standardní konvenci, ale to není zaručeno, pokud tým nemá zavedená pravidla a kontroly kódu.

Xcode a kompilátor LLVM mohou pracovat v zákulisí, aby snížily pracovní zátěž programátora. S programem Swift programátoři méně vedou účetnictví a mohou trávit více času vytvářením logiky aplikací. Swift přeruší práci s typovým štítkem a zlepší kvalitu podporovaných kódů, komentářů a funkcí.

3. Swift je bezpečnější

Jedním zajímavým aspektem Objective-C je způsob, jakým se s ukazateli - zejména s nulovými (nulovými) ukazateli - zachází. V Objective-C se nic nestane, pokud se pokusíte zavolat metodu s proměnnou ukazatele, která je nulová (neinicializovaná). Výraz nebo řádek kódu se stává neoperací (no-op), a i když se může zdát prospěšné, že se nezhroutí, byl to obrovský zdroj chyb. No-op vede k nepředvídatelnému chování, což je nepřítel programátorů, kteří se snaží najít a opravit náhodný pád nebo zastavit nevyzpytatelné chování.

Díky volitelným typům je možnost nulové volitelné hodnoty v kódu Swift velmi jasná, což znamená, že při psaní chybného kódu může generovat chybu kompilátoru. To vytváří krátkou zpětnou vazbu a umožňuje programátorům kódovat záměrně. Problémy lze opravit při psaní kódu, což výrazně snižuje množství času a peněz, které utratíte za opravu chyb souvisejících s logikou ukazatele z Objective-C.

Tradičně v případě Objective-C, pokud byla hodnota vrácena z metody, bylo odpovědností programátora dokumentovat chování vrácené proměnné ukazatele (pomocí komentářů a konvencí pojmenování metod). V Swiftu volitelné typy a typy hodnot v definici metody výslovně objasňují, zda hodnota existuje nebo zda má potenciál být volitelná (tj. Hodnota může existovat nebo může být nulová).

Chcete-li poskytnout předvídatelné chování, Swift spustí runtime selhání, pokud se použije nulová volitelná proměnná. Tato chyba poskytuje konzistentní chování, což usnadňuje proces opravy chyb, protože nutí programátora, aby problém ihned vyřešil. Selhání modulu runtime Swift se zastaví na řádku kódu, kde byla použita žádná volitelná proměnná. To znamená, že chyba bude dříve opravena nebo se jí úplně vyhneme v kódu Swift.

4. Swift je sjednocen se správou paměti

Swift sjednocuje jazyk způsobem, který Objective-C nikdy neměl. Podpora automatického počítání referencí (ARC) je úplná napříč procedurálními a objektově orientovanými cestami kódu. V Objective-C je ARC podporováno v rámci kakaových API a objektově orientovaného kódu; není však k dispozici pro procedurální C kód a API, jako je Core Graphics. To znamená, že se stává odpovědností programátora za správu paměti při práci s rozhraními Core Graphics API a dalšími nízkoúrovňovými rozhraními API dostupnými v systému iOS. Obrovské úniky paměti, které může mít programátor v Objective-C, jsou ve Swiftu nemožné.

Programátor by neměl myslet na paměť pro každý digitální objekt, který vytvoří. Vzhledem k tomu, že ARC zpracovává veškerou správu paměti v době kompilace, může být inteligence, která by šla směrem ke správě paměti, místo toho zaměřena na logiku základní aplikace a nové funkce. Protože ARC v Swiftu funguje napříč procedurálním i objektově orientovaným kódem, nevyžaduje žádné další přepínání mentálního kontextu pro programátory, i když píší kód, který se dotýká API nižší úrovně - problém s aktuální verzí Objective-C.

Automatická a vysoce výkonná správa paměti je problém, který byl vyřešen, a společnost Apple prokázala, že může zvýšit produktivitu. Dalším vedlejším účinkem je, že Objective-C i Swift netrpí tím, že Garbage Collector běží čištění nevyužité paměti, jako je Java, Go nebo C #. To je důležitý faktor pro jakýkoli programovací jazyk, který se použije pro responzivní grafiku a vstup uživatele, zejména na hmatových zařízeních, jako je iPhone, Apple Watch nebo iPad (kde je zpoždění frustrující a uživatelé vnímají, že je aplikace poškozená).

5. Swift vyžaduje méně kódu

Swift snižuje množství kódu, který je vyžadován pro opakované příkazy a manipulaci s řetězci. V Objective-C je práce s textovými řetězci velmi podrobná a vyžaduje mnoho kroků ke kombinování dvou informací. Swift využívá moderní funkce programovacího jazyka, jako je přidání dvou řetězců spolu s operátorem „+“, který v Objective-C chybí. Podpora kombinování znaků a řetězců, jako je tato, je zásadní pro jakýkoli programovací jazyk, který zobrazuje text uživateli na obrazovce.

Systém typů v Swift snižuje složitost příkazů kódu - protože kompilátor dokáže zjistit typy. Jako příklad, Objective-C vyžaduje, aby si programátoři zapamatovali speciální řetězcové tokeny (% s, % d, %@) a poskytnout seznam proměnných oddělených čárkami, které nahradí každý token. Swift podporuje interpolaci řetězců, což eliminuje potřebu zapamatovat si tokeny a umožňuje programátorům vkládat proměnné přímo inline do řetězce orientovaného na uživatele, jako je například popisek nebo název tlačítka. Systém odvozování typů a interpolace řetězců zmírňují společný zdroj selhání, které jsou běžné v Objective-C.

S Objective-C způsobí narušení objednávky nebo použití nesprávného řetězcového tokenu selhání aplikace. Zde vás Swift znovu osvobozuje od účetních prací a překládá se do méně kódu pro psaní (kód, který je nyní méně náchylný k chybám) kvůli své inline podpoře pro manipulaci s textovými řetězci a daty.

6. Swift je rychlejší

Upuštění od starších konvencí C značně vylepšilo Swift pod kapotou. Srovnávací hodnoty výkonu kódu Swift nadále poukazují na odhodlání společnosti Apple zlepšit rychlost, s jakou může Swift spouštět logiku aplikací.

Podle společnosti Primate Labs, tvůrců populárního výkonového nástroje GeekBench, se Swift v prosinci 2014 přiblížil výkonovým charakteristikám C ++ pro úlohy vázané na výpočet pomocí algoritmu Mandelbrot.

V únoru 2015 společnost Primate Labs zjistila, že Xcode 6.3 Beta vylepšil Swiftův výkon algoritmu GEMM - algoritmu vázaného na paměť se sekvenčním přístupem k velkým polím - o faktor 1,4. Počáteční implementace FFT - algoritmus vázaný na paměť s náhodným přístupem k velkým polím - měla 2,6násobné zlepšení výkonu.

Další vylepšení byla v Swiftu pozorována použitím osvědčených postupů, což vedlo k 8,5násobnému zvýšení výkonu algoritmu FFT (ponechání C ++ pouze s 1,1násobným zvýšením výkonu). Vylepšení také umožnila Swift překonat C ++ algoritmu Mandelbrot o faktor pouhých 1,03.

Swift je téměř na stejné úrovni jako C ++ pro algoritmy FFT i Mandelbrot. Podle Primate Labs výkon algoritmu GEMM naznačuje, že kompilátor Swift nemůže vektorizovat kód, který může kompilátor C ++ - snadný nárůst výkonu, kterého by bylo možné dosáhnout v další verzi Swift.

7. Méně kolizí jmen s open source projekty

Jedním z problémů, které trápily kód Objective-C, je jeho nedostatek formální podpory pro jmenné prostory, což bylo řešení C ++ pro kolize kódů souborů. Když k této kolizi názvu dojde v Objective-C, jedná se o chybu linkeru a aplikaci nelze spustit. Řešení existují, ale mají potenciální úskalí. Běžnou konvencí je použití předpony se dvěma nebo třemi písmeny k odlišení kódu Objective-C, který je napsán, řekněme, Facebookem oproti vašemu vlastnímu kódu.

Swift poskytuje implicitní obory názvů, které umožňují existenci stejného souboru kódu napříč více projekty, aniž by to způsobilo selhání sestavení a vyžadovalo názvy jako NSString (další krok - společnost Steva Jobse po propuštění z Apple) nebo CGPoint (Core Graphics). Tato funkce ve Swift nakonec udržuje programátory produktivnější a znamená, že nemusí dělat účetnictví, které existuje v Objective-C. Můžete vidět vliv Swiftu s jednoduchými jmény jako Array, Dictionary a String místo NSArray, NSDictionary a NSString, které se zrodily z nedostatku jmenných prostorů v Objective-C.

U Swiftu jsou jmenné prostory založeny na cíli, do kterého soubor kódu patří. To znamená, že programátoři mohou rozlišovat třídy nebo hodnoty pomocí identifikátoru oboru názvů. Tato změna ve Swiftu je obrovská. Velmi usnadňuje začlenění open source projektů, rámců a knihoven do vašeho kódu. Jmenné prostory umožňují různým softwarovým společnostem vytvářet stejné názvy souborů kódu bez obav z kolizí při integraci projektů s otevřeným zdrojovým kódem. Nyní mohou Facebook i Apple používat soubor kódů objektů s názvem FlyingCar.swift bez jakýchkoli chyb nebo selhání sestavení.

8. Swift podporuje dynamické knihovny

Největší změnou v Swiftu, které se nedostalo dostatečné pozornosti, je přechod ze statických knihoven, které jsou aktualizovány v hlavních bodových verzích (iOS 8, iOS 7 atd.), Na dynamické knihovny. Dynamické knihovny jsou spustitelné bloky kódu, které lze propojit s aplikací. Tato funkce umožňuje propojení současných aplikací Swift s novějšími verzemi jazyka Swift, jak se časem vyvíjí.

Vývojář odešle aplikaci spolu s knihovnami, které jsou digitálně podepsány vývojovým certifikátem, aby byla zajištěna integrita (ahoj, NSA). To znamená, že Swift se může vyvíjet rychleji než iOS, což je požadavek moderního programovacího jazyka. Změny knihoven lze zahrnout do nejnovější aktualizace aplikace v App Store a vše jednoduše funguje.

Dynamické knihovny nebyly na iOS nikdy podporovány až do spuštění Swift a iOS 8, přestože dynamické knihovny byly na Macu podporovány velmi dlouho. Dynamické knihovny jsou mimo spustitelný soubor aplikace, ale jsou zahrnuty v balíčku aplikace staženém z App Store. Snižuje počáteční velikost aplikace při načítání do paměti, protože externí kód je propojen pouze při použití.

Možnost odložit načítání v mobilní aplikaci nebo vložené aplikaci na Apple Watch zlepší vnímaný výkon pro uživatele. Toto je jeden z rozdílů, díky kterým se ekosystém iOS cítí lépe reagovat. Apple se zaměřuje na načítání pouze aktiv, zdrojů a nyní kompilovaného a propojeného kódu za běhu. Načítání za běhu snižuje počáteční čekací doby, než je skutečně potřeba prostředek k zobrazení na obrazovce.

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