블로그에 포스팅할려고 번역 했어요. 블로그에는 http://www.androidpub.com/1878598 랑 같이 포스팅해야 겠다 싶어서 제 블로그에 올리기 전에 안펍에 먼저 나눠드려요. ^^


중간 중간 틀린 부분이나, 지나치게 의역된 부분이 있을 수 있습니다. 하지만 본문에서 글쓴이가 말하고자 하는 내용에 충실하게, 충분히 전달하려고 노력하였습니다. ^^ 번역을 보지 마시고, 원래 글쓴이(Dianne)의 의도를 보세요.


즐겨주세요.


---- ---- ---- ---- 


Dianne Hackborn - 오후 4:21에 수정 - 공개

안드로이드 그래픽에 대한 진짜 진실에 관심 있으신가요?


안드로이드에서 그래픽이 어떻게 렌더링 되는 가에 대해 많은 곳에서 잘못된 정보들을 반복해서 포스팅하는걸 보고 있는게 슬슬 짜증이 밀려 오네요. 여기서 진실 몇 개를 말해 볼께요:


• 안드로이드는 항상 어느 정도는 하드웨어 가속을 사용해왔어요. 화면에 디스플레이되는 모든 윈도우의 내용들은 버전 1.0에서부터 쭉 하드웨어를 사용해 왔죠.


• 이 말은 여러분들이 보는 많은 애니메이션들이 언제나 하드웨어 가속을 사용해 왔다는 거에요. 눈에 보이는 메뉴들이나, 슬라이딩 되는 알림정보(notification), 액티비티들 간 변화할 때, 팝업이나 다이얼로그가 보이거나 숨겨질 때 등에 사용되요.


• 역사적으로 안드로이드는 각 윈도우에서 컨텐츠를 렌더링할 때 소프트웨어를 이용해 왔어요. 예를 들면, http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png에 있는 UI의 경우, 상태창(status bar), 바탕 배경(wallpater), 배경 위에 런쳐, 메뉴라는 네 개의 윈도우가 존재하지요. 만약 메뉴 아이템에 선택 표시(highlight)를 한다던가 하는 식으로 어떤 윈도우의 내용이 업데이트되면, (3.0 이전에는) 해당 윈도우에 업데이트된 내용을 그릴 때 소프트웨어를 사용해요. 그렇지만 다른 윈도우들은 다시 그려질 필요가 전혀 없기 때문에, 다른 윈도우들의 내용들은 하드웨어단에서 처리하게 되요. 마찬가지로, 윈도우 상에 어떤 움직임이 생성되는 경우, 예를 들어 메뉴가 올라오던가 내려가는 경우에는 모두 하드웨어 렌더링을 사용해요.


• 윈도우 내에 그려지는 것을 살펴보시죠. 완전한 60fps의 렌더링을 사용하려 한다고 해서 꼭 하드웨어를 사용할 필요는 없답니다. 렌더링 속도는 사용하시는 디스플레이 내의 픽셀의 개수와 CPU 속도에 영향을 많이 받으니까요. 예를 들면, NexusS에서는 여러분들이 안드로이드 UI에서 보는 보통의 요소들, 800x480 크기의 화면에서 리스트를 스크롤링한다던가 하는 부분들을 60fps로 렌더링하는데 문제가 없어요. 하지만 오리지날 Droid에서는 비슷한 화면 크기를 가지고 있지만 조금 밀리는 느낌이 들지요.


• 윈도우 내에서 완전히 하드웨어 가속"만"을 이용한 그리기는 안드로이드 3.0에서 추가된 부분이에요. 안드로이드 4.0에서 구현된 부분은 3.0과는 달리 더 이상 하드웨어 가속만을 사용하지 않는답니다. 만약 여러분이 개발하시는 앱에 하드웨어 가속을 이용할 수 있도록 플래그를 선언해 두셨으면, 3.0에서부터는 해당 앱의 모든 윈도우는 GPU를 이용해서 그려질 거에요. 이런 점에서 안드로이드 4.0의 주요 변경 부분은 이렇습니다. 이제 4.0 이상이라고 명시된 앱에서는 manifesto에 android:handwareAccelerated="true"라고 선언하지 않아도 하드웨어 가속이 기본으로 활성화됩니다. (추가적으로, 기존에 존재하던 앱들에서 이 부분이 그냥 활성화되지 않는 이유는 특정 종류의 그리기 명령(drawing operation)이 특정 하드웨어에서 제대로 지원되지 않을 수 있기 때문이며, 이런 부분은 앱들이 자신의 UI 상태를 변경하기 위해 물어보는 행동에 영향을 줄 수도 있기 때문이에요. 기존 앱들에 강제로 하드웨어 가속을 이용한 그리기를 실행할 경우 많은 경우에 때로는 미묘하게, 때로는 눈에 보이게 그래픽이 깨지게 될거랍니다.)


• 하드웨어 가속을 이용한 그리기에 장점만 존재하는 것은 물론 아니에요. NexusS나 Galaxy Nexus에 탑재된 PVR(주: PowerVR사) 드라이버의 예를 들면, OpenGL 프로세스를 이용하기 시작했는데, 이 프로세스는 약 8메가 정도나 되는 메모리를 먹어치우고 있거든요. 프로세스의 오버헤드(process overhead)가 약 2메가 밖에 안된다는 것을 감안하면, 8메가는 굉장히 많이 잡고 있는 거죠. 메모리를 점유하고 있다는 것, 예를 들면 많은 수의 백그라운드 프로세스가 계속 실행되고 있는 경우가 있을텐데, 이런 경우 앱을 전환하거나 하는 행동을 할 때 잠재적으로 느려질 수 있다는 의미니까요.


• OpenGL의 오버헤드(overhead) 때문에 누군가는 이에 대한 사용을 원하지 않할 수도 있어요. 우리가 NexusS에서 안드로이드 4.0이 잘 작동하도록 하기 위해 하는 일 중 하나를 예를 들면, 시스템 프로세스에서 8메가의 메모리를 잃지 않도록 하기 위해 하드웨어 가속을 끄는 기능도 UI의 일부로 포함하고 있어요. 또 다른 8메가는 전화 프로세스, 또 다른 8메가는 시스템 UI 프로세스 등이라서요. 확신하는데 여러분은 모르셨을 거에요. 여기저기 예쁜 애니메이션이나 상태창(status bar) 따위를 그리기 위해 OpenGL을 사용하는건 기계에는 아무런 이익이 되지 않는답니다.


• 하드웨어 가속 그리기는 매끈한 UI를 그리기 위한 요술 방망이가 아니에요. 이것을 달성하기 위해 다양한 노력이 있어 왔죠. 1.6에서 포어그라운드(foreground)와 백그라운드(background) 스레드에 대한 스케줄링(scheduling) 향상이 있었구요, 2.3에서는 입력 시스템,  스트릭트 모드(strict mode), 동시 가비지 콜렉션(concurrent garbage collection), 로더(loader) 등을 다시 작성했어요. 여러분이 60fps를 달성하고 싶으시면 각 프레임을 20 milliseconds로 처리하셔야 해요. 이건 긴 시간이 아니잖아요. 실행하고 있는 스레드에서 플래시 저장소 시스템에 저장하겠다고 터치하는 것만으로도, UI는 그 짧은 타이밍에서 벗어나게 만들 지연(delay)이 발생하는 경우도 있어요. 특히 저장소에 저장하는 경우에 그렇죠.


• 부드러운 UI에 영향을 준 흥미로운 일들 중 최근의 예들을 살펴 볼께요. NexusS에 올린 ICS에서 리스트들을 스크롤링 할 때보면 사실 GingerBread때보다 덜 부드럽다는걸 알게 되실거에요. 그 이유는 미묘한 타이밍 변화에 의한 것임이 밝혀졌는데, ICS에서는 터치 이벤트를 받은 후 스크린에 그릴때, 그 준비가 되기 약간 전에 다음 이벤트(손가락의 위치를 따라가는 것)로 옮겨 가게 된다고 하네요. 그래서 가끔 ICS에서는 터치 이벤트를 받아 스크린에 그릴 때 화면에 60fps로 그리더라도 손가락을 따라가는 동안 가시적으로 프레임이 놓치는 것처럼 보이는 거에요.


• 사람들이 예전부터 안드로이드와 iOS의 웹브라우저를 비교하는데, 비교 시 발견되는 다른 점들의 대부분은 하드웨어 가속 때문이 아니랍니다. 원래부터 안드로이드는 웹페이지 렌더링 부분에 대해서는 안드로이드만의 절충안을 만들어 다른 방향으로 가고 있었어요. 예를 들면, 웹페이지는 타일(tile)을 사용 하는 대신 지속적으로 화면에 렌더링되도록 디스플레이 리스트(display list)에 보여져요. 각기 그려져야 하는 타일(tile) 단위의 조각들이 아니기 때문에 스크롤을 할 때나 줌을 할 때 이점을 주었죠. 나쁜 점은 웹페이지의 그래픽들은 그리기에 더 복잡해져서 프레임 주기(frame rate)가 떨어진다는 점이에요. 현재 안드로이드 3.0의 웹브라우저에서는 타일(tile) 렌더링을 사용해요. 그래서 여러분들이 스크롤이나 줌을 할 때 생성되는 타일들에서, 표현 되어 보여져야 하지만 빠르게 렌더링 되지 못할 때 발생하는 제대로 보이지 않는 요소들을 표현할 때도 일관된 프레임 주기로 관리할 수 있게 해준답니다. 타일들 자체는 소프트웨어에서 렌더링 되고요, 제 생각에는 iOS에서도 비슷할 거라 생각되네요. (그리고 이 타일 기반의 접근 방식은 하드웨어 가속 그리기가 지원되지 않아도 3.0 이전에서 사용될 수 있어요. 이미 언급했다시피 NexusS는 CPU만으로 윈도우에서 타일을 60fps로 쉽게 그릴 수 있으니까요.)


• 하드웨어 가속은 그리기 성능을 마법처럼 말끔히 해소해 주지는 않아요. GPU 성능 만큼의 한게가 존재하거든요. 최근의 흥미로운 예는 테그라2(Tegra 2)에서 빌드된 타블렛의 경우 인데요, 테그라2의 GPU는 1024x800 화면상 모든 픽셀의 2.5배 가량을 60fps로 그려낼 수 있어요. 앱 목록을 변경할 수 있는 안드로이드 3.0 타블렛의 홈 스크린을 한 번 생각해 보시면 쉬워요. 이 경우 배경은 (모든 픽셀에 대해 1x로) 그려져야 하고요, 그리고 나서 바로가기(shortcut) 레이어와 위젯들을 (확실치 않지만 그냥 기분 좋게 모든 픽셀에 대해 5x라고 치고) 그린 후, 모든 앱들의 검은 배경을 (모든 픽셀에 대해 1x로) 그리고나서 앱들의 아이콘과 이름들을 (모든 픽셀에 대해 5x로) 그려야 하죠. 자, 이미 예측된 픽셀 수는 날아가 버린 듯 하네요. 아직 별개의 윈도우들에 있는 내용들을 한 번에 표현하기 위한  통합 그리기 과정을 진행조차 하지도 않았는데 말이에요. 이런 상황에 60fps 애니메이션을 만들어 내기 위해 안드로이드 3.0 이상에서는 몇 가지 트릭(trick)을 사용해요. 제일 중요한 것 중 하나는 오버레이(overlay)상에 있는 모든 윈도우를 GPU를 이용해서 프레임버퍼에 복사하는 것이 아니라, 그냥 오버레이 상에 두려고 한다는 점이에요. 지금 말하는 이 경우에는 이미 픽셀 수는 예상보다 초과되었지만, 또 다른 트릭(trick)을 사용할 수 있어요. 왜냐하면 안드로이드의 바탕화면은 다른 윈도우에 있는 데다가 비트맵 전체 정보를 갖고 있는 실제 화면보다 이 윈도우를 더 크게 만들 수 있으니까요. 자 이제, 스크롤을 하시면 배경의 움직임은 전혀 그릴 필요가 없고 그냥 윈도우만 움직일 뿐이게 되요. 왜그렇게 되냐하면 이 윈도우는 오버레이(overlay) 상에 있기 때문에, 이 부분은 GPU를 이용해서 화면에 표현하려고 다른 요소들과 통합시켜 그릴 필요조차 없게 되요.


• 기기의 화면 해상도가 올라갈 수록 UI를 60fps로 그려내는 것은 GPU의 속도, 특히 GPU의 메모리 버스의 옹량(memory bus bandwidth)과 관련이 있다고 보시면 되요. 실제로 여러분들이 어떤 하드웨어에 대한 성능 값을 얻기를 원하실 때는 항상 메모리 버스의 용량에 주의를 기울이셔야 하구요. (특히나 경이로운 NEON 인스트럭션을 사용하는 경우의) CPU는 늘상 메모리 보다 더 훨씬 더 빠르게 작동할 수 있으니까요.

 

출처: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s#105051985738280261832/posts/2FXDCz8x93s 

이 게시물을