KIT라는 곳에서 2010년도에 발표된 Analysis of the Android Architecture에 대해 번역을 한 글입니다.
원본은 http://os.ibds.kit.edu/downloads/sa_2010_braehler-stefan_android-architecture.pdf이며, 중간중간 개인적인 주석은 () / *로 처리하겠습니다.
간단하게 아키텍쳐를 이해하는데 도움을 얻으려 번역을 하고 공유하려 합니다.
(일부 오역 및 의도가 잘못 전달 되었을 수도 있습니다. 양해부탁드립니다)
2.3.3 Intents, Intent filters and receivers
CP와는 다르게 이 세가지의 컴포넌트타입(activities, services, broadcast receivers)는 intent와 연관이 있다. Intent는 메세지를 동기화하여 보내게 된다.
메세지는 액션을 포함하고 수행한다. 예를 들어 ACTION_EDIT, ACTION_VIEW, 혹은 ACTION_TIME_TICK등의 broadcast를 말할 수 있다. 액션과 더불어 메세지는 URI를 제공한다 URI는 액션을 통해 주고받는 데이터로 설명할 수 있다. 또한 이 Intent는 category를 포함하며, type, compenent, extra data, flag등이 있다.
액티비티는 onNewIntent()가 호출될때, 서비스는 onBind() 호출 될 때, 이러한 경우 안드로이드는 intent를 통해 정보를 주고 받는다. (쉽게 생각해서 '의도'라고 생각하면 좋을 듯 하다.) Broadcast는 context.sendBroadcast()로 사용된다. 받는 쪽에서는 onReceive()를 통해 register된 filter에 의해 자신이 받을 Intent를 정의하고 수신하게 된다. 이런 filter list들은 application내에 있는 manifest file에서 등록이 가능하며, (액티비티나 서비스도 가능하다) 등록이 된 후에 수신을 받기 때문에, 앱이 시작된 이후부터 수신이 가능해진다.
2.3.4 Content Provider
안드로이드 어플리케이션의 데이터 저장 및 검색은 content provider로 제공이 된다. 이런 provider들은 서로 다른 앱끼리의 data공유가 가능하며, 권한이 있다면 데이터를 가져오고 수정할 수 있다. 안드로이드는 default provider(이미지, 비디오, 연락처, 환경설정 등 android.provider 패키지 내에 있는 것들)를 제공한다.
ContentRessolver Query를 사용하면 ContentProvider를 return 받을 수 있다. 데이터베이스와 같은 모든 프로바이더들은 field name과 data type, field를 가진다. Application은 오로지 contentResolver를 통해 ContentProvider에 접근해 데이터를 공유할 수 있으며, 직접적으로 content로의 접근은 불가능하다. 만약에 Application이 data를 저장하고, 공유를 원하지 않는 다면, SQLiteDatabase를 이용하면된다. 다른 저장소 들에 대해서들은 5.1.4 section에서 설명을 할 예정이다.
2.3 Application internals
2.3.5 Background activities
Application은 특정한 상황에 Background에서 행동해야 할 때가 있다. 혹은 GUI를 제공하지 않아도 되는 경우도 있다. Android는 이런상황을 위해 BroadcastReceiver와 Service 두가지 컴포넌트를 제공한다. 만약 짧은 순간에 원하는 행동을 할 때에는 BraodcastReceiver를, 긴 시간동안 원하는 행동을 하길 원한다면 Service를 사용하면 된다.
위 두 개의 Class들은 배경요소로써 thread내부나 앱내의 process에서 꼭 실행을 하지 않아도 된다. 따라서 안드로이드는 이들의 행동을 따로 정의하지 않는다. 앱이 멈춘 경우 service나 broadcast는 보통 앱과는 상관없이 독립적인 thread를 통해 돌아가기 때문에 멈추지 ㅇ낳는다. 그렇기 때문에 안드로이드는 앱을 죽였다고 생각해도 실제로는 살아있는 것을 종종 볼 수 있다.
Broadcast는 onReceive를 통해 활성화할 수 있다. 이것은 receiver와 동기화가 되어야 한다. (onReceive에 원하는 filter를 적어놓았을 경우, 실제로 receiver에서 이 filter에 의해 받은 braodcast를 처리할 수 있어야 한다) broadcast는 일반적으로 모든 순서가 정해지지 않은 상태로 수신이 되며 동시에 일치하는 여러개의 방송을 수신할 수도 있다. 같은 방송을 여러 다른 앱에 있는 다른 receiver들이 수신할 경우, 우선순위에 따라 받게 되며 처리 한 후 다른 앱에게 넘겨줄 것인지 혹은 abort()시켜 자신만 수신을 할지도 정할 수 있다.
Service는 background에서 오랫동안 구동되면서 다양한 행동을 할 수 있으며, 몇몇 앱들은 시스템에서 제공되는 기능들을 가져와 서비스를 하기도 한다. 서비스는 두가지 방법으로 사용될 수 있다. 첫번째는 command나 start를 통해 실행이 가능하며, 다른 방법으로는 RPC를 사용하는 것이다.
receiver와 service 둘 다 manifestFile안에 정의가 가능하며 application이 살아있지 않아도 동작할지에 대한 여부를 결정할 수 있다.
2.3.6 Application lifetime & states
안드로이드의 상태는 대부분 앱이 가지고 있는 component에 의해 결정된다. (대부분 activities의 상태를 따른다.) 안드로이드의 컴포넌트가 자신의 상태를 변경할 때, application의 기본 프로세스 유형을 조정하게 된다.
어플리케이션 컴포넌트는 시작이 될 때 내부에서 함수를 호출하게 된다. 액티비티의 예를 들면, onCreate(), onStart(), onResume()등을 호출한다. onCreate()는 액티비티 생성 시 최초 한번이 호출되며, 나머지 두개의 함수는 액티비티의 상태에 따라 종종 호출이 된다. 액티비티가 focus를 잃게 되면(화면에서 보이지 않는 경우) onPause()가 호출이 되며, 액티비티가 더 이상 보이지 않게 될 경우 이어서 onStop()이 호출된다. 액티비티를 완전히 삭제하게 되면 onDestroy()가 호출되며 액티비티의 lifetime은 종료된다.
각각의 method들은 activitiy가 시작되거나 restart되는 등에 대한 state를 알 수 있으며, 각각에 맞는 event를 구현할 수 있다.
onCreate() 이 함수는 initialization 과 setup 행동을 하는 것을 목적으로 한다.이 메소드 다음에는 꼭 onStart()를 호출하게 된다.
onRestart() 이 함수는 Activity가 Stop된 이후 다시 시작될 때 호출되게 된다.
onStart() process가 보이는 상태로 변경되며 활동을 하게 된다.사용자가 볼 수 있지만, forground상태는 아니다.
onResmue() 액티비티에 focus가 맞춰지고, 유저의 입력을 받을 수 있는 상태이다.
onPause() 만약 앱의 focus를 잃거나 device가 슬립모드에 들어간 경우에 호출된다. onPause()가 호출 된 이후에는 시스템에서 언제든 App을 Kill할 수 있다.
서비스의 경우, 라이프타임이 액티비티보다 비교적 단순합니다. onResume, onPause, onStop 등이 존재 하지 않기 때문입니다. 서비스의 상호작용을 위해 onBind, onUnBind, and onRebind 가 제공되며 이것들은 시작, 중지, 그리고 서비스가 재시작 될 때 호출됩니다. broadcast receive는 오로지 onReceive()만 가집니다.
만약 액티비티의 상태가 저장이 되어야 한다면, onSaveInstanceState() 함수를 사용하면 됩니다. 이 함수는 onPause()대 호출이 되며 다이나믹한 데이터(bundle의 key-value pair와 같은)를 저장하기 위한 목적으로 사용되며, 반대로 저장되어 있는 상태를 제거하는 함수는 onRestoreInstanceState()입니다.
