4 ms·
Android's performance problems are more to do with architecture than anything else: - Prior to 4.x the "highly optimized JVM" was "highly interpreted". - Acce
by hosay123 14y ago
Android's performance problems are more to do with architecture than anything else:
- Prior to 4.x the "highly optimized JVM" was "highly interpreted".
- Access to the display is gated via userspace (SurfaceFlinger) which must be invoked to composite every frame, and at least in 2.x (if not still true) unconditionally repainted the screen each frame.
- Accelerated 2D did not exist in Android 2.x, I'm not sure if it exists yet.
- None of the standard GUI widgets knew how to handle partial repaint. I think this was fixed in 4.x.
From the perspective of getting lag right, you only need to ensure there is some native code that can scroll around a bitmap efficiently. As for how that bitmap gets rendered, a few hundred thousand lines of C++ stands a much better chance of efficiency than an unoptimized, initially interpreted Java GUI framework that has no native way of expressing "allocate this temporary on the stack" ever did.
The choices made for Android might have been valid when painting a 160x200ish 16bit display (about 64kb per frame), which AFAIK was roughly the original target hardware prior to the Google purchase, but for 800x480 24bit this quickly turns into a need to generate 34mb/sec to render at 30fps, all done in software, chunks of it interpreted, on (what was initially) a 500mhz ARM11 CPU. Really helps frame the panic Google must have been in to get something on the market and fast.
- DeepDuh 14y ago> Really helps frame the panic Google must have been in to get something on the market and fast. The way I see Google from the outside they don't seem to be panicky when entering new markets. Half of the internet already belonged to them before Android, it's not like do or die in their case. Maybe Android's technically poor choice of backend architecture may have been due to inexperience in low power device software? Microsoft has much more experience there too, and they seem to have proven my point by releasing a very responsive WP7 about a year after (it should have been). Actually, seeing Microsoft's (and Palm's) situation, Google's 'worse is better' approach may have been just what they needed, so their management certainly deserves some slack there.
- zanny 14y agoThey bought Android the company, who had already picked Java etc. Google just rolled with it. In practice, I hope that Ubuntu Phone is the refinement of the Android platform we need. You don't need a bytecode sandbox if you implement sound MAC, which Android had in its installer. I just hope that Ubuntu Phone adopts wayland instead of X, and not their own window manager mess like surfaceflinger.
- compilercreator 14y agoPrior to 4.x, the "highly optimized JVM" you speak of was fully interpreted. Slight correction: JIT compiler was first introduced in Android 2.2
- hosay123 14y agoThanks, pretty sure the remainder of the version numbers are messed up too.. pulled out of my old and foggy memory. :)
- pretoriusB 14y agoWow. From this list of issues some of which are "fixed at 4.x", and from the fact that --based on Google's own stats-- very few people have 4.x (only around 10% of all Android devices have it or have upgraded to it), the whole Android vs iOS fight seems kind of moot. Technology wise iOS wins hands down.
- bitwize 14y agoAndroid, the OS and company, was purchased by Google. Its founder, Andy Rubin, was also the founder of Danger, Inc., makers of the HipTop/T-Mobile Sidekick, one of the first mass-market smartphone-like devices. It's interesting to note that the HipTop has always had a modified Java run time, and in later versions even ran on a Unix kernel (NetBSD I think). So the architecture decisions for Android were already familiar to Rubin and the team.