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

카테고리

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 윤청하
, |
최근에 잘 나가는 회사의 팀장급 개발자 분이 하신 말씀이 생각 난다.
php를 좋아하면서 객체지향을 잘하는 사람을 본적이 없는데..ㅡㅡ^
그분의 말투는 마치 C style 개발자는 Loose Coupling, High Cohesion 과는 거리가 멀다는 것처럼 들렸다.
조금 비꼬아서 듣자면, C style 개발자는 스파게티 소스를 만들어낼 가능성이 크다는 것이었다.

내가 현재 재직중인 회사는 전형적인 C언어 개발 회사이다. 현재는 잘 모르겠지만 오래전(약 10년전)에 우리 회사에서 C언어로 만들어진 base library(자료구조, 로그, 통신등)들은 매우 훌륭했다. 어떤 도사분이신지는 모르겠지만 define으로 template까지 구현해놨다. 사실 현재 회사의 개발 능력으로 볼 때 그 base library의 출처가 의심스럽다.^^;; (깊이 알면 다친다..)
하지만, 솔직히 base library를 제외하고는 전체적으로 스파게티 소스에 가까운 경우가 많다. 물론 처음부터 스파게티 소스인 경우는 매우 드물다. 빈번한 customizing, 검증 받지 못한 코드의 커밋, 무분별한 BMT 성 코드 삽입등으로 인해 소스코드는 점점 스파게티처럼 꼬여만 간다.ㅠㅠ 이게 C로 개발하기 때문일까? (누가 답변좀~ㅋ)

나는 회사에서 객체지향으로의 패러다임 전환을 주장하고 있다. 하지만 꼭 C++을 쓰자는 것은 아니다.
단, 객체지향 언어에서 제공하는 것들을 잘 이용한다면 생산성에 더 도움이 될 수 있다에 한표를 던지고 싶다. (define문을 디버깅 한다고 생각해보면..끔찍하다)

나는 어떤 개발자의 주력 언어가 그 개발자의 개발 스타일을 어느정도 나타낼수 있지만 전부를 나타낼수는 없다고 생각한다. 그래도 패러다임이 다른 최소한 하나이상의 언어는 공부하는건 추천하고 싶다ㅋㅋ (요즘 python에 매료되었다는...ㅋㅋㅋ)

써놓고 보니..잡담이 되어버렸다는..ㄷㄷㄷ;; 
Posted by 윤청하
, |

객체지향 코덱 개발

제 업무의 60%는 표준 영상 코덱 개발입니다. 코덱개발은 성능과 품질이라는 trade-off를 가지고 있습니다.
더 많은 연산을 수행 할 수록 품질이 향상됩니다. 최근 멀티미디어 제품에서 품질 이슈가 굉장히 중요해졌습니다. 따라서 성능 개선이 가장 중요한 숙제중에 하나입니다. (대용량 미디어 처리를 위해 한 화면을 인코딩-디코딩하는데 약 2ms 이하로 유지해야 합니다.)
더불어 개발자에게 유지보수성(maintainability)은 버릴수 없는 가치 중에 하나입니다. 고객에게 직접적인 비즈니스 가치를 줄수는 없지만, 그 가치를 만들 수 있는 토대가 된다고 생각합니다.
기존의 영상 코덱은 주로 C언어로 개발되었습니다. 유지보수성은 철저하게 배재되었습니다. 자연히, 유지보수 가능 인력은 매우 제한되고, 기능 추가에 따른 위험은 매우 크며, 장애가 날 경우 원인 파악이 어려웠습니다. (대용량 미디어 처리 특성상 상용사이트에서 로그를 남기기 어렵습니다.)
그래서 저는 현재 기능 개발이 완료된 최신 영상 코덱(통신시장에서는 적용이 좀 늦습니다.)을 객체지향적으로 설계하고 개발하였습니다. (코덱의 복잡도가 매우 크게 증가해서 그랬습니다.ㅠㅠ 잘못한건가요??)

Subtype Polymorphism

Intellectual Wanderlust라는 블로그에 보면 "OOP란 조건문(if)을 줄이는 것"이라는 글에서 처럼 subtype polymorphism을 이용하여 조건문을 줄이는 것이 OOP의 핵심중 하나입니다. (IF문 안쓰기 운동도 있습니다. 껄껄^^ http://www.AntiIfCampaign.com 저도 동참하려고합니다(__ ))
보통 subtype polymorphism은 interface를 정의하는 base class를 상속(inheritance) 받아서 구현합니다.
따라서, virtual function을 자연스럽게 사용하게 됩니다.
(물론 C언어에서도 function pointer를 이용하여 비슷하게 구현할 수 있습니다. 좀 귀찮은 일이 많아 질 뿐이죠^^;;;)

Virtual Function과 성능 이슈

virtual function을 사용하게 되면 vtable이란 것이 생성됩니다. vtable을 이용하여 run-time에 어떤 함수를 호출할 건지 정하게 됩니다. 따라서, compile-time에서의 inline을 사용할 수 없습니다.(아픕니다.ㅠㅠ) 또한 vtable을 참조하여 함수호출이 이루어지는 경우 해당 주소로 redirect 해서 호출하게 되므로 성능이슈에 큰 영향을 줄 수 있습니다. 이러한 점들은 함수의 덩치가 크고 호출되는 횟수가 많지 않다면 전혀 문제가 될수 없지만, 영상 코덱의 경우 굉장히 호출횟수가 많은 작은 함수들이 다수 존재하기 때문에 문제가 됩니다.
또한 객체들의 메모리 사이즈가 virtual function의 갯수 곱하기 4bytes만큼 증가합니다.(32bit machine 기준)
이는 작은 internal memory(2MB under)에서 많은 작업을 해야 하는 DSP에서 제약이 될 수도 있습니다.

그럼 어떻게 해결할 수 있는가?

저는 호출횟수가 많지 않은 곳에서는 subtype polymorphism을 적용하고, 호출횟수가 많은 곳에서는 interface class에 기본적인 내용을 구현하였습니다. (다행히 단순한 기능들이라 가능했습니다^^;;;) 
결국 근본적인 해결이 아니기 때문에 부족한 부분이 많습니다. 그래서 찾아보고 고민하고 있습니다.!! (도움을 주세요~)


인터넷을 찾다가 virtual function을 template으로 대체 할 수 있다는 구문을 보고 찾아낸 방법입니다.
다음과 같은 방법으로 template을 사용하여 virtual function을 구현할 수 있습니다. 

결과는 child의 print()가 호출됩니다.
child = 123

약간(?)의 노력이 필요하지만 필요한 것을 모두 얻을수 있습니다. (base class가 복잡해 질듯..ㅋㅋ)
추후에 코드를 리팩토링 하면서 조금씩 적용해봐야 할 것 같습니다.^^
어디 더 좋은 방법 없나요?~~
Posted by 윤청하
, |