Android는 일반적인 리눅스 시스템과 달리 X Window 가 포함 되어 있지 않으며 독자적으로 윈도우 시스템을 구축하고
있다. 기본적인 윈도우 시스템과 윈도우 매니저를 기반으로 하여 View 를 구현하여 GUI를 구성하고 있다.
View는 위젲 툴
킷이라 생각하면 그 의미가 틀리지 않을 것이다. 또한 안드로이드는 Open GL ES 베이스로 UI가 드로잉 되며 또한
Surface Flinger를 통해 각 윈도우(뷰)를 합성하여 최종 드로잉을 하는 컴포지팅 윈도우 매니저 방식이다. 이러한 점
때문에 안드로이드 UI는 랭귀지가 자바임에 불구 하고도 쾌적한 UI 성능을 보여준다. 특히 요즘과 같이 WVGA(800x480)와
같이 높은 해상도를 가지는 LCD를 사용하는 경우는 Open GL ES를 사용하고 안 하고는 성능에 있어 매우 중요한 요소이다.
안드로이드 어플리케이션
안드로이드에서 어플리케이션은 4개의 핵심 컴포넌트(Activity, Service, Content Provider, Broadcast receiver)중 하나 혹은 그이상으로 구성을 하게 된다. 일반적으로 어플리케이션은 main() 로 시작하는 단일 진입점을 가지고 있으나 안드로이드에서는 진입점이 각 컴포넌트 별로 가질 수 있게 되어 있다. 다시 말하면 안드로이드 어플리케이션의 컴포넌트들은 개별적으로 진입점으로서 실행이 가능하다는 것이다. 구글에서는 이러한 방식이 독특한 방식이라고 이야기 하고 있지만 사실 그렇지도 않다. 핸드폰 UI 에서는 어쩌면 당연한 얘기이다.
예를 들어 메시지 어플리케이션을 살펴 보면, 스크린은 크게 리스트,뷰,컴포저(편집기)로 구성이 된다. 폰북에서 특정 번호로 메시지를 보낸다고 가정해 보면 다음과 같은 동작이 일어 날 것이다.
폰북 어플리케이션 실행 --> 폰북 리스트 --> 전화 번호 선택 --> 메시지 어플리케이션 실행을 하되 컴포저 화면이 보인다. --> 메시지 작성 완료 --> 메시지 어플리케이션 종료 --> 폰북 리스트..
예전의 핸드폰의 소프트웨어들도 구글에서 얘기 하고 있는 방법과 유사하게 동작하고 있었다. 물론 많은 부분들을 엔지니어가 직접 코딩하면서 버그도 엄청 만들어 내면서 고생하면서 구현 했었다. 물론 안드로이드와 같이 덩치가 큰 OS에서는 이러한 부분들을 OS레벨로 처리하게 만들어 주어 개발자가 직접 구현하지 않아도 되도록 만들었을 뿐이다.
안드로이드 어플리케이션을 정의를 내리자면 달빅 머신의 인스턴스를 가지고 있는 리눅스 프로세스라고 하고 싶다. 왜나면 어플리케이션은 4가지 종류나 존재 할 수 있고 각각 고유의 생명 주기를 가지고 있으니 이것이 어플리케이션이다 라고 하기에는 곤란하기 때문이다. UI적인 요소가 포함된것을 어플리케이션이라고 하고 그 외 나머지는 서비스라고 정의 했다면 어플리케이션에 대한 설명과 액티비티에 대한 개념 자체가 달라 졌을 것이다.
View
안
드로이드 GUI의 핵심은 바로 View이다. 뷰는 UI를 표현하는 가장 기본 단위로 위젲, 레이아웃의 베이스 클래스가 된다.
ViewGroup은 일종의 컨테이너로서 뷰를 그룹화 하고 이를 배치하는 역활을 한다. 기본적으로 View할수 있는 일은 모두 할 수 있다. 왜냐면 View로 부터 태어 났기 때문이다.
있다. 기본적인 윈도우 시스템과 윈도우 매니저를 기반으로 하여 View 를 구현하여 GUI를 구성하고 있다.
View는 위젲 툴
킷이라 생각하면 그 의미가 틀리지 않을 것이다. 또한 안드로이드는 Open GL ES 베이스로 UI가 드로잉 되며 또한
Surface Flinger를 통해 각 윈도우(뷰)를 합성하여 최종 드로잉을 하는 컴포지팅 윈도우 매니저 방식이다. 이러한 점
때문에 안드로이드 UI는 랭귀지가 자바임에 불구 하고도 쾌적한 UI 성능을 보여준다. 특히 요즘과 같이 WVGA(800x480)와
같이 높은 해상도를 가지는 LCD를 사용하는 경우는 Open GL ES를 사용하고 안 하고는 성능에 있어 매우 중요한 요소이다.
안드로이드 어플리케이션
안드로이드에서 어플리케이션은 4개의 핵심 컴포넌트(Activity, Service, Content Provider, Broadcast receiver)중 하나 혹은 그이상으로 구성을 하게 된다. 일반적으로 어플리케이션은 main() 로 시작하는 단일 진입점을 가지고 있으나 안드로이드에서는 진입점이 각 컴포넌트 별로 가질 수 있게 되어 있다. 다시 말하면 안드로이드 어플리케이션의 컴포넌트들은 개별적으로 진입점으로서 실행이 가능하다는 것이다. 구글에서는 이러한 방식이 독특한 방식이라고 이야기 하고 있지만 사실 그렇지도 않다. 핸드폰 UI 에서는 어쩌면 당연한 얘기이다.
예를 들어 메시지 어플리케이션을 살펴 보면, 스크린은 크게 리스트,뷰,컴포저(편집기)로 구성이 된다. 폰북에서 특정 번호로 메시지를 보낸다고 가정해 보면 다음과 같은 동작이 일어 날 것이다.
폰북 어플리케이션 실행 --> 폰북 리스트 --> 전화 번호 선택 --> 메시지 어플리케이션 실행을 하되 컴포저 화면이 보인다. --> 메시지 작성 완료 --> 메시지 어플리케이션 종료 --> 폰북 리스트..
예전의 핸드폰의 소프트웨어들도 구글에서 얘기 하고 있는 방법과 유사하게 동작하고 있었다. 물론 많은 부분들을 엔지니어가 직접 코딩하면서 버그도 엄청 만들어 내면서 고생하면서 구현 했었다. 물론 안드로이드와 같이 덩치가 큰 OS에서는 이러한 부분들을 OS레벨로 처리하게 만들어 주어 개발자가 직접 구현하지 않아도 되도록 만들었을 뿐이다.
안드로이드 어플리케이션을 정의를 내리자면 달빅 머신의 인스턴스를 가지고 있는 리눅스 프로세스라고 하고 싶다. 왜나면 어플리케이션은 4가지 종류나 존재 할 수 있고 각각 고유의 생명 주기를 가지고 있으니 이것이 어플리케이션이다 라고 하기에는 곤란하기 때문이다. UI적인 요소가 포함된것을 어플리케이션이라고 하고 그 외 나머지는 서비스라고 정의 했다면 어플리케이션에 대한 설명과 액티비티에 대한 개념 자체가 달라 졌을 것이다.
View
안
ViewGroup은 일종의 컨테이너로서 뷰를 그룹화 하고 이를 배치하는 역활을 한다. 기본적으로 View할수 있는 일은 모두 할 수 있다. 왜냐면 View로 부터 태어 났기 때문이다.
댓글 없음:
댓글 쓰기