Dianne Hackborn - 오후 4:21에 수정 - 공개
I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:
• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.
• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.
• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploa
• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.
• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)
• Hardware accelerated drawing is not all full of win. For example on the PVR(주: PowerVR사) drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.
• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)
• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.
• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
저도 점점 안드로이드 멀티태스킹에 대하여 이게 맞는건지 싶을때가 많아집니다.
iOS4에 멀티태스킹이 처음 나왔을 때, 진정한 멀티태스킹도 아닌것이 하며 많이 까였지만
거의 대다수의 App들이 멀티태스킹에 대응하고 나니
모바일에게 맞는것은 iOS 스타일의 제한적 또는 재워 대기시키는 방식의 멀티태스킹이야 말로 최적화 된 시스템 같습니다.
심지어 Windows8 개발자 프리뷰 버젼을 몇일 써보니 윈도우에도 iOS의 멀티태스킹 방식을 도입하였더군요.
모바일로 가기 위한 MS의 대응단계 겠지요.
구글이 안드로이드에서도 대책을 준비해 가이드를 제시해 주기 바랍니다. ㅠㅠ
언제까지 하드웨어 발전 성능만 믿고 써야 한다는 말입니까?
이미 글에 적힌대로 안드로이드도 sgx540부터는 그래픽가속에 대해서는 하드웨어적인 면은 걱정할 필요가 없고 중점적으로 개선되어야 할 부분은 백그라운드 서비스에 대한 제한이나 우선권 등의 명확한 개선이 필요하다고 봅니다. 깔아만놓고 쓰고있지도 않은 앱 때문에 전화가 안오는 불상사가 그 하드웨어 좋다는 갤투에서도 심심치않게 보이거든요.
저는 멀티태스킹은 지금 상태도 별 불만이 없는뎅...
설치하는 순간 자동실행 목록에 들어가는 앱들을 관리할 방법좀 만들어 주면 좋겠어요! 이런건 사용자에게 선택권도 없고...부팅하는 순간부터 항상 실행중이니 끄지도 못하고 완전히 끌려면 삭제하는 방법 뿐이니;; 이것만 해결해도 상당히 좋을것 같아요!
아이스크림에선 나아졌으려나..
주제 넘게 리소스를 과도히 소비하는 놈들은 삭제할 따름입니다 하드웨어가 날로 발전하는 상황에서 멀티태스킹을 과도히 제한할 필요는 없을 듯. 배터리 소비의 주범은 뭐니뭐니 해도 디스플레이라서....이 부분의 개선이 더욱 시급한 듯합니다. 디스플레이가 80% 전후로 잡아먹으니...
막는 걸 싫어서 뚫어 놓기를 원하는것, 바로 그것이 안드로이드 아닌가요.
베터리가 조루가 되든 말든..
리소스를 잔뜩 잡아 먹어 성능을 최대로 올리든,
개발자의 선택에 달려있고, 앱을 설치하는 사용자에게 달려 있는 것이니까.
안드로이드폰에서 어플종료할때 많은분들이 아이폰쓰는것처럼 홈버튼을 눌러서 종료하시더군요;
안드로이드에서 홈버튼누르면 어플이 꺼지는게 아니라 멀티태스킹 상태로 메모리에 남습니다
그러니 백그라운드에 남아서 배터리를 소모하게 됩니다
메모리부족,발열 예방과 배터리를 위해 귀찮더라도 뒤로가기로 어플을 종료시키는게 좋습니다
가끔 직장동료가 제폰을 빌려가서 어플을 쓸때가 있는데
그분역시 홈버튼눌러서 어플을 종료(?) 하시더군요
제가 한참 여러가지 어플을 쓰고 나면 별로 발열이 없는데
그분이 쓰고 나면 발열도 심하고 배터리도 많이줄어들어있습니다;;
그렇다고 그분이 와이파이나 인터넷을 사용하거나 배터리소모 심한어플을 사용하는것도 아닙니다
홈버튼으로 어플을 종료하다보니 그분이 쓰고나서 프로그램 관리자로 보면 메모리에 어플이 5개정도 떠있더라구요;;
제 결론은 메모리부족,발열 예방과 배터리를 위해 귀찮더라도 뒤로가기로 어플을 종료 시킵시다
입니다
글을 읽어보면 안드로이드 화면의 렌더링에 대해서
- 전면적인 소프트랜더링을 한다는 것은 완전한 오해고 1.0부터 언제나 하드웨어 가속을 (적어도 부분적으로) 이용해왔다.
- 더구나 리소스 관리 측면을 감안할 때 언제나 하드웨어 가속이 좋은 것은 아니다.
- 태블릿 운영체제였던 3.0에서는 전면적인 OpenGL 이용이 옵션이었지만 4.0부터는 다시 소프트웨어 랜더링을 이용하는 옵션을 열어주고 있다.
등의 내용을 다루고 있고, 전체적으로 보자면 소프트웨어 렌더링에 대한 (그리고 부분적으로 이를 이용해온 안드로이드에 대한) 변론임을 알 수 있습니다.
제목만 보고 흥분해서 내용은 읽어보지도 않은 상태에서 덮어놓고 안드로이드를 까는 댓글이 최초의 댓글이었다는 점이 매우 아쉬운, 본문 자체는 도움이 되는 좋은 정보였습니다.
다른 분께서 번역하신 게 있군요. 링크 겁니다.
http://dalinaum-kr.tumblr.com/post/13724432784/how-about-some-android-graphics-true-facts
글 쓴이 .. 구글 개발자 그룹서 그 까칠한 답변하는 아줌마 아닌가요? Romain Guy 와는 상당히 대조적인 .. ㅎㅎ
ui 쪽은 안드로이드 개발 넘어와서 처음 접한지라 .. api 설명만으론 장님 코끼리 더듬는 기분이었는데, 많은 도움 되었습니다
아줌마 구글 플러스에 땡큐 한 번 해줘야겠네요
개발의 개방성에 관해선, 올바른 개발 가이드라인을 공유하고, 물론 현실적으로 힘든 부분이 많지만 개발자들 스스로 최대한 노력 ^^ 하는 문화가 바른 방향 아닐까요.
인류가 우려 속에서도 희망적인 진보를 이뤄낸 것과 같은 방식으로 ..
잘 읽었습니다.
또다른 안드로이드 OS의 근본적인 문제점으로 선점형 멀티테스킹이 있습니다.
IOS의 멀티테스킹은 선점형이 아니며 엄격한 제한으로 최소한의 경우에만 허용되하는 반면
안드로이드는 사실상 APP에 달려있습니다.
때문에IOS는 엄격한 통제로 통상의 App들이 매우 가볍게 처리되는 반면
안드로이드는 테스크스위칭에 따른 엄청난 로스와 성능저하가 불가피한건 당연합니다.
물론 성능이야 멀티코어와 대용량 RAM장착으로 극복한다지만
부수적으로 수반되는 대기시 또는 운용시 막대한 배터리소비는 대안이 없는듯 합니다.
실제로 대기시의 소비전류가 IOS의 두배가 훨씬 넘어가는 현상이 필연적으로 발생하며.
안드로이드의 선점형 멀티태스킹은 반드시 없어져야할 필요악 입니다.