블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

최근에 올라온 글

최근에 달린 댓글

심히 객체지향적인 오픈플래폼, 안드로이드

안드로이드의 소스는 심히 객체지향적으로 구현되어 있습니다. 우선 애플리케이션을 구현하는 언어가 자바로 되어 있습니다.
또한 프로세스간 통신을 지원하는 Binder, 멀티미디어 프레임웍(OpenCore and StageFright), 서비스 및 서비스 프로바이더, 오디오/디스플레이 서브 시스템(AudioFlinger, SurfaceFlinger) 등등 대부분의 코드는 매우 객체지향적인 C++로 구현되어 있습니다. OpenCore의 경우 너무 객체지향적이어서 안드로이드 2.2 Froyo에서는 좀더 간단한(?) 구조의 StageFright가 정식 릴리즈 되기도 했습니다. (GingerBread에서는 OpenCore가 없어진다는 소문과 함께..)

Why are You Still Using C?

성능이 중요한 Embedded System에서 C언어를 사용하는 것은 일반적인 관례였습니다. 우리는 C++의 Polymorphism, Virtual Table 등으로 인해 성능이 저하될 수 있다는 편견과 컴파일러에 대한 불신등으로 인해 하드웨어의 성능이 크게 개선되었음에도 불구하고 C언어를 계속 사용하고 있었습니다. 꼭 C언어가 나쁜것은 아니지만 호환성, 유지보수성 또는 확장성 측면에서 어려운 점들이 있었던것은 사실이었습니다.

객체지향과 안드로이드 그리고 휴대폰 제조사

객체지향적으로 구현한다고 해서 호환성, 확장성등이 좋아지진 않습니다. 하지만 객체지향의 몇가지 원칙만 잘 지킨다면 좀 더 개선된 결과를 얻을 수 있습니다. 안드로이드는 객체지향을 통해 오픈플래폼으로써 지녀야할 호환성 및 확장성을 구현하였습니다. 그리고 구글은 당연히 휴대폰 제조사들도 객체지향적으로 접근할 것이라 생각했나 봅니다. 하지만 휴대폰 제조사의 개발 패러다임은 아직 많은 부분에서 객체지향적이지 못한 부분들이 있었습니다. 그리고 안드로이드의 소스를 수정(modification)하였습니다. 결국 애플리케이션의 호환성, 플래폼의 안정성 등에서 적지않은 문제가 발생했습니다.

Open-Close Principle

Robert C. Martin이 제안한 객체지향의 원칙중 하나인 Open-Close Principle의 정의는 다음과 같습니다.
SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION,
BUT
CLOSED FOR MODIFICATION.
휴대폰 제조사는 자신들만의 기능(feature)을 안드로이드의 소스에 확장(extension)해야 합니다. 구글에서 릴리즈한 소스를 수정(modification)해서는 안됩니다. (최소화 해야합니다.) 그래야 구글과 휴대폰 제조사가 윈-윈할 수 있습니다. 그리고 구글이 원하는 OTA(On-The-Air)도 구현할 수 있습니다.

구글은 결국 폐쇄적으로 갈것인가?

안드로이드 2.3 GingerBread에서는 구글이 휴대폰 제조사의 Built-in GUI 탑제를 제한하겠다는 소문이 돌고 있습니다. 하지만 그것이 정답은 아니라는 것을 구글도 알 것입니다. 오픈플래폼은 구글 혼자서 만들수 있는 것이 아니라는 것도 알 것입니다.
LG전자, 삼성전자가 그들의 개발 패러다임을 뛰어 넘는다면, 그들은 폐쇄적으로 갈 이유가 없습니다. (정치적인 이슈는 제외...)
개인적으로 LG전자가 뛰어넘었으면 좋겠습니다.^--------------------^

'Android' 카테고리의 다른 글

Android SurfaceView와 SurfaceFlinger 쫌 들여다 보기  (10) 2010.03.19
Posted by 윤청하
, |
SurfaceView의 역할

Android Application에서 View의 내용은 GDI Thread를 통해 Surface에 그려지게 됩니다.
만약 View에 동영상 또는 카메라 프리뷰와 같이 그려지는 양이 매우 많거나 빠른 화면 변화를 원한다면 SurfaceView를 사용해야 합니다. SurfaceView의 내용은 GDI Thread를 통해서 Surface에 그려지지 않고 다른 Thread를 통해서 그려지기 때문입니다.
SurfaceView는 아래 그림과 같이 Window의 아래쪽에 위치하며, Window를 뚫어서(punched) 자신이 보여지게끔 합니다.
단, 해당 Window 위에 다른 View가 있는 경우 블렌딩(blended)이 되어 보여지게 됩니다.

동영상 재생과 SurfaceView

아래 그림은 동영상이 재생되는 SurfaceView를 묘사한 것입니다.

동영상 재생을 담당하는 PVPlayer (Packet Video Player)에서 SurfaceView에 연결된 Surface에 동영상을 그립니다.
그려진 Surface와 다른 내용(ex. GUI)을 담고 있는 View의 Surface들을 모두 합쳐서(composition) 하나의 화면으로 FrameBuffer에 쓰는 역활을 하는 것이 SurfaceFlinger service입니다. SurfaceFlinger service는 연산량이 많기 때문에 독립적인 process로 존재합니다. 동영상의 화면이 크고 그 위에 블랜딩 되어야 하는 GUI가 많은 경우 오버레이를 위한 하드웨어 가속기를 사용하기도 합니다.
Posted by 윤청하
, |