Śledzenie lokalizacji na żywo, które przeżyje telefony i skaluje się na tysiące

Geolokalizacja w czasie rzeczywistym, która działa na każdym telefonie — i nie roztapia twojej serwerowni.

Stack do śledzenia lokalizacji, który radzi sobie zarówno z killowaniem przez Androida w tle, jak i z wysoką współbieżnością aktualizacji na żywo — zbudowany na Go i kanale realtime zaprojektowanym dokładnie pod ten problem.

Porozmawiajmy o tym Zobacz: Dedykowane rozwiązania

Sygnały, że to Twój problem

Rozpoznasz się w co najmniej jednym z poniższych

Użytkownicy narzekają, że „aplikacja przestała śledzić" po 20–30 minutach — głośniej na Xiaomi, Huawei, Oppo lub niektórych Samsungach niż na Pixelu.
Kurierzy, kierowcy lub pracownicy terenowi znikają z mapy live w środku sesji, bez błędu w logach.
Połączenia WebSocket spadają pod obciążeniem, a burze reconnectów tylko pogarszają sprawę.
Aktualizacje lokalizacji opóźniają się o 10–30 sekund, gdy wielu użytkowników jest aktywnych w jednym obszarze.
Polling co kilka sekund tłucze w twoją bazę danych i drenuje baterię telefonu.
Odtworzenie buga w biurze jest niemożliwe — dzieje się tylko „w terenie".

Dlaczego tak się dzieje

Główna przyczyna, prostym językiem

Zderzają się dwa problemy. Na urządzeniu agresywne, specyficzne dla producenta oszczędzacze baterii zamykają serwisy działające w tle bez powiadomienia aplikacji ani użytkownika — standardowa obsługa lifecycle Androida nie wystarczy. Na backendzie, design oparty na pollingu HTTP po prostu nie skaluje się na wielu jednocześnie aktywnych użytkowników. Lokalizacja na żywo wymaga zarówno strategii po stronie telefonu, która przetrwa, jak i architektury serwerowej zbudowanej pod wysoką współbieżność trwałych połączeń.

Nasze podejście

Jak realnie to rozwiązujemy

1
Audytujemy użycie foreground service, WorkManager i AlarmManager pod kątem aktualnych zasad Doze i App Standby.
2
Wdrażamy foreground service ze sticky notification dla naprawdę długiego trackingu.
3
Prowadzimy użytkowników przez specyficzne dla producenta ustawienia autostartu i ochrony baterii za pierwszym razem, gdy są potrzebne.
4
Przechodzimy z pollingu HTTP na trwały kanał realtime (WebSocket / streaming gRPC).
5
Budujemy backend realtime w Go pod niską latencję i wysoką współbieżność fan-out.
6
Mądrze throttlujemy klienta — wysyłamy tylko sensowne delty pozycji, nie każdy tick GPS.
7
Dodajemy reconnect-with-state oraz heartbeat + fallback z remote-restart, żeby zerwane połączenie lub zabita aplikacja wracały do życia w ciągu sekund.
8
Budujemy macierz prawdziwych urządzeń (Xiaomi, Huawei, Samsung, OnePlus, Oppo) do pipeline'a CI.

Czego możesz się spodziewać

Efekty, które widzą nasi klienci

Recenzje typu „aplikacja przestaje działać" spadły niemal do zera w ciągu dwóch cykli wydawniczych.
Mediana długości sesji na problematycznych urządzeniach wzrosła z ~25 min do pełnej długości przejazdu/zmiany.
Tysiące użytkowników śledzonych live, w jednym feedzie, bez skoków latencji.
Zmniejszony drenaż baterii w porównaniu z agresywnym pollingiem.
Koszt backendu pozostaje sensowny w miarę wzrostu bazy użytkowników.

Case study

MOTO SOS — motocykliści na żywo na mapie, end to end

Aplikacja mobilna dla motocyklistów, gdzie użytkownicy widzą siebie nawzajem live i mogą wezwać pomoc w sytuacjach awaryjnych. Użytkownicy zgłaszali, że znajomi znikają z mapy live po 20–30 minutach — przyczyną były konkretne marki telefonów po cichu wyłączające aplikację, w połączeniu z backendem, który męczył się, gdy wielu motocyklistów było aktywnych jednocześnie. Naprawiliśmy obie rzeczy: aplikacja teraz pozostaje aktywna przez cały przejazd na każdej rodzinie telefonów, a backend realtime (Golang) skaluje się do śledzenia live przy wysokiej współbieżności. Oceny w storze wróciły do normy w ciągu dwóch cykli aktualizacji.

Zobacz więcej naszych realizacji →

Powiązane rozwiązania