Android <2.2 c'est 10% de part de marché, et certainement pas la part de marché à l’affût de la moindre application.
Ben ça change pas grand chose au problème, t'as une appli qui peut pas tourner si tu veux supporter tout le monde. On revient a la fragmentation.
C'est pas comme si tout chez Google étant en Labs mais presque ... C'est expérimental par rapport à quoi ? (si c'est juste parce que c'est du Labs, ça tient de la mauvaise foi ...)
Ca a l'air d'avoir change dpeuis que j'avais zieute ca la dernière fois (genre avril ou mai). En gros c'était "on laisse rentrer qui on veut, c'est expérimental alors gueulez pas si ça marche mal".
Ca a l'air plus ouvert, mais toujours est il que ça reste du google labs. Comprendre par la, pas "beta" a la gmail ou en fait c'est production ready depuis 4 ans.
Elles ne sont pas notifiées, juste libérées. Ce qui permet d'éviter que le dév fasse de la merde, donc ça m'intrigue assez, c'est un peu dans le sens opposé à d'habitude où chez Google ils laissent le max de liberté au dév, et où ça se retourne contre eux. Sauf que là ça se retourne pas contre Apple ?
Ben ouais. C'est bien ça le pb. Et c'est bien ce que je dit.
Ne pas pouvoir dropper ses vues inutilisées, ça finit par faire le porc en cpu. L'appli sur laquelle je bosse maintenant a en gros 6 Mo de données en ram. Le reste, c'est de l'UI. Sur une vue costaud, on passe d'un coup de 40Mo d'occupation a 20. Très précisément parce que l'os envoie un signal "oulalala, fait gaffe" et d'un coup paf, tu recupere la moitié de ce que tu bouffais.
Qu'est-ce que j'en sais ? c'est le GC qui s'amuse
Le GC va certainement pas "s'amuser" a récupérer des trucs qui sont references par ailleurs. C'est pas un bâton magique le GC, si ton objet est reachable depuis ton code, il va rien libérer du tout.
Bah ... euh ... l'activité a sa fonction onCreate() d'appelée, 'fin le comportement auquel on pourrait s'attendre quoi.
Je suppose que c'est que l'activité complete qui est recreee, ie apres avoir tuée par le système. Different de "je vais sur la vue A, la vue B, la vue C, puis l'os me dit de dropper les vues A et B, puis je reviens a B et je recree la vue correspondante."
alors que dans certains cas avec ARC tu peux te retrouver à être bloquer à attendre que la mémoire soit libérée.
Comment ça, bloque a attendre que la mémoire soit libérée?
Je suis pas sur que t'ai compris comment ça marche ce truc.
T'attends rien du tout. Si la mémoire est pas libérée, c'est qu'elle est toujours referencee. Si elle est referencee, elle est utilisée. Si elle est utilisée, y'a intérêt a ce qu'elle soit pas libérée.
ARC ne change strictement rien a la facon mémoire dont la memoire est geree en objc. Ca permet juste de transférer ce boulot du dev vers le compilateur.
Notamment, il faut toujours suivre les conventions de nommage (init/create/copy etc).
C'est justement la ou l'approche d'Apple est magnifique. Ils ont réussi a se debarraser de la gestion manuelle dans 99.99% des cas (oui, il reste toujours qq endroits ou il faut faire le boulot a la main, notamment dans les bridges Carbon/Cocoa) sans pour autant implementer un GC.
Le reference counting d'objc n'est PAS un GC et n'a d'ailleurs rien a voir avec ce qu'on appelle couramment reference counting.
Chaque objet a son propre ref count. En gros, [[NSObject alloc] init] et le ref count est a 1.
Ensuite, a chaque envoi du message retain, le ref count monte.
A chaque envoi du message release, il descend.
Quand il arrive a 0, l'objet se desalloue tout seul.
Par dessus, y'a des autorelease pool. En gros, un objet dans un autorelease pool va recevoir un release a la fin de la runloop (bon, techniquement, quand le pool est drainé, mais en pratique, c'est ce qu'il se passe). Ca permet de créer un objet sans en devenir le proprio et sans qu'il disparaisse juste apres l'avoir cree.
Ya pas de process qui inspecte la heap et qui compte les references des objets pour savoir s'il faut desallouer ou pas. Ca reste une gestion purement manuelle, c'est juste qu'il y'a un outil foutrement pratique, double de conventions de codages très fortes permettant de savoir si l'objet qu'on reçoit est retained ou autoreleased.
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é à -5.
Ben ça change pas grand chose au problème, t'as une appli qui peut pas tourner si tu veux supporter tout le monde. On revient a la fragmentation.
Ca a l'air d'avoir change dpeuis que j'avais zieute ca la dernière fois (genre avril ou mai). En gros c'était "on laisse rentrer qui on veut, c'est expérimental alors gueulez pas si ça marche mal".
Ca a l'air plus ouvert, mais toujours est il que ça reste du google labs. Comprendre par la, pas "beta" a la gmail ou en fait c'est production ready depuis 4 ans.
Ben ouais. C'est bien ça le pb. Et c'est bien ce que je dit.
Ne pas pouvoir dropper ses vues inutilisées, ça finit par faire le porc en cpu. L'appli sur laquelle je bosse maintenant a en gros 6 Mo de données en ram. Le reste, c'est de l'UI. Sur une vue costaud, on passe d'un coup de 40Mo d'occupation a 20. Très précisément parce que l'os envoie un signal "oulalala, fait gaffe" et d'un coup paf, tu recupere la moitié de ce que tu bouffais.
Le GC va certainement pas "s'amuser" a récupérer des trucs qui sont references par ailleurs. C'est pas un bâton magique le GC, si ton objet est reachable depuis ton code, il va rien libérer du tout.
Je suppose que c'est que l'activité complete qui est recreee, ie apres avoir tuée par le système. Different de "je vais sur la vue A, la vue B, la vue C, puis l'os me dit de dropper les vues A et B, puis je reviens a B et je recree la vue correspondante."
Comment ça, bloque a attendre que la mémoire soit libérée?
Je suis pas sur que t'ai compris comment ça marche ce truc.
T'attends rien du tout. Si la mémoire est pas libérée, c'est qu'elle est toujours referencee. Si elle est referencee, elle est utilisée. Si elle est utilisée, y'a intérêt a ce qu'elle soit pas libérée.
ARC ne change strictement rien a la facon mémoire dont la memoire est geree en objc. Ca permet juste de transférer ce boulot du dev vers le compilateur.
Notamment, il faut toujours suivre les conventions de nommage (init/create/copy etc).
C'est justement la ou l'approche d'Apple est magnifique. Ils ont réussi a se debarraser de la gestion manuelle dans 99.99% des cas (oui, il reste toujours qq endroits ou il faut faire le boulot a la main, notamment dans les bridges Carbon/Cocoa) sans pour autant implementer un GC.
Le reference counting d'objc n'est PAS un GC et n'a d'ailleurs rien a voir avec ce qu'on appelle couramment reference counting.
Chaque objet a son propre ref count. En gros, [[NSObject alloc] init] et le ref count est a 1.
Ensuite, a chaque envoi du message retain, le ref count monte.
A chaque envoi du message release, il descend.
Quand il arrive a 0, l'objet se desalloue tout seul.
Par dessus, y'a des autorelease pool. En gros, un objet dans un autorelease pool va recevoir un release a la fin de la runloop (bon, techniquement, quand le pool est drainé, mais en pratique, c'est ce qu'il se passe). Ca permet de créer un objet sans en devenir le proprio et sans qu'il disparaisse juste apres l'avoir cree.
Ya pas de process qui inspecte la heap et qui compte les references des objets pour savoir s'il faut desallouer ou pas. Ca reste une gestion purement manuelle, c'est juste qu'il y'a un outil foutrement pratique, double de conventions de codages très fortes permettant de savoir si l'objet qu'on reçoit est retained ou autoreleased.
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.