출처: http://eggy.egloos.com/3776976
디앙 핵본이 안드로이드의 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의 죽여주는 바나나 프렌치 토스트를 꼭 먹길 바란다.) 둘 중 어느쪽이냐면 나는 분명 윈도폰 보단 안드로이드를 편애할 것이다.
마지막으로 이 글의 내용은 전적으로 나의 의견이며, 구글 고위직들의 입장이 아니다.
이를 염두에 두고 시작하도록 하자.
디앙은 이와 같은 놀라운 주장을 했다.
엉? 어떻게 이렇게 말할 수가 있지? 넥서스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이 되어가고 있다. 최근 테크크런치의 제이슨 킨케이드에게 갤럭시 넥서스가 부드럽냐고 물었을 때, 그는 이렇게 답했다.
자 그럼 이제 안드로이드의 버벅임 문제가 거의 해결된 건가? 그렇진 않다.
앞으로 나아갈 길
안드로이드 UI는 내가 앞서 말했던 디자인적 한계가 있는 한 절대 완전히 부드러워질 수 없다.
- UI 렌더링이 앱와 같이 메인 쓰레드에서 이루어진다
- UI 렌더링이 보통우선권이다
갤 럭시 넥서스나 쿼드코어 트랜스포머 프래임조차도 저 두가지 디자인적 한계가 남아있는 한 부드러운 프레임을 보장할 수 없다. 저 문제들이 갤럭시 넥서스가 3년 된 아이폰 수준의 부드러움을 따라잡는데 강력한 성능을 허비하게 만든다. 그럼 왜 안드로이드 팀은 렌더링 프레임웍을 이렇게 만들었을까?
안드로이드 개발이 시작됐을 때는 아이폰이 출시되기 전이었다. 그리고 그때 안드로이드는 블랙베리의 경쟁제품이 되도록 만들어졌다. 최초의 안드로이드 프로토타입은 터치스크린 기기가 아니었다. 안드로이드의 렌더링 트레이드오프는 키보드와 트랙볼 기기에서는 적절한 것이었다. 아이폰이 나왔을 때, 안드로이드 팀은 그에 맞추려고 서둘렀지만, 불행히도 UI 프레임웍을 다시 짜기에는 너무 늦었다.
이같은 이유로 윈도 모바일 6.5, 블랙베리 OS, 심비안이 끔찍한 터치스크린 성능을 보이는 것이다. 안드로이드와 마찬가지로 이들 역시 UI 렌더링을 우선시해서 만들어지지 않았다. 아이폰이 나온 이후로 MS, RIM, 그리고 노키아는 모두 자신들의 모바일 OS를 폐기하고 처음부터 새로 만들고 있다. 안드로이드 만이 아이폰 이전에 개발된 모바일 OS의 유일한 생존자이다.
그럼 왜 안드로이드 팀은 이제서라도 렌더링 프레임웍을 다시 짜지 않는가? 로메인 가이의 설명이다.
로메인은 단점들이 정확히 뭔지 말하진 않았지만, 추측하기란 어렵지 않다.
- 모든 앱들이 새 프레임웍에 맞춰서 새로 쓰여져야 한다.
- 안드로이드는 구식 앱을 위한 레거시 모드를 갖춰야한다.
- 새 프레임웍을 개발하는 동안 다른 안드로이드 기능 개발이 지연될 것이다.
하지만 나는 재구축이 이런 단점에도 불구하고 반드시 이뤄져야 한다고 생각한다. 프로덕트 매니저 지망생으로써, 나는 안드로이드의 버벅임이 절대 용납되선 안 된다고 본다. 이는 안드로이드 팀의 최우선 과제가 되야한다.
안 드로이드에 대해 기술자/비기술자 친구들과 얘기할 때면, 나는 언제나 안드로이드가 버벅이고 느리단 말을 듣는다. 실제로는 안드로이드가 iOS 만큼, 혹은 더 빠르게 앱을 실행하거나 웹페에지를 렌더링한다 하더라도, 결국 인식이 전부이다. UI 렉을 고치는 것은 안드로이드의 이미지를 개선하는 것이다.
인식 문제를 넘어서서, 버벅임은 구글의 핵심 철학을 훼손하고 있다. 구글은 모든 것이 빨라야 한다고 생각한다. 그 철학이 구글 검색, G메일, 크롬의 근저에 있다. 그게 구글이 HTTP를 향상시키려고 SPDY를 만든 이유이다. 그게 구글이 자신들의 웹사이트를 최적화 할 툴을 만든 이유이다. 그게 구글이 자신들의 CDN을 구축한 이유이다. 그게 구글맵이 WebGL로 렌더링 되는 이유이다. 그게 유투브 버퍼링이 한때는 만연했으나 오늘날 거의 보이지 않는 이유이다.(역주 : 해외에선 열악한 회선에도 불구하고 유투브 버퍼링이 거의 제로라고 해도 무방하다.)
하 지만 안드로이드의 UI 렉이 용납되지 않는 가장 큰 이유는 아마도 휴먼-컴퓨터 인터렉션 영역에서의 관점일 것이다. 현대의 터치스크린은 손가락의 움직임과 화면의 애니메이션을 1:1 매칭 시키는 행동밀착형 언어이다. 이것이 iOS의 오버 스크롤 이펙트가 그렇게 멋지면서, 재밌고, 직관적인 이유이다. 그리고 이것이 버진 아메리카 항공의 터치스크린이 끔찍한 이유이다. 그것들은 놀라울 정도로 버벅이고, 반응성이 떨어지고, 정확도가 떨어진다.
UI 렉은 터치스크린의 행동밀착형 언어를 파괴하는 것이다. 기기가 더이상 자연스럽게 느껴지지 않게 되고, 마법을 잃어버리게 된다. 유저는 상호작용에서 박탈되게되고 결국 이것이 불완전한 컴퓨터 시뮬레이션이란 걸 인식하게 되고 만다. 나는 종종 아이패드에서도 이런 '상실감'을 맛보지만, Xoom의 홈스크린 이동이 버벅일 때는 버틸 수가 없을 정도였다. 2억 안드로이드 유저는 더 나은 체험을 할 자격이 있다.
그리고 나는 그들이 결국 해낼 거란 걸 알고 있다. 안드로이드 팀은 세계에서 가장 헌신적이고 재능있는 개발자들이다. 디앙 핵본이나 로메인 가이 같은 스타들이 있으니 안드로이드 렌더링 프레임웍은 행운아다.
나 는 이 포스트가 안드로이드의 버벅임을 둘러싼 혼란을 감소시키길 바란다. 그리고 운이 따라준다면 안드로이드 5.0은 HTC G1 이래 우리 모두가 꿈꿔왔던 정말 부드러운 안드로이드가 될지도 모른다. 그동안 나는 MS에서 어느 아름답고 부드러운 모바일 OS가 그에 걸맞는 관심을 받을 수 있도록 애쓸 것이다.
크레딧
이 포스트의 일부는 아래 ddtro의 UI 쓰레드와 실시간 처리 문제에 대한 글에서 영감을 받았다.
이 글은 해커뉴스의 코룬이 안드로이드와 iOS의 UI 합성 문제를 설명한다.
http://news.ycombinator.com/item?id=3310475
안드로이드의 역사에 대해서는 스티븐 레비의 'In the Plex'와 월터 아이작슨의 '스티브 잡스'를 참고하였다.
디앙 핵본이 안드로이드의 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 쓰레드와 실시간 처리 문제에 대한 글에서 영감을 받았다.
이 글은 해커뉴스의 코룬이 안드로이드와 iOS의 UI 합성 문제를 설명한다.
http://news.ycombinator.com/item?id=3310475
안드로이드의 역사에 대해서는 스티븐 레비의 'In the Plex'와 월터 아이작슨의 '스티브 잡스'를 참고하였다.
|
|
트랙백
'모바일' 카테고리의 다른 글
| 넥서스S (SHW-M200K) 국내 정식 젤리빈 업데이트 후기 (2) | 2012.10.17 |
|---|---|
| 아이스크림샌드위치 4.0.4 OTA 업데이트 완료! + 뻘글 (0) | 2012.05.03 |
| [링크] 4G의 대세 LTE, 그 발전 가능성은? (0) | 2011.11.13 |
| KT 넥서스S에서 T Store 이용하기 (0) | 2011.09.01 |
| GPS카메라에 관한 포스트 링크 (0) | 2008.11.29 |
덧글
Ha-1 2011/12/07 19:42 # 답글
노래 실력만이 전부이던 음악 씬에 노래도 제법 잘 부르면서 얼굴 예쁜 가수가 나타나서 초토화된 꼴이군요. 기존 가수 중 뛰어난 가수는 앨범 판매는 앞서지만 공연에서는 영 밀리는 형국
maxi 2011/12/07 19:47 # 답글
좋은 글 잘읽었습니다.
로리 2011/12/07 19:50 # 답글
좋은 글인데 참 어렵군요 ^^
YoUZen 2011/12/07 20:11 # 답글
안드로이드가 느리게 느껴지는 것, 아이폰이 부드럽게 느껴지는 것엔 이런 이유가 있었군요. 안드로이드가 살짝걱정되지만 구글이니까 괜찮을거예요.
fzud 2011/12/07 20:30 # 삭제 답글
iOS의 그 부드러움은 정말 잡스의 편집증이 아주 긍정적으로 작용한 효과가 결과가 아닌가 생각합니다. 2007년도에 아이폰이 세상에 처음으로 나왔을때 부터 (IPhone OS2.0) 스크롤시의, 줌인/아웃시의 부드러움,바운드효과, 폰트 디더링등.. 도저히 이게 어디서 외계인 고문이라도 한게 아닌가 할 정도로 믿을수 없을정도로 완성도 높은 UI로 나왔었지요.. 특히 당시의 비교군은 윈모나 CE 였기에.. 이미 그 당시에 휴먼인터페이스 철학면에서 iOS의 완성도는 어디 테클걸 부분이 거의없을 정도;;그런 면에서 보면 윈모7도 이전 족보를 다 버리고 갑둑튀한놈으로 보면 UI쪽 완성도가 참 높아서 신기합니다.
yonetiger 2011/12/07 20:48 # 삭제 답글
잘 읽었습니다. 정말 좋은 글이군요.학부 3년생이신데.. 놀라운 지식입니다.
앞으로 자주 들러야겠네요.. 좋은 글 부탁드립니다.^^
계란소년 2011/12/07 20:49 #
제가 학부 3년생이라는 게 아니라 번역한 글의 원작성자가 학부 3년생이라네요.
사바욘의_단_울휀스 2011/12/07 21:08 # 답글
대충읽어보니 아직 최적화가 안끝나고 앞으로도 안끝날 가능성이 있는 안드로이드...
Eternalberry 2011/12/07 21:34 # 답글
잘 읽었습니다. 금새 번역해주시네요.제 개인적인 생각은 레거시 mode를 만들더라도 새로운 Framework을 만드는 것이 맞아 보이는데 어떻게 생각하세요?
계란소년 2011/12/08 00:19 #
사실 원래 목적이 이거였는데 거기에 앞 글이 좀 부연적으로 필요할 거 같아서 먼저 한 거였거든요. 그리고 프레임웍이 정말 문제라면 새로 만드는 게 맞다고 봅니다. 사실 이번 갤넥의 온스크린 버튼들을 생각하면 이 기회에 이거랑 한번에 묶어서 처리해야 했다는 생각이 드네요. 이 녀석도 잠재력은 있을지 몰라도 강제화가 약해서 결국 디펙토 표준에 밀려서 시망하게 될 것 같은 생각이 듭니다.
라임에이드 2011/12/07 21:59 # 삭제 답글
사실상 무슨 원칙 vs UI의 대결이 아니라 레거시 vs UI의 대결이군요. 구글이 언젠가 마소의 윈폰7 급 결단을 내려주기를 바랍니다.
LionHeart 2011/12/07 22:18 # 답글
잘 읽었습니다. 덕분에 두 OS에서 이런 차이가 있다는 것을 알게 되었네요. ^^
식용달팽이 2011/12/07 22:57 # 답글
좋은 정보 감사합니다. 언젠가 안드로이드가 iOS와 같은 수준의 UX를 제공한다면 굳이 iOS 기기를 둘이나(아이폰과 아이패드) 가질 필요가 있을까 생각했거든요.글을 읽어 봤을 때 그리 먼 미래가 아닌 곳 같아 안심했습니다. 윈도폰7이후도 괜찮아보이긴 하지만 손이 잘 안가는 건 예전 PDA시절에 CE에 크게 데인 때문이죠 ㅎㅎ
번역 감사합니다.
달리나음 2011/12/07 23:43 # 삭제 답글
1. Android 허니컴 이후 렌더스크립트를 채택한 앱의 경우에는 에니메이션 코드나 필터링 처리 등이 백그라운드 처리에서 돌아가기도 합니다. 렌더스크립트는 렌더스크립트 컴퓨팅과 그래픽으로 나눌 수 있는데 이 두가지 모두를 적용한 경우죠.2. 안드로이드의 경우 Strict mode를 채택한 앱의 경우에는 UI와 다른 로직들이 명시적으로 분리되어야 합니다. 허니컴 이후에서는 Strict mode에 대한 강제를 늘리고 있습니다.
3. 현대적인 운영체제는 사용자와의 상호작용에 더 자주 스케쥴링하러 노력하고 있고 안드로이드가 채택한 리눅스도 그러한 방법을 선택하고 있습니다. 아이폰에서 얼마만큼 더 진보된 방식을 채택하는지 모르겠지만 상당 수는 앱이 그렇게 구현된 까닭이겠지요. 이것은 선택의 문제라고 봅니다.
4. 허니컴과 아이스크림 샌드위치의 전(full) 하드웨어 가속 범위의 차이가 없는 것을 감안할 때 ICS에서 UI의 반응이 빠른 것의 상당 수는 전 하드웨어 가속과 무관한 것입니다.
5. 엑시노스 CPU는 꽤 괜찮은 CPU와 GPU를 가지고 있는데 왜 느린 GPU를 선택한 곳에서도 잘 동작한다고 얘기하는지 모르겠습니다.
6. 안드로이드의 UI 합성에 대해 이야기한 부분은 검증할 필요가 있겠습니다. 저도 업데이트되지 않는 영역에 대한 재 처리가 필요없는 것으로 알고 있습니다.
7. 달빅에 대한 비판은 합당하지 못합니다. JVM에 선택하고 있는 메서드 세분 JIT 컴파일러는 메서드 단위로 한계치가 넘었을 때 해당 메서드를 빌드하는 방식인데 이 방법은 메모리를 더 많이 차지하고 불필요한 코드를 더 많이 빌드합니다. 그 만큼 반응시간은 늦어지게 되죠. 물론 처리 성능은 더 많이 증가합니다. 달빅이 선택한 트레이스 세분 JIT은 더 적은 메모리 공간과 최단 경로로의 코드를 빌드하기 때문에 반응 시간은 더 빨라 집니다. 어떤 선택이든 trade-off는 항상 존재합니다.
8. 안드로이드 역시 대부분의 API가 C/C++로 짜여져 있고 JAVA 코드는 JNI를 통해 대문 역할을 하고 있습니다.
문제점의 핵심은 무엇이다고 짧게 진단하는 것은 매우 어려운 일이고 저도 할 수 없는 일이겠지요. 그리고 저 아저씨도 말입니다.
달리나음 2011/12/08 00:01 # 삭제
허니컴과 ICS를 비교한 것은 같은 디바이스에 ICS를 올려도 더 빠르기 때문이었습니다. 조금 더 자세히 이야기를 했어야 했는데 성급하게 글을 적었네요.Romain Guy는 Chet Haase와 함께 여기 저기 다니며 강연하는데 그것도 한번 살펴보세요. 계란소년님에게도 흥미로울 수 있겠네요.
계란소년 2011/12/08 00:01 #
1, 2. 3.0 이후 개선되었거나 개선되고 있는 사항에 해당한다 봅니다. 본문에서도 언급한 원인들이 모두 당분간 지속될 것들은 아니고 상당수가 해결중이라고 말하고 있네요.3. OS 차원인지 앱 차원인지에 대해서는 제가 결론을 낼 순 없겠네요.
4. 허니컴과 ICS가 직접적인 비교가 가능한지 모르겠네요. 일단 허니컴 기기와 ICS 기기는 AP도 거의 다 다르고 해상도도 다르며, 보통 지금 ICS에서 반응속도가 빠르다는 건 갤넥과 다른 기기의 비교, 혹은 넥S에서 진저브레드와의 비교인 듯 합니다. 허니컴에 대해서는 테그라2가 주범 중 하나는 지적이 있는데 이건 다른 AP를 쓴 녀석과 비교해봐야겠죠. 아니면 ICS 업그레이드 된 허니컴 타블렛이든지...
5. 마지막에 뜬금없이 느린 GPU 얘기하다가 뜬금없이 갤탭 7.7이 나오긴 했는데 그냥 테그라2가 아닌 녀석을 얘기하려다 실수한 거 같습니다.
6. 저는 자세히 모르는 바입니다.
7. 달빅 대신 JVM 방식을 쓰라는 말로 보이진 않습니다.
8. JAVA가 느리니까 그냥 거기 있다는 것만으로 언급됐다는 생각은 듭니다.
문제의 요인은 많겠지만 실제 구글 고위 엔지니어인 로메인 가이의 말은 앤드류의 최종 주장이 가장 주된 원인이란 걸 확인해주지 싶습니다.
계란소년 2011/12/08 00:03 #
덧글 정정하느라 순서가 꼬였네요. 여하튼 허니컴->ICS의 스크롤 개선은 하드웨어 가속 외의 것이겠지만 진저->ICS에서는 하드웨어 가속이 주된 원인이 아닐까 합니다.
달리나음 2011/12/08 00:06 # 삭제
동의합니다. 하드웨어 가속을 더 많은 부분에 적용할 수 있으면 더 매끄럽고 더 화려할 수 있을 겁니다. 하드웨어 가속을 안해도 60프레임 보장할 수 있다하지만 사실 넥서스 S에 메모리가 충분했다면 더 많은 곳에 적용했겠죠.
2011/12/07 23:57 # 답글 
비공개 덧글입니다.
계란소년 2011/12/07 23:59 #
페북 쓰라고
2011/12/08 00:29 # 답글 
비공개 덧글입니다.
계란소년 2011/12/08 00:30 #
그러니까 페북으로 소식 물으라고
아방가르드 2011/12/08 00:48 # 답글
역시 po블로거wer다운 엄청남이란...; 완전히 읽지는 못했지만 갤S2 유저로서 가끔 아이폰 3GS만도 못한것 같은 터치 부드러움의 원인을 조금 알것 같네요.
자갤러 2011/12/08 01:51 # 답글
좋은글 읽었습니다. 이런글 읽기 힘든데 좋은 자료들 보고 갑니다.^^
DIVE 2011/12/08 01:58 # 답글
아직 학부 3학년 이시라면서 굉장히 해박하시네요!
계란소년 2011/12/08 02:04 #
4학년입니다.
DIVE 2011/12/08 02:25 #
...진지하게 대꾸하지마여
사거리 2011/12/08 02:36 # 삭제 답글
안드로이드 애니메이션의 버벅임에 대해선 인용된 Romain Guy 의 멘트가 핵심인 것 같은데 .. 그 부분, 직역이 낫지 않을까요?
계란소년 2011/12/08 02:38 #
가이의 멘트는 포스팅이 아니라 아래 글(그래픽)에 달린 덧글이더군요. 원문은 아래와 같고 생략부분을 제외하면 인용된 것과 별 차이는 없습니다.+Florent Pillet You are right, a lot of the work we have to do today is because of certain choices made years ago. I'm not sure I agree with your conclusions about View vs ViewGroup but having the UI thread handle animations is the biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.
링고 2011/12/08 03:28 # 답글
새로운 버젼의 인조인간이 나오면 끊김 문제가 해결될 수도 있다는 것이네요. 그런데, 인조인간의 버벅거림도 수수께끼지만 데스크탑에서 유투브의 버벅거림도 수수께끼라는...
계란소년 2011/12/08 03:29 #
한국에서 유투브가 버벅거리는 이유는 첫째는 인터넷 실명제 문제로 국내에 미러서버가 개설되지 못 한 것과 그 다음으로는 해외와 연결된 백본망이 부실하기 때문이죠.
링고 2011/12/08 03:59 #
한국에서 살고 있는 한은 유투브의 버벅거림에서 자유롭지는 못할 것 같습니다. 답변 감사합니다.
늘봄 2011/12/08 08:23 # 삭제 답글
갤스2는 프로그램을 많이 돌려도 빠릿빠릿 부드럽게 돌아가더라고요.미스테리합니다