Swift vs. Objective-C: 10 Gründe, warum die Zukunft Swift bevorzugt

Programmiersprachen sterben nicht leicht, aber Entwicklungsgeschäfte, die an verblassenden Paradigmen festhalten. Wenn Sie Apps für mobile Geräte entwickeln und Swift noch nicht untersucht haben, beachten Sie: Swift wird Objective-C nicht nur bei der Entwicklung von Apps für Mac, iPhone, iPad, Apple Watch und zukünftige Geräte ersetzen. Es wird aber auch C für die eingebettete Programmierung auf Apple-Plattformen ersetzen.

Dank mehrerer Hauptfunktionen hat Swift das Potenzial, die De-facto-Programmiersprache für die Erstellung immersiver, reaktionsschneller und verbraucherorientierter Anwendungen für die kommenden Jahre zu werden.

Apple scheint große Ziele für Swift zu haben. Es hat den Compiler für die Leistung und die Sprache für die Entwicklung optimiert und spielt darauf an, dass Swift in der Swift-Dokumentation „so konzipiert ist, dass es von„ Hallo Welt “zu einem gesamten Betriebssystem skaliert“. Obwohl Apple noch nicht alle Ziele für die Sprache festgelegt hat, signalisieren die Starts von Xcode 6, Playgrounds und Swift zusammen Apples Absicht, die App-Entwicklung einfacher und zugänglicher zu machen als mit jeder anderen Entwicklungs-Toolkette.

Hier sind 10 Gründe, um dem Spiel einen Schritt voraus zu sein, indem Sie jetzt mit Swift arbeiten.

1. Swift ist leichter zu lesen

Objective-C leidet unter allen Warzen, die Sie von einer auf C basierenden Sprache erwarten würden. Um Schlüsselwörter und Typen von C-Typen zu unterscheiden, führte Objective-C neue Schlüsselwörter mit dem @ -Symbol ein. Da Swift nicht auf C basiert, kann es alle Schlüsselwörter vereinheitlichen und die zahlreichen @ -Symbole vor jedem Objective-C-Typ oder objektbezogenen Schlüsselwort entfernen.

Swift lässt alte Konventionen fallen. Daher benötigen Sie keine Semikolons mehr, um Zeilen oder Klammern zu beenden, um bedingte Ausdrücke in if / else-Anweisungen zu umgeben. Eine weitere große Änderung besteht darin, dass Methodenaufrufe nicht ineinander verschachtelt sind, was zur Klammer Hölle führt - bye-bye , [[[ ]]]. Methoden- und Funktionsaufrufe in Swift verwenden die durch Kommas getrennte Liste von Parametern in Klammern. Das Ergebnis ist eine sauberere, ausdrucksstärkere Sprache mit einer vereinfachten Syntax und Grammatik.

Swift-Code ähnelt neben anderen modernen populären Programmiersprachen eher dem natürlichen Englisch. Diese Lesbarkeit erleichtert bestehenden Programmierern aus JavaScript, Java, Python, C # und C ++ die Übernahme von Swift in ihre Toolkette - im Gegensatz zu dem hässlichen Entlein, das Objective-C war.

2. Swift ist einfacher zu warten

Vermächtnis ist das, was Objective-C zurückhält - die Sprache kann sich nicht entwickeln, ohne dass sich C weiterentwickelt. In C müssen Programmierer zwei Codedateien verwalten, um die Erstellungszeit und die Effizienz der Erstellung ausführbarer Apps zu verbessern. Diese Anforderung wird auf Objective-C übertragen.

Swift lässt die Anforderung für zwei Dateien fallen. Xcode und der LLVM-Compiler können Abhängigkeiten herausfinden und inkrementelle Builds automatisch in Swift 1.2 ausführen. Die wiederholte Aufgabe, das Inhaltsverzeichnis (Header-Datei) vom Body (Implementierungsdatei) zu trennen, gehört damit der Vergangenheit an. Swift kombiniert den Objective-C-Header (.h) und die Implementierungsdateien (.m) in einer einzigen Codedatei (.swift).

Das Zwei-Dateien-System von Objective-C erfordert zusätzliche Arbeit für Programmierer - und diese Arbeit lenkt Programmierer vom Gesamtbild ab. In Objective-C müssen Sie Methodennamen und Kommentare zwischen Dateien manuell synchronisieren, hoffentlich unter Verwendung einer Standardkonvention. Dies kann jedoch nur garantiert werden, wenn das Team über Regeln und Codeüberprüfungen verfügt.

Xcode und der LLVM-Compiler können hinter den Kulissen arbeiten, um die Arbeitsbelastung des Programmierers zu verringern. Mit Swift erledigen Programmierer weniger Buchhaltung und können mehr Zeit mit der Erstellung von App-Logik verbringen. Swift reduziert die Arbeit mit Boilerplates und verbessert die Qualität des Codes, der Kommentare und der unterstützten Funktionen.

3. Swift ist sicherer

Ein interessanter Aspekt von Objective-C ist die Art und Weise, wie Zeiger - insbesondere Nullzeiger (Nullzeiger - - behandelt werden. In Objective-C passiert nichts, wenn Sie versuchen, eine Methode mit einer Zeigervariablen aufzurufen, die null (nicht initialisiert) ist. Der Ausdruck oder die Codezeile wird zu einer No-Operation (No-Op), und obwohl es vorteilhaft erscheint, dass sie nicht abstürzt, war sie eine große Fehlerquelle. Ein No-Op führt zu unvorhersehbarem Verhalten, das der Feind von Programmierern ist, die versuchen, einen zufälligen Absturz zu finden und zu beheben oder unberechenbares Verhalten zu stoppen.

Optionale Typen machen die Möglichkeit eines optionalen Nullwerts im Swift-Code sehr deutlich, was bedeutet, dass beim Schreiben von fehlerhaftem Code ein Compilerfehler generiert werden kann. Dies erzeugt eine kurze Rückkopplungsschleife und ermöglicht es Programmierern, mit Absicht zu codieren. Probleme können beim Schreiben von Code behoben werden, wodurch sich der Zeit- und Geldaufwand für die Behebung von Fehlern im Zusammenhang mit der Zeigerlogik von Objective-C erheblich verringert.

Wenn in Objective-C ein Wert von einer Methode zurückgegeben wurde, lag es traditionell in der Verantwortung des Programmierers, das Verhalten der zurückgegebenen Zeigervariablen zu dokumentieren (unter Verwendung von Kommentaren und Methodenkonventionen). In Swift machen die optionalen Typen und Werttypen in der Methodendefinition explizit klar, ob der Wert vorhanden ist oder ob er möglicherweise optional ist (dh der Wert kann vorhanden sein oder er kann null sein).

Um ein vorhersehbares Verhalten bereitzustellen, löst Swift einen Laufzeitabsturz aus, wenn eine optionale Variable von Null verwendet wird. Dieser Absturz bietet ein konsistentes Verhalten, das den Fehlerbehebungsprozess vereinfacht, da der Programmierer gezwungen ist, das Problem sofort zu beheben. Der Swift-Laufzeitabsturz stoppt in der Codezeile, in der eine optionale Variable von Null verwendet wurde. Dies bedeutet, dass der Fehler früher behoben oder im Swift-Code vollständig vermieden wird.

4. Swift ist mit der Speicherverwaltung vereinheitlicht

Swift vereinheitlicht die Sprache auf eine Weise, die Objective-C niemals hat. Die Unterstützung für die automatische Referenzzählung (ARC) ist für alle prozeduralen und objektorientierten Codepfade vollständig. In Objective-C wird ARC in den Cocoa-APIs und im objektorientierten Code unterstützt. Es ist jedoch nicht für prozeduralen C-Code und APIs wie Core Graphics verfügbar. Dies bedeutet, dass der Programmierer für die Speicherverwaltung verantwortlich ist, wenn er mit den Core Graphics-APIs und anderen unter iOS verfügbaren Low-Level-APIs arbeitet. Die enormen Speicherverluste, die ein Programmierer in Objective-C haben kann, sind in Swift unmöglich.

Ein Programmierer sollte nicht für jedes digitale Objekt, das er erstellt, über das Gedächtnis nachdenken müssen. Da ARC die gesamte Speicherverwaltung zur Kompilierungszeit übernimmt, kann sich die Intelligenz, die für die Speicherverwaltung aufgewendet worden wäre, stattdessen auf die Kernlogik der App und neue Funktionen konzentrieren. Da ARC in Swift sowohl für prozeduralen als auch für objektorientierten Code funktioniert, sind für Programmierer keine mentalen Kontextwechsel mehr erforderlich, selbst wenn sie Code schreiben, der APIs auf niedrigerer Ebene berührt - ein Problem mit der aktuellen Version von Objective-C.

Die automatische und leistungsstarke Speicherverwaltung ist ein Problem, das gelöst wurde, und Apple hat bewiesen, dass es die Produktivität steigern kann. Der andere Nebeneffekt ist, dass sowohl Objective-C als auch Swift nicht unter einem Garbage Collector leiden, der die Bereinigung für nicht verwendeten Speicher wie Java, Go oder C # ausführt. Dies ist ein wichtiger Faktor für jede Programmiersprache, die für reaktionsschnelle Grafiken und Benutzereingaben verwendet wird, insbesondere auf einem taktilen Gerät wie dem iPhone, der Apple Watch oder dem iPad (wo Verzögerungen frustrierend sind und Benutzer erkennen, dass eine App defekt ist).

5. Swift benötigt weniger Code

Swift reduziert die Menge an Code, die für sich wiederholende Anweisungen und die Manipulation von Zeichenfolgen erforderlich ist. In Objective-C ist das Arbeiten mit Textzeichenfolgen sehr ausführlich und erfordert viele Schritte, um zwei Informationen zu kombinieren. Swift übernimmt moderne Programmiersprachenfunktionen wie das Hinzufügen von zwei Zeichenfolgen zusammen mit einem "+" - Operator, der in Objective-C fehlt. Die Unterstützung für das Kombinieren solcher Zeichen und Zeichenfolgen ist für jede Programmiersprache von grundlegender Bedeutung, die einem Benutzer Text auf einem Bildschirm anzeigt.

Das Typsystem in Swift reduziert die Komplexität von Code-Anweisungen, da der Compiler Typen herausfinden kann. Als Beispiel erfordert Programmierer Objective-C spezielle String - Token zu speichern ( %s, %d, %@) und bietet eine durch Kommata getrennte Liste von Variablen jedes Token zu ersetzen. Swift unterstützt die Zeichenfolgeninterpolation, wodurch das Speichern von Token überflüssig wird und Programmierer Variablen direkt in eine benutzerbezogene Zeichenfolge einfügen können, z. B. eine Beschriftung oder einen Schaltflächentitel. Das Typinferenzsystem und die Zeichenfolgeninterpolation verringern eine häufige Ursache für Abstürze, die in Objective-C häufig auftreten.

Wenn Sie bei Objective-C die Reihenfolge durcheinander bringen oder das falsche Zeichenfolgentoken verwenden, stürzt die App ab. Auch hier entlastet Swift Sie erneut von der Buchhaltung und übersetzt in weniger zu schreibenden Code (Code, der jetzt weniger fehleranfällig ist), da Inline die Bearbeitung von Textzeichenfolgen und Daten unterstützt.

6. Swift ist schneller

Das Löschen älterer C-Konventionen hat Swift unter der Haube erheblich verbessert. Benchmarks für die Leistung von Swift-Code weisen weiterhin auf Apples Engagement hin, die Geschwindigkeit zu verbessern, mit der Swift App-Logik ausführen kann.

Laut Primate Labs, Hersteller des beliebten GeekBench-Leistungstools, näherte sich Swift im Dezember 2014 den Leistungsmerkmalen von C ++ für rechnergebundene Aufgaben mithilfe des Mandelbrot-Algorithmus.

Im Februar 2015 stellten Primate Labs fest, dass die Xcode 6.3 Beta die Leistung von Swift für den GEMM-Algorithmus - einen speichergebundenen Algorithmus mit sequentiellem Zugriff auf große Arrays - um den Faktor 1,4 verbesserte. Die anfängliche FFT-Implementierung - ein speichergebundener Algorithmus mit wahlfreiem Zugriff auf große Arrays - hatte eine 2,6-fache Leistungsverbesserung.

Weitere Verbesserungen wurden in Swift durch Anwendung von Best Practices beobachtet, was zu einer 8,5-fachen Steigerung der Leistung des FFT-Algorithmus führte (wobei C ++ nur einen 1,1-fachen Leistungsgewinn verzeichnete). Die Verbesserungen ermöglichten es Swift auch, C ++ für den Mandelbrot-Algorithmus um den Faktor 1,03 zu übertreffen.

Swift ist sowohl für den FFT- als auch für den Mandelbrot-Algorithmus nahezu gleichwertig mit C ++. Laut Primate Labs deutet die Leistung des GEMM-Algorithmus darauf hin, dass der Swift-Compiler keinen Code vektorisieren kann, den der C ++ - Compiler kann - ein einfacher Leistungsgewinn, der in der nächsten Version von Swift erzielt werden könnte.

7. Weniger Namenskollisionen mit Open Source-Projekten

Ein Problem, das den Objective-C-Code geplagt hat, ist die mangelnde formale Unterstützung für Namespaces. Dies war die Lösung von C ++ zur Codierung von Dateinamenkollisionen. Wenn diese Namenskollision in Objective-C auftritt, handelt es sich um einen Linkerfehler, und die App kann nicht ausgeführt werden. Es gibt Problemumgehungen, aber sie haben potenzielle Fallstricke. Die übliche Konvention besteht darin, Präfixe mit zwei oder drei Buchstaben zu verwenden, um Objective-C-Code, der beispielsweise von Facebook geschrieben wurde, von Ihrem eigenen Code zu unterscheiden.

Swift bietet implizite Namespaces, mit denen dieselbe Codedatei in mehreren Projekten vorhanden sein kann, ohne dass ein Buildfehler auftritt, und Namen wie NSString (nächster Schritt - Steve Jobs 'Unternehmen nach dem Auslösen von Apple) oder CGPoint (Core Graphics) erforderlich sind. Letztendlich hält diese Funktion in Swift Programmierer produktiver und bedeutet, dass sie nicht die in Objective-C vorhandene Buchhaltung durchführen müssen. Sie können Swifts Einfluss mit einfachen Namen wie Array, Dictionary und String anstelle von NSArray, NSDictionary und NSString sehen, die aus dem Mangel an Namespaces in Objective-C entstanden sind.

Bei Swift basieren Namespaces auf dem Ziel, zu dem eine Codedatei gehört. Dies bedeutet, dass Programmierer Klassen oder Werte mithilfe der Namespace-ID unterscheiden können. Diese Veränderung in Swift ist enorm. Es erleichtert die Integration von Open Source-Projekten, Frameworks und Bibliotheken in Ihren Code erheblich. Mit den Namespaces können verschiedene Softwareunternehmen dieselben Code-Dateinamen erstellen, ohne sich bei der Integration von Open Source-Projekten um Kollisionen sorgen zu müssen. Jetzt können sowohl Facebook als auch Apple eine Objektcodedatei namens FlyingCar.swift ohne Fehler oder Erstellungsfehler verwenden.

8. Swift unterstützt dynamische Bibliotheken

Die größte Änderung in Swift, die nicht genügend Beachtung gefunden hat, ist der Wechsel von statischen Bibliotheken, die bei wichtigen Punktversionen (iOS 8, iOS 7 usw.) aktualisiert werden, zu dynamischen Bibliotheken. Dynamische Bibliotheken sind ausführbare Codestücke, die mit einer App verknüpft werden können. Mit dieser Funktion können aktuelle Swift-Apps im Laufe der Zeit mit neueren Versionen der Swift-Sprache verknüpft werden.

Der Entwickler sendet die App zusammen mit den Bibliotheken, die beide mit dem Entwicklungszertifikat digital signiert sind, um die Integrität sicherzustellen (Hallo, NSA). Dies bedeutet, dass sich Swift schneller entwickeln kann als iOS, was eine Voraussetzung für eine moderne Programmiersprache ist. Änderungen an den Bibliotheken können alle mit dem neuesten Update einer App im App Store aufgenommen werden, und alles funktioniert einfach.

Dynamische Bibliotheken wurden unter iOS bis zum Start von Swift und iOS 8 noch nie unterstützt, obwohl dynamische Bibliotheken auf Mac schon sehr lange unterstützt werden. Dynamische Bibliotheken befinden sich außerhalb der ausführbaren App-Datei, sind jedoch im App-Bundle enthalten, das aus dem App Store heruntergeladen wurde. Es reduziert die anfängliche Größe einer App, wenn sie in den Speicher geladen wird, da der externe Code nur bei Verwendung verknüpft wird.

Die Möglichkeit, das Laden in einer mobilen App oder einer eingebetteten App auf der Apple Watch zu verschieben, verbessert die wahrgenommene Leistung für den Benutzer. Dies ist einer der Unterschiede, durch die sich das iOS-Ökosystem reaktionsschneller anfühlt. Apple hat sich darauf konzentriert, nur Assets, Ressourcen und jetzt kompilierten und verknüpften Code im laufenden Betrieb zu laden. Das On-the-Fly-Laden reduziert die anfänglichen Wartezeiten, bis tatsächlich eine Ressource für die Anzeige auf dem Bildschirm benötigt wird.