CremeDeLaCreme
Enthusiast
Thread Starter
- Mitglied seit
- 02.07.2005
- Beiträge
- 2.060
Das geistert grade bei google+ herum, es stammt von einem Entwickler, der bei Google ein Praktikum gemacht hat.
ich dachte, immer, dass daran liegt, das das iPhone die GPU zur Darstellung mitnutzt, Android hingegen nicht; stimmt aber nicht, seit der ersten Version ist auch bei Android die GPU beteiligt. Hier zu lesen, darauf antwortet der Autor mit dem Beitrag unten: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
Das Wichtigste:
Quelle
ich dachte, immer, dass daran liegt, das das iPhone die GPU zur Darstellung mitnutzt, Android hingegen nicht; stimmt aber nicht, seit der ersten Version ist auch bei Android die GPU beteiligt. Hier zu lesen, darauf antwortet der Autor mit dem Beitrag unten: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
Das Wichtigste:
Quelle
It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.
This is a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari. Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around. All rendering instantly stops.
...
Android UI will never be completely smooth because of the design constraints I discussed at the beginning:
- UI rendering occurs on the main thread of an app
- UI rendering has normal priority
Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone. So why did the Android team design the rendering framework like this?
Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.
...
This is a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari. Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around. All rendering instantly stops.
...
Android UI will never be completely smooth because of the design constraints I discussed at the beginning:
- UI rendering occurs on the main thread of an app
- UI rendering has normal priority
Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone. So why did the Android team design the rendering framework like this?
Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.
...
Zuletzt bearbeitet:
