Omówienie zadań w tle

Aplikacje często muszą wykonywać więcej niż 1 czynność naraz. Interfejsy API Androida pozwalają to robić na wiele różnych sposobów. Wybór właściwej opcji jest bardzo ważny. Jedna opcja może być odpowiednia w jednej sytuacji, ale bardzo niewłaściwa w innej. Wybór niewłaściwych interfejsów API może negatywnie wpływać na wydajność aplikacji lub wydajność zasobów, co może się rozładowywać i pogarszać wydajność urządzenia użytkownika. W niektórych przypadkach niewłaściwe podejście może spowodować, że aplikacja nie pojawi się w Sklepie Play.

W tym dokumencie opisujemy różne dostępne opcje i pomagamy wybrać opcję odpowiednią do danej sytuacji.

Terminologia

Niektóre ważne terminy związane z zadaniami w tle mogą być używane na wiele sprzecznych sposobów. Z tego powodu należy zdefiniować nasze warunki.

Jeśli aplikacja działa w tle, system nakłada na nią szereg ograniczeń. Na przykład w większości przypadków aplikacja w tle nie może uruchamiać usług na pierwszym planie.

W tym dokumencie terminem „zadanie” będziemy używać w odniesieniu do operacji wykonywanych przez aplikację poza głównym przepływem pracy. Aby zapewnić zgodność ze zrozumieniem, podzieliliśmy je na 3 główne kategorie zadań: praca asynchroniczna, interfejsy API do planowania zadań i usługi na pierwszym planie.

Wybierz odpowiednią opcję

W większości przypadków możesz określić odpowiednie interfejsy API do swojego zadania, określając kategorię (praca asynchroniczna, interfejsy API do planowania zadań lub usługi na pierwszym planie), do której należy to zadanie.

Jeśli nadal masz wątpliwości, możesz użyć podanych przez nas schematów blokowych, które dodają więcej niuansów do decyzji. Każdą z tych opcji opisujemy szczegółowo w dalszej części dokumentu.

W przypadku zadań w tle należy wziąć pod uwagę 2 główne scenariusze:

Te 2 scenariusze mają własne drzewka decyzyjne.

Praca asynchroniczna

W wielu przypadkach aplikacja musi po prostu wykonywać operacje jednocześnie, gdy działa na pierwszym planie. Na przykład aplikacja może wymagać czasochłonnego obliczania. Gdyby obliczenia zostały wykonane w wątku interfejsu, użytkownik nie mógł korzystać z aplikacji do czasu zakończenia obliczeń, ponieważ mogłoby to spowodować błąd ANR. W takim przypadku aplikacja powinna używać opcji pracy asynchronicznej.

Typowe opcje asynchronicznej pracy to m.in. współprogramy Kotlin i wątki Java. Więcej informacji znajdziesz w dokumentacji pracy asynchronicznej. Warto zauważyć, że w przeciwieństwie do interfejsów API zadań w tle działanie asynchronicznej pracy nie zostanie ukończone, jeśli aplikacja przestanie być na prawidłowym etapze cyklu życia (np. jeśli opuści aplikację na pierwszym planie).

Interfejsy API do planowania zadań

Interfejsy API do planowania zadań są bardziej elastyczną opcją, gdy musisz wykonywać zadania, które muszą być kontynuowane nawet wtedy, gdy użytkownik wyjdzie z aplikacji. W większości przypadków najlepszym rozwiązaniem do uruchamiania zadań w tle jest użycie interfejsu WorkManager, ale w niektórych przypadkach może być wskazane użycie interfejsu API platformy JobScheduler.

WorkManager to zaawansowana biblioteka, która pozwala konfigurować proste i złożone zadania. Możesz użyć WorkManagera, by zaplanować uruchamianie zadań w określonych godzinach lub określić warunki ich uruchomienia. Możesz nawet skonfigurować łańcuchy zadań, aby każde z nich uruchamiało się po kolei i przekazywało jego wyniki do następnego. Aby poznać wszystkie dostępne opcje, przeczytaj listę funkcji WorkManagera.

Oto niektóre z najczęstszych scenariuszy wykonywania zadań w tle:

  • Okresowe pobieranie danych z serwera
  • Pobieram dane z czujnika (np. dane z licznika kroków)
  • Pobieram okresowe dane o lokalizacji (na Androidzie 10 lub nowszym musisz mieć uprawnienie ACCESS_BACKGROUND_LOCATION)
  • Przesyłanie treści za pomocą reguły dotyczącej treści, np. zdjęć utworzonych przez aparat

Usługi działające na pierwszym planie

Usługi działające na pierwszym planie zapewniają zaawansowane rozwiązania w zakresie natychmiastowego uruchamiania zadań, które nie powinny być przerywane. Usługi działające na pierwszym planie mogą jednak znacznie obciążać urządzenie i czasami mogą zagrażać prywatności i bezpieczeństwu. Z tego powodu system nakłada wiele ograniczeń na to, jak i kiedy aplikacje mogą korzystać z usług działających na pierwszym planie. Na przykład usługa na pierwszym planie musi być widoczna dla użytkownika, a w większości przypadków aplikacje nie mogą uruchamiać takich usług, gdy działają w tle. Więcej informacji znajdziesz w dokumentacji usług na pierwszym planie.

Istnieją 2 metody tworzenia usługi na pierwszym planie. Możesz zadeklarować własny adres Service i określić, że usługa działa na pierwszym planie, wywołując metodę Service.startForeground(). Możesz też użyć WorkManagera do utworzenia usługi na pierwszym planie, jak omówiliśmy w sekcji Obsługa długotrwałych instancji roboczych. Pamiętaj jednak, że usługa na pierwszym planie utworzona przez WorkManager musi być zgodna z tymi samymi ograniczeniami co każda inna usługa na pierwszym planie. WorkManager udostępnia tylko kilka wygodnych interfejsów API, które ułatwiają tworzenie usług na pierwszym planie.

Alternatywne interfejsy API

System udostępnia alternatywne interfejsy API, które zostały zaprojektowane tak, aby działały lepiej w bardziej konkretnych przypadkach. Jeśli istnieje alternatywny interfejs API do wykorzystania w Twoim przypadku, zalecamy używanie go zamiast usługi na pierwszym planie, ponieważ powinien on poprawić wydajność aplikacji. Dokumentacja typów usług na pierwszym planie zawiera informacje o tym, czy istnieje dobry alternatywny interfejs API, którego można użyć zamiast konkretnego typu usługi na pierwszym planie.

Oto kilka najczęstszych scenariuszy używania alternatywnych interfejsów API:

Zadania zainicjowane przez użytkownika

Schemat blokowy przedstawiający wybór odpowiedniego interfejsu API. Ten wykres zawiera podsumowanie materiału w sekcji „Zadania zainicjowane przez użytkownika”.
Rysunek 1. Jak wybrać odpowiedni interfejs API do uruchamiania inicjowanego przez użytkownika zadania w tle.

Jeśli aplikacja musi wykonywać zadania w tle, a operacja jest inicjowana przez użytkownika, gdy jest ona widoczna, odpowiedz na te pytania, aby znaleźć odpowiednie podejście.

Czy zadanie musi być kontynuowane, gdy aplikacja działa w tle?

Jeśli zadanie nie musi być kontynuowane, gdy aplikacja działa w tle, użyj pracy asynchronicznej. Istnieje wiele sposobów wykonywania pracy asynchronicznego. Pamiętaj, że te opcje przestaną działać, gdy aplikacja zacznie działać w tle. Zatrzymują się też po wyłączeniu aplikacji. Na przykład aplikacja mediów społecznościowych może chcieć odświeżyć swój kanał treści, ale nie będzie musiała kończyć operacji, jeśli użytkownik opuści ekran.

Czy odroczenie lub przerwanie zadania może negatywnie wpłynąć na wrażenia użytkownika?

Ważne jest, by wziąć pod uwagę, czy przełożenie zadania lub jego anulowanie nie wpłynie na wrażenia użytkownika. Jeśli na przykład aplikacja wymaga aktualizacji zasobów, użytkownik może nie zauważyć, czy operacja odbywa się od razu, czy w środku nocy, gdy urządzenie się ładuje. W takich przypadkach użyj opcji pracy w tle.

Czy jest to krótkie, kluczowe zadanie?

Jeśli zadania nie można opóźnić i zakończy się szybko, możesz użyć usługi na pierwszym planie typu shortService. Tworzenie takich usług jest łatwiejsze niż inne usługi na pierwszym planie i nie wymagają tylu uprawnień. Krótkie usługi muszą jednak zostać ukończone w ciągu 3 minut.

Czy istnieje alternatywny interfejs API przeznaczony tylko do tego celu?

Jeśli zadanie nie jest widoczne dla użytkownika, dobrym rozwiązaniem może być skorzystanie z usługi na pierwszym planie. Te usługi działają w trybie ciągłym po uruchomieniu, więc jeśli przerwanie wykonywania zadania mogłoby zmniejszyć wygodę użytkowników, jest to dobry wybór. Na przykład aplikacja śledząca trening może korzystać z czujników lokalizacji, aby umożliwić użytkownikom rejestrowanie trasy joggingu na mapie. Nie należy robić tego z opcją pracy w tle, ponieważ gdyby zadanie zostało wstrzymane, śledzenie natychmiast zatrzyma się. W takiej sytuacji najlepszym rozwiązaniem jest usługa na pierwszym planie.

Usługi działające na pierwszym planie mogą jednak potencjalnie wykorzystywać duże zasoby urządzeń, dlatego system nakłada wiele ograniczeń na temat tego, kiedy i jak można z nich korzystać. W wielu przypadkach zamiast usługi na pierwszym planie możesz użyć alternatywnego interfejsu API, który wykonają to zadanie za Ciebie. Jeśli na przykład aplikacja musi podjąć działanie, gdy użytkownik dotrze w określone miejsce, najlepszym rozwiązaniem będzie skorzystanie z interfejsu geoofence API zamiast śledzenia lokalizacji użytkownika za pomocą usługi na pierwszym planie.

Zadania w odpowiedzi na zdarzenie

Schemat blokowy przedstawiający wybór odpowiedniego interfejsu API. Ten wykres zawiera podsumowanie materiału w sekcji „Zadania w odpowiedzi na zdarzenie”.
Rysunek 2. Jak wybrać odpowiedni interfejs API do uruchamiania zadania w tle wywoływanego przez zdarzenia.

Czasami w odpowiedzi na aktywator aplikacja musi wykonać działanie w tle, na przykład:

Może to być aktywator zewnętrzny (np. wiadomość FCM) lub reakcja na alarm ustawiony przez samą aplikację. Na przykład gra może otrzymać komunikat FCM z prośbą o zaktualizowanie niektórych zasobów.

Jeśli masz pewność, że zadanie zakończy się w ciągu kilku sekund, użyj pracy asynchronicznej. System da aplikacji kilka sekund na wykonanie takich zadań, nawet jeśli działała w tle.

Jeśli zadanie zajmie więcej niż kilka sekund, dobrym rozwiązaniem może być uruchomienie do niego usługi na pierwszym planie. W rzeczywistości nawet wtedy, gdy aplikacja działa obecnie w tle, może uruchamiać usługę na pierwszym planie, jeśli to zadanie zostało aktywowane przez użytkownika i należy do jednego z zatwierdzonych wykluczeń z ograniczeń uruchamiania w tle. Jeśli na przykład aplikacja otrzyma wiadomość o wysokim priorytecie w FCM, może uruchomić usługę na pierwszym planie, nawet jeśli działa w tle.

Jeśli zadanie zajmie więcej niż kilka sekund, użyj interfejsów API do planowania zadań.