질문자 :Community Wiki
Android를 배우려는 시도를 계속 하면서 다음을 읽었습니다 .
질문: 우리가 그것을 죽이기 위한 메뉴 옵션을 넣지 않는 한 사용자는 애플리케이션을 죽일 수 있는 선택권이 있습니까? 이러한 옵션이 없으면 사용자가 응용 프로그램을 어떻게 종료합니까?
답변: (Romain Guy): 사용자는 그렇지 않습니다. 시스템이 이를 자동으로 처리합니다. 그것이 바로 활동 수명 주기(특히 onPause/onStop/onDestroy)의 목적입니다. 당신이 무엇을 하든지 "종료"또는 "종료"응용 프로그램 버튼을 누르지 마십시오. Android의 애플리케이션 모델에서는 쓸모가 없습니다. 이는 핵심 응용 프로그램이 작동하는 방식과도 반대입니다.
헤헤, Android 세계에서 내가 한 걸음 내디딜 때마다 일종의 문제에 봉착합니다 =(
분명히 Android에서는 애플리케이션을 종료할 수 없습니다(하지만 Android 시스템은 필요할 때마다 앱을 완전히 파괴할 수 있습니다). 무슨 일이야? 사용자가 결정하면 앱을 종료할 수 있는 "일반 앱"으로 작동하는 앱을 작성하는 것은 불가능하다고 생각하기 시작했습니다. 그것은 OS에 의존해야 할 일이 아닙니다.
내가 만들려고 하는 응용 프로그램은 Android 마켓용 응용 프로그램이 아닙니다. 일반 대중의 "광범위한 사용"을 위한 애플리케이션이 아니라 매우 좁은 비즈니스 분야에서 사용될 비즈니스 앱입니다.
Android 플랫폼은 Windows Mobile 및 .NET에 존재하는 많은 문제를 해결하기 때문에 실제로 Android 플랫폼용 개발을 기대하고 있었습니다. 하지만 지난주는 저에게 다소 분기점이 되었습니다... 안드로이드를 버리지 않았으면 하는 바램이 있지만 지금은 별로 좋아보이진 않네요 =(
정말 응용 프로그램을 종료하는 방법이 있습니까?
이것은 결국 귀하의 질문에 도달할 것이지만 먼저 이 글을 쓰는 시점에 이미 제공된 다양한 답변에 대한 다양한 의견에서 제기한 여러 문제를 해결하고 싶습니다. 나는 당신의 마음을 바꿀 생각이 없습니다. 오히려 이것은 미래에 이 포스트를 읽으러 오는 다른 사람들을 위해 여기에 있습니다.
요점은 Android가 내 앱이 종료될 시기를 결정하도록 허용할 수 없다는 것입니다. 그것은 사용자의 선택이어야 합니다.
수백만 명의 사람들이 필요에 따라 환경이 애플리케이션을 닫는 모델에 완벽하게 만족합니다. 이러한 사용자는 웹 페이지를 "종료"하거나 온도 조절 장치를 "종료"하는 것에 대해 생각하는 것과 마찬가지로 Android 앱을 "종료"하는 것에 대해 생각하지 않습니다.
iPhone 사용자는 앱이 실제로 종료된 경우에도 많은 iPhone 앱이 사용자가 중단한 위치에서 선택하기 때문에 iPhone 버튼을 누르는 것이 반드시 앱이 종료된 것처럼 "느끼지"는 않는다는 점에서 거의 동일합니다(iPhone만 허용하기 때문에 현재 한 번에 하나의 타사 앱).
위에서 말했듯이 내 앱에는 많은 일들이 있습니다(기기에 푸시되는 데이터, 항상 있어야 하는 작업 목록 등).
"항상 있어야 하는 작업 목록"이 무엇을 의미하는지 모르겠지만 "장치로 푸시되는 데이터"는 유쾌한 허구이며 어떤 경우에도 활동에 의해 수행되어서는 안 됩니다. 최대 안정성을 위해 데이터를 업데이트하려면 예약된 작업( AlarmManager
우리 사용자는 로그인을 하고 전화를 받을 때마다 그렇게 할 수 없고 Android가 앱을 종료하기로 결정합니다.
이를 처리하는 많은 iPhone 및 Android 응용 프로그램이 있습니다. 일반적으로 사용자가 매번 수동으로 로그인하도록 하는 것이 아니라 로그인 자격 증명을 보유하기 때문입니다.
예를 들어 애플리케이션을 종료할 때 업데이트를 확인하고 싶습니다.
이는 모든 운영 체제에서 발생하는 실수입니다. 아시다시피 응용 프로그램이 "종료"되는 이유는 OS가 종료되고 업데이트 프로세스가 중간에 실패하기 때문입니다. 일반적으로 그것은 좋은 것이 아닙니다. 시작 시 업데이트를 확인하거나 종료 시가 아닌 완전히 비동기식으로(예: 예약된 작업을 통해) 업데이트를 확인합니다.
일부 의견은 뒤로 버튼을 눌러도 앱이 전혀 종료되지 않는다고 제안합니다(위의 내 질문에 있는 링크 참조).
BACK 버튼을 눌러도 "앱을 종료"하지 않습니다. 사용자가 BACK 버튼을 눌렀을 때 화면에 있던 활동을 종료합니다.
사용자가 종료하기를 원할 때만 종료해야 합니다. 다른 방법은 절대 사용하지 마세요. Android에서 그렇게 동작하는 앱을 작성할 수 없다면 Android는 실제 앱을 작성하는 데 사용할 수 없다고 생각합니다 =(
그러면 웹 애플리케이션도 마찬가지입니다. 또는 WebOS , 내가 그들의 모델을 올바르게 이해한다면 (아직 가지고 놀 기회가 없었습니다). 이 모든 것에서 사용자는 아무 것도 "종료"하지 않고 그냥 떠납니다. iPhone은 현재 한 번에 한 가지만 실행할 수 있다는 점에서 약간 다릅니다(몇 가지 예외 제외). 따라서 떠나는 행위는 앱의 상당히 즉각적인 종료를 의미합니다.
정말 응용 프로그램을 종료하는 방법이 있습니까?
다른 사람들이 말했듯이 사용자(BACK을 통해) 또는 코드( finish() 를 통해)가 현재 실행 중인 활동을 닫을 수 있습니다. 일반적으로 사용자는 웹 응용 프로그램을 사용하기 위해 "종료" 옵션이 필요한 것 이상으로 적절하게 작성된 응용 프로그램에 대해 다른 것이 필요하지 않습니다.
정의상 동일한 애플리케이션 환경은 없습니다. 즉, 새로운 환경이 발생하고 다른 환경은 묻힐 때 환경의 경향을 볼 수 있습니다.
예를 들어 '파일'이라는 개념을 없애려는 움직임이 커지고 있습니다. 대부분의 웹 응용 프로그램은 사용자가 파일을 생각하도록 강요하지 않습니다. iPhone 앱은 일반적으로 사용자가 파일을 생각하도록 강요하지 않습니다. Android 앱은 일반적으로 사용자가 파일을 생각하도록 강요하지 않습니다. 등등.
마찬가지로 앱을 "종료"하는 개념을 없애려는 움직임이 커지고 있습니다. 대부분의 웹 응용 프로그램은 사용자에게 강제로 로그아웃하지 않고 일정 기간 사용하지 않으면 암시적으로 사용자를 로그아웃합니다. Android도 마찬가지고 iPhone(및 WebOS도 가능)은 그보다 적습니다.
이를 위해서는 비즈니스 목표에 초점을 맞추고 이전 애플리케이션 환경에 묶인 구현 모델을 고수하지 않고 애플리케이션 설계에 더 중점을 두어야 합니다. 이를 수행할 시간이나 의향이 없는 개발자는 기존 멘탈 모델을 깨는 새로운 환경에 좌절할 것입니다. 이것은 어느 환경의 잘못도 아니며, 산을 통하지 않고 주위를 흐르는 폭풍에 대한 산의 잘못입니다.
예를 들어, Hypercard 및 Smalltalk와 같은 일부 개발 환경에는 애플리케이션과 개발 도구가 하나의 설정으로 혼합되어 있었습니다. 이 개념은 앱에 대한 언어 확장(예: Excel의 VBA , AutoCAD의 Lisp ) 외에는 많은 관심을 받지 못했습니다. 따라서 앱 자체에 개발 도구가 있다고 가정하는 멘탈 모델을 고안한 개발자는 모델을 변경하거나 모델이 적용되는 환경으로 스스로를 제한해야 했습니다.
따라서 다음을 작성할 때:
내가 발견한 다른 지저분한 것들과 함께 Android용 앱 개발은 일어나지 않을 것이라고 생각합니다.
그것은 당신을 위해, 지금 당장을 위한 최선으로 보일 것입니다. 마찬가지로, Android에서 보고한 것과 동일한 문제 중 일부는 웹 애플리케이션에서도 발견할 수 있으므로(예: "종료" 없음) 애플리케이션을 웹으로 이식하지 말라고 조언합니다. 또는 반대로 언젠가 는 앱을 웹으로 이식하면 웹 애플리케이션의 흐름이 Android에 더 적합할 수 있으며 그 당시 Android 포트를 다시 방문할 수 있습니다.
이 스레드의 미래 독자를 위해 여기에 수정 사항을 추가하고 싶습니다. 이 특별한 뉘앙스는 오랫동안 제 이해를 벗어났기 때문에 여러분 중 누구도 같은 실수를 하지 않도록 하고 싶습니다.
스택에 둘 이상의 활동이 있는 경우 System.exit() 실제로 일어나는 일은 프로세스가 종료 되고 스택에서 하나의 적은 활동으로 즉시 다시 시작된다는 것입니다. 이것은 강제 종료 대화 상자에 의해 앱이 종료되거나 DDMS에서 프로세스를 종료하려고 할 때도 발생합니다. 이것은 내가 아는 한 완전히 문서화되지 않은 사실입니다.
짧은 대답은 당신이 당신의 응용 프로그램을 종료하려는 경우, 당신은 당신의 스택과의 모든 활동을 추적 계속있어입니다 finish() 사용자가 (종료하고자 할 때 그들 모두가없고, 반복하는 방법이 없습니다 액티비티 스택이므로 이 모든 것을 직접 관리해야 합니다.) 이것조차도 실제로 프로세스 또는 귀하가 가질 수 있는 댕글링 참조를 종료하지 않습니다. 간단하게 활동을 마칩니다. Process.killProcess(Process.myPid()) 가 더 잘 작동하는지 확실하지 않습니다. 나는 그것을 테스트하지 않았다.
반면에 스택에 활동이 남아 있어도 괜찮다면 매우 쉽게 Activity.moveTaskToBack(true) 은 단순히 프로세스를 배경으로 하고 홈 화면을 표시합니다.
긴 대답에는 이 행동의 이면에 있는 철학에 대한 설명이 포함됩니다. 철학은 다음과 같은 여러 가정에서 탄생합니다.
- 우선, 이것은 앱이 포그라운드에 있을 때만 발생합니다. 백그라운드에 있으면 프로세스가 정상적으로 종료됩니다. 그러나 포그라운드에 있는 경우 OS는 사용자가 하던 일을 계속하기를 원한다고 가정합니다. (DDMS에서 프로세스를 종료하려는 경우 홈 버튼을 먼저 누른 다음 종료해야 함)
- 또한 각 활동이 다른 모든 활동과 독립적이라고 가정합니다. 예를 들어 앱에서 브라우저 활동을 시작하는 경우와 같이 완전히 별개이며 사용자가 작성하지 않은 경우가 많습니다. 브라우저 활동은 매니페스트 속성에 따라 동일한 작업에서 생성되거나 생성되지 않을 수 있습니다.
- 각 활동이 완전히 자립적이며 순식간에 종료/복원될 수 있다고 가정합니다. (내 앱에는 많은 양의 캐시된 데이터에 의존하는 많은 활동이 있고
onSaveInstanceState 동안 효율적으로 직렬화하기에는 너무 커서 어떻게 해야 할까요?) 대부분의 잘 작성된 Android 앱의 경우 이것이 사실이어야 합니다. , 앱이 백그라운드에서 언제 종료될지 모르기 때문입니다. - 마지막 요소는 가정이 아니라 OS의 한계입니다 . 앱을 명시적으로 종료하는 것은 앱 충돌과 동일하고 Android가 메모리를 회수하기 위해 앱을 종료하는 것과 동일합니다. 이것은 쿠데타로 절정에 달합니다. Android는 앱이 종료되었거나 충돌했는지 또는 백그라운드에서 종료되었는지 알 수 없기 때문에 사용자가 중단한 부분으로 돌아가기를 원한다고 가정하므로 ActivityManager가 프로세스를 다시 시작합니다.
생각해보면 플랫폼에 맞는 말이다. 첫째, 이것은 프로세스가 백그라운드에서 종료되고 사용자가 다시 돌아올 때 발생하는 일이므로 중단된 위치에서 다시 시작해야 합니다. 둘째, 앱이 충돌하고 두려운 강제 종료 대화 상자가 표시될 때 발생합니다.
내 사용자가 사진을 찍어 업로드할 수 있기를 원한다고 가정해 보겠습니다. 내 활동에서 카메라 활동을 시작하고 이미지를 반환하도록 요청합니다. 카메라가 내 현재 작업의 맨 위로 푸시됩니다(자체 작업에서 생성되지 않음). 카메라에 오류가 있고 충돌하는 경우 전체 앱이 충돌해야 합니까? 사용자 입장에서는 카메라만 실패했고, 이전 활동으로 돌아가야 합니다. 따라서 스택에서 카메라를 제외한 모든 동일한 활동으로 프로세스를 다시 시작합니다. 활동 은 모자 한 방울에서 죽고 복원될 수 있도록 설계되어야 하므로 문제가 되지 않습니다. 그것은 우리의 많은 문제가 불행히도, 모든 애플 리케이션, 그런 식으로 설계 할 수있다, 로맹 가이 또는 다른 사람이 당신을 알려줍니다 상관없이. 따라서 해결 방법을 사용해야 합니다.
그래서, 나의 마지막 조언:
- 프로세스를 종료하려고 하지 마십시오. 모든 활동에서
finish() moveTaskToBack(true) 호출하십시오. - 프로세스가 충돌하거나 종료되고 나처럼 메모리에 있던 데이터가 필요하고 지금은 손실된 경우 루트 활동으로 돌아가야 합니다.
Intent.FLAG_ACTIVITY_CLEAR_TOP 플래그가 포함된 Intent로 startActivity() 를 호출해야 합니다. - Eclipse DDMS 관점에서 앱을 종료하려면 포그라운드에 있지 않는 것이 좋습니다. 그렇지 않으면 자체적으로 다시 시작됩니다. 먼저 홈 버튼을 누른 다음 프로세스를 종료해야 합니다.
내 모든 응용 프로그램에는 종료 버튼이 있습니다... 그리고 그것 때문에 사용자로부터 꽤 자주 긍정적인 코멘트를 받습니다. 플랫폼이 응용 프로그램에 필요하지 않은 방식으로 설계되었는지 여부는 신경 쓰지 않습니다. "그들을 거기에 두지 마십시오"라고 말하는 것은 일종의 우스꽝스러운 일입니다. 사용자가 종료하려는 경우... 정확히 수행할 수 있는 액세스 권한을 제공합니다. Android가 작동하는 방식을 전혀 줄이지 않고 좋은 습관처럼 보입니다. 저는 라이프 사이클을 이해하고 있습니다... 그리고 제가 관찰한 바에 따르면 Android는 이를 잘 처리하지 못합니다.... 그리고 그것은 기본적인 사실입니다.
애플리케이션을 모놀리식 애플리케이션으로 생각하지 마세요. 사용자가 귀하의 "어플리케이션"과 Android 서비스를 통해 제공되는 "기능"과 상호 작용할 수 있는 UI 화면의 집합입니다.
당신의 신비한 앱이 "하는" 일을 아는 것은 그다지 중요하지 않습니다. 매우 안전한 기업 인트라넷으로 터널링하여 일부 모니터링 또는 상호 작용을 수행하고 사용자가 "응용 프로그램을 종료"할 때까지 로그인 상태를 유지한다고 가정해 보겠습니다. IT 부서에서 명령을 내리기 때문에 사용자는 인트라넷 내부 또는 외부에 있을 때를 매우 잘 알고 있어야 합니다. 따라서 사용자가 "종료"하는 것이 중요하다는 사고 방식입니다.
이것은 간단합니다. 알림 표시줄에 "나는 인트라넷에 있거나 실행 중입니다"라는 지속적인 알림을 표시하는 서비스를 만듭니다. 해당 서비스가 애플리케이션에 필요한 모든 기능을 수행하도록 합니다. 사용자가 "응용 프로그램"과 상호 작용하는 데 필요한 UI 비트에 액세스할 수 있도록 해당 서비스에 바인딩하는 활동이 있습니다. 그리고 Android 메뉴 -> 종료(또는 로그아웃 또는 기타) 버튼이 있어 서비스를 종료하도록 지시한 다음 활동 자체를 닫습니다.
이것은 모든 의도와 목적을 위해 정확히 당신이 원하는 것을 말하는 것입니다. 안드로이드 방식으로 완료했습니다. 이 "출구"가 가능한 사고 방식의 예를 보려면 Google 토크 또는 Google 지도 내비게이션을 참조하세요. 유일한 차이점은 활동에서 뒤로 버튼을 누르면 사용자가 응용 프로그램을 되살리기를 원하는 경우를 대비하여 UNIX 프로세스가 대기 상태로 남아 있을 수 있다는 것입니다. 이것은 최근에 액세스한 파일을 메모리에 캐시하는 최신 운영 체제와 실제로 다르지 않습니다. Windows 프로그램을 종료한 후에도 필요한 리소스는 여전히 메모리에 남아 있으며 더 이상 필요하지 않으므로 로드될 때 다른 리소스로 대체되기를 기다리고 있습니다. 안드로이드도 똑같습니다.
난 정말 당신의 문제를 볼 수 없습니다.
많은 전문가들이 참여하는 흥미롭고 통찰력 있는 토론입니다. 이 게시물은 Android OS의 핵심 디자인 중 하나를 중심으로 돌아가기 때문에 Android 개발 메인 웹사이트 내에서 반복되어야 한다고 생각합니다.
여기에 내 두 센트를 추가하고 싶습니다.
지금까지 저는 Android의 수명 주기 이벤트 처리 방식에 깊은 인상을 받아 웹과 같은 경험의 개념을 기본 앱에 도입했습니다.
그래도 나는 여전히 Quit 버튼이 있어야 한다고 믿습니다. 왜요? ... 저나 Ted 또는 여기 기술 전문가가 아니라 최종 사용자의 요구를 충족시키기 위한 유일한 목적입니다.
나는 Windows의 열렬한 팬은 아니지만 오래 전에 그들은 대부분의 최종 사용자가 (X 버튼) ... "원할 때 위젯 실행을 종료하고 싶습니다"라는 개념을 도입했습니다.
그것은 누군가(OS, 개발자?)가 그/그녀의 재량에 따라 그것을 처리한다는 것을 의미하지 않습니다. 그것은 단순히 "내가 익숙한 내 Red X 버튼은 어디에 있습니까?"를 의미합니다. 내 동작은 '버튼을 누르면 전화 끊기', '버튼을 눌러 장치 끄기' 등과 유사해야 합니다. 이것은 인식입니다. 내 행동이 실제로 목적을 달성했다는 사실 자체가 만족스럽습니다.
개발자가 여기에 제공된 제안을 사용하여 이 동작을 스푸핑할 수 있지만 최종 사용자의 요구에 따라 독립적이고 신뢰할 수 있으며 중립적인 소스(OS)에 의해 애플리케이션이 (지금) 완전히 작동을 중지해야 한다는 인식이 여전히 남아 있습니다.
뒤로 버튼을 누르거나 Activity 에서 finish() 를 호출하여 종료 할 수 있습니다. 명시적으로 종료하려면 MenuItem 에서 finish() 를 호출하기만 하면 됩니다.
Romain은 할 수 없다고 말하는 것이 아니라 무의미하다고 말합니다. 사용자는 작업을 종료하거나 저장하는 것에 대해 신경 쓸 필요가 없습니다. 애플리케이션 수명 주기가 작동하는 방식은 자동으로 저장하고 저장하는 스마트 소프트웨어를 작성하도록 권장하기 때문입니다. 무슨 일이 있어도 상태를 복원합니다.
테드, 당신이 성취하려고 하는 것은 이루어질 수 있지만, 아마도 당신이 지금 생각하는 방식은 아닐 것입니다.
나는 당신이 활동 및 서비스에 대해 읽을 것을 제안합니다. "앱"이라는 용어 사용을 중단하고 구성 요소, 즉 활동, 서비스를 참조하십시오. Android 플랫폼에 대해 더 많이 알아야 한다고 생각합니다. 그것은 표준 PC 앱에서 사고 방식의 변화입니다. 귀하의 게시물에 "활동"이라는 단어(FAQ 인용문, 즉 귀하의 단어가 아님)가 포함되어 있지 않다는 사실은 귀하가 더 읽어야 함을 알려줍니다.
이 논쟁은 개발자가 가장 잘 아는지 아니면 사용자가 가장 잘 아는지에 대한 오래된 질문으로 귀결됩니다. 인적 요소의 모든 영역에서 전문 디자이너는 매일 이를 위해 고군분투합니다.
Ted는 마켓에서 가장 많이 다운로드된 앱 중 하나가 '앱 킬러'라는 점을 지적했습니다. 사람들은 응용 프로그램을 종료할 때 약간의 추가 세로토닌을 얻습니다. 그들은 데스크탑/노트북에 익숙합니다. 일이 빠르게 진행되도록 합니다. 프로세서를 시원하게 유지하고 팬이 켜지지 않도록 합니다. 더 적은 전력을 사용합니다.
모바일 장치가 훨씬 더 작은 배라고 생각할 때 특히 '더 이상 필요하지 않은 것을 바다에 던지기'에 대한 인센티브를 높이 평가할 수 있습니다. 이제 Android 개발자는 OS가 가장 잘 알고 있으며 앱을 종료하는 것은 골동품이라고 추론했습니다. 저는 이것을 진심으로 지지합니다.
그러나 사용자의 무지에서 비롯된 좌절이라 할지라도 사용자를 실망시키지 않아야 한다고 생각합니다. 그 때문에 '종료' 옵션이 있는 것이 보기를 닫는 것 외에는 아무것도 하지 않는 플라시보 버튼일지라도 좋은 디자인이라고 결론지었습니다.
블로그 게시물 Android 앱에 종료 버튼을 포함해야 하는 경우(힌트: 절대 안 됨)에서 내가 할 수 있는 것보다 훨씬 더 잘 설명합니다. 모든 Android 개발자가 이미 읽었으면 합니다.
발췌:
내 경험에 따르면 [사용자]가 정말로 원하는 것은 다음과 같습니다. 앱이 리소스(배터리, CPU 주기, 데이터 전송 등) 소비를 중지하도록 보장하는 명확한 방법.
많은 사용자는 종료 버튼이 이 요구 사항을 구현하고 추가할 것을 요청하는 것으로 인식합니다. 사용자를 기쁘게 하려는 개발자는 의무적으로 하나를 추가합니다. 얼마 지나지 않아 둘 다 실패합니다.
- 대부분의 경우 종료 버튼은 단순히
Activity.finish() 를 호출합니다. 이것은 뒤로 버튼을 누르는 것과 정확히 동일합니다. 정확히. 서비스가 계속 실행되고 폴링이 계속 발생합니다. 사용자는 앱을 종료했다고 생각할 수 있지만 실제로는 그렇지 않으며 곧 더 짜증이 날 것입니다. - 종료 동작이 이제 모호합니다. 종료 버튼이 활동을 닫아야 합니까, 아니면 연결된 모든 서비스, 수신기 및 경보도 중지해야 합니까? 백 은 어떻게 해야 합니까? 대신 홈 을 누르면 어떻게 되나요? 앱에 위젯이 있으면 어떻게 됩니까? 종료 버튼도 업데이트를 중지해야 합니까?
해결책은 뒤로 버튼이 종료 버튼이 기대하는 대로 동작하도록 하는 것입니다. 더 나은 방법은 앱이 표시되지 않을 때마다 리소스 소비를 중지하는 것입니다.
계속해서 전체 기사를 읽으십시오.
답변: (Romain Guy): 사용자는 그렇지 않습니다. 시스템이 이를 자동으로 처리합니다. 그것이 바로 활동 수명 주기(특히 onPause/onStop/onDestroy)의 목적입니다. 당신이 무엇을 하든지 "종료"또는 "종료"응용 프로그램 버튼을 누르지 마십시오. Android의 애플리케이션 모델에서는 쓸모가 없습니다. 이는 핵심 응용 프로그램이 작동하는 방식과도 반대입니다.
1: 응용 프로그램을 완전히 종료하는 것은 일반적으로 필수가 아니지만 쓸모가 없습니다. 창에 종료 옵션이 없다면 어떻게 될까요? 메모리가 가득 차서 OS가 어떤 프로그램을 끝냈는지 추측해야 하므로 시스템이 매우 느릴 것입니다. 나는 Romain Guy 또는 Larry Page와 Sergey Brin의 말을 신경 쓰지 않습니다. 이것은 의심할 여지가 없는 사실입니다. 새 앱이 시작되기 전에 메모리를 확보하기 위해 작업을 종료해야 할 때 시스템이 더 느리게 실행됩니다. 앱을 죽이는 데 시간이 걸리지 않는다고 말할 수는 없습니다! 먼 별에서조차 빛이 완전히 가까운 애플리케이션에 대한 사용자 수 있도록 몇 가지 사용이 있습니다 ... 시간이 걸립니다.
2: 핵심 애플리케이션이 작동하는 방식과 반대입니까? 그게 무슨 뜻이야? 지금은 앱 실행을 마치면 더 이상 작업을 수행하지 않습니다. 메모리가 필요할 때 OS에 의해 종료되기를 기다리고 있습니다.
요약하면 최소화하는 것과 종료하는 것 사이에는 뚜렷한 차이가 있으며 어느 쪽 핀치도 서로에게 잘 맞지 않습니다. 모든 나사에 드라이버를 남겨두나요? 아니면 모든 문에 열쇠가 있습니까? 차단기가 끊어지고 다른 기기를 켜야 할 때까지 모든 기기를 높은 상태로 두나요? 식기 세척기에 접시를 가득 채운 상태로 두고 매번 더러워진 새 접시를 위한 공간을 확보할 만큼만 꺼내나요? 우리는 모든 차를 차도에 계속 놔둘까요?
사용자가 앱을 최소화하려는 경우 가장 좋은 것은 최소화하는 것입니다. 사용자가 앱을 종료하려면 반드시 종료하는 것이 가장 좋습니다.
찡그린건가? 그것이 안드로이드의 관점입니다. 그들은 그것에 대해 눈살을 찌푸립니다. 그리고 많은 독립적인 신인 Android 개발자들은 이에 대해 눈살을 찌푸립니다.
그러나 문제가 발생하면 좋은 코딩과 나쁜 코딩이 있습니다. 좋은 프로그램 흐름 모델이 있고 나쁜 프로그램 흐름 모델이 있습니다.
사용자가 프로그램이 끝났다는 것을 알면서도 프로그램을 메모리에 남겨두는 것은 좋은 프로그램 흐름이 아닙니다. 어떤 용도로도 사용되지 않으며 새 앱을 시작하거나 앱을 실행할 때 더 많은 메모리를 할당할 때 속도가 느려집니다.
그것은 일종의 자동차와 같습니다. 정지 신호에서 멈추거나 패스트 푸드 드라이브를 통과하거나 ATM에서 멈추는 것처럼 계속 달리는 경우가 있습니다. 그러나 직장에 도착하거나 식료품 점 또는 집에 도착할 때와 같이 차단하고 싶은 다른 상황이 있습니다.
마찬가지로 게임을 하고 있는데 전화벨이 울리면 그렇습니다. 게임을 일시 중지하고 계속 실행하십시오. 그러나 사용자가 잠시 동안 게임을 마치면 반드시 종료하도록 하십시오.
일부 응용 프로그램의 종료 버튼은 다른 응용 프로그램보다 더 앞에 있어야 합니다. 예를 들어 사용자가 완전히 종료하고 싶어하는 게임이나 프로그램은 분명한 종료가 있어야 합니다. 이메일 프로그램과 같은 다른 프로그램은 종료를 원하지 않는 경우(이메일을 계속 확인할 수 있도록) -- 이러한 프로그램은 종료 옵션으로 주 제어 입력 화면 공간을 낭비해서는 안 되지만 좋은 프로그램 흐름을 위해서는 종료 옵션이 있어야 합니다. 누군가가 수신 범위가 열악한 지역이나 Skype 통화 중일 때 메일 프로그램이 이메일을 확인하는 것을 원하지 않는다고 결정하면 어떻게 됩니까? 원하는 경우 이메일 프로그램을 종료하게 하십시오!
일시 중단과 종료는 두 가지 중요한 작업이며 어느 쪽도 다른 역할을 수행하지 않습니다.
데이터/연결(따라서 "응용 프로그램")을 영구적으로 만드는 방법을 이해할 수 없다면 Android로 "필요한" 작업을 수행할 수 없습니다.
귀엽고 작은 앱 킬러를 다운로드하는 사람들은 일반적으로 배터리 수명이나 메모리 사용에 도움이 되지 않지만 OS가 메모리를 효율적으로 관리하는 작업을 수행하는 것을 방해한다는 것을 알게 됩니다...
http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
버그가 있는 소프트웨어가 없으면 앱을 종료할 필요가 없다는 것이 요점이라고 생각합니다. Android는 사용자가 앱을 사용하지 않고 기기에 더 많은 메모리가 필요할 때 앱을 종료합니다. 백그라운드에서 서비스를 실행해야 하는 앱이 있는 경우 서비스를 끄는 방법이 필요할 수 있습니다.
예를 들어 Google Listen은 앱이 보이지 않을 때 팟캐스트를 계속 재생합니다. 그러나 사용자가 작업을 마치면 팟캐스트를 끌 수 있는 일시 중지 버튼이 항상 있습니다. 내 기억이 맞다면 Listen은 알림 표시줄에 바로가기를 추가하여 언제든지 일시 중지 버튼으로 빠르게 이동할 수 있습니다. 또 다른 예는 인터넷에서 서비스를 지속적으로 폴링하는 트위터 앱과 같은 앱입니다. 이러한 유형의 앱은 실제로 사용자가 서버를 폴링하는 빈도 또는 백그라운드 스레드에서 폴링할지 여부를 선택할 수 있도록 해야 합니다.
종료 시 실행되는 코드가 필요한 경우 onPause(), onStop() 또는 onDestroy()를 적절하게 재정의할 수 있습니다. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
Addison-Wesley에서 발행한 "Android Wireless Application Development"를 읽는 것이 좋습니다. 나는 그것을 끝내고 있으며 매우 철저합니다.
Android 플랫폼에 대한 근본적인 오해가 있는 것 같습니다. 저도 처음에는 Android 앱의 애플리케이션 수명 주기에 대해 약간 좌절했지만, 더 많이 이해하고 나서 이 접근 방식을 정말 좋아하게 되었습니다. 이 책은 당신의 모든 질문과 그 이상에 대한 답을 줄 것입니다. 새로운 Android 개발자를 위해 찾은 최고의 리소스입니다.
또한 기존 앱의 line-for-line 포트를 버려야 한다고 생각합니다. 애플리케이션을 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에서 애플리케이션을 구상할 때 다음과 같이 표시됩니다.
- 당신은 당신의 응용 프로그램으로 작업 중입니다
- 전화가 울렸다
- 당신은 전화를 받아
- 통화가 끝나면 같은 장소에서 지원서로 돌아갑니다.
그렇게 하려면 뒤로 버튼이나 휴대폰의 홈 버튼(짧게 또는 길게 누르기)과 알림 표시줄만 있으면 됩니다.
응용 프로그램을 종료할 때 응용 프로그램이 종료될 때까지 뒤로 버튼이나 홈 버튼만 사용합니다.
내가 생각하는 대부분의 응용 프로그램은 그렇게 생각됩니다. 그러나 어떤 종류의 세션이나 연결이 필요한 경우 로그인/로그아웃 버튼과 알림(제목 표시줄 또는 기타)으로 사용자에게 명확하게 알렸습니다. 이것은 순수한 "종료" 스타일 응용 프로그램과 다소 다른 스타일입니다.
PC에는 다중 GUI 데스크탑이 있고 Android에는 분명히 다중 작업이 있지만 한 번에 하나의 앱만 표시합니다(여기서 위젯은 고려하지 않습니다 ^^). 그리고 휴대폰에서는 언제든지 하고 있는 일보다 더 중요한 일에 대한 알림을 받을 수 있습니다.
따라서 응용 프로그램의 전체 개념은 "응용 프로그램 입력 - 작업 - 응용 프로그램 종료"와 다른 것에 의존합니다.
흠...
나는 당신이 안드로이드 앱을 제대로 보지 못한다고 생각합니다. 원하는 것과 거의 유사한 작업을 쉽게 수행할 수 있습니다.
개발자 라이브 주기 문서에서 권장하는 것처럼 앱 활동을 상태를 저장/복원합니다.
복원 단계에서 일부 로그인이 필요한 경우(사용 가능한 로그인/세션 정보가 없음) 그렇게 하십시오.
결국 버튼/메뉴/시간 초과를 추가 finish() 를 수행하여 암시적으로 앱 세션이 종료됩니다. 따라서 앱이 시작되거나 다시 앞으로 표시되면 시작됩니다. 새 세션.
그렇게하면 앱이 실제로 메모리에서 제거되는지 여부에 신경 쓰지 않습니다.
정말로 그것을 메모리에서 제거하고 싶다면(이것은 권장하지 않으며 어떤 목적을 위한 것인가?) onDestroy() java.lang.System.exit(0) (또는 아마도 restartPackage(..) ))를 사용하여 조건부로 종료할 수 있습니다. restartPackage(..) ?). onDestroy() 는 앱이 종료되는 것이 아니라 정상적인 활동 수명 주기의 일부이기 때문에 "앱을 실제로 종료"하려는 경우에만 수행합니다.
Android 컨텍스트의 애플리케이션은 막연하게 관련된 활동의 묶음일 뿐이므로 애플리케이션을 종료하는 것은 그다지 의미가 없습니다. 활동을 완료()할 수 있으며 활동 스택의 이전 활동 보기가 그려집니다.
나는 테드의 말에 동의한다. 애플리케이션을 종료하는 것이 '안드로이드 방식'이 아님을 이해하지만 배제되어야 할 것 같지는 않습니다. 다음은 활동뿐만 아니라 애플리케이션을 실제로 종료해야 하는 세 가지 이유입니다.
사용자는 메모리가 부족한 경우 어떤 앱이 종료되는지에 대한 제어를 원할 수 있습니다. 중요한 앱 A가 백그라운드에서 실행 중인 경우 앱 A가 운영 체제에 의해 종료되지 않도록 작업이 끝나면 앱 B를 종료하는 것이 좋습니다.
애플리케이션의 메모리에 캐시된 민감한 데이터가 있는 경우 바이러스/웜/악성 앱이 접근할 수 없도록 앱을 종료할 수 있습니다. 보안 모델이 이를 방지해야 한다는 것을 알고 있지만 만일을 대비하여...
애플리케이션이 전화기에 부정적인 영향을 미칠 수 있는 리소스(예: 네트워크, CPU, 센서 등)를 사용하는 경우 해당 리소스를 확보하는 한 가지 방법은 애플리케이션을 종료하는 것입니다. 나는 잘 작동하는 앱이 필요하지 않을 때 리소스를 확보해야 한다는 것을 이해합니다. 그러나 다시, 응용 프로그램을 종료하는 것이 이를 보장하는 합리적인 방법인 것 같습니다.
Linux 커널에는 메모리 부족 킬러 라는 기능이 있습니다(위에서 언급했듯이 정책은 사용자 공간 수준에서 구성할 수 있으며 커널은 최적의 것이 아니지만 절대 불필요한 것은 아닙니다).
그리고 Android에서 많이 사용됩니다.
일부 사용자 공간 앱은 이러한 킬 앱을 지원하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.
finish() 명령에서 원하는 답을 찾은 것 같습니다. 이렇게 하면 메모리에서 앱이 제거되지 않지만 Android는 리소스가 필요할 때마다 제거하므로 명시적으로 제거하지 않아도 아무런 차이가 없습니다.
나는 응용 프로그램 종료가 일반적으로 가질 수 있는 완전한 효과를 얻기 위해 장치를 부팅한 직후, 바로 직전에 앱이 처음 실행될 때 앱의 상태를 정상 상태로 재설정하고 싶을 것이라고 덧붙였습니다. 모든 활동에서 finish()를 호출합니다. 그렇게 하면 사용자가 앱을 다시 선택하면 시뮬레이션된 "종료" 이전 지점에서 남은 상태 없이 "새로" 실행된 것으로 나타납니다.
사용자의 작업을 저장하는 것과 같이 "종료" 시에만 발생해야 하는 특수 작업이 있는 경우 위 루틴의 재초기화 부분 이전에 수행할 수도 있습니다.
이 접근 방식을 사용하면 앱 닫기를 포함한 OS 리소스 관리를 운영 체제의 손에 맡기는 Android의 철학을 위반하지 않고 "종료" 명령을 사용하는 목표를 달성할 수 있습니다.
개인적으로 저는 이 접근 방식을 사용하지 않을 것입니다. 왜냐하면 Android 사용자는 앱을 다시 방문할 때 앱의 연속성을 유지하기를 기대하고 앱을 "종료"하는 방식에 익숙하지 않기 때문입니다. 대신 프로세스에서 앱을 "남겨둘" 필요 없이 사용자가 앱을 기본 초기 상태로 재설정하기 위해 호출할 수 있는 "지우기" 기능을 지원합니다.
한 가지 예외는 사용자가 뒤로 버튼을 충분히 여러 번 눌러 앱을 닫는 경우입니다. 이러한 상황에서 사용자 측에서는 상태가 저장될 것이라고 기대하지 않습니다(그리고 앱에 저장되지 않은 상태가 있는 경우 개발자로서 저장되지 않은 데이터를 감지하는 뒤로 버튼을 처리하는 코드가 있어야 합니다. SharedPreferences, 파일 또는 기타 비휘발성 매체에 저장하라는 메시지가 표시됩니다.
system.exit(0) 관련:
system.exit(0)을 사용하여 최종적으로 앱을 종료하기로 결정했다면(예: 마지막 뒤로 버튼 누름의 결과로) 이 방법이 "작동"하지만 일부에서는 케이스는 내가 앱의 흔적을 남기지 않고 앱을 닫을 수 있었던 유일한 방법이었습니다. 이 접근 방식을 사용할 때 Jelly Bean에서 발생하는 사소한 결함이 하나 있습니다.
특히, 최근 앱 목록을 사용하여 앱을 연 다음 뒤로 버튼을 사용하여 앱을 닫는 경우(시스템 종료는 system.exit(0)을 통해 구현됨) 최근 앱 목록은 다음과 같이 다시 표시됩니다. 닫힌 적이 없습니다. 그런 다음 해당 목록에서 앱 항목을 탭하여 이미 열려 있는 동일한 최근 앱 목록에서 두 번째로 실행하면 응답이 없습니다.
이 문제의 원인은 최근 앱 목록이 system.exit(0)를 사용하여 앱을 닫았기 때문에 작동하지 않는 앱에 대한 참조를 유지하고 있기 때문이라고 생각합니다. finish()를 사용하여 보다 문명화된 앱을 닫으면 최근 앱 목록을 새로 고칠 수 있는 방식으로 OS에 알릴 수 있지만 system.exit(0)은 분명히 이 작업을 수행하지 않습니다.
최근 앱에서 앱을 연 다음 종료한 다음 동일한 열린 최근 앱 목록에서 즉시 다시 열 사람이 거의 없기 때문에 이것은 그 자체로 큰 문제가 아닙니다. 그리고 그들이 홈 버튼을 탭한 다음 최근 앱 목록을 다시 열면 앱 항목이 거기에 있고 완전히 작동할 것입니다. 하지만 system.exit(0)을 사용하면 앱과 OS 간의 적절한 통신을 방해할 수 있으며, 이는 이 접근 방식을 사용할 때 더 심각하고 미묘할 수 있는 다른 결과가 있을 수 있음을 시사한다고 생각합니다.
시간이 지나면 상황이 바뀌길 바랍니다. 앱 프로세스가 OS에 의해 올바르게 샌드박스 처리된 경우 사용자는 앱 또는 프로세스를 종료할 수 있어야 합니다. 앱은 완벽하게 작성되어야 하며 그렇지 않으면 사용자가 모든 SDK 권장 사항을 따르는 앱만 사용해야 한다는 개념이 있습니다. 나는 그것이 높은 주문이라고 생각합니다.
"출구" 난제를 해결할 수 있는 (상대적으로) 단순한 디자인이 있습니다. 앱이 빈 화면인 "기본" 상태(활동)를 갖도록 합니다. 활동의 첫 번째 onCreate에서 앱의 주요 기능이 있는 다른 활동을 시작할 수 있습니다. 그런 다음 이 두 번째 활동을 종료()하고 빈 화면의 기본으로 돌아가서 "종료"를 수행할 수 있습니다. OS는 이 빈 화면을 원하는 만큼 메모리에 유지할 수 있습니다.
본질적으로 OS로 나갈 수 없기 때문에 스스로 만들어낸 무(無)로 변모할 뿐이다.
응용 프로그램 개발자가 자신의 응용 프로그램을 종료할 수 있는 종료 기능이 없으면 매우 나쁜 디자인입니다.
내 응용 프로그램은 사용자가 런타임 중에 동적으로 데이터를 변경할 수 있도록 허용해야 하고 사용자는 변경 효과를 적용하려면 내 응용 프로그램을 다시 시작해야 하지만 Android는 내 응용 프로그램을 자체적으로 다시 시작하는 것을 허용하지 않았습니다. Android OS는 매우 나쁜 디자인 애플리케이션 수명 주기를 가지고 있습니다.
언제든지 앱을 닫으 FLAG_ACTIVITY_CLEAR_TOP Intent에서 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(); } } ......................
이것은 Android 수명 주기를 중단하지 않고 작동합니다.
우선 System.exit(0)을 절대 사용하지 마십시오. 그것은 사람의 머리를 때리며 잠들게 하는 것과 같습니다!
두 번째: 이 문제에 직면해 있습니다. 내 솔루션을 공유하기 전에 내 생각을 공유하고 싶습니다.
나는 "나가기 버튼"이 바보라고 생각합니다. 정말 정말 정말 바보입니다. 그리고 나는 당신의 응용 프로그램에 대한 종료 버튼을 요구하는 사용자 (소비자)도 바보라고 생각합니다. 그들은 OS가 어떻게 작동하고 어떻게 리소스를 관리하는지 이해하지 못합니다.
적절한 순간과 조건에 올바른 작업(업데이트, 저장 및 푸시)을 수행하고 올바른 작업(서비스 및 수신기)을 사용하는 좋은 코드를 작성하면 꽤 잘 작동하고 아무도 불평하지 않을 것이라고 생각합니다. .
하지만 그렇게 하려면 Android에서 작동하는 방식을 연구하고 배워야 합니다. 어쨌든 이것은 사용자에게 "Exit Button"을 제공하는 솔루션입니다.
나는 각 활동에서 항상 볼 수 있는 옵션 메뉴를 만들었습니다(저는 그렇게 하는 슈퍼 활동이 있습니다).
사용자가 해당 버튼을 클릭하면 다음과 같은 일이 발생합니다.
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에 저장하고 Intent를 시작합니다. 저 깃발들을 봐주세요. 그것들은 나의 "집" 활동인 나의 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는 너무 (비동기 Ted, Windows 프로그래머처럼 코딩하지 마십시오. 그렇지 않으면 프로그램이 Windows 프로그램처럼 실행될 것입니다... 와우, 그렇게 어렵지 않습니다).
나는 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(); }
이 코드는 완전히 틀릴 수 있지만 작동합니다. 이것은 내 첫 번째 Android 응용 프로그램 중 하나입니다.
Voilà, 백그라운드에 있을 때 CPU를 소비하지 않지만 RAM에 있기 때문에 즉시 다시 열 준비가 된 응용 프로그램입니다(Android 수명 주기와 같이 RAM을 유지하지는 않지만) ... 앱은 항상 준비되어 있으며 전화입니다. , 남자/여자. 앱이 모든 RAM을 사용하고 OS에서 종료할 수 없는 경우 벨소리가 중지될 수 있습니다. =P 그렇기 때문에 OS는 앱이 백그라운드에 있을 때 앱을 닫을 수 있어야 합니다(애플리케이션이 리소스 돼지가 아니라 닫히지 않을 것이므로 더 나은 응용 프로그램을 작성해 보겠습니다.
인텐트를 통해 다음 페이지로 이동할 때마다 다음을 사용하세요.
`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); .
당신은 아마도 "적절한" 컴퓨터를 위한 "적절한" 프로그램을 작성하는 데 수년을 보냈을 것입니다. 당신은 안드로이드 에서 프로그래밍을 배우고 있다고 말합니다. 이것은 배워야 할 것 중 하나일 뿐입니다. 수채화 그림을 그리는 데 몇 년을 보내고 유화가 정확히 같은 방식으로 작동한다고 가정할 수는 없습니다. 이것은 제가 8년 전 첫 앱을 작성할 때 저에게 가장 새로운 개념이었습니다.
출처 : http:www.stackoverflow.com/questions/2033914/is-quitting-an-application-frowned-upon