📺 Swift Concurrency: В каком порядке смотреть WWDC

Проблема всех телеграм каналов, блогов, твитторов — отсутствие системы. Чаще это посты, которые по рефлексу или по реакциям пишут интересные им темы, пересказывают чужие посты, реагируют на новости первыми ради репостов. Это хорошо работает как медиа, но не работает как источник обучения.

В такой методике легко получить клиповое мышление и отрафировать скилл композиции материала. Где старт и где финал особо не поймешь в ленте постов. Вся усвоенная инфа становится калейдоскопом рандомных фактов. Моя же цель делать изучение структурным и понятным (прям как Structured Concurrency 🤤). Последовательным. С понятным началом и концом...

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

Продолжаем погружаться системно в изучение Swift Concurrency. В прошлом посте мы поняли какие proposals нам читать, а теперь идем в сторону WWDC. Че же надо посмотреть и в каком порядке?

1️⃣ Фаза 1: Hello, Swift Concurrency

Meet async/await in Swift. Самый первый видос про эпоху SC. Тут вкратце рассказывают про проблемы кода на GCD и как async/await помогает избежать забытые completion (кстати, забытыми completion в guard часто подлавливают на собесах)

Explore structured concurrency in Swift. Тут можно хорошо понять почему и для чего вообще вся эта движуха. Мне больше нравится не попсовая формулировка "это просто лучше читать", а что "теперь мы лучше знаем время жизни потока управления, памяти функций и переменных". Звучит осознанней и практичней.

Protect mutable state with Swift actors. Ну тут нам конкретно помогают понять проблемы Data Race на примере всем известного Counter'а, ImageLoader'а. Вы ищите хорошие формулировки для чего же нам акторы, изоляции, Actror Reentrancy, Main Actor.

В отдельных постах пройдемся по практическим точкам каждых секций.

How to measure productivity part 2

Время перфоманс ревью и начало следующего полугодия. Тут есть отличный шанс понять что улучшить за прошлый период и начать планировать следующий.

Мы уже обсуждали очень важную статью про output’ы и outcome’ы. Но правила перфоманс ревью каждую калибровку меняются. Они не стоят на месте.

Вкратце, коммерческая разработка сильно изменилась в оценке инженеров:
- перестали оцениваться только колличественные метрики как пуллреквесты, коммиты и часы
- каждая техническая цель должна аргументироваться с позиции пользы для бизнеса
- разрабы стали более осознанны в следующих шагах

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

Я тоже начал планировать следующие полгода. Идей очень много, но фильтровать их помогают разные метрики. Вот интересные статьи:

🌟Как измерять качество. Очень важная статья про метрики качества. Автор статьи говорит про повышения тимлидам и сеньорам благодаря им:)

🌟Результаты 25000 перфоманс ревью. Интересные наблюдения и выводы на основе многих данных.

🌟Perfomance review в Microsoft. Интересный опыт про эксперименты с перфоманс ревью в майкрософт

Типичные списки 75 задач из Литкода

Нашел в сети пост про список интересных задач.

В интернетах есть куча разных списков задач, которые все ОБЯЗАНЫ прорешать перед тем как идти на интервью. Опять же, решать наугад задачи — не иметь структуры и плана, а значит терять время. Think about it 😏

Самые известные из них:

Top Interview 150
Blind 75
LeetCode 75
NeetCode 150

Эти списки охватывают основную часть паттернов, алгоритмов и структур данных необходимых для алгособесов. Считается, что начинать с этих задач — правильная стратегия.

Задачи из списков выше — хорошая база. Можно хорошо их миксовать с курсами и теорией.

📺 Асинхронный Layout: AsyncDisplayKit

Решил перед выпусками наваливать ЛОРа за темы, которые будем обсуждать. Так и весь контекст обсуждений можно понять, и экспозицию доклада сделать шире.

Не секрет, что мессенджеры — это отдельный вид приложений, не похожий ни на что. Модные SwiftUI, SC или CMP туда не запихнешь, тк он требует высокой производительности от очень старых устройств и версий. Здесь нужно уходить глубже, чем документации смузи штук. Обсуждать все сложности можно часами.

Поговорим про забытую многими технологию. Но оставившую свой след в индустрии.

Либа, AsyncDisplayKit aka Texture, знакома многими по исходникам телеграма. Много боли она принесла с конкурсами, когда нужно работать с исходной кодовой базой. Такие конкурсы на понимание и чтение исходников телеграма имели повышенную сложность. Именно в таком участвовал наш гость Паша.

В чем ее плюсы?

1️⃣ Асинхронный рендеринг — Рендеринг и layout происходят в фоновом потоке (да да), что уменьшает нагрузку на мейнтред. Вы думаете почему телеграм такой быстрый? Ну, потому что он эффективно работает с лайаутом.

Фейсбук* (запрещенная организация в РФ) создавала его для приложений с большим количеством контента (Pinterest, Facebook Paper).

2️⃣ Декларативный стиль через ASLayoutSpec еще до SwiftUI

3️⃣ Прерасчет лайаута до отображения.

В чем же минусы?

1️⃣ Сложность. Если вы где либо видите сложность — это плохой дизайн. Будь это текста авторов в телеграме, книги, кино, все что угодно. А уж тем более software engineering. Закон жанра: то, что остается сложным — умрет.

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

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

Полезные ссылки:
- Using AsyncDisplayKit to Develop Responsive UIs in iOS
- Build Timeline View with AsyncDisplayKit

1/3

📺 Воркшоп: Создание сложных коллекций в UIKit

Всю неделю я готовил фактуру и контексты для видео. Мы с Пашей, призером телеграм конкурсов и крутым разрабом, собрали плотную лекцию с кодом и замерами перфоманса:
🔘Кишки UIKit
🔘Render Server и хитчи
🔘Texture, Pinlayout, FrameBased Development vs AutoLaout
🔘много замеров
🔘много примеров из практики
🔘и другое

Это первый доклад Паши, сейчас он делает сложный клон телеги и прям из печи принес пирожки.

🧬 Получить доступ 💰тут или ⭐️ тут

Swift Concurrency: что делает компилятор?

Я не считаю, что обучение по чужим статьям и твиторам — эффективно. Чаще это инфошум. Поэтому продолжаю структурировать и делым понятным то, что разбросано по кускам. Мы уже немного познакомились с Swift Concurrency по первоисточникам. Выяснили какие proposals почитать и какие wwdc посмотреть.

Теперь перейдем к кратким формулировкам и структурированию мозаик. Все абстракции и примерные мыслительные модели бесполезны, если мы не поймем как работает код.

Давайте по порядку. В теории, можно разделить все на такие ключевые слова:
- Компилятор ->
- State Machine ->
- suspension points ->
- Continuation ->
- Executor ->
- Co-operative thread pool

🟣Компилятор и State Machine. Каждый раз, когда компилятор видит await, то он режет функцию на структуру с полем resumePoint. Разбивает код на блоки и вставляет переходы между ними.

🟣Suspension points. Каждое await — это место приостановки. В интернете нет явной инфы, но общая формулировка такая: Функция приостанавливается и текущий стэк с переменными и позицией сохраняются в кучу. Создаётся continuation.

Swift implements asynchronous functions by transforming them into state machines. Each call to an asynchronous function and each await is a suspension point, where the function can suspend execution

🟣Continuation. Это объект, который хранит что делать дальше, после await. Он хранит в каком месте приостановилось выполнение, какие переменные были в контексте, что делать, когда результат будет готов.

“Continuations are the fundamental building block for suspending and resuming execution in Swift’s concurrency model.”

🟣Executor. Это условный планировщик, который решает, на каком потоке и когда выполнять async-код. Если continuation — это инструкция, то Executor — исполнитель. Сontinuation возобновляется и передаётся в executor, который решает где и когда продолжить выполнение.

“The continuation resumes execution via an executor, which may be the same as the original or different, depending on actor context.”

🟣Co-operative thread pool. Если Executor — это манагер задач, то Co-operative thread pool — это рабочие потоки, на которых Executor исполняет эти задачи. Это общий пул потоков, управляемый Swift Runtime. Потоки не создаются на каждую задачу, вместо этого задачи добровольно уступают выполнение, когда достигают await. Потоки переключаются на другие задачи, пока первая ждёт. Executor получает задачу, ставит ее в очередь и запускает на одном из потоков пулла.

Полезные ссылки:
- Apple Docs
- 0392-custom-actor-executors
- Swift concurrency: Behind the scenes

1/5