18
In fact it was just not feasible
to implement hardware
accelerated drawing inside windows until recently.
Because Android is designed
around having multiple windows on the screen,
to have
the drawing inside each window
be hardware accelerated
means
requiring that
the GPU and driver
support multiple active GL contexts
in different processes running at the same time.
The hardware at that time
just didn’t support this,
even ignoring the additional memory needed for it
that was not available.
Even today we are in the early stages of this
-- most mobile GPUs
still have fairly expensive GL context switching.
19
I hope this helps people
better understand how Android works.
And just to be clear again from my last point
-- I am not writing this to make excuses for
whatever things people don’t like about Android,
I just get tired of seeing people
write egregiously(터무니없게) wrong explanations
about how Android works
and worse present themselves
as authorities on the topic.
20
There are of course many things
that can be improved in Android today,
just as there are many things that have been improved since 1.0.
As other more pressing(긴급한) issues are addressed,
and hardware capabilities improve and change,
we continue to push the platform forward and make it better.
21
One final thought.
I saw an interesting comment from Brent Royal-Gordon
on what developers sometimes need to do
to achieve 60fps scrolling in iOS lists: “
Getting it up to sixty is more difficult
—you may have to
simplify the cell's view hierarchy,
or delay adding some of the content,
or remove text formatting
that would otherwise require a more expensive text rendering API,
or even rip the subviews out of the cell altogether
and draw everything by hand.”
22
I am no expert on iOS,
so I’ll take that as as true.
These are the exact same recommendations
that we have given to Android’s app developers,
and based on this statement
I don't see any indication
that there is something intrinsically(본질적으로) flawed(결함이 있는) about Android
in making lists scroll at 60fps, any more than there is in iOS.
18
사실, 최근까지만 해도 윈도우 안에서 하드웨어로 가속해서 그리는 것은 불가능했다. 안드로이드의 화면이 여러 개의 윈도우를 가지도록 설계되었기 때문에, 하드웨어로 가속해서 각각의 윈도우를 그린다는 것은, GPU와 드라이버가 동시에 서로 다른 프로세스에서 다수의 활성화된 GL 컨텍스트를 지원해야 함을 의미한다. 당시에는 하드웨어가 이러한 기능을 지원하지 않았고, 그걸 위해 필요한 추가적인 메모리가 없었다는 것을 무시하기까지 했다. 심지어 요즘에도 이러한 기술들은 초기 단계에 있다. -- 대부분의 모바일 GPU는 GL 컨텍스트 스위칭 비용이 꽤 비싸다.
19
나는 이 기사가 사람들이 안드로이드의 동작을 더 잘 이해하는데 도움이 되길 바란다. 그리고 나의 관점을 한번만 더 명확히 해 보자면, 내가 이걸 쓰는 이유가 사람들이 안드로이드를 싫어하는 것에 대해 변명하고자 하는게 아니라, 안드로이드의 동작에 대해 터무니없이 잘못된 설명을 하거나 심지어 그 주제와 관련해서 마치 그들이 대단한 권위자인양 하는걸 더 이상 보기 싫어서이다.
20
물론 아직까지도, 1.0부터 많은 것들이 개선되어온 것과 같이, 안드로이드는 개선해야 할 것을이 많다. 더 긴급한 이슈들이 강조되고 하드웨어의 처리 능력이 개선됨에 따라서, 우리는 안드로이드가 더 좋아지도록 끊임없이 노력할 것이다.
21
마지막 한마디. 나는 브렌트 로얄-고든의 흥미로운 코멘트를 봤는데, 그건 iOS 리스트에서 60 fps 스크롤링을 위해 개발자가 해야 할 몇 가지에 관한 것이었다: "60 fps까지 올리려면 꽤 어려워. 쎌의 뷰 구조를 더 간략화하거나, 컨텐츠 일부를 추가하는걸 지연시키거나, 더 비싼 텍스트 렌더링 API를 필요로하는 텍스트 포매팅을 없애거나, 심지어는 모든 셀로부터 서브뷰를 떼어 내고 모든걸 손으로 그리거나."
22
나는 iOS 전문가가 아니라서, 이걸 진실로 받아들이기로 했다. 이러한 것들은 우리가 안드로이드 앱 개발자들에게 제공한 권고사항들과 정확하게 일치한다. 그리고 이 문장을 기반으로 한다면, 리스트를 60 fps로 스크롤 하는데 있어서 안드로이드에는 뭔가 본질적으로 결함이 있다거나, iOS보다 뭔가 더 나쁘다거나 하는 등의 징후는 보지 못했다.
