Czy rezygnacja z aplikacji jest mile widziana?

Chciałbym tylko dodać korektę dla przyszłych czytelników tego wątku. Ten konkretny niuans umknął mojemu zrozumieniu przez długi czas, więc chcę się upewnić, że nikt z Was nie popełni tych samych błędów: {]}

System.exit() nie zabija aplikacji, Jeśli masz więcej niż jedną aktywność na stosie. dzieje się tak, że Proces jest zabijany i natychmiast uruchamiany ponownie z jedną mniejszą aktywnością na stosie. Dzieje się tak również, gdy Twoja aplikacja zostanie zabita przez Wymuś Zamknij okno dialogowe, lub nawet gdy próbujesz zabić proces z DDMS. Jest to fakt, który jest całkowicie nieudokumentowany, o ile wiem.

Krótka odpowiedź brzmi: jeśli chcesz wyjść z aplikacji, musisz śledzić wszystkie działania w stosie i finish() Wszystkie, gdy użytkownik chce wyjść (i nie, nie ma sposobu na iterację przez stos aktywności, więc musisz zarządzać tym wszystkim samodzielnie). Nawet to nie zabija procesu lub jakichkolwiek zwisających możesz mieć referencje. To po prostu kończy działania. Poza tym nie jestem pewien, czy Process.killProcess(Process.myPid()) działa lepiej; nie testowałem go.

Jeśli, z drugiej strony, jest w porządku, aby działania pozostały w stosie, istnieje inna metoda, która sprawia, że rzeczy są super łatwe dla Ciebie: Activity.moveTaskToBack(true) po prostu tło procesu i pokazać ekran główny.

1. Po pierwsze, dzieje się tak tylko wtedy, gdy aplikacja jest na pierwszym planie. Jeśli jest w tle, proces zakończy się dobrze. Jeśli jednak znajduje się na pierwszym planie, system operacyjny zakłada, że użytkownik chce robić to, co robił. (Jeśli próbujesz zabić proces z DDMS, powinieneś najpierw nacisnąć przycisk home, a następnie go zabić) {]}
2. zakłada również, że każde działanie jest niezależne od wszystkich innych działań. Często jest to prawdą, na przykład w przypadku, gdy Twoja aplikacja uruchamia aktywność w przeglądarce, która jest całkowicie oddzielna i nie została napisana przez Ciebie. Aktywność przeglądarki może lub nie może być utworzona w tym samym zadaniu, w zależności od jej oczywistych atrybutów.
3. zakłada, że każda z twoich działań jest całkowicie samodzielna i może zostać zabita/przywrócona w mgnieniu oka. (Raczej nie lubię tego konkretnego założenia, ponieważ moja aplikacja ma wiele działań, które opierają się na dużej ilości danych buforowanych, zbyt dużych, aby być / align= "left"/) Dla większości dobrze napisanych aplikacji na Androida powinno to być prawdą, ponieważ nigdy nie wiadomo, kiedy Twoja aplikacja zostanie zabita w tle.
[24]}ostatnim czynnikiem jest nie tyle założenie, ale raczej ograniczenie systemu operacyjnego: [31]}zabicie aplikacji jest tym samym, co awaria aplikacji, a także tym samym, co zabicie aplikacji przez Androida, aby odzyskać pamięć. to kulminacja naszego zamachu stanu: skoro Android nie wie, czy aplikacja została zamknięta, zawieszona lub zabita w tle, zakłada, że użytkownik chce wrócić tam, gdzie skończył, a więc menedżer ActivityManager uruchamia ponownie proces.

Kiedy się nad tym zastanowić, jest to odpowiednie dla platformy. Po pierwsze, to jest dokładnie to, co dzieje się, gdy proces jest zabity w tle i użytkownik wraca do niego, więc musi być ponownie uruchomiony tam, gdzie został przerwany. Po drugie, tak się dzieje, gdy aplikacja zawiesza się i prezentuje przerażającą siłę blisko dialog.

Powiedz, że chcę, aby moi użytkownicy mogli zrobić zdjęcie i przesłać je. Uruchamiam aktywność kamery z mojej aktywności i proszę ją o zwrócenie obrazu. Kamera jest popychana na szczyt mojego obecnego zadania (zamiast być tworzona w swoim własnym zadaniu). Jeśli aparat ma błąd i ulega awarii, czy powinno to spowodować awarię całej aplikacji? Z punktu widzenia użytkownika, tylko Kamera zawiodła i powinny one zostać przywrócone do poprzedniej aktywności. Więc po prostu uruchamia proces ponownie z tymi samymi czynnościami w stosie, bez kamery. Ponieważ Twoje działania powinny być zaprojektowane tak, aby można je było zabić i przywrócić w mgnieniu oka, nie powinno to być problemem. Niestety, nie wszystkie aplikacje mogą być tak zaprojektowane, więc to jest problemem dla wielu z nas, bez względu na to, co mówi Romain Guy lub ktokolwiek inny. Musimy więc zastosować obejścia.

Nie próbuj zabić procesu. Either call finish() na wszystkich działaniach lub wywołaniu moveTaskToBack(true).
• Jeśli twój proces ulegnie awarii lub zostanie zabity, i jeśli, tak jak ja, potrzebujesz danych, które były w pamięci, które zostały utracone, będziesz musiał wrócić do aktywności roota. Aby to zrobić, należy wywołać startActivity() z intencją zawierającą flagę Intent.FLAG_ACTIVITY_CLEAR_TOP.
• Jeśli chcesz zabić swoją aplikację z perspektywy Eclipse DDMS, lepiej, żeby nie była na pierwszym planie, albo sama się zrestartuje. Należy najpierw nacisnąć przycisk Home, a następnie zabić proces.

Wszystkie moje aplikacje mają przyciski quit... i dość często dostaję pozytywne komentarze od użytkowników z tego powodu. Nie obchodzi mnie, czy platforma została zaprojektowana w sposób, który aplikacje nie powinny ich potrzebować. Mówienie "nie kładź ich tam" jest trochę śmieszne. Jeśli użytkownik chce zamknąć... Zapewniam im dostęp do tego. Nie sądzę, że zmniejsza to, jak działa Android w ogóle i wydaje się dobrą praktyką. Rozumiem cykl życia... a moje spostrzeżenie było takie, że Android nie radzi sobie z tym dobrze.... i to jest podstawowy fakt.

Przestań myśleć o swojej aplikacji jako o aplikacji monolitycznej. Jest to zestaw ekranów interfejsu użytkownika, które użytkownik może wchodzić w interakcję z "aplikacją" i "funkcjami" udostępnianymi za pośrednictwem Usług Android.

Niewiedza co "robi" twoja tajemnicza aplikacja nie jest tak naprawdę ważna. Załóżmy, że tuneluje się w jakimś super bezpiecznym intranecie korporacyjnym, wykonując pewien monitoring lub interakcję i pozostaje zalogowany, dopóki użytkownik "nie zamknie aplikacji". Ponieważ twój dział IT to poleca, użytkownicy muszą być bardzo świadomi, kiedy wchodzą lub wychodzą z intranetu. Stąd twój sposób myślenia o tym, że jest ważne dla użytkowników, aby "zamknąć".

To proste. Stwórz usługę, która umieszcza bieżące powiadomienie na pasku powiadomień z napisem "Jestem w intranecie lub jestem uruchomiony". Zleć tej usłudze wykonanie wszystkich funkcji, których potrzebujesz w swojej aplikacji. Wykonuj czynności związane z tą usługą, aby umożliwić użytkownikom dostęp do bitów interfejsu użytkownika, których potrzebują do interakcji z "aplikacją". I mieć Android Menu - > Zakończ (lub wyloguj się lub cokolwiek) przycisk, który mówi, że usługa ma zakończyć, a następnie zamyka samą aktywność.

To jest, dla wszystkich intencji i celów dokładnie to, co mówisz, że chcesz. Zrobiłem Android sposób. Spójrz na Google Talk lub Google Maps nawigacji przykłady tego" wyjście " jest możliwe mentalność. Jedyną różnicą jest to, że naciśnięcie przycisku wstecz z Twojej aktywności może pozostawić proces Uniksa w oczekiwaniu na wypadek, gdyby użytkownik chciał ożywić Twoją aplikację. To jest tak naprawdę nie różni się od nowoczesnego systemu operacyjnego, który buforuje ostatnio dostępne pliki w pamięci. Po zamknięciu programu windows najprawdopodobniej potrzebne zasoby są nadal w pamięci i czekają na zastąpienie ich innymi zasobami, ponieważ są ładowane teraz, gdy nie są już potrzebne. Android to to samo.

Naprawdę nie widzę Twojego problemu.

To ciekawa i wnikliwa dyskusja z udziałem tak wielu ekspertów. Uważam, że ten post powinien zostać zapętlony z powrotem z głównej strony rozwoju Androida, ponieważ kręci się wokół jednego z podstawowych projektów systemu operacyjnego Android.

Chciałbym również dodać moje dwa centy tutaj.

Do tej pory byłem pod wrażeniem sposobu obsługi zdarzeń cyklu życia Androida, wprowadzając koncepcję środowiska internetowego do natywnych aplikacji.

Powiedziawszy, że wciąż uwierz, że powinien być przycisk Quit. Dlaczego? ... nie dla mnie, Teda, ani żadnego z tych guru, ale tylko w celu zaspokojenia potrzeb użytkowników końcowych.

Chociaż nie jestem wielkim fanem systemu Windows, ale dawno temu wprowadzili koncepcję, do której większość użytkowników końcowych jest przyzwyczajona (przycisk X)... "Chcę zakończyć uruchamianie widżetu, gdy 'chcę'".

To nie znaczy, że ktoś (OS, developer?) zajmie się tym według własnego uznania... to po prostu znaczy " gdzie jest mój Czerwony przycisk X, do którego jestem przyzwyczajony". Moje działanie powinno być analogiczne do "Zakończ połączenie po naciśnięciu przycisku", "wyłącz urządzenie naciskając przycisk", i tak dalej i tak dalej ... to percepcja. Satysfakcja sama w sobie sprawia, że moje działanie rzeczywiście osiąga swój cel.

Mimo że programista może sfałszować to zachowanie za pomocą podanych tutaj sugestii, percepcja nadal pozostaje tzn. aplikacja powinna całkowicie przestać funkcjonować (teraz), przez niezależne, zaufane i neutralne źródło (OS) na żądanie użytkownika końcowego.

Możeszzakończyć pracę, naciskając Wsteczlub wywołując finish() w swoim Activity. Po prostu zadzwoń finish() z MenuItem, Jeśli chcesz go wyraźnie zabić.

Romain nie mówi, że nie można tego zrobić, tylko, że jest to bezcelowe - użytkownicy nie muszą przejmować się rzucaniem pracy lub zapisywaniem pracy, ponieważ sposób działania aplikacji zachęca do pisania inteligentnego oprogramowania, które automatycznie zapisuje i przywraca swój stan bez względu na to, co się stanie.

Ta debata sprowadza się do odwiecznego pytania, czy deweloperzy wiedzą najlepiej, czy też użytkownik wie najlepiej. Profesjonalni projektanci we wszystkich obszarach czynników ludzkich zmagają się z tym każdego dnia.

Ted zwrócił uwagę, że jedną z najczęściej pobieranych aplikacji na rynku jest "zabójca aplikacji". Ludzie dostają trochę dodatkowej serotoniny, gdy rezygnują z aplikacji. Przywykli do tego z komputerem stacjonarnym/laptopem. To sprawia, że wszystko dzieje się szybko. Utrzymuje procesor w chłodzie, a wentylator z włączam. Zużywa mniej energii.

Kiedy uznasz, że urządzenie mobilne jest znacznie mniejszym statkiem, możesz szczególnie docenić ich zachętę do "wyrzucenia za burtę tego, czego już nie potrzebujesz". Teraz twórcy Androida przekonali, że system operacyjny wie najlepiej i że rezygnacja z aplikacji jest antyczna. Z całego serca to popieram.

Uważam jednak również, że nie należy frustrować użytkownika, nawet jeśli frustracja ta wynika z jego własnej ignorancji. Z tego powodu wniosek, że posiadanie opcji "Zakończ" jest dobrym projektem, nawet jeśli jest to głównie przycisk placebo, który nie robi nic więcej niż zamykanie widoku.

Ted, to, co próbujesz osiągnąć, można zrobić, być może nie tak, jak teraz o tym myślisz.

Proponuję poczytać o działalności i usługach. Przestań używać terminu "aplikacja" i zacznij odnosić się do komponentów, tj. aktywności, usługi. Myślę, że po prostu trzeba dowiedzieć się więcej o platformie Android; jest to zmiana sposobu myślenia ze standardowej aplikacji na PC. Fakt, że żaden z Twoich postów nie miał w nich słowa "aktywność" (Krótki cytat z FAQ, czyli nie twoje słowa) mówi musisz poczytać więcej.

Blog post kiedy włączyć przycisk wyjścia w aplikacjach na Androida (podpowiedź: nigdy) lepiej niż ja. Szkoda, że każdy programista Androida już go przeczytał.

Fragmenty:

Z mojego doświadczenia wynika, że to, czego [użytkownicy] naprawdę chcą, to: jednoznaczny sposób zagwarantowania, że aplikacja przestanie zużywać zasoby (bateria, cykle procesora, transfer danych itp.).

Wielu użytkowników dostrzega, że Przycisk exit implementuje wymóg ten i poproś o dodanie. Deweloperów, chcących zadowolić swoich użytkowników, obowiązkowo dodać jeden. Wkrótce potem obaj zawiedli.

• w większości przypadków przycisk exit po prostu wywołuje Activity.finish(). Jest to Dokładnie równoważne naciśnięciu przycisku Wstecz. Dokładnie. usługi wciąż działają, a sondaże wciąż się zdarzają. Użytkownicy mogą myśleć, że zabili aplikację, ale tak się nie stało i wkrótce będą jeszcze bardziej zirytowani.
• zachowanie wyjścia jest teraz niejednoznaczna. Czy przycisk wyjścia powinien po prostu zamknąć aktywność, czy też powinien zatrzymać wszystkie powiązane usługi, odbiorniki i alarmy? Co należy zrobić Z Powrotem ? Co się stanie, jeśli zamiast tego uderzą w Dom? Co się stanie, jeśli Twoja aplikacja ma widżet? Czy przycisk exit też powinien zatrzymać aktualizację?

Rozwiązaniem jest, aby przycisk back zachowywał się tak, jak można się spodziewać przycisk wyjścia do. Jeszcze lepiej, po prostu przestań zużywać zasoby, gdy tylko aplikacja nie jest widoczne.

Śmiało, Przeczytaj cały artykuł.

Myślę, że chodzi o to, że nie ma potrzeby, aby zamknąć aplikację, chyba że masz wadliwe oprogramowanie. Android zamyka aplikację, gdy użytkownik jej nie używa, A Urządzenie potrzebuje więcej pamięci. Jeśli masz aplikację, która musi uruchomić usługę w tle, prawdopodobnie będziesz potrzebować sposobu wyłączenia usługi.

Na przykład Google Listen kontynuuje odtwarzanie podcastu, gdy aplikacja nie jest widoczna. Ale zawsze jest przycisk pauzy, aby wyłączyć podcast, gdy Użytkownik skończy z nim. If I pamiętaj poprawnie, słuchaj, nawet umieszcza skrót na pasku powiadomień, dzięki czemu zawsze możesz szybko dostać się do przycisku pauzy. Innym przykładem jest aplikacja, na przykład aplikacja twitter, która stale ankiety usługi w Internecie. Tego typu aplikacje powinny naprawdę pozwolić użytkownikowi wybrać, jak często ankieta serwera, czy nawet ankieta w wątku w tle.

Jeśli potrzebujesz kodu, który działa po zakończeniu, możesz nadpisać onpause (), onStop () lub onDestroy () jako odpowiednie. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Jeśli nie jesteś w stanie pojąć, jak sprawić, by Twoje dane/połączenia (a tym samym Twoja "aplikacja") stały się trwałe, nie będziesz w stanie zrobić tego, co "potrzebujesz" zrobić z Androidem.

Ci, którzy pobierają te cutesy Little App Killers zwykle znaleźć nie pomagają żywotność baterii lub zużycie pamięci, ale utrudniają system operacyjny od wykonywania jego zadanie efektywnego zarządzania pamięcią...

Http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

Rozważyłbym przeczytanie "Android Wireless Application Development" opublikowane przez Addison-Wesley. Właśnie kończę i jest bardzo dokładny.

Wygląda na to, że masz pewne fundamentalne nieporozumienia dotyczące Platformy Android. Ja też na początku byłem trochę sfrustrowany cyklem życia aplikacji na Androida, ale po lepszym zrozumieniu, naprawdę cieszę się tym podejściem. Ta książka odpowie na wszystkie Twoje pytania i wiele więcej. Informatyka naprawdę jest to najlepszy zasób, jaki znalazłem dla nowych programistów Androida.

Również, myślę, że trzeba puścić linię do linii portu istniejącej aplikacji. Aby przenieść aplikację na platformę Android, część projektu aplikacji ulegnie zmianie. Zastosowany cykl życia aplikacji jest niezbędny, ponieważ urządzenia mobilne mają bardzo ograniczone zasoby w stosunku do systemów stacjonarnych i umożliwiają urządzeniom z systemem Android uruchamianie kilku aplikacji w uporządkowany i świadomy zasobów sposób. Zrób więcej w dogłębne zbadanie platformy i myślę, że zdasz sobie sprawę, że to, co chcesz zrobić, jest całkowicie wykonalne. Powodzenia.

Przy okazji, nie jestem w żaden sposób związany z Addison-Wesley lub jakąkolwiek osobą lub organizacją związaną z tą książką. Po ponownym przeczytaniu mojego postu czuję, że wyszedłem trochę fanboyish. Po prostu bardzo, bardzo mi się podobało i okazało się to niezwykle pomocne. :)

ODPOWIEDŹ: (Romain Guy): użytkownik nie, system obsługuje to automatycznie. To właśnie cykl życia aktywności (zwłaszcza onPause/onStop / onDestroy) jest dla. Bez względu na to, co robisz, nie wkładaj przycisk" Zakończ "lub" zakończ " aplikacji. jest bezużyteczny z Androidem model aplikacji. Jest to również sprzeczne z tym, jak podstawowe aplikacje praca.

1: całkowite opuszczenie aplikacji może być ogólnie niemandatowe, ale nie jest bezużyteczne. Co by było gdyby okna nie miały wyjście? System byłby powolny, ponieważ pamięć była pełna, a system operacyjny musiał zgadywać, z którymi programami skończyłeś. Nie obchodzi mnie, co mówią Romain Guy, a nawet Larry Page i Sergey Brin - to niezaprzeczalne fakty: systemy działają wolniej, gdy muszą zabić zadania, aby uzyskać pamięć, zanim nowa aplikacja może zostać uruchomiona. Po prostu nie możesz mi powiedzieć, że nie potrzeba czasu, aby zabić aplikację! Nawet światło z odległych gwiazd wymaga czasu... Istnieje pewne zastosowanie w pozwalaniu użytkownikowi na pełne zamknij aplikacje.

2: wbrew temu, jak działają podstawowe aplikacje? Co to miało znaczyć? Kiedy skończę na razie uruchamiać aplikację, nie robi już żadnych work...It po prostu czeka na śmierć przez system operacyjny, gdy jego pamięć jest potrzebna.

Podsumowując, istnieje wyraźna różnica między minimalizacją a opuszczeniem, i Żadna szczypta nie uderza dobrze dla drugiej. Zostawiamy śrubokręt w każdej śrubie? Albo klucz w każdych drzwiach? Czy zostawiamy wszystkie nasze urządzenia na wysokim poziomie, dopóki nie wybuchnie wyłącznik i musimy włączyć inne urządzenie? Czy zostawiamy zmywarkę pełną naczyń i za każdym razem wyjmujemy tylko tyle, aby zrobić miejsce dla nowych brudnych? Zostawiamy wszystkie samochody na podjeździe, aż ...

Jeśli użytkownik chce zminimalizować aplikację, najlepiej ją zminimalizować. Jeśli użytkownik chce zamknąć aplikację, najlepiej jest ją zamknąć.

Czy jest źle? Takie jest zdanie Androida-marszczą na nim brwi. I wiele wielu niezależnych Programiści Androida marszczą na nim brwi.

Ale jeśli chodzi o to, jest dobre kodowanie i złe kodowanie. Istnieją dobre modele przepływu programu i są złe modele przepływu programu.

Pozostawianie programów w pamięci, gdy użytkownik wie, że są z nimi po prostu nie jest dobrym przepływem programu. Nie służy to absolutnie żadnemu celowi i spowalnia działanie podczas uruchamiania nowych aplikacji lub uruchamiania aplikacji przydziel więcej pamięci.

To coś w rodzaju Twojego samochodu: są czasy kiedy zostawisz go uruchomiony, jak zatrzymanie się na światłach stop, a może przejazd fast foodem lub zatrzymanie się w bankomacie. Ale są inne sytuacje, w których chcesz go wyłączyć - jak w pracy, sklepie spożywczym lub nawet w domu.

Przycisk exit w niektórych aplikacjach powinien być bardziej z przodu niż inni. Na przykład gry lub programy, w których użytkownik prawdopodobnie będzie chciał w pełni wyjść, powinny mieć oczywiste wyjście. Inne programy, takie jak, być może, Programy pocztowe, gdzie wyjście jest mało prawdopodobnym pragnieniem ( tak, że może nadal sprawdzać pocztę e-mail) -- te programy nie powinny marnować miejsca na ekranie wejściowym prime control z opcją exit, ale dla dobrego przepływu programu, powinny mieć opcję exit. Co jeśli ktoś zdecyduje, że nie chce, aby jego program pocztowy próbował sprawdzić pocztę e-mail kiedy są w słabym zasięgu, a może w rozmowie Skype lub cokolwiek innego? Pozwól im wyjść z programu e-mail, jeśli chcą!

Prawie 99% czasu nie ma potrzeby, aby aplikacja na Androida przejęła własny cykl życia. Większość czasu sprowadza się do lepszego planowania lub inteligentniejszego projektowania aplikacji. Na przykład raczej zbuduj wewnętrzną usługę (Nie eksportowaną) do obsługi pobrań itp. lub projektowanie działań i zadań wokół przepływu pracy użytkownika.

Więc jak poprosić aplikację o popełnienie samobójstwa w Androidzie? Cóż, sztuczka jest prosta:

Utwórz własną klasę aplikacji na Androida, dziedzicząc po standardowym Androidzie.app.Klasa aplikacji (pamiętaj, aby zadeklarować ją w AndroidManifest.plik xml).

Nadpisuje metodę onCreate () i Przechowuje identyfikator procesu, który rozpoczęcie aplikacji:

this.pid = android.os.Process.myPid(); // Save for later use.

Teraz, aby zabić twoją aplikację, podaj metodę kill ():

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

Teraz, gdy potrzebujesz swojej aplikacji do popełnienia samobójstwa, po prostu wpisz cast kontekst aplikacji i zadzwoń do swojej metody zabijania!

((MySuicidalApp) context.getApplicationContext()).kill()

Kiedy wyobrażam sobie aplikację w Androidzie, widzę ją w ten sposób:

• pracujesz ze swoją aplikacją
• zadzwonił telefon
• you take the call
• Po zakończeniu rozmowy wracasz do aplikacji w tym samym miejscu, w którym byłeś

Aby to zrobić, wystarczy przycisk Back lub przycisk Home w telefonie (przez krótkie lub długie naciśnięcie) i pasek powiadomień.

Po wyjściu z aplikacji używam tylko przycisk do tyłu , aż się z niego wydostanę lub przycisk do domu .

Myślę, że tak powstaje większość aplikacji. Ale jeśli potrzebuję jakiegoś rodzaju sesji lub połączenia, wyjaśniłem to użytkownikowi za pomocą przycisku logowania/wylogowania i powiadomienia (pasek tytułu lub cokolwiek innego). Jest to raczej inny styl niż czysta aplikacja stylu "exit".

Na komputerach PC masz pulpit z wieloma interfejsami graficznymi, a na Androidzie oczywiście masz wiele zadań, ale wyświetlasz tylko jedno aplikacja na raz (nie uważam widgetów tutaj^^). A na telefonie komórkowym w każdej chwili możesz otrzymać powiadomienie o czymś ważniejszym niż to, co robisz.

Więc cała koncepcja aplikacji opiera się na czymś innym niż "enter application-work-exit application".

Hmmmm...

Myślę, że po prostu nie widzisz aplikacji na Androida w odpowiedni sposób. Możesz zrobić coś prawie jak chcesz łatwo:

• Czy działania aplikacji Zapisz/Przywróć stan, jak to jest zalecane w dokumentacji programisty livecycle.

• Jeśli potrzebne jest jakieś logowanie na etapie przywracania (brak informacji o logowaniu/sesji), zrób to.

• Ewentualnie dodać przycisk / menu / timeout, w którym to przypadku zrobisz finish() bez zapisywanie loginu i innych informacji o sesji, co pośrednio oznacza koniec sesji aplikacji: więc jeśli aplikacja zostanie ponownie uruchomiona/przeniesiona do przodu, rozpocznie nową sesję.

W ten sposób nie obchodzi cię, czy aplikacja jest naprawdę usunięta z pamięci, czy nie.

Jeśli naprawdę chcesz usunąć go z pamięci (to zniechęca, a BTW w jakim celu?) można go zabić warunkowo na końcu onDestroy() za pomocą java.lang.System.exit(0) (a może restartPackage(..)?). Oczywiście rób to tylko w przypadku, gdy chcesz aby "naprawdę zakończyć aplikację", ponieważ onDestroy() jest częścią normalnego cyklu życia aktywności, a nie końcem aplikacji w ogóle.

Ponieważ aplikacja w kontekście Androida to tylko kilka niejasno powiązanych działań, rzucenie aplikacji nie ma zbyt wiele sensu. Możesz zakończyć działanie (), a Widok poprzedniej aktywności na stosie działań zostanie narysowany.

Jądro Linuksa posiada funkcję o nazwie Out-of-memory killer (Jak wspomniano powyżej, zasady są konfigurowalne na poziomie przestrzeni użytkownika, a jądro nie jest optymalne, ale nie jest niepotrzebne).

I jest mocno używany przez Androida:

• OOM killer nie jest dla przestrzeni użytkownika

• Android Notes (Oom Killer Info-gdzie można skonfigurować funkcję OOM na Android)

• Android Portowanie Na Rzeczywistym Celu

Niektóre aplikacje w przestrzeni użytkownika są dostępne, aby pomóc z tymi aplikacjami kill, na przykład:

• Autokiller / Konfigurowanie wewnętrznego zabójcy Zadań Androida

Najwyraźniej znalazłeś żądaną odpowiedź w Komendzie finish (). Nie usunie to aplikacji z pamięci, ale Android zrobi to, gdy potrzebuje zasobów, więc nie ma żadnej różnicy, że nie będziesz tego robić wyraźnie.

Dodam tylko, że w celu osiągnięcia pełnego efektu, jaki zwykle ma wyjście z aplikacji, chcesz zresetować stan aplikacji do tego, jaki jest normalnie w momencie jej pierwszego uruchomienia po uruchomieniu urządzenia, tuż przed wywołaniem finish() we wszystkich twoich działaniach. W ten sposób, jeśli użytkownik ponownie wybierze aplikację, będzie się wydawać, że została uruchomiona "świeżo", bez żadnego stanu pozostałego z punktu przed symulowanym "zakończeniem"."

Jeśli istnieją pewne specjalne akcje, które powinny wystąpić tylko przy "exit", takie jak zapisywanie pracy użytkownika lub cokolwiek innego, możesz również wykonać je przed ponowną inicjalizacją części powyższej procedury.

Takie podejście pozwala osiągnąć swój cel, jakim jest posiadanie polecenie "exit" bez naruszania filozofii Androida polegającej na pozostawieniu zarządzania zasobami systemu operacyjnego, w tym zamykania aplikacji, w rękach systemu operacyjnego.

Osobiście nie korzystałbym z tego podejścia, ponieważ użytkownicy Androida oczekują, że aplikacja zachowa jej ciągłość, gdy ponownie ją odwiedzają, a więc nie są przyzwyczajeni do sposobu "wychodzenia" z aplikacji. Zamiast tego wspierałbym funkcję "Wyczyść", którą użytkownik może wywołać, aby zresetować aplikację do domyślnego stanu początkowego, bez konieczność "pozostawienia" go w procesie.

Jedynym wyjątkiem będzie, gdy użytkownik naciśnie przycisk Wstecz wystarczającą liczbę razy, aby spowodować zamknięcie aplikacji. W takiej sytuacji nie ma oczekiwań ze strony użytkownika, że stan zostanie zapisany (a jeśli w aplikacji jest niezapisany stan, to Ty, jako deweloper, powinieneś mieć kod obsługujący przycisk Wstecz, który wykrywa niezapisane dane i prosi użytkownika o zapisanie go na SharedPreferences lub do pliku, lub do jakiegoś innego programu. nielotne medium).

Odnośnie systemu.wyjście(0):

Jeśli zdecydujesz się na użycie systemu.exit (0) aby zamknąć aplikację z chamskim finality (na przykład, w wyniku ostatniego naciśnięcia przycisku Wstecz), następnie chciałbym ostrzec, że chociaż dla mnie to "działa", aw niektórych przypadkach był to jedyny sposób byłem w stanie zamknąć aplikację bez śladu to pozostały, jest jeden drobny usterka, która występuje w Jelly Bean, gdy używasz tego podejścia.

W szczególności, jeśli używasz Lista ostatnich aplikacji umożliwia otwarcie aplikacji, a następnie zamknięcie aplikacji za pomocą przycisku wstecz (z tym zamknięciem zaimplementowanym za pośrednictwem systemu.exit (0)), lista ostatnich aplikacji stanie się ponownie widoczna, ponieważ nigdy nie zostanie zamknięta. Jeśli następnie stukniesz pozycję aplikacji na tej liście, aby uruchomić ją po raz drugi z tej samej, już otwartej, ostatniej listy aplikacji, nie będzie odpowiedzi.

Podejrzewam, że przyczyną tego jest to, że lista ostatnich aplikacji trzyma się odniesienia do Twojej aplikacji, która ma stań się niefunkcjonalny ze względu na zamknięcie aplikacji za pomocą systemu.exit (0) Bardziej cywilizowane zamknięcie aplikacji za pomocą finish() mogło poinformować system operacyjny w sposób, który pozwoliłby mu odświeżyć listę ostatnich aplikacji, ale system.exit (0) najwyraźniej tego nie robi.

Nie jest to wielki problem sam w sobie, ponieważ bardzo niewiele osób otworzy aplikację z ostatnich aplikacji, a następnie ją opuści, a następnie natychmiast otworzy ją ponownie z tej samej listy otwartych ostatnich aplikacji. A jeśli dotkną przycisk home, a następnie ponownie otwórz listę ostatnich aplikacji, wpis Twojej aplikacji będzie tam i będzie w pełni funkcjonalny. Ale myślę, że to pokazuje, że korzystanie z systemu.exit (0) może zakłócać prawidłową komunikację między aplikacją a systemem operacyjnym, co sugeruje, że mogą wystąpić inne, poważniejsze, być może subtelne konsekwencje stosowania tego podejścia.

Zgadzam się z Tedem. Rozumiem, że wyjście z aplikacji nie jest "Android sposób", ale nie wydaje się, że należy go wykluczyć. Proszę. są trzy powody, dla których możesz chcieć prawdziwego wyjścia do aplikacji (nie tylko aktywność):

1. Użytkownik może chcieć mieć kontrolę nad tym, która aplikacja zostanie zabita w przypadek niskiej pamięci. Jeśli ważna aplikacja A działa w tle, następnie możesz wyjść z aplikacji B, gdy skończysz z tym, więc ta aplikacja A nie zostaje zabita przez system operacyjny.

2. Jeśli aplikacja ma poufne dane w pamięci podręcznej, możesz jak zabić aplikację tak, że wirus / robak / rogue aplikacja nie może dostać się do niego. I wiem, że model bezpieczeństwa ma temu zapobiec, ale na wszelki wypadek...

3. Jeśli Twoja aplikacja korzysta z zasobów (takich jak sieć, procesor, czujniki itp.) które mogą niekorzystnie wpłynąć na telefon, a następnie jednym ze sposobów zapewnienia, że te zasoby są zwolnione, aby zamknąć aplikację. Rozumiem. że dobrze wychowany aplikacje powinny zwolnić zasoby, gdy nie są potrzebne. Ale ponownie, wyjście z aplikacji wydaje się rozsądnym sposobem zapewnienia tego.

Istnieje (stosunkowo) prosta konstrukcja, która pozwoli ominąć zagadkę "wyjścia". Spraw, aby Twoja aplikacja miała stan "podstawowy" (aktywność), który jest tylko pustym ekranem. Przy pierwszym uruchomieniu aktywności możesz uruchomić inną aktywność, w której znajduje się główna funkcjonalność Twojej aplikacji. "Wyjście" można następnie wykonać poprzez finish()w tej drugiej czynności i powrót do podstawy tylko pustego ekranu. System Operacyjny może zachować ten pusty ekran w pamięci tak długo, jak chce...

In esencja, ponieważ nie możesz wyjść na OS, po prostu przekształcisz się w samo-stworzoną nicość.

Mam nadzieję, że z czasem wszystko się zmieni. Użytkownik powinien być w stanie zabić aplikację lub proces, jeśli proces aplikacji jest poprawnie piaskownicy przez system operacyjny. Istnieje pogląd, że aplikacje powinny być napisane doskonale lub użytkownik będzie korzystać tylko z aplikacji, które spełniają wszystkie zalecenia SDK. Myślę, że to trudne zadanie.

Po pierwsze, nigdy nigdy nie używaj systemu.exit (0)To tak, jakby człowiek spał, waląc go w głowę!

Myślę, że jeśli napiszesz dobry kawałek kodu, który zrobi właściwe rzeczy (aktualizuje, zapisuje i wypycha) w odpowiednim momencie i warunkach oraz używając poprawnych rzeczy (usługi i odbiornika), to będzie działać całkiem dobrze i nikt nie będzie narzekał.

Ale aby to zrobić, musisz się uczyć i uczyć, jak to działa na Androidzie. W każdym razie, jest to moje rozwiązanie, aby zapewnić użytkownikom "Przycisk Wyjścia".

Stworzyłem menu opcji zawsze widoczne w każdej aktywności (mam super aktywności, które to robią).

Gdy użytkownik kliknie ten przycisk, dzieje się tak:

Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);

  // Commit the edits!
editor.commit();
startActivity(intent);
finish();

Więc zapisuję w SharedPreferences, że chcę zabić moją aplikację, i zaczynam zamiar. Proszę spojrzeć na te flagi; te wyczyszczą cały mój backstack, nazywając moją aktywność na pulpicie nawigacyjnym, która jest moją aktywnością "domową".

Więc w mojej aktywności na desce rozdzielczej uruchamiam tę metodę w onResume:

private void checkIfForceKill() {

    // CHECK IF I NEED TO KILL THE APP

    // Restore preferences
    SharedPreferences settings = getSharedPreferences(
            getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
    boolean forceKill = settings.getBoolean(
            MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);

    if (forceKill) {

        //CLEAR THE FORCE_EXIT SETTINGS
        SharedPreferences.Editor editor = settings.edit();
        editor.putBoolean(FORCE_EXIT_APPLICATION, false);

        // Commit the edits!
        editor.commit();

        //HERE STOP ALL YOUR SERVICES
        finish();
    }
}

I będzie działać całkiem dobrze.

Jedyna rzecz, której nie rozumiem, dlaczego to dzieje się tak, że gdy robię Ostatnie wykończenie (i sprawdziłem: to po wszystkich prawidłowy przepływ onPause → onStop → ondestroy) aplikacja jest nadal na ostatniej aktywności (ale jest pusty).

Wydaje się, że najnowsza intencja (która uruchomiła Pulpit Nawigacyjny) nadal jest w systemie.

Bez Funkcji exit dla dewelopera aplikacji do zabicia własnej aplikacji jest to bardzo zły projekt.

Moja aplikacja musi pozwolić użytkownikowi na dynamiczną zmianę danych podczas wykonywania i użytkownik musi ponownie uruchomić moją aplikację, aby efekt zmiany, ale Android nie pozwolił na ponowne uruchomienie mojej aplikacji sam. Android OS ma bardzo zły cykl życia aplikacji projektowej.

[2]}przeczytanie tego pytania i odpowiedzi Zajęło mi więcej czasu niż wdrożenie pół-WŁAŚCIWEGO cyklu życia aplikacji na Androida.

Jest to aplikacja GPS, która sonduje punkty i wysyła bieżącą lokalizację do serwisu internetowego co kilka sekund za pomocą wątku... Może to być ankieta co 5 minut w przypadku Ted dla aktualizacji, a następnie onStop może po prostu rozpocząć aktywność aktualizacji Ted był soo zaniepokojony, jeśli ktoś został znaleziony (asynchroniczny Ted, nie koduj jak programista Windows lub Twoje programy będą działać jak Programy Windows ... eww, to nie takie trudne).

Zrobiłem kilka początkowych kodów w onCreate, aby skonfigurować rzeczy do życia aktywności, w tym checkUpdate.start();:

...

@Override
public void onStart() {
    super.onStart();
    isRemote = true;
    checkUpdate.resume();

    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}

@Override
public void onPause() {
    isRemote = false;
    checkUpdate.suspend();
    locationManager.removeUpdates(luh);
    super.onStop();
}

Ten kod może być całkowicie błędny, ale działa. Jest to jedna z moich pierwszych aplikacji na Androida.

Voilà, aplikacja, która nie zużywa procesora, gdy jest w tle, ale jest natychmiast gotowa do ponownego otwarcia, ponieważ jest w pamięci RAM (chociaż nie trzyma pamięci RAM, jak to jest w cyklu życia Androida) ... aplikacja jest zawsze gotowy, to telefon, chłopaki / dziewczyny. Jeśli aplikacja miała zużyć całą pamięć RAM i nie mogła być wyłączona przez system operacyjny, to może przestać dzwonić =P dlatego system operacyjny musi być w stanie zamknąć aplikację, gdy jest w tle (jeśli aplikacja nie jest Wieprzem zasobów, nie zostanie zamknięta BTW), więc po prostu napiszmy lepsze aplikacje.

Do zamknięcia aplikacji w dowolnym momencie użyj znacznika FLAG_ACTIVITY_CLEAR_TOP w intencji, a następnie system.exit();

Lub istnieje podobny sposób, ale bez system.exit() Gdy chcesz zakończyć wywołanie tej metody:

public void exit() {
    startActivity(new Intent(this, HomeActivity.class).
    setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}

W Twoim HomeActivity.onCreate() Dodaj następujący kod

protected void onCreate(Bundle savedInstanceState) {
    if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
        if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
            finish();
        }
    }
......................

To zadziała bez przerywania cyklu życia Androida.

Za każdym razem, gdy przechodzisz do następnej strony poprzez intent, użyj:

`YourActivityname.this.finish()`;

Przykład:

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

Aby żadna aktywność nie była uruchomiona w tle i kiedy chcesz wyjść z aplikacji, Użyj:

MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();

To wyjście zadziałało jak urok dla mnie:)

Cykl życia aplikacji na Androida jest przeznaczony dla użytkowników telefonów komórkowych, a nie użytkowników komputerów.

Cykl życia aplikacji jest brutalnie uproszczonym paradygmatem wymaganym do przekształcenia serwera Linux w urządzenie konsumenckie.

Android to Java zamiast Linuksa, prawdziwy wieloplatformowy system operacyjny serwera. W ten sposób rozprzestrzenił się tak szybko. Cykl życia aplikacji obejmuje podstawową rzeczywistość systemu operacyjnego.

Dla użytkowników mobilnych aplikacje są po prostu zainstalowane lub nie. Nie ma pojęcia o bieganiu lub wychodzę. W rzeczywistości procesy aplikacji mają działać, dopóki system operacyjny nie wyda ich dla posiadanych zasobów.

Ponieważ jest to przepełnienie stosu, każdy, kto to czyta, jest użytkownikiem komputera i musi wyłączyć 90% swojej wiedzy, aby zrozumieć cykl życia aplikacji mobilnej.

W każdym przypadku, jeśli chcesz zakończyć aplikację, zawsze możesz zadzwonić System.exit(0);.

Jeśli masz 10,20 .. wiele działań uruchomionych i chcesz zakończyć je wszystkie i wyjść z systemu.

Utwórz tablicę statyczną w application class lub constants class.

Stałe

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

MainActivity Dodaj odniesienie do bieżącej aktywności w tej tablicy

activity = MainActivity.this; Constants.activities.add(activity);

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        activity = MainActivity.this;
        Constants.activities.add(activity);

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}