Life Cycle of an Android Application
[안드로이드 애플리케이션 생명주기]
In most cases, every Android application runs in its own Linux process. This process is created
for the application when some of its code needs to be run, and will remain running until it is no
longer needed and the system needs to reclaim its memory for use by other applications.
An important and unusual feature of Android is that an application process's lifetime is not directly
controlled by the application itself. Instead, it is determined by the system through a combination
of the parts of the application that the system knows are running, how important these things are
to the user, and how much overall memory is available in the system.
대부분의 경우에 있어서 모든 안드로이드 애플리케이션은 자신 고유의 리눅스 프로세스 기반 위에서
동작한다. 이 프로세스는 애플리케이션의 특정 코드가 실행되어야 할 필요가 있을 때 애플리케이션을
위해서 생성되며, 애플리케이션이 더이상 필요하기 않고 다른 애플리케이션들을 위해 메모리를 반활할
필요가 있을 때까지 실행상태로 존재하게 된다.
안드로이드의 중요하면서 보편적이지 않은 하나의 특징은 애플리케이션 프로세스의 생명주기가 해당
애플리케이션에 의해 직접적으로 제어되지 않는 다는 것이다. 대신, 애플리케이션이 사용자를 위해서
얼마나 중요한가? 그리고 시스템 전체적으로 얼마나 많은 메모리가 유용한가라는 애플리케이션 실행과
관련된 시스템의 인식기반과 관련된 애플리케이션의 조합된 영역들에 의해 결정난다.
It is important that application developers understand how different application components
(in particular Activity, Service, and IntentReceiver) impact the lifetime of the application's process.
Not using these components correctly can result in the system killing the application's
process while it is doing important work.
A common example of a process life-cycle bug is an IntentReceiver that starts a thread when it
receives an Intent in its onReceiveIntent() method, and then returns from the function. Once it returns,
the system considers that IntentReceiver to be no longer active, and thus its hosting process no
longer needed (unless other application components are active in it). Thus, it may kill the process
at any time to reclaim memory, terminating the spawned thread that is running in it. The solution to
this problem is to start a Service from the IntentReceiver, so the system knows that there is still
active work being done in the process.
애플리케이션 개발자가 애플리케이션 프로세스의 생명주기에 얼마나 다른 애플리케이션 컴포넌트
(특별히, Activity, Service, 그리고 IntentReceiver)가 영향을 미치는가를 이해하는 것은 중요하다.
이러한 컴포넌트들을 정확하게 사용하지 않는다면, 시스템이 해당 애플리케이션이 중요한 작업을 수행
하는 동안 해당 프로세스를 종료시키는 결과를 야기할 수 있다.
프로세스 생명주기와 관련된 버그중 일반적인 예가 IntentReceiver가 onReceveIntent() 메쏘드내에서
Intent를 받을 때 쓰레드를 시작한 다음 해당 함수를 리턴하는 경우이다. 그러한 리턴이 발생하면,
시스템은 IntentReceiver가 더이상 활성화되어 있지 않다고 간주하고, 따라서 그 호스팅 프로세스가
더이상 필요하지 않다고 간주한다. (단지 다른 애플리케이션 컴포넌트가 그 안에서 활성화 되지 않는 한)
따라서, 시스템은 메모리 반환요청이 있는 어떤 시점에선 해당 프로세스를 종료시킬 수 있다. 이 문제를
해결하기 위한 해법은 시스템이 해당 프로세스 내에서 행해지고 있는 활성화된 작업이 여전히 존재한다는
것을 알도록 IntentReceiver로 부터 Service를 시작시키는 것이다.
To determine which processes should be killed when low on memory, Android places them into an
"importance hierarchy" based on the components running in them and the state of those components.
These are, in order of importance:
메모리가 부족할 때, 어떤 프로세스들이 종료되어야 하는가를 결정하기 위해서, 안드로이드는 프로세스를
그것안에서 실행되는 컴포넌트와 그러한 컴포넌트의 상태에 기반을 둔 "중요성 계층구조"에 추가합니다.
아래의 내용은 중요성과 관련된 순서입니다.
-
A foreground process is one holding an Activity at the top of the screen that the user is
interacting with (its onResume() method has been called) or an IntentReceiver that is
currently running (its onReceiveIntent() method is executing). There will only ever be a few
such processes in the system, and these will only be killed as a last resort if memory is so
low that not even these processes can continue to run. Generally at this point the device has
reached a memory paging state, so this action is required in order to keep the user interface
responsive.
foreground 프로세스는 사용자와 상호작용을 하고 있는 스크린의 최상위에 있는 Activity나 현재
수행되고 있는 IntentReceiver를 점유하고 있는 프로세스이다. 시스템에는 매우 작은 수의 그러한
프로세스들이 존재할 뿐이며, 이런 프로세스가 계속 실행 되기조차 어려운 최후의 메모리 부족
상태에서만 종료된다. 일반적으로 디바이스가 메모리 페이징 상태에 도달하는 시점에, 사용자
인터페이스에 대한 응답을 처리하기 위해서 그러한 행위가 요구된다.
-
A visible process is one holding an Activity that is visible to the user on-screen but not in
the foreground (its onPause() method has been called). This may occur, for example, if the
foreground activity has been displayed with a dialog appearance that allows the previous
activity to be seen behind it. Such a process is considered extremely important and will not
be killed unless doing so is required to keep all foreground processes running.
visible 프로세스는 사용자의 화면상에는 나타나지만 foreground 상태는 아닌 Activity를 점유하는
프로세스이다. 예를 들어 foreground activity 다이얼로그 형태로 그 뒤에 이전에 보여졌던 activity를
허용하면서 표시될때 이러한 것은 발생하게 된다. 그러한 프로세스는 극도록 중요하게 고려되며
더이상 그것을 수행하지 않을 때까지 종료되지 않으며, 모든 foreground 프로세스들을 실행 상태로
유지하는 것이 요구된다.
-
A service process is one holding a Service that has been started with the startService()
method. Though these processes are not directly visible to the user, they are generally doing
things that the user cares about (such as background mp3 playback or background network
data upload or download), so the system will always keep such processes running unless
there is not enough memory to retain all foreground and visible process.
service 프로세스는 startService() 메쏘드를 가지고 시작된 Service를 점유하고 있는 프로세스
이다. 이러한 프로세스는 사용자에게 직접적으로 보여지는 않지만, 이것은 일반적으로 사용자와
관련된 어떤 일을 일반적으로 수행하며, 시스템이 모든 foreground와 visibile 프로세스를 보유하기에
충분한 메모리가 존재하는 한, 시스템은 그러한 프로세스들은 항상 실행상태로 유지할 것이다.
-
A background process is one holding an Activity that is not currently visible to the user
(its onStop() method has been called). These processes have no direct impact on the user
experience. Provided they implement their activity life cycle correctly (see Activity for more
details), the system can kill such processes at any time to reclaim memory for one of the three
previous processes types. Usually there are many of these processes running, so they are
kept in an LRU list to ensure the process that was most recently seen by the user is the last
to be killed when running low on memory.
background 프로세스는 사용자에게는 현재 보여지지 않는 Activity를 점유하는 프로세스이다.
이러한 프로세스는 사용자에게 어떤 것도 직접적으로 영향을 미치지 않는다. activity 생명주기를
정확하게 구현하기 위해서 마련된 것이며, 시스템은 위의 3가지 프로세스 타입 중 한 가지를 위한
메모리 반환 요청이 있을 시에만 그러한 프로세스를 종료시킬 것이다. 일반적으로 많은 수의
이런 프로세스가 실행되고 있으며, 해당 프로세스들은 메모리 결핍 시 사용자에게 가장 최근에
보여진 것이 가장 마지막에 종료되는 절차를 확립하기 위해 LRU 리스트 상에서 유지된다.
-
An empty process is one that doesn't hold any active application components. The only
reason to keep such a process around is as a cache to improve startup time the next time a
component of its application needs to run. As such, the system will often kill these processes
in order to balance overall system resources between these empty cached processes and
the underlying kernel caches.
empty 프로세스는 어떤 활성화 된 애플리케이션 컴포넌트도 점유하지 않는 프로세스이다.
이러한 프로세스를 유지하고 있는 유일한 이유는 다음번에 해당 애플리케이션을 실행할 필요가
있을 때 시동(startup) 시간을 개선하기 위한 캐쉬로써 사용하기 위함이다. 그런 이유로, 시스템은
이러한 캐쉬화된 empty 프로세스들과 기반에 있는 커널 캐쉬들 사이에서 전반적인 시스템
균형을 유지하기 위해 이러한 프로세스들을 가끔 종료하게 된다.
When deciding how to classify a process, the system picks the most important level of all the
components currently active in the process. See the Activity, Service, and IntentReceiver
documentation for more detail on how each of these components contribute to the overall life cycle of
a process. The documentation for each of these classes describes in more detail how they impact
the overall life cycle of their application.
프로세스에 대한 분류방법을 결정할 때, 시스템은 프로세스내에서 현재 활성화 된 모든 컴포넌트 중에서
가장 중요한 레벨을 얻어냅니다. 프로세스의 모든 생명주기에 이러한 Activity, Service, 그리고 IntentReceiver
같은 컴포넌트의 각각이 얼마나 영향을 미치는 지에 대해서는 각각에 대한 보다 자세한 문서를 보기 바랍니다.
이러한 클래스들의 각각에 대한 문서는 해당 클래스들이 그것을 포함한 애플리케이션의 전체적인 생명주기에
얼마나 영향을 미치는가를 설명합니다. |
Life Cycle of an Android Application
