In a nutshell: Android itself isn't actually any slower, but it _seems_ slower due to garbage collection pauses.
When Android stutters, you can put money on it being down to the garbage collector running at an inopportune moment. This is the downside of most Android apps being built in Java, whereas most iOS apps are written in Objective C, which uses reference counting and so you have more deterministic release of allocated memory. The upside of this is little or no stuttering, but the downside is that you can still end up with pauses, but they can be in places which are hidden from the user. The other downside of GC is that developers can lean on it a bit more than is justifiable to create needless duplicates of objects on the assumption that they'll be garbage collected eventually... which can lead to GC stutter. A lot of Android's 'slowness' issues would go away if devs were a bit more careful with how they allocate their objects.
Another thing that makes Android seem slower than iOS is that Android gives apps a pretty lengthy grace period when they hang for some reason and will alert the user if it thinks the app has hung. iOS, OTOH, is less tolerant of this kind of thing and will just kill the offending app and rely on the app to restore its state when restarted. This hides a lot of issues with apps on iOS that are more obvious on Android. Which choice is better is a matter of debate: the iOS route gives the better user experience 90% of the time, but when you want that 10%, you really want that 10%.
Emulators (and quite a lot of games too) tend to be written in C and C++, which means they do manual memory management or use the conservative Boehm GC, so you end up with little or no GC stutter. OTOH, if the developer isn't careful, you're more likely to end up with memory leaks.