버그 잡이

[Udacity android with kotlin]4. LifeCycle #안드로이드 생명주기 본문

안드로이드

[Udacity android with kotlin]4. LifeCycle #안드로이드 생명주기

버그잡이 2020. 4. 10. 12:17

(3번을 패스하고 4번으로 넘어갔다. 3번은 navigation인데 아직 나의 이해가 부족해 기회가 되면 나중에 다시 정리해서 올려야 겠다.)

 

4번째 레슨은 바로 생명주기이다.

아직 면접을 봐보지는 않았지만 안드로이드 개발자 면접 필수 질문으로 등장하는 것이 '생명주기'라고 한다.

다음 질문에 답해보자.

 

 

"startActivity 메소드를 실행했을대 A(현재 액티비티), B(다음 액티비티)의 생명주기 변화는?"

 

 

'음... A pause, A stop, B create, B start, B resume 아닌가?' 라고 생각했었다.

 

정답은

 

A pause , B create, B start, B resume, A stop

 

두번째 액티비티가 포커스를 받은 이후에 이전 액티비티가 사라지는 것이었다.

 

 

  왜 onStop은 나중에 호출될까?

 

피호출자(B)가 투명하거나 화면을 일부만 덮는 액티비티라면 호출자의 onStop()을 호출하지 않는데, 

피호출자가 뜨고 난 후에야 onStop()이 필요한지 알 수 있기 때문이다.

 

 

 

 

"back버튼을 눌러 다시 B에서 A로 화면전환한다면?"

 

B pause, A restart, A start, A resume, B stop, B destroy 

 

이것도 마찬가지로 다음 액티비티가 포커스를 받은 후에 사라진다.

한가지 더 특이점이 있다면 stop 이후에는 create가 아니라 restart가 호출된다.

 

 

 

생명주기가 중요하다고 하지만 나는 사실 잘 이해하지 못 하고 있었던 것이다.

그렇다면 udacity는 생명주기의 어떤 부분에 대해서 이야기 하는가?

(기본적인 생명주기의 개념은 넘어가고 내가 새롭게 알게 된 부분과 놓치고 있었던 부분에 대해서만 정리하고자 한다.)

 

 

 

 

Timber 라는 로그 찍는 것을 도와주는 라이브러리가 있다.

 

Log.d(TAG, "  ")로 그냥 로그를 찍어도 되지만 Timber를 사용하면 다음과 같은 장점이 있다.

 

1. TAG를 자동으로 생성해준다.

2. 앱 배포시 관련 로그가 뜨지 않도록 설정할 수 있다.

 

사실 두번째 장점이 큰 것 같다. 규모가 큰 앱이라면 Log를 언제 다 지우겠는가...

 

 

 

LifeCycleObserver를 이용하여 생명주기를 설정할 수 있다.

 

특정 메소드가 실행될 생명주기를 어노테이션 형식으로 직접 지정해줄 수 있는 라이브러리다.

 

사용법

1. 아래와 같이 LifcycleObserver 상속 받고 초기화

  •  

 

2. 메서드가 실행되길 원하는 생명주기를 어노테이션 형식으로 표시

    • 안드로이드 시스템이 어노테이션을 보고 해당 메서드를 실행시켜주는 .

 

3. 원하는 액티비티에 해당 사항 전달하기

 

 

 

개발자가 생명주기 관련 직면하는 두가지 문제를 해결하자

 

1. Configuration change

    - 화면의 구성이 변하는 경우(ex_ 가로/세로 화면 전환)

2. Process Shutdown

    - 안드로이드 시스템의 메모리가 부족할 경우 백그라운드에 있는 앱을 파괴하는 것

 

 

onSaveInstanceState / onRestoreInstanceState와 생명주기를 활용하면 위와 같은 문제를 해결할 수 있다.

 

그런데 나도 예전에 onSaveInstance를 사용해서 화면 전환 문제를 해결하려고 했던 적이 있다. 원인이 잘 기억은 안나는데 그때 내가 원하는 문제를 잘 해결하지 못해서 shared preference로 사용했던 기억이 있다. 

(강의에서 지적하는 saveInstance의 문제점은 용량 제한이 있어 이 용량을 넘길 경우 에러가 날 수 있다는 점이다.)

 

개인적으로는 saveInstance보다 shared를 쓰는 것이 데이터를 복원하기에 더 깔끔한 방법인 것 같다.

  

그리고 최근 LiveData가 나오고 이를 통해서 데이터가 자동 복원 되는 상황에서 생명주기가 점점 덜 사용되는 방향으로 코딩이 발전하지 않을까 싶다.(다음 chapter가 viewmodel + livedata인 것을 보면 나의 이런 생각에 대한 답을 좀 얻을 수 있을 것 같다.)

 

 

 

 

 

*기타

 

글을 쓰다 보니 아래와 같은 질문이 들었다.

 

"생명주기를 왜 알아야 하는가?"

- 데이터 복원(Configuration change, Process shutdown)

- 데이터 최신화(다른 액티비티에서 데이터 수정하고 돌아왔을때)

 

또 뭐가 있을까? 찬찬히 생각해보자...

 

 

반응형
Comments