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.