Mobile System Design: Low-connectivity mode. Проблемы покрытия сети и их решения

Определить, что человек работает в СНГ реалиях, очень просто. Стоит только упомянуть про массовые блокировки интернета. На удивление об этом мало кто пишет.

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

Это новая среда выживания. Сначала удаление аппок из стора, отключение GPS, просадки мобильной сети, перебои в LTE. Хотели hardcore mode? Выживание в спартанских условиях.

Это чувствуют таксисты, курьеры, продавцы маркетплейсов. Весь малый и сервисный бизнес. Но он старается адаптироваться. Придумывает обходные механики, внедряет BDUI, работает с вайтлистами, настраивает работу под локальные Wi-Fi точки, добавляет fallback-режимы. Как можно решить такую проблему?

Вот варианты:

1️⃣ Ограничение запросов/ответов

Грузить с сети только критические данные. Так я разок сократил время загрузки контекта в 2 раза, при херовом интернете. Особенно часто на него ругались важные заказчики когда летали в самолетах или были в странах с херовым интернетом. Показывая "а вот в телеграме все лучше!". Эх если бы мне платили столько как в телеграме...

2️⃣ Offline First

Я слышал тот же WB, пока конкуренты делают ставку на BDUI, решил перейти на offline first. Мне честно сложно пока понять логику, но вроде попробовал собрать.

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

Так мы не упускаем юзера, все его поведения сохраняются локально, а отправляется сразу с подключением к нормальной сети (или делится на чанки и постепенно)

3️⃣ Резать медиа файлы

Мы уже отдельно проходили как оптимизирует трафик тот же запретограм. Вкратце:
- Prefetching
- Chuncking
- Размеры под разные соединения

4️⃣ Разделяй критичность и второстпенность

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

Поделитесь своими рекомендациями как выживать в текущем мире.

Профилирование и Перфоманс метрики

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

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

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

Такую систему мало где видел, поэтому решил изучить открытые third party библиотеки:

1️⃣ Xcode Performance and metrics

Плюсы: Глубокий анализ CPU, памяти, графики в реальном времени; бесплатный и интегрирован в Xcode.
Минусы: Требует подключенного устройства; не для production-мониторинга

2️⃣ MetricKit

Плюсы: MetricKit работает пассивно в продакшене. Уже лучше для релиза
Минусы: Отчеты передаются только раз в сутки

3️⃣ New Relic Mobile

Плюсы: Облачный мониторинг в проде, можно следить за трендами версий и делать сравнения. ​
Минусы: Платный

4️⃣ Firebase Performance

Плюсы: Неплохой базовый бесплатный функционал
Минусы: Мало инструментов

Расскажите какие необычные инструменты для профилирования и метрик юзаете вы? Пишите ли сами или используете готовые решения?

Как фиксить AI-генерейтед Swift код

Эту статью уже обсудили и на линкедине, и в тг, и в тв.

Генерация кода с АИ стала новым скиллом. Когда ты раньше точечно и аккуратно писал в ручную небольшой, но выверенный код, то сейчас игра поменялась.

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

Еще больше усложняет то, что Swift код от ИИ в разы хуже того же Kotlin'а, Go, Python'а из-за их популярности. В этой статье автор дает лайфхаки как фиксить код от аишек:
- Если проект неправильно настроен на rules, то АИ могут игнорировать общий стиль и правила.
- Проблемы с асинхронностью и управлением потоками. Часто он генерит GCD, чем Swift Councurrency
- АИшки редко думают о корнеркейсах. Здесь их нужно поправлять и давать доп условия.
- Пиши тесты и не стесняйся их использовать

Ну и главное правило — использовать аи как помощника, а не как источник истины.

Кстати, делюсь главной книгой года по продажам в Amazon.

За которую я отдал 60$. А вам, дорогие зрители, дарю ее!

https://www.group-telegram.com/iosmmcresources/129

AI Engineering: Основные навыки AI-разработчика

Давайте немного о книге выше.

Chip Huyen пишет:

AI-разработчик — это не тот, кто общается с ChatGPT. Это тот, кто умеет превращать модель в рабочую систему. Если классический разработчик пишет правила, то AI-разработчик пишет условия, в которых модель думает правильно.

Если вкратце, она определяет такие критерии:

1️⃣ Prompting

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

2️⃣ Контекст-инженерия

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

3️⃣ Адаптация моделей: finetuning, выбор моделей, компромиссы

Нужно понимать, когда достаточно промпта, когда нужен RAG, а когда — дообучение. Как в готовке блюд. Иногда достаточно соли, иногда нужна новая специя, а иногда целый новый рецепт.

4️⃣ Оценка качества (evaluation): метрики, AI-судьи, тесты

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

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

В идеале, нужно делать так:
1. Вместо обычного запроса "сверстай мне кнопку" дай АИ максимальное описание с API JSON'ом, стили, состояния
2. Опиши какие действия она выполняет.
3. Какие условия и ограничения есть.
4. Отдельно автор подчеркивает важность guardrails. Для UI это означает: проверка, что данные валидны. Убедись что AI не прислал недопустимый код. Убедись что поведение безопасно.
5. Огромный акцент на feedback loop: не забывайте писать аишки правильный ли результат она сделала. Даже ваши лайки влияют на ее следующие генерации.

Проектирование реальных фич: Feed App ч 1

Продолжаю тему книг.

Среди книг про моб систем дизайн самая практичная — это "Mobile System Design Interview" от ByteByte. Здесь нет философии в пусть и хорошей, но очень большой Mobile System Design.

В книге от ByteByte все главы направлены практику. Только хардкодному проектированию. В первой общедоступной главе разбирают одну из самых частых фичей — ленту новостей.

Вопреки заблуждениям, новостная лента — это не просто список постов.

Я разобью инфу на несколько постов. Первый про общие требования и ожидания.

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

Ключевая сложность — это как собрать правильные посты и отдать их быстро. Так как обычно ленты делаются для миллионой аудитории.

При проектировании фичи обычно выделяют:
- пагинация
- Низкая задержка. Лента должна открываться быстро
- Масштабируемость.
- Оптимизации для плохого интернета

Есть несколько основных подхода для формирования ленты

1️⃣ Pull model (on-the-fly)

Когда пользователь открывает ленту:
- сервер собирает посты прямо сейчас
- сортирует публикации
- отдает результат

Плюсы
- простая логика
- всегда актуальные данные

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

2️⃣ Push model (precomputed feed)

Когда кто-то публикует пост:
- он заранее раскладывается в ленты подписчиков
- при открытии ленты данные уже готовы

Плюсы
- очень быстрая загрузка ленты
- меньше вычислений при чтении

Минусы
- дорого по памяти
- сложнее поддерживать

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

По мнению автора что хотят услышать интервьюеры:
- ты понимаешь trade-offs (push vs pull)
- ты думаешь про кэш
- ты учитываешь мобильные ограничения
- ты умеешь объяснять архитектуру шаг за шагом

1/3

wtf? Ждем переезда в Max?