Zasobniki gotowości aplikacji

Android 9 (poziom API 28) i nowsze obsługują grupy aplikacji w stanie gotowości. Czuwanie aplikacji Za pomocą puli system może ustalać priorytety żądań zasobów aplikacji na podstawie tego, jak często i jak dawno aplikacje były używane. Na podstawie wzorców korzystania z aplikacji każda aplikacja jest umieszczana w jednym z 5 grup priorytetowych. System ogranicza zasoby urządzenia dostępne dla każdej aplikacji na podstawie tego, do której grupy należy aplikacja.

Zasoby priorytetowe

System dynamicznie przypisuje każdą aplikację do zasobnika priorytetów, przypisując aplikacje w razie potrzeby. System może korzystać z wstępnie załadowanej aplikacji, która używa uczenia maszynowego do określania, jak często dana aplikacja jest używana, i przypisywania aplikacji do odpowiednich grup.

Jeśli na urządzeniu nie ma aplikacji systemowej, system domyślnie sortuje aplikacje według tego, jak często są używane. Bardziej aktywne aplikacje są przypisywane do grup o wyższym priorytecie, dzięki czemu mają dostęp do większej ilości zasobów systemowych. Grupa określa, jak często zadania aplikacji są wykonywane i jak często aplikacja może uruchamiać alarmy. Te ograniczenia mają zastosowanie tylko wtedy, gdy urządzenie jest zasilane z baterii. Podczas ładowania urządzenia system nie nakłada tych ograniczeń.

Grupy priorytetów:

  • Aktywna: aplikacja jest używana lub była używana bardzo niedawno.
  • Zestaw roboczy: aplikacja jest regularnie używana.
  • Często: aplikacja jest często używana, ale nie codziennie.
  • Rzadko: aplikacja jest rzadko używana.
  • Ograniczona: aplikacja zużywa dużo zasobów systemowych lub może zachowywać się niepożądanie.

Oprócz tych grup priorytetowych istnieje specjalna grupa nigdy przeznaczona dla aplikacji, które są zainstalowane, ale nigdy nie były uruchamiane. System nakłada na te aplikacje poważne ograniczenia.

Poniższe opisy dotyczą przypadku nieprognostycznego. Gdy natomiast prognoza wykorzystuje do przewidywania zachowań systemy uczące się, zbiory są wybierane z wyprzedzeniem, aby przewidzieć kolejne działania użytkownika, a nie na podstawie jego ostatniego korzystania z aplikacji. Na przykład ostatnio używana aplikacja może trafić do puli rzadkich, ponieważ uczenie maszynowe przewiduje, że nie będzie używana przez kilka godzin.

Aktywne

Aplikacja jest w grupie aktywne, gdy jest używana, gdy była używana bardzo niedawno lub gdy wykonuje jedną z tych czynności:

  • Uruchamia aktywność.
  • Uruchomiona jest usługa działająca długo na pierwszym planie.
  • Użytkownik klika go w powiadomieniu.

Jeśli aplikacja znajduje się w aktywnej puli, system nie nakłada żadnych ograniczeń na zadania ani alarmy tej aplikacji.

Interakcje użytkownika przypisują aplikacje jako aktywne

W Androidzie 9 (poziom interfejsu API 28) i nowszych, gdy użytkownik w określony sposób wchodzi w interakcję z Twoją aplikacją, system tymczasowo umieszcza ją w grupie aktywnych aplikacji. Gdy użytkownik przestanie korzystać z aplikacji, system umieści ją w grupie na podstawie historii użytkowania.

Oto przykłady interakcji, które powodują takie działanie systemu:

  • Użytkownik klika powiadomienie wysłane przez Twoją aplikację.

  • Użytkownik wchodzi w interakcję z usługą na pierwszym planie w aplikacji przez kliknięcie przycisku multimedialnego.

  • Użytkownik łączy się z aplikacją podczas interakcji z Androidem Automotive OS, gdzie aplikacja korzysta z usługi na pierwszym planie lub z CONNECTION_TYPE_PROJECTION.

Zestaw roboczy

Aplikacja znajduje się w grupie zestawu roboczego, jeśli jest często uruchamiana, ale nie jest aktywna. Na przykład aplikacja do obsługi mediów społecznościowych, którą użytkownik uruchamia prawie codziennie, prawdopodobnie znajduje się w zestawie roboczym. Aplikacje są też przenoszone do zbioru zestawów roboczych, jeśli są używane pośrednio.

Jeśli aplikacja znajduje się w zbiorze roboczym, system nakłada na nią łagodne ograniczenia dotyczące możliwości wykonywania zadań i uruchamiania alarmów. Więcej informacji znajdziesz w artykule o ograniczeniach związanych z zarządzaniem energią.

Częste

Aplikacja znajduje się w grupie często, jeśli jest używana regularnie, ale niekoniecznie codziennie. Na przykład aplikacja do śledzenia treningów, której użytkownik używa na siłowni, może znajdować się w grupie często używanych aplikacji.

Jeśli aplikacja znajduje się w grupie częstotliwości, system nakłada na nią większe ograniczenia dotyczące możliwości wykonywania zadań i uruchamiania alarmów. Więcej informacji znajdziesz w artykule o ograniczeniach związanych z zarządzaniem energią.

Rzadkie

Aplikacja jest w grupie rzadko, jeśli nie jest często używana. Na przykład aplikacja hotelowa, której użytkownik używa tylko podczas pobytu w hotelu, może należeć do rzadkich.

Jeśli aplikacja znajduje się w grupie rzadkich aplikacji, system nakłada na nią ścisłe ograniczenia dotyczące możliwości wykonywania zadań i uruchamiania alarmów. System ogranicza też możliwość połączenia aplikacji z internetem. Więcej informacji znajdziesz w artykule o ograniczeniach związanych z zarządzaniem energią.

Z ograniczonym dostępem

Ten zasób, dodany w Androidzie 12 (poziom API 31), ma najniższy priorytet i największe ograniczenia spośród wszystkich zasobników. System bierze pod uwagę zachowanie aplikacji, np. częstotliwość interakcji z nią użytkownika, aby zdecydować, czy umieścić ją w grupie ograniczonej.

W Androidzie 13 (poziom API 33) lub nowszym, chyba że aplikacja kwalifikuje się do wyjątku, system umieszcza ją w grupie ograniczonej w tych sytuacjach:

  • Użytkownik nie wchodzi w interakcję z Twoją aplikacją przez określoną liczbę dni. W przypadku Androida 12 (poziom API 31) i 12L (poziom API 32) liczba dni wynosi 45. Android 13 zmniejsza liczbę dni do 8.

  • Aplikacja wywołuje nadmierną liczbę transmisji lub wiązań w ciągu 24 godzin.

Jeśli system umieści Twoją aplikację w grupie ograniczonej, będą obowiązywać te ograniczenia:

  • Możesz wykonywć zadania raz dziennie w ramach 10-minutowej sesji zbiorczej. Podczas tej sesji system grupował zadania Twojej aplikacji z zadaniami innych aplikacji.
    • Zadania z ograniczeniami nie są wykonywane automatycznie. Musi być co najmniej 1 inne zadanie uruchomione lub oczekujące w tym samym czasie, które może być dowolnym innym zadaniem.
  • Twoja aplikacja może wykonywać mniej przyspieszonych zadań niż w przypadku, gdy system umieszcza ją w mniej restrykcyjnej puli.
  • Aplikacja może wywołać 1 alarm dziennie. Alarm może być dokładny lub niedokładny.

Wyjątki z zasobnika z ograniczeniami

Te typy aplikacji nie są umieszczane w grupie ograniczonej i omijają regułę dotyczącą braku aktywności nawet na Androidzie 12 i nowszych wersjach:

Ocena puli priorytetów

Aby sprawdzić, do którego zasobnika przypisana jest aplikacja, wykonaj jedną z tych czynności:

  • Zadzwoń pod numer getAppStandbyBucket().

  • Wykonaj to polecenie w oknie terminala:

    adb shell am get-standby-bucket PACKAGE_NAME

System ogranicza działanie aplikacji, gdy zostanie ona umieszczona w grupie aplikacji w stanie gotowości, której wartość jest większa niż STANDBY_BUCKET_ACTIVE (10).

Sprawdzone metody

Jeśli Twoja aplikacja stosuje się do sprawdzonych metod dotyczących Doze i trybu gotowości aplikacji, późniejsze funkcje zarządzania zasilaniem nie powinny sprawić Ci trudności. Jednak niektóre zachowania aplikacji, które wcześniej działały dobrze, mogą powodować problemy.

  • Nie próbuj manipulować systemem, aby umieścić aplikację w określonej grupie. Metoda nadawania priorytetów przez system może się zmienić, a każdy producent urządzeń może zdecydować się na napisanie własnej aplikacji do grupowania z własnym algorytmem. Zamiast tego zadbaj o to, aby aplikacja działała prawidłowo niezależnie od tego, do której grupy należy.
  • Jeśli aplikacja nie ma aktywności w menu, może nigdy nie zostać przeniesiona do aktywnego zasobnika. Rozważ przeprojektowanie aplikacji, aby zawierała taką aktywność.
  • Jeśli użytkownicy nie mogą wchodzić w interakcję z powiadomieniami aplikacji, nie mogą też aktywować promocji aplikacji w aktywnej puli. W takim przypadku rozważ zmianę wyglądu niektórych powiadomień, które umożliwiają interakcję z użytkownikiem. Niektóre wytyczne znajdziesz we wzorcach projektowania powiadomień w interfejsie Material Design.

  • Jeśli aplikacja nie wyświetli powiadomienia po otrzymaniu wiadomości o wysokim priorytecie z Komunikacji w chmurze Firebase (FCM), użytkownik nie będzie mógł z nią wchodzić w interakcje i w ten sposób przenieść jej do aktywnego zasobnika. W zasadzie jedynym dozwolonym zastosowaniem wiadomości FCM o wysokim priorytecie jest wysłanie powiadomienia do użytkownika, więc taka sytuacja nie powinna mieć miejsca. W wersji 12L (poziom interfejsu API 32) i starszych, jeśli nieprawidłowo oznaczysz wiadomość FCM jako o wysokim priorytecie, gdy nie powoduje ona interakcji użytkownika, może to spowodować obniżenie priorytetu przyszłych wiadomości.

  • Jeśli aplikacje są podzielone na kilka pakietów, mogą one znajdować się w różnych grupach i mieć różne poziomy dostępu. Przetestuj te aplikacje z pakietami przypisanymi do różnych grup, aby upewnić się, że aplikacja działa prawidłowo.