Nexus S Beats iPhone 4 In 'Real World' Web Browsing Tests 260
bongey writes "In a series of measured real-world web load tests, the Android-based Nexus S phone spanked the iPhone 4. The Android phone and iPhone 4 median load times were 2.144s and 3.254s respectively. The sample size was 45,000 page loads, across 1000 web sites. It also follows rumors that Apple is intentionally slowing down web apps to make their native apps more favorable."
Bogus (Score:5, Interesting)
They were using a custom app. Not the default browser. So what they are saying is that their app runs faster on the Nexus S. Not that the Nexus S is faster then the iPhone.
Android/iPhone UI performance (Score:2, Interesting)
From personal observations, I have noticed that transitions are much smoother on iPhones than on comparable Android phones. For example, if I am browsing photos on an iPhone and I swipe left, I see the image smoothly (60fps or more?) move to the left and the new image smoothly move on. By comparison, every Android phone I have seen implements the same effect, but I see artifacts like tearing or skipping of frames. It looks like it goes at 60fps, then drops down to 5, then back up to 60. I tend to be more sensitive to this type of thing than most people (I see CRT refreshes and tend to get motion sick playing games that bob up and down)
IMHO, this is something Apple has done right all the way back to the original macs, and many other developers don't seem to have a grasp on. Most people don't notice the artifacts directly, but they "feel" it subtly. It makes people just like the iPhone UI more, and they may not be able to put their finger on exactly why.
Apple/Oranges (Score:5, Interesting)
Someone pointed out already that the way they tested is with apps that use the browser engine available to apps. As the second link says in the main story (probably, I'm too lazy to RTFA, I read others already), the iOS browser engine doesn't use the Nitro javascript engine.
I found one link that discusses it, but I'm sure there are better ones:
http://www.informationweek.com/news/personal-tech/smart-phones/showArticle.jhtml?articleID=229301178
Re:Bogus (Score:4, Interesting)
Re:Well... no. (Score:2, Interesting)
And more to the point, there is actually a technical reason not to have Nitro in apps.
Nitro is a JIT compiler. To use it means that the App needs to be basically allowed to have self modifying code (the power to say "this data memory is now executable"). This capability is an application-wide setting, that is reserved to Apple-developped apps for now, for good reasons.
This has never been allowed in apps (and is the technical basis to disallow any frameworks like mono), because it exposes the device to a security threat that is not easily detected by Apple's testing (say an app that will, at some future date, download data from a remote server, turn it into code, and execute it. Voila, instant virus).
This is not something Apple is prepared to simply allow for the sake of performance. This decision does not degrade web apps performance (as you noted, they still perform as good as they used to).
People on slashdot usually yell when companies do not take security seriously. Well, this is a decision that is firmly rooted in the security camp.
There might be technical solutions allowing nitro in apps and not compromising the device's security in the future. But anything that is released is a compatibility weight in the future, so I don't blame Apple for not releasing something half baked that they would have to take away later (or leave a gaping security hole).