디앙 핵본이 안드로이드의 UI 처리에 대한 글을 썼지만 그것이 왜 안드로이드가 버벅이는가에 대한 답은 되지 못 한다. 단지 기술적인 내용이었을 뿐이다. 앤드류 문(Andrew Munn)은 거기에 더해서 어째서 안드로이드가 버벅이는지에 대해 설명하고자 한다.

Follow up to “Android graphics true facts”, or The Reason Android is Laggy(Google+)

 어제 디앙 핵본이 구글+에 안드로이드의 UI가 버벅이는 이유가 허니컴 전에는 하드웨어 가속이 없어서라는 보편적인 인식이 사실이 아니라는 글을 썼다.

안드로이드 그래픽에 대한 진실들
How about some Android graphics true facts?(Google+)

 이 글은 안드로이드의 부드러운 렌더링을 둘러싼 많은 복합적인 요소들을 다룬 통찰력 있는 글이다. 불행히도 이는 많은 기술자/비기술자 안드로이드 유저들이 제기하는 근본적인 질문의 답은 되지 못한다. 그 질문은 바로

왜 안드로이드는 버벅이고 iOS, 윈도폰7, QNX, WebOS는 부드러운가?

이다. 이 글이 그에 대한 답이 될 참이다.



 하지만 시작하기 전에 몇가지 일러둘 게 있다. 일단 나는 소프트웨어 엔지니어링을 전공하는 3학년 학부생이라는 것이다. 나는 안드로이드 팀에 인턴으로 일했고, 허니컴의 하드웨어 가속을 맡았던 로메인 가이가 내 코드를 살펴보기도 했다. 하지만 나는 프레임웍 팀에서 일하지 않았고 안드로이드 렌더링 소스코드를 읽어보지도 않았다. 나는 안드로이드에 대해 공인된 사람이라고 말할 수 없으며, 내가 말하는 게 100% 정확하다고 말할 수도 없다. 하지만 내가 아는 한 최선을 다 해 보겠다.

 둘째로, 나는 1월부터 윈도폰 팀에서 인턴을 하고 있다는 것이다. 그러니 무의식중에 내가 안드로이드에 부정적으로 글을 썼을 수도 있다. 하지만 내 친구들에게 물어보면 내가 안드로이드에 대해 칭찬하는 걸 멈추게 하기 어려운 매니아란 걸 알 것이다. 나는 일주일 내내 갈아입을 안드로이드 T셔츠가 있고, 넥서스S를 포기하느니 맥북을 포기하겠다. 구글플렉스는 나의 제2의 집이었고 거기서 몇 번 밤을 새면서 청소부들을 놀라게 하기도 했다.(그리고 혹시 방문할 기회가 있다면 Big Table Cafe의 죽여주는 바나나 프렌치 토스트를 꼭 먹길 바란다.) 둘 중 어느쪽이냐면 나는 분명 윈도폰 보단 안드로이드를 편애할 것이다.

 마지막으로 이 글의 내용은 전적으로 나의 의견이며, 구글 고위직들의 입장이 아니다.

 이를 염두에 두고 시작하도록 하자.

 디앙은 이와 같은 놀라운 주장을 했다.

 "이런 식으로 구성하게 되면 60fps를 위해 꼭 하드웨어 가속이 없어도 된다. 이때 렌더링은 디스플레이의 픽셀 수와 CPU의 속도에 크게 좌우된다. 가령 넥서스S의 800*480 스크린은 안드로이드 UI에서 발생하는 모든 일반적인 스크롤과 같은 것들을 60fps로 표시하는 데 문제가 없다. 하지만 초대 드로이드는 같은 해상도에서 상당히 어려움을 겪었다."

 엉? 어떻게 이런 말을 할 수가 있지? 넥서스S를 써 본 사람이라면 누구나 가장 단순한 리스트를 볼 때도 버벅임이 생긴다는 걸 알 것이다. 그리고 그리고 만약 백그라운드에서 앱 설치든 뭐든 어떤 일이라도 일어나고 있다면 훌륭한 스크롤 같은 건 볼 수도 없다. 반면 iOS는 앱을 깔고 있을 때도 100% 부드럽다. 하지만 우리는 디앙이 CPU 퍼포먼스가 충분하다는 말이 거짓이 아니란 건 분명 알고 있다. 그럼 뭐가 문제인 건가?


근본적 문제

 가비지 콜렉터가 제대로 안 돼서 그런 건 아니다. 안드로이드가 바이트코드를 돌리는 반면 iOS가 네이티브 코드를 돌려서도 아니다. 차이가 생기는 이유는 iOS는 모든 UI 렌더링을 전용 UI 쓰레드에 실시간처리 우선권을 주고 도린다는 것이다. 반면 안드로이드는 전통적인 PC 모델을 따라서, UI를 메인 쓰레드에서 보통 우선권으로 돌린다.

 이건 단순히 이론상의 문제가 아니다. 실제로 눈으로도 볼 수 있다. 근처에 있는 아이패드나 아이폰을 집어서 사파리를 열어보라. 페이스북 처럼 복잡한 페이지를 열어보자. 절반 정도 로딩된 상태에서 스크롤 하려고 시도해보라. 모든 렌더링이 즉각 멈출 것이다. 웹사이트는 손가락을 때기 전엔 절대 로드가 완료되지 않을것이다. 이것은 UI 쓰레드가 최우선권을 갖고 있어 모든 다른 일을 중단시키기 때문이다.

 이를 안드로이드에서도 해보면, 브라우저가 스크롤 애니메이션을 그리려 하면서 HTML 렌더링도 계속하려 하는 것을 볼 수 있다. 그리고 양쪽 다 그럭저럭(OK) 해낸다. 안드로이드는 이런 이유로 좋은 듀얼코어 프로세서는 정말 효과가 있는데, 그래서 갤럭시S2가 그렇게 부드럽기로 유명한 것이다.

 iOS에서는 앱이 인스톨 되고 있을 때 화면에 손가락을 대면 렌더링이 끝날 때까지 즉시 멈추게 된다.(역자주 : 오늘 앱들을 업데이트 하면서 해봤으나 앱 인스톨은 정지되지 않는 듯 하다. 다만 웹사이트는 앤드류의 말처럼 스크롤링 하는 즉시 오브젝트 표시가 중단되며-하지만 네트워크는 계속 작동해서 불러들이고 있다- 손을 때는 순간 최종결과물이 한방에 표시된다.) 안드로이드는 이를 동시에 하려고 하고, 그래서 프레임이 떨어진다. 일단 이 사실을 알고 나면 모든 안드로이드 폰에서 이렇다는 게 보일 것이다. 왜 무비 앱에서 스크롤이 느리지? 왜냐하면 스크롤 하면서 즉시 썸네일들을 그려내려고 하기 때문이다. iOS는 스크롤이 끝난 뒤에야 느긋하게 표시하지만 말이다.

첨삭 : 몇몇 사람들(특히 곽치호(?)와 브렌트 로얄-고든이)이 iOS에 대한 나의 묘사에 실수가 있다고 지적하였다. 안드로이드와 iOS의 근본적 차이에 대한 것은 내가 말한 것이 여전히 유효하지만, 내가 예시를 드는데 있어서 너무 단순화 하여 말한 감이 있다. 나는 iOS에 그리 많이 친숙하진 않기 때문이다. 브렌트 로얄-고든이 이에 대해 설명해주었다.

"iOS에 대한 설명이 정확성이 부족하다. 여기 좀 더 자세한 내용이 있다.

1. 합성 및 미리 짜여진 애니메이션들-모두가 코어 애니메이션 렌더링 레이어 트리에 연관되는 것들-은 사실 백그라운드 쓰레드에서 돌아간다.

2. 코어 애니메이션 레이어에 새 컨텐츠를 그리는 것과 애니메이션을 구현하는 것은 메인 쓰레드에서 구동된다. 이것은 UI 구동(비주얼이 아닌)이 이루어지는 것과 같은 곳이다.

3. 대개의 코드들, 그러니까 개발자들이 쓴 모든 코드는 메인 쓰레드에서 돌아간다. 하지만 애플은 백그라운드 쓰레드로 데이터를 옮길 수 있는 아주 쉬운 API(Grand Central Dispatch와 NSOperation)를 제공한다. iOS5에서는 심지어 코어 데이터가 꼭 메인 쓰레드에 있을 필요도 없다.

당신이 목격한 것들-스크롤을 개시하면 시스템이 터치를 따라가기 위해 웹킷 렌더링을 중지하는 것-이 단순히 손가락이 화면에 닿으면 모든 걸 멈추는 메커니즘 때문만은 아니다.(주) 이는 앱 개발자들이 고통스런 수고 끝에 결정한 방식이다.

기술적인 차이가 아니다. 문화적 차이이다. 훌륭한 iOS 개발자들은 스크롤이 60fps에 근접하고 터치가 거의 완벽해질 때까지 앱을 내놓지 않는다. 하지만 훌륭한 안드로이드 개발자들은 그런 상태로도 내놓곤 한다."

글쓴이주 : 이건 엄밀히 맞는 말은 아니다. 메인 스레드는 터치추적이 시작되면 특별한 모드로 들어가게 되고, 기본 설정상태에서는 일부 작업들은 지연시키도록 되어있다. 하지만 다른 몇가지들, 가령 디스크에서의 로드나 네트워크 활동 같은 것들은 백그라운드 스레드에서 계속 돌아가고 멈추지 않는다. 개발자들은 이들을 멈추고 싶다면 수동적으로 지정해야 한다.

(역자주 : 앤드류가 처음 말한 것처럼 손을 대는 것이 모든 다른 프로세스를 무조건 정지시키진 않지만, 일부는 강제로 정지되며 나머지는 브렌트의 말처럼 개발자들이 직접 정지시키도록 지시해야 한다는 것이다. 어쨌든 전적으로는 아니더라도 iOS는 안드로이드 보다 UI 렌더링에 더 우선권을 두고 있다는 것이다.)



다른 원인들

 안드로이드의 UI가 버벅이는 근본적인 이유는 쓰레드와 우선권 때문이지만 그게 유일한 이유는 아니다.

 첫째, 디앙의 주장에도 불구하고 하드웨어 가속은 확실히 도움이 된다. 내 넥서스S는 ICS에서 하드웨어 가속이 추가된 뒤 전례없이 빠릿하게 돌아간다. 하드웨어 가속은 홈스크린이나 마켓 등에서 큰 차이를 보여준다. GPU로 부하를 분산시키는 것은 배터리 수명에도 좋은데, GPU는 이런 역할에 특화되어 있으므로 더 저전력으로도 해낼 수 있기 때문이다.

 두번째, 내가 앞서 말한 것과 조금 다르게 향상된 달빅의 GC에도 불구하고 가비지 콜렉션이 여전히 문제가 되기도 한다는 것이다. 허니컴이나 ICS에서 포토갤러리 앱을 써봤다면, 어째서 프레임이 이렇게 떨어지는지 궁금했을 것이다. 결과적으로 말하자면 포토갤러리는 30fps로 제한이 걸려있으며, 만약 이 제한을 걸지 않으면 대개의 경우 스크롤링이 60fps로 돌아가겠지만 가끔씩 GC가 멈추게 되어서 '딸꾹질'을 일으키기 때문이다. 30프레임으로 고정하는 것은 이 딸꾹질 문제를 해결하기 위해 부드러운 애니메이션을 포기한 것이다.

 세번째는 디앙이 얘기한 하드웨어 문제이다. 테그라2는 엔비디아의 휘황찬란한 마케팅에도 불구하고 떨어지는 메모리 대역폭과 NEON 명령어 미지원으로 고통받았다.(NEON은 ARM 버전 SSE라고 할 수 있고, 행렬연산을 빠르게 해준다.) 허니컴은 이때문에 일견 테그라2보다 느린 것처럼 보이는 GPU라도 더 잘 작동할 것이다. 가령 삼성 허밍버드나 애플 A4 같은 칩들 말이다. 가장 빠른 허니컴 타블렛이 갤럭시탭 7.7이며 갤럭시S2가 썼던 엑시노스 CPU를 쓴다는 것을 보라.

 네번째, 안드로이드는 좀 더 효율적인 UI 합성이 필요하다. iOS에선 각 UI들이 별개로 렌더링 되어서 메모리에 저장되며, 이들을 혼합해서 표시할 때만 GPU를 필요로 한다. GPU는 이런 작업에 매우 뛰어나다. 불행히도 안드로이드에서는 UI 혼합이 렌더링 이전에 이루어지게 되고, 그래서 화면에 어떤 조그만 변화가 있어도 전체 프레임을 새로 그려내야 한다.(역자주 : 디앙은 각 UI 창들이 별개로 업데이트 된다고 했지만 앤드류의 말대로면 이 방법은 UI 비주얼을 업데이트 하는 것 자체의 부하는 줄일 수 있지만, 최종 합성단계에서 상당한 비효율이 이루어지는 것이다.)

 마지막으로 달빅 VM은 데스크탑 JVM 만큼 훌륭하지 못 하다. 자바는 데스크탑에서 끔찍한 GUI 성능으로 악명이 높지만, 달빅에서 일어나는 일에는 미치지 못 한다. 네이티브 API들 위에 크로스 플랫폼 레이어가 올라가 있기 때문이다. 본래 윈도폰7이 완전한 실버라이트로 제작될 예정이었지만 코어 UI는 네이티브로 짜여졌다는 것도 흥미로운 점이다. 윈도폰7에서 네이티브와 바이트코드의 성능차이는 확연히 보인다. 서드파티 앱들은 실버라이트로 짜여졌고 퍼포먼스가 떨어지기 때문이다.(NoDo와 Mango 업데이트에서 이 문제를 해결하려 애써왔고 실버라이트 UI는 전에 비해 확실히 부드러워졌다.)

 다행스럽게도 이 다섯가지 문제는 안드로이드를 크게 뜯어고치지 않고도 해결할 수 있다. 하드웨어 가속은 ICS를 쓰는 모든 폰에 도입될 것이다. 달빅은 계속 GC 효율을 개선하고 있다. 테그라2는 결국 사라질 것이다. UI 합성문제를 해결하기 위한 노력이 있고, 달빅은 점점 빠른 VM이 되어가고 있다. 최근 테크크런치의 제이슨 킨케이드에게 갤럭시 넥서스가 부드럽냐고 물었을 때, 그는 이렇게 답했다.

"대체로 나는 갤럭시 넥서스의 ICS가 상당히 부드럽다는 걸 알았다. 가끔 버벅이는 경우가 있긴 하다-내가 갤넥에서 꾸준히 버벅이는 한부분은 멀티태스킹 버튼을 눌렀을 때인데, 1/4초 정도 멈추는 것 같다. 하지만 아이폰4S 역시 내 예상보다는 좀 더 버벅였고, 특히 스팟라이트로 들어갈 때 그렇다.(홈화면에서 왼쪽으로 스크롤 했을 때 말이다.)"

 자 그럼 이제 안드로이드의 버벅임 문제가 거의 해결된 건가? 그렇진 않다.



앞으로 나아갈 길

 안드로이드 UI는 내가 앞서 말했던 디자인적 한계가 있는 한 절대 완전히 부드러워질 수 없다.

- UI 렌더링이 앱와 같이 메인 쓰레드에서 이루어진다
- UI 렌더링이 보통우선권이다

 갤럭시 넥서스나 쿼드코어 트랜스포머 프래임조차도 저 두가지 디자인적 한계가 남아있는 한 부드러운 프레임을 보장할 수 없다. 저 문제들이 갤럭시 넥서스가 3년 된 아이폰 수준의 부드러움을 따라잡는데 강력한 성능을 허비하게 만든다. 그럼 왜 안드로이드 팀은 렌더링 프레임웍을 이렇게 만들었을까?

 안드로이드 개발이 시작됐을 때는 아이폰이 출시되기 전이었다. 그리고 그때 안드로이드는 블랙베리의 경쟁제품이 되도록 만들어졌다. 최초의 안드로이드 프로토타입은 터치스크린 기기가 아니었다. 안드로이드의 렌더링 트레이드오프는 키보드와 트랙볼 기기에서는 적절한 것이었다. 아이폰이 나왔을 때, 안드로이드 팀은 그에 맞추려고 서둘렀지만, 불행히도 UI 프레임웍을 다시 짜기에는 너무 늦었다.

 이같은 이유로 윈도 모바일 6.5, 블랙베리 OS, 심비안이 끔찍한 터치스크린 성능을 보이는 것이다. 안드로이드와 마찬가지로 이들 역시 UI 렌더링을 우선시해서 만들어지지 않았다. 아이폰이 나온 이후로 MS, RIM, 그리고 노키아는 모두 자신들의 모바일 OS를 폐기하고 처음부터 새로 만들고 있다. 안드로이드 만이 아이폰 이전에 개발된 모바일 OS의 유일한 생존자이다.

 그럼 왜 안드로이드 팀은 이제서라도 렌더링 프레임웍을 다시 짜지 않는가? 로메인 가이의 설명이다.

"...오늘날 우리가 해결해야 하는 일 중 상당수는 수년 전 우리가 내린 결정들 때문이다...UI 쓰레드를 만드는 것은 가장 큰 문제거리이다. 우리는 스크롤을 향상시키려고 여러 다른 해결책들을 도입하였다.(디앙이 썼던 것과 같은...) 물론 가장 확실한 해결책은 새 UI 툴킷을 만드는 것이지만, 거기엔 많은 단점 또한 따라온다."

 로메인은 단점들이 정확히 뭔지 말하진 않았지만, 추측하기란 어렵지 않다.

- 모든 앱들이 새 프레임웍에 맞춰서 새로 쓰여져야 한다.
- 안드로이드는 구식 앱을 위한 레거시 모드를 갖춰야한다.
- 새 프레임웍을 개발하는 동안 다른 안드로이드 기능 개발이 지연될 것이다.

 하지만 나는 이런 단점에도 불구하고 재구축이 반드시 이뤄져야 한다고 생각한다. 프로덕트 매니저 지망생으로써, 나는 안드로이드의 버벅임이 절대 용납되선 안 된다고 본다. 이는 안드로이드 팀의 최우선 과제가 되야한다.

 안드로이드에 대해 기술자/비기술자 친구들과 얘기할 때면, 나는 언제나 안드로이드가 버벅이고 느리단 말을 듣는다. 실제로는 안드로이드가 iOS 만큼, 혹은 더 빠르게 앱을 실행하거나 웹페에지를 렌더링한다 하더라도, 결국 인식이 전부이다. UI 렉을 고치는 것은 안드로이드의 이미지를 개선하는 것이다.

 인식 문제를 넘어서서, 버벅임은 구글의 핵심 철학을 훼손하고 있다. 구글은 모든 것이 빨라야 한다고 생각한다. 그 철학이 구글 검색, G메일, 크롬의 근저에 있다. 그게 구글이 HTTP를 향상시키려고 SPDY를 만든 이유이다. 그게 구글이 자신들의 웹사이트를 최적화 할 툴을 만든 이유이다. 그게 구글이 자신들의 CDN을 구축한 이유이다. 그게 구글맵이 WebGL로 렌더링 되는 이유이다. 그게 유투브 버퍼링이 한때는 만연했으나 오늘날 거의 보이지 않는 이유이다.(역주 : 해외에선 열악한 회선에도 불구하고 유투브 버퍼링이 거의 제로라고 해도 무방하다.)

 하지만 안드로이드의 UI 렉이 용납되지 않는 가장 큰 이유는 아마도 휴먼-컴퓨터 인터렉션 영역에서의 관점일 것이다. 현대의 터치스크린은 손가락의 움직임과 화면의 애니메이션을 1:1 매칭 시키는 행동밀착형 언어이다. 이것이 iOS의 오버 스크롤 이펙트가 그렇게 멋지면서, 재밌고, 직관적인 이유이다. 그리고 이것이 버진 아메리카 항공의 터치스크린이 끔찍한 이유이다. 그것들은 놀라울 정도로 버벅이고, 반응성이 떨어지고, 정확도가 떨어진다.

 UI 렉은 터치스크린의 행동밀착형 언어를 파괴하는 것이다. 기기가 더이상 자연스럽게 느껴지지 않게 되고, 마법을 잃어버리게 된다. 유저는 상호작용에서 박탈되게되고 결국 이것이 불완전한 컴퓨터 시뮬레이션이란 걸 인식하게 되고 만다. 나는 종종 아이패드에서도 이런 '상실감'을 맛보지만, Xoom의 홈스크린 이동이 버벅일 때는 버틸 수가 없을 정도였다. 2억 안드로이드 유저는 더 나은 체험을 할 자격이 있다.

 그리고 나는 그들이 결국 해낼 거란 걸 알고 있다. 안드로이드 팀은 세계에서 가장 헌신적이고 재능있는 개발자들이다. 디앙 핵본이나 로메인 가이 같은 스타들이 있으니 안드로이드 렌더링 프레임웍은 행운아다.

 나는 이 포스트가 안드로이드의 버벅임을 둘러싼 혼란을 감소시키길 바란다. 그리고 운이 따라준다면 안드로이드 5.0은 HTC G1 이래 우리 모두가 꿈꿔왔던 정말 부드러운 안드로이드가 될지도 모른다. 그동안 나는 MS에서 어느 아름답고 부드러운 모바일 OS가 그에 걸맞는 관심을 받을 수 있도록 애쓸 것이다.



크레딧

이 포스트의 일부는 아래 ddtro의 UI 쓰레드와 실시간 처리 문제에 대한 글에서 영감을 받았다.

 

 

 

 

출처 : Follow up to “Android graphics true facts”, or The Reason Android is Laggy(Google+)

번역문 출처 : http://eggy.egloos.com/3776976