🧬 Mobile System Design vs Архитектурный собес

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

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

🧬 Что такое проектирование?

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

Собес обычно разделен на несколько этапов. Очень поверхностно разберем на примере чата:
🔘 Сбор основных требований фичи. Например, как пользователь может взаимодействовать с интерфейсом. Отправлять сообщения текстом или прикреплять фотографии. Может ли он удалять сообщения
🔘 Сбор нефункциональных требований. Эти требования играют очень важную роль для стабильности и производительности. Например, будут ли уведомления в реальном времени, офлайн поддержка, оптимизации батерии.
🔘 Дополнительные требования. Тут обычно задаются вопросы про аналитику, логирование сбоев, доступность и безопасность.

На основе этих требований мы и решаем какие паттерны, архитектуры, технологии нам подойдут. Здесь нет универсального ответа в стиле "VIPER/TCA/MVVM — это универсальный паттерн". Бизнес требования не должны натягивать на архитектуры — это архитектура должна адаптироваться к бизнесу.

💎 Еще раз напоминаю, что в ноушене есть полезные подборки, статьи и пересказы книг по архитектурам и system design'у

💎 Вопросы для собесов по многопоточке | Middle | ч. 1

Я уже писал, что вопросы для мидлов создавать гораздо интереснее. Мало инфы в интернете про сложные вопросы, почти нет нигде задач.

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

В этой подборке:
🟣Что такое Dispatch Barrier?
🟣Перечисление и сравнение POSIX мутексов
🟣Работа с NSOperations
🟣В чем разница голодания и livelock'а?
🟣А также еще 20 вопросов и 5 мощных задач

Скоро ждем подборку вопросов про Swift Concurrency

🌿 Этот и другие сборники можно найти тут
🧬 Ознакомиться с другими сборниками тут

BDUI – удовольствие или боль?

Отличный доклад про разбор BDUI. В целом, многие мысли я повторял в своем посте, но тут все подтверждается внутренними метриками.

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

А то наплодятся андроид разрабов, что кричат о замене иосеров. И бэкендеров, что кричат о смерти мобильщиков.

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

Ставь лайк, если нужен в ноушене "Курс по самообороне от KMP и BDUI"

😎 Сила статической диспетчеризации в Swift

Автор статьи рассказывает, что Apple заявляла,как язык Swift в 2,6 раза быстрее по сравнению с Objective-C.

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

В статье он также делает замеры функций и дает советы как оптимизировать код для производительности:
🟣 Что лучше Generics или функции с созданием класса
🟣 Как влияет рекурсия на производительность
🟣 Как не заиграться с оптимизацией и не усложнить код

Я в канале также уже проверял, что Message Dispatch работает медленнней

💎 Больше материала про диспетчеризацию, а также перевод этой статьи, можно найти в ноушене

💎 Обновление ноушена и комьюнити за неделю

Традиционный changelog что изменилось за неделю в ноушене и комьюнити.

Когда я проходил курсы менторства в авито, то нас учили о главном ресурсе, за которым приходит менти. Это коммьюнити. Менти приходит не только за твоими знаниями, но и за твоими социальными связями. А их дают только навыки и опыт.

Какой смысл всяких закрытых ноушенов, ресурсов, роадмапов, если этим никто не пользуется и работает в вакууме? Главное люди и фидбэк, кто использует их и дает корректировки. Важна среда обитания. Материал, который ее наполняет, служит пищей и упражнениями.

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

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

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

Чувство жертвенности подталкивает к поиску навыков и импакта, а твой фидбэк более значимый.

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

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

Я с уверенностью могу сказать, что мы самое первое, быстрорастущее и большое закрытое иос-сообщество.

🌿Вступить в сообщество можно тут

🌿 Скидка на подписку мидл

День неслыханной щедрости!

Мне тут подсказали, что в связи с сезоном собеседований самое время сделать небольшую скидку на middle уровень. Так как конкуренция весной и осенью самая высокая.

На ней вы получите:
🟣 Доступ в чат с практикующими спецами. В нем не будут спамить вопросами новичков.
🟣 Доступ к ноушену
🟣 Доступ к 250 вопросам и 100 задачам для подготовки
🟣Многое другое

С помощью этих инструментов ты сможешь лучше подготовиться, чем конкуренты 😬

💎 Успевай, скидка бессрочная, но ограничена на количество

UPD: Добавил еще 10 подписок

Выгодней всего будет сразу на несколько месяцев

👨‍🦱 ну что, мы переступили этот психологический лимит тракториста

Тем самым став самым большим закрытым сообществом чисто иос-разработчиков с самой большой конверсией. Почти 80%

🍤 Спасибо всем. Это большая и солидная цифра, которая точно повлияет на новые форматы контента и активностей.

🍭 Ваша поддержка и фидбэк дает мотивацию и силы. Обнял-приподнял.

🌿 Оптимизация UI: Offscreen Rendering

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

Начнем с Offscreen rendering.

Off-screen рендеринг это часть отрисовки, которая не может быть выполнена на GPU и должны быть выполнена на CPU.

Низкоуровнево это выглядит так:
при рендеринге layer'a который требует off-screen рендеринг, GPU останавливает процесс рендеринга и передает управление CPU, который выполняет все необходимые операции и возвращает контроль обратно GPU, который затем продолжает процесс рендеринга.

В дополнение к оверхеду по смене контекста, off-screen рендеринг также требует выделения дополнительной памяти.

Кейсы которые приводят к off-screen рендерингу:
🟣Кастомный drawRect (даже если мы просто заполняем background цветом)
🟣CALayer corner radius
🟣CALayer shadow
🟣CALayer mask
🟣Любая кастомная отрисовка с использованием CGContext

Как найти проблему с off-screen rendering?
В случае с corner radius, проблему можно решить отрисовав контент с округленными углами заранее. К примеру, если мы хотим показать аватарку с округленными углами, вместо того чтобы выставлять cornerRadius у UIImageView, мы можем отрисовать аватарку с округленными углами и соотвествущим фоном за ними. Таким образом сделав сделав округленные углы частью bitmap'a.

В случае с тенями, мы можем заранее посчитать и выставить shadowPath у layer'a, либо использовать картику теней для достижения нужного эффекта.

💎 В ноушене уже полная статья со всеми советами, туториалами и примерами в коде

🧵 Thread в Swift

В 95% случаев современные разработчики используют GCD как инструмент для многопоточности. Но иногда, нам требуется создать отдельный тред для дополнительных задач. В Swift мы легко сделаем это с помощью Thread.

Собрал подборку статей про:
- Основные советы по Thread: создание, синхронизация, завершение
- Исследование потоков в Swift
- Жизненный цикл Thread'ов

🌿 Еще больше задач и примеров про них тут