Zephyros' Web Log: Architecture

출처: http://hyeonstorage.tistory.com/138

Android 모바일 기반 아키텍처 사례

* 모바일 기반 아키텍처 정의서

* 문서관리

* 목차

1. Android Application 개발 개요

1.1 Android Application은 Java로 작성되며 Compile된 Class와 데이터, 리소스와 파일과 함께 apk 파일 형태로 묶여진다.

1.2 apk 파일은 Application 배포/설치를 위한 단위이며 하나의 Application으로 간주된다.

1.3 모든 Application은 리눅스 프로세스에서 실행된다.

1) 각 프로세스는 자신만의 VM을 가진다.

2) 각 Application은 고유한 userId를 가지며 Permission이 설정된다.

3) 두 개의 Application은 동일한 userId 공유가 가능하다 (동일 프로세스, VM 공유)

2. Android Application 개발 과정

3. Android Application Start-up (구동 프로세스)

리 눅스 커널 구동 후 최초로 실행되는 프로세스는 Zygote이다. Zygote란 어플리케이션을 빠르게 구동하기 위해서 미리 Fork 되어 있는 프로세스이다. 이것은 시스템에서 exec() 호출을 통해 특정 어플리케이션을 실행하고자 하기 전까지는 중립적인 상태, 즉 특정 어플리케이션과 합체되지 않은 상태를 유지한다.

4. Anroid 프로세스

* Android 프로세스 흐름

리눅스는 기본적으로 Init이 가장 먼저 실행된다. Init.rc 라는 이름의 파일에는 Init이 해야할 작업들이 기록되어 있다. 파일시스템 마운팅, 폴더 권한설정, 캐시폴더 삭제, 시작프로그램 동작 등이 기록되어 있다.

우선 데몬을 올린다. 데몬은 Init에 의해 리눅스와 같이 시작되었다가 리눅스가 종료될 때 없어지는 프로그램으로서 데몬을 작성하는 규격에 따라 만들어져야 한다.

Zygote가 Dalvik을 초기화 한다. C 밑에 있는 기본라이브러리들은 런타임을 통해 실행되고 상위 서비스들은 Dalvic을 통해 실행된다. 이러한 과정들을 위한 설정은 해당하는 config 파일을 수정하면 된다. 어떤 동작들을 바꾸고 싶으면 기본적으로 init.rc를 바꾸면 되고 Zygote를 바꾸고 싶으면 그 설정파일을 바꾸면 된다.

그리고 시스템서버, 서페이스매니저(SurfaceManager), 오디오매니저들이 올라간다.

그 다음에는 시스템 서비스들이 활성화 된다. 이들은 서비스들이므로 서비스매니저에 등록된다.

5. Android 개발 구성 요소

User Interface, Resource and Assets, Intents & Intent Filter, Data Storage, Contentt Providers, Security & Permission

Graphics, Audio and Video, Location and Maps, App Widgets, Message Handling

출처: http://hyeonstorage.tistory.com/137

모바일 기반 아키텍처 (iPhone, Android)

1. iPhone

(1) Application Life Cycle

- User taps application icon : 어플리케이션 실행, 어플리케이션이 실행되면서 화면가운데 화면이 확대되는 트랜직션 그래픽스

- main(), UIApplicatonMain() : 메인함수 호출, 어플리케이션이 실작할때 최초로 읽히는 main.m 파일을 의미, 어플리케이션을 초기화

- Event Loop : 프로그램이 이벤트가 발생할때까지 대기상태로 아무것도 하지 않고 이벤트를 받을 준비를 하거나 이벤트를 받으면 응답하고 대기하는 것을 반복한다.

- System asks application to terminate : 어플리케이션 종료를 체크

- Application execution terminates : 어플리케이션 종료

(2) Event Handling Cycle

사용자가 장치를 조작하면 아이폰 운영체제는 터치 이벤트를 감지하고 어플리케이션의 이벤트 큐에 그 이벤트를 배치한다.

그러면 UIApplication 객체의 이벤트 핸들링 하부구조는 이벤트 큐의 TOP에서 각 이벤트를 꺼내와서 그 이벤트를 다루는데 가장 적합한 객체에게 전달한다.

또한 이벤트는 어플리케이션에서 터치 이벤트를 다루어야 할 간접적인 책임이 있는 컨트롤 객체와 기타 객체에게 전달될 수도 있다.

(3) iPhone App에 사용된 Design Pattern

- Model-View-Conroller

모델-뷰-컨트롤러(MVC) 디자인 패턴은 어플리케이션의 객체들을 세 가지 역할로 나눈다.

모델 객체는 데이터를 나타낸다.

이 어플리케이션에서 데이터가 매우 단순하다. 그냥 문자열이다. 그리고 실제로 하나의 메소드 안에서만 사용될 것이다. 그래서 엄밀히 말하면 모델이 필요하지 않다고도 할 수 있다. 그러나 여기서 중요한 것은 기본 원칙이다. 다른 어플리케이션들에서 모델은 좀 더 복잡할 것이며 여러 곳에서 사용될 것이다.

뷰 객체는 데이터를 보여주는 법을 알며 사용자에게 데이터를 편집할 수 있게 한다.

컨트롤러 객체는 모델과 뷰를 연결한다.

- Delegation

딜리게이션은 한 객체가 자신의 딜리게이트(위임자)로 지정된 다른 객체에게 입력을 요청하거나 이벤트가 발생했음을 알리기 위해 주기적으로 메시지를 보내는 패턴이다.

이것은 클래스 상속을 사용하지 않고도 이미 존재하는 객체의 기능을 확장하여 재사용할 수 있는 방법이다.

딜 리게이트 메소드는 보통 프로토콜로 그룹 지어져 있다. 프로토콜은 기본적으로 단순히 메소드들의 리스트이다. 어떤 클래스가 프로토콜을 따른다면(Conform), 그것은 해당 프로토콜이 필요로 하는 메소드들을 구현했음을 보장하는 것이다. 딜리게이트 프로토콜은 객체가 그 딜리게이트에 보낼 수 있는 모든 메시지를 정의한다.

- Target-action

타겟-액션 매커니즘은 버튼이나 슬라이더 같은 컨트롤 객체가 클릭이나 드래그와 같은 사용자 이벤트에 반응하여, 그 메시지를 해석할 수 있는 다른 객체(타겟)에게 메시지를 보내며(액션) 어플리케이션에서 지정된 명령을 수행

(4) View Class Hierarchy

- 뷰가 다시 그려질 필요가 있으면, UIView 객체의 기제작된 드로잉 코드는 drawRect: 메소드를 호출하여 사각영역으로 전달함

- 추가한 커스텀 뷰 서브클래스에서 이 메소드를 오버라이드하고, 뷰의 컨텐츠를 그리기 위해 사용함

- 처음으로 뷰가 그려지면, drawRect: 메소드에 전달된 Rectangle은 뷰의 전체 가시 영역을 포함함

- 이후의 호출동안 이 Rectangle은 실제로 다시 그려져야할 부분만 표현함

뷰가 다시 그리는 이벤트

> 부분적으로 뷰를 가리는 다른 뷰를 이동하거나, 제거할 때

> hidden 프러퍼티를 NO로 설정함으로써 이전에 숨겨진 뷰를 다시 보이게 할 때

> 뷰의 스크롤을 움직일 때

> 뷰의 setNeedsDisplay나 setNeedsDisplayInRect: 메소드를 명시적으로 호출할 때

drawRect: 메소드를 호출한 후, 뷰는 스스로 업데이트 되었음으로 표시하고, 또다른 업데이트 사이클이 도착하고, 업데이트 사이클을 촉발하는 새로운 액션을 기다림

뷰가 정적인 컨텐츠를 표시한다면, 스크롤과 다른 뷰 때문에 발생하는 이벤트만 신경쓰면 됨

뷰 컨텐츠를 주기적으로 업데이트 한다면, setNeedsDisplay나 setNeedsDisplayRect: 메소드를 언제 호출할 지 결정해야만 함 또한 사용자와 상호작용이나 새로운 컨텐츠의 생성에 응답해 뷰를 업데이트 할 수도 있음

(5) Layered View in Clock Application

2. Android

(1) Android SDK Emulator 디렉토리 구조와 UI

(2) Android Architecture

안드로이드 플랫폼은 크게 리눅스 커널과, C/C++ 로 작성한 라이브러리, 안드로이드 응용프로그램의 뼈대를 제공하는 어플리케이션 프레임워크와 기본 어플리케이션으로 구성돼 있다. 리눅스 커널은 OS의 기본 기능인 태스크간의 스케쥴링과 메모리, 디스크, 네트워크 등의 자원을 사용할 수 있도록 시스템 콜을 제공한다. 이는 리눅스 커널 윗부분에 초록색으로 표시된 네이티브 라이브러리를 통해 응용프로그램이 편하게 사용할 수 있는 형태로 제공된다.

안드로이드 응용프로그램은 자바 언어로 작성하고, 자바 클래스로 구성된 어플리케이션 프레임워크를 이용한다. 이 자바 파일을 안드로이드 SDK를 이용해 빌드하면 내부적으로 Java 컴파일러와 dex converter를 거쳐 Dalvic VM위에서 동작하는 바이트 코드로 변환하게 된다.
결과적으로 안드로이드 응용프로그램은 어플리케이션 프레임워크를 이용해 버추얼머신에서 제공하는 코어 라이브러리 기능을 사용하게 되고, 이 코어 라이브러리는 리눅스 커널 위에서 동작하는 다양한 C/C++ 라이브러리를 호출하게 된다. 이 라이브러리는 필요에 따라 리눅스 커널의 시스템 콜을 호출하게 된다.

(3) Android Architecture에 사용된 Open Source

안드로이드 플랫폼에는 다양한 오픈소스가 사용되었다.

(4) Android Application Layer

Eclair 기준으로 총 51개 기본 어플이 등록되어 있으며 추가적으로 동일한 어플리케이션 프로그램 인터페이스 라이브러리를 이용하는 서드파티 어플을 추가할 수 있다.

(5) Android Framework

안드로이드 어플리케이션 프레임워크는 자바 기반의 프레임워크이며 대부분이 native C/C++ 코드로 작성되어 있다.

이 프레임워크는 액티비티 매지너, 패키지 매니저 등 핵심 시스템 서비스를 담당하는 코어 시스템 서비스들과 하드웨어와의 인터페이스를 담당하는 하드웨어 서비스들로 구성된다.

(6) Android Library

안드로이드 내장 라이브러리는 Bionic Libc, Function Library, Native Server, Hardware Abstraction Library로 구성된다.
Bionic은 임베디드에서 사용을 위해 최적화된 직접 구현된 libc이다.
Function Library에는 Webkit, 미디어 프레임워크, SQLite가 속하며, 그리고 Native Server에는 Surface Finger와 Audio Finger가 있다.

(7) Android Runtime

안드로이드 런타임은 Core 라이브러리와 Dalvic 가상머신으로 구성되어 있다. 코어 라이브러리는 강력하지만, 단순하고 익숙한 개발 플랫폼을 제공하는 Java 언어를 위한 Core API를 포함하고 있다. 그리고 Dalvic 가상 머신은 안드로이드에서 자체적으로 만든 것으로 청정영역을 제공하는 가상머신으로써 어플리케이션의 호환성과 실행의 일관성을 제공한다.

(8) Android Kernel

안드로이드에서 리눅스 커널을 사용하는 이유는 메모리 및 프로세스 관리, 인가 기반의 보안 모델, 검증된 드라이버 모델, 공유 라이브러리 지원, 오픈소스 기반 등의 장점 때문이다. 그러나, 안드로이드가 표준 리눅스 유틸리티 전체를 포함하고 있지는 않다. 이는 안드로이드가 리눅스 커널을 기반으로 하고 있지만 내장 윈도우 시스템을 지원하지 않기 때문이다 그리고 알람, 파워 매니지먼트 등은 안드로이드를 위해 확장된 리눅스 커널 영역이다.

* 모바일 기반 아키텍처 요구사항

- 최적화된 리소스 사용으로 경량화 구조를 유지할 것

- 프로세스의 적절한 사용으로 고가용성을 유지할 것

- User Interface 로딩 시간을 최소화할 것

- 확장 가능한 권한/ 인즈 체제를 구축할 것

- Application 수준에서 보안 요구사항을 만족할 것

- Application Download 및 Install 작업이 용이할 것

Zephyros' Web Log

2015년 6월 29일 월요일

[H3 2011] 하이브리드 앱 아키텍쳐 및 개발방법

[SW 아키텍처] Android 모바일 기반 아키텍처 사례

[SW 아키텍처] 모바일 기반 아키텍처 (iPhone, Android)