Component - Activity

Activity 역할

• 사용자와 Application의 상호작용하기 위한 진입점이다.
• UI를 포함한 하나의 화면을 말한다.
• 여러 Activity가 있을 경우 서로 간 독립적이다. (이에 따라 Activity -> Activity 전환 시 데이터를 주고받을 때 별도로 코드를 추가해야 한다.)
• 다른 Application과 상호작용을 할 때 진입점이기도 하다. Camera App <-> Gallery App 간의 전환 시 Intnet를 통하여 처리한다. ex(https://developer.android.com/training/basics/intents?hl=ko)
• System에 실행중인 Process 중 현재 사용자가 보고 있는 화면(Activity)을 Hosting 중인 Process를 계속 실행하도록 도와준다.

음.. 이말은 좀 정리를 할 필요가 있다.. 

 

우리는 앱을 크게 사용자가 사용 중인 상태와 사용 중이지 않은 상태 2가지로 나눌 수 있다.

간단히 Process의 상태(Application의 상태)가 Background 인지 Foreground 인지로 나눌 수 있다는 말이다.

(Process의 상태는 foreground process, visible process, service process , cache process로 세분화할 수 있다.)

 

보통 Application을 실행하게되면 Manifest에 작성된 Component들을 확인하면서 단일 Linux 프로세스 및 단일 스레드로 Application을 실행하게 된다.(외에도 Component별로 Process를 실행시킬 수 있지만 일일이 관리해야 하기 때문에 되도록이면 단일 프로세스를 지향한다.  https://developer.android.com/guide/components/processes-and-threads#Processes)

 

실행된 Process는 더 이상 사용되지 않더라도 System에서 메모리를 회수하기 전까지 자체적으로 종료가 되지않는다. (Background Process가 발생됨) 그러나 System에서 메모리가 부족하다고 판단되었을 때 가장 오래된 Process 순으로 정리를 하여 메모리를 회수한다.(오래된 cache process 상태일 경우 정리됨)

 

위와 같은 상황때문에 Process는 실행 중인 Component를 추적하게 되고 해당 Component의 상태에 따라 Process를 여러 상태로 변경될 수 있는데 위와 같이 Cache Process 상태는 흔히 사용자에게 표시되지 않고 있는(lifecycle = onStop()이 호출된) 한 개 이상의 Activity Instance를 포함하고 있을 경우 해당된다.

 

위 글을 예시로 표현하면 다음과 같다.

Manifest에 작성된 Component가 MainActivity 하나이고 앱을 실행하였다.  그 후 뒤로가기를 하여 Activity를 stop 시켰다. 그러면 Process는 Cache Process(Background 상태)로 변환되고 Stop 된 Activity의 Instance를 Process는 기억하고 있다가 System에서 메모리 정리가 필요한 경우 해당 Process가 오래되었을 시 정리해 준다.

 

이어서 가보자..

 

• 이전에 사용한 Process에 사용자가 중단(onStop) 하였던 Activity가 있다는것을 알려주고 해당 Process를 유지하는데 더 높은 순위를 둔다.

이 말도 설명하고 넘어가야할 듯하다.

 

Process를 유지하는데 더 높은 순위를 준다는 것은 그만큼 System에서 메모리 정리 시 Cache Process 순위를 뒤로 미루어 준다는 말이다. 이는 다음과 같은 상황에 유리하게 작용을 한다.

 

보통 사용자들은 Application을 실행할 때 되도록 빠르게 실행되기를 원한다. (버벅거리거나 Splash 화면에서 오래 걸릴 경우 짜증을 내는.. 킄..)

 

Application은 Cold, Warm, Hot 상태를 가지고 시작할 수 있다. 이는 Application이 실행되는 시간에 영향을 준다. 

각 상태를 간단하게 설명하자면 다음과 같이 볼 수 있다.

 

Cold Start

Cold Start 이전에는 System의 Process에서 Application의 Linux Process를 만들지 않는 상태이며 스마트폰의 재부팅 혹은 Application이 메모리에서 정리되었을 경우에 Cold Start로 Application이 실행됨을 말한다. 이는 간단히 말해 Application이 처음부터 시작하는 것을 의미한다.

 

Cold Start 시 System은 다음 작업을 실행한다.

1. Application Loading and Application Start
2. Application Start 직후에 빈 화면 표시 (화이트 색상으로 표시)
3. Creating the Application Process

 

System에서 Application Process를 만들고 나면 곧바로 Application Process는 다음 작업을 실행한다.

1. Creating the Application Object
2. Main Thread 실행
3. Main Activity 실행
4. Inflating View 실행
5. 화면에 layout 배치
6. View 그리기 실행

위 6번째 작업을 완료하면 Application Process는 System Process에 있는 빈 화면과 현재 그려진 화면을 교환한다.

이후에는 사용자가 앱을 사용하는 방식으로 정리할 수 있다.

 

Hot Start 

• System이 Activity를 Foreground로 호출하는 것을 의미한다.
• Application의 모든 Activity Component가 메모리에 유지되어 있으면 object 초기화, layout Inflating, 렌더링 작업을 하지 않아도 되기에 Cold Start 보다 훨씬 빠르고 Overhead가 낮다.
• 단, onTrimMemory()와 같은 메모리에 손실이 있을 경우 별도로 대응을 해주어야 한다.
• System Process에서는 Application Process가 Activity 렌더링 작업이 완료될 때까지 Cold Start 화면 표시와 동일하게 빈 화면으로 보인다.

Warm Start

• Application이 처음부터 시작하지만 Activity lifecycle 중 onCreate()에서 Bundle 객체인 saveInstancestate를 사용하여 Activity를 실행하는 경우를 의미

앱 시작 시간  |  Android 개발자  |  Android Developers

다시 한번 언급하자면 위와 같은 Application 실행 상태에 따른 문제로 Cache Process 순위를 뒤로 미루어 준다는 점은 좋은 효과를 줄 수 있다.

 

다시 이어서 가보자..

 

• Activity를 통해 Application이 Process를 종료하도록 도와주고 사용자가 다시 Activity의 이전 상태를 복원해주고 돌아갈 수 있게 해 준다.

이건 위에 있는 Cache Process 개념을 이해하고 있으면 어렵지 않게 이해할 수 있다. 그런데 이전 상태를 복원해준다. 이 말을 짚고 넘어가자.

 

간단하게 말해서 Activity는 UI를 담는 Class라고 볼 수 있다. 그러면 이전 상태를 복원한다라는 말은 UI 상태를 저장하였다가 다시 불러온다 라는 말과 맥락이 비슷하다고 볼 수 있다.

 

이에 개발자들은 ViewModel의 SavedStateHandle, Activity의 onSaveInstanceState(), Local 저장소(sqlite, room)등을 사용하여 Application 및 Activity의 전환되는 과정에서 UI 상태를 저장하고 다시 불러올 수 있도록 설계할 수 있다.

 

위 3가지 방법을 사용할 때는 다음 3가지를 유의 하자.

• UI 구성에 필요한 데이터가 얼마나 복잡한지
• 메모리 사용량 대비 어떤 방법을 사용하였을 때 검색 속도가 효율적인지
• 사용자가 어떤 방식으로 UI 상태를 종료하였고 언제 다시 시작하는지

위 3가지 항목을 유의해서 사용해야 하는 이유는 다음과 같이 각각 기준이 다르기 때문이다.

	ViewModel	SaveInstanceState	Repository
UI 상태를 저장하는 저장소 위치	메모리 안에 저장	디스크에 직렬화하여 저장	디스크 또는 네트워크 통신을 통해 저장
구성 변경시에도 유지 여부 (System language 변경, background 전환, 화면 rotation, 화면 분할 등등)	유지됨	유지됨	유지됨
Process 중단 시에도 유지 여부	유지되지 않음	유지됨	유지됨
사용자가 onDestroy() or onFinish()를 호출하여 종료하였을 경우에도 유지되는 지	유지되지 않음	유지되지 않음	유지됨
저장할 수 있는 데이터에 대한 제한요소	복잡한 객체도 가능하지만 사용 가능한 메모리에 의해 공간이 제한적이다.	primitive types (우리가 흔히 사용하는 int float string dobule 등등의 타입) 및 String type과 같은 단순하고 작은 객체만 가능하다. (Bundle 객체임)	디스크 공간 또는 네트워크 리소스에서 검색하는 비용/시간에 의해서만 제한적이다.
읽기 / 쓰기 소요 시간	메모리 접근 시 빠름	데이터의 직렬화 및 역직렬화 작업 후 디크스에 접근해야하기에 느리다.	디스크 접근 및 네트워크 트랜잭션이 필요하기에 느리다.

 

위에 있는 특성 중 하나인 이전 상태를 복원해준다.라는 말은 Activity의 SaveInstanceState를 사용하여 복원해준다.라고 생각하면 될 듯하다.