반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

카테고리

Udacity 강좌 - Lesson 4 - Activity

2016. 10. 23. 02:12 | Posted by 솔웅


반응형

4과에서는 Activity Persistence Storage (SQLite) 다룹니다.

 

우선 액티비티를 보겠습니다.

 

안드로이드에서는 주로 하나의 화면이 하나의 액티비티 입니다.

 

선샤인 내에서도 여러 화면이 있습니다. 그래서 여러 화면을 다니다 보면 디바이스 내에 여러개의 액티비티가 있게 됩니다.

 

선샤인을 사용하다가 다른 앱들도 사용하게 되는데요. 이러면 앱들의 액티비티들도 디바이스내에서 작동하게 됩니다.

 

디바이스 내에는 하나의 화면만 보이겠지만 뒤에 지금까지 실행했던 화면들이 숨어 있게 됩니다.

 

이럴 화면들을 계속 띄우다 보면 디바이스의 메모리가 부족해 때가 있습니다.

 

사용자게 의해서이건 시스템에 의해서이건 특정 Activity들이 Kill 있습니다.

 

이렇게 액티비티가 화면에 떴다가 Background 있다가 Kill 되고 하는 과정들은 Activity Lifecycle 보면 이해하기 쉽습니다.

 

Activity와 관련해서 좀 더 자세한 사항을 알고 싶으면 이곳에서 보시면 됩니다.



http://developer.android.com/training/basics/activity-lifecycle/starting.html



위 그림에 나와있는 Android Activity Life Cycle을 보겠습니다.
우선 처음에 앱을 시작하면 onCreate가 실행 되서 앱이  Create 됩니다.


그리고 나서 onStart가 실행되고 나면 비로서 화면이 디바이스에 보기게 됩니다.
화면이 보이는 상태가 Active 상태인데요. 이 때 onResume을 거쳐서 Active됩니다.


다음 단계는 Paused 상태인데요.
이 상태는 Alert 화면이 떴다던가 다른 화면이 떴지만 반투명 상태라서 이전 화면이 현재화면 뒤에 보이게 되는 상태입니다.


그러니까 완전하게 눈에 보이지 않게 되는 상황이 아니라 어스름하게라도 보이는 상황인데요.
이때 그 Activity는 onPause를 거쳐서 Paused한 상황이 됩니다.


이 상황에서 다시 화면에 보이게 될 수 있는데요 이때는 onResume을 거쳐서 화면이 활성화 됩니다.
Paused상태에서 다른 화면이 완전히 덮어서 사용자 눈에 보이지 않는 상황이 될 수도 있는데요.
그 때는 Stopped 상태입니다. onStop 과정을 거쳐서 이 상태가 됩니다.


해당 Activity는 눈에 보이지는 않지만 Background에서 계속 살아 있습니다.


즉 일정정도 메모리가 할당 돼 있는 상황입니다.


여기서 다시 이 뒤의 화면을 foreground로 불러올 경우도 있습니다. 이때는 Restart를 하게 됩니다.
이땐 onRestart가 실행 됩니다.


아까 onResume은 Paused 상태에서 실행 되는 것이고 이 onRestart는 Stopped상태에서 실행되는 것입니다.


onRestart가 실행되면 해당 액티비티가 다시 화면에 보이게 됩니다.


onStart를 거쳐서 보이게 되고 onResume을 거쳐서 활성화 됩니다.


한편 Stopped 상태에서 Background에서도 완전히 사라질 수도 있는데요.


즉 메모리에서 해당 Activity가 사라지게 되는 상황은 onDestroy를 거쳐서 발생됩니다.


해당 Activity가 완전히 Destroy되는 거죠.


이 Activity Life Cycle 을 잘 이용해서 적당한 때에 적당한 정보를 저장하고 다시 불러오고 연결을 끊고 재연결하고 하는 작업들을 잘 해야 앱이 무난하게 작동하게 됩니다.


게임을 하다가 상태정보를 저장하지도 않고 Destroy되면 그 다음에 앱을 시작하면 벌써 깼던 stage를 다시 새로 해야 되는 상황이 발생할 수 있으니까요.



그러면 Device 가 Rotation이 될 때는 어떤 과정을 거칠까요?
앱에서 대개 가로 화면과 세로 화면이 다른 경우가 있는데요. 이 화면 전환을 할 때는 어떤 과정을 거칠까요.
 
onPause - onStop - onDestroy - onCreate - onStart - onResume

그 때는 위와 같은 과정을 거칩니다.
 
Memory가 다해 시스템이 강제로 백그라운드 액티비티를 터미네이트 할 경우를 대비해서 관련된 작업을 해 둬야 합니다.
밧데리가 다 돼서 강제로 터미네이트 되는 경우도 있습니다. 이럴 때도 관련된 작업을 해 둬야 합니다.
(onPause 나 onStop 등등에)
 
Sensor Listeners, Location Updates, Dynamic Broadcast Receivers, Game Physics Engine
이런 것들은 onPause 나 onStop 시 disconnect 시키거나 stop 시켜야 합니다.
 


시스템에 의해 강제로 종료될 때를 대비해서 상태 정보는 onPause시에 저장하고 다시 onCreate시에 restore 합니다.


Active -> onSaveInstanceState -> onPause -> Terminated
-> onCreate -> onRestoreInstanceState



여기까지가 Activity와 관련된 이론들 이었습니다.
이후에는 데이터를 저장하는 것과 관련된 내용이 있습니다.


예를 들어 현재 작업하고 있는 Sunshine앱에서...
현재는 날씨를 표시할 때마다 날씨 웹싸이트에 접속해서 화면에 뿌려 줍니다.


하지만 이러면 네트워크에 접속하고 처리하는 과정을 매번 거치게 되서 시간이 많이 걸릴 수 있습니다.
네트워크 사정에 따라서 화면이 아주 늦게 뜰 수도 있구요.


또 밧데리 소모도 더 빨리 됩니다.


해당 서버의 접속량도 아주 많아 질 거고...


비행기 안이라던지 네트워크를 사용할 수 없는 경우에는 아예 날씨를 볼 수가 없습니다.
 


이런 이유로 한번 날씨를 받으면 이것을 저장해 뒀다가 일정기간 사용을 하면 위와 같은 단점들을 극복할 수 있습니다.


 
이럴때 모바일 데이터베이스인 SQLite를 사용하게 됩니다.
자세한 내용은 다음 글에서 이어 나가겠습니다.



반응형