안드로이드 개발자 모임 게시판
(글 수 7,949)
버퍼는 당연히 사용할 겁니다. 10년 전 휴대용 오락기에도 쓰이는 방식입니다. 지금 시대에 가상 프레임버퍼가 없는 GUI는 상상하기 어렵군요. 범용OS이기에 범용성에 중시하여 개별적인 하드웨어에 대한 최적화가 부족한 것도 아닌 것 같습니다. 안드로이드가 리눅스 커널과 얼마나 잘 맞물려 돌아가는지는 모르겠습니다만, 소프트웨어 윗단은 하드웨어를 신경쓰지 않게 되어 있고, 하드웨어는 HAL에서 관리합니다. 하드웨어 최적화는 HAL에게 맡기는 거니 범용성과 최적화가 공존할 수 있습니다. (PC에서 어떤 하드웨어를 사용하건 똑같이 잘 작동하는 것을 생각하십시오.)
문제는 하나의 프로세서가 여러 작업을 한다는 것에 있습니다. 윈도우 환경이든 리눅스든 많은 자원을 사용하는 작업을 실행하는 경우, 화면 갱신이 느려지거나 하는 일을 쉽게 경험하셨을 겁니다. 물론, 아무 작업도 하지 않는데, 화면 갱신이 느려지는 것을 PC에서는 생각하기 힘듭니다만, 모바일 플랫폼에서는 있을 수 있는 일입니다. 저도 해박한 지식이 없기에 자세하게 말씀드릴 수는 없습니다만, 이벤트 큐에 많은 작업이 쌓이거나 이벤트를 처리하는 루틴이 길 수 있습니다. 몇가지 내부 작업이 부하를 줄 수도 있구요. 만져보지 않아서 확실하진 않습니다만, 안드로이드의 멀티터치 동영상을 보면 이벤트의 처리 부분에 최적화가 필요할 것 같았습니다.(해외에서 드로이드 브라우저에 관련하여 탭을 드래그로 인식하는 문제가 있었습니다. 손가락을 튕기듯 탭하면 빠른 가속도의 드래그로 인식해 엄청나게 빠른 속도로 스크롤하는 문제였습니다. 이를 보면, 아직 터치 이벤트에 대한 처리가 매끄럽지 못함을 알 수 있습니다.) 안드로이드 강좌를 들을 때 강사님께선 리눅스 커널의 비선점성과 이벤트 처리에 대한 문제라고 말씀하셨는데 이 역시 설득력 있습니다. 리눅스 커널 위에 다시 안드로이드를 올리고 Java를 어플리케이션 개발 언어로 둔 것이 문제일 수도 있습니다. 아이폰이 백그라운드 작업에 제한을 둔 것이 속도저하 문제라는 의견도 있습니다.
WM나 안드로이드가 느린 것에 나름 문제가 있겠지만, 생각하고 계신 것처럼 단순한 문제(부족한 하드웨어의 활용)은 아니라고 봅니다. 100%는 아니지만 최대한 활용하고 있을 겁니다. 학부생 졸업과제도 아니고, 세계 공룡 기업들이 많은 예산을 투자한 작업이니까요. 리눅스가 윈도우보다 하드웨어를 잘 활용하지 못하는 부분이 있습니다만, 이는 하드웨어 업체의 드라이버 미제공 혹은 부실한 드라이버 제공으로 인한 것으로, 안드로이드 폰 같은 경우 이러한 문제는 없으리라 예상합니다.
확실한 건 문제점은 차근차근 고쳐질 거란 겁니다. 개발자들도 충분히 많고 문제점을 찾아낼 하드코어 유저들도 많습니다. 어플리케이션 밑단이 고쳐진다고, 어플리케이션이 동작하지 않을 정도로 허술하게 만들어지지는 않았을 것이기에 호환성에 대한 문제도 거의 없을 겁니다.
WM나 안드로이드가 느린 것에 나름 문제가 있겠지만, 생각하고 계신 것처럼 단순한 문제(부족한 하드웨어의 활용)은 아니라고 봅니다. 100%는 아니지만 최대한 활용하고 있을 겁니다. 학부생 졸업과제도 아니고, 세계 공룡 기업들이 많은 예산을 투자한 작업이니까요. 리눅스가 윈도우보다 하드웨어를 잘 활용하지 못하는 부분이 있습니다만, 이는 하드웨어 업체의 드라이버 미제공 혹은 부실한 드라이버 제공으로 인한 것으로, 안드로이드 폰 같은 경우 이러한 문제는 없으리라 예상합니다.
확실한 건 문제점은 차근차근 고쳐질 거란 겁니다. 개발자들도 충분히 많고 문제점을 찾아낼 하드코어 유저들도 많습니다. 어플리케이션 밑단이 고쳐진다고, 어플리케이션이 동작하지 않을 정도로 허술하게 만들어지지는 않았을 것이기에 호환성에 대한 문제도 거의 없을 겁니다.
2010.01.26 02:39:54
토론을 이어가서.
예전에 찐돌님도 언급한적있는 메모리 버스 I/O 속도가 결국 가장 큰 영향을 끼치는 것인데. 디스플레이에서 레이어되어있는 버퍼들을 합쳐서 내보내고 더블 버퍼링하는 등의 구조는 안드로이드에서도 그대로 사용됩니다. 윈도우, GL, 비디오 등에서 각각 성능을 위해 다른 버퍼링 방식을 사용하기도 하구요. 그런 디스플레이 처리 과정은 어느 정도 표준화가 되어있는 부분 다른 플랫폼에서 비슷하기 때문에 특별히 안드로이드가 비능률적인 것은 아닐거라 이야기한거구요. 하드웨어 가속은 충분히 사용하고 있습니다. 그리고 비선점이나 이벤트 처리과정 자바가 올라간것에서의 속도저하는 그리 심각하다고 생각하지 않습니다.
앱 자체에서만 보면 직접 속도에 영향을 끼치는 것으로 느껴지는 부분은 가비지 컬렉션 부분이구요. 한 앱내에서 갑자기 버벅이다 잘돌아가는 현상 많이 목격하셨을텐데 대부분 GC때문입니다. 말씀하신 백그라운드 프로세스가 동작할때도 느껴집니다.(그래서 태스크 킬러 앱이 인기있는것이죠) 즉 메모리가 부족하고, 프로세스가 여러개가 떠있어 로딩이나 언로딩이 자주 일어나고 포커스된 앱이 메모리를 비효율적으로 사용해 가비지 컬렉션이 많이 일어나는 상황이 최악이라는 거죠. 일단 GC 자체는 개선의 여지가 있고 구글도 문제를 알고 진행할 것이라고 언급도 한 부분입니다. 백그라운드 프로세스는 시스템이 얼마나 효율적으로 언제 어떻게 프로세스를 올리고 내리느냐의 부분인데 이것도 쉽지 않겠죠. 그렇다고 아이폰처럼 태스크 제약을 걸어버릴수도 없구요.
마지막으로 브라우저 속도의 경우 일단 처리 방식이 약간 틀리구요. 안드로이드의 줌은 대부분 디스크리트하게 구성되어 있습니다. 애초에 핀치등으로 손의 움직임 정도에 따라 매끄럽게 주밍되는 것이 고려된 모델이 아니었다는거죠. (구글맵도 마찬가지) 거기다 Auto Fit 등이 적용되어 있으면 상대적으로 느리게 보일수 있습니다. 줌 변경시마다 레이아웃을 새로 맞추니까요. 일단 전부 로딩된 다음에는 드로이드가 아이폰 3GS에 스크롤 등에서는 별로 많이 뒤져 보이진 않습니다. 다만 처음 로딩 속도차이는 확실히 나는데 자바스크립트 부분이 가장 차이가 많이 납니다. 자바스크립트 들어간 페이지랑 아닌 페이지 속도비교하면 차이나는 것 확인할 수 있습니다.
안드로이드는 일단 GC랑 자바스크립트 엔진 부분만 개선해도 체감 속도는 많이 좋아질것 같네요. 머 옵티마이제이션이란게 시작하고 보면 밑도 끝도 없는 것일수도 있지만 말이죠 =_=
2010.01.26 06:40:09
제가 쓸데없는 쓰레드를 시작한것 같습니다만.. 여러 고수님들로부터 많이 배울수 있는 기회는 되네요.. ^^
맞습니다.. 가상 프레임 버퍼를 사용하지 않는다는건 좀 말이 안되죠.. 기본 중의 기본이니.. 하지만, 하드웨어를 100% 사용한다는건 말처럼 쉬운 문제는 아닙니다.. 일단 어플리케이션은 여러분들이 말씀하신 대로 하드웨어에서 분리되어 있습니다.. 준비된 API를 이용해서 원하는 기능을 수행하게 되죠..
이 HAL이란게 좀 tricky한 부분인데요.. 어플리케이션에게 제공하는 API는 될수 있으면 특정 하드웨어에 종속되지 않고, 일반적인 역할을 수행하도록 설계될 겁니다.. 하드웨어와 연결되는 부분은, 하드웨어에서 제공하는 기능이 있으면 특정 하드웨어를 사용하도록 설계가 될 것이고, 하드웨어가 지원되지 않으면 HAL에서 구현을 할 것입니다.. 물론 대부분의 Mobile Processor는 제가 알기에 WM에서 필요로 하는 함수는 다 구현되어 있는걸로 압니다..
이 HAL을 구현할 1차적인 책임은 현재 폰 제작 업체가 가지고 있습니다.. 물론 Mobile 칩셋 제작 업체가 특정 OS에 맞게 포팅하는 작업을 주로 수행하긴 하겠죠.. 이 칩셋 제작 업체는, OS에 필요로 하는 API를 구현하는걸 최우선으로 삼습니다.. 이 과정에서 칩셋이 제공하는 특정 기능 자체가 구현될 가능성은 줄어듭니다.. 그래픽을 예로 든다면, 그 그래픽을 담당하는 엔진 자체를 통째로 새로 코딩한다면 최대한 옵티마이즈 하는게 가능할 터이지만, 칩셋 업체에서 그렇게 까지 하긴 힘들죠.. 결국 하드웨어는 API가 제공하는 최대한도에서 100%사용된다고 말하는게 맞을 것 같습니다..
특정 기능을 사용할수 밖에 없는 멀티미디어 코덱의 경우 더 복잡해 지는데, 코덱의 하드웨어 부분과 소프트웨어 부분이 분리가 될수 없으므로, 아예 OS에서 코덱 전체로 call을 할수 밖에 없습니다.. 비디오를 예로 든다면 파일 이름이나 위치를 넘겨주고, play를 call하는 것일테죠.. 이 경우, 코덱은 OS의 메모리 관리나 스케쥴러와 공존하면서 최대한의 우선순위를 점하면서 동작을 하겠죠.. 제가 아는 어떤 회사의 비디오 코덱은 매크로 블럭 처리할때마다 H/W가 인터럽트를 날립니다.. 정식으로 하자면 HAL내의 인터럽트 핸들러를 거치는게 맞을테지만, 효율 문제상, 코덱이 직접 인터럽트를 핸들 하는게 효율적입니다.. 결국 코덱은 Application API로 call을 하지만 HAL까지 아우르는.. 경계가 불분명한 존재가 되어 버리죠..
다른 방식으로 구현을 하자면, 구글에서 제공하는 Default Codec을 사용해서 CPU에서 다 처리를 해 버리면.. 문제가 단순합니다.. HAL에서 제공되는 그래픽 관련 API몇개를 사용해서 (그래도 어느 정도 가속은 될테니).. 구현을 하면, 폰 제작업체나 칩셋 제작업체의 포팅이 단순하죠.. 제가 의심하는건, 안드로이드 업체들이 이런 방식으로 구현을 하지 않았나 하는 것입니다..
Audio Playback도 마찬가지입니다.. 하드웨어를 제대로 사용하려면, 별도로 존재하는 DSP를 사용하는게 효율적입니다.. 근데 DSP를 사용하려면, 별도의 프로세서를 사용하는 것이니, 통째로 오디오 파일을 넘겨주는게 제일 효율적입니다.. 그리고 DSP에서 여러작업을 동시에 수행할수 있으니, 안드로이드 OS도 올라가야 할테구요.. 그러면 멀티 프로세서에 대한 설계도 고려가 되어야 할텐데, 멀티 프로세서가 구현되는 방식도 회사마다 차이가 있으니 제일 쉽게 구현하는 방식으론, 안 쓰면 됩니다.. ^^ 그래도 별로 표 안나거든요..
물론 말씀하신 이벤트 핸들링 문제도 크게 작용할거라 생각합니다.. OS API의 Response time에 대한 튜닝도 많이 해야 할테고.. iPod Touch도 그냥 사용하면 응답성이 좋지, Push mail만 켜도 배터리 소모가 극심해지고, 많이 느려집니다.. GC도 없어서 거의 리소스 관리를 안하는 OS인데도 불구하고 말이죠.. 그런데 음악 재생은 부드럽게 잘 되는걸로 보아, 별개 DSP같은 하드웨어 리소스를 잘 사용하고 있는거라 생각합니다.. 애플이야 범용 OS를 만드는게 아니거든요..
맞습니다.. 가상 프레임 버퍼를 사용하지 않는다는건 좀 말이 안되죠.. 기본 중의 기본이니.. 하지만, 하드웨어를 100% 사용한다는건 말처럼 쉬운 문제는 아닙니다.. 일단 어플리케이션은 여러분들이 말씀하신 대로 하드웨어에서 분리되어 있습니다.. 준비된 API를 이용해서 원하는 기능을 수행하게 되죠..
이 HAL이란게 좀 tricky한 부분인데요.. 어플리케이션에게 제공하는 API는 될수 있으면 특정 하드웨어에 종속되지 않고, 일반적인 역할을 수행하도록 설계될 겁니다.. 하드웨어와 연결되는 부분은, 하드웨어에서 제공하는 기능이 있으면 특정 하드웨어를 사용하도록 설계가 될 것이고, 하드웨어가 지원되지 않으면 HAL에서 구현을 할 것입니다.. 물론 대부분의 Mobile Processor는 제가 알기에 WM에서 필요로 하는 함수는 다 구현되어 있는걸로 압니다..
이 HAL을 구현할 1차적인 책임은 현재 폰 제작 업체가 가지고 있습니다.. 물론 Mobile 칩셋 제작 업체가 특정 OS에 맞게 포팅하는 작업을 주로 수행하긴 하겠죠.. 이 칩셋 제작 업체는, OS에 필요로 하는 API를 구현하는걸 최우선으로 삼습니다.. 이 과정에서 칩셋이 제공하는 특정 기능 자체가 구현될 가능성은 줄어듭니다.. 그래픽을 예로 든다면, 그 그래픽을 담당하는 엔진 자체를 통째로 새로 코딩한다면 최대한 옵티마이즈 하는게 가능할 터이지만, 칩셋 업체에서 그렇게 까지 하긴 힘들죠.. 결국 하드웨어는 API가 제공하는 최대한도에서 100%사용된다고 말하는게 맞을 것 같습니다..
특정 기능을 사용할수 밖에 없는 멀티미디어 코덱의 경우 더 복잡해 지는데, 코덱의 하드웨어 부분과 소프트웨어 부분이 분리가 될수 없으므로, 아예 OS에서 코덱 전체로 call을 할수 밖에 없습니다.. 비디오를 예로 든다면 파일 이름이나 위치를 넘겨주고, play를 call하는 것일테죠.. 이 경우, 코덱은 OS의 메모리 관리나 스케쥴러와 공존하면서 최대한의 우선순위를 점하면서 동작을 하겠죠.. 제가 아는 어떤 회사의 비디오 코덱은 매크로 블럭 처리할때마다 H/W가 인터럽트를 날립니다.. 정식으로 하자면 HAL내의 인터럽트 핸들러를 거치는게 맞을테지만, 효율 문제상, 코덱이 직접 인터럽트를 핸들 하는게 효율적입니다.. 결국 코덱은 Application API로 call을 하지만 HAL까지 아우르는.. 경계가 불분명한 존재가 되어 버리죠..
다른 방식으로 구현을 하자면, 구글에서 제공하는 Default Codec을 사용해서 CPU에서 다 처리를 해 버리면.. 문제가 단순합니다.. HAL에서 제공되는 그래픽 관련 API몇개를 사용해서 (그래도 어느 정도 가속은 될테니).. 구현을 하면, 폰 제작업체나 칩셋 제작업체의 포팅이 단순하죠.. 제가 의심하는건, 안드로이드 업체들이 이런 방식으로 구현을 하지 않았나 하는 것입니다..
Audio Playback도 마찬가지입니다.. 하드웨어를 제대로 사용하려면, 별도로 존재하는 DSP를 사용하는게 효율적입니다.. 근데 DSP를 사용하려면, 별도의 프로세서를 사용하는 것이니, 통째로 오디오 파일을 넘겨주는게 제일 효율적입니다.. 그리고 DSP에서 여러작업을 동시에 수행할수 있으니, 안드로이드 OS도 올라가야 할테구요.. 그러면 멀티 프로세서에 대한 설계도 고려가 되어야 할텐데, 멀티 프로세서가 구현되는 방식도 회사마다 차이가 있으니 제일 쉽게 구현하는 방식으론, 안 쓰면 됩니다.. ^^ 그래도 별로 표 안나거든요..
물론 말씀하신 이벤트 핸들링 문제도 크게 작용할거라 생각합니다.. OS API의 Response time에 대한 튜닝도 많이 해야 할테고.. iPod Touch도 그냥 사용하면 응답성이 좋지, Push mail만 켜도 배터리 소모가 극심해지고, 많이 느려집니다.. GC도 없어서 거의 리소스 관리를 안하는 OS인데도 불구하고 말이죠.. 그런데 음악 재생은 부드럽게 잘 되는걸로 보아, 별개 DSP같은 하드웨어 리소스를 잘 사용하고 있는거라 생각합니다.. 애플이야 범용 OS를 만드는게 아니거든요..
2010.01.26 09:17:06
토론중에 죄송한데 궁금한게 있습니다..;
현재 안드로이드 탑재된 단말기의 프로세서중에
hardware floating 연산을 처리하는것들이 얼마나 되나요?
프로세서가 지원하지 않는다면 개발시 이부분도 고려해야 하지 않나 싶네요..특히 게임개발 하시는분들...^^;
현재 안드로이드 탑재된 단말기의 프로세서중에
hardware floating 연산을 처리하는것들이 얼마나 되나요?
프로세서가 지원하지 않는다면 개발시 이부분도 고려해야 하지 않나 싶네요..특히 게임개발 하시는분들...^^;
2010.01.26 09:58:28
//FPU는 Droid와 넥서스원 밖에 없지 않나요?
//대부분 소프트웨어에서 처리 하고 있는걸로 알고 있습니다.
이번 토론을 보고 있으면서 느끼는건.
성능 이슈라기 보다는 Android 와 IPhone의 장단점에 관한 이슈인것 같습니다.
Android는 모바일에서 멀티태스킹을 비롯한 기술적 자유도를 "완벽" 지원하기 위해 어느정도의 성능쪽 Trade-off 를 감수한것 같고,
IPhone은 모바일에서의 쾌적함과 무결성을 "완벽" 지원하기 위해 기술적 Trade-off를 감수한 것 같습니다.
Android는 IPhone의 후발주자 인것은 당연한 사실이니,
분명 자신만의 Identity가 필요했을 것인데.
그것이 멀티태스킹이라고 판단했을지도 모르겠네요.
아직은 이것이 자충수가 되어 머리를 아프게 하지만.
개선이 되어 안정적으로 자리 잡을 것이라고 생각합니다.
아이폰은 완성도와 편리함에서 높은 점수를
안드로이는 잠재성과 확장성에서 높은 점수를 주고 싶습니다.
^^
2010.01.26 10:58:58
번외(?)의 얘기입니다만, 애플의 경우 이런 얘기가 있더군요.
"퍼포먼스를 저해하는 것은 아무리 좋은 기능이라도 배제한다."
또, 주관적인 얘기일수도 있습니다만, 실제로 동작 시간등을 다른 제품과 비교해보면, 딱히 아이폰이 두드러지거나 하지 않았습니다. 다만, 시각적으로, 사용자가 느끼기에, 감성적인 면에서 무척이나 부드럽고 빠르다, 내지는 지연이 없다-라고 느끼게끔 UX 측면에서 고려를 많이한 흔적이 보였습니다.
"퍼포먼스를 저해하는 것은 아무리 좋은 기능이라도 배제한다."
또, 주관적인 얘기일수도 있습니다만, 실제로 동작 시간등을 다른 제품과 비교해보면, 딱히 아이폰이 두드러지거나 하지 않았습니다. 다만, 시각적으로, 사용자가 느끼기에, 감성적인 면에서 무척이나 부드럽고 빠르다, 내지는 지연이 없다-라고 느끼게끔 UX 측면에서 고려를 많이한 흔적이 보였습니다.
WM, 아이폰, 안드로이드의 성능을 비교하면서, 스크롤이 얼마나 자연스럽느니, 그런말을 많이 듣는데.. 실제 하드웨어를 만들어 본 사람으로서 스크롤이 자연스럽지 않으면 더 이상한겁니다.. 그건 하드웨어를 잘 사용하고 있지 못하다는 말이거든요..
PC도 그렇지만, 모바일쪽 2D 그래픽도 당연히 가상 화면을 지원합니다.. 실제 해상도가 854x480이더라도, 프레임 버퍼의 해상도는 854x480을 옆으로 4개쯤 펼쳐둔 1920이 될수도 있습니다.. 브라우저를 예로 든다면, 긴 페이지에 대비해서 1600x480정도의 가상 화면 해상도를 가지고 있을수 있죠.. 이 경우, 모든 화면을 다 미리 만들어두고, 손가락으로 스크롤할때 Display Buffer가 시작되는 어드레스만 변경해 줄수 있습니다.. 그냥 레지스터 셋팅만 변경하는 거라, CPU MIPS가 필요하고 말것도 없죠. 얼마나 부드럽게 움직이느냐는 손가락 입력의 주기가 얼마나 정확한지로 결정이 되죠.. 근데, 안드로이드 폰들은 이게 멈칫 멈칫 한단 말입니다.. 꼭 브라우저를 새로 redrawing 하는 것처럼 말입니다.. 안드로이드에선 어떤 H/W(칩)가 사용될지 모르니까, 프레임 버퍼랑 실제 화면 해상도가 일치하는 걸로 가정하는게 아닌지.. 아니면 실제 API에선 가상 화면을 지원해도, 실제 구현에선 스크롤이 있을때마다, 화면을 카피하는 식으로 구현을 한건지..
애플이 아예 삼성에게 별도의 그래픽 프로세서를 만들어 달라고 요구할수도 있을만큼 슈퍼 갑이니, 가속 기능 몇개 추가하는건 일도 아니겠죠..