안드로이드 기기 정보/후기/팁
(글 수 459)
지난달부터 구글은 안드로이드의 버전별 분포를 공유하기 시작했습니다. 이 작업이 완료되서 개발자들은 버전벌 분포를 이해할 수 있게 되었고 , 어느 부분에 역량을 집중해야 할지를 결정할 수 있게 되었습니다.
구글에서는 안드로이드의 버전별 분포를 정기적으로 업데이트 할 것이라고 합니다.
보시다시피, 안드로이드 1.6이 줄어든 반면 1.5와 2.x가 증가했습니다. 안드로이드 2.x로 업데이트된 기계가 없기때문에 안드로이드 1.6이 줄어든 것은 조금 이상지만, 안드로이드 1.5와 2.0 폰의 판매증가 때문이던가 아니면 T-Mobile 사용자가 드로이드로 바꾸려고 버라이즌으로 이동했기 때문일 수도 있습니다.
위의 자료는 넥서스원을 포함하고 있지 않기 때문에, 넥서스원을 반영한 분포도는 다음달 리포트에서 볼수 있을것입니다.
안드로이드 버전벌 분포에서 흥미로운 점 :
- 78.9%가 구버전의 안드로이드(1.5, 1.6) 라는 점 (대부분 2010년 2사분기까지 업데이트 예정)
- 31%가 맵스 네비게이션, 신규 안드로이드 마켓, 구글등에 접속해본적이 없다는 것 (모두 안드로이드 1.6이상 필요)
- 21.1%가 멀티터치 지원 (안드로이드 2.x)
- 92.7%가 모든 윈도우 모바일 폰보다 좋다는것.
출처 : http://androidandme.com/2010/01/news/google-updates-android-fragmentation-numbers/
나태함, 그 순간은 달콤하나 그 결과는 비참하다
2010.01.25 06:38:02
1.5가 아직도 31%라..생각보다 1.5->1.6 업뎃이 부진하군요.. 어떤 제조사에서 이리 업뎃을 안해주는지 궁금하네요.
고객만족과 가격에 맞춰 버젼을 선택하는건 찬성이지만, 업글가능한기기를 포기하고 차별화를 두어 신제품을 출시하는건
소비자 입장에선 달갑지 않군요. 뻔히 보이는 전략이라..
2010.01.25 08:01:29
이게 점차 누적되면 안드로이드 앞길에 문제점으로 대두되겠군요.
풀어야할 큰 숙제이기도 하구요.
왠만하면 하드웨어 사양이 되는한 구글에서 강제성을 좀 줬으면 좋겠네요.
아니면 단말안에서 그냥 업데이트 메뉴가 뜨던지..
풀어야할 큰 숙제이기도 하구요.
왠만하면 하드웨어 사양이 되는한 구글에서 강제성을 좀 줬으면 좋겠네요.
아니면 단말안에서 그냥 업데이트 메뉴가 뜨던지..
2010.01.25 12:38:59
제가 실제 개발을 해 보지 않아서 그런 API가 존재하는지 몰라서, 뭐라 하긴 그렇지만.. 현재의 옵티마이즈 수준도 좀 의심스럽습니다..
WM, 아이폰, 안드로이드의 성능을 비교하면서, 스크롤이 얼마나 자연스럽느니, 그런말을 많이 듣는데.. 실제 하드웨어를 만들어 본 사람으로서 스크롤이 자연스럽지 않으면 더 이상한겁니다.. 그건 하드웨어를 잘 사용하고 있지 못하다는 말이거든요..
PC도 그렇지만, 모바일쪽 2D 그래픽도 당연히 가상 화면을 지원합니다.. 실제 해상도가 854x480이더라도, 프레임 버퍼의 해상도는 854x480을 옆으로 4개쯤 펼쳐둔 1920이 될수도 있습니다.. 브라우저를 예로 든다면, 긴 페이지에 대비해서 1600x480정도의 가상 화면 해상도를 가지고 있을수 있죠.. 이 경우, 모든 화면을 다 미리 만들어두고, 손가락으로 스크롤할때 Display Buffer가 시작되는 어드레스만 변경해 줄수 있습니다.. 그냥 레지스터 셋팅만 변경하는 거라, CPU MIPS가 필요하고 말것도 없죠. 얼마나 부드럽게 움직이느냐는 손가락 입력의 주기가 얼마나 정확한지로 결정이 되죠.. 근데, 안드로이드 폰들은 이게 멈칫 멈칫 한단 말입니다.. 꼭 브라우저를 새로 redrawing 하는 것처럼 말입니다.. 안드로이드에선 어떤 H/W(칩)가 사용될지 모르니까, 프레임 버퍼랑 실제 화면 해상도가 일치하는 걸로 가정하는게 아닌지.. 아니면 실제 API에선 가상 화면을 지원해도, 실제 구현에선 스크롤이 있을때마다, 화면을 카피하는 식으로 구현을 한건지..
애플이 아예 삼성에게 별도의 그래픽 프로세서를 만들어 달라고 요구할수도 있을만큼 슈퍼 갑이니, 가속 기능 몇개 추가하는건 일도 아니겠죠..
WM, 아이폰, 안드로이드의 성능을 비교하면서, 스크롤이 얼마나 자연스럽느니, 그런말을 많이 듣는데.. 실제 하드웨어를 만들어 본 사람으로서 스크롤이 자연스럽지 않으면 더 이상한겁니다.. 그건 하드웨어를 잘 사용하고 있지 못하다는 말이거든요..
PC도 그렇지만, 모바일쪽 2D 그래픽도 당연히 가상 화면을 지원합니다.. 실제 해상도가 854x480이더라도, 프레임 버퍼의 해상도는 854x480을 옆으로 4개쯤 펼쳐둔 1920이 될수도 있습니다.. 브라우저를 예로 든다면, 긴 페이지에 대비해서 1600x480정도의 가상 화면 해상도를 가지고 있을수 있죠.. 이 경우, 모든 화면을 다 미리 만들어두고, 손가락으로 스크롤할때 Display Buffer가 시작되는 어드레스만 변경해 줄수 있습니다.. 그냥 레지스터 셋팅만 변경하는 거라, CPU MIPS가 필요하고 말것도 없죠. 얼마나 부드럽게 움직이느냐는 손가락 입력의 주기가 얼마나 정확한지로 결정이 되죠.. 근데, 안드로이드 폰들은 이게 멈칫 멈칫 한단 말입니다.. 꼭 브라우저를 새로 redrawing 하는 것처럼 말입니다.. 안드로이드에선 어떤 H/W(칩)가 사용될지 모르니까, 프레임 버퍼랑 실제 화면 해상도가 일치하는 걸로 가정하는게 아닌지.. 아니면 실제 API에선 가상 화면을 지원해도, 실제 구현에선 스크롤이 있을때마다, 화면을 카피하는 식으로 구현을 한건지..
애플이 아예 삼성에게 별도의 그래픽 프로세서를 만들어 달라고 요구할수도 있을만큼 슈퍼 갑이니, 가속 기능 몇개 추가하는건 일도 아니겠죠..
2010.01.25 13:52:37
아마 그럴거라 생각합니다.. 스크롤할때도, 하나 하나 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가 해주면 되는데.. 아예 그런걸 고려하지도 않았다면, 나중에 가서 바꿀순 없죠.. 이미 깔린 어플이 수만개일텐데요..
OMAP도 600MHz짜리 Cortax 말고도 DSP도 있고, 비디오 가속기도 있습니다.. DSP로는 음악 감상 같은거 돌릴수 있죠.. 그러면, 화면이 잠겼을때 Cortax CPU는 전력을 차단하고 DSP로만 동작시키면 되니까 전력 소모도 줄일수 있습니다.. 근데 어느 회사도 그렇게 하는것 같진 않더군요.. 안드로이드 OS가 그런걸 허용하도록 설계가 안되었을수도 있구요.. AAC던 Mp3던.. 요즘이야 알고리즘이 공개가 많이 되어있으니 구현하는게 어려운건 아니지만.. 최적화야.. 힘든 문제죠..
아마, 최적화 지금 안하면 영원히 못할겁니다.. 애플 OS는 계속 새로운 기능 추가하면서 달아날테고.. 그거 쫗아가면서.. 또한 제조업체 지원해 가면서.. 구글은 새로운 기능 구현하기도 바쁠겁니다.. 그리고 최적화 되면서 기존의 아키텍쳐가 잘못되었다고 판단이라도 한다면.. 바꾸긴 너무 늦었죠..
앞의 화면 스크롤 얘기만 해도.. 일단 가상 버퍼를 사용해서 디스플레이 한다고 API를 설계했다면, 하드웨어가 가상 프레임 버퍼를 지원하건 안 하건 간에, OS가 스크롤을 구현해 주기만 하면 되는 것이니까, H/W가 지원하면 그걸 사용하고.. 안하면 OS가 해주면 되는데.. 아예 그런걸 고려하지도 않았다면, 나중에 가서 바꿀순 없죠.. 이미 깔린 어플이 수만개일텐데요..
2010.01.26 00:54:11
버퍼는 당연히 사용할 겁니다. 10년 전 휴대용 오락기에도 쓰이는 방식입니다. 지금 시대에 가상 프레임버퍼가 없는 GUI는 상상하기 어렵군요. 범용OS이기에 범용성에 중시하여 개별적인 하드웨어에 대한 최적화가 부족한 것도 아닌 것 같습니다. 안드로이드가 리눅스 커널과 얼마나 잘 맞물려 돌아가는지는 모르겠습니다만, 소프트웨어 윗단은 하드웨어를 신경쓰지 않게 되어 있고, 하드웨어는 HAL에서 관리합니다. 하드웨어 최적화는 HAL에게 맡기는 거니 범용성과 최적화가 공존할 수 있습니다. (PC에서 어떤 하드웨어를 사용하건 똑같이 잘 작동하는 것을 생각하십시오.)
문제는 하나의 프로세서가 여러 작업을 한다는 것에 있습니다. 윈도우 환경이든 리눅스든 많은 자원을 사용하는 작업을 실행하는 경우, 화면 갱신이 느려지거나 하는 일을 쉽게 경험하셨을 겁니다. 물론, 아무 작업도 하지 않는데, 화면 갱신이 느려지는 것을 PC에서는 생각하기 힘듭니다만, 모바일 플랫폼에서는 있을 수 있는 일입니다. 저도 해박한 지식이 없기에 자세하게 말씀드릴 수는 없습니다만, 이벤트 큐에 많은 작업이 쌓이거나 이벤트를 처리하는 루틴이 길 수 있습니다. 몇가지 내부 작업이 부하를 줄 수도 있구요. 만져보지 않아서 확실하진 않습니다만, 안드로이드의 멀티터치 동영상을 보면 이벤트의 처리 부분에 최적화가 필요할 것 같았습니다.(해외에서 드로이드 브라우저에 관련하여 탭을 드래그로 인식하는 문제가 있었습니다. 손가락을 튕기듯 탭하면 빠른 가속도의 드래그로 인식해 엄청나게 빠른 속도로 스크롤하는 문제였습니다. 이를 보면, 아직 터치 이벤트에 대한 처리가 매끄럽지 못함을 알 수 있습니다.) 안드로이드 강좌를 들을 때 강사님께선 리눅스 커널의 비선점성과 이벤트 처리에 대한 문제라고 말씀하셨는데 이 역시 설득력 있습니다. 리눅스 커널 위에 다시 안드로이드를 올리고 Java를 어플리케이션 개발 언어로 둔 것이 문제일 수도 있습니다. 아이폰이 백그라운드 작업에 제한을 둔 것이 속도저하 문제라는 의견도 있습니다.
WM나 안드로이드가 느린 것에 나름 문제가 있겠지만, 생각하고 계신 것처럼 단순한 문제(부족한 하드웨어의 활용)은 아니라고 봅니다. 100%는 아니지만 최대한 활용하고 있을 겁니다. 학부생 졸업과제도 아니고, 세계 공룡 기업들이 많은 예산을 투자한 작업이니까요. 리눅스가 윈도우보다 하드웨어를 잘 활용하지 못하는 부분이 있습니다만, 이는 하드웨어 업체의 드라이버 미제공 혹은 부실한 드라이버 제공으로 인한 것으로, 안드로이드 폰 같은 경우 이러한 문제는 없으리라 예상합니다.
확실한 건 문제점은 차근차근 고쳐질 거란 겁니다. 개발자들도 충분히 많고 문제점을 찾아낼 하드코어 유저들도 많습니다. 어플리케이션 밑단이 고쳐진다고, 어플리케이션이 동작하지 않을 정도로 허술하게 만들어지지는 않았을 것이기에 호환성에 대한 문제도 거의 없을 겁니다.
문제는 하나의 프로세서가 여러 작업을 한다는 것에 있습니다. 윈도우 환경이든 리눅스든 많은 자원을 사용하는 작업을 실행하는 경우, 화면 갱신이 느려지거나 하는 일을 쉽게 경험하셨을 겁니다. 물론, 아무 작업도 하지 않는데, 화면 갱신이 느려지는 것을 PC에서는 생각하기 힘듭니다만, 모바일 플랫폼에서는 있을 수 있는 일입니다. 저도 해박한 지식이 없기에 자세하게 말씀드릴 수는 없습니다만, 이벤트 큐에 많은 작업이 쌓이거나 이벤트를 처리하는 루틴이 길 수 있습니다. 몇가지 내부 작업이 부하를 줄 수도 있구요. 만져보지 않아서 확실하진 않습니다만, 안드로이드의 멀티터치 동영상을 보면 이벤트의 처리 부분에 최적화가 필요할 것 같았습니다.(해외에서 드로이드 브라우저에 관련하여 탭을 드래그로 인식하는 문제가 있었습니다. 손가락을 튕기듯 탭하면 빠른 가속도의 드래그로 인식해 엄청나게 빠른 속도로 스크롤하는 문제였습니다. 이를 보면, 아직 터치 이벤트에 대한 처리가 매끄럽지 못함을 알 수 있습니다.) 안드로이드 강좌를 들을 때 강사님께선 리눅스 커널의 비선점성과 이벤트 처리에 대한 문제라고 말씀하셨는데 이 역시 설득력 있습니다. 리눅스 커널 위에 다시 안드로이드를 올리고 Java를 어플리케이션 개발 언어로 둔 것이 문제일 수도 있습니다. 아이폰이 백그라운드 작업에 제한을 둔 것이 속도저하 문제라는 의견도 있습니다.
WM나 안드로이드가 느린 것에 나름 문제가 있겠지만, 생각하고 계신 것처럼 단순한 문제(부족한 하드웨어의 활용)은 아니라고 봅니다. 100%는 아니지만 최대한 활용하고 있을 겁니다. 학부생 졸업과제도 아니고, 세계 공룡 기업들이 많은 예산을 투자한 작업이니까요. 리눅스가 윈도우보다 하드웨어를 잘 활용하지 못하는 부분이 있습니다만, 이는 하드웨어 업체의 드라이버 미제공 혹은 부실한 드라이버 제공으로 인한 것으로, 안드로이드 폰 같은 경우 이러한 문제는 없으리라 예상합니다.
확실한 건 문제점은 차근차근 고쳐질 거란 겁니다. 개발자들도 충분히 많고 문제점을 찾아낼 하드코어 유저들도 많습니다. 어플리케이션 밑단이 고쳐진다고, 어플리케이션이 동작하지 않을 정도로 허술하게 만들어지지는 않았을 것이기에 호환성에 대한 문제도 거의 없을 겁니다.
2010.01.26 02:11:07
이 글이 어쩌다 퍼포먼스 이슈가 되어버렸는지 모르겠네요. 뉴스 게시판에서 진행할 토론의 범위를 넘어간것 같아 아래 게시물로 이동합니다. http://www.androidpub.com/83580