Néanmoins la partie "Perfs en deca de tout, UI pourrie a chier" pour Android, ça me fait un peu penser à la méthode Coué non ?
Non, pas methode coue.
Le meilleur exemple, c'est le scroll sur une table bien chargee.
Ya deux aspects en fait:
- la technique pure. Le scroll est saccade, ya une bonne raison, c'est le gc qui par design va creer des pauses, et les pauses sur un thread ui, meme de 50ms, c'est mauvais. En plus de ca, le framework d'android est clairement pas aussi optimise
- le design. Le scroll sous iOS a une deceleration qui est tres raffinee, et qui a un feeling tres naturel.
Chrome est notoire pour etre mauvais sur des pages costaud, la ou safari rend et scroll tout ca sans broncher, les doigts dans le nez. J'ai vu une video recemment qui comparait techcrunch sur un android top of the line et un iphone 4 (donc "vieux"), c'etait assez flagrant - la version android etait a peine utilisable.
Apres, on peut parler d'autre aspects.
iOS a une gestion de la memoire particulierement adaptee a des peripheriques limites. Leur modele "ton process est (presque) tout seul, fait toi zizir, mais souviens toi que plus tu bouffes, et plus t'as de chances de te fiare tuer en background" marche tres bien. En plus dr ca, ils ont ajoute un systeme de recuperation des vues inutilisees qui permet de reellement droper 30 a 40% de la ram utilisee pour rien (mesuree avec mes petites mimines a moi).
Ce qui explique pourquoi android a besoin d'autant de ram la ou un ipod avec 256Mo s'en sort admirablement (meme un 3g avec 128Mo s'en sort bien en fait, ce qui bloque, c'est le cpu).
Apres, on peut parler des animations, ca rejoint les remarques sur le scroll plus haut. Une pause gc pendant ton animation et paf l'animation. Meme si la pause ne dure que 50ms.
Tant qu'on parle des animations, parlons de l'api. ICS introduit tout jute une api qui ressemble de loin a ce qu'apple a introduit dans iOS 3 (pardon, iphone os 3), qui est pratique pour des ptits truc mais devient tres vite un enfer pour des trucs un tant soit peu complexe.
Et il se trouve que ces animations sont un point essentiel pour tout ce wui est navigation et "ergonomie". En gros, ca permet au con qui est devant l'ecran de comprendre ce qu'il se passe.
On peut aussi parler de la duree de vie de la batterie (oui, ca fait partie des perfs aussi). Ok, iOs a introduit un vilain bug qui bouffait tout en 12 heures. Mais c'est corrige depuis qq jours.
Tout le monde gueulait sur apple sur le multi tache, le jour ou google w introduit le multitache, tous ces gens se sont rendus compte pourquoi apple ne le faisait pas: c'est pas faisable sur un pauvre telephone sans ruiner les perfs/la batterie.
On peut parler du systeme push. Oui, celui d'iOS est contraignant, mais il marche foutrement bien, et surtout, il ya une seule connexion push ouverte pour tout le telephone. Sur android, tu veux faire pareil, ben... Tu peux pas vraiment, ya pas de push. Du coup tout le monde implemente son propre push (une connexion par appli) ou fait du polling (bye bye la batterie, bonjour facture att).
Et je parle meme pas du bordel a implementer un push cote serveur.
Apres, ya l'api en general, qui est extremement puissante tout en restant simple pour les cas d'utilisations simples (oui, on sort des perfs la).
Jette un oeil a l'api UITableView sur les docs apple (gratos avec un email), tu comprendras ce que je veux dire.
Ou encore UIViewController.
Ya certes des points relou (le cote asynchrone UIWebView est vite chiant quand on a autre chose qu'une webview a l'ecran et le bordel que c'est pour la dimensioner pour l'empecher de scroller est tres "non applish", amis ca reste un moindre mal).
Apres, on peut aussi parler de l'utilisation de Java qui doit bien etre le pire langage de la creation pour faire de l'UI. Pas de closure... Pas de closures!
Objc avait le probleme de la gestion de la memoire, certes. Mais cette gestion devient simplissime dans 99% des cas quand tu suis les conventions retain/release et que tu utilises des properties. Et apple vient d'envoyer le probleme aux abimes avec ARC de toutes facons. Pas de gc, pas de gestion manuelle de memoire.
Ya une bonne raison pour laquelle tout ce qui sort dans le monde mobile sort sur iphone d'abord, et apres sur android (si ca sort sur android).
Android a une part de marche consequente, largement assez grande pour justifier une equipe qui bosse dessus, et pourtant, ca se fait pas.
Ou sont les applis tablettes android? (non, pas la, non)
Ou est, par exemple, garageband pour android? Un editeur de video? Celui d'ios tourne sur un A4 et 256 de ram, android a mieux niveau hard.
Pourquoi c'est pas possible de faire pareil sur android, si les perfs soft sont les memes que sur ios?
D'un point de vue developeur, je suis pas sur que le loup soit celui que tu penses dans ta fable.
Et entre nous, une tablette sans appli, elle a beau etre "libre" (encore que , faudrait deja avoir le code honeycomb pour etre libre), ca sert pas a grand chose.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bravo
Posté par pasScott pasForstall . En réponse au journal Barnes & Noble résiste à M$. Évalué à 4.
Non, pas methode coue.
Le meilleur exemple, c'est le scroll sur une table bien chargee.
Ya deux aspects en fait:
- la technique pure. Le scroll est saccade, ya une bonne raison, c'est le gc qui par design va creer des pauses, et les pauses sur un thread ui, meme de 50ms, c'est mauvais. En plus de ca, le framework d'android est clairement pas aussi optimise
- le design. Le scroll sous iOS a une deceleration qui est tres raffinee, et qui a un feeling tres naturel.
Chrome est notoire pour etre mauvais sur des pages costaud, la ou safari rend et scroll tout ca sans broncher, les doigts dans le nez. J'ai vu une video recemment qui comparait techcrunch sur un android top of the line et un iphone 4 (donc "vieux"), c'etait assez flagrant - la version android etait a peine utilisable.
Apres, on peut parler d'autre aspects.
iOS a une gestion de la memoire particulierement adaptee a des peripheriques limites. Leur modele "ton process est (presque) tout seul, fait toi zizir, mais souviens toi que plus tu bouffes, et plus t'as de chances de te fiare tuer en background" marche tres bien. En plus dr ca, ils ont ajoute un systeme de recuperation des vues inutilisees qui permet de reellement droper 30 a 40% de la ram utilisee pour rien (mesuree avec mes petites mimines a moi).
Ce qui explique pourquoi android a besoin d'autant de ram la ou un ipod avec 256Mo s'en sort admirablement (meme un 3g avec 128Mo s'en sort bien en fait, ce qui bloque, c'est le cpu).
Apres, on peut parler des animations, ca rejoint les remarques sur le scroll plus haut. Une pause gc pendant ton animation et paf l'animation. Meme si la pause ne dure que 50ms.
Tant qu'on parle des animations, parlons de l'api. ICS introduit tout jute une api qui ressemble de loin a ce qu'apple a introduit dans iOS 3 (pardon, iphone os 3), qui est pratique pour des ptits truc mais devient tres vite un enfer pour des trucs un tant soit peu complexe.
Et il se trouve que ces animations sont un point essentiel pour tout ce wui est navigation et "ergonomie". En gros, ca permet au con qui est devant l'ecran de comprendre ce qu'il se passe.
On peut aussi parler de la duree de vie de la batterie (oui, ca fait partie des perfs aussi). Ok, iOs a introduit un vilain bug qui bouffait tout en 12 heures. Mais c'est corrige depuis qq jours.
Tout le monde gueulait sur apple sur le multi tache, le jour ou google w introduit le multitache, tous ces gens se sont rendus compte pourquoi apple ne le faisait pas: c'est pas faisable sur un pauvre telephone sans ruiner les perfs/la batterie.
On peut parler du systeme push. Oui, celui d'iOS est contraignant, mais il marche foutrement bien, et surtout, il ya une seule connexion push ouverte pour tout le telephone. Sur android, tu veux faire pareil, ben... Tu peux pas vraiment, ya pas de push. Du coup tout le monde implemente son propre push (une connexion par appli) ou fait du polling (bye bye la batterie, bonjour facture att).
Et je parle meme pas du bordel a implementer un push cote serveur.
Apres, ya l'api en general, qui est extremement puissante tout en restant simple pour les cas d'utilisations simples (oui, on sort des perfs la).
Jette un oeil a l'api UITableView sur les docs apple (gratos avec un email), tu comprendras ce que je veux dire.
Ou encore UIViewController.
Ya certes des points relou (le cote asynchrone UIWebView est vite chiant quand on a autre chose qu'une webview a l'ecran et le bordel que c'est pour la dimensioner pour l'empecher de scroller est tres "non applish", amis ca reste un moindre mal).
Apres, on peut aussi parler de l'utilisation de Java qui doit bien etre le pire langage de la creation pour faire de l'UI. Pas de closure... Pas de closures!
Objc avait le probleme de la gestion de la memoire, certes. Mais cette gestion devient simplissime dans 99% des cas quand tu suis les conventions retain/release et que tu utilises des properties. Et apple vient d'envoyer le probleme aux abimes avec ARC de toutes facons. Pas de gc, pas de gestion manuelle de memoire.
Ya une bonne raison pour laquelle tout ce qui sort dans le monde mobile sort sur iphone d'abord, et apres sur android (si ca sort sur android).
Android a une part de marche consequente, largement assez grande pour justifier une equipe qui bosse dessus, et pourtant, ca se fait pas.
Ou sont les applis tablettes android? (non, pas la, non)
Ou est, par exemple, garageband pour android? Un editeur de video? Celui d'ios tourne sur un A4 et 256 de ram, android a mieux niveau hard.
Pourquoi c'est pas possible de faire pareil sur android, si les perfs soft sont les memes que sur ios?
D'un point de vue developeur, je suis pas sur que le loup soit celui que tu penses dans ta fable.
Et entre nous, une tablette sans appli, elle a beau etre "libre" (encore que , faudrait deja avoir le code honeycomb pour etre libre), ca sert pas a grand chose.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.