SwiftUI Perfomance Tips

С опытом и практикой мы все больше пониманием, что полностью на SwiftUI перейти не получится в сложных проектах. Он отлично помогает делать почти 80% экранов, но в вопросе навигации и высоконагруженных экранов пока контроля и возможностей больше в UIKit. Слишком уж много ограничений для быстрых интерфейсов у SUI.

Это значит, что современному инженеру еще долго придется знать оба фреймворка.

Нашел статью с конспектом одной из самых полезных секций WWDC Demystify SwiftUI performance. Здесь собраны все важные советы, которые мы в будущем разберем подробнее:

🌟 уменьшайте количество данных, передаваемых в View, чтобы избежать ненужных обновлений. Используйте @Observable, чтобы отслеживать только нужные свойства.
🌟 избегайте тяжёлых вычислений в body, не злоупотребляйте AnyView, используйте _printChanges() для отладки.
🌟 обеспечьте стабильные id у элементов List и Table, и выносите фильтрацию/сортировку из View в вьюмодель .

⚔️ SwiftUI: Deep dive AttributeGraph p. 1

Вышла одна из самых больших и полезных статей в ноушене.

Продолжаем разбирать кишки SwiftUI. В прошлом посте мы очень поверхностно разобрали AttributeGraph. А также я сказал, что мне очень понравились ролики ребят из objc.io. Я купил подписку и решил сделать их разбор платного контента.

У них крутейший контент где целых 6 часов они пишут с нуля свой AttributeGraph и разбирают его потенциальную работу.

Я решил сократить время и разобрать в ноушене первые четыре главы из девяти. Получилась большая статья где они разбирают:
🟣Что такое AttributeGraph и зачем нужен
🟣Как он устроен изнутри: Node & Edges
🟣Псевдокод AttributeGraph изнутри и построение графа
🟣Правила и вычисления: механизм dirty/pending
🟣Перевычисления зависимостей

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

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

🧬 Получить доступ к разделу и другой контент можно 💰тут или ⭐️ тут

🚴‍♂️Как написание своих велосипедов помогает развитию

Помните мы читали одну из лучших книг прошлого года? The Software Engineer's Guidebook. Тогда я делился главой про написание кастомных решений. Автор говорил, что свои велосипеды — это лучший путь для карьерного и профессионального развития. Фундамент promotion driven development.

Утверждение крайне спорное. В комментах поста крутые инженеры немного поспорили выгодно ли писать свои решения или лучше заимствовать чужие?

Недавно заметил за собой, что в канале ни разу не писал разборы чужих опенсоурсов. Дико не люблю разборы чужих библиотек и фреймворков. Своих велосипедов на работах всегда хватало 😂

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

В FAANG’ах любят писать все свое. На то есть несколько причин:

1. Антипаттерн Vendor Lock. Используя закрытое чужое решение, становишься от него зависимым.

В Яндексе есть свой git, jira, свой teamcity. Казалось бы зачем? Помню, как у многих были проблемы с CI. А в Авито в один день отключили корпоративные учетки гугл доков, потеряв очень много ценной инфы.

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

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

Например, на последнем конкурсе телеграм, для написания видеоплеера нужно было отказаться от AVFoundation. Задача усложнялась в разы и в итоге победителей конкурса не оказалась.

Слышал, что написать свой AVFoundation в ВК видео вроде заняло почти три года. Но объективно плеер ВК в разы лучше телеграмовского.

Конечно, писать или заимствовать вопрос многих переменных: сроков, цены, целей. Но для меня лучше всегда писать хотяб минимум, но своих решений. Улучшать или дополнять. Так мы находим боевой опыт, который дает уникальную ценность нам и нашему продукту. А также повышая техническую осознанность.

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

Мораль. Использовать готовые решения можно и иногда даже необходимо, но если у тебя есть ресурсы и возможности создать свое — то преступление этими возможностями не пользоваться.

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

SwiftUI: Основы Dependency Injection

Мы уже достаточно поговорили про layout engine SwiftUI: узнали что такое wrapper'ы, view & render trees, для чего нужен AttributeGraph и другие вещи. Пока сделаем паузу в UI и множно сказать что для основы работы этого достаточно.

Ведь кроме UI есть еще и другие слои: роутинг, диплинки, пуши, сеть, тесты, модуляризация, данные и многое другое. Кнопки красить мы плюс/минус научились, осталось еще 80% работы 😂

Одними же кнопками дело не ограничивается — мы только начали. Все выше нельзя сделать хорошо без опыта в построении архитектуры. А начиная большую тему нельзя не начать с DI.

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

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

В книге "Mobile System Design" есть отличный блок глав для чего нужен DI:
- Нужно передавать компоненты, которые используются в нескольких местах (например, логгером, аналитикой и тп)
- Хочется быстро переключать окружение: staging, прод, тест.

Dependency Injection — это как если бы ты не сам ходил за продуктами, а тебе их приносили на кухню. Всё нужное приходит извне, а ты просто готовишь — удобно, гибко и легко менять ингредиенты.

Это просто: мы передаём нужные объекты туда, где они нужны. Никакой магии. Просто значения, которые идут по цепочке.

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

Даже если мы обожаем third-party решения я считаю нельзя недооценивать силу простого и скучного кода.

Представь, что в вашу команду приходит новый разработчик.
Если в коде просто передаются значения, то новенькому будет несложно понять:
🟣откуда берутся зависимости,
🟣как они создаются,
🟣и как передаются между компонентами.

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

В следующих постах аккуратно будем погружаться в DI: от самого простого до чуть более продвинутого.

⭐️ Подписки на Tribute

Многие встречаются с проблемой сервиса бусти: не проходит/продлевается оплата; разные цены в разных регионах 🤯 и другие приколы.

Поэтому делаю отдельный пост для истории со всеми подписками трибьюта. Там в целом удобнее и для вас дешевле.

🌟 Подписка мидл
🌟 Подписка мидл+
🌟 Годовая подписка на все виды контента

Вопросы для собеседований SwiftUI: Layout Engine

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

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

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

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

В этой подборке вы встретите > 20 вопросов:
🌟Вопросы о пройденных темах: AttributeGraph, view & render trees
🌟Чем отличается жизненный цикл SwiftUI от UIKit
🌟Что такое концепция Source of Truth
🌟Тонкости property wrapper'ов, отложенный рендеринг и многие другие вопросы

🧬 Получить доступ к разделу и другой контент можно 💰тут или ⭐️ тут

Разбор багов и решений Swift Concurrency

Главная мысль приходящяя с опытом — нет идеальных решений и инструментов. Все можно похвалить и покритиковать. Инструменты не будут приносить только пользу, а их разработчики не смогут расчитать все варианты использований. Не смогут не допускать баги.

На фоне прошлого поста с багами SwiftUI собрал известные и неочень баги Swift Concurrency.

🤢 ConcurrencyRecipes от Matt Massicotte

Этот репозиторий на GitHub содержит практические решения и описания проблем, таких как: Проблемы с изоляцией (actor isolation); Ошибки порядка выполнения; Проблемы с Sendable; Блокировки потоков и зависания; Сложности с async-вирусностью (когда async распространяется по коду); и другие

👎 Статья “Swift Concurrency – Things They Don’t Tell You”

Автор делится наблюдениями о том, как async/await может привести к неожиданным проблемам, особенно при работе с UI и @MainActor. Основные моменты:

🔘async функции могут выполняться на любом потоке, даже если они вызываются с главного потока.
🔘await может приостановить выполнение и позволить другим задачам выполняться, что может привести к неожиданным изменениям состояния.
🔘Использование @MainActor не гарантирует, что весь метод будет выполняться на главном потоке, особенно если внутри есть await.

🤢 Проблемы с Sendable и предупреждения компилятора

Обсуждение на GitHub: “thoughts on Sendable and swift 5.10 concurrency warnings?”
Разработчики обсуждают предупреждения компилятора, связанные с Sendable, и как они могут повлиять на существующий код. Основные моменты:
🔴Предупреждения о том, что определённые типы не соответствуют Sendable, могут быть сложными для устранения.
🔴Некоторые предупреждения связаны с ограничениями языка, которые ещё не полностью решены.

🤢 Сбои при высокой нагрузке

Даже простые задачи с TaskGroup могут часто аварийно завершаться при высокой нагрузке на систему. Проблема связана с повреждением памяти при параллельном выполнении задач.

💎 Рефакторинг — это не про улучшение. Это про выживание

Перечитываю книгу Фаулера "Рефакторинг". В ней он демонизирует плохой код, дает советы как продать бизнесу рефакторинг и жить проще. Ну, всё как мы любим.

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

Спойлер: оно не останется. Хороший код быстрее понимается. В нём проще искать баги. В него безопаснее добавлять новое. Его можно передавать другим — и жопа команды не сгорит.

Когда же грязный код это не про красоту, а про выживание. Где ты добавил фичу и сломал что-то старое. Хотел пофиксить баг и зарылся на часы. А любая правка — это мини-экспедиция с риском не вернуться.

Окей, мы все знаем проблемы херового кода, но как его подчищать и какие процессы существуют? Давайте разберем методики рефакторинга кода в продуктовых командах:

🟣Refactor-as-you-go
Когда добавляешь фичу или чинишь баг — вначале подчисти кусок кода, с которым работаешь. Позволяет улучшать код постоянно, не дожидаясь «идеального времени». Не увлекайся — цель не улучшить весь мир, а упростить конкретную задачу.

🔘Test-Covered Refactoring
Прежде чем что-то менять — напиши или обнови тесты. Рефакторинг должен быть безопасным.

🔘Code Smell Driven Refactoring
Обнаружил «запах» — отреагируй. Например: длинный метод; слишком много параметров; дублирование;

🟣Встроенный рефакторинг в Definition of Done
Команда включает рефакторинг в определение готовности задачи.

Пример: «Фича считается готовой, если код покрыт тестами и улучшен в рамках контекста задачи».

Формализует это как норму, а не "инициативу отдельного разработчика".

В целом, есть еще и разные инструменты как линтер и сонары, а также правила бойскаутов. О них может быть поговорим позже