Swift vs. Objective-C: 10 причин, по которым будущее в пользу Swift

Языки программирования нелегко умирают, но магазины разработчиков, цепляющиеся за исчезающие парадигмы, умирают. Если вы разрабатываете приложения для мобильных устройств и не исследовали Swift, обратите внимание: Swift не только вытеснит Objective-C, когда дело доходит до разработки приложений для Mac, iPhone, iPad, Apple Watch и других устройств, но он также заменит C для встроенного программирования на платформах Apple.

Благодаря нескольким ключевым функциям Swift может стать де-факто языком программирования для создания иммерсивных, отзывчивых и ориентированных на потребителя приложений на долгие годы.

Apple, похоже, ставит перед Swift большие цели. Он оптимизировал компилятор для повышения производительности и языка для разработки, и в документации Swift упоминается, что Swift «предназначен для масштабирования от« hello, world »до всей операционной системы». Хотя Apple еще не объявила всех своих целей в отношении языка, запуск Xcode 6, Playgrounds и Swift вместе свидетельствует о намерении Apple сделать разработку приложений более простой и доступной, чем с любой другой цепочкой инструментов разработки.

Вот 10 причин, чтобы опередить игру, начав работать со Swift прямо сейчас.

1. Swift легче читать

Objective-C страдает всеми недостатками, которые можно ожидать от языка, построенного на C. Чтобы отличать ключевые слова и типы от типов C, Objective-C представил новые ключевые слова с использованием символа @. Поскольку Swift не построен на C, он может объединить все ключевые слова и удалить многочисленные символы @ перед каждым ключевым словом типа Objective-C или объектным ключевым словом.

Swift отказывается от устаревших соглашений. Таким образом, вам больше не нужны точки с запятой в конце строки или круглые скобки для окружения условных выражений внутри операторов if / else. Другое большое изменение в том , что вызовы методов не гнездятся внутри друг друга приводит к кронштейну ад-прощай, [[[ ]]]. В вызовах методов и функций в Swift используется стандартный список параметров, разделенных запятыми, заключенный в круглые скобки. В результате получается более чистый и выразительный язык с упрощенным синтаксисом и грамматикой.

Код Swift больше похож на естественный английский, в дополнение к другим современным популярным языкам программирования. Такая удобочитаемость упрощает для существующих программистов JavaScript, Java, Python, C # и C ++ внедрение Swift в свою цепочку инструментов - в отличие от гадкого утенка, которым был Objective-C.

2. Swift проще в обслуживании.

Наследие - это то, что сдерживает Objective-C: язык не может развиваться без развития C. C требует, чтобы программисты поддерживали два файла кода, чтобы улучшить время сборки и эффективность создания исполняемого приложения, требование, которое переносится на Objective-C.

Swift отказывается от требования двух файлов. Xcode и компилятор LLVM могут определять зависимости и автоматически выполнять инкрементные сборки в Swift 1.2. В результате повторяющаяся задача отделения оглавления (файла заголовка) от тела (файла реализации) ушла в прошлое. Swift объединяет заголовок Objective-C (.h) и файлы реализации (.m) в один файл кода (.swift).

Двухфайловая система Objective-C требует от программистов дополнительной работы - и эта работа отвлекает программистов от общей картины. В Objective-C вам нужно вручную синхронизировать имена методов и комментарии между файлами, надеюсь, используя стандартное соглашение, но это не гарантируется, если у команды нет правил и проверок кода.

Xcode и компилятор LLVM могут работать «за кулисами», чтобы снизить нагрузку на программиста. Благодаря Swift программисты меньше занимаются бухгалтерией и могут тратить больше времени на создание логики приложения. Swift исключает стандартную работу и улучшает качество кода, комментариев и поддерживаемых функций.

3. Swift безопаснее

Один интересный аспект Objective-C - это способ обработки указателей, особенно нулевых (нулевых) указателей. В Objective-C ничего не происходит, если вы пытаетесь вызвать метод с переменной-указателем, равной нулю (неинициализированной). Выражение или строка кода становятся нерабочими (no-op), и хотя может показаться полезным то, что они не дают сбоев, они были огромным источником ошибок. Невыполнение операций приводит к непредсказуемому поведению, которое является врагом программистов, пытающихся найти и исправить случайный сбой или остановить неустойчивое поведение.

Необязательные типы очень четко указывают на возможность использования необязательного значения nil в коде Swift, что означает, что он может генерировать ошибку компилятора при написании плохого кода. Это создает короткий цикл обратной связи и позволяет программистам сознательно писать код. Проблемы могут быть исправлены по мере написания кода, что значительно сокращает время и деньги, которые вы будете тратить на исправление ошибок, связанных с логикой указателя из Objective-C.

Традиционно в Objective-C, если значение было возвращено из метода, программист должен был задокументировать поведение возвращаемой переменной-указателя (используя комментарии и соглашения об именах методов). В Swift необязательные типы и типы значений явно указывают в определении метода, существует ли значение или оно потенциально может быть необязательным (то есть значение может существовать или быть нулевым).

Чтобы обеспечить предсказуемое поведение, Swift вызывает сбой во время выполнения, если используется необязательная переменная nil. Этот сбой обеспечивает согласованное поведение, которое упрощает процесс исправления ошибок, поскольку заставляет программиста сразу же исправить проблему. Авария среды выполнения Swift остановится на той строке кода, где использовалась необязательная переменная nil. Это означает, что ошибка будет исправлена ​​раньше или полностью устранена в коде Swift.

4. Swift объединен с управлением памятью

Swift унифицирует язык так, как никогда не делал Objective-C. Поддержка автоматического подсчета ссылок (ARC) является полной во всех процедурных и объектно-ориентированных путях кода. В Objective-C ARC поддерживается в API-интерфейсах Какао и объектно-ориентированном коде; однако он недоступен для процедурного кода C и таких API, как Core Graphics. Это означает, что ответственность за управление памятью ложится на программиста при работе с API Core Graphics и другими низкоуровневыми API, доступными в iOS. Огромные утечки памяти, которые программист может иметь в Objective-C, невозможны в Swift.

Программисту не следует думать о памяти для каждого цифрового объекта, который он или она создает. Поскольку ARC обрабатывает все управление памятью во время компиляции, интеллектуальные ресурсы, которые были бы направлены на управление памятью, вместо этого могут быть сосредоточены на основной логике приложения и новых функциях. Поскольку ARC в Swift работает как с процедурным, так и с объектно-ориентированным кодом, он больше не требует мысленных переключений контекста для программистов, даже когда они пишут код, затрагивающий API нижнего уровня - проблема с текущей версией Objective-C.

Автоматическое и высокопроизводительное управление памятью - проблема, которая была решена, и Apple доказала, что она может повысить производительность. Другой побочный эффект заключается в том, что и Objective-C, и Swift не страдают от того, что сборщик мусора выполняет очистку неиспользуемой памяти, например Java, Go или C #. Это важный фактор для любого языка программирования, который будет использоваться для адаптивной графики и пользовательского ввода, особенно на тактильных устройствах, таких как iPhone, Apple Watch или iPad (где задержка расстраивает и заставляет пользователей думать, что приложение не работает).

5. Swift требует меньше кода

Swift сокращает объем кода, который требуется для повторяющихся операторов и манипуляций со строками. В Objective-C работа с текстовыми строками очень многословна и требует многих шагов для объединения двух частей информации. Swift использует современные функции языка программирования, такие как добавление двух строк вместе с оператором «+», который отсутствует в Objective-C. Подобная поддержка комбинирования символов и строк является фундаментальной для любого языка программирования, который отображает текст пользователю на экране.

Система типов в Swift снижает сложность операторов кода, поскольку компилятор может определять типы. В качестве примера, Objective-C требует , чтобы программисты запоминать специальные маркеры строк ( %s, %d, %@) , и обеспечивают разделенный запятыми список переменных , чтобы заменить каждый маркер. Swift поддерживает строковую интерполяцию, которая устраняет необходимость запоминания токенов и позволяет программистам вставлять переменные непосредственно в строку, обращенную к пользователю, такую ​​как метка или заголовок кнопки. Система определения типа и интерполяция строк смягчают общий источник сбоев, которые распространены в Objective-C.

В Objective-C нарушение порядка или использование неправильного строкового токена приводит к сбою приложения. Здесь Swift снова избавляет вас от бухгалтерской работы, переводя в меньшее количество кода для написания (код, который теперь меньше подвержен ошибкам) ​​благодаря своей встроенной поддержке для управления текстовыми строками и данными.

6. Swift быстрее

Отказ от устаревших соглашений C значительно улучшил Swift. Тесты производительности кода Swift продолжают указывать на стремление Apple повысить скорость, с которой Swift может запускать логику приложений.

По данным Primate Labs, создателей популярного инструмента повышения производительности GeekBench, в декабре 2014 года Swift приближался к характеристикам производительности C ++ для задач с привязкой к вычислениям с использованием алгоритма Мандельброта.

В феврале 2015 года Primate Labs обнаружила, что бета-версия Xcode 6.3 улучшила производительность Swift алгоритма GEMM - алгоритма с привязкой к памяти с последовательным доступом к большим массивам - в 1,4 раза. Первоначальная реализация БПФ - алгоритм с ограничением памяти с произвольным доступом к большим массивам - позволила повысить производительность в 2,6 раза.

Дальнейшие улучшения наблюдались в Swift за счет применения передовых методов, что привело к увеличению производительности алгоритма БПФ в 8,5 раз (в результате чего C ++ получил прирост производительности только в 1,1 раза). Усовершенствования также позволили Swift превзойти C ++ для алгоритма Мандельброта всего в 1,03 раза.

Swift почти соответствует C ++ как по алгоритмам БПФ, так и по алгоритмам Мандельброта. По данным Primate Labs, производительность алгоритма GEMM предполагает, что компилятор Swift не может векторизовать код, который может компилятор C ++ - легкий прирост производительности, который может быть достигнут в следующей версии Swift.

7. Меньше конфликтов имен с проектами с открытым кодом.

Одна проблема, которая беспокоила код Objective-C, - это отсутствие формальной поддержки пространств имен, что было решением C ++ для конфликтов имен файлов кода. Когда это столкновение имен происходит в Objective-C, это ошибка компоновщика, и приложение не может работать. Существуют обходные пути, но есть потенциальные подводные камни. Обычное соглашение - использовать двух- или трехбуквенные префиксы, чтобы отличать код Objective-C, написанный, например, Facebook, от вашего собственного кода.

Swift предоставляет неявные пространства имен, которые позволяют одному и тому же файлу кода существовать в нескольких проектах, не вызывая сбоев сборки и не требуя таких имен, как NSString (следующий шаг - компания Стива Джобса после увольнения из Apple) или CGPoint (Core Graphics). В конечном итоге эта функция в Swift позволяет программистам работать более продуктивно и означает, что им не нужно вести бухгалтерский учет, как в Objective-C. Вы можете увидеть влияние Swift с помощью простых имен, таких как Array, Dictionary и String, вместо NSArray, NSDictionary и NSString, которые возникли из-за отсутствия пространств имен в Objective-C.

В Swift пространства имен основаны на цели, которой принадлежит файл кода. Это означает, что программисты могут различать классы или значения, используя идентификатор пространства имен. Это изменение в Swift огромно. Это значительно упрощает включение проектов, фреймворков и библиотек с открытым исходным кодом в ваш код. Пространства имен позволяют различным компаниям-разработчикам программного обеспечения создавать одинаковые имена файлов кода, не беспокоясь о конфликтах при интеграции проектов с открытым исходным кодом. Теперь и Facebook, и Apple могут использовать файл объектного кода под названием FlyingCar.swift без каких-либо ошибок или сбоев сборки.

8. Swift поддерживает динамические библиотеки.

Самым большим изменением в Swift, которому не уделялось достаточно внимания, является переход со статических библиотек, которые обновляются в основных выпусках (iOS 8, iOS 7 и т. Д.), На динамические библиотеки. Динамические библиотеки - это исполняемые фрагменты кода, которые можно связать с приложением. Эта функция позволяет текущим приложениям Swift связываться с более новыми версиями языка Swift по мере его развития.

Разработчик отправляет приложение вместе с библиотеками, обе из которых имеют цифровую подпись с сертификатом разработки для обеспечения целостности (привет, АНБ). Это означает, что Swift может развиваться быстрее, чем iOS, что является требованием для современного языка программирования. Все изменения в библиотеках могут быть включены в последнее обновление приложения в App Store, и все просто работает.

Динамические библиотеки никогда не поддерживались в iOS до выпуска Swift и iOS 8, хотя динамические библиотеки поддерживались на Mac очень давно. Динамические библиотеки являются внешними по отношению к исполняемому файлу приложения, но включены в пакет приложения, загруженный из App Store. Он уменьшает начальный размер приложения по мере его загрузки в память, поскольку внешний код связывается только при использовании.

Возможность отложить загрузку в мобильном приложении или во встроенном приложении на Apple Watch улучшит воспринимаемую пользователем производительность. Это одно из отличий, которые делают экосистему iOS более отзывчивой. Apple была сосредоточена на загрузке только активов и ресурсов, а теперь скомпилированный и связанный код на лету. Загрузка «на лету» сокращает начальное время ожидания до тех пор, пока ресурс действительно не понадобится для отображения на экране.