Facebook dropper iPhone-app bygget i HTML5 - den er alt for langsom

9 kommentarer.  Hop til debatten
Facebook dropper iPhone-app bygget i HTML5 - den er alt for langsom
Illustration: Google.
Langsomme reaktionstider i Facebooks app til iPhone får nu selskabet til at droppe HTML5 og i stedet satse mere på styresystemets foretrukne sprog Objective-C.
person
Casper Thomsen
Udviklingschef
10. juli 2012 kl. 11:39
errorÆldre end 30 dage
person
Casper Thomsen
Udviklingschef
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Facebook vil skifte spor for udviklingen af selskabets populære app til iPhone, fordi den nuværende app er alt for langsom, skriver The New York Times.

Hidtil har Facebook i vid udstrækning benyttet sig af HTML5, så app'en i praksis fungerer som en webbrowser, der indeholder sider fra Facebook optimeret til iPhone.

Problemet er, at dette kan begrænse reaktionstiderne voldsomt, fordi den indbyggede browser i apps ikke er specielt hurtig.

I stedet er Facebook nu i fuld gang med at færdiggøre en ny udgave af app'en, som primært er bygget med Objective-C, som er det foretrukne programmeringssprog til Apples mobile styresystem iOS.

Artiklen fortsætter efter annoncen

Dette skulle gøre Facebook i stand til bedre at udnytte de indbyggede hardwareressourcer i iPhone og samtidig hente færre løbende data fra nettet.

Den nye Facebook-app vil som udgangspunkt ikke adskille sig fra den nuværende app i design og funktionalitet, men blot være langt hurtigere.

Når Facebook hidtil har benyttet sig af HTML5, har det været for at gøre livet lettere for udviklerne, som på den måde kunne genbruge langt flere ressourcer fra den mobile udgave af Facebook.

Nyheden fra Facebook kommer, efter LinkedIn for nylig lancerede en ny iPad-app, hvor 95 procent af funktionaliteten er bygget i HTML5.

9 kommentarer.  Hop til debatten
Fortsæt din læsning
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
6
Emil Moe
11. juli 2012 kl. 02:44

Endelig skal det nok også med i overvejelserne, at hvis der trækkes færre data fra Facebook, belaster det på længere sigt sikkert deres egne servere mindre, så de kan spare penge den vej.

  • more_vert
    • insert_linkKopier link
3
Frederik Dam Sunne
10. juli 2012 kl. 17:35

Hej,

Hvis man bruger Ajax kald med JSON formatteret data burde det ikke gøre nogen forskel IMHO.

Hilsen,

Frederik

  • more_vert
    • insert_linkKopier link
1
Frederik Dam Sunne
10. juli 2012 kl. 17:20

"Applications that are predominantly HTML5 render most of the components of an app as a Web page, pulling images and content from the Web directly into the application. Objective-C takes the opposite approach, taking full advantage of the hardware in the iPhone and then building most of the functionality directly into the application so it has to collect less information from the Web."

Hvis forskellen er, at de sparer nogle HTTP forespørgsler ved at lave en app, hvorfor cachede de så ikke bare de samme forespørgsler i deres HTML5 app?

"Problemet er, at dette kan begrænse reaktionstiderne voldsomt, fordi den indbyggede browser i apps ikke er specielt hurtig."

Nu har jeg ikke en iPhone, men er det ikke bare en Mobile Safari de benytter uden chrome? Så er der vel ingen forskel i hastighed på normal browsning på iPhone eller når apps bare åbner den samme browser uden chrome...?

Hilsen,

Frederik

  • more_vert
    • insert_linkKopier link
4
Jacob Møhl
10. juli 2012 kl. 21:48

Problemstillingen ligger i at det Objective-C komponent man bruger til at rendere HTML(5) i (også kaldet et WebView) ikke anvender den samme JavaScript motor som Apple Mobile Safari.

Hvorfor at javascript tung HTML(5) køre meget langsommere i en app end gennem Mobile Safari.

Dette tolkes at mange som Apples forsøg på at minimere brugen af HTML som kode i Native Apps, men kun som en mulighed til begrænset funktionalitet.

Så det har ikke noget at gøre med antallet at kald eller mængde af dataen som skal transporteres. Facebook appen er f.eks. lige langsom om man er på Wifi eller 3G.

Håber det kan bringe lidt klarhed over problemstillingen.

  • more_vert
    • insert_linkKopier link
5
Michael Lykke
10. juli 2012 kl. 22:39

Problemstillingen ligger i at det Objective-C komponent man bruger til at rendere HTML(5) i (også kaldet et WebView) ikke anvender den samme JavaScript motor som Apple Mobile Safari.

Det er nemlig én af forskellen der har indflydelse på en webapps performance. Men uanset om app'en benyttede Nitro javascript engine eller ej så vil en native app stadigvæk performe mange gange bedre end HTML. Der er stor forskel på at skulle render HTML og på en native kompileret app der direkte kan udnytte hardwarens ressourcer. Vi taler om forskel i performance med alt fra hvordan app'en reagere når du trykker på en knap til scroll i lister, animationer, rendering af billeder og video osv.

HTML5 er ganske enkelt ikke den magiske løsning på cross-platform apps som mange forsøger at gøre dem til. De har fortsat store begrænsninger og netop dette gør at en native app, i de fleste tilfælde, vil være en langt bedre løsning. Facebook er langt fra den første applikation der er startet som en HTML5 app som efterfølgende skifter til native netop pga. de mange problemer der følger med HTML5 apps.

HTML5 er IKKE den magiske løsning på cross-platform apps... I hvertfald ikke endnu!

Nyheden fra Facebook kommer, efter LinkedIn for nylig lancerede en ny iPad-app, hvor 95 procent af funktionaliteten er bygget i HTML5.

Som jeg tidligere har sagt så må man stille kraftige spørgsmålstegn ved Linkedin's påstand om 95% HTML. Et nærmere kig på IPA filen bag applikationen afslører en størrer mængde XIB filer m.m. Netop XIB filer er native interface filer(med tilhørende controllers) og indikere at app'en består af en hel del mere end 5% native kode. At dømme ud fra filnavne m.m. så tyder det også på at en hel del af de native elementer netop er mange af de ting som giver performance problemer i HTML5 apps - Tabeller/lister, views med mange elementer m.m.

  • more_vert
    • insert_linkKopier link
7
Tore Julø
11. juli 2012 kl. 09:55

Vi taler om forskel i performance med alt fra hvordan app'en reagere når du trykker på en knap til scroll i lister, animationer, rendering af billeder og video osv.

Der var faktisk et par rigtigt gode sessions på Google I/O om hvordan man optimerer den slags. Fast UIs for the Cross-Device Web : http://www.youtube.com/watch?v=ie4I7B-umbAJank Busters: Building Performant Web Apps : http://www.youtube.com/watch?v=hAzhayTnhEI

Et trick der bliver nævnt mht. reaktionstid ved tryk er at bruge touchend i stedet for click events, da man på den måde undgår, at browseren venter 300ms på, om det skulle være et dobbelttap. Teknikken er forklaret i detaljer her: https://developers.google.com/mobile/articles/fast_buttons

  • more_vert
    • insert_linkKopier link
8
Michael Lykke
11. juli 2012 kl. 16:03

Det løser desværre ikke en lang række af de problemer der er, som er direkte relateret til forskellen mellem den tid en browser skal bruge på at render HTML og hvor hurtigt native kode kan render et tilsvarende interface.

Men tak for links - Det er altid interessant at suge mere info til sig :)

  • more_vert
    • insert_linkKopier link
9
Baldur Norddahl
11. juli 2012 kl. 21:48

Det løser desværre ikke en lang række af de problemer der er, som er direkte relateret til forskellen mellem den tid en browser skal bruge på at render HTML og hvor hurtigt native kode kan render et tilsvarende interface.

Hvad er det for en naturlov, som siger at et "native API" kan tegne en brugergrænseflade hurtigere end en "browser"? Dit "native" program opbygger ikke skærmbilledet pixel for pixel, men bruger i stedet et API til at beskrive layout. Det er ikke nødvendigvis spor mere effektivt end et andet API som er baseret på CSS og HTML.

  • more_vert
    • insert_linkKopier link
2
Deleted User
10. juli 2012 kl. 17:30

De bruger en WebKit render til deres HTML5. Den samme render som den mobile version af Safari anvender. Den rigtige problem stilling er vel også at "HTML5 er langsommere end Cocoa" ikke at "HTML5 er langsomt".

En væsentlig speedup ligger i hvert fald i forskellen på at skulle hente en masse markup samt data ved en HTML5 app, kontra at kun skulle hente data ved en native app.

  • more_vert
    • insert_linkKopier link