J'ai cherché partout des informations et je n'ai trouvé aucune liste définitive. Veuillez ajouter vos observations. Je suis sûr que cela sera utile à tous.
Réponses
Trop de publicités?Il ne dispose pas du moteur Javascript Nitro. Cela rend l'exécution de Javascript beaucoup plus lente dans UIWebView par rapport à Safari.
http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/
http://ariya.ofilabs.com/2012/06/nitro-javascriptcore-and-jit.html
Lorsque UIWebView fait défiler son contenu, il gèle tous les événements JavaScript jusqu'à la fin du défilement. Donc vous devez absolument ne peut pas d'observer et/ou de contrôler programmatiquement le processus de défilement de cette manière courante :
window.onscroll = function() {
var scrolled = window.pageYOffset || document.documentElement.scrollTop;
// do something
}
parce que la variable 'scrolled' ne sera mise à jour qu'une seule fois - après que le défilement soit complètement terminé.
Une chose que j'ai trouvée, à mon grand regret, c'est que UIWebView
est un peu plus strict lorsqu'il s'agit de définir des valeurs de style par le biais de JS. Par exemple, dans le safari mobile
element.style.width = 300;
fonctionnera très bien, mais dans UIWebView
vous devez définir la valeur comme
element.style.width = 300 + "px";
Il y a d'autres différences que je découvre lentement. Je mettrai ce texte à jour au fur et à mesure.
Les deux plus évidentes que j'ai rencontrées sont l'authentification et les pages avec des cadres.
Pour l'authentification, UIWebView ne gère pas automatiquement les défis d'authentification, c'est aux développeurs de les gérer.
Pour les pages avec des framesets, UIWebView ne garde pas la trace de l'historique de navigation pour les transitinos de page dans les frames, ce qui peut être une fonctionnalité souhaitable. Il faut un peu de bricolage pour y parvenir.