Использовались ли сокеты в проекте

Что проверяют

Работали ли вы с постоянным соединением и понимаете ли, что на мобильном устройстве оно требует особого обращения.

Как отвечать

Расскажите про задачу: чат, живые обновления статуса, котировки, совместное редактирование. И про выбор технологии, потому что «сокеты» это обычно WebSocket, а не сырой TCP:

• WebSocket для двустороннего обмена (в Android чаще через OkHttp или Ktor);
• push-уведомления через Firebase, когда сообщения редкие: держать соединение ради этого дороже, чем получить уведомление;
• периодический опрос там, где обновления не срочные, это самый дешёвый вариант в эксплуатации;
• gRPC-потоки и SSE как альтернативы для односторонней передачи.

Дальше самое ценное, специфика мобильного клиента:

• жизненный цикл: соединение поднимают, когда экран виден, и закрывают при уходе в фон, иначе система всё равно ограничит фоновую работу, а батарея сядет;
• переподключение: сеть на телефоне рвётся постоянно, поэтому нужны повторы с нарастающей задержкой и восстановление состояния после разрыва;
• потеря сообщений: после переподключения нужен запрос пропущенного по последнему известному идентификатору, иначе часть событий исчезнет незаметно;
• фон и уведомления: пока приложение свёрнуто, обновления доставляются push-уведомлениями, а не соединением;
• тестирование: обрыв связи, переключение сети, длительный фон.

Где спотыкаются

Держат соединение в фоне и удивляются расходу батареи и разрывам.

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

Считают доставку гарантированной и не восстанавливают пропущенные события после разрыва.