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

카테고리

Chungha Story (46)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (3)
Total120,782
Today108
Yesterday128
심히 객체지향적인 오픈플래폼, 안드로이드

안드로이드의 소스는 심히 객체지향적으로 구현되어 있습니다. 우선 애플리케이션을 구현하는 언어가 자바로 되어 있습니다.
또한 프로세스간 통신을 지원하는 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전자가 뛰어넘었으면 좋겠습니다.^--------------------^
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2010.07.30 17:11 신고 뇨릉  댓글주소  수정/삭제  댓글쓰기

    LG, 삼성에서 안드로이드와 대적할만한 OS를 만들고 있는건가요?? (잘 몰라서..)
    삼성의 바다가 라고는 들어봤지만,,, LG도 자체 OS가 있는건가요? 잘 몰라도.. 저도 저희 나라 기업을 응원해봅니다^^ ㅋ
    그리고 객체지향 커널이라니.. 정말 어떤지 궁금하네요 ㅎㅎ

    • 2010.08.01 22:26 신고 윤청하  댓글주소  수정/삭제

      LG에서 개발하는 자체 OS는 현재 없는걸로 알고 있습니다^^;;
      제가 단어를 잘못쓴것 같습니다~ 안드로이드는 커널이 아니라 플래폼입니다.;;
      그래서 글을 수정했습니다. 정확한 지적 감사드립니다!^^

  2. 2010.08.03 08:53 신고 뇨릉  댓글주소  수정/삭제  댓글쓰기

    커널이란 용어는.. 제가 지적해드리려고 했던건 아니라..
    정말 객체지향 커널인줄 알고 말씀드린건데 플랫폼이였군요^^; ㅋ

최근에 잘 나가는 회사의 팀장급 개발자 분이 하신 말씀이 생각 난다.
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 윤청하

댓글을 달아 주세요

  1. 2009.11.23 21:39 신고 Eminency  댓글주소  수정/삭제  댓글쓰기

    Python은 배우기 쉽고 재밌는 언어지만 개발자에게 껍질을 깰만한 깨달음을 줄 정도는 아닌 거 같아(물론 나도 Python을 꽤 좋아하지만). 다양한 요소들을 잘 버무려 놓은 언어라 어떤 스타일로든 짜기 쉬운 언어란게 오히려 단점이랄까...;

  2. 2009.11.24 10:33 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    객체지향언어로 개발한다고 한들....깨진 유리창을 한번 만들기 시작하면..
    어짜피 결과는 같을거 같아요... 단순 개발언어의 문제는 아닌듯...ㅋㅋ
    눈앞에 보이는 작은 이득(?)의 유혹에 넘어가는 일이 너무 많죠...ㅋ

  3. 2013.04.15 19:15 신고 sunyzero  댓글주소  수정/삭제  댓글쓰기

    어떻게 보면 리눅스 커널도 심각한 스파게티 소스죠. 하지만 잘 돌아가잖아요. ^^


객체지향 코덱 개발

제 업무의 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 윤청하

댓글을 달아 주세요

  1. 2009.11.18 11:36 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    template를 이용해서 virtual function을 simulating 하는 것은 좀 문제가 있네요.
    parent<child> *p = new child;
    parent를 사용하는 경우 child의 명시적인 type을 알아야 한다는...ㅡㅡ^ (머야..이건ㅋㅋ)

  2. 2009.11.18 14:39 신고 언데드  댓글주소  수정/삭제  댓글쓰기

    저기의 parent<child>라는 부분은.. 컴파일타임에 실클래스를 알 수 있다는 건데
    그런 경우 상속없이 템플릿 만으로 구현해도 되겠지요.. 유지보수 측면에서는 비추이지만요..

    설계/성능의 밸런스를 위해서는 OOP스타일C나 C스타일C++를 취하기 마련인데
    이때 C의 유지보수도 그리 나쁘지 않고, C++의 크기와 성능도 만족할만 합니다.
    극한의 특별한 경우라면 모르겠지만 DSP나 임베디드에서는 둘다 괜찮더군요..
    그보단 설계를 우선할 수 있는 여건이 잘 안되는게 문제랄까요..
    유지보수성 증가는 HW에서의 원가절감(여기에는 다들 목을 메죠) 이상의 가치가 있을텐데 말이죠..

    • 2009.11.18 14:49 신고 언데드  댓글주소  수정/삭제

      아니 글 쓰고 보니 그 내용이 리플로.. --;;

    • 2009.11.18 15:14 신고 윤청하  댓글주소  수정/삭제

      맞습니다. 잘 설계해서 만들수 있는 여건이 중요합니다^^
      저는 그 설계 부분에서 코덱 내부의 자료구조간에 여기저기 얽혀있는 '의존성'을 제거하고 싶었습니다. '강한 의존성'에서 유지보수성이 크게 떨어졌기 때문입니다.
      의존성 제거를 하다보면 (C style로 하다보면 function pointer table을 관리하겠죠.) 성능에 않좋은 영향을 끼치는 부분이 있다는 것이 저의 고민이었습니다. 당연히 저위의 '다른 대안'은 진짜 대안이 되지 못합니다.;;

      언데드님께서는 이쪽에 경험이 많으 신것 같습니다.^^ 좋은 조언 감사드립니다~ 앞으로도 잘부탁드려요~

티스토리 툴바