System Design

Описывают как пользователь будет взаимодействовать с приложением. Примеры:

• Возможность проскроллить приложения в каталоге или загрузить их.

• Аутентификация пользователей: создание учётных записей, вход в систему, сброс паролей.

• Корзина покупок: добавление товаров, просмотр содержимого корзины, переход к оформлению заказа.

• Функция поиска: поиск продуктов по ключевым словам.

Незаметны пользователю но влияют на его опыт взаимодействия с приложением. Примеры:

• Кэширование или подгрузка превью в низком разрешении для экономии трафика.

• Производительность: загрузка веб-страницы менее чем за 3 секунды при одновременном использовании 100 пользователей.

• Безопасность: соответствие отраслевым стандартам безопасности и протоколам шифрования.

• Масштабируемость: способность приложения справляться с увеличением пользовательского трафика.

Локализуем проблему на кластере устройств. Если проблема на сильный устройствах - очень плохо, если на слабых - уже не так плохо. Запустить посмотреть, потыкать UI с помощью LayoutInspector, для compose соответственно бенчмарки, как композиция происходит, слишком много рекомпозиций, добавить аннотации. Обычно проблема в плохо написанном UI который не аффектит на сильных устройствах. Сложные анимации, грузят слишком большие картинки, выполняют запросы не на тех потоках. Тестить на устройствах среднего и слабого сегмента. Наладить перфоманс тесты. Подключить линтеры. Сделать производительность как бизнес-фичу.

• Слать смс.

• Аналитика открытия пушей.

• GMS и HMS.

Использовать стандартный DownloadManager.

POST-запрос через HTTP. Объект грузится по частям (чанки). Информация указывается в заголовках запроса.

• Сколько идут запросы.

• Сколько жрет оперативки.

• Сколько жрет заряд батареи.

• Скипаются фремы кадры в секунду отзывчивость UI.

• Время старта приложения.

• Как забивается кэш.

Следить за метриками: TTID (Time-To-Initial-Display) отрисовка 1 кадра и TTFD (Time-To-Full-Display) готов к взаимодействию с юзером.

Метод Activity.onCreate оказывает наибольшее влияние на время загрузки.

• Ленивая инициализация зависимостей (библиотека AppStartup).

• Не использовать тяжелые макеты которые долго инфлейтятся.

• У большинства телефонов 4 и больше ядер. использовать многопоточность.

• Кэширование.

• Отключить autoplay у медиа.

• Грузить картинки в низком разрешении.

• Пагинацию уменьшим до 10 айтемов.

Картинки можно конвертировать в base64.

Репликация - полное копирование бд на такой же сервер. Любой из этих серверов будем называть Node. Реплики будут синхронизироваться с мастером.

• Отказоустойчивость - если мастер умерт одна из реплик его заменит.

• Чтение - читать можем из любой ноды. в три раза больше.

Шардирование - не дублирует данные а разделяет их по нодам.

• Записывать можем в 4 раза больше данных одновременно.

• Диска стало тоже в 4 раза больше.

Представьте, что вам нужно разработать бесконечный список в Android с использованием архитектурного паттерна MVVM, корутин и Jetpack Compose.

• Договориться с бэкендом о контракте: Page / Limit-Offset / LastId.

• Затащить библиотеку Paging.

• Прототипирование.

• UI.

• Бизнес-логика.

Возьмем чистую архитектуру. Data (API, DB), Domain (Interactor, UseCase), Presentation (Compose). ViewModel + MVVM или MVI.

Основные требования: поле ввода, подсказки, результаты.

Дополнительные требования: предварительный поиск в кэше, дебаунс на поле ввода.

Будет работа с финансами. Подумать о безопасности хранении данных. Провайдеры биллинга. Категории товаров должны попадать под категории публикации в магазинах приложений требования гугла. Приложение - это витрина, продумать дизайн и бэкенд. Нужна ли авторизация? Декомпозировать главные фичи: авторизация, витрина, корзина. Чтобы фичи пилились параллельно - чистая архитектура, разбить по gradle-модулям, чтобы команды не пересекались. Один на всех database-модуль, network-модуль, core-ui модуль. У каждой фичи должен быть 1 модуль, который я подключаю и он сам внутри себя тянет нужные ему модули. Круговой зависимости не будет, общий код вынесем в другой модуль. Модуль application знает про все фичи и может вызывать их с помощью deeplinks.

Требования:

• Нагрузка 500 млн пользователей.

Как сделать сетевой запрос? Что необходимо учесть? Какие инструменты использовать?

• Permissions для интернета.

• Retrofit/Okhttp/Ktor.

• Сериализация данных.

• Обработка ошибок.

• Корутины Dispatcher.IO.

• Разделение по Clean-слоям.

• Безопасность и SSL-pinning.

• Авторизация: access и refresh токены.

Нужно спроектировать 2 экрана. Выбрать технологии. При этом счетчик в корзине должен увеличиваться сразу, а кнопка в корзину должна менять цвет + counter справа. А если запрос на бэк упадет нужно вернуть все в исходное состояние и наривать какую-нибудь ошибку. Важно упомянуть, что запрос на бэк на добавление в корзину нужно запускать не из Scope Вьюмодели экрана деталей, а из такого скоупа, который гарантирует, что операция не прервется, если пользователь закроет экран деталей раньше(например из Scope MainActivity).

Есть 2 экрана: список товаров и экран товара. В списке можно добавить товар в корзину. На экране товара можно убрать из корзины или увеличить счетчик.

• Взаимодействие через бэк.

• Поддержка работы на нескольких устройствах.

• Работа без интернета.

• Проверка подключения к сети.

• Какой проект или какой функциональностью горжусь?

• Как сделать этот экран? XML или Compose. Полный путь. Если бы я пришел на проект и дали такую задачу.

Сделать виджет отображающий промокод с сервера (Compose/View).

• Виджет автономный.

• Промокод достается по GET-запросу из сети.

• Набор классов разбитый на слои.