응용 프로그램을 종료하는 것은 눈살을 찌푸리고 있습니까?

Android를 배우려는 시도 에서 다음을 읽었습니다 .

질문: 메뉴 옵션을 종료하지 않으면 사용자가 응용 프로그램을 종료 할 수 있습니까? 그러한 옵션이 없으면 사용자는 어떻게 응용 프로그램을 종료합니까?

답변 : (Romain Guy) : 사용자는 그렇지 않습니다. 시스템은 이것을 자동으로 처리합니다. 그것이 활동 라이프 사이클 (특히 onPause / onStop / onDestroy)의 목적입니다. 무엇을 하든지 "종료"또는 "종료"응용 프로그램 단추를 넣지 마십시오. 안드로이드의 응용 프로그램 모델에는 쓸모가 없습니다. 이것은 또한 핵심 응용 프로그램의 작동 방식과 상반됩니다.

Hehe, 내가 안드로이드 세계에서 취한 모든 단계에 대해 일종의 문제가 발생합니다 = (

분명히 Android에서 응용 프로그램을 종료 할 수는 없지만 Android 시스템은 느낌이들 때마다 앱을 완전히 파괴 할 수 있습니다. 무슨 일이야? "일반 앱"으로 기능하는 앱을 작성하는 것이 불가능하다고 생각하기 시작했습니다. 사용자가 앱을 종료하기로 결정할 때 앱을 종료 할 수 있습니다. 그것은 OS가해야 할 일이 아닙니다.

내가 만들려고하는 응용 프로그램은 Android 마켓 용 응용 프로그램이 아닙니다. 일반인의 "광범위한 사용"용 응용 프로그램이 아니며, 매우 좁은 비즈니스 분야에서 사용되는 비즈니스 응용 프로그램입니다.

실제로 Android 플랫폼 개발은 Windows Mobile 및 .NET에 존재하는 많은 문제를 해결하기 때문에 실제로 기대했습니다. 그러나 지난주에 다소 나빴습니다 ... 안드로이드를 포기할 필요는 없지만 지금은 그다지 좋지 않습니다 = (

응용 프로그램 을 실제로 종료 할 수있는 방법이 있습니까?

이것은 결국 귀하의 질문에 도달 할 것이지만, 먼저이 글을 쓰는 시점에 이미 제공된 다양한 답변에 대한 다양한 의견에서 제기 한 많은 문제를 다루고 싶습니다. 나는 당신의 마음을 바꿀 생각이 없습니다. 차라리 미래에이 글을 읽게 될 다른 사람들을위한 것입니다.

요점은 안드로이드가 앱 종료 시점을 결정할 수 없다는 것입니다. 그것은 반드시 사용자의 선택이어야합니다.

수백만의 사람들이 환경이 필요에 따라 애플리케이션을 닫는 모델에 완전히 만족합니다. 이러한 사용자는 단순히 웹 페이지를 "종료"하거나 온도 조절기를 "종료"하는 것 이상으로 Android 앱을 "종료"하는 것에 대해 생각하지 않습니다.

iPhone 사용자는 iPhone 버튼을 누르는 것이 앱이 종료 된 것처럼 느껴질 필요는 없다는 점에서 거의 동일합니다. 왜냐하면 많은 iPhone 앱은 앱이 실제로 종료 된 경우에도 사용자가 중단 한 위치를 선택하기 때문입니다 (iPhone 만 현재 한 번에 하나의 타사 앱을 허용합니다).

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

"항상 있어야하는 작업 목록"이란 무엇을 의미하는지 모르겠지만 "데이터를 장치에 푸시하는"것은 쾌적한 소설이며 어떤 경우에도 활동으로 수행해서는 안됩니다. 을 통해 예약 된 작업을 사용하여 AlarmManager최대의 안정성을 위해 데이터를 업데이트하십시오.

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

이를 다루는 많은 iPhone 및 Android 응용 프로그램이 있습니다. 일반적으로 사용자가 매번 수동으로 로그인하지 않고 로그온 자격 증명을 보유하기 때문입니다.

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

그것은 모든 운영 체제에서 실수입니다. 아시다시피, 응용 프로그램이 "종료"되는 이유는 OS가 종료되고 업데이트 프로세스가 중간에 실패하기 때문입니다. 일반적으로 이것은 좋지 않습니다. 시작시 업데이트를 확인하거나 예약 된 작업을 통해 완전히 비동기식으로 업데이트를 확인하고 종료하지 마십시오.

일부 의견은 뒤로 버튼을 눌러도 앱이 전혀 종료되지 않는다고 제안합니다 (위의 질문에서 링크 참조).

BACK 버튼을 눌러도 "앱이 종료되지 않습니다". 사용자가 BACK 버튼을 눌렀을 때 화면에 표시된 작업을 마칩니다.

사용자가 종료하고 싶을 때만 종료해야합니다. 안드로이드에서와 같이 동작하는 앱을 작성할 수 없다면, 안드로이드를 실제 앱을 작성하는 데 사용할 수 없다고 생각합니다 = (

그러면 웹 애플리케이션도 마찬가지입니다. 또는 모델을 올바르게 이해하면 WebOS (아직 게임 할 기회가 없었습니다). 이 모든 것에서 사용자는 아무것도 "종료"하지 않고 그냥 떠납니다. iPhone은 현재 한 번에 한 가지만 실행할 수 있다는 점에서 약간 다릅니다 (몇 가지 예외 제외).

응용 프로그램을 실제로 종료 할 수있는 방법이 있습니까?

다른 사람들이 말했듯이 BACK을 통해 사용자 또는을 통해 코드를 통해 finish()현재 실행중인 활동을 닫을 수 있습니다. 사용자는 일반적으로 웹 응용 프로그램을 사용하기 위해 "종료"옵션이 필요한 것보다 적절하게 작성된 응용 프로그램에 대해 다른 것을 필요로하지 않습니다.

정의상 두 응용 프로그램 환경이 동일하지 않습니다. 즉, 새로운 환경이 생겨나 고 다른 환경이 묻히면 환경의 트렌드를 볼 수 있습니다.

예를 들어 "파일"개념을 제거하려는 움직임이 커지고 있습니다. 대부분의 웹 응용 프로그램은 사용자가 파일을 생각하도록 강요하지 않습니다. iPhone 앱은 일반적으로 사용자가 파일을 생각하도록 강요하지 않습니다. Android 앱은 일반적으로 사용자가 파일을 생각하도록 강요하지 않습니다. 등등.

마찬가지로 앱을 "종료"한다는 개념을 제거하려는 움직임이 커지고 있습니다. 대부분의 웹 응용 프로그램에서는 사용자가 강제로 로그 아웃하지 않고 일정 시간 동안 사용하지 않으면 암시 적으로 사용자를 로그 아웃합니다. 안드로이드와 마찬가지로 아이폰과 웹 OS도 마찬가지다.

이를 위해서는 비즈니스 목표에 중점을두고 이전 애플리케이션 환경과 연계 된 구현 모델을 고수하지 않고 애플리케이션 설계에 더욱 중점을 둡니다. 이를 수행 할 시간이나 성향이없는 개발자는 기존의 정신 모델을 깨뜨리는 새로운 환경에 좌절 할 것입니다. 이것은 어느 환경의 결점도 아닙니다. 그 이상의 폭풍이 산을 통과하는 것이 아니라 산의 결점 이상입니다.

예를 들어 Hypercard 및 Smalltalk와 같은 일부 개발 환경에서는 응용 프로그램과 개발 도구가 하나의 설정으로 통합되었습니다. 이 개념은, 예를 들어 (응용 프로그램에, 많은 언어 확장의 외부를 잡을하지 않았다 VBA를 에 엑셀 , AutoCAD에서 리스프 ). 따라서 앱 자체에 개발 도구가 있다고 가정 한 정신 모델을 개발 한 개발자는 모델을 변경하거나 모델이 적용되는 환경으로 제한해야했습니다.

당신이 쓸 때 :

내가 발견 한 다른 지저분한 것들과 함께 Android 용 앱 개발이 일어나지 않을 것이라고 생각합니다.

그것은 당신을 위해 지금 당장 최고인 것처럼 보일 것입니다. 마찬가지로, Android에서보고 한 동일한 문제 중 일부는 웹 응용 프로그램에서도 발견 될 수 있으므로 (예 : "종료"없음) 응용 프로그램을 웹에 이식하려고 시도하지 말라고 조언합니다. 또는, 반대로, 언젠가 경우 어떻게 포트 웹에 응용 프로그램을, 당신은 웹 응용 프로그램의 흐름이 안드로이드에 대한 더 적합하다는 사실을 발견 할 수있다, 당신은 그 시간에 안드로이드 포트를 다시 방문 할 수 있습니다.

이 스레드의 미래 독자를 위해 여기에 수정 사항을 추가하고 싶습니다. 이 특별한 뉘앙스는 오랫동안 내 이해를 벗어 났으므로 아무도 같은 실수를 저 지르지 않기를 원합니다.

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

짧은 대답은 응용 프로그램을 종료하려면 스택의 모든 활동과 finish()사용자가 종료하려고 할 때 모든 활동을 추적해야한다는 것입니다 (그리고 활동 스택을 반복 할 수있는 방법이 없습니다) 따라서이 모든 것을 직접 관리해야합니다.) 이것조차도 실제로 프로세스 또는 매달려있는 참조를 죽이지는 않습니다. 단순히 활동을 마칩니다. 또한 Process.killProcess(Process.myPid())더 잘 작동 하는지 잘 모르겠습니다 . 나는 그것을 테스트하지 않았습니다.

반면에 스택에 활동이 남아있는 것이 괜찮다면 작업을 쉽게 수행 할 수있는 또 다른 방법이 있습니다. Activity.moveTaskToBack(true)프로세스를 배경으로하고 홈 화면을 표시합니다.

긴 대답은이 행동의 배경이되는 철학에 대한 설명입니다. 이 철학은 다음과 같은 여러 가정에서 나옵니다.

1. 우선, 이것은 앱이 포 그라운드에있을 때만 발생합니다. 백그라운드에 있으면 프로세스가 정상적으로 종료됩니다. 그러나 포 그라운드에있는 경우 OS는 사용자가 수행 한 작업을 계속 수행하려고한다고 가정합니다. (DDMS에서 프로세스를 종료하려는 경우 먼저 홈 단추를 누른 다음 종료해야합니다)
2. 또한 각 활동이 다른 모든 활동과 독립적이라고 가정합니다. 예를 들어 앱이 브라우저 활동을 시작하는 경우가 종종 있는데, 이는 완전히 별개이며 사용자가 작성하지 않은 것입니다. 브라우저 활동은 매니페스트 속성에 따라 동일한 작업에서 생성되거나 생성되지 않을 수 있습니다.
3. 각 활동이 완전히 자립적이며 잠시 후에 종료 / 복원 될 수 있다고 가정합니다. (내 앱에는 많은 양의 캐시 된 데이터에 의존하는 활동이 많기 때문에 너무 직렬화하기에는 너무 크지 onSaveInstanceState만 그래야 할 것입니까?) 대부분 잘 작성된 Android 앱의 경우, 앱이 백그라운드에서 언제 종료되는지 알 수 없기 때문입니다.
4. 마지막 요인은 많은 가정이 아니라 OS의 한계입니다 . 앱을 명시 적으로 종료하는 것은 앱 충돌과 동일하며 메모리를 확보하기 위해 앱을 종료하는 Android와 동일합니다. 안드로이드는 앱이 종료되었거나 백그라운드에서 종료되었는지 알 수 없기 때문에 사용자가 중단 한 곳으로 돌아 가기를 원한다고 가정하므로 ActivityManager가 프로세스를 다시 시작합니다.

당신이 그것에 대해 생각할 때, 이것은 플랫폼에 적합합니다. 첫째, 이것은 프로세스가 백그라운드에서 종료되고 사용자가 프로세스로 돌아 왔을 때 발생하는 것과 정확히 일치하므로 중단 된 위치에서 다시 시작해야합니다. 둘째, 이것은 앱이 충돌하고 무서운 강제 종료 대화 상자를 표시 할 때 발생합니다.

사용자가 사진을 찍고 업로드 할 수 있기를 원한다고 가정 해 보겠습니다. 활동에서 카메라 활동을 시작하고 이미지를 반환하도록 요청합니다. 카메라는 자신의 작업으로 생성되지 않고 현재 작업의 상단으로 푸시됩니다. 카메라에 오류가 발생하여 충돌이 발생하면 전체 앱이 중단됩니까? 사용자의 입장에서는 카메라 만 실패했으며 이전 활동으로 돌아와야합니다. 따라서 스택에서 동일한 활동을 모두 빼고 카메라를 빼고 프로세스를 다시 시작합니다. 활동 은 모자를 쓰러 뜨리면 죽이고 회복 될 수 있도록 설계 되어야 하므로 문제가되지 않습니다. 불행히도 모든 앱을 그런 식으로 디자인 할 수있는 것은 아니므로 것입니다Romain Guy 또는 다른 사람이 말한 것에 관계없이 많은 사람들에게 문제가됩니다. 따라서 해결 방법을 사용해야합니다.

따라서 닫는 조언 :

• 프로세스를 죽이려고하지 마십시오. 어느 전화 finish()의 모든 활동이나 통화 moveTaskToBack(true).
• 프로세스가 충돌하거나 종료되면 나와 같이 메모리에 있던 데이터가 필요하면 현재 손실 된 데이터가 필요한 경우 루트 활동으로 돌아 가야합니다. 이렇게하려면 플래그 startActivity()가 포함 된 인 텐트로 호출해야합니다 Intent.FLAG_ACTIVITY_CLEAR_TOP.
• Eclipse DDMS 관점에서 앱을 종료하려면 포 그라운드에 있지 않은 것이 좋거나 자체적으로 다시 시작됩니다. 먼저 홈 버튼을 누른 다음 프로세스를 종료해야합니다.

모든 응용 프로그램에는 종료 버튼이 있습니다 ... 그리고 나는 그 때문에 사용자로부터 긍정적 인 의견을 얻습니다. 플랫폼이 응용 프로그램에 필요하지 않은 방식으로 설계되었는지는 중요하지 않습니다. "그것을 거기에 두지 마십시오"라고 말하는 것은 우스운 일입니다. 사용자가 종료하고 싶다면 ... 그들에게 정확하게 그렇게 할 수있는 액세스 권한을 제공하십시오. 나는 그것이 안드로이드가 전혀 작동하는 방식을 감소시키지 않으며 좋은 습관처럼 보인다고 생각하지 않습니다. 나는 라이프 사이클을 이해합니다 ... 그리고 내 관찰은 안드로이드가 그것을 잘 처리하지 못한다는 것입니다 .... 그것은 기본 사실입니다.

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

당신의 신비한 앱이 무엇을하는지 모르는 것은 실제로 중요하지 않습니다. 보안 성이 뛰어난 회사 인트라넷으로 터널링하여 모니터링 또는 상호 작용을 수행하고 사용자가 "응용 프로그램을 종료"할 때까지 로그인 상태를 유지한다고 가정 해 봅시다. IT 부서에서 명령을하기 때문에 사용자는 인트라넷의 IN 또는 OUT에 대해 매우주의해야합니다. 따라서 사용자가 "종료"하는 것이 중요하다는 사고 방식.

이것은 간단합니다. 알림 표시 줄에 "인트라넷에 있거나 실행 중"이라는 알림을 표시하는 서비스를 만드십시오. 해당 서비스가 응용 프로그램에 필요한 모든 기능을 수행하도록하십시오. 사용자가 "응용 프로그램"과 상호 작용하는 데 필요한 UI 비트에 액세스 할 수 있도록 해당 서비스에 바인딩 된 활동이 있어야합니다. 그리고 서비스를 종료하도록 알리고 활동 자체를 닫는 Android 메뉴-> 종료 (또는 로그 아웃 또는 기타) 버튼이 있습니다.

이것은 모든 의도와 목적을 위해 정확히 당신이 원하는 것을 말합니다. 안드로이드 방식을 완료했습니다. 이 "종료"의 예는 Google 토크 또는 Google지도 내비게이션을 참조하십시오. 유일한 차이점은 활동에서 뒤로 단추를 누르면 사용자가 응용 프로그램을 부활시키려는 경우를 대비하여 UNIX 프로세스가 대기 상태에있게 될 수 있다는 것입니다. 이것은 실제로 최근에 액세스 한 파일을 메모리에 캐시하는 최신 운영 체제와 다르지 않습니다. Windows 프로그램을 종료 한 후에는 필요한 리소스가 여전히 메모리에 있으며 더 이상 필요하지 않은 다른 리소스로 대체되기를 기다리는 중입니다. 안드로이드도 마찬가지입니다.

나는 정말로 당신의 문제를 보지 못합니다.

이것은 많은 전문가들이 참여하는 흥미롭고 통찰력있는 토론입니다. 이 게시물은 Android 개발 기본 웹 사이트에서 다시 돌아 가야한다고 생각합니다 .Android OS의 핵심 디자인 중 하나를 중심으로하기 때문입니다.

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

지금까지 라이프 사이클 이벤트를 처리하는 Android의 방식에 감명을 받아 웹과 같은 경험 개념을 기본 앱에 적용했습니다.

나는 여전히 Quit버튼 이 있어야한다고 믿는다 . 왜? ... 나나 Ted 또는 여기에 기술 전문가가 아니라 최종 사용자 요구를 충족시키기위한 목적으로 만 사용됩니다.

나는 Windows의 열렬한 팬은 아니지만 오래 전부터 대부분의 최종 사용자가 (X 버튼)에 익숙한 개념을 소개했습니다 ... " '내가 원할 때 위젯 실행을 종료하고 싶습니다".

그것은 누군가 (OS, 개발자?)가 자신의 재량에 따라 그것을 처리한다는 것을 의미하지는 않습니다. 단지 "내가 익숙한 Red X 버튼은 어디에 있습니까"를 의미합니다. 내 행동은 '버튼을 누르면 전화를 끊는 것', '버튼을 누르면 장치를 끄는 것'등과 유사해야합니다 ... 등 인식입니다. 내 행동이 실제로 그 목적을 달성한다는 것은 만족스러운 결과를 가져옵니다.

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

당신은 할 수 가압에 의해 중, 종료 Back버튼 또는 호출하여 finish()당신에 Activity. 명시 적으로 종료하려면 finish()a에서 전화 MenuItem하십시오.

Romain은 할 수 없다고 말하지 않고 단지 무의미하다고 말합니다. 사용자는 응용 프로그램 수명주기가 작동하는 방식에 따라 자동으로 저장하고 저장하는 스마트 소프트웨어를 작성하도록 장려하므로 작업을 종료하거나 저장하는 데 신경 쓸 필요가 없습니다. 어떤 일이 있어도 상태를 복원합니다.

이 토론은 개발자가 가장 잘 알고 있는지 또는 사용자가 가장 잘 알고 있는지에 대한 오래된 질문으로 요약됩니다. 모든 인적 요소 영역의 전문 디자이너가 매일이 문제로 어려움을 겪고 있습니다.

Ted는 마켓에서 가장 많이 다운로드 된 앱 중 하나가 'App Killer'라고 지적했습니다. 사람들은 응용 프로그램을 종료 할 때 약간의 세로토닌을 얻습니다. 그들은 데스크탑 / 랩톱에 익숙합니다. 물건을 빠르게 움직입니다. 프로세서를 식히고 팬이 켜지지 않도록합니다. 적은 전력을 사용합니다.

모바일 장치가 훨씬 작은 선박이라고 생각하면 '더 이상 필요없는 것을 배 밖으로 던지다'는 인센티브에 특히 감사 할 수 있습니다. 이제 Android 개발자는 OS가 가장 잘 알고 있고 앱을 종료하는 것이 골동품이라고 생각했습니다. 나는 진심으로 이것을 지원합니다.

그러나 좌절감이 자신의 무지에서 벗어나더라도 사용자를 좌절시키지 않아야한다고 생각합니다. 그 때문에 '종료'옵션을 사용하는 것이보기를 닫는 것 이상을 수행하지 않는 위약 버튼 인 경우에도 좋은 디자인이라고 결론을 내 렸습니다.

테드, 당신이 이루고자하는 것은 아마도 지금 당신이 그것을 어떻게 생각하고 있는지가 아니라 수행 될 수 있습니다.

나는 당신이 활동과 서비스에 대해 읽어 볼 것을 제안합니다. "앱"이라는 용어 사용을 중단하고 구성 요소 (예 : 활동, 서비스)를 언급하십시오. 안드로이드 플랫폼에 대해 더 배우면된다고 생각합니다. 표준 PC 앱의 사고 방식의 변화입니다. 귀하의 게시물에 "Activity"라는 단어가없는 단어 (FAQ 인용 부호가 적습니다 (예 : 단어가 아님))는 더 읽어야한다는 것을 알려줍니다.

블로그 게시물 Android 앱에 종료 버튼을 포함하는시기 (힌트 : 사용 안함) 는 내가 할 수있는 것보다 훨씬 더 잘 설명합니다 . 모든 Android 개발자가 이미 읽었기를 바랍니다.

발췌 :

내 경험상 [사용자]가 실제로 원하는 것은 다음과 같습니다. 앱이 리소스 (배터리, CPU주기, 데이터 전송 등)의 소비를 중지하도록 보장하는 분명한 방법입니다.

많은 사용자가 이탈 버튼이이 요구 사항을 구현하고 추가를 요청한다고 인식합니다. 사용자를 기쁘게하려는 개발자는 반드시 추가해야합니다. 그 후 얼마 지나지 않아 둘 다 실패합니다.

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

해결책은 종료 버튼이 예상 한대로 뒤로 버튼을 작동시키는 것입니다. 더 나은 방법은 앱이 보이지 않을 때마다 리소스 소비를 중단하는 것입니다.

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

답변 : (Romain Guy) : 사용자는 그렇지 않습니다. 시스템은 이것을 자동으로 처리합니다. 그것이 활동 라이프 사이클 (특히 onPause / onStop / onDestroy)의 목적입니다. 무엇을 하든지 "종료"또는 "종료"응용 프로그램 단추를 넣지 마십시오. 안드로이드의 응용 프로그램 모델에는 쓸모가 없습니다. 이것은 또한 핵심 응용 프로그램의 작동 방식과 상반됩니다.

1 : 응용 프로그램을 완전히 종료하는 것이 일반적으로 필수는 아니지만 쓸모가 없습니다. 윈도우에 종료 옵션이 없으면 어떻게됩니까? 메모리가 가득 차서 시스템이 느리게 작동하고 OS가 어떤 프로그램을 수행했는지 추측해야했습니다. Romain Guy 또는 Larry Page와 Sergey Brin의 말에 신경 쓰지 않습니다. 의심 할 여지가없는 사실입니다. 새로운 앱을 실행하기 전에 메모리를 확보하기 위해 작업을 종료해야 할 때 시스템이 느리게 실행됩니다. 앱을 죽이는 데 시간이 걸리지 않는다고 말할 수는 없습니다! 먼 별에서조차 빛이 ... 시간이 걸릴 것입니다 완전히 가까운 응용 프로그램을 사용자에게 허용에 일부 사용.

2 : 핵심 응용 프로그램 작동 방식과 반대로? 그게 무슨 뜻이야? 지금은 응용 프로그램을 실행하면 더 이상 작업을 수행하지 않습니다. 메모리가 필요할 때 OS가 종료되기를 기다리는 중입니다.

요약하면, 최소화와 종료 사이에는 뚜렷한 차이가 있으며, 핀치도 서로 맞지 않습니다. 우리는 모든 나사에 드라이버를 남겨 두나요? 아니면 모든 문에 열쇠가 있습니까? 차단기가 끊어 질 때까지 모든 기기를 높은 상태로두고 다른 기기를 켜야합니까? 식기 세척기는 식기를 가득 채운 채로두고, 매번 새로운 더러운 것을 넣을 공간을 충분히 확보 할 수 있습니까? 우리는 모든 차를 차도에서 주행 할 때까지 두어야합니까?

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

눈살을 찌푸 리나요? 그것은 안드로이드의 관점입니다. 그들은 눈살을 찌푸 렸습니다. 그리고 많은 독립적 인 신인 안드로이드 개발자들이 그것에 눈살을 찌푸 렸습니다.

그러나 그것이 바로 올 때, 좋은 코딩과 나쁜 코딩이 있습니다. 좋은 프로그램 흐름 모델이 있고 잘못된 프로그램 흐름 모델이 있습니다.

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

그것은 마치 자동차와 같습니다 : 정지 등에서 멈추거나 패스트 푸드 드라이브를 통과하거나 ATM에서 멈추는 것과 같이 달리는 경우가 있습니다. 그러나 일을하려고 할 때나 식료품 점 또는 심지어 집과 같이 잠그고 싶은 다른 상황이 있습니다.

마찬가지로 게임을하고 있는데 전화가 울린다면 그렇습니다. 게임을 일시 정지하고 계속 실행하십시오. 그러나 사용자가 게임을 잠시 동안 끝냈다면 반드시 종료하십시오.

일부 응용 프로그램의 종료 단추는 다른 응용 프로그램보다 앞에 있어야합니다. 예를 들어, 게임 또는 사용자가 완전히 종료하고자하는 프로그램은 명백히 종료해야합니다. 종료가 바람직하지 않은 전자 메일 프로그램과 같은 다른 프로그램 (이메일을 계속 확인할 수 있도록)-이 프로그램은 종료 옵션으로 주요 제어 입력 화면 공간을 낭비하지 말고 프로그램 흐름을 좋게하기 위해 종료 옵션이 있어야합니다. 서비스 지역이 좋지 않거나 Skype 전화 등에서 메일 프로그램이 전자 메일을 확인하지 못하게하려면 어떻게해야합니까? 원하는 경우 이메일 프로그램을 종료하십시오!

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

요점은 버그가있는 소프트웨어가 없으면 앱을 종료 할 필요가 없다는 것입니다. 사용자가 사용하지 않고 기기에 더 많은 메모리가 필요한 경우 Android가 앱을 종료합니다. 백그라운드에서 서비스를 실행해야하는 앱이있는 경우 서비스를 끄는 방법이 필요할 수 있습니다.

예를 들어, 앱이 보이지 않을 때 Google Listen이 계속 팟 캐스트를 재생합니다. 그러나 사용자가 팟 캐스트를 마치면 일시 중지 버튼이 항상 있습니다. 내가 정확하게 기억한다면, 듣고, 알림 표시 줄에 바로 가기를 넣어서 언제든지 일시 정지 버튼으로 빠르게 이동할 수 있습니다. 또 다른 예는 인터넷에서 서비스를 지속적으로 폴링하는 Twitter 앱과 같은 앱입니다. 이러한 유형의 앱을 통해 사용자는 서버를 얼마나 자주 폴링 할 것인지 또는 백그라운드 스레드에서 폴링 할 것인지를 선택할 수 있습니다.

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

데이터 / 연결 (및 "응용 프로그램")을 영구적으로 만드는 방법을 알 수 없다면 Android와 관련하여 "필요한"작업을 수행 할 수 없습니다.

귀엽고 작은 App Killers를 다운로드하는 사람들은 일반적으로 배터리 수명이나 메모리 사용에 도움이되지 않지만 OS가 메모리를 효율적으로 관리하는 일을 방해한다는 것을 알게됩니다 ...

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

Addison-Wesley가 출판 한 "Android Wireless Application Development"를 읽는 것을 고려할 것 입니다. 나는 그것을 끝내고 있으며 매우 철저합니다.

Android 플랫폼에 대한 근본적인 오해가있는 것으로 보입니다. 나도 안드로이드 앱의 응용 프로그램 수명주기에 대해 약간 실망했지만, 더 잘 이해 한 후에는이 접근법을 실제로 즐기게되었습니다. 이 책은 모든 질문에 대한 답변을 제공합니다. 정말 새로운 안드로이드 개발자를 위해 찾은 최고의 리소스입니다.

또한 기존 앱의 라인 간 포트를 놓아야한다고 생각합니다. 애플리케이션을 Android 플랫폼으로 이식하기 위해 일부 애플리케이션 디자인이 변경 될 예정입니다. 모바일 장치는 데스크톱 시스템에 비해 리소스가 매우 제한되어 있으며 Android 장치가 순서대로 리소스를 인식하는 방식으로 여러 응용 프로그램을 실행할 수 있으므로 사용되는 응용 프로그램 수명주기가 필요합니다. 플랫폼에 대해 좀 더 깊이 연구하면, 원하는 것은 전적으로 실현 가능하다는 것을 알게 될 것입니다. 행운을 빌어 요.

그건 그렇고, 나는 Addison-Wesley 또는이 책과 관련된 사람이나 조직과 제휴하지 않습니다. 내 게시물을 다시 읽은 후 나는 약간 팬 보이시 한 느낌이 들었습니다. 나는 정말로, 정말로 그것을 즐기고 매우 도움이되었다는 것을 알았습니다. :)

거의 99 %의 시간에 Android 애플리케이션이 자체 수명주기를 인수 할 필요가 없습니다. 대부분의 경우 응용 프로그램을보다 효율적으로 계획하거나보다 효과적으로 설계해야합니다. 예를 들어 다운로드 등을 처리하기 위해 내부 서비스 (내보내기되지 않음)를 구축하거나 사용자 워크 플로와 관련된 작업 및 작업을 디자인합니다.

그러나 의지가있는 곳에 방법이 있습니다. Android는 android.os.Process 클래스를 통해 기본 프로세스를 제어하기 위해 Java보다 훨씬 우수한 API를 제공합니다. Java와는 달리 간단한 java.lang.System.exit () 호출 뒤에 숨겨져 개발자를 바보처럼 취급하지 않습니다.

그렇다면 애플리케이션에서 Android에서 자살을 요청하는 방법은 무엇입니까? 음, 트릭은 간단합니다.

표준 android.app.Application 클래스에서 상속하여 고유 한 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);

자살을 위해 앱이 필요할 때마다 애플리케이션 컨텍스트를 캐스트하고 kill 메소드를 호출하십시오!

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

Android의 프로세스 관리 정책, 특히 서비스와 관련된 프로세스 관리 정책으로 인해 Android는 서비스를 다시 시작하도록 선택할 수 있습니다 ( Android에서 태스크 킬러를 사용하지 않아야 함 참조 ).

Android에서 응용 프로그램을 생각하면 다음과 같이 보입니다.

• 당신은 당신의 응용 프로그램과 함께 일하고 있습니다
• 전화가 울렸다
• 당신은 전화를
• 통화가 끝날 때, 당신은 당신이 있던 곳에서 당신의 응용 프로그램으로 돌아옵니다

그렇게하려면 Back버튼이나Home 전화기 버튼 (짧거나 길게 누름)과 알림 표시 줄 됩니다.

애플리케이션을 종료 할 때 Back버튼을 사용하지 않을 때까지만 또는Home 합니다.

그것이 내가 생각하는 대부분의 응용 프로그램이 생각 된 방식입니다. 그러나 어떤 종류의 세션이나 연결이 필요하면 로그인 / 로그 아웃 버튼과 알림 (제목 표시 줄 또는 다른 것)을 사용자에게 분명히했습니다. 이것은 순수한 "종료"스타일 응용 프로그램과는 다른 스타일입니다.

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

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

흠 ...

나는 당신이 안드로이드 앱을 올바르게 보지 못한다고 생각합니다. 당신이 원하는 것과 거의 같은 것을 할 수 있습니다 :

• 개발자 활동주기 문서에서 권장하는 것처럼 앱 활동 저장 / 복원 상태를 수행하십시오.

• 복원 단계에서 일부 로그인이 필요한 경우 (사용 가능한 로그인 / 세션 정보가없는 경우) 로그인하십시오.

• 결국 버튼 / 메뉴 / 시간 초과를 추가 finish()하면 로그인 및 기타 세션 정보를 저장하지 않고 앱 세션을 암시 적으로 종료 할 수 있습니다. 따라서 앱이 시작 / 다시 시작되면 새 세션이 시작됩니다.

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

당신이 정말로 메모리에서 제거하려면 (이 어떤 목적을 위해 BTW 낙담하고있다?) 당신의 말에 조건을 죽일 수 onDestroy()와 java.lang.System.exit(0)(혹은 restartPackage(..)?). 물론 "실제로 앱을 종료"하려는 경우에만 수행해야 onDestroy()합니다. 이는 앱이 아닌 활동의 정상적인 수명주기의 일부 이기 때문 입니다.

Android 컨텍스트의 응용 프로그램은 모호하게 관련된 많은 활동이므로 응용 프로그램을 종료하는 것은 실제로 의미가 없습니다. 액티비티를 finish () 할 수 있으며 액티비티 스택에서 이전 액티비티의 뷰가 그려집니다.

Ted에 동의합니다. 응용 프로그램을 종료하는 것이 "Android 방식"이 아니라는 것을 배제해야하는 것은 아닙니다. 활동이 아닌 응용 프로그램을 실제로 종료하려는 세 가지 이유는 다음과 같습니다.

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

2. 애플리케이션에 메모리에 캐시 된 민감한 데이터가있는 경우 바이러스 / 웜 / 악성 앱이 접근 할 수 없도록 앱을 종료 할 수 있습니다. 보안 모델이 그것을 막아야한다고 생각하지만, 경우에 따라 ...

3. 애플리케이션이 전화에 부정적인 영향을 줄 수있는 리소스 (예 : 네트워크, CPU, 센서 등)를 사용하는 경우 이러한 리소스를 확보하는 한 가지 방법은 애플리케이션을 종료하는 것입니다. 잘 작동하는 앱은 필요하지 않을 때 리소스를 확보해야한다는 것을 알고 있습니다. 그러나 다시 한 번 응용 프로그램을 종료하면 합리적인 방법으로 보일 수 있습니다.

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

그리고 그것은 안드로이드에 의해 많이 사용됩니다 :

• OOM 킬러는 사용자 공간 용이 아닙니다

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

• 실제 대상에 Android 포팅

다음과 같은 킬 응용 프로그램을 지원하기 위해 일부 사용자 공간 응용 프로그램을 사용할 수 있습니다.

• 자동 킬러 / Android의 내부 작업 킬러 구성

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

나는 응용 프로그램 종료가 일반적으로 갖는 전체 효과를 얻기 위해 장치를 부팅 한 후 처음 실행했을 때의 상태로 일반적으로 응용 프로그램의 상태를 재설정하려고합니다. 모든 활동에서 finish ()를 호출합니다. 이렇게하면 사용자가 앱을 다시 선택하면 시뮬레이션 된 "종료"이전 지점에서 상태가 남지 않고 "새로"실행 된 것으로 나타납니다.

"종료"에서만 발생해야하는 작업 (예 : 사용자 작업 저장 등)이있는 경우 위의 루틴을 다시 초기화하기 전에 수행 할 수도 있습니다.

이 접근 방식을 사용하면 운영 체제에서 앱 종료를 포함하여 OS 자원 관리를 떠나는 Android의 철학을 위반하지 않고 "종료"명령을 수행 할 수 있습니다.

개인적으로 Android 사용자는 앱을 다시 방문 할 때 앱의 연속성이 유지되기를 기대하므로 앱을 "종료"하는 방식에 익숙하지 않기 때문에 개인적으로는이 방법을 사용하지 않을 것입니다. 대신 프로세스에서 앱을 "이탈"할 필요없이 사용자가 앱을 기본 초기 상태로 재설정하도록 호출 할 수있는 "클리어"기능을 지원합니다.

한 가지 예외는 사용자가 뒤로 버튼을 여러 번 눌러 앱을 종료하는 경우입니다. 이 상황에서는 사용자 측에서 상태가 저장 될 것이라는 기대가 없습니다 (앱에 저장되지 않은 상태가있는 경우 개발자는 저장되지 않은 데이터를 감지하는 뒤로 버튼을 처리하는 코드가 있어야합니다. SharedPreferences 또는 파일 또는 다른 비 휘발성 매체에 파일을 저장하라는 메시지를 표시합니다.

system.exit (0) 관련 :

system.exit (0)을 사용하여 무례한 최종성 (예 : 최종 뒤로 버튼 누름의 결과)으로 앱을 종료하기로 결정한 경우 나 에게이 "작동"하고 일부는 경고하지만 사례는 내가 남은 흔적없이 앱을 닫을 수있는 유일한 방법이었습니다.이 접근법을 사용할 때 젤리 빈에서 발생하는 사소한 결함이 있습니다.

특히 최근 앱 목록을 사용하여 앱을 연 다음 뒤로 버튼을 사용하여 앱을 닫으면 (닫은 system.exit (0)을 통해 구현 된 경우) 최근 앱 목록이 다시 표시됩니다. 닫히지 않았습니다. 그런 다음 해당 목록에서 앱의 항목을 탭하여 두 번째 로 실행하십시오 이미 열려있는 동일한 최근 앱 목록에서 응답이 없습니다.

system.exit (0)을 사용하여 앱을 닫아 최근 앱 목록이 작동하지 않는 앱에 대한 참조를 보유하고 있기 때문입니다. finish ()를 사용하여 더 문명화 된 앱을 닫으면 최근 앱 목록을 새로 고칠 수있는 방식으로 OS에 정보를 제공했을 수 있지만 system.exit (0)은이 작업을 수행하지 않습니다.

소수의 사람들이 최근 앱에서 앱을 연 다음 종료 한 다음 열려있는 동일한 최근 앱 목록에서 즉시 다시 열기 때문에 이는 큰 문제가 아닙니다. 그리고 홈 버튼을 탭한 다음 최근 앱 목록 을 다시 열면 앱의 항목이 표시되고 완전히 작동합니다. 그러나 system.exit (0)을 사용하면 앱과 OS 사이의 적절한 통신을 방해 할 수 있으며,이 접근법을 사용하면 더 심각하고 미묘한 결과가 발생할 수 있음을 알 수 있습니다.

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

"종료"수수께끼를 극복 할 수있는 (상대적으로) 간단한 디자인이 있습니다. 앱이 빈 화면 인 "기본"상태 (활동)를 갖도록합니다. 활동의 첫 번째 onCreate에서 앱의 주요 기능이있는 다른 활동을 시작할 수 있습니다. 그런 다음이 두 번째 활동을 finish ()하고 빈 화면으로 돌아가서 "종료"를 수행 할 수 있습니다. OS는 원하는만큼이 빈 화면을 메모리에 유지할 수 있습니다.

본질적으로, 당신은 OS로 나갈 수 없기 때문에, 당신은 단순히 스스로 만든 아무것도로 변형하지 않습니다.

애플리케이션 개발자가 자신의 애플리케이션을 종료 할 수있는 종료 기능이 없으면 설계가 매우 나쁩니다.

내 응용 프로그램은 사용자가 런타임 중에 동적으로 데이터를 동적으로 변경할 수 있어야하며 사용자는 변경 효과를 내기 위해 응용 프로그램을 다시 시작해야하지만 Android는 내 응용 프로그램 자체를 다시 시작하지 못했습니다. Android OS의 설계 응용 프로그램 수명주기는 매우 나쁩니다.

언제든지 앱을 닫으려면 FLAG_ACTIVITY_CLEAR_TOPIntent에서 플래그를 사용한 다음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가 어떻게 작동하고 리소스를 관리하고 있는지 이해하지 못합니다 (그리고 훌륭한 일을합니다).

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

그러나 그렇게하려면 Android에서 작동하는 방식을 연구하고 배워야합니다. 어쨌든 이것은 사용자에게 "종료 버튼"을 제공하는 솔루션입니다.

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

사용자가 해당 버튼을 클릭하면 다음과 같은 일이 발생합니다.

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

따라서 SharedPreferences에 저장하여 앱을 종료하고 인 텐트를 시작합니다. 그 깃발들을보세요; 그것들은 나의 "가정"활동 인 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();
    }
}

그리고 그것은 잘 작동합니다.

왜 그런 일이 일어나고 있는지 이해하지 못하는 유일한 것은 마지막 마무리를 수행 할 때 (그리고 확인한 : onPause → onStop → onDestroy의 모든 올바른 흐름을 따르고 있음) 응용 프로그램이 여전히 최근 활동에 있다는 것입니다 (그러나 비어 있습니다).

최신 의도 (DashboardActivity를 시작한)가 여전히 시스템에있는 것 같습니다.

나는 그것을 제거하기 위해 더 많은 것을 파야했습니다.

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

앱 수명주기는 Linux 서버를 소비자 기기로 전환하는 데 필요한 잔인하고 단순한 패러다임입니다.

Android는 실제 플랫폼 간 서버 OS 인 Linux를 통한 Java입니다. 그것이 그렇게 빨리 퍼지는 방식입니다. 앱 수명주기는 OS의 기본 현실을 캡슐화합니다.

모바일 사용자에게는 앱이 설치되었거나 설치되지 않았습니다. 달리거나 나가는 개념은 없습니다. 실제로 앱 프로세스는 OS가 보유한 리소스를 위해 프로세스를 릴리스 할 때까지 실행됩니다.

이것이 스택 오버플로이므로 이것을 읽는 사람은 컴퓨터 사용자이므로 모바일 앱 수명주기를 이해하려면 지식의 90 %를 꺼야합니다.

실제로 반 적절한 Android 애플리케이션 수명주기를 구현하는 것보다이 Q & A를 읽는 데 시간이 더 걸렸습니다.

스레드를 사용하여 포인트를 폴링하고 현재 위치를 웹 서비스에 몇 초마다 전송하는 GPS 앱입니다. 업데이트를 위해 Ted의 경우 5 분마다 폴링 할 수 있습니다. 그러면 onStop은 단순히 업데이트 활동을 시작할 수 있습니다. 하나가 발견되면 (비동기 Ted, Windows 프로그래머와 같은 코드를 작성하지 마십시오. 그렇지 않으면 프로그램이 Windows 프로그램처럼 실행됩니다 ... eww, 그렇게 어렵지 않습니다).

onCreate에서 몇 가지 초기 코드를 사용하여 활동 수명을 설정했습니다 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();
}

이 코드는 완전히 잘못되었을 수 있지만 작동합니다. 이것은 내 첫 번째 안드로이드 응용 프로그램 중 하나입니다.

Voilà, 백그라운드에서 CPU를 소비하지 않지만 RAM에 있기 때문에 즉시 다시 열 준비가 된 응용 프로그램 인 Voilà (Android 수명주기와 마찬가지로 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();

이 출구는 나를 위해 매력처럼 작동했습니다 :)

어쨌든 응용 프로그램을 종료하려면 언제든지 전화하십시오 System.exit(0);.

10,20 .. 여러 활동이 실행 중이고 모든 활동을 마치고 시스템을 종료하려는 경우.

application class또는에 정적 배열 만들기constants class.

상수

public class Constants {

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

}

MainActivity 이 배열에 현재 활동 참조 추가

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