Android knuser iOS i nettleserhastighet

[PL610]

Alt testen viser er at WebView er raskere enn UIWebView, og slett ikke hvilket operativsystem som har den raskeste nettleseren.

 

Det skaper jo selvsagt en stor mengde klikk når det fremstilles slik det er blitt

 

Det skulle derimot vært interessant å se en reell test mellom nettleserne.

[Marasmus]

At Apple driter seg ut ved at de ikke gir utviklere de beste forutsetninger, får stå for Apples egen regning. At de syter og klager blir bare tåpelig.

 

Hvis du hadde lest tidligere innlegg i tråden og artiklene det lenkes til, ville du fått med deg at årsaken til at optimaliseringene i Safari ikke er tilgjengelig i UIWebView skyldes sikkerhet. Det er altså ikke fordi Apple er ute etter å drite seg ut eller fremheve Safari som et bedre alternativ enn tredjepartsbrowsere på plattformen.

[wirrumsen]

Hvis du hadde lest tidligere innlegg i tråden og artiklene det lenkes til, ville du fått med deg at årsaken til at optimaliseringene i Safari ikke er tilgjengelig i UIWebView skyldes sikkerhet. Det er altså ikke fordi Apple er ute etter å drite seg ut eller fremheve Safari som et bedre alternativ enn tredjepartsbrowsere på plattformen.

 

Og hva så? Javel, det er på grunn av sikkerhet. Da bør de gjøre noe med dette, og i mellomtiden innse nederlaget. At de ikke klarer å opprettholde sikkerheten i UIWebView er jo ikke testhuset sin feil...

[M@R7!N]

Skriv din kommentar....Android telefonen som ble brukt i testen er faktisk nesten like dyr som den billigste iPhone 4 (flaut fra Samsung/google's side..) så det er neppe noe godt argument.

 

Flaut å prise en like god telefon billigere? Smart du

[Marasmus]

@wirrumsen

 

At Apple faktisk gjør noe med dette fremkommer også i artiklene du ikke har lest.

 

Både Apple og Apple-brukere er fullt klar over at Android laster nedsider kjappere enn nettlesere på iOS som benytter UIWebView. Eventuelt har de innsett nederlaget, for å bruke dine ord. Det eneste det har blitt protestert på er at det skal være bevist at Android-nettlesere er kjappere enn Safari i iOS 4.3. Når det ikke nødvendigvis stemmer, må Apple få lov til å protestere.

Endret 19. mars 2011 av Marasmus

[Zappy]

Blaze gjorde dette som et PR-stunt for å selge ut deres ekspertise på å få fart på nettsider, vet ikke helt hvordan de kunne skapt verre PR for seg selv enn dette.

Du tror ikke på at all PR er god PR?

Ikke i alle sammenhenger kanskje, men definitivt sant i denne.

De eneste som hårsår etter dette er Apple fanboys.

 

De la tross alt ut forklaringen om at det var samme feil like etter de ble informert om det. No foul i mine øyne.

[PL610]

Tja, som Gruber skriver:

These Blaze guys are either incompetent or dishonest attention seekers, given that they claim this, in an update to their report:

 

"Some wonder whether the new Nitro JavaScript engine was used in our measurements. We’re still investigating this issue, as the report was completed before it was made known. So far we’ve seen indications in both directions, so we can’t say for sure it’s being applied.

 

That said, the results from measuring Android show that JavaScript only accounts for a small percentage of the total load time, about 15% on average. This implies that even if Nitro is not in use, it likely can only slightly narrow the gap. We’ll follow up with any additional info."

 

Because the thing is, Nitro isn’t the only difference between Mobile Safari’s rendering and UIWebView’s rendering. Mobile Safari has better caching and asynchronous multithreading, too.

 

Edit: Uthevet det Gruber skrev

Endret 19. mars 2011 av PL610

[NgZ]

Dette er jo en god test av den innebygde nettlesere i systemet uasett om Safari på iOS er bedre eller ikke.

 

*Svært* mange apps til iOS er jo bare wrappere for den innebygde nettlesermotoren

[PL610]

Mulig det er det på Android, men det er det ikke i iOS.

[NgZ]

Vel, det var ikke det inntrykket jeg fikk på AppStore av en del apps. Særlig appsene til ulike nettsider som Wired, engadget osv, bla annet en del nettaviser, var bare et skall rundt den innebygde nettleserfunksjonalite med en knpp eller to som snarvei til div. innhold/menyer, Skandiabanken app-en er vel et annet eksempel. Synes det virker logisk at disse bruker den samme innebygde webmotoren som appen det er snakk om her, ettersom det sp vidt je har skjønt kun er den som er tilgjengelige for utviklere.

[PL610]

De må kjøre UIWebView som ikke har de samme optimaliseringene som Safari.

Og Nitro JavaScript engine som kom i 4,3 er kun tilgjengelig i Safari.

 

Edit: Feil ord

Endret 22. mars 2011 av PL610

[NgZ]

Men er ike det det samme som den innebygde UIWebView-funksjonaliteten? Eller finnes det tre renderingmotorer i iOS; UIWebView, Web.app og den i Safari?

[PL610]

UIWebView control er det man har tilgjengelig for nettleserapps i appstore, og brukes også i webapps hvis jeg har forstått det riktig.

Det kan godt hende UIWebView control får tilgang til Nitro JavaScript engine med tiden, men Safari vil nok uansett ha bedre optimalisering.

[NgZ]

Vel, siden mange apps i praksis er wrappere rundt HTML-innhold, eller i hvert fall brukr HTML-innhold i ganske stor grad, vil jo da denne testen være relevant for veldig mange apps.

[PL610]

Ja, det er den nok sikkert, men den sier ingenting om hvor rask eller treg Safari er i forhold til nettleseren på Android.

 

Denne testen kan man sikkert foreta selv med litt tålmodighet og en stoppeklokke. Dog kanskje ikke på fullt så mange sider

[NgZ]

Neida, det gjør den nok ikke, men at den feiler på et punkt, gjør den jo absolutt ikke verdiløs av dn grunn.

 

Forhåpentligvis et spark bak til Apple for å få fikset "sikkerhetsproblemene" i den nye motoren, slik at trdjepartapps kan bli like gode somderes egen Safarinettleser. Ikke at de ønsker det, selvfølgelig.

[PL610]

Nja, det har nok mer med sikkerhet og gjøre:

he real answer is about security. Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation. Here’s Wikipedia’s page on JIT. A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

 

It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.

 

http://daringfireball.net/2011/03/nitro_ios_43

 

For de andre optimaliseringene derimot kan man sikkert spekulere hvis man vil.

[NgZ]

Jada, jeg så den biten av artikkelen, og det var jo en mer reell sikkerhetsrisiko enn jeg i ugangspunktet hade trodd. I utgangspunktet så jeg på det som en "det er noen sikkerhetshull vi vil gjemme", men det var det i det minste ikke.

 

Men det er jo egentlig ikke snakk om et konkret sikkerhetsproblem med motoren, men et plattformproblem - vil man ikke gi apps tilgang til kjørbart minne, må man tilby komponenter integrert som fungerer tilfredsstillende. Men det kommr jo i hvert fall i fremtiden.