애플리케이션을 종료하는 것이 눈살을 찌푸리게 합니까?

애플리케이션을 종료하는 것이 눈살을 찌푸리게 합니까?

Android를 배우려는 시도를 계속하면서, 저는 다음과 같습니다.

질문:.우리가 앱을 죽이기 위해 메뉴 옵션을 넣지 않는 한 사용자가 앱을 종료할 수 있는 선택권이 있습니까? 이러한 옵션이 없는 경우 사용자는 어떻게 애플리케이션을 종료합니까?

답변: (로메인 가이):사용자는 그렇지 않습니다. 시스템은 자동으로 이 작업을 처리합니다. 활동 라이프사이클(특히 Pause/onStop/onDestroy)의 목적이 바로 여기에 있습니다. 당신이 무엇을 하든, "종료" 또는 "종료" 응용프로그램 버튼을 넣지 마십시오. 그것은 안드로이드의 애플리케이션 모델에서는 쓸모가 없습니다. 이는 또한 핵심 애플리케이션이 작동하는 방식과도 반대됩니다.

헤헤, 안드로이드 세상에서 한 걸음 한 걸음 할 때마다 일종의 문제가 생깁니다=(

분명히 안드로이드에서는 애플리케이션을 종료할 수 없습니다. 하지만 안드로이드 시스템은 앱이 원할 때마다 완전히 파괴될 수 있습니다.저거 어떻게 된 거예요?사용자가 마음만 먹으면 앱을 종료할 수 있는 '일반 앱' 기능을 하는 앱을 만드는 것은 불가능하다는 생각이 들기 시작했습니다.그것은 OS에 의존해서는 안 되는 일입니다.

제가 만들려고 하는 앱은 안드로이드 마켓용 앱이 아닙니다.일반인들이 '광범위하게 사용'하기 위한 애플리케이션이 아니라, 매우 좁은 비즈니스 분야에서 사용될 비즈니스 앱입니다.

Windows Mobile 및 .NET에 존재하는 많은 문제를 해결하기 때문에 Android 플랫폼을 개발하는 것이 매우 기대되었습니다.하지만, 지난 주는 나에게 약간의 휴식이었습니다...안드로이드를 버리지 않아도 된다면 좋겠지만, 지금은 별로 좋아 보이지 않아요 =(

제가 정말로 지원서를 그만둘 수 있는 방법이 있나요?

이것은 결국 여러분의 질문에 도달하겠지만, 저는 먼저 여러분이 이 글을 쓸 때 이미 주어진 다양한 답변에 대해 여러분의 다양한 논평에서 제기하는 많은 문제들을 다루고 싶습니다.저는 당신의 생각을 바꿀 생각이 없습니다. 오히려, 이것들은 미래에 이 게시물을 읽으러 오는 다른 사람들을 위해 여기에 있습니다.

요점은 안드로이드가 내 앱이 언제 종료될지 결정하도록 허용할 수 없다는 것입니다.사용자가 선택해야 합니다.

수백만 명의 사람들이 환경이 필요에 따라 애플리케이션을 종료하는 모델에 완벽하게 만족하고 있습니다.이러한 사용자들은 단순히 웹 페이지를 "종료"하거나 온도 조절기를 "종료"하는 것처럼 안드로이드 앱을 "종료"하는 것에 대해 생각하지 않습니다.

iPhone 사용자들은 iPhone 버튼을 누르는 것이 사용자가 중단한 곳에서 많은 iPhone 앱이 선택되기 때문에 앱이 종료된 것처럼 "느끼지 않는다"는 점에서 매우 비슷합니다(현재 iPhone은 한 번에 하나의 타사 앱만 허용하므로).

위에서 말했듯이, 내 앱에는 많은 일들이 있습니다(장치에 푸시되는 데이터, 항상 있어야 하는 작업 목록 등).

"항상 있어야 하는 작업이 포함된 목록"이 무엇을 의미하는지는 모르겠지만, "장치에 푸시 중인 데이터"는 유쾌한 허구이므로 어떤 경우에도 활동에 의해 수행되어서는 안 됩니다.스케줄링된 작업 사용(다음을 통해)AlarmManager신뢰성을 극대화하기 위해 데이터를 업데이트합니다.

사용자가 로그인하고 전화를 받을 때마다 Android가 앱을 종료하기로 결정할 때마다 로그인할 수 없습니다.

이것을 다루는 많은 아이폰과 안드로이드 애플리케이션이 있습니다.일반적으로 사용자가 매번 수동으로 로그인하도록 강제하기보다는 로그인 자격 증명을 보유하고 있기 때문입니다.

예를 들어, 응용 프로그램을 종료할 때 업데이트를 확인하려고 합니다.

그것은 모든 운영 체제의 실수입니다.아시다시피, 애플리케이션이 "종료"되는 이유는 OS가 종료되고 있기 때문입니다. 그러면 업데이트 프로세스가 중간에 실패합니다.일반적으로, 그것은 좋은 것이 아닙니다.시작 시 업데이트를 확인하거나 예약된 작업 등을 통해 완전히 비동기적으로 업데이트를 확인하고 종료하지 않습니다.

뒤로 버튼을 눌러도 앱이 전혀 사라지지 않는다는 의견도 있습니다(위 질문의 링크 참조).

뒤로 버튼을 눌러도 "앱을 종료"하지 않습니다.사용자가 뒤로 단추를 눌렀을 때 화면에 표시된 활동이 종료됩니다.

사용자가 종료를 원할 때만 종료해야 합니다. 절대 다른 방법은 없습니다.안드로이드에서 그렇게 행동하는 앱을 작성할 수 없다면, 안드로이드를 실제 앱 작성에 사용할 수 없다고 생각합니다 =(

그러면 웹 애플리케이션도 마찬가지입니다.또는 WebOS, 만약 내가 그들의 모델을 올바르게 이해한다면 (아직 그것을 가지고 놀 기회가 없습니다).이 모든 것들에서, 사용자들은 아무것도 "종료"하지 않고 그냥 떠나갑니다. 아이폰은 현재 (몇 가지 예외를 제외하고) 한 번에 한 가지만 실행할 수 있다는 점에서 약간 다릅니다. 그래서 떠나는 행동은 앱을 상당히 즉시 종료하는 것을 의미합니다.

제가 정말로 지원서를 그만둘 수 있는 방법이 있나요?

사람들이 경유) 코드 다모사가말이듯했자용든코경사른드자용, BACK또는유사용자경유back▁(▁as코(드▁code)finish()현재 실행 중인 활동을 닫을 수 있습니다.사용자는 일반적으로 웹 응용프로그램을 사용하기 위해 "종료" 옵션이 필요한 것보다 적절하게 작성된 응용프로그램에 대해 더 이상 필요한 것이 없습니다.

---

두 애플리케이션 환경은 정의상 동일하지 않습니다.이것은 새로운 것이 생겨나고 다른 것들이 묻히면서 환경의 추세를 볼 수 있다는 것을 의미합니다.

예를 들어, "파일"의 개념을 없애려는 움직임이 증가하고 있습니다.대부분의 웹 응용 프로그램은 사용자가 파일을 생각하도록 강요하지 않습니다. 아이폰 응용 프로그램은 일반적으로 사용자가 파일을 생각하도록 강요하지 않습니다.안드로이드 앱은 일반적으로 사용자가 파일을 생각하도록 강요하지 않습니다.등등.

마찬가지로, 앱을 "종료"하는 개념을 제거하려는 움직임이 증가하고 있습니다.대부분의 웹 응용 프로그램은 사용자가 로그아웃하도록 강제하지 않고 일정 기간 동안 사용하지 않으면 암묵적으로 로그아웃합니다.Android에서도 마찬가지이며, iPhone(및 WebOS)도 마찬가지입니다.

이를 위해서는 비즈니스 목표에 초점을 맞추고 이전 애플리케이션 환경과 연결된 구현 모델을 고수하지 않고 애플리케이션 설계에 더 중점을 두어야 합니다.이를 수행할 시간이나 성향이 부족한 개발자는 기존의 정신적 모델을 깨는 새로운 환경에 좌절할 것입니다.이것은 두 환경의 잘못이 아닙니다. 마치 폭풍이 산을 통과하기 보다는 산 주위를 흐르는 것이 산의 잘못인 것처럼 말입니다.

예를 들어 Hypercard 및 Smalltalk와 같은 일부 개발 환경에서는 애플리케이션과 개발 도구가 하나의 설정으로 결합되었습니다.이 개념은 앱에 대한 언어 확장(예: Excel의 VBA, AutoCAD의 Lisp) 외에는 그다지 인기를 끌지 못했습니다.따라서 앱 자체에 개발 도구의 존재를 추정하는 정신적 모델을 고안한 개발자는 모델을 변경하거나 모델이 사실일 수 있는 환경으로 제한해야 했습니다.

그래서, 당신이 다음을 쓸 때:

제가 발견한 다른 지저분한 것들과 함께, 저는 안드로이드용 앱을 개발하는 것은 불가능하다고 생각합니다.

그게 최선인 것 같아요, 당신을 위해서요, 지금 당장요.마찬가지로, Android에서 보고한 것과 동일한 문제 중 일부는 웹 응용 프로그램에서도 발견될 수 있기 때문에 응용 프로그램을 웹으로 이식하지 않도록 권장합니다(예: "종료" 없음).또는 반대로 언젠가 앱을 웹으로 포팅하면 웹 응용 프로그램의 흐름이 Android와 더 잘 맞을 수 있으며, 그 때 Android 포트를 다시 방문할 수 있습니다.

이 스레드의 미래 독자를 위해 여기에 수정 사항을 추가하고 싶습니다.이 특별한 뉘앙스는 오랫동안 제가 이해하지 못했기 때문에 저는 여러분 중 누구도 같은 실수를 하지 않도록 하고 싶습니다.

System.exit() 스택에 둘 이상의 활동이 있는 경우 앱을 종료하지 않습니다.실제로 프로세스가 종료되고 스택에서 작업이 하나 줄어들면 즉시 다시 시작됩니다.강제 종료 대화 상자에 의해 앱이 종료되거나 DDMS에서 프로세스를 종료하려고 할 때에도 이 문제가 발생합니다.제가 아는 한, 이것은 완전히 문서화되지 않은 사실입니다.

간단히 말하면, 애플리케이션을 종료하려면 스택의 모든 활동을 추적하고finish()사용자가 종료를 원할 때(아니오, 활동 스택을 반복할 방법이 없으므로 사용자가 이 모든 작업을 직접 관리해야 합니다).이 경우에도 실제로 프로세스 또는 사용자가 가지고 있을 수 있는 임의의 참조가 삭제되지는 않습니다.그것은 단순히 활동을 마칩니다.또한, 나는 확신할 수 없습니다.Process.killProcess(Process.myPid())더 잘 작동합니다. 테스트해 본 적이 없습니다.

의 스택에 남아 쉽게 : 반면스택남있아활다않되문는같지다있수니사습수매작쉽할행업을우게여하용방을법은음과에다제가면에동는이▁if▁which▁method▁super다있니수▁is▁another▁things,:▁for습▁makes▁there.Activity.moveTaskToBack(true)프로세스를 백그라운드에서 실행하고 홈 화면을 표시합니다.

긴 대답은 이 행동 뒤에 숨겨진 철학에 대한 설명을 포함합니다.이 철학은 다음과 같은 여러 가지 가정에서 비롯됩니다.

1. 우선, 이것은 앱이 전면에 있을 때만 발생합니다.백그라운드에서 실행되는 경우 프로세스가 정상적으로 종료됩니다.그러나, 만약 그것이 전경에 있다면, OS는 사용자가 자신이 하던 일을 계속하고 싶어한다고 가정합니다. (DDMS에서 프로세스를 죽이려는 경우, 홈 버튼을 먼저 누른 다음 죽이십시오.)
2. 또한 각 활동이 다른 모든 활동과 독립적이라고 가정합니다.예를 들어 앱이 완전히 별개의 사용자가 작성하지 않은 브라우저 활동을 시작하는 경우 이는 종종 사실입니다.브라우저 활동은 매니페스트 특성에 따라 동일한 작업에 작성될 수도 있고 작성되지 않을 수도 있습니다.
3. 각활복완독즉삭수며가있/구될합니다정다고제이립적동싫많 (는 오히려 이 . 제 , (저는 (저의 앱은) 동안 될 수 없기 입니다.)onSaveInstanceState하지만 어떻게 할 겁니까?)잘 작성된 대부분의 Android 앱의 경우 백그라운드에서 앱이 언제 종료될지 모르기 때문에 이는 사실이어야 합니다.
4. 마지막 요인은 가정이라기보다는 OS의 한계입니다. 앱을 명시적으로 죽이는 것은 앱이 충돌하는 것과 같고 Android가 메모리를 회수하기 위해 앱을 죽이는 것과 같습니다.이것은 우리의 성공적인 결과입니다. Android는 앱이 종료되었는지, 충돌했는지, 백그라운드에서 삭제되었는지 구분할 수 없기 때문에 사용자가 중단된 위치로 돌아가기를 원한다고 가정하고 Activity Manager가 프로세스를 다시 시작합니다.

생각해보면, 이것은 플랫폼에 적합합니다.첫째, 프로세스가 백그라운드에서 종료되고 사용자가 프로세스로 돌아오면 바로 이 작업이 수행되므로 프로세스가 중단된 곳에서 다시 시작해야 합니다.둘째, 앱이 충돌하여 무서운 Force Close 대화 상자를 표시할 때 발생합니다.

사용자가 사진을 찍어서 업로드할 수 있도록 합니다.활동에서 카메라 활동을 시작하고 이미지를 반환하도록 요청합니다.카메라가 자체 작업에서 생성되지 않고 현재 작업의 맨 위로 푸시됩니다.카메라에 오류가 발생하여 충돌이 발생하면 전체 앱이 충돌해야 합니까?사용자의 관점에서 카메라만 실패했으며 카메라는 이전 활동으로 돌아가야 합니다.따라서 카메라를 제외한 스택의 모든 동일한 활동으로 프로세스를 다시 시작합니다.활동은 즉시 삭제 및 복원할 수 있도록 설계되어야 하므로 문제가 되지 않습니다.불행하게도, 모든 앱이 그런 식으로 설계될 수 있는 것은 아니기 때문에, 로메인 가이나 다른 누군가가 당신에게 무엇을 말하든, 우리 중 많은 사람들에게 문제가 됩니다.그래서 우리는 해결책을 사용해야 합니다.

자, 마지막 조언입니다.

• 프로세스를 끝내려고 하지 마십시오. 하세요.finish()모든 활동 또는 방문 시moveTaskToBack(true).
• 프로세스가 중단되거나 중단된 경우, 그리고 저처럼 메모리에 저장되어 있던 데이터가 손실된 경우에는 루트 작업으로 돌아가야 합니다., 은 이를위합니다해야를화에 전화해야 .startActivity()가 .Intent.FLAG_ACTIVITY_CLEAR_TOP 깃발
• Eclipse DDMS 관점에서 앱을 종료하려면 앱이 전경에 없는 것이 좋습니다. 그렇지 않으면 앱이 자동으로 다시 시작됩니다.홈 버튼을 먼저 누른 다음 프로세스를 종료해야 합니다.

모든 프로그램이 종료되었습니다...그리고 그것 때문에 사용자들로부터 긍정적인 평가를 자주 받습니다.플랫폼이 애플리케이션에서 필요로 하지 않는 방식으로 설계되었든 상관 없습니다."그들을 거기에 두지 마세요"라고 말하는 것은 말도 안 됩니다.사용자가 종료하려는 경우...저는 그들에게 정확히 그것을 할 수 있는 접근권을 제공합니다.안드로이드가 작동하는 방식을 전혀 줄이지 않고 좋은 관행처럼 보입니다.생명의 주기를 이해합니다그리고 제가 관찰한 바로는 안드로이드가 이 문제를 잘 처리하지 못한다는 것입니다. 그것은 기본적인 사실입니다.

애플리케이션을 단일 애플리케이션으로 생각하지 마십시오.사용자가 안드로이드 서비스를 통해 제공되는 "애플리케이션" 및 "기능"과 상호 작용할 수 있는 UI 화면 세트입니다.

여러분의 신비한 앱이 무엇을 하는지 모르는 것은 정말 중요하지 않습니다.예를 들어 슈퍼 보안 회사 인트라넷에 터널링하여 모니터링 또는 상호 작용을 수행하고 사용자가 "애플리케이션을 종료"할 때까지 로그인 상태를 유지한다고 가정합니다.IT 부서에서 명령하기 때문에 사용자는 인트라넷에 들어가거나 나갈 때 매우 주의해야 합니다.따라서 사용자가 "종료"하는 것이 중요하다는 당신의 생각이 있습니다.

이것은 간단합니다.알림 표시줄에 "Intranet에 있거나 실행 중입니다."라는 지속적인 알림을 표시하는 서비스를 만듭니다.해당 서비스가 애플리케이션에 필요한 모든 기능을 수행하도록 하십시오.사용자가 "애플리케이션"과 상호 작용하는 데 필요한 UI 비트에 액세스할 수 있도록 해당 서비스에 바인딩되는 활동을 수행합니다.Android Menu -> 종료(또는 로그아웃 등) 버튼을 사용하여 서비스를 종료하도록 지시한 다음 활동 자체를 종료합니다.

이것은 모든 면에서 당신이 원하는 것을 정확히 말해주는 것입니다.안드로이드 방식으로 했습니다.이러한 "출구"가 가능한 사고방식의 예를 보려면 Google Talk 또는 Google Maps Navigation을 보십시오.유일한 차이점은 활동에서 뒤로 버튼을 누르면 사용자가 응용 프로그램을 다시 시작하려는 경우를 대비하여 UNIX 프로세스가 대기 상태로 유지될 수 있다는 것입니다.이는 최근 액세스한 파일을 메모리에 캐시하는 최신 운영 체제와 다를 바 없습니다.Windows 프로그램을 종료한 후에도 필요한 리소스가 메모리에 남아 다른 리소스가 로드되어 더 이상 필요하지 않을 때까지 대기합니다.Android도 마찬가지입니다.

저는 당신의 문제를 정말 이해가 안 가요.

이것은 매우 많은 전문가들이 참여한 흥미롭고 통찰력 있는 토론입니다.이 게시물은 안드로이드 OS의 핵심 디자인 중 하나를 중심으로 하기 때문에 안드로이드 개발 메인 웹사이트 내에서 루프백되어야 한다고 생각합니다.

저는 또한 여기에 제 2센트를 추가하고 싶습니다.

지금까지 저는 Android의 라이프사이클 이벤트 처리 방식에 감명을 받아 네이티브 앱에 웹과 같은 경험을 제공했습니다.

하지만 여전히 버튼이 있어야 한다고 생각합니다. 왜죠? 저나 테드, 여기 있는 기술자들을 위한 것이 아니라 최종 사용자의 요구를 충족시키기 위한 유일한 목적입니다.

저는 Windows의 열렬한 팬은 아니지만, 오래 전에 대부분의 최종 사용자들이 익숙한 개념(X 버튼)을 도입했습니다."'내가'하고 싶을 때 위젯 실행을 중단하고 싶습니다."

그렇다고 누군가(OS, 개발자?)가 알아서 처리한다는 뜻은 아닙니다.단순히 "익숙한 내 Red X 버튼이 어디에 있는지"를 의미합니다.내 작업은 '버튼을 누르면 통화 종료', '버튼을 눌러 장치 끄기' 등과 유사해야 합니다.그것은 인식입니다.나의 행동이 정말로 목적을 달성했다는 것 자체가 만족감을 가져다줍니다.

개발자는 여기에 제시된 제안을 사용하여 이러한 동작을 스푸핑할 수 있지만, 애플리케이션은 최종 사용자의 요구에 따라 독립적이고 신뢰할 수 있는 중립적인 소스(OS)에 의해 완전히 작동을 중지해야 한다는 인식은 여전히 남아 있습니다.

버튼을 누르거나 전화를 걸어 종료할 수 있습니다.finish()의 신의에Activity 전화해요.그냥 전화하세요.finish()에서.MenuItem당신이 분명히 그것을 죽이고 싶다면요.

Romain은 그럴 수 없다고 말하는 것이 아닙니다. 단지 의미가 없기 때문입니다. 애플리케이션 라이프사이클이 작동하는 방식이 어떤 일이 발생하더라도 자동으로 상태를 저장하고 복원하는 스마트 소프트웨어를 작성하도록 장려하기 때문에 사용자는 작업을 중단하거나 저장하는 것에 신경 쓸 필요가 없습니다.

이 논쟁은 개발자가 가장 잘 알고 있는지 아니면 사용자가 가장 잘 알고 있는지에 대한 오래된 질문으로 귀결됩니다.인적 요소의 모든 분야에 있는 전문 디자이너들은 매일 이것에 어려움을 겪고 있습니다.

테드는 시장에서 가장 많이 다운로드되는 앱 중 하나가 '앱 킬러'라는 점을 분명히 했습니다.사람들은 애플리케이션을 그만둘 때 약간의 추가 세로토닌을 얻습니다.그들은 데스크톱/노트북에 익숙합니다.그것은 일을 빠르게 진행시킵니다.이것은 프로세서의 온도를 낮추고 팬이 켜지지 않게 합니다.전력을 덜 사용합니다.

모바일 장치가 훨씬 작은 배라는 것을 고려할 때, 여러분은 특히 더 이상 필요하지 않은 것을 밖으로 버리려는 그들의 동기를 높이 평가할 수 있습니다.이제 Android의 개발자들은 OS가 가장 잘 알고 있으며 앱을 종료하는 것은 오래된 일이라고 추론했습니다.저는 진심으로 이것을 지지합니다.

하지만, 비록 그 좌절이 그들 자신의 무지에서 비롯된 것일지라도, 저는 또한 사용자를 좌절시켜서는 안 된다고 생각합니다.이러한 이유로, 저는 보기를 닫는 것 이상의 기능을 하지 않는 위약 버튼이 대부분일지라도 '종료' 옵션을 갖는 것이 좋은 설계라고 결론짓습니다.

테드, 당신이 성취하고자 하는 것은 성취될 수 있습니다. 아마도 당신이 지금 그것을 생각하는 방식이 아닐 것입니다.

활동 및 서비스에 대해 자세히 읽어보시기 바랍니다."app"이라는 용어 사용을 중단하고 구성 요소를 참조하기 시작합니다.활동, 서비스.당신은 안드로이드 플랫폼에 대해 더 많이 배우면 된다고 생각합니다. 그것은 표준 PC 앱에서 사고방식을 바꾸는 것입니다.귀하의 게시물에 "활동"이라는 단어(FAQ 인용문의 줄임말, 즉 귀하의 단어가 아님)가 없다는 사실은 귀하가 좀 더 읽어야 한다는 것을 의미합니다.

블로그 게시물 안드로이드 앱에 종료 버튼을 포함할 때(힌트: 네버)는 제가 할 수 있는 것보다 훨씬 더 잘 설명합니다.모든 안드로이드 개발자들이 이미 읽었으면 좋겠습니다.

발췌:

제 경험상 [사용자]가 진정으로 원하는 것은 애플리케이션이 리소스(배터리, CPU 사이클, 데이터 전송 등) 소비를 중단할 것을 보장하는 명확한 방법입니다.

많은 사용자가 종료 단추가 이 요구 사항을 구현한다고 인식하고 추가를 요청합니다.사용자를 만족시키기 위해 개발자들은 의무적으로 하나를 추가합니다.그 직후 그들은 둘 다 실패했습니다.

• 대부분의 경우 종료 버튼은 단순히 호출합니다.Activity.finish()이는 뒤로 버튼을 누르는 것과 정확히 같습니다.맞아요.서비스가 계속 실행되고 폴링이 계속 발생합니다.사용자들은 그들이 앱을 죽였다고 생각할 수 있지만, 그들은 그렇지 않을 것이고, 곧 그들은 훨씬 더 짜증이 날 것입니다.
• 이제 종료 동작이 모호합니다.종료 단추를 눌러 활동을 닫아야 합니까? 아니면 관련된 모든 서비스, 수신기 및 경보도 중지해야 합니까?어떻게 해야 할까요?만약 그들이 대신 치면 어떻게 될까요?앱에 위젯이 있으면 어떻게 됩니까?종료 버튼도 업데이트를 중지해야 합니까?

해결책은 뒤로 단추를 종료 단추가 예상대로 작동하도록 하는 것입니다.더 좋은 것은 앱이 보이지 않을 때마다 리소스 사용을 중단하는 것입니다.

계속해서 전체 기사를 읽어 보십시오.

답변: (로메인 가이):사용자는 그렇지 않습니다. 시스템은 자동으로 이 작업을 처리합니다.활동 라이프사이클(특히 Pause/onStop/onDestroy)의 목적이 바로 여기에 있습니다.당신이 무엇을 하든, "종료" 또는 "종료" 응용프로그램 버튼을 넣지 마십시오.그것은 안드로이드의 애플리케이션 모델에서는 쓸모가 없습니다. 이는 또한 핵심 애플리케이션이 작동하는 방식과도 반대됩니다.

1: 응용 프로그램을 완전히 종료하는 것은 일반적으로 필수 사항일 수 있지만, 쓸모없는 것은 아닙니다.만약 창에 종료 옵션이 없다면요?메모리가 가득 차 있고 OS가 어떤 프로그램으로 완료되었는지 추측해야 하므로 시스템이 느려질 수 있습니다.나는 Romain Guy나 심지어 Larry Page와 Sergey Brin이 뭐라고 말하든 상관하지 않습니다 - 이것들은 의심할 여지가 없는 사실입니다.새 앱을 시작하기 전에 메모리를 확보하기 위해 작업을 중지해야 할 경우 시스템 실행 속도가 느려집니다.앱을 종료하는 데 시간이 걸리지 않는다고 말할 수는 없습니다!먼 별에서 오는 빛조차도 시간이 걸립니다...사용자가 앱을 완전히 닫을 수 있도록 하는 데는 몇 가지 유용성이 있습니다.

2: 핵심 애플리케이션의 작동 방식과 반대입니까?무슨 말을 하려는 거에요?일단 앱 실행이 끝나면 앱이 더 이상 작동하지 않습니다...메모리가 필요할 때 OS에 의해 죽기만을 기다리고 있습니다.

요약하자면, 최소화와 종료 사이에는 뚜렷한 차이가 있으며, 두 핀치 모두 상대방에게 잘 맞지 않습니다.우리는 모든 나사에 드라이버를 남겨두나요?아니면 모든 문에 열쇠가 있나요?차단기가 터지고 다른 기기를 켜야 할 때까지 모든 가전제품을 높게 켜두나요?식기세척기를 접시로 가득 채우고, 매번 새로운 더러운 것들을 위한 공간을 만들기 위해 충분한 양만 꺼내놓나요?우리는 모든 차들을 진입로에 세워두고 -- 아, 신경쓰지 마세요.

사용자가 앱을 최소화하려면 가장 좋은 방법은 앱을 최소화하는 것입니다.사용자가 앱을 종료하려면 종료하는 것이 가장 좋습니다.

찡그렸나요?그것은 Android의 견해입니다. 그들은 눈살을 찌푸립니다.그리고 많은 독립 신인 Android 개발자들은 그것에 대해 눈살을 찌푸립니다.

하지만 결국 좋은 코딩과 나쁜 코딩이 있습니다.좋은 프로그램 흐름 모델과 나쁜 프로그램 흐름 모델이 있습니다.

사용자가 프로그램을 다 사용했다는 것을 알고 있을 때 프로그램을 메모리에 남겨두는 것은 좋은 프로그램 흐름이 아닙니다.그것은 전혀 목적이 없으며, 새로운 앱을 시작하거나 앱을 실행할 때 더 많은 메모리를 할당할 때 속도가 느려집니다.

그것은 당신의 차와 같은 것입니다.정지 신호에서 멈추거나, 패스트푸드가 통과하거나, 현금 자동 인출기에서 멈추는 것과 같은 경우가 있습니다.하지만 직장에 출근할 때나 식료품점, 심지어 집에 갈 때와 같이 전원을 차단하고 싶은 다른 상황들이 있습니다.

마찬가지로, 게임을 하고 있는데 전화벨이 울리면 그렇습니다.게임을 일시 중지하고 계속 실행합니다.하지만 사용자가 잠시 게임을 마친 경우에는 반드시 종료하도록 합니다.

일부 응용 프로그램의 종료 단추는 다른 응용 프로그램보다 앞쪽에 더 있어야 합니다.예를 들어 게임이나 사용자가 완전히 종료할 가능성이 있는 프로그램은 명백한 종료가 있어야 합니다.전자 메일 프로그램과 같은 다른 프로그램(이메일을 계속 확인할 수 있도록)은 종료하기를 원하지 않습니다. 이러한 프로그램은 종료 옵션이 있는 기본 제어 입력 화면 공간을 낭비하지 않아야 하지만, 좋은 프로그램 흐름을 위해서는 종료 옵션이 있어야 합니다.만약 누군가가 그들의 메일 프로그램이 그들이 열악한 커버리지 지역에 있을 때, 혹은 아마도 스카이프 통화 중이거나 무엇이든 간에 이메일을 확인하는 것을 원하지 않는다고 결정한다면 어떻게 될까요?그들이 원한다면 이메일 프로그램을 종료하도록 하라!

일시 중단과 종료는 두 가지 중요한 작업이며 다른 작업의 역할을 수행하지도 않습니다.

데이터/연결(및 "애플리케이션")을 지속적으로 유지하는 방법을 파악할 수 없다면 Android로 "필요한" 작업을 수행할 수 없습니다.

이 귀여운 작은 앱 킬러들을 다운로드하는 사람들은 보통 그것들이 배터리 수명이나 메모리 사용에 도움이 되지 않지만 OS가 메모리를 효율적으로 관리하는 것을 방해한다는 것을 알게 됩니다.

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

버그가 있는 소프트웨어가 아니면 앱을 종료할 필요가 없다는 것이 포인트라고 생각합니다.사용자가 앱을 사용하지 않고 단말기에 메모리가 더 필요할 때 안드로이드는 앱을 종료합니다.백그라운드에서 서비스를 실행해야 하는 앱이 있는 경우 서비스를 끄는 방법을 원할 수 있습니다.

예를 들어, 앱이 보이지 않을 때 Google Listen은 팟캐스트를 계속 재생합니다.그러나 사용자가 팟캐스트를 마치면 항상 일시 중지 버튼이 있습니다.제 기억이 맞다면, 들어보세요. 알림 표시줄에 바로 가기를 입력하여 항상 일시 중지 단추로 빠르게 이동할 수 있습니다.또 다른 예는 인터넷에서 서비스를 지속적으로 폴링하는 트위터 앱과 같은 앱입니다.이러한 유형의 앱을 사용하면 사용자가 서버를 폴링할 빈도를 선택하거나 백그라운드 스레드에서 폴링할지 여부를 선택할 수 있습니다.

종료 시 실행되는 코드가 필요한 경우 Pause(), onStop() 또는 Destroy()에 대해 적절히 재정의할 수 있습니다.http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

저는 애디슨 웨슬리가 출판한 "안드로이드 무선 애플리케이션 개발"을 읽는 것을 고려하고 싶습니다.나는 그것을 막 끝내고 있고 그것은 매우 철저합니다.

당신은 안드로이드 플랫폼에 대해 근본적인 오해를 하고 있는 것 같습니다.저도 처음에는 안드로이드 앱의 애플리케이션 라이프사이클에 약간 실망했지만, 더 많은 것을 이해한 후에 이 접근 방식을 정말 좋아하게 되었습니다.이 책은 당신의 모든 질문과 그 이상의 질문에 답할 것입니다.이것은 제가 새로운 안드로이드 개발자들을 위해 찾은 최고의 자원입니다.

또한 기존 앱의 회선 포트를 놓아야 할 것 같습니다.응용프로그램을 Android 플랫폼으로 이식하기 위해 응용프로그램 설계 중 일부가 변경될 것입니다.모바일 장치는 데스크톱 시스템에 비해 리소스가 매우 제한적이며 Android 장치가 여러 애플리케이션을 질서정연하고 리소스를 인식하는 방식으로 실행할 수 있기 때문에 사용되는 애플리케이션 라이프사이클이 필요합니다.플랫폼에 대해 좀 더 깊이 연구하면, 당신이 원하는 것이 완전히 실현 가능하다는 것을 깨닫게 될 것이라고 생각합니다.행운을 빌어요.

그건 그렇고, 저는 결코 애디슨 웨슬리나 이 책과 관련된 어떤 사람이나 단체와도 관계가 없습니다.제 게시물을 다시 읽은 후에 저는 제가 약간 팬보이처럼 변했다고 느낍니다.저는 정말 정말 즐거웠고 매우 도움이 되었습니다.:)

거의 99%의 시간이 Android 애플리케이션이 자체 수명 주기를 대신할 필요가 없습니다.대부분의 경우 애플리케이션을 더 잘 계획하거나 더 스마트하게 설계해야 합니다.예를 들어 다운로드 등을 처리할 내부 서비스(내보내지 않음)를 구축하거나 사용자 워크플로우를 중심으로 작업 및 작업을 설계합니다.

하지만 말하자면, 의지가 있는 곳에는 방법이 있습니다.Android는 Android.os를 통해 제공합니다.기본 프로세스를 제어하기 위한 Java보다 훨씬 우수한 API인 프로세스 클래스.그리고 자바와 달리 개발자를 단순한 java.lang 뒤에 모두 숨겨 바보 취급을 하지 않습니다.System.Exit() 호출입니다.

그렇다면 안드로이드에서 애플리케이션에 자살을 어떻게 요청합니까?비결은 간단합니다.

표준 Android.app에서 상속하여 자신만의 Android 응용 프로그램 클래스를 만듭니다.응용 프로그램 클래스(AndroidManifest.xml 파일에서 선언해야 함).

onCreate() 메서드를 재정의하고 응용 프로그램을 시작한 프로세스 ID를 저장합니다.

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

이제 응용 프로그램을 종료하려면 kill() 방법을 제공합니다.

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

이제 자살하기 위해 앱이 필요할 때마다 애플리케이션 컨텍스트를 입력하고 킬 방법을 호출하십시오!

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

Android의 프로세스 관리 정책, 특히 서비스와 관련된 정책 때문에 Android는 서비스를 다시 시작하는 것을 선택할 수 있습니다(Android에서는 태스크 킬러를 사용하면 안 됩니다 참조).

Android에서 응용 프로그램을 구상할 때 다음과 같이 봅니다.

• 응용 프로그램으로 작업 중입니다.
• 전화벨이 울렸습니다.
• 전화를 받으십시오.
• 통화가 끝나면 이전과 동일한 위치에 있는 애플리케이션으로 돌아갑니다.

이렇게 하려면 전화기의 단추 또는 단추(짧게 누르거나 길게 누름)와 알림 표시줄만 있으면 됩니다.

응용프로그램을 종료할 때는 종료될 때까지 단추를 사용하거나 단추를 사용합니다.

저는 대부분의 응용 프로그램들이 그렇게 생각합니다.그러나 세션이나 연결이 필요한 경우 로그인/로그아웃 버튼과 알림(타이틀바 등)을 사용하여 사용자에게 명확히 설명했습니다.이것은 순수한 "종료" 스타일 애플리케이션과는 다소 다른 스타일입니다.

PC에서는 다중 GUI 데스크톱이 있고 Android에서는 다중 데스크톱이 있지만 한 번에 하나의 앱만 표시합니다(여기서는 위젯은 고려하지 않습니다^^).그리고 휴대전화에서는 언제든지 자신이 하고 있는 것보다 더 중요한 것에 대한 알림을 받을 수 있습니다.

따라서 응용프로그램의 전체 개념은 "응용프로그램 입력 - 작업 - 응용프로그램 종료"라는 다른 개념에 의존합니다.

음...

저는 당신이 안드로이드 앱을 제대로 보지 못한다고 생각합니다.여러분은 여러분이 원하는 것과 거의 비슷한 것을 쉽게 할 수 있습니다.

• 개발자 라이브사이클 설명서에서 권장하는 것처럼 앱 활동 상태 저장/복원을 수행합니다.

• 복원 단계에서 일부 로그인이 필요한 경우(사용 가능한 로그인/세션 정보가 없음) 이 작업을 수행합니다.

• 합니다. 이 에는 " " " "/ "/ "/ " " " 를 합니다. " " 를 실행합니다.finish()로그인 및 기타 세션 정보를 저장하지 않고 앱 세션을 암시적으로 종료합니다. 따라서 앱이 다시 시작/앞으로 이동하면 새 세션이 시작됩니다.

그렇게 하면 앱이 메모리에서 정말 제거되는지 여부에 대해 별로 신경 쓰지 않습니다.

만약 당신이 정말로 메모리에서 그것을 제거하고 싶다면 (이것은 권장되지 않으며, BTW는 어떤 목적으로?)당신은 그것을 마지막에 조건부로 죽일 수 있습니다.onDestroy()와 함께java.lang.System.exit(0) 아마도).restartPackage(..) "합니다. ?). 물론 "앱을 정말 종료"하고 싶은 경우에만 수행합니다. 왜냐하면onDestroy()는 일반적인 활동 라이프사이클의 일부이며 전혀 추가되지 않습니다.

Android 환경에서 응용프로그램은 모호하게 관련된 여러 활동에 불과하므로 응용프로그램을 종료하는 것은 그다지 의미가 없습니다.활동을 완료할 수 있으며() 활동 스택의 이전 활동 보기가 그려집니다.

저는 테드의 의견에 동의합니다.애플리케이션을 종료하는 것이 "안드로이드 방식"이 아니라는 것은 이해하지만, 배제되어야 할 것 같지는 않습니다.활동뿐만 아니라 응용프로그램의 실제 종료를 원하는 세 가지 이유는 다음과 같습니다.

1. 사용자는 메모리가 부족한 경우 어떤 앱이 삭제되는지 제어하기를 원할 수 있습니다.중요한 A 앱이 백그라운드에서 실행되고 있다면, A 앱이 운영 체제에 의해 죽지 않도록 앱 B를 종료하는 것이 좋습니다.

2. 응용 프로그램에 중요한 데이터가 메모리에 캐시되어 있으면 바이러스/웜/로그 응용 프로그램이 액세스할 수 없도록 응용 프로그램을 종료할 수 있습니다.보안 모델이 그걸 막는다는 건 알지만, 혹시 모르니까...

3. 응용 프로그램이 전화기에 악영향을 미칠 수 있는 리소스(예: 네트워크, CPU, 센서 등)를 사용하는 경우 이러한 리소스를 확보하는 한 가지 방법은 응용 프로그램을 종료하는 것입니다.저는 잘 작동하는 앱이 필요하지 않을 때 자원을 확보해야 한다는 것을 이해합니다.그러나 애플리케이션을 종료하는 것은 이를 보장하는 합리적인 방법인 것 같습니다.

시간이 지나면서 상황이 바뀌기를 바랍니다.사용자는 앱 프로세스가 OS에 의해 올바르게 샌드박스 처리된 경우 앱 또는 프로세스를 종료할 수 있어야 합니다.앱을 완벽하게 작성해야 한다는 개념이 있습니다. 그렇지 않으면 사용자는 모든 SDK 권장 사항을 따르는 앱만 사용할 것입니다.저는 그것이 어려운 주문이라고 생각합니다.

Linux 커널에는 메모리 부족 킬러라는 기능이 있습니다(위에서 언급했듯이 정책은 사용자 공간 수준에서 구성할 수 있으며 커널은 최적의 정책이 아니지만 불필요한 정책은 아닙니다).

Android에서 많이 사용됩니다.

• OOM 킬러는 사용자 공간을 위한 것이 아닙니다.

• Android Notes(OOM Killer Info - Android에서 OOM 기능을 구성할 수 있는 곳)

• 실제 대상에 대한 Android 포팅

다음과 같은 일부 사용자 공간 앱은 이러한 킬 앱을 지원하는 데 사용할 수 있습니다.

• 자동 살인기/Android의 내부 태스크 킬러 구성

finish() 명령에서 원하는 답을 찾은 것 같습니다.이렇게 해도 앱이 메모리에서 제거되지는 않지만 Android는 리소스가 필요할 때마다 제거되므로 명시적으로 제거하지 않아도 됩니다.

응용 프로그램 종료가 일반적으로 갖는 효과를 완전히 얻으려면 모든 작업에 대해 완료()를 호출하기 직전에 장치 부팅 후 처음 실행될 때 응용 프로그램의 상태를 일반적인 상태로 재설정해야 합니다.그런 식으로 사용자가 앱을 다시 선택하면 시뮬레이션된 "종료" 이전의 지점에서 남은 상태 없이 "새로" 실행된 것으로 나타납니다.

사용자의 작업을 저장하거나 기타 작업과 같이 "종료"에서만 수행해야 하는 몇 가지 특수 작업이 있는 경우 위 루틴의 재초기화 부분 전에 해당 작업을 수행할 수도 있습니다.

이 접근 방식을 사용하면 앱 종료를 포함한 OS 리소스 관리를 운영 체제에 맡긴다는 Android의 철학에 위배되지 않고 "종료" 명령을 사용할 수 있다는 목표를 달성할 수 있습니다.

개인적으로 안드로이드 사용자들은 앱을 다시 방문할 때 앱의 연속성을 유지하기를 기대하기 때문에 앱을 "종료"하는 방식에 익숙하지 않기 때문에 이 접근 방식을 사용하지 않을 것입니다.대신 사용자가 앱을 기본 초기 상태로 재설정하기 위해 호출할 수 있는 "클리어" 기능을 지원합니다.

한 가지 예외는 사용자가 앱을 닫기에 충분한 횟수만큼 뒤로 버튼을 눌렀을 때입니다.이러한 상황에서 사용자 측에서는 상태가 저장될 것으로 예상하지 않습니다(그리고 앱에 저장되지 않은 상태가 있는 경우, 개발자인 사용자는 저장되지 않은 데이터를 감지하여 공유 기본 설정, 파일 또는 다른 비휘발성 매체에 저장할 것인지 묻는 뒤로 버튼을 코드 처리해야 합니다).

system.exit(0) 관련:

만약 당신이 system.exit(0)을 사용하여 무례한 최종성으로 앱을 닫기로 결정한다면(예: 마지막 뒤로 버튼을 누른 결과), 나는 비록 이것이 나에게 "작동한다"고 경고할 것이고, 어떤 경우에는 내가 앱을 닫을 수 있는 유일한 방법이 그것의 흔적을 남기지 않고 앱을 닫을 수 있었던 유일한 방법이었다.당신이 이 접근법을 사용할 때 젤리빈에서 발생하는 작은 결함이 하나 있습니다.

특히, 최근 앱 목록을 사용하여 앱을 연 다음 뒤로 버튼을 사용하여 앱을 닫으면(시스템.exit(0)을 통해 닫기가 구현됨) 최근 앱 목록이 다시 표시됩니다.그런 다음 해당 목록에서 해당 앱의 항목을 눌러 이미 열려 있는 동일한 최근 앱 목록에서 다시 실행해도 응답이 없습니다.

저는 최근 앱 목록이 system.exit(0)을 사용하여 앱을 닫아서 작동하지 않게 된 당신의 앱에 대한 참조를 보유하고 있기 때문이라고 생각합니다.finish()를 사용하여 앱을 좀 더 문명적으로 닫았으면 최근 앱 목록을 새로 고칠 수 있는 방식으로 OS에 알렸을 수도 있지만 system.exit(0)은 분명히 이를 수행하지 않습니다.

최근 앱에서 앱을 열고 종료한 다음 동일하게 열려 있는 최근 앱 목록에서 즉시 다시 여는 사용자는 극히 드물기 때문에 그 자체로 큰 문제는 아닙니다.그리고 그들이 홈 버튼을 누른 다음 최근 앱 목록을 다시 열면, 당신의 앱의 항목이 거기에 있을 것이고, 그것은 완전히 작동할 것입니다.하지만 system.exit(0)의 사용이 앱과 OS 간의 적절한 통신을 방해할 수 있다는 것을 보여준다고 생각합니다. 이는 이 접근 방식을 사용함으로써 다른, 더 심각한, 어쩌면 미묘한 결과가 있을 수 있음을 시사합니다.

Android 애플리케이션 수명 주기는 컴퓨터 사용자가 아닌 휴대폰 사용자를 위해 설계되었습니다.

앱 수명 주기는 리눅스 서버를 소비자 어플라이언스로 전환하는 데 필요한 잔인할 정도로 단순한 패러다임입니다.

Android는 실제 크로스 플랫폼 서버 OS인 Java over Linux입니다.그것이 그렇게 빨리 퍼지는 방법입니다.앱 수명 주기는 OS의 기본 현실을 요약합니다.

모바일 사용자에게는 앱이 설치된 것이나 설치되지 않은 것입니다.실행 또는 종료 개념은 없습니다.사실 앱 프로세스는 OS가 보유한 리소스에 대해 앱 프로세스를 릴리스할 때까지 실행됩니다.

이것은 스택 오버플로이므로, 이것을 읽는 사람은 누구나 컴퓨터 사용자이며 모바일 앱 라이프사이클을 이해하려면 지식의 90%를 꺼야 합니다.

"출구" 문제를 해결할 수 있는 (상대적으로) 간단한 디자인이 있습니다.앱을 빈 화면인 "기본" 상태(활동)로 만듭니다.활동 만들기의 첫 번째 단계에서 앱의 주요 기능이 있는 다른 활동을 시작할 수 있습니다.그런 다음 두 번째 활동을 끝내고 빈 화면 아래로 돌아가 "종료"를 수행할 수 있습니다.OS는 원하는 만큼 이 빈 화면을 메모리에 저장할 수 있습니다.

본질적으로, 당신은 OS로 나갈 수 없기 때문에, 당신은 단순히 스스로 만들어낸 무(無)로 변신합니다.

응용프로그램 개발자가 자신의 응용프로그램을 종료할 수 있는 종료 기능이 없으면 매우 나쁜 설계입니다.

내 애플리케이션은 사용자가 런타임 중에 동적으로 데이터를 변경할 수 있도록 허용해야 하고 변경을 적용하려면 사용자가 내 애플리케이션을 다시 시작해야 하지만 안드로이드는 내 애플리케이션 자체를 다시 시작할 수 없도록 했습니다.Android OS는 설계 애플리케이션 수명 주기가 매우 좋지 않습니다.

에서 앱을 언든지앱수있다니습닫을 사용합니다.FLAG_ACTIVITY_CLEAR_TOP에 의로플지정한다음래그도▁flag.system.exit();

또는 비슷한 방법이 있지만, 그렇지 않은 경우.system.exit()종료하려면 다음 메소드를 호출합니다.

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

의 신의에서.HomeActivity.onCreate() 합니다.

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

이것은 안드로이드 라이프 사이클을 깨지 않고 작동할 것입니다.

우선 System.exit(0)을 절대 사용하지 마십시오.그것은 사람의 머리를 주먹으로 때리는 것과 같습니다!

두 번째: 저는 이 문제에 직면해 있습니다.나의 해결책을 공유하기 전에 나는 나의 생각을 공유하고 싶습니다.

저는 "종료 버튼"이 어리석다고 생각합니다.정말 정말 정말 바보같습니다.그리고 애플리케이션의 종료 버튼을 요청하는 사용자(소비자)도 어리석다고 생각합니다.그들은 OS가 어떻게 작동하고 어떻게 리소스를 관리하는지 이해하지 못합니다(그리고 훌륭한 일을 합니다).

적절한 시점과 조건에서 올바른 작업(업데이트, 저장, 푸시)을 수행하고 올바른 작업(서비스 및 수신기)을 사용하는 좋은 코드를 작성하면 꽤 잘 작동하고 아무도 불평하지 않을 것이라고 생각합니다.

하지만 그러기 위해서는 안드로이드에서 어떻게 작동하는지 연구하고 배워야 합니다.어쨌든, 이것은 사용자에게 "종료 버튼"을 제공하는 저의 솔루션입니다.

각 활동에 항상 표시되는 옵션 메뉴를 만들었습니다(이 메뉴는 수퍼 활동입니다).

사용자가 해당 버튼을 클릭하면 다음과 같이 됩니다.

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();

그래서 공유 환경설정에 앱을 삭제하고 싶은 내용을 저장하고 인텐트를 시작합니다.이 플래그들을 보십시오. 그러면 "집" 활동인 DashBoard 활동을 호출하는 모든 백스택이 지워집니다.

그래서 대시보드 활동에서 다음 방법을 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();
    }
}

그리고 그것은 꽤 잘 작동할 것입니다.

왜 이런 일이 일어나는지 이해할 수 없는 유일한 이유는 마지막 피니시를 수행했을 때(그리고 확인한 바에 따르면 Pause → onStop → onDestroy의 모든 올바른 흐름을 따르고 있음) 애플리케이션이 여전히 최근 활동에 남아 있다는 것입니다(그러나 비어 있음).

대시보드 활동을 시작한 최신 의도가 아직 시스템에 있는 것 같습니다.

저는 그것도 제거하기 위해 더 파야 합니다.

이 Q&A를 읽는 데 반-적절한 Android 애플리케이션 라이프사이클을 실제로 구현하는 것보다 시간이 더 걸렸습니다.

포인트를 폴링하고 몇 초마다 스레드를 사용하여 현재 위치를 웹 서비스로 전송하는 GPS 앱입니다.이는 테드의 경우 업데이트를 위해 5분마다 폴링할 수 있으며, 온스톱은 테드가 너무 걱정했던 업데이트 작업을 쉽게 시작할 수 있습니다(비동기식 테드, Windows 프로그래머처럼 코드화하지 마십시오. 프로그램이 Windows 프로그램처럼 실행됩니다...).에우, 그렇게 어렵지 않아요).

는 Create 에서 Create를 포함하여 수명에 코드를 .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();
}

이 코드는 완전히 틀릴 수 있지만 작동합니다.이것은 저의 첫 안드로이드 앱 중 하나입니다.

Voila는 백그라운드에서 CPU를 사용하지 않지만 RAM에 있기 때문에 즉시 다시 열 수 있는 애플리케이션입니다(안드로이드 라이프사이클처럼 RAM을 보유하고 있지는 않지만). 앱은 항상 준비되어 있습니다. 바로 전화기입니다.애플리케이션이 RAM을 모두 사용하고 OS에서 종료할 수 없는 경우 호출음이 더 이상 울리지 않을 수 있습니다. =P 그렇기 때문에 OS가 백그라운드에서 애플리케이션을 닫을 수 있어야 합니다(애플리케이션이 리소스 호그가 아니라면 BTW가 닫히지 않습니다). 따라서 더 나은 애플리케이션을 작성합시다.

의도를 통해 다음 페이지로 이동할 때마다 다음을 사용합니다.

`YourActivityname.this.finish()`;

예:

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

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

백그라운드에서 작업이 실행되지 않도록 하고 앱을 종료하려면 다음을 사용합니다.

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

이 퇴장은 저에게 매력적으로 작용했습니다 :)

여러분은 아마도 "적절한" 컴퓨터를 위한 "적절한" 프로그램을 작성하는 데 수년을 보냈을 것입니다.당신은 안드로이드에서 프로그래밍하는 것을 배우고 있다고 말합니다.이것은 당신이 배워야 할 것들 중 하나일 뿐입니다.여러분은 수채화를 그리는데 몇 년을 보낼 수 없고 유화가 정확히 같은 방식으로 작동한다고 가정할 수 없습니다.이것은 제가 8년 전에 제 첫 앱을 만들었을 때 저에게 가장 새로운 개념이었습니다.

어떤 경우든, 당신이 당신의 애플리케이션을 종료하고 싶다면, 당신은 언제든지 전화할 수 있습니다.System.exit(0);.

언급URL : https://stackoverflow.com/questions/2033914/is-quitting-an-application-frowned-upon