WWDC 2019: Черный стриж

В “яблочной” экосистеме грядут перемены. Скорее всего, радикальные. Для пользователя программа – это её пользовательский интерфейс, UI. До SwiftUI, с 1988 и до наших дней, в NeXTSTEP и в её потомках процесс создания UI оставался, в основном, тем же. И вот… Swift, которому как раз в эти дни исполняется 5 лет, действительно превращается в “гражданина первого сорта” в его вселенной. Когда-нибудь это должно было произойти, на нем уже сейчас пишут бóльшую часть программного обеспечения для macOS и iOS, а в относительно новых системах (tvOS и watchOS), почти без вариантов используется он.

Язык вырвался за пределы “яблочной” экосистемы, взлетел на самые первые позиции в чартах и даже успел опуститься в них на несколько пунктов – то есть, состоялся.

Но в родной экосистеме, между исполняемым кодом и элегантными исходными кодами неизбежно присутствовал толстый слой иной природы, а против природы, как мы знаем по собственному жизненному опыту, не попрешь. Ну не был он “гражданином первого сорта” в своем отечестве.

Года через два или три UI подавляющего большинства программ для операционных систем Apple будет создаваться с помощью SwiftUI. Чтобы это предсказание не сбылось, я даже не знаю что должно произойти. Что-то вроде конца света, ядерного апокалипсиса, второго пришествия или возвращения в Apple Скотта Форстолла в 2021 году (как планировал Стив).

Катастрофы меньшего масштаба не смогут повлиять на его судьбу. Новорожденный SwiftUI фантастически хорош, продуктивен, гибок – это очевидно даже в самой первой его версии. Точнее, в первой публичной бета-версии (он жил тайной жизнью уже несколько лет).

Реальное его вторжение в мир случится осенью, после приземления (приводнения?) Каталины.

Переоценивать значение SwiftUI тоже не стоит. Пользовательский интерфейс программ лишь самая заметная и очень важная их часть. Это для пользователей UI и программа одно и то же. Мы-то с вами знаем что это не так. Слой иной природы стал чуть тоньше, но увы, он всё еще печальная правда жизни. Его уход уже давно был вопросом времени, теперь он стал вопросом самого ближайшего будущего. Сюрпризы неизбежны, ждите.

А теперь поговорим о том, что такое SwiftUI, придирчиво и беспристрастно…

Продолжение серии про WWDC 2019, предыдущие части здесь:

Первая часть: WWDC 2019: Возвращение “тёрки для сыра”.

Кто ты, Черный Стриж?

Это очень разноплановая сущность. Это и средство для создания и совершенствования пользовательских интерфейсов для всех “яблочных” платформ, и декларативный диалект Swift, и инфраструктура для поддержки всего этого встроенная в Xcode 11 и macOS 10.15, и долгожданная замена играм с запредельным энергопотреблением: теперь они не нужны.

Есть более увлекательный и экологически чистый способ получить кайф. Создавай. Миры. Сам.

В основе всего – фреймворк (разновидность библиотеки), и очень хорошо продуманные правила “игры”. В первой версии “под капотом” используются те самые сущности, которые принадлежат к “толстому слою иной природы”, но это лишь временный компромисс.

Специально для SwiftUI в списке редакторов Xcode 11 появился Editor and Canvas. В сети я уже видел слово “канвас”, в роли перевода второй части этого названия. Обычно я руками и ногами “за” появление новых терминов в русском языке, заимствования обогащают язык и позволяют выражать смыслы более точно. Но в данном случае “холст” лучше. Полезные ассоциации, подтекст – все это работает в нужном направлении.

Декларативный диалект Swift – иносказание. Это обычные Swift-файлы, во всех магических проявлениях в “редакторе-и-холсте” виновны фреймворк SwiftUI (на самом деле, комплекс из нескольких фреймворков, извините за анатомический реализм) и особенности Swift 5.1. И еще что-то, встроенное в Xcode 11. Подробности на это ресурсе, видимо, неуместны.

Традиционное приложение для, например, iOS – это исходные файлы на разных языках (C, C++, Objective-C, Objective-C++, JavaScript, Swift и т.п.) и nib-файлы, с расширениями “xib” или “storyboard”, где в “засушенном” виде хранятся объекты интерфейсных элементов.

SwiftUI – это нечто параллельное традиционным ценностям. В SwiftUI интерфейс – Swift-файл или файлы. Холст в Editor and Canvas отображает, в режиме реального времени, все изменения исходного кода в описании интерфейса. В статике, но реалистично, как все это и выглядело бы в реальной программе если бы её построили прямо сейчас.

Холст не только изображает написанное в swift-файле. Элементы нарисованного UI живые, их атрибуты и параметры (цвет, прозрачность, форму, шрифт и много чего еще) с тем же успехом можно редактировать на холсте, как если бы это был графический редактор. Как в Interface Builder. При этом, все эти изменения синхронно отображаются в коде. Отличный способ изучения возможностей декларативного диалекта (огромного набора структур из которых в SwiftUI собираются интерфейсы).

Режим статического отображения несложно переключить в динамическое, чтобы увидеть как все это будет работать.

Подробнее про “что это” можно узнать на портале developer.apple.com.

SwiftUI превратит нынешние программы в бесполезный хлам?

Нет. Это было бы равносильно выстрелу себе в висок. Apple (и взаимно поглотившая её NeXT) не первый год в софтверном бизнесе, и отлично понимают что к чему.

Тем более что SwiftUI – технология новорожденная. Её подвергали всевозможным тестам, как космонавта, её пытали самыми немыслимыми пытками – но с чем он (UI – интерфейс, то есть “он”) встретится в реальной жизни можно узнать только попробовав.

В софтверном бизнесе в актуальной версии программ принято поддерживать, помимо актуальной мажорной версии системы, еще и версию N-1. Или N-1 и N-2. Например, если программа написана для macOS 10.15, она должна работать в macOS 10.14, без каких-то функций которые в X.14 недоступны, но корректно и предсказуемо. Это N-1. Поддержка N-2, то есть macOS 10.13, еще сложнее. Никто не запрещает программе работать в более старых системах (если для этого нет веских причин), её совместимость с ними просто не проверяют, ничего личного – это трудоемко и недешево.

В наше время мажорные версии операционных систем выходят каждый год. В ближайшие год или два нашествие SwiftUI маловероятно, он поддерживается только в macOS 10.15 и выше.

Первые птенцы черного стрижа появятся быстрее, но погоду им сделать не удастся.

Все герои сегодняшнего дня остаются на своих местах: Objective-C, Interface Builder и прочие хорошие ребята. Но дорога в будущее проходит мимо них. Они останутся здесь.

С чем-то расставаться грустно. Но едва ли кто-то пожалеет об утрате AutoLayout, или Cocoa Bindings. В SwiftUI то что они делали делается проще, гибче и элегантнее.

Дежавю

Вводная лекция про SwiftUI для разработчиков началась с примера его применения. Это было увлекательно, захотелось немедленно все это попробовать, пощупать пределы всей этой невероятной магии (моя техника не потянет, увы) – вместо подробного рассказа о том что это, зачем и почему.

Об основах была другая лекция.

А ведь все это уже было. В конце 80-х и в начале 90-х Стив, в смокинге с галстуком типа “бабочка” (не путать с клавиатурой этого типа, не к ночи будь она помянута) вызывал у слушателей бурный восторг и иллюзию бесконечной легкости разработки программ этими средствами.

NeXTSTEP и в самом деле был самым мощным инструментом того времени, его талантов хватило на тридцать с лишним лет (Cocoa, Cocoa Touch, и всякие tvOS и watchOS – его современные версии). Бад Трибл (один из ключевых разработчиков первого Mac’а и его ОС, программирующий руководитель проекта NeXTSTEP) и Стив Джобс – гении, если бы они создали только эту среду разработки и её библиотеки, они вошли бы в историю.

Но иллюзия бесконечной легкости нанесла NeXTSTEP огромный, почти фатальный, ущерб.

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

Ущерб оказался не фатальным, но речь не о том.

SwiftUI – это безумно интересно, увлекательно, революционно (да, это не первая в мире реализация подобных идей, но и Apple II не был первым персональным компьютером, ни Mac, ни даже Lisa не были первыми компьютерами с графическим пользовательским интерфейсом, iPhone был далеко не самым первым смартфоном – можно не продолжать?), но…

Впрочем, на это раз Apple подготовилась основательно. SwiftUI создавался не один год, а программирующая публика 2019 года на порядок порядков мудрее чем публика 1988-89 годов.

Как и в NeXTSTEP, по мере усложнения интерфейса работать с SwiftUI становится трудней, число ошибок и неудачных решений растет экспоненциально. Как и NeXTSTEP, ему надо учиться, пробовать и ошибаться. Принципы просты и понятны, но есть еще и конкретика.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

WWDC 2014: история появления Swift

Главное событие пресс-конференции по случаю открытия WWDC 2014 года случилось в самом её конце. Ему уделили совсем немного времени. Крис Латнер, умеющий захватить внимание аудитории и делать с ней все что захочет, был скован и непохож на себя. И тем не менее, WWDC 2014 вошла в историю как “WWDC на которой был представлен Swift”. Новый язык программирования, название которого переводится просто и без затей как “Стриж”, пришел на смену Objective-C.

26 лет этот язык использовался в NeXTSTEP и во всех наследниках этой системы (Mac OS X, iOS, GnuStep, tvOS), стал одним из самых популярных языков в мире, а по моему мнению он был (есть?) лучшим из лучших. Я не могу быть объективным, с 2001 по 2016 Objective-C был моим основным языком программирования. До него были ObjectPascal и C++.

Все остальное, объявленное и представленное на той пресс-конференции (новые версии OS X, iOS и Xcode, и даже Metal) произвело значительно более слабый эффект.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно.

Раскол

Восторг, охвативший самых разных людей, искренний и неподдельный, я не разделял. Мне было больно и неприятно читать и слышать восхваления в адрес нового языка, который нес в сплоченные ряды пишущих для “яблочных” систем раскол и неразбериху.

В исходных кодах библиотек iOS и OS X десятки (если не сотни) миллионов строк кода на Objective-C. Переписать их на Swift в ближайшие лет десять-двадцать было нереально, тем более переписать по-умному, чтобы не утратить что-то важное и приобрести что-то очень важное и нужное.

Даже если бы Apple удалось идеально надстроить существенно другой по своей природе язык над всеми этими миллионами строк, проблемы были бы неизбежны. А сложное никто и никогда не делает идеально.

Что до самого языка, то сначала он мне очень не понравился. Скачав книгу про Swift (это шедевр технической документации, без капли иронии), и открыв её в первый раз, я увидел что-то вроде let aNumber = 42. Как в самых древних вариантах Basic’а! Отсталых уже тогда, когда я их изучал, лет за 20 до конца предыдущего тысячелетия. Оператор присваивания в них выглядел именно так, почти в точности (примерно так: LET ANUMBER = 42).

Я плюнул и закрыл эту электронную книгу. Возвратившись с работы и преодолев себя, я приступил к чтению. Оказалось что “let” в Swift имеет вполне достойное предназначение, но язык мне активно не нравился.

Строгий контроль за типами данных, сплошные “нельзя” и “обязательно” – это же кошмар, правда? Идея с optionals интересна, но как-то все непривычно. Не по-людски! А мне с ним жить.

Язык мне не нравился очень долго. Целую эпоху. Неделю или две. Через месяц меня охватил восторг.

Смелые обещания

Публике Swift представили как Objective-C без C. Будто бы из-за этого освоить его будет легче. Молодёжь к нему потянется, и напишет шедевры невероятной мощи. Стоп…

Человек, который не способен освоить C, может быть гением в любой области, но шедевр программистского искусства он не напишет никогда. Это не его.

К счастью, это всего лишь маркетинговый лозунг. C в Swift’е присутствует на каждом шагу, это C-подобный язык. Хотя собственно C, как отдельной сущности, в нем действительно нет.

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

Современный, быстрый, компактный, продуманный, безопасный – пожалуй, эти обещания в новом языке были выполнены, с самого начала.

Но в то что Swift, с первого его дня, станет “гражданином первого сорта” в iOS и OS X я не поверил. В этом направлении Apple им команда Латнера сделали очень многое, возможное и невозможное, и даже (забегая вперед, в 2014 году об этом еще никто не знал) несколько раз все это переделали, улучшив и углУбив.

Некоторые из этих улучшений понравились мне даже больше чем сам Swift. Вы видели CoreGraphics в варианте для Swift, и другие библиотеки в оригинале написанные на C?

Когда системы хотя бы наполовину будут написаны на Swift, тогда это обещание будет исполнено.

Порадовало что никто не пообещал что даже самые-самые альтернативно одаренные товарищи смогут без труда писать в Swift отличный “софт”. Увы. Ни один язык в мире не гарантирует от ужасных программ.

Обещания (их было дюжины полторы) были “придуманы” в маркетинговой службе, со слов инженеров и менеджеров знавших про Swift и языки программирования не понаслышке. Их общение, скорее всего, было нервным – но продуктивным.

Маркетологи почти не солгали. Так, чуть-чуть, в рамках приличий. И только так, чтобы их невозможно было поймать на обмане и убедительно доказать это.

Swift 1.0

При всех его удивительных качествах, первый Swift был очень сырым, многое в нем вело себя не так как обещала Книга (бесплатная, отлично написанная, книга про Swift).

Согласно теории Жана-Поля Гассé, любое сложное техническое изделие (компьютер, программа, операционная система, графический или центральный процессор) не может “состояться” раньше чем в третьей его версии.

Теория работает не всегда: процессоры от Apple “состоялись” уже в первой их версии, в той которая называлась Swift (это Apple A6 и Apple A6X), а Cyclone (центральный процессор в Apple A7) уже просто громил конкурентов. Были и обратные примеры (но о грустном не буду).

Swift-который-язык состоялся именно в третьей версии.

Когда Крис ушел из Apple, самым главным в проекте Swift стал Тед Кременек, один из тех кто придумал, продумал и сделал реальностью это язык. Мне показалось что чуду пришел конец – но, судя по нынешней версии языка, я ошибался.

А какой язык лучше – Swift или Kotlin или современный C++?

Джеф Раскин говорил что сравнивать сложные сущности на лучше/хуже также нелепо как сравнивать точки на плоскости на больше/меньше. Джеф говорил много разных вещей. С очень многими его утверждениями я не согласен – но не с этим.

Про сам язык не пишу – о нем столько всего уже написано.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Что за Swift показала Apple в 2012 году?

12 сентября 2012 Apple представила iPhone 5, внутри которого, неназванный и никому не известный, был Swift. В 2012 году! Только это был совсем другой Swift, не тот о котором вы подумали. И едва ли не более сенсационный…

К Swift 2012 года мы еще вернемся. С iPhone 5 связана одна из загадок, которая, наверное, никогда не будет разгадана. Одобрил Стив увеличение размера этого устройства или нет. В публикациях приводятся оба мнения на этот счет, оба из которых категоричны. Мнения тех, кто имел возможность получить эту информацию из первых рук, тоже разные.

Возьму на себя смелость предложить свою версию: обе стороны правы. Некоторые очень известные проекты Apple прошли через эту стадию. Стив, как правило, склонялся к одному из вариантов их развития, но по тем или иным причинам не останавливал работу и над их альтернативой или даже альтернативами. И как минимум в одном случае он оказался прав, iPhone – это бывшая альтернатива. Оппозиция великому деспоту.

Стив был уверен что размеры устройства и его экрана идеальны. Они не были случайными, это результат серьезных и дотошных исследований. Но весной 2011, когда iPhone 4S был уже на финишной прямой (тестирование, отладка, доводка), пришло время определиться с параметрами следующей модели. В распоряжении тех, кому это было поручено, были идеи и наработки, результаты экспериментов, предложения (самы разные) и сведения о сильных и слабых сторонах конкурентов.

И, как это было всегда в 1997-2011, мнения специалистов (не только относительно экрана и размера устройства) разошлись. Аргументированные мнения, обоснованные и имеющие смысл. Ознакомившись с точкой зрения сторонников увеличения iPhone, Стив задумался. Причины для изменения размеров были, возражения Стива были, по пунктам, учтены. Что было потом, кто и что предлагал – неизвестно.

Известно только чем все это закончилось. Вышел iPhone 5…

Это двадцатая часть серии про iPhone и ему подобных, предыдущие части здесь:

Первая часть: MacWorld Expo 2007;
Вторая часть: Touch-интерфейс приходит на iPod;
Третья часть: iPhone для предприятий, iPhone SDK и App Store;
Четвертая часть: Леопард переселяется в iPhone.
Пятая часть: Следующий шаг: iPhone 3G, iPhone OS 2.0 и много чего еще…;
Шестая часть: iPhone OS 2.1, уже не бета-версия…;
Седьмая часть: iPhone OS 3.0 и поле искажения реальности;
Восьмая часть: iPhone 3GS – на 2 грамма легче, в 2 раза быстрее…;
Девятая часть: iPod touch третьего поколения, и другие iPod’ы…;
Десятая часть: iPhone OS 4…;
Одиннадцатая часть: iPhone 4: телефон с криминальным прошлым…;
Двенадцатая часть: iPhone 4: Антеннагейт, утечки и “белая горячка”;
Тринадцатая часть: Стив Джобс: людям нужны кнопки…;
Четырнадцатая часть: iPod touch 4G;
Пятнадцатая часть: iPhone вырывается на свободу…;
Шестнадцатая часть: Apple Special Event 4 октября 2011 года;
Семнадцатая часть: iPhone 4S + iOS 5 = Бэтеригейт?;
Восемнадцатая часть: iOS 6: Дебют Apple Тима Кука;
Девятнадцатая часть: 12.9.12, первое музыкальное событие новой эры.

Swift 2012 года

Внутри iPhone 5 был КнК (SoC, “компьютер на кристалле”) Apple A6, впервые в истории Apple построенный вокруг двухъядерного процессора собственной разработки. До этого Apple использовала процессоры разработанные ARM, по лицензии. Архитектура ARMv7-A, кодовое название процессора – Swift.

Apple не ограничилась самыми общими словами об этом процессоре, но для тех кто очень хотел установить правду, нет преград. Сколько iPhone 5 пало смертью храбрых во время этих исследований – история умалчивает. КнК подвергали изощренным тестам (благодаря которым удалось вычислить примерную структуру процессора, его тактовую частоту и ряд других моментов), распиливали и исследовали с помощью электронного микроскопа.

Сколько экземпляров iPhone 5 были убиты во время исследований – неизвестно. Десяток или два. Кстати, побочный результат исследований: iPhone 5 был удобнее для ремонта чем любой iPhone прежних моделей.

Серьезно помогли и исследования кода iOS 6. Подробностей не знаю, но кодовое имя процессора установили именно так. Бывшие сотрудники Apple подтвердили правильность этого предположения.

Тактовая частота процессора динамически изменялась, в диапазоне от 1,0 до 1,3 ГГц.

Кроме процессора, в КнК входила графическая подсистема, на основе PowerVR SGX 543MP3, где MP3 указывает на 3-ядерный вариант графического процессора. В составе КнК был 1 Гигабайт оперативной памяти (LPDDR2-1066).

По словам Фила Шиллера процессор превосходил Apple A5 по производительности в два раза, и по графической производительности – тоже.

Apple A6 производился Samsung, по технологии 32 нм, на фоне судебных исков со стороны последней, но на производстве Apple A6 это никак не сказалось.

Экран и прочие безобразия

Retina-дисплей с 4 дюймами по диагонали с разрешением в 1136×640 пикселей, близкое к 16:9. IPS, высокая яркость и четкость – один из лучших экранов среди современников.

Две камеры. Тыльная (главная) с разрешением в 8 Мегапикселей и фронтальная (для чатов) с разрешением в 1,2 Мегапикселя. Массированная поддержка со стороны программного обеспечения позволяла им успешно конкурировать с камерами большего разрешения.

Фил объявил iPhone 5 “самым тонким в мире телефоном”, поленившись проверить факты. В Китае, у двух производителей мобильных телефонов, один из которых был за пределами Китая неизвестен, выпускались более тонкие модели. Сравнить их с iPhone 5, за давностью лет, сложновато. Да и нет необходимости. iPhone 5 прекрасен, самый тонкий и легкий iPhone за всю их историю, и третий в мире по утонченности корпуса.

Изменившийся размер экрана заставил разработчиков переделывать массу кода, но тут никто кроме когда-то написавших этот код не виноват. К самому экрану претензий не было. Самой большой проблемой стал их дефицит, мешавший Apple справляться с более чем высоким спросом.

Претензии были очень серьезными, к двум пунктам: во-первых, к замене традиционного докового разъема (образца 2003 года) на новый, более компактный и меньшего размера, названный Apple “Lightning” (молния). Фил еще пошутил что теперь у Apple и Thunderbolt (раскат грома) и молния. Во-вторых, к замене Micro-SIM на Nano-SIM.

Проблему с доковыми разъёмами Apple вроде как решила (предлагая несколько вариантов адаптера, за 29-39 долларов), но даже с адаптером Lightning поддерживала подключение далеко не всех устройств, с которыми работал старый коннектор.

А еще – корпус оказался не только безумно красивым, но и очень нежным. Издержки. Без чехла носить его в одном кармане с мелочью и ключами не рекомендуется. Видел iPhone 5 которым активно пользовались лет пять: он был без единой царапины.

И тем не менее, повторилась та же самая история что и с предыдущими iPhone: рекордные продажи. Все кто хотел его купить, смогли это сделать.

Хотя произвести нужное количество iPhone требуемого качества было непросто: в Китае на заводах Foxconn забастовали контролеры качества, у производителей дисплеев для iPhone 5 и iPod touch (5G) слишком большое их количество не проходило контроль, с чем никак не удавалось справится – дефицит дисплеев был угрожающим в течение полугода.

Справились.

Впечатления

Отзывы были разными. На первых порах 53% отзывов были отрицательными: из-за нано-симки и коннектора, но зато 35% назвали его лучшим iPhone за всю историю.

Самая главная проблема iPhone 5 не имела к нему отношения. Её звали Apple Maps. Она не имела прямого отношения ни к iOS 6, ни к программному обеспечению Maps.

Разработчики Maps совершили подвиг: собрали гигантский объём данных, во всех уголках Земли, обработали их и многократно всё перепроверили, работая сутками, без отдыха. Это в ДНК у Apple: делать невозможное. У них получилось. Почти.

Число ошибок и неточностей в Maps не превышало их числа в первых версиях технически сложных проектов компании. Возможно, их даже было меньше. Только для карт это было неприемлемо.

Контракт с Google на использование их картографии истекал только в 2014, отношения с Google были даже лучше чем с Samsung, а если бы Apple Maps были выпущены в статусе бета-версии, с кнопкой в интерфейсе упрощающей информирование о проблеме, все было бы иначе.

А если бы и в 2014 число неточностей превышало рамки приличия, в Google были готовы пойти на встречу. Отношения и бизнес – это не одно и то же.

На случившееся руководство Apple отреагировало быстро и правильно. Изгнание Google Maps из iOS было признано ошибочным. Тим Кук опубликовал извинения. Скотт Форстолл отказался его подписать. Он отвечал за Apple Maps, он правдами и неправдами добился их монопольного статуса в системе и их выпуска несмотря ни на что.

Признавать свои ошибки он не захотел.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Революция 2011 года: Objective-C 3.0, ссылки, сборщики мусора

Иосифу Виссарионовичу, говорят, термин “гиперссылка” понравился бы. Это спорно, а кроме того, никакого отношения к тому о чем эта статья, не имеет. Речь в ней пойдет о совсем других ссылках. И о других сущностях называемых приведенными словами… В 2011 году на смену системе управления памятью, которую придумал за 20 лет до этого великий Бад Триббл (один из создателей первого Mac’а, руководитель и автор NeXTSTEP, затем – старший вице-президент Sun Microsystems), пришла новая.

Старое и новое еще долго сосуществовали (не знаю, уместно ли здесь прошедшее время), но это был один из тех редких случаев, когда новое было настолько лучше и удобнее, что даже в её изначальном и несовершенном виде ARC почти моментально стала основной.

Не все было просто и безоблачно – новая система управления памятью упростила жизнь, но принесла с собой новые проблемы.

ARC был разработан командой LLVM, под управлением Криса Латнера. Одновременно с этим, та же команда, занималась проектом в статусе хобби, тем самым “Objective-C 3.0 без C”, известным сегодня под другим названием. В тот же год компиляторы на основе LLVM 3 окончательно вытеснили GCC из арсенала компании.

Я имел честь общаться с Крисом, примерно в то время – если бы у меня была возможность выбирать главу Apple, я выбрал бы или Скотта Форстолла, или Криса Латнера – а лучше их обоих, и Джонатана Айва им в помощь, для равновесия и внутренней конкуренции…

Это продолжение серии про WWDC 2011, предыдущие части здесь:
Первая часть: WWDC 2011: Apple уходит на облака…;
Вторая часть: WWDC 2011: Про убийство;
Третья часть: iCloud, по другую сторону экрана;
Четвертая часть: Управление памятью и сборщики мусора.

Традиционная система управления памятью

Система Триббла (её так никто не называет, но мы назовем) основана на подсчете числа ссылок на объект.

В первых версиях NeXTSTEP этого не было, что порождало проблемы. Объект, созданный в одном месте программы, мог использоваться в нескольких разных местах – и запросто мог быть удален в одном из этих мест, превратившись в пустышку, попытка обращения к которой неминуемо приводила к аварийному завершению программы.

Вообще не удалять объекты еще хуже: многие из них занимали много места в памяти, а так как и язык, и NeXTSTEP жили динамической и заранее непредсказуемой жизнью (это было одним из их важных преимуществ), подобная практика вела к переполнению памяти, и тому же самому аварийному завершению.

Систему управления памятью основанную на подсчете ссылок изобрел не Бад. Он изобрел то, что в течение почти 20 лет превращало жизнь неофитов в пытку, но в умелых руках было фантастически эффективно – метод autorelease. Только это случилось чуть позже.

В самом начале команд было две, retain (придержать) и release (отпустить). А в объектах появился счетчик ссылок на него. При рождении объекта, его счетчику присваивалось значение 1.

Команда retain добавляла к значению 1, release уменьшала значение на ту же единицу.

Теперь если рожденный в точке А объект передавался в точку Б, получатель отправлял ему сообщение retain, увеличивая значение счетчика на единицу. Если в А в этом объекте больше не было необходимости, ему отправляли release. Теперь в любом месте, где объект использовался, он гарантированно оставался в живых пока был нужен.

При обнулении счетчика объект уничтожался. Команда autorelease добавляла в систему динамизм, позволяя создавать временные объекты не заботясь об их уничтожении – они убивались сами (после выхода из контекста).

Как и все прочие, эти объекты рождались с единицей на счетчике, но кроме этого, ссылка на них помещалась в расстрельный список, в NSAutoreleasePool. В каждый оборот цикла управления, программа отправляла всем объектам в списке сообщение release, и очищала его.

Если программист соблюдал правила, в пункт Б прибывали объекты занесенные в Список, если объект был нужен на короткое время (узнать время и вывести его на экран), он тихо и самостоятельно “умирал”. Если на долгое – ему отправлялся retain. Собственно все. Это и есть то непроходимое препятствие. Правил и соглашений было побольше, педантично все их соблюсти непросто – требовалась тренировка.

Сборщик мусора

О том, как работает сборщик памяти нетрудно догадаться. Он помнит где расположены все объекты, считает ссылки на них, и если объект больше не нужен, по собственному расписанию, запускает процесс очищения. Все это происходит одновременно с работой программы, отнимает у неё ресурсы, память и циклы процессора.

Зато программисту не надо ни о чем заботиться – наплодил и забыл.

Это процесс времени исполнения, лишняя нагрузка и все такое – увы, в iOS устройствах где это особенно недопустимо, сборщик мусора неуместен. А как же Android, где Java и сборщик мусора “в деле”?

Автоматический подсчет ссылок (ARC)

На пустом месте, с ноля, написать что-то похожее на ARC было бы невозможно, но в группе низкоуровневых (LL!) технологий отделении средств разработки Apple, в рамках проекта по переходу на LLVM-компиляторы, был разработан Xcode Static Analyzer.

Его первые версии мы называли “вредные советы” – он часто ошибался. Но с каждой версией он становился умней, и теперь уже действовало правило: если вы и анализатор расходитесь в мнениях по какому-то поводу, подумайте еще раз: 9 из 10 что он прав. Если не 99 из 100.

ARC делает то же самое, что в течении 20+ лет делали все писавшие программы для NeXT, Apple Cocoa и Apple Cocoa Touch – только с нечеловеческой педантичностью. И во время компиляции, так же как и люди до него, ARC генерирует код для управления памятью.

Управление памяти основано на том же принципе – на подсчете ссылок. ARC похож на магию, но он не магия. Когда человек принимает решение о том, в каком виде отдавать объект во внешний мир (в приговоренном или нет), он опирается на здравый смысл и на знание жизни. У ARC ни первого, ни второго – нет.

Соглашения об отражении долговечности возвращаемых объектов, существовавшие уже полтора десятка лет, стали на порядок более важными, их пришлось уточнить: если мы не поможем ARC’у, ему никто не поможет.

Если название метода начинается с одного из четырех сочетаний букв, после которых заглавная буква – это метод возвращающий долгоживущие объекты. Иначе – нет.

Четыре магических сочетания: new, alloc, copy и mutableCopy.

Использование retain, release и autorelease было… запрещено.

Инструментарий для управления памятью был разработан заново, более эффективный, и применялся он только ARC – с нечеловеческой аккуратностью.

Были и минусы: ARC работал только с кодом на Objective-C. Программы для Mac’а и для iOS-устройств состоят из фрагментов на C, и обращений к областям памяти созданным в разных библиотеках – они не поддерживались, для взаимодействия с ними требовались специальные меры, то есть лишнее время. И это был лишний повод для ошибок.

Разработчики ARC приложили массу усилий для обеспечения совместимости с кодом без поддержки ARC. Почти получилось – хотя проблемы случались.

Проблем, правда, оказалось на удивление мало – хоть это и была самая первая версия технологии, радикально менявшей устои.

Продолжение следует…

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Swift вошел в топ-10 самых популярных языков программирования

Язык программирования с открытым исходным кодом Apple Swift стремительно набирает популярность и уже обогнал предыдущую разработку корпорации — Objective-C. Такой рейтинг составила аналитическая компания RedMonk. Для определения популярности того или иного языка программировани эксперты воспользовались...

Вышли Xcode 9.3 и Swift Playground 2.0

Apple обновила программное обеспечение для разработки Xcode и обучающее приложение Swift Playgrounds.   В Xcode 9.3 Apple пообещала исправить ряд ошибок и ускорить работу программы. Также в него встроен инструмент для изменения уровня энергопотребления игр...

Telegram X — официальный клиент для iOS, написанный на Swift

Разработчики Telegram запустили альтернативную версию фирменного мессенджера, целиком основанную на языке программирования Swift. Клиент Telegram X, как и оригинал, распространяется совершенно бесплатно и уже доступен для загрузки в российском сегменте каталога App Store.

Несмотря на то, что разработчиком Telegram X в App Store значится «Telegram Messenger LLP», а не «Telegram LLC», как в случае с оригиналом, данное приложение является официальным и было создано командой, принимавшей участие в проектировании стандартной версии мессенджера.

«Telegram X — официальное альтернативное приложение для iOS. Оно целиком написано на Swift, работает гораздо быстрее, ещё дружелюбнее к батарее вашего телефона, есть поддержка тем. Но часть функциональности пока отсутствует, постепенно будет обновляться, — рассказали в поддержке».

Поскольку Telegram X целиком написан на языке Swift, приложение отличается повышенным по сравнению с оригинальной версией быстродействием, энергоэффективностью и плавностью работы. Кроме того, пользователям альтернативного клиента будет доступен широкий ассортимент тем оформления.

Название: Telegram X
Издатель/разработчик: Telegram Messenger LLP
Цена: Бесплатно
Встроенные покупки: Нет
Совместимость: Универсальное приложение
Ссылка: Установить

Как Apple поможет Google в популяризации новой ОС

Таинственная операционная система Fuchsia от Google будет совместима с приложениями, написанными на Swift. Соответствующее подтверждение было обнаружено коллегами из издания CultofMac в репозитории GitHub. Поддержка дополнительного языка программирования, который сегодня считается одним из наиболее востребованных, должна привлечь внимание разработчиков и популяризовать ОС.

Swift был создан и представлен компанией Apple как универсальная платформа для разработки с открытым исходным кодом. С тех пор популярность языка растет небывалыми темпами, а аудитория программистов, владеющих им, увеличивается экспоненциально. В настоящее время Swift лежит в основе большинства приложений и утилит, которые пишутся для актуальных версий iOS, macOS, tvOS и watchOS.

Google ведет открытую разработку Fuchsia с августа 2016 года. В отличие от Android и Chrome OS, основанных на Linux, новая операционная система базируется на микроядре под названием Magenta. Детальный анализ Fuchsia показал, что эта ОС универсальна и может работать как на смартфонах, так и компьютерах. Это утверждение может свидетельствовать о том, что Google планирует отказаться от Android и Chrome OS в пользу Fuchsia.

Язык программирования Apple Swift будет использоваться в операционной системе Google Fuchsia

В середине ноября 2017 года в сообществе программистов возникли споры о том, не разветвляет ли компания Google язык программирования с открытым кодом Apple Swift, применяя его в собственной операционной системе Fuchsia. Сообщает The Verge. Некоторые...

Apple добилась, чтобы Swift начали преподавать студентам

Язык программирования Swift, созданный Apple для разработчиков под iOS и macOS, в этом году войдет в учебную программу 30 ведущих колледжей из Соединенных Штатов Америки. AppleInsider.ru узнал это из опубликованного компанией пресс-релиза. В рамках предстоящей программы Apple рассчитывает обучить языку 74 000 студентов из разных уголков страны и зарубежья.

«Сегодня мы воочию наблюдаем, как экосистема приложений для устройств Apple превращается в самостоятельный экономический пласт, создавая миллионы рабочих мест и генерируя новые отрасли в промышленности, — отметил Тим Кук. — Мы искренне верим, что возможность [изучать Swift] должна появиться во всех учебных заведениях, став одинаково доступной каждому».

Полный курс, обучающий программированию на Swift, ранее стал доступен в магазине iBooks Store. Программа рассчитана на начинающих разработчиков, не имеющих опыта в создании приложений. При должном упорстве, уверяет Apple, даже человек, совершенно далекий от программирования, к концу курса сможет самостоятельно написать полнофункциональную программу для одной из платформ.