Мы уже объясняли такую ментальную модель как View Tree, но под капотом нет такого понятия. Есть только AttributeGraph. Разница между деревом (tree) и графом (graph) в том, что в графе зависимости могут течь в любом направлении. Это значит, что визуально структура UI напоминает дерево, на самом деле под капотом используется граф зависимостей, где узлы могут иметь взаимные зависимости.
Как мы уже помним, чтобы писать более производительный код на SwiftUI, мы должны понять этот фреймворк. Apple скрыл внутренности как это работает, хоть некоторые и пытались зареврс инжинирить. Вокруг этой темы нет документаций. Материалы отличаются только по уровню практических ресерчей от комьюнити. Единственное, что мы можем — опытным путем изучить работу этого механизма.
AttributeGraph — это граф с расширенной моделью атрибутов. Ключевая особенность — это не просто связи между узлами, а система распространения изменений атрибутов. SwiftUI — декларативный UI. А чтобы декларативный UI работал эффективно, нужен быстрый механизм обнаружения изменений.
AttributeGraph — это не уникальная концепция. Очень похожая есть и в React с его виртуальным DOM'ом и других технологиях.
Ключевые понятия AttributeGraph:
Схема работы AttributeGraph в SwiftUI выглядит так:
1. Создание узлов данных (Nodes): Когда ты описываешь @State, @Binding, @ObservedObject, SwiftUI: создаёт отдельные Node объекты для каждого состояния.
2. Первая вычислительная фаза — Построение зависимостей (Edges). Когда SwiftUI вычисляет body SwiftUI включает режим записи зависимостей: Каждый доступ к данным регистрируется как: graph.addEdge(from: variableNode, to: viewNode). Это происходит автоматически во время первого прохода по body
3. Реакция на изменение данных — Инвалидирование (Invalidation Phase). Система помечает изменённые узлы и пересчитывает только нужные значения.
4. После пересчёта SwiftUI перерисовывает только те элементы интерфейса, которые реально изменились.
Вдохновившись серией выпусков от objc.io решил сделать примерную реализацию графа. Детальней в скриншотах, но потом сделаю большую статью в ноушене. В будущих постах сделаем связь между узлами и других особенностей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
iOS Makes Me Hate
Теперь можете брать задачу на собесы для SwiftUI - написать свою реализацию AttributeGraph 😂
Please open Telegram to view this post
VIEW IN TELEGRAM
На Я.Субботниках технические специалисты Яндекса рассказывают об устройстве сервисов, над которыми они работают. В этот раз собираемся в двух городах — Москва и Санкт-Петербург!
Что ждёт участников:
Среди тем докладов этого года: секреты адаптации мобильного приложения под ТВ, стратегии ускорения старта и observability-система для BDUI. Полное расписание ищите на сайте.
➡️ Регистрируйтесь и приходите слушать доклады, задавать вопросы и обсуждать кейсы
Please open Telegram to view this post
VIEW IN TELEGRAM
Разработка приложений в больших командах — отдельный вызов и опыт. Когда твоя команда и продукт небольшой, то многим можно пренебречь. Но уже с увеличением аудитории и команды объемы производства кода увеличиваются, а значит и импакт от оптимизаций тоже растет.
Попалась подборка интересных статей про архитектуру SwiftUI приложений в больших командах. Мы уже писали о некоторых статьях, но есть и новые.
Подробное руководство по модульной архитектуре для масштабных SwiftUI-приложений. Как разбить проект на независимые модули и упростить сопровождение.
Практики проектирования архитектуры с использованием SwiftData. Управление моделью данных, работа с хранилищем и зависимости.
Подходы к валидации пользовательского ввода: как сделать формы безопасными, удобными и повторно используемыми.
Как компоненты SwiftUI обмениваются данными — через @Binding, @Environment, ObservableObject и другие способы.
Управление модальными окнами (sheets) из любого места приложения. Упрощает отображение экранов без жёсткой связи между модулями.
Обзор современных навигационных подходов: StackNavigation, Routing, NavigationPath и как избежать “адской” вложенности.
Please open Telegram to view this post
VIEW IN TELEGRAM
AzamSharp
Building Large Scale Apps Swiftui
Blog about iOS development and musings on technology
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
Забирает ли AI радость от работы
Большинство знакомых мне людей сходятся на том, что AI точно повышает продуктивность индивидуального разработчика – код пишется и рефакторится быстрее, а задач закрывается больше. Для тех, кого мы привыкли называть "продуктовыми разработчиками" – людей, кого в первую очередь драйвит результат их работы, создаваемый продукт, и его влияние на бизнес и мир вокруг – это просто прекрасно и бьет в их факторы мотивации.
Но помимо них в индустрии есть довольно большой сегмент тех, кто любит сам процесс написания кода, и получает удовольствие от самостоятельного решения инженерных задач. Использование AI, конечно, оставляет инженерные задачи, перемещая их на более высокий уровень – ты должен думать не столько о том, как реализовать нужный алгоритм, сколько о том, как спроектировать систему. Но для многих этого будет недостаточно – ведь и раньше не каждый хотел расти в архитектора.
Так вот, для таких разработчиков AI хоть и повышает механическую продуктивность, но при этом забирает из работы всю радость, ничем ее не заменяя. Что с этим делать пока не очень понятно, так что пока что просто ноем вместе с автором статьи и продолжаем нажимать Tab-Tab-Tab.
Большинство знакомых мне людей сходятся на том, что AI точно повышает продуктивность индивидуального разработчика – код пишется и рефакторится быстрее, а задач закрывается больше. Для тех, кого мы привыкли называть "продуктовыми разработчиками" – людей, кого в первую очередь драйвит результат их работы, создаваемый продукт, и его влияние на бизнес и мир вокруг – это просто прекрасно и бьет в их факторы мотивации.
Но помимо них в индустрии есть довольно большой сегмент тех, кто любит сам процесс написания кода, и получает удовольствие от самостоятельного решения инженерных задач. Использование AI, конечно, оставляет инженерные задачи, перемещая их на более высокий уровень – ты должен думать не столько о том, как реализовать нужный алгоритм, сколько о том, как спроектировать систему. Но для многих этого будет недостаточно – ведь и раньше не каждый хотел расти в архитектора.
Так вот, для таких разработчиков AI хоть и повышает механическую продуктивность, но при этом забирает из работы всю радость, ничем ее не заменяя. Что с этим делать пока не очень понятно, так что пока что просто ноем вместе с автором статьи и продолжаем нажимать Tab-Tab-Tab.
Terrible Software
The Hidden Cost of AI Coding
AI coding tools boost productivity but may sacrifice the flow state and deep satisfaction developers experience when writing code by hand. What are we losing?
считаете ли вы что мы на пороге новой промышленной революции в ит?
Anonymous Poll
23%
Да, ит заменит всех неподготовленных
21%
Да, но будут незначительные изменения
41%
Нет, это лишь новый дополнительный инструмент
6%
Нет, всё это скам
8%
Хз, еще не определился
Подборка известных багов SwiftUI
Разработчики — неидеальные люди. За тоннами статей и документаций всегда стоит практика, которая срывает покров реальных проблем.
Не все, что описано, работает как ожидается. А многое может быть вообще не описано.
Для меня гораздо полезнее разборы тех вещей, которые не прочитаешь в исходниках, документациях и тп. Например, очень часто бывают баги или даже краши, когда воспроизводятся только под определенной версии iOS, swift’а или даже Xcode.
Позже разберем какие-нибудь отдельные из репы.
Кстати, скоро попробую собрать похожее с Swift Concurrency. Недавно обожглись и с ним🥲
Разработчики — неидеальные люди. За тоннами статей и документаций всегда стоит практика, которая срывает покров реальных проблем.
Не все, что описано, работает как ожидается. А многое может быть вообще не описано.
Для меня гораздо полезнее разборы тех вещей, которые не прочитаешь в исходниках, документациях и тп. Например, очень часто бывают баги или даже краши, когда воспроизводятся только под определенной версии iOS, swift’а или даже Xcode.
Позже разберем какие-нибудь отдельные из репы.
Кстати, скоро попробую собрать похожее с Swift Concurrency. Недавно обожглись и с ним
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - ryangittings/swiftui-bugs
Contribute to ryangittings/swiftui-bugs development by creating an account on GitHub.
1 12
This media is not supported in your browser
VIEW IN TELEGRAM
Сорри, пока майские чисто деградируем под мемы
В it нет «правильных» или «неправильных» законов и правил
Следующий месяц мы продолжим погружаться в непростые и практичные вещи в SwiftUI, поэтому обещаного традиционного голосования с темой на месяц не будет. Демократия закончилась🥲
Нередко слышу инженеров, которые ищут тех, кто будет с полуслова их понимать. Тем, кому не нужно объяснять почему здесь нужно использовать SOLID принципы или долго выбирать правильное решение, а моментально на каком-то экстрасенсорном уровне приходить к одному решению. Считаю это фантастикой. Ведь любая разработка это всегда поиск решений и изучение разных требований, которые никто не найдет в абсолютном молчании или согласии. Эффективный процесс принятий решений — это всегда большой труд.
Начнем этот месяц с разбора темы «правильных путей». Автор делится мнением, что нет никаких правильных архитектур и решений. Многие вещи зависят от целей и контекстов.
🌟 контекст имеет значение
Некоторые решения, такие как вызов главного потока, имеют строгие ограничения. Но большинство архитектурных или других инструментов сильно зависят от контекста.
🌟 нет серебряных пуль
У каждых решений есть свои недостатки и плюсы.
🌟 субъективные предпочтения
Многие решения зависят от личных предпочтений и опыта команды. Важно осознавать эту субъективность и избегать навязывания своих предпочтений как единственно верны
Показатели зрелости команды это когда опытные разработчики умеют выбирать подходы, соответствующие конкретным задачам, а не следовать моде или личным предпочтениям.
SwiftUI vs UIKit
Автор рассматривает дебаты между сторонниками SwiftUI и UIKit. Он отмечает, что SwiftUI отлично подходит для простых проектов, но может быть менее эффективным для сложных приложений, где UIKit предоставляет больше гибкости. Таким образом, выбор между ними должен основываться на требованиях конкретного проекта, а не на общих предпочтениях.
В целом вся разработка это не то место, где есть шаблонный универсальный алгоритм. Это место дискуссий, поиска компромиссов, осознание целей и условий проекта.
Принятие этой идеи способствует профессиональному росту и более эффективной работе в команде.
Следующий месяц мы продолжим погружаться в непростые и практичные вещи в SwiftUI, поэтому обещаного традиционного голосования с темой на месяц не будет. Демократия закончилась
Нередко слышу инженеров, которые ищут тех, кто будет с полуслова их понимать. Тем, кому не нужно объяснять почему здесь нужно использовать SOLID принципы или долго выбирать правильное решение, а моментально на каком-то экстрасенсорном уровне приходить к одному решению. Считаю это фантастикой. Ведь любая разработка это всегда поиск решений и изучение разных требований, которые никто не найдет в абсолютном молчании или согласии. Эффективный процесс принятий решений — это всегда большой труд.
Начнем этот месяц с разбора темы «правильных путей». Автор делится мнением, что нет никаких правильных архитектур и решений. Многие вещи зависят от целей и контекстов.
Некоторые решения, такие как вызов главного потока, имеют строгие ограничения. Но большинство архитектурных или других инструментов сильно зависят от контекста.
У каждых решений есть свои недостатки и плюсы.
Многие решения зависят от личных предпочтений и опыта команды. Важно осознавать эту субъективность и избегать навязывания своих предпочтений как единственно верны
Показатели зрелости команды это когда опытные разработчики умеют выбирать подходы, соответствующие конкретным задачам, а не следовать моде или личным предпочтениям.
SwiftUI vs UIKit
Автор рассматривает дебаты между сторонниками SwiftUI и UIKit. Он отмечает, что SwiftUI отлично подходит для простых проектов, но может быть менее эффективным для сложных приложений, где UIKit предоставляет больше гибкости. Таким образом, выбор между ними должен основываться на требованиях конкретного проекта, а не на общих предпочтениях.
В целом вся разработка это не то место, где есть шаблонный универсальный алгоритм. Это место дискуссий, поиска компромиссов, осознание целей и условий проекта.
Принятие этой идеи способствует профессиональному росту и более эффективной работе в команде.
Please open Telegram to view this post
VIEW IN TELEGRAM
Swiftrocks
There is no right or wrong in software engineering
Developers love to argue about which tools and languages are better. In this article, we'll see that things are not that straightforward in practice.
Кодстайл в крупномасштабном проекте на примере SwiftUI
Читаемость проекта очень важна. Почти сразу после стабильности и работаспособности. Чистый код улучшает структуру, уменьшает когнитивную нагрузку и ускоряет производство и деббагинг. Поэтому мы чаще жертвуем уникальностью и следуем консистентности.
Особенно согласованность важна в командной работе. Не редко, общие архитектурные паттерны, структура модулей или даже кодстайл легко помогает погрузиться в проект. Например, каждый сервис бэкенда в Авито был очень сильно похож на предыдущий, что помогало соседним командам легко погружаться в чужой код и подхватывать задачи. В мобилке же вообще делать разные модули в избыточно разных архитектурах — редкость.
Статья подчеркивает важность командной работы и согласованности в больших проектах. Хорошо продуманное руководство по стилю кода:
🌟 Упрощает совместную работу.
🌟 Облегчает обучение новых разработчиков.
🌟 Повышает качество и стабильность продукта.
Здесь много очевидных вещей, но если ищите чеклист для вдохновения для своей команды, то отличный пример
Читаемость проекта очень важна. Почти сразу после стабильности и работаспособности. Чистый код улучшает структуру, уменьшает когнитивную нагрузку и ускоряет производство и деббагинг. Поэтому мы чаще жертвуем уникальностью и следуем консистентности.
Особенно согласованность важна в командной работе. Не редко, общие архитектурные паттерны, структура модулей или даже кодстайл легко помогает погрузиться в проект. Например, каждый сервис бэкенда в Авито был очень сильно похож на предыдущий, что помогало соседним командам легко погружаться в чужой код и подхватывать задачи. В мобилке же вообще делать разные модули в избыточно разных архитектурах — редкость.
Статья подчеркивает важность командной работы и согласованности в больших проектах. Хорошо продуманное руководство по стилю кода:
Здесь много очевидных вещей, но если ищите чеклист для вдохновения для своей команды, то отличный пример
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
Mastering Coding Style Guides for Large-Scale Codebases - With a SwiftUI Case Study
Developers often get caught up in building their technical skills and learning new tools, sometimes taking attention away from the teamwork…