Nie wiem jak jest w przypadku Hero, ale mogę się wypowiedzieć o platformie o jaką jest oparty (a ostatnie modele od HTC praktycznie nie różnią się pod tym względem między sobą).
Ujmę to tak: Qualcommy ze swojej wydajności nie słyną, a xscale z podobnym taktowaniem (i dołożonym akceleratorem grafiki) by qualcomma wgniótł w ziemię i jeszcze po nim poskakał 😉 Widziałem absurdalną wręcz sytuację, w której HTC Wizard ze 192MHz procesorem TI Omap bił w benchmarku graficznym HTC Kaiser z 400MHz qualcommem (chociaż fakt, że kasier chodził na zamulającym romie od operatora).
Po zabawie diamondem (sprzętowo praktycznie to samo co G1) z windowsem mobile na pokładzie miałem pewne obawy co do wydajności G1 którego zakup rozważałem, ale muszę przyznać że ogólnie jestem mile zaskoczony. Android w przeciwieństwie do WinMo po prostu lepiej wykorzystuje moc obliczeniową tej platformy. Na przykład windows mobile używa możliwości akceleracji 3D qualcomma tylko w nielicznych przystosowanych do tego aplikacjach. Android najwyraźniej korzysta z nich cały czas dając wrażenie znacznie większej płynności działania interfejsu.
Mówiąc krótko: demon szybkości to nie jest, ale do obsługi systemu/multimediów czy porządnie napisanych gier wystarcza. A jak się developerzy postarają to potrafi pociągnąć i
. Z połączenia android+qualcomm jestem ogólnie bardziej zadowolony niż z windows mobile+xscale (poprzednio miałem toshibę G900). Mając do wyboru urządzenie z androidem na procesorze qualcomm i xscale bez zastanowienia wybieraj xscale. Problem w tym, że jeszcze takowych na rynku nie ma - są tylko zapowiedzi. Ale mając do wyboru windows mobile i android to póki co android mi odpowiada bardziej - winMo po prostu popadł w stagnację. Dopiero ostatnio coś się powoli zaczyna ruszać. Odnośnie porównania z iphonem się nie wypowiem bo nie bawiłem się nim wystarczająco długo.
Co do wolnego działania programów pisanych w javie - na pewno takie programy zawsze będą wolniejsze niż oprogramowanie pisane natywnie na daną platformę ze względu na to, że ich kod jest z reguły interpretowany "w locie" przez wirtualną maszynę javy, a nie skompilowany dla danej platformy. Na pecetach czy innych maszynach o podobnie dużej mocy obliczeniowej nie jest to duża różnica, ale zaczyna być odczuwalna na urządzeniach takich jak telefony. Nie wnikałem (jeszcze) w programowanie dla androida, ale pamiętaj o tym, że w przypadku tego systemu to nie mówimy o javie, a dalvik-u. Wywodzi się z javy bierze z niej składnię i ogólną koncepcję, ale są też spore różnice. Nie wspominając o tym, że najsłabszy sprzęt z którym aplikacje muszą być kompatybilne jest wydajniejszy niż w przypadku javy znanej z większości telefonów, a do tego oferuje akcelerację 2d/3d co dość mocno odciąża procesor.
Z punktu widzenia użytkownika nie powinieneś się martwić wydajnością aplikacji - dobrze napisana aplikacja nie odbiega wydajnością od podobnych programów pisanych natywnie dla WinMo, a czasem nawet je prześciga (np. emulacja SNES-a, czy GBA).
Poza tym nie będziesz miał problemu znanego np. z windows mobile że po odpaleniu kilku aplikacji system zaczyna zamulać. Android bardzo skutecznie zarządza uruchomionymi programami zwalniając użytkownika z tego obowiązku. Jeśli jakaś aplikacja działająca w tle zbytnio obciąża procesor to system ją zamyka. Ale bez obaw - takie zachowanie jest przewidziane i programy zapisują przed zamknięciem swój aktualny stan żeby do niego wrócić po ponownym uruchomieniu. Czyli różnica między pozostawieniem aplikacji w tle a ponownym uruchomieniem będzie taka, że w pierwszym przypadku przełączenie z powrotem nastąpi natychmiast, a w drugim odczekasz dodatkową sekundę na ponowną inicjalizację programu i przywrócenie stanu poprzedniego.
Zwiecha całego systemu też jest dość mocno utrudniona, bo nad wszystkim zawiaduje bardzo stabilny linux który kontroluje uruchomione aplikacje javowe i w razie potrzeby jest w stanie zamknąć (lub w przypadku krytycznych elementów systemu zrestartować) zawieszony program. Ponieważ same programy w normalnej sytuacji (nie zrootowany telefon) nie mają możliwości ingerencji w działanie znajdującego się pod spodem linuxa, nie jest on zagrożony utratą stabilności z winy źle napisanego programu, co jest dość częstą sytuacją np. w windowsie mobile.