Jak wspomniano w innym miejscu, głównym problemem jest to, że Android został zaprojektowany jako przenośny system operacyjny, który działa na szerokiej gamie sprzętu. Opiera się również na strukturze i języku znanych wielu istniejącym programistom mobilnym.
Na koniec powiedziałbym, że jest to zakład na przyszłość - wszelkie problemy z wydajnością staną się nieistotne wraz z poprawą sprzętu - podobnie, zachęcając programistów do kodowania wbrew abstrakcjom, Google może znacznie łatwiej wydobyć i zmienić podstawowy system operacyjny, niż gdyby programiści kodowali do API POSIX / Unix.
W przypadku większości aplikacji narzut związany z używaniem języka opartego na maszynach wirtualnych zamiast natywnego nie jest znaczący (wąskim gardłem dla aplikacji korzystających z usług internetowych, takich jak Twitter, jest głównie sieć). Palm WebOS również to pokazuje - i to używa JavaScript zamiast Javy jako głównego języka.
Biorąc pod uwagę, że prawie wszystkie maszyny wirtualne JIT kompilują się do kodu natywnego, prędkość surowego kodu jest często porównywalna z prędkością natywną. Wiele opóźnień przypisywanych językom wyższego poziomu ma mniej wspólnego z narzutem maszyny wirtualnej niż z innymi czynnikami (złożone środowisko wykonawcze obiektów, „bezpieczeństwo” sprawdzanie dostępu do pamięci poprzez sprawdzanie granic itp.).
Pamiętaj też, że niezależnie od języka używanego do pisania aplikacji, wiele faktycznej pracy jest wykonywana w API niższego poziomu. Język najwyższego poziomu często po prostu łączy wywołania API w łańcuchy.
Istnieje oczywiście wiele wyjątków od tej reguły - gry, aplikacje audio i graficzne, które przesuwają granice sprzętu telefonicznego. Nawet na iOS programiści często przechodzą do C / C ++, aby uzyskać prędkość w tych obszarach.