Фоновые загрузки на мобильных устройствах, которые переживают плохую сеть

Почему загрузки в полевых условиях ломаются на практике

Полевой сотрудник редко стоит на одном месте с полным сигналом и временем на ожидание. Он снимает фото в подвале, у дороги, внутри склада или рядом с объектом, где связь то появляется, то пропадает. Приложение может показывать «загрузка», но сеть уже слишком слабая, и передача зависает.

С видео всё ещё сложнее. Фото может отправиться быстро, а короткий ролик на мобильном интернете способен грузиться минутами. Если сотрудник записывает несколько роликов подряд, очередь растёт ещё до того, как закончится отправка первого файла. В офисном Wi‑Fi это кажется нормальным. В поле всё разваливается.

Люди ещё и пользуются телефоном, пока идут загрузки. Блокируют экран, отвечают на звонок, открывают карты, чтобы сориентироваться, или переходят в мессенджер. На многих телефонах это меняет то, сколько времени приложению дают работать в фоне. Где-то процесс замедляется. Где-то ставится на паузу. Где-то останавливается, и человеку в руках не объясняют почему.

Ещё одна точка отказа — нехватка памяти. Если на телефоне мало свободной памяти, система может перезапустить приложение, пока файлы ещё отправляются. На старых устройствах это происходит чаще, но и на новых тоже случается, когда пользователь прыгает между камерой, картами и другими тяжёлыми приложениями. Если состояние загрузки хранится только в памяти, приложение забывает, что уже успело отправить, а что ещё осталось.

Человеческая цена выше технической. Когда прогресс исчезает, сотрудники не думают: «сломалась сессия передачи». Они думают, что приложение потеряло доказательства их работы. А это значит снова делать те же фото, возвращаться в то же место или просить клиента повторить то, что он уже сделал.

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

Что нужно пользователю, чтобы чувствовать себя спокойно

В фоновом режиме доверие начинается ещё до того, как загрузка закончится. Полевому сотруднику нужен один простой ответ: «Приложение сохранило мою работу?» Если экран блокируется или связь пропадает, приложение должно показать, что ответ — да.

Сначала показывайте локальное сохранение. В момент, когда человек записал видео или добавил фото, помечайте каждый файл как сохранённый на устройстве. Это важно, потому что снимает страх, что работу придётся делать дважды. Если загрузка зависла, пользователь знает: файл всё ещё здесь.

Очередь должна быть видимой и понятной. У каждого элемента нужен ясный статус: сохранён, ожидает, загружается, приостановлен, загружен или ошибка. Размытые подписи только нервируют. «Ожидание Wi‑Fi» или «Нет сигнала» намного лучше, чем крутилка без объяснения.

Контроль тоже помогает. Дайте человеку возможность поставить на паузу один файл или всю очередь. Это кажется мелочью, но хорошо совпадает с реальной работой. Например, кто-то может остановить видео на 300 МБ, чтобы сначала отправились три фото и подписанная форма.

Когда он нажимает «возобновить», приложение должно продолжить с сохранённого файла. Не просите снова искать фото, переснимать ролик или заново открывать форму. Если человек уже выполнил работу, приложение должно это уважать.

Каждому файлу нужен свой контекст. Заметки, ID задачи, метки времени, чек-листы и ответы формы должны оставаться прикреплёнными к этому файлу, даже если телефон ушёл в офлайн, приложение свернулось или загрузка продолжилась спустя часы. Фото без заметки часто бесполезно.

Простой пример показывает, почему это важно. Инспектор на объекте делает шесть фото, добавляет к каждому короткую заметку и потом спускается в подвал со слабой связью. Если приложение показывает «сохранено на этом телефоне» и держит каждую заметку рядом с нужным изображением, инспектор спокойно продолжает работу. Если приложение теряет заметки или снова просит прислать файлы, доверие быстро исчезает.

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

Как построить поток загрузки по шагам

Начинайте ещё до того, как первый байт уйдёт с телефона. Когда пользователь выбирает фото или записывает видео, приложение должно сразу сохранить файл локально вместе с метаданными. Это включает в себя, кто его создал, когда, где и к какой задаче или отчёту он относится. Если сеть пропадёт через секунду, работа всё равно останется.

У каждой загрузки должен быть свой стабильный ID. Не привязывайте его к состоянию экрана или временному объекту в памяти. Используйте один ID, который не меняется при перезапусках приложения, повторных попытках и фоновых загрузках на мобильных устройствах. Это одно решение предотвращает массу дубликатов, пропавших вложений и путаницы в статусах.

Простой поток выглядит так:

1. Сохраните файл и метаданные в локальное хранилище.
2. Создайте запись загрузки со стабильным ID и статусом.
3. Если файл большой, начните отправку маленькими частями.
4. Обновляйте прогресс только после подтверждения сервера для каждой части.
5. Позже продолжайте с последней подтверждённой части.

Чанкинг особенно важен для видео, длинных аудиозаметок и пачек фотографий высокого разрешения. Если сотрудник отправляет видео с осмотра на 400 МБ, а связь обрывается на 92 процентах, начинать заново с нуля — это ощущается как поломка. Разбейте файл на части, отправляйте их по одной и сохраняйте подтверждённый оффсет после каждого успешного чанка. Маленькие части делают повторные попытки дешевле и быстрее.

Храните прогресс в надёжном локальном хранилище, а не только в памяти. Если приложение закрыли, телефон перезагрузился или система выгрузила экран из памяти, запись о загрузке всё равно должна показывать последний хороший момент. При следующем запуске приложение сможет проверить сервер, сверить уже отправленные чанки и продолжить.

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

Один реалистичный тест: техник снимает фото, запускает загрузку видео, заходит в зону со слабым сигналом, переключается с Wi‑Fi на мобильную сеть и открывает другое приложение. Если ваш поток сохраняет работу до начала загрузки и возобновляет её с последнего подтверждённого чанка, пользователь почти не замечает сбоя. К этому и нужно стремиться.

Как обрабатывать закрытие приложения и ограничения фона

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

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

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

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

• путь к файлу или локальный ID ассета
• статус загрузки
• сколько байт уже отправлено
• сессию загрузки на сервере или временный ID файла
• последнюю ошибку, если она была

Когда приложение снова открывают, оно должно само просканировать очередь и возобновить незавершённые задачи. Пользователю не нужно помнить, что именно сломалось. Полевой техник может сделать доказательства в подвале со слабой связью, убрать телефон и открыть его снова через 40 минут в фургоне. Приложение должно продолжить с того места, где остановилось, а не начинать с нуля.

Иногда телефон не позволит продолжить загрузку, пока приложение не вернётся на передний план. Скажите об этом прямо. Короткое сообщение вроде «Загрузка приостановлена. Оставьте приложение открытым, чтобы закончить это видео» — простое и полезное. Молчание заставляет думать, что файл всё ещё отправляется, хотя это не так.

Не помечайте файл как завершённый, когда полоска прогресса доходит до 100%. Помечайте его как готовый только после того, как сервер подтвердит, что сохранил файл и прикрепил его к нужной записи. До этого держите элемент в статусе ожидания.

Этот последний шаг помогает избежать частой путаницы: приложение показывает успех, сотрудник уезжает с объекта, а офис позже находит пустой отчёт. Подтверждение сервера закрывает эту дыру.

Что делать, когда меняется сеть

Полевую работу почти никогда не делают на стабильной связи. Техник может начать загрузку видео на Wi‑Fi на объекте, дойти до машины, потерять сигнал на 30 секунд, а потом переключиться на мобильную сеть. Если приложение воспринимает каждую смену сети как новый старт, люди быстро теряют и время, и доверие.

Когда сигнал пропадает, приложение должно ставить загрузку на паузу предсказуемым образом. Не крутите индикатор так, будто ничего не случилось. Пометьте загрузку как приостановленную, сохраните уже отправленные байты и ждите, пока появится рабочее соединение. Это звучит просто, но реально экономит работу, когда человек уже пять минут снимал фото повреждений или длинный ролик осмотра.

Переключение между сетями требует аккуратности. Переход с Wi‑Fi на мобильную сеть или с одной слабой вышки на другую может сломать сессию загрузки. Самый безопасный подход — отправлять файлы чанками и подтверждать каждый чанк, прежде чем двигаться дальше. Тогда приложение сможет продолжить с последнего подтверждённого места, а не начинать весь файл заново.

Для больших файлов на мобильном интернете нужны более строгие правила. Большинство людей спокойно отправляют несколько фото через сотовую сеть. Видео на 900 МБ — это уже другое дело. Дайте командам выбрать правило по умолчанию, например: «фото — в любой сети, видео — только по Wi‑Fi» или «спрашивать перед использованием сотовой сети для файлов больше 100 МБ». Если приложение решает это без вопроса, пользователь заметит это по счёту за трафик.

На слабой связи нужны более редкие попытки, а не постоянные удары в стену. Если приложение пытается повторить отправку каждые несколько секунд при плохом сигнале, оно тратит батарею и держит радиомодуль занятым, не приближаясь к результату. Лучше использовать короткую задержку с увеличением интервала: 15 секунд, потом 30, потом 1 минута, потом 2 минуты. Сбросьте этот таймер, когда сеть снова станет стабильной.

Статусы должны оставаться понятными всё время. Одна загрузка не должна одновременно где-то показываться как «загружается», где-то как «повторная попытка», а где-то как «ошибка». Выберите одну модель статусов и используйте её везде.

Обычно хорошо работает такой набор:

• Загружается
• Приостановлено — нет сигнала
• Приостановлено — ждём Wi‑Fi
• Повтор через 2 мин
• Ошибка — нажмите, чтобы повторить

Такая ясность важнее красивых анимаций. В фоновых загрузках на мобильных устройствах пользователям в основном нужен один ответ: «Мои данные в безопасности и потом всё завершится?»

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

Один день в поле с фото и видео

Инспектор проводит утро на трёх объектах после шторма. К обеду у неё уже 20 фото и два коротких видео для одного отчёта. Она работает быстро, часто одной рукой, так что приложение не может просить её останавливаться и следить за загрузками.

После каждого фото или видео приложение сначала сохраняет файл в локальное хранилище, а уже потом переходит к следующей задаче. Оно также сразу создаёт запись загрузки. Этот маленький шаг важнее, чем думают многие команды. Если приложение закроется, телефон заблокируется или она переключится на карты, её доказательства всё равно останутся на устройстве и в очереди.

На экране должны быть простые статусы, которым можно верить:

• Сохранено на устройстве
• Загружается 6 из 22
• Приостановлено — нет сигнала
• Ожидает Wi‑Fi
• Загружено

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

Когда поезд подъезжает к депо, телефон подключается к Wi‑Fi. Очередь просыпается и проверяет каждый элемент. Файлы, которые завершились раньше, остаются завершёнными. Видео, которое дошло только наполовину, продолжает загрузку с последнего подтверждённого чанка, а не с нуля. Оставшиеся фото уходят по порядку, без прыжков и без вторых копий.

Вот где фоновые загрузки на мобильных устройствах либо ощущаются спокойно, либо ломаются. Пользователь никогда не должен думать: «Я потерял это видео?» Он должен видеть, что приложение помнит каждый файл и знает, что делать дальше.

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

Ошибки, которые приводят к потере работы пользователя

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

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

Другая ошибка — привязка состояния загрузки к экрану, а не к самой задаче. Пользователь открывает отчёт, нажимает загрузку, а потом блокирует телефон или переключается между приложениями. Если полоска прогресса живёт только на этом экране, задача может исчезнуть вместе с ним. У загрузки должна быть своя запись в локальном хранилище со статусом, отправленными байтами, числом попыток и расположением файла. Экран должен читать эту запись, а не владеть ею.

Слишком раннее удаление локального файла тоже приносит вред, который пользователь не сможет исправить. Некоторые команды удаляют файл сразу после старта запроса или после первого успешного ответа с одного из эндпоинтов. Это рискованно. Храните файл, пока сервер не подтвердит, что финальный объект сохранён и прикреплён к правильному отчёту. Если полевое приложение загружает большие видео-доказательства, одно неудачное переподключение может заставить пользователя снимать всё заново.

Повторные попытки создают ещё один хаос, когда приложение бесконечно пытается отправить файл и ничего не говорит. Люди думают, что загрузка завершилась, уходят с объекта и только потом узнают, что приложение всё это время падало в фоне. Показывайте понятный статус, например: приостановлено, ждём сеть или требуется внимание. Когда важна смена сети, прямо говорите, что будет делать приложение на Wi‑Fi, мобильной сети или без сигнала.

Самая хрупкая схема — когда отправка формы и загрузка медиа объединены в один шаг. Тогда одно неудачное видео блокирует весь отчёт. Разделяйте их. Сначала сохраняйте данные формы, медиа отправляйте как отдельные задачи и показывайте в отчёте, какие файлы ещё требуют внимания. Это также делает паузу и возобновление загрузок намного безопаснее.

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

Быстрые проверки перед выпуском

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

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

• Включите авиарежим во время большой загрузки. Приложение должно аккуратно остановиться, сохранить уже отправленные байты, если это поддерживает ваш backend, и показать понятный статус приостановки или ожидания вместо немедленной «ошибки».
• Заблокируйте телефон, пока очередь активна. Через несколько минут разблокируйте его и проверьте, продолжилась ли загрузка в фоне или возобновилась сама без создания второй копии.
• Закройте приложение после того, как часть файла уже отправилась, а потом откройте его снова. Очередь должна восстановиться из сохранённого состояния, не потерять прогресс и не оставить пользователя перед зависшей крутилкой.
• Переключитесь с мобильной сети на Wi‑Fi посреди одного файла. Проверьте, нет ли дублирующихся чанков, повреждённого медиа или перезапуска передачи с нуля, когда он не нужен.
• Отправьте два файла с одинаковым именем, например IMG_0001.jpg из разных дней. Сервер должен считать их разными файлами, если вы явно не связываете их по содержимому или upload ID.

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

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

Следующие шаги для более безопасного запуска

Безопасный запуск начинается с небольшого письменного плана. До релиза определите каждое состояние, в которое может попасть загрузка, и что приложение делает дальше. Если пользователь не понимает, в безопасности ли файл, он считает, что он потерян.

• в очереди
• загружается
• приостановлено
• готово
• ошибка

Эти ярлыки кажутся простыми, но для каждого нужны свои правила. «В очереди» должно означать, что файл уже сохранён локально и ждёт своей очереди. «Приостановлено» должно иметь причину: пользователь нажал паузу, нет сети или телефон ограничил фоновую работу.

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

Тестируйте на реальных файлах из поля. Несколько маленьких демонстрационных фото расскажут мало. Используйте те же размеры фото и видео, которые ваша команда действительно отправляет, а потом проверяйте паузу и возобновление загрузок, перемещаясь между Wi‑Fi, мобильной сетью и зонами слабого сигнала.

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

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

Если вашей команде нужна помощь с этим разбором, Oleg Sotnikov может посмотреть на мобильный поток, серверную обработку и инфраструктурные решения в рамках Fractional CTO support. Такой аудит часто заранее находит дорогие ошибки, особенно в приложениях с медиа, где одно неверное правило повторной попытки может стоить часов полевой работы.

Выпускайте только тогда, когда поведение ощущается скучным, предсказуемым и трудно ломаемым. Именно этому доверяют пользователи.