Art of Dalinaum

아목 윤호정 군의 명복을 빕니다.

Sat, 11 May 2013 00:40:00 +0900

어렸고 두려움도 많았지만 한 걸음 세상을 밟으면서 앞으로 나아가는 소년이 있었습니다. 그는 젊은 오픈소스 해커였습니다. 샌드박에서 리눅스 커널의 소스를 읽고 안드로이드 소스에 대해 토론하고 펄 언어의 패치를 만들었다고 좋아하던 모습이 눈에 선합니다. 그는 이제 겨우 24살이었습니다. 미숙한 점도 많았지만 다양한 관심과 노력과 재능은 그의 미래를 축복해주었고 그가 필요한 세상이 곧 올거라는 것은 의심할 여지가 없었습니다.

하지만 세상은 가끔은 너무나 야속하네요. 그 소년은 불의의 교통사고로 2013년 5월 8일 다른 세상으로 떠났습니다. 오픈소스 커뮤니티의 샛별이 미처 제 궤도를 잡지 못한채 희미해져갑니다. 만날 때에 미리 떠날 것을 염려하고 경계하지 아니한 것은 아니지만, 이별은 뜻밖의 일이 되고, 놀란 가슴은 새로운 슬픔에 터집니다. 모든 것이 거짓말이었으면 좋겠습니다. 짖궂은 장난이었으면 좋겠습니다. 한번만 이런 장난 하지말라고 화내고 다시 만날 수 있었으면 좋겠습니다. 그랬으면 정말 좋겠습니다. 그랬으면 좋겠습니다.

그가 남긴 마지막 트윗입니다.

RT @the_unstabler 사람이 착하게 살면 천국에, 나쁘게 살면 지옥에, 적당히 살면 중국에 간다고 합니다.
— Hojung Youn (@am0c)
May 8, 2013

제발 중국에서 봅시다. (..)

그의 페이스북 링크입니다.
그의 GitHub 링크입니다. - Star를 눌러줬습니다.

엔하 위키 성능 문제 자체 미러로 해결될까?

Thu, 18 Apr 2013 13:27:00 +0900

엔하 위키 마니아들은 부정하겠지만 엔하 위키는 성능 문제가 있다. 엔하 위키는 트래픽에 대한 우려로 봇의 접속을 막는 등의 조치를 취하고 있지만 접속 시간은 들쭉 날쭉하고 서버가 다운되는 일도 종종 일어난다. 이 문제를 엔하 위키 스스로 해결하는 것은 현재 상황에서 힘들어보인다.

성능 변동이 심한 것은 괜찮은 캐쉬 시스템과 렌더링 시스템이 없다는 뜻이다. 이 문제를 해결하려면 캐쉬 시스템을 개선하거나 렌더링 시스템을 개선하면 된다.

캐쉬를 잘 쓴다.
static page 등을 잘 활용한다.
템플릿 파트를 다시 짠다.
기타 등등

엔하 위키는 어떤 전략을 택할 것이냐? 엔하 위키 측의 대응은 “자체 미러”를 만들 겠다는 것이다. 이건 기술적인 방향이 아니다. 미러는 같은 내용을 가지고 있는 사이트인데 이를 만드는 것은 원 사이트가 성능에 문제가 있기 때문이다.

애당초 성능의 문제가 없다면 미러를 만들어 힘들게 관리할 필요 자체가 없다. 문제의 근본 원인을 해결하고 추후 사용자가 더 많아질 때 규모 가변성을 대비한 전략을 세우는 것이 옳다.

자체 미러가 대안이라 생각하는 한 엔하 위키의 성능이 개선될 가능성은 없어 보인다.

PS: 기술적으로 더 자세한 글이 있어 인용한다.

less is more: 반응형 웹 같은 소리 하고 있네

Sat, 06 Apr 2013 13:30:35 +0900

less is more: 반응형 웹 같은 소리 하고 있네:

materiality:

xymz:

그리고 그건 내 생각에 웹이라는 매체의 특성을 고려하면 당연히 해야 하는 일이다. 디바이스 및 스크린 사이즈를 처음부터 고려한 적절한 배치.

반응형 웹 같은 소리 하고 있네. 대체 처음에 “이 페이지는 1024*768에 최적화되었습니다” 같은 개소리를 한 미친놈은 누구란 말인가?

인류는 웹의 등장 이전까지 크기가 변할 수 있는 시각 매체를 접해본 적이 별로 없습니다. 심지어 TV조차 크기는 다양할지언정 실질적으로 비슷비슷한 화면 비례를 가졌죠. 이런 상황에서 처음 시작하는 입장이라면 땐 누구나 자기가 익숙했던 매체를 — 책이라던가 신문이라던가 — 기준으로 디자인을 시작할 수밖에 없었을 겁니다. 천재가 아닌 이상에야 말입니다.

웹의 시대가 도래한지 20년이 지났지만, 사람들이 크기가 변하는 매체라는 개념을 이해하기에는 아직 갈 길이 멀어 보입니다.

컴퓨터 프로그램도 크기가 변하는 시각 매체이죠. 모바일 애플리케이션도 크기가 변하고요. 그리고 일반인이면 모를까 이걸로 먹고 사는 사람들은 달라야죠. 외국 애들은 비교적 잘하는데 한국애들이 못하는 것은 한국인들이 대체로 바보이거나 너무 만만하게 보기 때문일겁니다.

TextureView Demo

Thu, 04 Apr 2013 19:26:00 +0900

텍스쳐 뷰 샘플이 너무 없어서 만들어보았습니다.

해당 데모는 마켓에서 받을 수도 있습니다.

키워드 파라미터 필요없습니다.

Fri, 29 Mar 2013 10:26:00 +0900

아이폰이 유행하면서 많은 프로그래머가 접하게 된 개념 중 키워드 파라미터 (keyword parameter)가 있습니다. 이 개념은 명명된 파라미터(named paramter)라고 불리우기도 합니다. 키워드 파라미터를 모르시는 분을 위해 전형적인 예제를 보여드리겠습니다.

[window addNewControlWithTitle:@"Title"
                     xPosition:20
                     yPosition:50
                         width:100
                        height:50
                   drawingNow:YES];

이 코드는 보통의 언어에서의 아래의 형태와 동등합니다.

window.addNewControl("Title", 20, 50, 100, 50, true);

어떤 사람들은 이 개념이 메서드 시그네쳐를 기억하게 쉽게 하며 인간이 사용하는 언어와 흡사해서 편한 장점이 있다고 주장합니다. 처음에 듣기에는 그럴싸 해 보였습니다. 키워드가 있으면 이해하기 쉬울 것 같고 사용하기 쉽고 읽기 쉬울 것 같았습니다. 과연 그럴까요? 저는 이 개념들이 그런 장점을 가지고 있다는 것에 동의하기 힘든 것 같습니다.

파라미터 순서를 바꿀 수 없는 언어의 경우 (Objective C)처럼 일반 언어의 호출과 다름이 없습니다. 파라미터 타입 마다의 순서를 이해한 경우 키워드 파라미터의 키워드는 추가로 타이핑해야 하는 귀찮은 요소가 됩니다. 물론 전혀 모르던 코드를 볼 때 잠깐은 도움이 될 수 있습니다. 해당 파라미터가 무엇인지 정보를 주석처럼 달고 있으니깐요. 하지만 보통 여러 파라미터를 가진 메서드는 한번만 호출되는 경우는 별로 없기 때문에 타입에 대한 설명이 없어도 그 메서드가 무엇인지 알게 되고 결국 코드를 이해하는데 크게 도움이 안되더군요. 만약에 코드가 매우 짧다면 도움이 될 것 같지만 그럴 경우에는 컴파일 언어 자체를 쓸지 의문이 들고요.

파라미터의 순서를 바꿀 수 있는 언어의 경우 어떤 파라미터가 빠졌는지 생각해 내어야 합니다. 마치 퀴즈같습니다. 부가적인 파라미터 (Optional parameter)를 쓸 수 있어 일부 파라미터를 생략할 수 있는 경우도 있지만 별 도움은 안됩니다. 오히려 제가 생각지도 못했던 파라미터가 빠져서 초기값으로 설정이 되고 혼동을 줄 수 있습니다. 부가적인 파라미터는 대게의 경우 기본 값을 가지고 있고 제가 실수로 누락한 파라미터의 경우 이 기본 값에 의한 영향 역시 명확하게 판단되지 않은 상황인 경우가 많습니다.

네이밍 컨벤션의 범위가 넓어집니다. 메서드 명에 전치사를 어떤 경우에는 붙여야 하고 어떤 컨벤션은 파라미터 마다 전치사를 입력하는 경우도 있습니다. 저는 관습이나 문화의 힘에 의존하는 방식은 좋지 못하다고 생각합니다. 지킬 필요를 느끼지 못해 어기는 사람도 있고 몰라서 지키지 않는 사람도 있고 실수하는 사람도 있습니다. 키워드 파라미터에서도 그렇습니다. 어떤 사람은 파라미터마다 전치사를 붙이고 어떤 사람은 최초의 메소드 명에만 붙이거나 아예 안 붙입니다. 그리고 붙이는 경우에도 영어에서 붙이는 경우와 안 붙이는 경우에 따라 달리 쓰기 때문에 기계적으로 판단하기는 어려워 집니다. 그래서 여러 라이브러리를 섞어 쓰면 키워드 파라미터를 쓰지 않는 언어보다 더 혼란스럽습니다. 어떤 라이브리에서 온 시그네쳐가 어떤 문법을 쓰고 있는지 문맥 전환(context switching)을 하면서 코드를 읽고 써야 하는 느낌입니다.

너무나 장황(verbose) 해집니다. 탭을 2칸 단위로 하더라도 하나의 메서드 호출이 2, 3줄 이상이 되는 경우는 아주 흔합니다. 파라미터를 위한 키워드가 5 바이트 이상씩 먹으면 파라미터가 4개만 되어도 20바이트가 채워지는 것입니다. 대개의 경우 파라미터 키워드가 자세히 풀어서 쓴 경우에는 pos와 같은 이름을 가지는 변수를 인자로 전달하기 조금 꺼려지게 되죠. 적어도 position이나 titlePosition정도의 이름은 붙이게 될겁니다. 그럼 하나의 파라미터를 위한 공간으로 15바이트 이상을 쓰는 경우가 흔하게 됩니다. 키워드 파라미터를 쓰는 경우 여러 줄의 메서드 호출을 사용하며 파라미터를 한 줄 당 여러개 적는 방식은 권장되지 않는데 마치 파라미터가 생략된 것 처럼 느껴지기 때문입니다. 아래의 코드를 보십시요.

[window addNewControlWithTitle:@"Title"
        xPosition:20   yPosition:50  width:100
           height:50  drawingNow:YES];

파라미터를 시선을 가로로 쭉 보거나 세로로 쭉 내려가면서 보기 위해서 줄을 맞추는 경향이 있기 때문에 공간은 더 좁아집니다. 보통 메서드 명은 첫번째 파라미터의 명칭을 겸하고 있기 때문에 더 길어지고 실제 파라미터 변수를 기준으로 줄을 맞추면 꽤 뒤쪽을 기준으로 줄 맞춤이 이루어집니다. 위의 소스코드에서 @"Title"과 20 50 100 50 YES를 좌측 기준으로 줄을 맞추어 보면 얼마나 공간이 낭비될지 예상할 수 있습니다.

많은 사람들이 IDE에 대해 환상을 가지고 있고 언어의 장황함을 IDE가 해결해 줄 수 있다고 생각합니다. 위의 문제들도 IDE가 해결해줄 수 있을 것으로 생각하고요. 키워드 파라미터도 IDE가 해결해줄 수 있을까요? IDE가 제공해주는 것은 저희가 입력해주는 키워드가 변수명으로 있을 때나 시그네쳐로 있을 때 자동완성을 하거나 이 중에 하나가 아니냐며 제안해 줄 수 있습니다. 하지만 자동완성이나 추천 기능은 생각만큼 빠르지 않으며 완성된 내용을 채우는 과정은 매끄럽지 못합니다. 중간 중간에 있는 키워드를 피해서 탭이나 화살표를 누르고 제 위치를 찾아 입력하는 것은 곤혹스럽습니다. 또 제가 키를 하나 입력한 후 자동완성되는 것을 기다리는 것도 생각보다 긴 과정입니다. 키를 누르고 거기에 대한 피드백이 뜨길 기다리고 목록을 확인하고 비슷해 보이는 시그네쳐 사이에서 정확히 원하는 시그네쳐를 선택하고… 생각에 흐름에 비하면 IDE의 처리 속도는 바틀 넥에 가깝습니다. 또 IDE는 수평적인 코드 작업에는 도움이 될지 몰라도 수직적인 코드의 흐름에는 별로 도움이 되지 못하는 것도 문제입니다. 장황한 언어는 대부분 수평으로만 장황하지는 않죠. 불행하게도 키워드 파라미터도 역시 코드를 수평적으로 그리고 수직적으로 장황해지게 만듭니다. 저는 어떤 여러 줄에 걸쳐서 사용자의 불편을 제대로 돕는 도구를 못 봤고 키워드 파라미터에 있어서도 별 도움은 안되는 것 같습니다.

ActionBar & Fragment

Sat, 02 Feb 2013 00:27:00 +0900

ActionBar & Fragment

액션 바 셜록과 슬라이딩 메뉴에서 환경설정 사용하기

Wed, 30 Jan 2013 00:53:00 +0900

설정을 위한 새 API PreferenceFragment는 안드로이드 신버전에서만 사용할 수 있습니다. 해당 Fragment가 시스템 함수를 사용하고 있기 때문에 호환성 라이브러리에서도 없으며, 오픈 소스 라이브러리들도 포팅을 하지 못했습니다.

그런 이유 때문인지 Activity를 상속받는 라이브러리들은 낡은 뷰인 PreferenceActivity를 제공합니다. 안드로이드 구버전을 사용하는 경우 PreferenceFragment를 쓰기 어렵기 때문에 PreferenceActivity를 확장하는 것이죠.

액션바를 안드로이드 구 버전에서 구현한 액션바 셜록 라이브러리가 있습니다. 액션 바 셜록은 PreferenceActivity의 액션바 셜록 버전인 SherlockPreferenceActivity를 만들었지만, 호환성 라이브러리의 Fragment를 지원하지는 못했습니다. PreferenceActivity의 인플레이터는 호환성 라이브러리의 Fragment를 안드로이드의 Fragment로 상속받으려다 죽게됩니다.

단순히 액션바와 환경 설정을 사용하려고 하면 이렇게도 충분합니다. (하위 단계에서 업 네비게이션 버튼 등이 이상하게 동작하는 등의 문제는 있습니다만.) 하지만 다른 라이브러리와 결합된다면 상황은 복잡해집니다.

최근 슬라이딩 메뉴와 같은 라이브러리가 자주 쓰이고 있습니다. 안드로이드의 드로어를 제공해주는 오픈소스 라이브러리입니다. (드로어는 페이스북 등의 앱에서 측면에 서랍같이 열리는 사용자 인터페이스입니다.) 이 라이브러와 셜록을 같이 쓰기 위해 슬라이딩 메뉴의 엑티비티들의 부모를 셜록의 엑티비티로 지정하는 사용하는 경우가 있습니다. 슬라이딩 메뉴의 구성을 프래그먼트로 하면 대부분의 경우에는 멀쩡하게 동작합니다. 하지만 프리퍼런스와 함께라면 런타임 에러가 발생하고 말죠.

PrefereceActivity나 그것을 상속받은 Activity에서 Fragment를 지원하는 방법은 없을까요? 제가 잠깐의 시간 동안 호환성 라이브러리의 코드를 살펴보았는데 매우 어려운 일일 것 같습니다. 호환성 라이브러의 FragmentActivity는 LayoutInflater에 커스텀 팩토리를 등록하고 있습니다. 이 팩토리는 onCreateView 메서드를 가지고 있습니다. 이 액티비티는 호환성 라이브러리의 Fragment 객체와 패키지 수준의 자료 공유를 통한 공 결합을 이루고 있습니다. 저희가 같은 패키지 수준이 되지 못한다면 프래그먼트 지원을 기존의 액티비티에 추가하기 어려울 것입니다.

제가 생각하는 가능한 방법은 두가지가 보이네요. 첫 번째 방법은 Fragment와 FragmentActivity까지 오픈소스 라이브러리에서 자신만의 버전을 만드는 것입니다. 호환성 라이브러리를 쓰지 않기 때문에 다른 라이브러리와 잘 맞지 않는 부분은 감당해야겠죠. 두번째 방법은 자신만의 호환성 라이브러리를 만드는 것입니다. Fragment, FragmentManagerImpl, FragmentActivity 등과 같은 디렉토리 주소에 저희의 확장들을 넣어주는 것입니다. 어떻게 보니깐 두가지 방법이 다 비슷한 방법 처럼 보이네요…

안드로이드의 Fragment를 쓰면 액션바 셜록 + 슬라이딩 메뉴가 됩니다만. API 버전이 올라갑니다. 그럴바엔 슬라이딩 메뉴 라이브러리만 쓰면서 ICS용으로 앱을 만들고 말죠.

한줄 요약: 제목의 내용은 사실 안됨.

Cocoa 소감

Mon, 28 Jan 2013 17:20:00 +0900

요즘 틈틈히 Objective C를 다시 써보고 있다. (이전의 경험은 iPhone OS 2.x/3.x시절이라 매우 오래전이다.) 다시 써보면서 느끼는 것이 조금 있다.

어. XCode UI는 정말 많이 바뀌었구나. 예전에는 하나의 앱을 여러창이 구성했다는 느낌이면 이제는 하나의 창이 일시적으로 나뉘어지는 느낌이다. 어떤 상황에 펼쳐질지 직관적이지는 않지만 조금 더 넓고 일관성있게 쓸 수 있는 것 같다.
ARC가 retain, release 지옥에서 해방시켜줬지만 레거시 환경에 따라서 탈출 못 할 수 있다. CocoaPods와 같은 훌륭한 도구로 ARC를 쓰지 않는 라이브러리를 격리시키더라도 Cocos와 같이 ARC를 쓰지 않는 템플릿을 가진 환경이 영향을 미치면 다시 메모리 관리는 신경써야할 이슈가 된다.
Objective C의 경험은 좋지못하다. 다른 언어에서 컴파일 타임에러로 해결 가능한 일이 런타임에도 못잡는 경우도 있는데 괴롭다. dynamic인 프로퍼티가 문제가 있었는데 인스턴스가 없었을 때 조용히 처리되는 것을 알았을 때 나는 경악했다. 문제는 가능한 빨리 발견되어야 한다. LLVM이 컴파일 타임에 알려주는 정보는 여전히 불완전하며 Objective C의 런타임은 너무나 조용하다.
카테고리는 흥미롭다. 이전에 iPhone OS (이제는 iOS)의 API가 바뀌어 호환성이 없어졌을 때 기존의 라이브러리를 확장시켜 호환성을 유지할 수 있어 좋았다. Java에서는 이런 기법이 불가능하기 때문에 안드로이드의 액션바 셜록 라이브러리와 슬라이딩 메뉴 라이브러리를 같이 쓸 경우에는 순차적인 상속 체인을 만들기 위해 라이브러리를 소스 차원에서 수정해야 한다. 슬라이딩 메뉴가 셜록을 상속받거나 셜록이 슬라이딩 메뉴를 상속받던가… 자바의 무식함은 맘에 안들지만 한편으로는 Objective C의 카테고리와 같이 기존 객체를 변경하는 방법이 바람직하고 안전한지는 의문이다. 의도하지 않는 기능을 추가하는 것은 어떤 영향을 미칠지는 알기 어려운 부분이며, 카테고리는 어느 부분에서 인터페이스의 변경이 발생했는지 알아채리는 것이 상속보다 어렵다. 자바 식의 단일 상속은 너무나 괴롭고 카테고리 보다 안전한 확장 방법이 필요하다.
XCode의 UI를 매핑시켜서 Mac OS X 앱을 만드는 과정은 자연스러웠다. 이 정도 수준의 깔끔함은 이클립스나 비주얼 스튜디오가 제공해주지 못했던 환경.
컬럼 제약을 설정하기도 어렵고 남들과 같은 환경을 맞추기도 어려워 통일된 개발 기준을 갖는다는 것은 어렵다. 이클립스라면 포매팅 파일 하나 공유로 끝나는 문제다.
머지가 힘든 프로젝트 파일은 대규모 프로젝트에서 어떻게 관리해야 할지 우려스럽다. XCode 식의 관리는 소규모 작업이 아닌 경우에 관리하기 어려울 것 같다.
파일을 읽고 쓰는데 같은 스레드에서 하는 경우가 많다. 그냥 샘플 들이라서 그런가? Strict mode와 같은 런타임에서 메인 스레드의 반응성을 일관되게 유지되도록 유도하는 도구는 없나 보다. 프로그래머가 알아서 해줘야 하는 환경인데 나는 그보다는 프로그래머가 잘하도록 유도하는게 나은 전략이라 생각한다.

한줄요약: 언어, 에디터, 컨벤션 관리, 빌드 환경 글쎄? 인터페이스 빌더는 좋네.

햄버거와 지하

Tue, 11 Dec 2012 04:37:00 +0900

햄버거와 지하:

jxnblk:

“Good design makes a product understandable” – Dieter Rams

Good navigation should do at least three things well:
(1) it should allow the user to navigate;
(2) it should serve as wayfinding, letting the user know where they are;
and (3) it should help the user understand what the product is…

페이스북 식의 사이드 바를 Left Nav Flyouts라고 부르는 것 같은데 저 기준에 따르면 좋지 못한 네비게이션이 맞는 것 같다.

사용자가 결국 어디론가 가겠지만, 지금 어디에 있는지 모를테고, 햄버거 아이콘을 눌러서 지하실을 열기 전에는 어떤 기능이 있는지도 몰라서 어디로 가야할지도 모를테다.

멋져 보이는 것이 좋은 인터페이스는 아니다.

안드로이드 메모리 관리에 대한 오해

Thu, 25 Oct 2012 19:00:00 +0900

안드로이드에 대한 오해는 인터넷 전반에서 볼 수 있습니다. 안드로이드 메모리 관리에 대한 오해는 그 중 하나죠.

여기에 대해 간단히 답글을 달아보겠습니다.

모바일 운영체제는 스와핑을 하지 않습니다. 플래시 메모리 환경에서 스와핑을 하는 것은 매체 수명에 영향을 미치기 때문입니다.
안드로이든 아이폰이든 메모리를 적게 쓰도록 앱을 짜야 합니다. 모바일 환경은 메모리가 적기 때문에 언제나 공간효율적인 프로그래밍을 해야합니다. 또 PC 환경에서 앱을 짤 때도 가용램에 대한 어떠한 가정을 할 수 없습니다.
비트맵으로 인한 힙 사용은 언제나 VM의 상한선에 영향 받지 않습니다. 이는 비트맵에 의한 메모리 사용이 VM의 제한을 받지 않기 때문입니다.
비트맵이 위치하는 영역은 안드로이드가 임의로 어느 위치에 올리지 않고 안드로이드 버전 별로 일관된 정책에 따릅니다. 진저브레드까지는 네이티브 힙에 들어가며 허니컴 부터는 JNI 레이어에서 VM에 힙을 할당하고 그것을 JNI에 다시 가져옵니다. 이는 DDMS에서 힙 영역을 추적하여 메모리 관리하기 쉽도록 변경된 부분입니다. 안드로이드 버전에 따라 비트맵을 쓸 때 어떤 상황이 벌어질지는 명확합니다.
비트맵은 recycle이 명시적으로 호출되거나 Bitmap 객체의 소멸자자에 의해 JNI를 통해 명시적으로 해제됩니다. 하지만 소멸자의 호출 시점은 예상하기 어렵기 때문에 공격적으로 비트맵을 쓰는 앱의 경우에는 비트맵이 필요가 없어질 때 recycle을 호출하는 것이 바람직합니다.
Allow purging of assets 는 CyanogenMod의 설정으로 asset에 있는 비트맵인 경우 다시 불러올 수 있기 때문에 제거할 수 있게 허용하는 것입니다. 이런 기교적인 방법을 통해 일부 메모리를 더 할당받을 수 있습니다. 재미난 발상이지만 메모리 릭과는 상관없는 이슈이죠.

PS: 이 글을 처음에 답글로 달려 했으나 해당 사이트는 즉시 답글을 다는 것을 허용하지 않고 있네요. 스팸 때문일 것 같긴 하지만 이해하기 힘든 정책입니다.

Google I/O 2012 후기

Tue, 10 Jul 2012 07:17:19 +0900

Google I/O 2012에 다녀왔습니다.

자세한 내용은 아래 첫번째 글에 올렸습니다. 다른 분들의 후기도 모아두었습니다. (혹시 다른 한국분의 Google I/O 후기가 있다면 알려주시면 링크를 같이 걸어두겠습니다.)

달리나음(김용욱): Google I/O 2012를 다녀와서
GDG Summit 후기: 개발자의, 개발자에 의한, 개발자를 위한
nurinamu(이원제): 구글 I/O 2012 - Day #1: Android & Nexus
휴휴휴(양찬석): 구글 I/O에 다녀왔습니다.
커니(김태호): 2012 Google I/O: 당신의 Input과 Output은 어떻습니까?
달리나음(김용욱): 샌프란시스코에서 쓰는 구글 I/O 후기

추신: 안드로이드에 대해 전문적인 글을 적어야 겠다고 생각하다 보니 글을 그동안 많이 적지 못했군요. 이제는 간단한 글이라도 종종 올리겠습니다.

렌더스크립트를 소개합니다.

Thu, 22 Mar 2012 08:56:42 +0900

안드로이드 허니컴부터 소개된 렌더스크립트는 아직 미지의 기술인 것 같습니다. 여러 모임을 참석해 보면 많은 사람들은 막연히 허니컴 이후에 추가된 그래픽 기술이라고 생각하고는 뭔가 향상점이 있겠지하고 지나가더군요. 또, 렌더스크립트에 대해 기술된 쓸만한 글들도 거의 없는 실정입니다. 그렇기 때문에 개발자 블로그에 올라왔던 세개의 렌더스크립트 기사는 꽤 유용했던 것 같습니다. 아래는 제가 렌더스크립트 기사들을 번역한 것입니다.

위 아티클 들은 실제 그래픽 처리보다는 렌더스크립트가 보일 수 있는 분산 처리를 이용한 연산 가속(compute acceleration)에 더 비중을 두고 있습니다. 그래픽 관련 아티클을 보고자 하시는 분들은 SDK의 샘플을 보시는게 가장 좋습니다.

안드로이드 렌더링의 특징: 디스플레이 리스트

Wed, 21 Mar 2012 01:43:00 +0900

안드로이드 3.0(허니컴)부터 렌더링 부분이 많이 향상되었습니다. 하드웨어 가속이라는 특성도 그 중의 하나이죠. 또 다른 변화 중 하나는 디스플레이 리스트가 추가된 점입니다. 진저브레드까지 안드로이드는 변화를 전파하는 모델을 가지고 있었습니다.

이런 모델은 변경 사항을 ViewRoot까지 전파하는 문제가 있었습니다.

전파되어 올라간 후 다시 아래로 내려오면서 그려야 합니다.

이런 모델은 하나의 뷰 변경이 꽤 많은 코드를 접근하게 하여 비효율적이었습니다. 하나의 뷰를 다시 그리기 위한 정보가 상단의 유아이 요소까지 올라가야만 얻을 수 있기 때문에 변경 내역을 전파하고 다시 그려야만 했습니다.

이 비효율에 대한 대안은 디스플레이 리스트를 사용하는 것입니다.

뷰가 위와 같은 목록을 가짐에 따라 갱신하는 과정은 매우 간단합니다.

디스플레이 리스트는 각 UI요소를 그리기 위한 정보를 리스트로 모아둔 것입니다. UI 요소의 변경이 발생했을 때 위로 올라갈 필요가 없습니다. 그냥 해당 UI 요소의 디스플레이 리스트를 확인하고 사용하면 됩니다. 그리기 위해 필요한 정보가 한 곳에 모여있습니다.

더 깊은 내용을 알고 싶은 분들을 위해 조금 더 내려가겠습니다.

디스플레이 리스트는 DisplayList와 GLES20DisplayList 객체를 구현되어 있습니다.
DisplayList는 추상 객체로 녹화의 시작과 끝을 지정할 수 있습니다.
GLES20DisplayList는 구체화된 객체로 화면 구성을 위한 비트맵 등의 리소스를 가지고 있습니다.
GLES20DisplayList는 녹화의 시작(start())에 GLES20RecordingCanvas를 생성하여 반환합니다.
GLES20RecordingCanvas는 GLES20Canvas의 자식 클래스로 풀(pool)을 만들어 자신을 관리합니다.
GLES20RecordingCanvas는 GLES20DisplayList의 비트맵 리스트에 접근할 수 있습니다.
GLES20Canvas는 DisplayRenderer를 생성합니다.
DisplayRenderer는 뷰를 위한 그림 연산들을 순차적인 목록으로 보관합니다.
DisplayRenderer는 다시 뷰를 그릴 (replay()) 수 있습니다.
DisplayRenderer는 OpenGLRenderer를 사용하여 하드웨어 가속을 사용합니다.
DisplayRenderer와 OpenGLRenderer는 상속관계가 아닙니다.
OpenGLRenderer가 GPU를 사용하여 실제 렌더링을 합니다. (SKIA의 간소화된 버전)

코드는 아래 디렉토리에서 확인하십시요.

frameworks/base/core/java/android/view
frameworks/base/core/jni/android
frameworks/base/core/jni/android/graphics
frameworks/base/libs/hwui

이 글의 이미지는 Romain Guy와 Chet Haase의 Google I/O 2011 Android Accelerated Rendering에서 발췌하였습니다.

안드로이드 소스 개별 리포지토리

Tue, 20 Mar 2012 23:32:00 +0900

안드로이드 소스는 여러개의 리포지토리가 합쳐 구성되어 있습니다. 전체를 받는 것은 많은 시간이 들기도 하고 용량이 많기 때문에 부담이 된다는 분들이 계시더군요.

개별 리포지토리의 주소를 따 두었습니다. (이렇게 따두는 것은 어려운 일은 아니긴 하지만 조금 귀찮은 일입니다.)

https://docs.google.com/document/pub?id=1TigHy4rEIOKyCoiAbuUYt_X7twrNXbLmmwbDTc3Xh7Y

하나씩 https 주소를 따 두어서 git clone <https 주소> 이렇게 입력하면 하나 씩 받을 수 있습니다.

PS: 안드로이드는 서브모듈을 쓰지 않고 repo라는 도구를 씁니다. repo는 여러 리포지토리를 받아와 소스 트리를 구성해주고 변경된 내역을 리뷰 사이트에 올려 검증 절차를 받게 하는 도구입니다.

스핀락의 구현

Sun, 04 Mar 2012 17:22:15 +0900

스핀락에 대해 어렵게 생각하시는 분들이 많으시더군요.

static inline void arch_spin_lock(arch_spinlock_t *lock)
{
    unsigned long tmp;
    /*
     * 스핀락의 ARM 아키텍쳐 구현입니다.
     * 1. lock->lock의 값을 가져와서 tmp에 저장합니다. 
     *    배타적 로드(ldrex)를 썼기 때문에 이후에 오는 배타적
     *    스토어(strex)가 오기 까지 변경이 되었는지 
     *    하드웨어가 검증합니다.
     * 2. 값이 0인지 확인하여, 0인 경우에만 lock->lock에 1을
     *    저장합니다.
     * 3. 배타적 로드와 스토어 사이에 lock->lock의 값의 변경이
     *    있었다면 1로 돌아가서 반복합니다.
     * 4. 완료가 되었다면 smp_mb를 호출하여 메모리 베리어를
     *    사용합니다. 메모리 베리어에 의해 lock->lock의
     *    (SMP에서도) 변경 된 값이 이용되는게 보장됩니다.
     */
    __asm__ __volatile__(
"1: ldrex   %0, [%1]\n"
"   teq %0, #0\n"
    WFE("ne")
"   strexeq %0, %2, [%1]\n"
"   teqeq   %0, #0\n"
"   bne 1b"
    : "=&r" (tmp)
    : "r" (&lock->lock), "r" (1)
    : "cc");

    smp_mb();
}

위의 코드는 리눅스 커널에 ARM용으로 스핀락을 구현된 곳입니다. 주석은 제가 달았습니다. 간단하게 루프를 돌면서 기다리는 것을 볼 수 있습니다.

퀴즈: 인텔에는 배타적 로드/스토어(ldrex, strex)가 없는데 구현을 어떻게 했을까요?

Vim vs IDE (and Emacs)

Mon, 27 Feb 2012 00:48:00 +0900

hongminhee:

사람의 욕구는 기본적으로 비슷한 면을 많이 공유한다. 코딩에 있어서 손을 적게 움직여서 원하는 것을 이루고자 하는 욕구는 비슷하다. 하지만 Vim 사용자의 해법은 코드의 분량을 줄이는 것이고, IDE 사용자들의 해법은 키스트로크의 횟수를 줄이는 것이다. 그러다보니 어느쪽 사람들은 값의 타입이 추론될 수 있어야 한다고 보는 한편 다른쪽 사람들은 값의 타입이 무엇인지 코드 상에서 눈에 보여야 한다고 다르게 생각하게 되는 것이다. 어떤 편집기를 사용하느냐가 이렇듯 언어에 관한 취향에 반영된다.

Vim 사용자와 Emacs의 사용자의 입장도 또 많이 다를 것 같다. 나는 Vim으로 시작했지만 결국 Emacs로 갔는데 Vim이 키스토르크가 지나치게 많다고 생각한게 그 이유였다.

나는 차라리 함수를 정의하고 호출하는 것이 좋고, 또 어느 정도는 에디터가 자동으로 해줬으면 하는 생각이 있다. 어느 정도는 홍민희 옹이 말한 IDE 사용자 패턴과 일치하는 것이다. 반면에 기존의 IDE가 지나치게 무겁거나, 기능이 고정적인 것은 싫었고.

그래서인지 회사에서 요즘 Eclipse로 자주 작업하는 것에 대해 큰 반감도 없는 것 같다. 사실 회사에 있는 시간은 내내 Eclipse만 쓰고 있다. (안드로이드 관련 작업은 플랫폼 작업이 아닐 때는 이클립스 이외의 대안이 없는 것 같다.)

한줄요약: 이클립스 씀.

우분투 11.10 amd64 버전에서 안드로이드 빌드 환경 구축

Sat, 04 Feb 2012 10:46:00 +0900

우분투 11.10 64비트 버전에서 안드로이드 빌드 설정을 위해 테스트 해보고 있습니다. 여기를 참고해서요.

lib32readline5-dev가 설치되지 않아 우선 배제하였습니다. apt-get install의 메시지에서 lib32readline-gplv2-dev의 사용을 권고하네요. 이 패키지를 설치하면 제대로 설정되는 것 같습니다.

우분투 업데이트 후에 무선랜이 느릴 때

Sat, 04 Feb 2012 09:42:51 +0900

저는 우분투 11.04나 11.10으로 업데이트하면 SENSX170노트북에서 무선랜이 기어가더군요. 1kbps정도 나오는 걸 보면 제 예전 모뎀보다 느립니다.

nm-tool 명령을 이용하면 무선랜/유선랜 드라이버를 확인할 수 있습니다. 저는 iwlagn인데 인텔 내장 랜입니다. 드라이버에서 11n을 쓰게 되는 경우 구형 랜 칩에서 문제가 되나 보더군요. 해결책은 다음과 같습니다. 해결책 1, 해결책 2

저는 인텔 칩과 같이 범용적인 구성인데 우분투 11.04부터 아직까지 문제가 고쳐지지 않고 있는 이유를 모르겠습니다. 우분투는 정말 유지보수를 너무 똥으로 여기는 것 같습니다.

그래도 우분투가 세상을 지배했으니깐 우분투를 쓰지 않으면 더 어려워지기 때문에 계속 쓰렵니다. -_-

새누리 당에 대한 평가

Thu, 02 Feb 2012 22:29:00 +0900

새누리 당에 대해 평가합니다.

우리말로 되어 부르기 쉽고 이해하기 쉽다. (+100점)
비슷한 이름이 또 나오지 않을 테니 혼란스럽지 않다. (+100점)
좋은 의미를 가졌다. (+100점)
나쁜 당원들을 가졌다. (-1억점)

커니님으로부터 선물

Tue, 31 Jan 2012 22:08:18 +0900

감사합니다. 잘 보겠습니다.