Зачем учить Objective-C в 2022 году: умелое управление памятью и другие операции на низком уровне

Мобильные разработчики в КРОК решают реальные проблемы заказчиков и конечных пользователей: создают приложения для удалённой проверки остроты зрения, интеграции с умными очками для полиции Дубая или доступа к корпоративной социальной сети. В этой статье команда мобильной разработки рассказала, почему Objective-C до сих пор жив и зачем его учить в 2022 году.

Глубокое понимание процессов

Большая часть внутреннего кода macOS, XCode и ядра iOS написаны на C и С++. Objective-C очень хорошо с ними «стыкуется», потому что формально это не язык программирования, а большой препроцессор к чистому Cи.

Поверх Objective-C строится вся экосистема Apple. Тот же Swift во многом написан поверх него, и чтобы понимать, как система работает изнутри и почему Swift выглядит так, как выглядит, и работает так, как работает, «базу» полезно знать.

Например, Objective-C помогает понять, что не все NSProxy это NSObject и в чём разница между Int, NSInteger и NSNumbe. А также за счёт чего работает Swizzling, что такое Selector, как работает responder chain и так далее. В Swift это сильно инкапсулировано и абстрагировано, а потому не очень хорошо видно.

Кроме того, Objective-C, как и любой Cи-язык, помогает разобраться в том, как работают ссылки, указатели и память в принципе. В нём приходится работать со ссылками напрямую, поэтому достаточно написать 1-2 небольших проекта, чтобы понять тему.

Плюсы на собеседовании

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

Например, атомарность и атрибуты копирования. Долгое время контроль памяти в Objective-C был ручным, и атомарность — то есть доступность переменных одновременно из разных тредов — достаточно больная тема. Поэтому, проработав N времени на Objective-C, ты начинаешь неплохо в этом разбираться: можешь объяснить, какие проблемы возникают в работе с тредами, когда нужно предусмотреть атомарность или подумать о том, как будет копироваться значение, нужен ли дополнительный акцессор.

Objective-C до сих пор используется в разработке

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

Во-вторых, пока некоторые приложения не получается переписать на Swift — это требует времени и денег, которые компания или заказчик не готовы тратить. Поэтому база Objective-C разрастается.

В-третьих, если необходима сложная работа с сетью, памятью, ресурсами устройства, то приходится использовать языки с более низким уровнем абстракции, чем у Swift. Это могут быть Objective-C, Objective-C++ или просто C и С++ — в зависимости от того, насколько низкий уровень нам нужен.

Подобное встречается довольно редко, например в работе с мессенджерами (Telegram), потоковым вещанием (Zoom) или видеосервисами (Кинопоиск). В таких случаях тоже можно абстрагироваться и либо вынести часть логики в отдельную зависимость, либо перенести рендеринг или всю логику пакетирования данных на бэкенд. Но не всегда.

Некоторые вещи сложнее делать на Swift, чем на Objective-C

Иногда решать задачи на Swift долго и неудобно — проще воспользоваться костылями, которые давно есть в Objective-C.

В основном речь идёт про управление памятью: протянуть сообщение в несанкционированную память, вручную поманипулировать управлением памятью или тредами. Разберём пару кейсов.

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

Кроме того, ARC не решает многих проблем — например, с длительностью жизни объектов. Допустим, у нас есть голосовое сообщение на 14 минут. Пользователь уже прослушал 12 — и они «съели» всю оперативную память. На Objective-C мы легко можем их почистить — на уровне указателей и байтов — оставив только текущую минуту и две последних. А на Swift это потребует высокого уровня абстракции и большого количества кода (либо использования трюков Objective-C через Swift-интерфейс).

Наконец, зачастую нагруженные, сложные и высоко оптимизированные библиотеки, реализующие распознавание видео или фото, компьютерное зрение или криптографические вычисления, написаны на С++. И интегрироваться с ними через Swift больно, долго и дорого. Как правило, легче создать заголовочный файл в Objective-C, написать пару методов для красивой обёртки и обратиться уже к ним. Такие кейсы очень часто встречаются при интеграции с третьими библиотеками.

Что в итоге?

Да, Objective-C не идеален, но его полезно выучить.

Это по-прежнему востребованный язык программирования. Он помогает лучше понять, как устроен Swift и экосистема Apple в целом, позволяет гранулярно работать с низкоуровневыми задачами. Кроме того, на Objective-C всё ещё написана больша́я часть кодовой базы, которую нужно поддерживать. И наконец, знание языка — это бонус на собеседованиях.