SwiftUI: Advanced View Trees vs Render Trees

Начал новый большой цикл статей и материалов по SwiftUI. В этом блоке мы затронем фундаментальные вещи о важных концепциях:
🟣View Trees vs Render Trees
🟣Процесс рендеринга
🟣Indentity
🟣Лучшие практики
🟣Решение задач на практике

Старался подобрать важные материалы, чтобы после не осталось никаких вопросов.

🧬 Получить материалы вы можете 💰 тут или ⭐️ тут

Performance analysis of SwiftUI and UIKit

кек. Изучаю перфоманс двух фреймворков и нашел чью-то магистерскую диссертацию.

В ней автор делает анализ перфоманса по двум ключевым метрикам:
🟣время работы CPU;
🟣использование памяти для различных UI-компонентов.

Ключевые результаты:
🔘UIKit в целом показал примерно на 25% лучшую производительность, чем SwiftUI
🔘SwiftUI стабильно потребляет больше памяти, чем UIKit во всех сценариях
🔘Наибольшая разница в использовании памяти наблюдалась в сценариях с кнопками и коллекциями

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

The Composable Architecture — худшее, с чем я работал

В прошлом посте мы обсуждали тему декомпозиции и косвенно затронули тему архитектуры. Сейчас мы косвенно поговорим почему выбор паттернов и шаблонов, слепое натягивание SOLID'ов и использование чужих шаблонов чаще вредит, чем помогает.

При изучении SwiftUI нельзя не затронуть популярную архитектуру TCA. За все существование канала я почти о ней не писал и это не просто так. И сейчас объясню почему.

За практику работы с VIPER, когда его пихали в любой проект, я понял, что архитектурные паттерны UI слоя тоже должны выбираться с умом. У этого процесса должен быть этап обсуждений с командой и сбор требований. Груммить и челенджить их нужно до написания кода. Это здоровый и осознанный подход.

Но такого в 90% нет. Обычно какой-нибудь новоиспеченный лид с опытом 2 года насмотрится докладов с конференций или начитается статей. И вдруг заставит всех через диктатуру перейти на любимую им архитектуру. Я считаю этот подход самым худшим и наименее эффективным.

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

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

Вот и автор статьи делится критическим взглядом на опыт использования:
🟣Крутая кривая обучения: многие говорят, что большинство проблем с TCA — это skill issue и зависит от кривизны рук, но я так не считаю. И если технология требует много времени на обучение — это не очень и хорошая технология. Можно и молотком выполнять 90% задач.

🟣Сложность структуры: Feature, State, Action и Reducer, приводит к усложнению кода и увеличению его объема.

🟣 Проблемы с производительностью: обсервинг состояний в TCA приводит к избыточным перерисовкам, что негативно сказывается на производительности.

🟣Навигация и композиция: Автор критикует подход TCA к управлению навигацией и объединению функций, указывая на излишнюю сложность и нарушение принципов SOLID, особенно принципа единственной ответственности.

🟣Управление зависимостями: Использование собственной системы управления зависимостями в TCA рассматривается как избыточное и усложняющее код без явных преимуществ перед стандартными методами.

Топ советов для себя в начале пути

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

🟣Нет никаких гайдов.
Когда ты новичок ты думаешь, что твоя работа — это только писать код. Но чем дольше ты в индустрии, тем лучше понимаешь, что код — это только 1/10 эффективного результата.

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

🟣Изучай всё. Наша индустрия развивается быстрее всех. Она создает целые виртуальные вселенные и только находясь внутри нее ты можешь ее чувствовать. Но иногда нужно выходить за границы и смотреть на нее со стороны.

Изучай базу, алгосы, архитектуры. Они отличный фитнес для улучшения кодерских навыков. Вдохновитель на новые идеи. Закрепление старых.

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

🟣Понимай ценности для бизнеса.
Ты — коммерческий разраб. Тебя не нанимают для убыточного прожигания бюджетов бизнеса. Весь твой перфекционизм разбивается об прагматизм. Ты не просто пишешь код — ты создаешь продукт.

Особенно актуален этот навык с развитием ИИ, где все мы перестанем быть кодерами и будем микро-предпринимателями.

🟣Будь частью команды.
Программирование стало командным видом спорта. Эпоха соло кодеров ушла. Большинство проблем, которые мы решаем — это договоренности, сбор требований и понимание потребностей. Ты выигрываешь не когда пишешь самый крутой код, а когда команда выпускает рабочий продукт.

🟣Умей делать сложное простым.
Самый сложный для меня навык. Умение объяснять сложное простыми словами — редкий, но ценный навык. Это помогает и в код-ревью, и в защите решений перед продуктом или заказчиком. Это помогает не оверинженерить и находить множество эффективных путей.

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

В одном из последних ИПР на работе мы с моим руководителем придерживались концепции "80/15/5". Где 80% — это практика на работе, 15% это дополнительное образование и 5% это книги и другие источники образования. Многие лишь повторяют что практика нужна, но их слова или контент — это репосты чужих статей или копирование других идей. А их авторских мыслей или постов с уникальной экспертизой нет. Они лишь повторяют что важна практика, но каждое их действие — это очередная копия.

Мне не хочется идти по этому пути.

🗑 Почему наш подписчик от TCA отказался

По следам прошлого поста получили свежий отзыв от подписчика чата про выпил TCA. @ios_iss_blog решил дать очень ценный и хорошо сформулированный комментарий. Поделился своим опытом использования TCA на большом проекте. И как они от него отказались. 😬

Он обещал написать большую статью на Хабре с детальными примерами. Очень ждем.

У TCA очень много преимуществ, начиная от эргономики, observability и высоким уровнем возможности покрытия тестами

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

При этом, есть несколько особенностей:

- изменение в любом сторе ведет к вызову всех редьюс методов во всех сторах по всему дереву, почему?

1) Таким образом достигается observability, и в этом и есть смысл TCA

2) Нельзя приватить actions в чайлд сторе, так как это enum, поэтому любой чих в приложении, это редьюс всех сторов

3) Да, в простых приложениях редьюсеры лежат на стэке, и, мол, прогон каждого экшена - ничего страшного, из этого возникают новые проблемы:

i: Переполнение стэка (прям мужицкий краш, из-за которого есть гайды, как перекинуть стэк в кучу в TCA)

ii: По моим замерам на банковском приложений (простом технически, но много флоу и экранов), при открытии глубоко экрана по иерархии с CPU начинается беда, и каждый клик кнопки начинает «ощущаться» физически

iii: Практики начинают создавать мультисторы, когда помимо корневого, то создаешь новые, но связываешь их не через скоуп TCA, а через экшены в конкретном флоу. Это позволяет приватить (логически) экшены, потому что ты их не отправляешь сам, но тут начинает теряться весь смысл TCA

возвращаемся к особенностям:

- Сомнительная работа в рамках Swift Cuncurency:
1) нельзя редьюсер подписать под main actor, и в редьюс методе приходится писать переходы на мейн поток

2) казалось бы, а если бы всю эту жатву вынести в бэкграун поток, таким образом вся бизнес логика будет в бэкграунде (мечта любителей бигтеха?). Если коротко - то нет, редьюсеры чисто на главном потоке, если мы говорим про основное дерево редьюсеров

3) из-за этого нельзя (можно, но больно) создавать редьюсеры для сервисов, чтобы был observability и stability сервисов. Опять же можно, но с главного потока либо прочие костыли. Да и опционально создавать их тоже гемор, с особенностями

возвращаемся к особенностям:

- баги и краши TCA. Если коротко: они есть

- Навигация с концепцией TCA - это работа со стейтом, что в рамках SwiftUI топ, но опять же, либо баги SwiftUI, либо костылишь на UIKit. А так как я предпочитаю динамическую навигацию, основанную на дереве, по типу Route Composer, с TCA не совмещается особо.

- Тянешь TCA, значит тянешь 10+ либ, ребята молодцы, но уровень входа в проект растет. Плюс дока и экзамплы оставляют желать лучшего.

Наверняка еще что-то было, и, в целом, мы со всеми недостатками нашли способ работать, но вот когда начало страдать CPU, было началом конца TCA в нашем проекте

Кст выпил TCA очень прост, заменяем редьюсер на VM, редьюс метод на func, а стейт на @Published

Даже половина тестов сразу сохранили

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

Я считаю, что делиться реальным практическим опытом, а не пересказами чужих статей и документаций, преступно нужно.

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

В критике после реального опыта — больше пользы. О ней мало кто скажет, потому что мало кто попробует. А еще меньше соберется сформулировать отзыв. Еще сложнее быть готовым к критике своего мнения, которое не похоже и отличается, на это тоже нужно мужество. Именно поэтому я и ставлю практиков на вершину иерархии и их мнение самое важное в моих приоритетах.

🧑‍💻 SwiftUI: Подборка лучших задач для изучения часть 1

⏺ Уровень: Junior

Собрал топ полезных задач, которые помогут для первых шагов в изучении SwiftUI.

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

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

Кстати, в базе уже есть два авторских роадмапа: общий от комьюнити и роадмап по SwiftUI от разрабов Авито

🧬 Получить материалы вы можете 💰 тут или ⭐️ тут

Подборки книг для инженеров от разраба Spotify

Пока я в небольшом отпуске перед выходом на новую работу, ищу себя чем занять. Прошел две части Ori (одна из лучших игр ever), посмотрел пару сериалов, походил в бани и зал. Даже с женой посмотрели пару выпусков "Беремена в 16". И узнал что такое мемы про italian brainrot, мой любимый это crocodilo bombardino.

Но пора потихоньку выходить из такого отпуска. Начинать разминать мозг. Вот подборка крутых книг от сеньора иосера и нашего любимого блогера:

🟣Write Great Code: Understanding The Machine (Randall Hyde)
Лучшая альтернатива Танненбауну. Понятное введение в то, как работают современные компьютеры. Книга не перегружена техническими деталями, но помогает глубже понять, что происходит “под капотом”.

🟣*OS Internals Trilogy (Jonathan Levin)
Отдельная рекомендация автора. Подробное руководство по внутреннему устройству платформ Apple. Рекомендуется опытным разработчикам, интересующимся такими темами, как загрузчики и ядра. Книги объемные и не подходят для новичков.

🟣Hacking: The Art of Exploitation
Первая часть книги посвящена C и ассемблеру, что может быть устаревшим. Однако вторая часть предлагает полезное введение в сетевую безопасность и основы реверс-инжиниринга.

💎 Большая статья SwiftIU: State, Binding, Observable и частые ошибки

Роадмапы и шпаргалки "100 вопросов на собесах в компанию N" — вымерли как формат обучения. EdTech не стоит на месте. Индусы засыпали линкедин топ 1к вопросов, их даже можно посмотреть в наших ресурсах. А чатгпт дает всю базу сразу в лоб.

Рекрутеры ищут самых любопытных. Теперь среди кандидатов выигрывает не тот, кто знает ответ. А тот, кто знает самый полный и глубокий. Чей ресерч был лучше, подходящей и практичней. А мысли сформулированней (Так он лучше промтит 😂)

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

В этой статье я разобрал:
🟣как устроен под капотом State
🟣что такое Binding и как он устроен в кишках
🟣лучшие практики использования State & Observable
🟣И другое

📹 Ну а к концу следующей недели ждите тестовый мини-обучающий видос для самураев. Видео формат — будущее образования?

🧬 Получить материалы вы по подписке 💰 тут или ⭐️ тут