http://www.androidpub.com/81837 의 댓글엣 시작된 토론 개발자들이 관심있어할 이슈라서 가져옵니다. 


찐돌
제가 실제 개발을 해 보지 않아서 그런 API가 존재하는지 몰라서, 뭐라 하긴 그렇지만.. 현재의 옵티마이즈 수준도 좀 의심스럽습니다..

WM, 아이폰, 안드로이드의 성능을 비교하면서, 스크롤이 얼마나 자연스럽느니, 그런말을 많이 듣는데.. 실제 하드웨어를 만들어 본 사람으로서 스크롤이 자연스럽지 않으면 더 이상한겁니다.. 그건 하드웨어를 잘 사용하고 있지 못하다는 말이거든요.. 

PC도 그렇지만, 모바일쪽 2D 그래픽도 당연히 가상 화면을 지원합니다.. 실제 해상도가 854x480이더라도, 프레임 버퍼의 해상도는 854x480을 옆으로 4개쯤 펼쳐둔 1920이 될수도 있습니다.. 브라우저를 예로 든다면, 긴 페이지에 대비해서 1600x480정도의 가상 화면 해상도를 가지고 있을수 있죠.. 이 경우, 모든 화면을 다 미리 만들어두고, 손가락으로 스크롤할때 Display Buffer가 시작되는 어드레스만 변경해 줄수 있습니다.. 그냥 레지스터 셋팅만 변경하는 거라, CPU MIPS가 필요하고 말것도 없죠. 얼마나 부드럽게 움직이느냐는 손가락 입력의 주기가 얼마나 정확한지로 결정이 되죠.. 근데, 안드로이드 폰들은 이게 멈칫 멈칫 한단 말입니다.. 꼭 브라우저를 새로 redrawing 하는 것처럼 말입니다.. 안드로이드에선 어떤 H/W(칩)가 사용될지 모르니까, 프레임 버퍼랑 실제 화면 해상도가 일치하는 걸로 가정하는게 아닌지.. 아니면 실제 API에선 가상 화면을 지원해도, 실제 구현에선 스크롤이 있을때마다, 화면을 카피하는 식으로 구현을 한건지.. 

애플이 아예 삼성에게 별도의 그래픽 프로세서를 만들어 달라고 요구할수도 있을만큼 슈퍼 갑이니, 가속 기능 몇개 추가하는건 일도 아니겠죠.. 

회색
범용적인 플랫폼이라 소프트웨어에서 디스플레이버퍼를 직접 잡고 레지스터 변경해가며 사용하지는 않습니다. 그렇다고해도 단순 디스플레이나 스크롤하는 부분이 성능에 문제가 될 정도는 아니구요. 밑에서부터 위끝까지 살펴가며 옵티마이제이션을 해야하는데 아직 안드로이드가 최적화 보다 기능 향상 밑 안정화에 더 중점을 두고 있는것 같습니다.

찐돌
아마 그럴거라 생각합니다.. 스크롤할때도, 하나 하나 on the fly 로 그려나갈지도 모르죠.. ^^ 성능이야 근사하게 맞출수 있을진 모르지만.. 전력소모는.. 한쪽이 극심하게 많이 먹을 겁니다.. 아시겠지만.. 1GHz snapdragon이라고 해도, 메모리 액세스가 많아지면 많아질수록 133MHz짜리 프로세서에 근접합니다.. 내부만 1GHz이지 버스 속도는 그렇게 높지 않거든요.. 그래서 하드웨어엔 단순 DMA가 아니라, 좀더 복잡한 동작을 수행할수 있도록 DMA engine이 존재하는데, 회사마다 사용방법이 다르니.. 당연히 안드로이드는 안 건드릴거라 생각합니다.. 

OMAP도 600MHz짜리 Cortax 말고도 DSP도 있고, 비디오 가속기도 있습니다.. DSP로는 음악 감상 같은거 돌릴수 있죠.. 그러면, 화면이 잠겼을때 Cortax CPU는 전력을 차단하고 DSP로만 동작시키면 되니까 전력 소모도 줄일수 있습니다.. 근데 어느 회사도 그렇게 하는것 같진 않더군요.. 안드로이드 OS가 그런걸 허용하도록 설계가 안되었을수도 있구요.. AAC던 Mp3던.. 요즘이야 알고리즘이 공개가 많이 되어있으니 구현하는게 어려운건 아니지만.. 최적화야.. 힘든 문제죠.. 

아마, 최적화 지금 안하면 영원히 못할겁니다.. 애플 OS는 계속 새로운 기능 추가하면서 달아날테고.. 그거 쫗아가면서.. 또한 제조업체 지원해 가면서.. 구글은 새로운 기능 구현하기도 바쁠겁니다.. 그리고 최적화 되면서 기존의 아키텍쳐가 잘못되었다고 판단이라도 한다면.. 바꾸긴 너무 늦었죠.. 

앞의 화면 스크롤 얘기만 해도.. 일단 가상 버퍼를 사용해서 디스플레이 한다고 API를 설계했다면, 하드웨어가 가상 프레임 버퍼를 지원하건 안 하건 간에, OS가 스크롤을 구현해 주기만 하면 되는 것이니까, H/W가 지원하면 그걸 사용하고.. 안하면 OS가 해주면 되는데.. 아예 그런걸 고려하지도 않았다면, 나중에 가서 바꿀순 없죠.. 이미 깔린 어플이 수만개일텐데요.. 

버퍼는 당연히 사용할 겁니다. 10년 전 휴대용 오락기에도 쓰이는 방식입니다. 지금 시대에 가상 프레임버퍼가 없는 GUI는 상상하기 어렵군요. 범용OS이기에 범용성에 중시하여 개별적인 하드웨어에 대한 최적화가 부족한 것도 아닌 것 같습니다. 안드로이드가 리눅스 커널과 얼마나 잘 맞물려 돌아가는지는 모르겠습니다만, 소프트웨어 윗단은 하드웨어를 신경쓰지 않게 되어 있고, 하드웨어는 HAL에서 관리합니다. 하드웨어 최적화는 HAL에게 맡기는 거니 범용성과 최적화가 공존할 수 있습니다. (PC에서 어떤 하드웨어를 사용하건 똑같이 잘 작동하는 것을 생각하십시오.)
문제는 하나의 프로세서가 여러 작업을 한다는 것에 있습니다. 윈도우 환경이든 리눅스든 많은 자원을 사용하는 작업을 실행하는 경우, 화면 갱신이 느려지거나 하는 일을 쉽게 경험하셨을 겁니다. 물론, 아무 작업도 하지 않는데, 화면 갱신이 느려지는 것을 PC에서는 생각하기 힘듭니다만, 모바일 플랫폼에서는 있을 수 있는 일입니다. 저도 해박한 지식이 없기에 자세하게 말씀드릴 수는 없습니다만, 이벤트 큐에 많은 작업이 쌓이거나 이벤트를 처리하는 루틴이 길 수 있습니다. 몇가지 내부 작업이 부하를 줄 수도 있구요. 만져보지 않아서 확실하진 않습니다만, 안드로이드의 멀티터치 동영상을 보면 이벤트의 처리 부분에 최적화가 필요할 것 같았습니다.(해외에서 드로이드 브라우저에 관련하여 탭을 드래그로 인식하는 문제가 있었습니다. 손가락을 튕기듯 탭하면 빠른 가속도의 드래그로 인식해 엄청나게 빠른 속도로 스크롤하는 문제였습니다. 이를 보면, 아직 터치 이벤트에 대한 처리가 매끄럽지 못함을 알 수 있습니다.) 안드로이드 강좌를 들을 때 강사님께선 리눅스 커널의 비선점성과 이벤트 처리에 대한 문제라고 말씀하셨는데 이 역시 설득력 있습니다. 리눅스 커널 위에 다시 안드로이드를 올리고 Java를 어플리케이션 개발 언어로 둔 것이 문제일 수도 있습니다. 아이폰이 백그라운드 작업에 제한을 둔 것이 속도저하 문제라는 의견도 있습니다.
WM나 안드로이드가 느린 것에 나름 문제가 있겠지만, 생각하고 계신 것처럼 단순한 문제(부족한 하드웨어의 활용)은 아니라고 봅니다. 100%는 아니지만 최대한 활용하고 있을 겁니다. 학부생 졸업과제도 아니고, 세계 공룡 기업들이 많은 예산을 투자한 작업이니까요. 리눅스가 윈도우보다 하드웨어를 잘 활용하지 못하는 부분이 있습니다만, 이는 하드웨어 업체의 드라이버 미제공 혹은 부실한 드라이버 제공으로 인한 것으로, 안드로이드 폰 같은 경우 이러한 문제는 없으리라 예상합니다. 
확실한 건 문제점은 차근차근 고쳐질 거란 겁니다. 개발자들도 충분히 많고 문제점을 찾아낼 하드코어 유저들도 많습니다. 어플리케이션 밑단이 고쳐진다고, 어플리케이션이 동작하지 않을 정도로 허술하게 만들어지지는 않았을 것이기에 호환성에 대한 문제도 거의 없을 겁니다.

쟝그리안
저도 찐돌님 생각에 동의합니다. OS자체가 아직 하드웨어를 잘 활용하고 있다는 생각은 별루 안들어요.
하드웨어 스펙이 좋아도 안드로이드 스크롤은 그닥 부드럽단 느낌이 잘 들진 않거든요.
하드웨어에 무리가 가고 있는 상황이 아닌데도 소프트웨어가 부드럽게 동작하지 않는 경우도 있구요.

구글도 바보가 아닌 이상 버퍼를 이용하는게 속도면에서 이득임을 모를 리가 없구요.
제 생각엔 플로팅 연산에 문제가 있지 않나 싶습니다. 

쟝그리안
이거 말이 이상하네요; 그니까 플로팅 연산에 문제가 있단게; OS자체나 시스템 문제가 아니라
APP 설계상의 플로팅 연산이 문제가 있다는 말.. ( - -) (써 놓고 읽어보니 이상해서;)

스크롤만으로 하드웨어의 활용에 대해 언급하는 건 무리가 있는 것 같습니다. PC의 예를 들자면, 윈도우에 비해 리눅스나 맥이 GUI는 더 부드럽게 동작하지만, 게임과 같은 작업은 윈도우가 더 빠르거든요. (포토샵 작업 역시 윈도우가 맥보다 빠른 인상을 받았습니다만, 확실치는 않네요.) 물론 이는 윈도우에 최적화된(DX에 최적화된) 하드웨어나 소프트웨어의 영향일 수도 있고, 안드로이드가 최적화가 필요한 것은 맞습니다.