Porównanie lokalnej usługi klasy bazowej w toku z AsyncTask:
✱ (Ta odpowiedź nie dotyczy usług eksportowanych ani żadnej usługi działającej w procesie innym niż proces klienta, ponieważ oczekiwane przypadki użycia różnią się znacznie od przypadków użycia AsyncTask. Ponadto, w interesie zwięzłości, charakter pewnych wyspecjalizowanych Servicepodklasy (np IntentService, JobService) będą ignorowane tutaj).
Żywotność procesu
A Servicereprezentuje dla systemu operacyjnego „chęć aplikacji do wykonywania dłuższej operacji bez interakcji z użytkownikiem” [ ref ].
Kiedy masz Serviceuruchomiony, Android rozumie, że nie chcesz, aby Twój proces został zabity. Dotyczy to również sytuacji, gdy masz Activityekran, a jest to szczególnie prawdziwe, gdy używasz usługi pierwszego planu . (Kiedy wszystkie składniki aplikacji znikną, system Android myśli: „Och, teraz jest dobry czas, aby zabić tę aplikację, abym mógł zwolnić zasoby”).
Ponadto, w zależności od ostatniej zwróconej wartości z Service.onCreate(), Android może próbować „ożywić” aplikacje / usługi, które zostały zabite z powodu presji zasobów [ ref ].
AsyncTasksnie rób tego. Nie ma znaczenia, ile wątków w tle masz uruchomionych ani jak ciężko pracują: Android nie utrzyma twojej aplikacji przy życiu tylko dlatego, że aplikacja korzysta z procesora. Musi mieć jakiś sposób, aby wiedzieć, że Twoja aplikacja nadal ma pracę; dlatego Servicessą zarejestrowane w systemie operacyjnym, a AsyncTasksnie.
Wielowątkowość
AsyncTasks polegają na utworzeniu wątku w tle, na którym można wykonać pracę, a następnie zaprezentowaniu wyniku tej pracy wątkowi interfejsu użytkownika w sposób bezpieczny dla wątków.
Każde nowe AsyncTaskwykonanie generalnie skutkuje większą współbieżnością (większą liczbą wątków), z zastrzeżeniem ograniczeń AsyncTasks'spuli wątków [ ref ].
ServiceZ drugiej strony metody są zawsze wywoływane w wątku interfejsu użytkownika [ ref ]. Odnosi się to do onCreate(), onStartCommand(), onDestroy(), onServiceConnected(), itd. Tak więc, w pewnym sensie, Servicesnie zrobić „run” w tle. Po uruchomieniu ( onCreate()) po prostu „siedzą” tam - aż nadejdzie czas na wyczyszczenie, wykonanie onStartCommand()itp.
Innymi słowy, dodanie kolejnych Servicesnie powoduje większej współbieżności. Metody serwisowe nie są dobrym miejscem do wykonywania dużej ilości pracy, ponieważ działają w wątku interfejsu użytkownika .
Oczywiście możesz je rozszerzać Service, dodawać własne metody i wywoływać je z dowolnego wątku. Ale jeśli to zrobisz, odpowiedzialność za bezpieczeństwo nici spoczywa na tobie - a nie na strukturze.
Jeśli chcesz dodać wątek w tle (lub innego rodzaju pracownika) do swojego Service, możesz to zrobić. Możesz na przykład rozpocząć wątek / AsyncTaskin w tle Service.onCreate(). Ale nie wszystkie przypadki użycia tego wymagają. Na przykład:
- Możesz chcieć nadal
Servicedziałać, aby nadal otrzymywać aktualizacje lokalizacji w „tle” (co oznacza, że niekoniecznie musisz Activitieswyświetlać na ekranie).
- Możesz też chcieć utrzymać swoją aplikację przy życiu tylko po to, aby móc
BroadcastReceiverprzez dłuższy czas rejestrować „niejawną” (po API 26 nie zawsze możesz to zrobić za pomocą manifestu, więc zamiast tego musisz zarejestrować się w czasie wykonywania [ ref ]).
Żaden z tych przypadków użycia nie wymaga dużej aktywności procesora; wymagają tylko, aby aplikacja nie została zabita .
Jako pracownicy
Servicesnie są zorientowane na zadania. Nie są skonfigurowane do „wykonywania zadania” i „dostarczania wyniku”, jak AsyncTaskssą. Servicesnie rozwiązują żadnych problemów związanych z bezpieczeństwem wątków (niezależnie od faktu, że wszystkie metody są wykonywane w jednym wątku). AsyncTasksz drugiej strony zajmij się tą złożonością za siebie.
Zauważ, że AsyncTaskjest to przestarzałe . Ale to nie oznacza, że należy wymienić AsyncTasksz Services! (Jeśli dowiedziałeś się czegoś z tej odpowiedzi, to powinno być jasne).
TL; DR
Servicessą głównie po to, by „istnieć”. Działają jak poza ekranem Activity, dając powód, dla którego aplikacja pozostaje żywa, podczas gdy inne komponenty zajmują się „pracą”. AsyncTaskswykonują „pracę”, ale same w sobie nie utrzymają procesu przy życiu.