Il y a deux jours, nous avons publié une actualité indiquant que les performances d’iOS 4.3 semblaient différentes selon qu’on chargeait des pages web depuis Safari, ou depuis une application web épinglée sur la grille des icônes. Parallèlement à ce souci soulevé par The Register, une batterie de tests a été réalisée par Blaze Software, qui en a sorti des différences énormes de performances entre iOS 4.3 et Android 2.3. Explications.
L'absence de Nitro et les performances d'Android
The Register s’était fait l’écho d’une différence importante de performances entre les pages web chargées dans Safari, et les applications web épinglées. La différence de performances ressemblait fort à la hausse de 50 % sur les performances JavaScript clamée par Apple, qui introduisait pour la première fois sa machine virtuelle Nitro dans Safari mobile. Cet écart a rapidement fait parler de lui, et encore davantage depuis les tests de Blaze.
Chez cette société canadienne, on s’est intéressé aux écarts de performances entre les navigateurs d’iOS 4.3 et d’Android 2.3. Sur les 45 000 tests effectués, Android était plus rapide pour charger les pages dans 84 % des cas. Moyenne enregistrée : 52 % de performances en plus pour Android, un écart plus que conséquent. Ce chiffre diminuait par contre avec les versions mobiles des sites, et l’écart n’était plus que de 3 %.
Nitro n'est que dans Safari
Ces deux histoires cumulées ont provoqué une réaction finalement assez rare : celle d’Apple. Et c’est à The Register que Trudy Muller, porte-parole de la société, s’est adressée. Elle a confirmé ce que les développeurs qui avaient communiqué avec The Register avaient pressenti : les pages web épinglées sur l’écran de l’iPhone ne profitent pas de Nitro. Les optimisations de la version 4.3 d’iOS intègrent Nitro, la gestion de certains caches ainsi que le mode de rendu asynchrone. Or, ces optimisations ne sont présentes que dans Safari, pas dans les web views.
Les web views permettent d’afficher un contenu web en utilisant une API de Safari (UIWebView), mais sans passer par le navigateur complet. La question qui se pose est évidemment : pourquoi une telle différence de traitement ? C’est le célèbre John Gruber qui fournit un élément de réponse. Il indique que le principal attrait et vecteur de performances dans Nitro vient du compilateur JIT (Just-In-Time) intégré. Pour que ce compilateur fonctionne, il faut que certains espaces dans la mémoire vive puissent être désignés comme exécutables. Et c’est là toute la différence : la chose est possible depuis Safari, mais pas depuis les web views.
Sécurité et performance : soit l'une, soit l'autre ?
D’après Gruber, ce serait une question de sécurité. La création de zones mémoire exécutables n’est normalement pas autorisée dans iOS, et la seule exception vient de Safari mobile dans iOS 4.3. Ces zones mémoires permettraient l’exécution de code natif non signé, « brisant ainsi la chaîne de confiance ». Bien entendu, la situation est techniquement beaucoup plus complexe, mais le choix d’Apple se base sur la sécurité et non sur les performances. Si Apple activait ce type de zones mémoires pour tous, il serait possible d’utiliser n’importe quelle faille pour créer une escalade de privilèges et ainsi ouvrir la porte à des dégâts plus importants.
Du coup, Apple juge la méthodologie de Blaze faussée, pour la simple et bonne raison que les 45 000 tests n’ont pas été réalisés dans Safari. L’éditeur canadien a en effet utilisé sa propre solution maison qui se base... Sur des web views. De fait, les améliorations d’iOS 4.3 ne sont pas présentes, et le titre du résultat aurait plutôt dû faire mention d’iOS 4.2, puisque c’est quasiment à ceci que revient la conclusion.
Gruber indique que plusieurs pistes seraient possibles pour Apple concernant l’utilisation de Nitro pour les web views. Car ces dernières sont importantes, puisqu’elles permettent d’appeler une page web depuis une application. Sur le client Twitterrific par exemple, cliquer sur un lien dans un tweet ouvre la page dans l’application, et pas dans Safari, ce qui évite les allers retours. Deux idées sont fournies :
L'absence de Nitro et les performances d'Android
The Register s’était fait l’écho d’une différence importante de performances entre les pages web chargées dans Safari, et les applications web épinglées. La différence de performances ressemblait fort à la hausse de 50 % sur les performances JavaScript clamée par Apple, qui introduisait pour la première fois sa machine virtuelle Nitro dans Safari mobile. Cet écart a rapidement fait parler de lui, et encore davantage depuis les tests de Blaze.
Chez cette société canadienne, on s’est intéressé aux écarts de performances entre les navigateurs d’iOS 4.3 et d’Android 2.3. Sur les 45 000 tests effectués, Android était plus rapide pour charger les pages dans 84 % des cas. Moyenne enregistrée : 52 % de performances en plus pour Android, un écart plus que conséquent. Ce chiffre diminuait par contre avec les versions mobiles des sites, et l’écart n’était plus que de 3 %.
Nitro n'est que dans Safari
Ces deux histoires cumulées ont provoqué une réaction finalement assez rare : celle d’Apple. Et c’est à The Register que Trudy Muller, porte-parole de la société, s’est adressée. Elle a confirmé ce que les développeurs qui avaient communiqué avec The Register avaient pressenti : les pages web épinglées sur l’écran de l’iPhone ne profitent pas de Nitro. Les optimisations de la version 4.3 d’iOS intègrent Nitro, la gestion de certains caches ainsi que le mode de rendu asynchrone. Or, ces optimisations ne sont présentes que dans Safari, pas dans les web views.
Les web views permettent d’afficher un contenu web en utilisant une API de Safari (UIWebView), mais sans passer par le navigateur complet. La question qui se pose est évidemment : pourquoi une telle différence de traitement ? C’est le célèbre John Gruber qui fournit un élément de réponse. Il indique que le principal attrait et vecteur de performances dans Nitro vient du compilateur JIT (Just-In-Time) intégré. Pour que ce compilateur fonctionne, il faut que certains espaces dans la mémoire vive puissent être désignés comme exécutables. Et c’est là toute la différence : la chose est possible depuis Safari, mais pas depuis les web views.
Sécurité et performance : soit l'une, soit l'autre ?
D’après Gruber, ce serait une question de sécurité. La création de zones mémoire exécutables n’est normalement pas autorisée dans iOS, et la seule exception vient de Safari mobile dans iOS 4.3. Ces zones mémoires permettraient l’exécution de code natif non signé, « brisant ainsi la chaîne de confiance ». Bien entendu, la situation est techniquement beaucoup plus complexe, mais le choix d’Apple se base sur la sécurité et non sur les performances. Si Apple activait ce type de zones mémoires pour tous, il serait possible d’utiliser n’importe quelle faille pour créer une escalade de privilèges et ainsi ouvrir la porte à des dégâts plus importants.
Du coup, Apple juge la méthodologie de Blaze faussée, pour la simple et bonne raison que les 45 000 tests n’ont pas été réalisés dans Safari. L’éditeur canadien a en effet utilisé sa propre solution maison qui se base... Sur des web views. De fait, les améliorations d’iOS 4.3 ne sont pas présentes, et le titre du résultat aurait plutôt dû faire mention d’iOS 4.2, puisque c’est quasiment à ceci que revient la conclusion.
Gruber indique que plusieurs pistes seraient possibles pour Apple concernant l’utilisation de Nitro pour les web views. Car ces dernières sont importantes, puisqu’elles permettent d’appeler une page web depuis une application. Sur le client Twitterrific par exemple, cliquer sur un lien dans un tweet ouvre la page dans l’application, et pas dans Safari, ce qui évite les allers retours. Deux idées sont fournies :
- Rendre Nitro disponible pour toutes les applications, en l’isolant dans un processus spécifique, à la manière du lecteur Flash dans Snow Leopard
- Un processus Nitro dédié aux applications tierces, et qui exécute le JavaScript « pour » les applications, et non « dans » les applications
![[Test] Steam Deck, enfin un succès matériel chez Valve ?](https://cdnx.nextinpact.com/compress/100-75/data-next/images/bd/square-linked-media/12524.jpg)
