At the same time, Apple is strongly pushing developers to not use pixel perfect layouts anymore that are dependent on particular screen sizes, and to use auto layout everywhere. If you follow Apple's iOS 8 guidance, you really shouldn't have any problem dealing with even the original graph of "terrible" fragmentation.
Which prompts the question whether it was really that bad after all, or just a gut reaction to something that was different.
No, on those early devices, which were at least an order of magnitude slower than current devices, pixel-perfect layout was the only way to achieve fluid animations. It's not an accident that iOS devices were so much better at animations compared to Android devices in the early days, despite not necessarily having the best hardware.
But this is no longer true, or at least true to a much lesser extent. With current hardware you can achieve 60fps reliably even with a layout engine running constraint evaluations for every frame. It makes sense to make it easier to target variable screen geometries now, which was not the case 7 years ago.
> It's not an accident that iOS devices were so much better at animations compared to Android devices in the early days, despite not necessarily having the best hardware.
Pixel perfect layouts had NOTHING to do with that performance gap, and iOS devices have far and away the best GPUs of each generation. iOS devices consistenly push fewer pixels (lower resolution screens) with faster GPUs than Android does.
The only reason people think Android devices are such power houses is because everyone still just looks at the CPU core count and clock speed. Which has almost no impact on scrolling and animation performance.
EDIT: For example compare the Galaxy Nexus to the iPhone 4S. Both shipped Nov 2011, both use PowerVR GPUs. The GN is rendering 920k pixels, the 4S is only 615k pixels! The GN is making due with the SGX540 at 307MHz, whereas the 4S has the SGX543MP2 at 266mhz or so - literally double the GPU power of the GN, and for a lower resolution screen.
No, dynamic layout is a big factor, which is the reason why Google added new APIs for apps to tell the OS not to re-evaluate layout.
In every year's Google I/O there's at least one session on Android performance, and in every session there was always some technique on how to prevent layout calculation during animation.
So I'm just a old town country ios programmer for fun, so please correct me if I'm wrong. But wasn't the original issue that there wasn't a great way to deal with the multiple layouts/issues on the early 2.3 and below android models?
ios8 makes it plainly obvious that "something" is coming that will throw out the "the size of the screen shall be 5 and 5 shall be the size of counting, not 3 nor 4 but 5" paradigm. That or multitasking similar to windows 8 maybe.
But this shouldn't be all that crazy hard, we had how many years to deal with 800x600/1024x768/etc...
The core infrastructure for variable screen sizes and densities was introduced in Android 1.6 Donut (September 2009). There have been improvements with newer versions (e.g. more sizes and densities), but that's straightforward to deal with.
The other big improvement was the Fragments API that came with Android 3.0 Honeycomb (February 2011), but that came with a compatibility library that worked all the way back to Donut. And it was more about decomposing your UI into components that could be arranged differently for phones and tablets, not about adjusting a single UI within a device class.
Nope, there have been no substantive changes to the way one handles these layouts since android 1.0, with the exception of some additional targeting for LTR and changes to the way you address physically larger or smaller screens (as opposed to screens with fewer or more pixels).
Which prompts the question whether it was really that bad after all, or just a gut reaction to something that was different.