The Innovator's Dilemma guy also talks about integrated vs. modular architectures. By integrated, he means made in one elegant piece, meshing together <i>just so</i>; by modular he means you can mix-and-match (eg. from different suppliers, or to customize attributes easily), with clearly defined standard interfaces. Maybe it sounds like modular is <i>always</i> better; while it is more customizable and cheaper, integrated can always outperform it. Which one wins in a market depends on what that market most demands at that time, with respect to where the technology is at that moment. Is it fast enough? Does it have enough functions? Is it flexible enough? Is it cheap enough? Markets tend to move back and forth between them, as they evolve over a period of years.<p>For smartphones, performance is still an issue (and will be for 2-3 years I'd guess, by Moore's law), and so integrated platforms do the best job at this. This is Apple's forte - but they have limited time to make hay and get as firmly established as possible.<p>It's limited, because once the market's demand for performance is sated ("fast <i>enough</i>"), the market will base decisions on other issues - such as price. And that is not Apple's forte, nor does Apple want it to be. Thus, Apple already has the iPad lined up. After that, there'll be in another market at a stage where Apple's extraordinary ability to integrate can shine.<p>To be clear: Android is <i>modular</i>.
In my opinion, one of the main reasons people like the iPhone/iPad is the look and feel including the icons, animations, transitions, etc. The fact that iOS has included hardware acceleration from the very beginning speaks to how important the user experience was for them and using the GPU allowed them to provide a faster, smoother user experience.<p>I have to admit that the user experience in Android is severely lacking and is no where near as good as iOS. Let's hope this gets addressed in Gingerbread both for the core OS and for third-party apps.
The actual question should be why isn't the UI faster and more responsive? Stating a solution as a requirement is rarely a good idea.<p>We know that the iPhone and Droid (and successor Droid X) has pretty similar hardware, both license the GPU IP block from Imagination Technologies.
<a href="http://www.anandtech.com/show/3826/motorola-droid-x-thoroughly-reviewed/5" rel="nofollow">http://www.anandtech.com/show/3826/motorola-droid-x-thorough...</a><p>However, we do have some details missing in comparison with the iPhone. For example, do we know whether Apple's UI is h/w accelerated? If it is, does the GPU have dedicated graphics memory (and how much?) or could a blitter be used?<p>AFAIK, most if not all Android phones will have a GPU just simply as a function that Surfaceflinger (the Android window compositor) is an OpenGL implementation. It's only the emulator and during bring up that you'd use the software implementation of libagl/OpenGL.<p>There's also a question that how good is a mobile SoC GPU at doing 2D. As mentioned, it isn't de rigueur that a mobile GPU has dedicated (fast) memory which is completely different in the PC space which has copious amounts. In the Droid X case you're weighing a 1GHz CPU vs 200Mhz GPU with a small number of cores. In fact, consider that we're fairly used to spending as much if not more for the GPU in desktop systems as the CPU.<p>I do know for a fact that Imagination's 2D interface (PVR2D) has a large setup overhead which makes blitting of small bitmaps very slow, but somewhat ok with larger bitmaps. Add, alpha and it sucks in any case.<p>You shouldn't also discount that perhaps the Android UI and app. framework is naively implemented compared to Apples.
Did anyone else notice how early on in the bug Google's Romain Guy pointed out that <i>The "choppiness" and "lagginess" you are mentioning are more often related to heavy garbage collection than drawing performance</i> as well as saying that newer devices might allow them to use the GPU as well.<p>Did anyone pay any attention to that, and ask sensible questions about tuning that? Of course not...<p>On the Galaxy S (under Android 2.1) for example, the lagging seems to be caused by keeping temporary data on the slow, internal SD memory. That can be fixed by moving it to external memory, and there is a one-click fix for it in the Market. That fix <i>triples</i> the phones performance in some benchmarks, and has completely solves any lagging issues for me.<p>It's possible the HTC phones suffer from a similar problem, but here everyone assumes it's the GPU so you'd never know.<p><i>Never performance tune without benchmarking first. You'll fix the wrong thing</i>
The complete lack of responsiveness in the Android UI, regardless of how difficult it is to fix, needs to be remedied, and needs to be top priority.<p>The UI is the connection between the user and the device. When it's laggy and unresponsive, the experience of using the device is always going to be sub-par, no matter how many new features and optimizations the developers have added.<p>Whenever I've had a chance to test out the latest and greatest Android phone, I've always been blown away by how awful the scrolling performance and animations are, to the point where I really don't understand how people put up with it on a day-to-day basis. My iPhone 3G, at least when it's not randomly hanging due to 4.0, feels more responsive than any Android phone I've tried, and it's running on 3+ year-old hardware (it's got the same processor and memory as the iPhone 2G, IIRC).<p>Smooth animations, not benchmark results, are equivalent to speed to the average person, and who can blame them?
It's interesting to realize that one could be holding a phone and using a fraction of its computational capacity because the two companies that collaborated on creating it... don't talk enough?
I find that piece pretty interesting: "The "choppiness" and "lagginess" you are mentioning are more often related to heavy
garbage collection than drawing performance.".<p>Wasn't that supposed to be a thing of the past with modern garbage collectors?
Apple run loops are more flexible and adaptable than this<p><a href="http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/os/Looper.java" rel="nofollow">http://android.git.kernel.org/?p=platform/frameworks/base.gi...</a><p>via <a href="http://stackoverflow.com/questions/3321587/anatomy-of-an-android-run-loop" rel="nofollow">http://stackoverflow.com/questions/3321587/anatomy-of-an-and...</a><p>but since Looper is OSS it should be improved. Here's an idea, make it customizable like NextStep/Apple's architecture. Be able to change run loops on the fly when scrolling, select on different input sources, etc. Could be as simple as that...<p>Or if you want the long answer, it could be NextStep's key design choices which have paid off over the past decade.... Might as well learn from them. Will really flexible run loops solve single OGL context issues? Probably not. But they might just make things less jerky...
If you read between the lines, the reason they have tried and failed to implement this is fragmentation of the market. While more modern devices would likely support GPU usage, the older devices (or even new low end devices?) would not. So they either have to live with the current fragmentation or fragment the market even more.<p>Fragmentation is, of course, a huge point for Android detractors. This is a very real manifestation of that which shows that Android may stagnate in the future due to the inability to develop features for a significant number of devices.<p>However, for the most part, Android as it sits today has a low level of fragmentation compared to what could happen. I recently developed an Android app for 1.6-2.2 and only had a couple fragmentation issues (performance related and contacts API). Google and its partners really need to take a long look at the direction of Android and resolve the fragmentation now while its possible.