[4] 액티비티 라이프사이클 다루기 [1] 액티비티 시작하기

THIS LESSON TEACHES YOU TO

  1. Understand the Lifecycle Callbacks
  2. Specify Your App’s Launcher Activity
  3. Create a New Instance
  4. Destroy the Activity

YOU SHOULD ALSO READ

 

Unlike other programming paradigms in which apps are launched with a main() method, the Android system initiates code in an Activity instance by invoking specific callback methods that correspond to specific stages of its lifecycle. There is a sequence of callback methods that start up an activity and a sequence of callback methods that tear down an activity.

앱들이 main() 메서드에서 시작하는 일반적인 프로그래밍 패러다임과는 다르게도, 안드로이드 시스템은 액티비티 인스턴스에서 지정된 콜백 함수를 호출함으로써 코드를 초기화합니다. 그 콜백 메서드는 지정된 라이프사이클 단계에 상응하는 콜백 메서드입니다. 액티비티를 시작하는 콜백 메서드의 순서가 있고, 액티비티를 종료하는 콜백 메서드의 순서도 있습니다.

This lesson provides an overview of the most important lifecycle methods and shows you how to handle the first lifecycle callback that creates a new instance of your activity.

이번 수업은 가장 중요한 라이프 사이클 메서드들의 전반적인 정보를 제공합니다. 그리고 우리가 어떻게 첫번째 라이프사이클 콜백을 다루는지 보여줍니다. 우리 앱의 새로운 인스턴스를 생성하는 콜백 말이지요.

라이프사이클 콜백들 이해하기 – Understand the Lifecycle Callbacks


During the life of an activity, the system calls a core set of lifecycle methods in a sequence similar to a step pyramid. That is, each stage of the activity lifecycle is a separate step on the pyramid. As the system creates a new activity instance, each callback method moves the activity state one step toward the top. The top of the pyramid is the point at which the activity is running in the foreground and the user can interact with it.

액티비티가 살아있는 동안, 시스템은 라이사이클 메서드의 세트를 차례대로 호출합니다. 마치 계단 피라미드처럼 생겼지요. 각각의 액티비티 라이프사이클 스테이지가 계단처럼 분리되어 있습니다. 시스템이 새로운 액티비티 인스턴스를 생성하면, 각각의 콜백 메서드는 액티비티 스테이트를 한 스텝씩 꼭데기를 향해 옮깁니다. 피라미드의 꼭데기는 액티비티가 포어그라운드(가장 앞에서) 실행중이라는 것을 가리킵니다. 사용자가 직접 앱을 만날 수 있는 상태입니다.

As the user begins to leave the activity, the system calls other methods that move the activity state back down the pyramid in order to dismantle the activity. In some cases, the activity will move only part way down the pyramid and wait (such as when the user switches to another app), from which point the activity can move back to the top (if the user returns to the activity) and resume where the user left off.

사용자가 액티비티를 떠나기 시작할 때, 시스템은 다른 메서드를 호출합니다. 그 메서드는 액티비티를 해체하기 위해서 액티비티 스테이지를 피라이드에서 한 칸 내려오게 합니다. 일부 케이스에서는, 액티비티는 피라미드에서 내려오는 일부 단계만 이동할 것입니다. 그리고 대기합니다 (유저가 다른 앱으로 전환했을 때 처럼), 액티비티가 뒤로 돌아가 꼭데기로 돌아갈 수 있는 곳 (만약 사용자가 그 액티비티로 다시 돌아돈다면( 그리고 사용자가 떠났던 부분부터 다시 시작할 수 있는 곳에서

Figure 1. A simplified illustration of the Activity lifecycle, expressed as a step pyramid. This shows how, for every callback used to take the activity a step toward the Resumed state at the top, there’s a callback method that takes the activity a step down. The activity can also return to the resumed state from the Paused and Stopped state.

그림 1. 계단 피라미드로 표현한 액티비티 라이프사이클 도식.

Depending on the complexity of your activity, you probably don’t need to implement all the lifecycle methods. However, it’s important that you understand each one and implement those that ensure your app behaves the way users expect. Implementing your activity lifecycle methods properly ensures your app behaves well in several ways, including that it:

액티비티의 복잡도에 따라서, 모든 라이프사이클 메서드를 구현할 필요가 없을 수도 있습니다. 하지만 각각의 메서드를 이해하는 것은 중요합니다. 또한 사용자가 기대하는 방식으로 앱이 동작하는 것 역시 중요합니다. 우리의 액티비티 라이프라시클 메서드를 구현하는 것은, 우리의 앱 동작이 다음과 같이 여러 방식으로 동작할 수 있다는 것을 보장합니다.

 

  • Does not crash if the user receives a phone call or switches to another app while using your app.
  • Does not consume valuable system resources when the user is not actively using it.
  • Does not lose the user’s progress if they leave your app and return to it at a later time.
  • Does not crash or lose the user’s progress when the screen rotates between landscape and portrait orientation.
  • 충돌하지 않습니다 : 우리 앱을 사용하고 있다가 전화를 받거나 다른 앱으로 전환 할 때
  • 시스템 리소스를 잡아먹지 않습니다 : 사용자가 시스템 리소스를 사용하지 않을 때
  • 유저의 프로그레스를 놓치지 않습니다 : 유저가 앱을 떠나거나 다시 돌아올 때
  • 유저의 프로그레스가 충돌이 나거나 그것을 놓치지 않습니다 : 스크린이 가로, 세로로 돌아갈 때

As you’ll learn in the following lessons, there are several situations in which an activity transitions between different states that are illustrated in figure 1. However, only three of these states can be static. That is, the activity can exist in one of only three states for an extended period of time:

여러분이 다음 레슨을 배움에 따라, 위의 그림 1처럼 액티비티가 다른 상태로 전환되는 여러 상황이 있습니다. 하지만 단지 3개의 상태만 정적일 수 있습니다. 다시 말해, 액티비티는 다음 3개의 상태에서만 존재할 수 있습니다.

Resumed
In this state, the activity is in the foreground and the user can interact with it. (Also sometimes referred to as the “running” state.)
이 상태에서, 액티비티는 맨 앞에 있습니다. 그리고 사용자는 이 액티비티와 상호작용 할 수 있습니다.
Paused
In this state, the activity is partially obscured by another activity—the other activity that’s in the foreground is semi-transparent or doesn’t cover the entire screen. The paused activity does not receive user input and cannot execute any code.
이 상태에서, 액티비티는 다른 액티비티에 의해서 살짝 뒤로 물러나 있습니다—포어그라운드로 나오는 다른 액티비티는 반투명이거나 전체를 덮지는 않습니다. 일시정지된 액티비티는 유저의 입력을 받지 않습니다. 또한 액티비티의 어떠한 코드도 실행되지 않습니다.
Stopped
In this state, the activity is completely hidden and not visible to the user; it is considered to be in the background. While stopped, the activity instance and all its state information such as member variables is retained, but it cannot execute any code.
이 상태에서, 액티비티는 완전히 가려져서 사용자에게 보여지지 않습니다; 백그라운드에 놓이게 된 것으로 간주됩니다. stopped 인 동안에, 액티비티 인스턴스와 이 멤버변수같은 액티비티의 상태 정보는 유지됩니다. 하지만 액티비티의 어떠한 코드도 실행되지 않습니다.

The other states (Created and Started) are transient and the system quickly moves from them to the next state by calling the next lifecycle callback method. That is, after the system calls onCreate(), it quickly calls onStart(), which is quickly followed by onResume().

다른 상태 (Created 와  Started)는 일시적입니다. 그리고 시스템은 빠르게 이 것들을 다음 상태로 보냅니다. 다음 라이프사이클의 콜백 메서드를 사용해서요. 다시 말해, 시스템이 onCreate() 을 호출하고 나서,  onStart() 이 불리고 또 onResume()가 호출됩니다.

That’s it for the basic activity lifecycle. Now you’ll start learning about some of the specific lifecycle behaviors.

이 것이 기초적인 액티브 라이프사이클입니다. 이제 우리는 특정 라이프사이클의 동작에 대해서 알아봅니다.

우리 앱의 런처 액티비티 지정하기 – Specify Your App’s Launcher Activity


When the user selects your app icon from the Home screen, the system calls the onCreate() method for theActivity in your app that you’ve declared to be the “launcher” (or “main”) activity. This is the activity that serves as the main entry point to your app’s user interface.

사용자가 홈스크린에서 우리의 앱 아이콘을 선택했을 때, 시스템은 우리 앱에 있는 onCreate() 메서드를 부르게 됩니다. 이 것은 우리가 런처 (또는 메인) 액티비티라고 선언해 뒀던 것이지요. 이 액티비티는 메인 엔트리 포인트를 제공하는 액티비티입니다.

You can define which activity to use as the main activity in the Android manifest file, AndroidManifest.xml, which is at the root of your project directory.

어떤 액티비티를 메인 액티비티로 할 지 정할 수 있습니다. 안드로이드 매니페스트 파일에서 정합니다. 우리 프로젝트의 root 디렉토리에 있습니다.

The main activity for your app must be declared in the manifest with an <intent-filter> that includes the MAINaction and LAUNCHER category. For example:

이 메인 액티비티는 반드시 매니페스트파일 안에 선언되어야 합니다. 선언은 <intent-filter>라는 태그를 사용합니다. 이 태그 내에 MAIN 액션과 LAUNCHER 카데고리를 포함해야 합니다. 예를 들어:

<activity android:name=".MainActivity" android:label="@string/app_name">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Note: When you create a new Android project with the Android SDK tools, the default project files include anActivity class that’s declared in the manifest with this filter.

주의 : 우리가 안드로이드 프로젝트를 안드로이드 SDK 툴을 이용해서 생성할 때, 기본 프로젝트 파일은 Activity 클래스를 포함합니다. 액티비티 클래스에서는 이 필터(인텐트필터 인 듯 합니다)와 함께 매니패스트가 선언되어 있습니다.

If either the MAIN action or LAUNCHER category are not declared for one of your activities, then your app icon will not appear in the Home screen’s list of apps.

MAIN 액션 및 LAUNCHER 카데고리가 우리 액티비티 중 한 곳에서 선언되지 않았다면, 우리 앱 아이콘은 홈 스크린에서 사라져버립니다.

새 인스턴스 생성 – Create a New Instance


Most apps include several different activities that allow the user to perform different actions. Whether an activity is the main activity that’s created when the user clicks your app icon or a different activity that your app starts in response to a user action, the system creates every new instance of Activity by calling its onCreate() method.

매부분의 앱은 몇 개의 액티비티를 포함합니다. 이 액티비티는 사용자에게 각각 다른 액션을 수행하도록 합니다. 액티비티가 메인 액티비티(유저가 앱 아이콘을 클릭할 때 생성된)던  다른 액티비티(사용자 액션에 의해서 시작된)던간에, 시스템은 액티비티의 새로운 인스턴스를 onCreate() 메서드를 통해서 생성합니다.

You must implement the onCreate() method to perform basic application startup logic that should happen only once for the entire life of the activity. For example, your implementation of onCreate() should define the user interface and possibly instantiate some class-scope variables.

액티비티의 총 생애 주기 중 단 한 번 일어나는, 기초적인 어플리케이션 시작 로직을 수행하기 위해, 반드시 onCreatea()메서드를  구현해야 합니다. 예를 들어 우리의 onCreate() 구현은 사용자 인터페이스를 정의하고, 일부 클래스범위 변수를 만들어야 할 것입니다.

For example, the following example of the onCreate() method shows some code that performs some fundamental setup for the activity, such as declaring the user interface (defined in an XML layout file), defining member variables, and configuring some of the UI.

예를 들어, 다음 onCreate() 메서드의 예제는,  액티비티를 위한 필수기초적인 셋업을 수행하는 코드를 보여줍니다. 예를 들어 유저 인터페이스 선언(XML 레이아웃 파일에 정의되어 있는), 멤버 변수 선언, 일부 UI 선언 등이 있지요.

TextView mTextView; // Member variable for text view in the layout

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // Set the user interface layout for this Activity
    // The layout file is defined in the project res/layout/main_activity.xml file
    setContentView(R.layout.main_activity);
    
    // Initialize member TextView so we can manipulate it later
    mTextView = (TextView) findViewById(R.id.text_message);
    
    // Make sure we're running on Honeycomb or higher to use ActionBar APIs
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        // For the main activity, make sure the app icon in the action bar
        // does not behave as a button
        ActionBar actionBar = getActionBar();
        actionBar.setHomeButtonEnabled(false);
    }
}

Caution: Using the SDK_INT to prevent older systems from executing new APIs works in this way on Android 2.0 (API level 5) and higher only. Older versions will encounter a runtime exception.

주의 : SDK_INT 를 오래된 시스템울 기존 API들의 동작으로부터 보호하기 위해서 사용하는 것은 안드로이드 2.0 이상일 때만 가능합니다. 오래된 버전은 런타임 예외가 발생할 것입니다.

Once the onCreate() finishes execution, the system calls the onStart() and onResume() methods in quick succession. Your activity never resides in the Created or Started states. Technically, the activity becomes visible to the user when onStart() is called, but onResume() quickly follows and the activity remains in the Resumed state until something occurs to change that, such as when a phone call is received, the user navigates to another activity, or the device screen turns off.

일단 onCreate()의 실행이 끝나게 되면, 시스템은 onStart()와 onResume() 메서드를 빠르게 호출하게 됩니다. 우리의 액티비티는 결코 Created나 Started 상태에 머물러 있지는 않습니다. 기술적으로, 액티비티는 사용자에 의해 onStart()가 불릴 때 눈에 보이게 되는데요, onResume()은 빠르게 그 뒤에 실행됩니다. 그리고 액티비티는Resumed 상태로 남게 됩니다. 이 상태는 무언가 이 상태를 바꾸기 위한 것이 있기 전까지는 그대로 유지가 됩니다. 예를 들어 전화가 걸려 오거나, 사용자가 다른 액티비티를 실행하거나, 디바이스 스크린이꺼지거나 할 때까지는 그대로 그 상태 유지합니다.

In the other lessons that follow, you’ll see how the other start up methods, onStart() and onResume(), are useful during your activity’s lifecycle when used to resume the activity from the Paused or Stopped states.

다음 레슨에서는,Paused 나 Stopped 상태였을 때 액티비티를 재시작할 때,  start up 메서드(onStart() 나 onResume() 메서드)가 액티비티 라이프 사이클 내에서 어떻게 유용하게 쓰이는지 알아봅니다.

Note: The onCreate() method includes a parameter called savedInstanceState that’s discussed in the latter lesson about Recreating an Activity.

주의 : *****

Figure 2. Another illustration of the activity lifecycle structure with an emphasis on the three main callbacks that the system calls in sequence when creating a new instance of the activity: onCreate(), onStart(), and onResume(). Once this sequence of callbacks complete, the activity reaches the Resumed state where users can interact with the activity until they switch to a different activity.

그림 2.  액티비티 라이프사이클 구조를 설명하는 또 다른 그림. 3개의 메인 콜백을 강조하였으며, 액티비티의 새로운 인스턴스가 생성될 때 시스템이 순서대로 호출합니다 : onCreate(), onStart(), onResume(). 일단 한 번 이 콜백 순서가 완료되며느 액티비티는 Resumed 상태가 되고, 사용자는 이 액티비티가 다른 액티비티로 변경될 때 까지 인터랙티브 할 수 있습니다.

액티비티 종료 – Destroy the Activity


While the activity’s first lifecycle callback is onCreate(), its very last callback is onDestroy(). The system calls this method on your activity as the final signal that your activity instance is being completely removed from the system memory.

액티비티의 첫 라이프사이클 콜백이 onCreate() 인 것 처럼, 맨 마지막 콜백은 onDestroy()입니다. 시스템은 이 메서드를 우리의 액티비티에서 호출합니다.  우리의 액티비티 인스턴스가 완벽하게 시스템으로부터 제거되도록 하는 final 시그널입니다.

Most apps don’t need to implement this method because local class references are destroyed with the activity and your activity should perform most cleanup during onPause() and onStop(). However, if your activity includes background threads that you created during onCreate() or other long-running resources that could potentially leak memory if not properly closed, you should kill them during onDestroy().

대부분의 앱들은 이 메서드를 구현할 필요가 없는데요, 왜냐하면 로컬 클래스 레퍼런스들이 액티비티와 함께 종료되고, 우리의 액티비티도 대부분의 클린업이 onPause()와 onStop()동안 수행되기 때문입니다. 그러나 만약 우리의 액티비티가 백그라운드 스레드를 포함하고 있다면 잠재적으로 메모리 릭이 발생할 수 있습니다. 반드시 onDestroy() 메서드에서 그 것들을 kill 해 줘야 합니다.

@Override
public void onDestroy() {
    super.onDestroy();  // Always call the superclass
    
    // Stop method tracing that the activity started during onCreate()
    android.os.Debug.stopMethodTracing();
}

Note: The system calls onDestroy() after it has already called onPause() and onStop() in all situations except one: when you call finish() from within the onCreate() method. In some cases, such as when your activity operates as a temporary decision maker to launch another activity, you might call finish() from withinonCreate() to destroy the activity. In this case, the system immediately calls onDestroy() without calling any of the other lifecycle methods.

주의 : 시스템은 onDestroy()메서드를 onPause()와 onStop() 메서드가 이미 호출된 후에 호출하는데요, 예외가 하나 있습니다.onCreate()메서드 내에서  finish() 를 호출할 때 예외적이지요. 어떤 상황에서는, 예를 들어, 우리의 액티비티가 임시적인 디지전메이커로써 다른 액티비티를 호출하도록 동작할 때, 우리는 finish()를 onCreate()함수 내에서 액티비티를 죽이기 위해서 호출할 수 있겠지요. 이 경우, 시스템은 즉각적으로 onDestroy() 메서드를 호출합니다. 어떠한 다른 라이프사이클 메서드 동원 없이 말이죠.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중