carnage deployement
@importer
Membre
Bonsoir,
Je viens solliciter votre aide. J'ai peiné pour mettre mon appli sur l'iPhone, et là ... c'est le drame. Elle fonctionnait nickel chrome sur le Mac mais là c'est vraiment un carnage.Â
-Les mouvements sont plus que saccadés,
-le touch fonctionne en insistant vraiment,Edit: le touchMoved marche nickel, c'est le touch simple qui déboque
-une image initialement en alpha=0 et passant en alpha=1 progressivement, passe bien en alpha=1, puis disparait mystérieusement,
-l'alarme ne fonctionne plus.Edit: si elle fonctionne...
Sur Mac tout fonctionnait parfaitement, je ne comprend pas. D'ailleurs, au lancement de l'appli le GDB se lance (normal ou pas?!) et à la console il y a:
Avant déploiement, le projet a été compilé pour OS3 (ok), et les leak vérifiés avec Clang (ok).Le device est sous OS3 non jailbreaké
Savez vous d'où viens LE problème?
Je viens solliciter votre aide. J'ai peiné pour mettre mon appli sur l'iPhone, et là ... c'est le drame. Elle fonctionnait nickel chrome sur le Mac mais là c'est vraiment un carnage.Â
-Les mouvements sont plus que saccadés,
-le touch fonctionne en insistant vraiment,Edit: le touchMoved marche nickel, c'est le touch simple qui déboque
-une image initialement en alpha=0 et passant en alpha=1 progressivement, passe bien en alpha=1, puis disparait mystérieusement,
-l'alarme ne fonctionne plus.Edit: si elle fonctionne...
Sur Mac tout fonctionnait parfaitement, je ne comprend pas. D'ailleurs, au lancement de l'appli le GDB se lance (normal ou pas?!) et à la console il y a:
Loading program into debugger...<br />No symbol table is loaded. Use the "file" command.<br />No symbol table is loaded. Use the "file" command.<br /><br />tty /dev/ttys006<br />Program loaded.<br />target remote-mobile /tmp/.XcodeGDBRemote-135-53<br />Switching to remote-macosx protocol<br />mem 0x1000 0x3fffffff cache<br />mem 0x40000000 0xffffffff none<br />mem 0x00000000 0x0fff none<br />(gdb) run<br />Running...<br />[Switching to thread 10755]<br />[Switching to thread 10755]<br />(gdb) continue
Avant déploiement, le projet a été compilé pour OS3 (ok), et les leak vérifiés avec Clang (ok).Le device est sous OS3 non jailbreaké
Savez vous d'où viens LE problème?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Par contre je vois pas pour "No symbol table is loaded". mais ça m'a pas l'air si grave.
Enfin comme quoi, faut toujours tester son appli progressivement sur son iPhone Niveau fluidité je doute que tu puisses arranger ça à moins d'avoir peut-être un petit algo à améliorer.
Si tu parles du touch sur une UITableView, j'ai aussi remarqué le problème et ça vient de l'OS 3.0 apparemment.
Pour les mouvement en fait c'est des timer, je devrait les faire tourner plus souvent??
Bô je testerai demain, là je sature tellement j'ai eu du mal à exporter sur l'iPhone et tellement je suis déçu.
Bonne soirée
N'hésitez pas à me soumette vos réactions. Merci
Le mobile (iPhone en l'occurrence) a des contraintes fortes, tant en terme de performances (même si elles sont tout à fait honorables, si on fait ramer la bête avec des Timers qu'on lance toutes les microsecondes ou des calculs intensifs ou quoi, forcément...), de mémoire (beaucoup moins de RAM dispo qu'un ordi, et surtout pas de swap), ... et il faut aussi prendre en compte tout ça
Dans certaines applications, ça n'a pas forcément grande incidence si on ne sollicite pas plus que de raison le CPU ou la mémoire, mais dans certaines autres les applis auront la "place" de tourner sous émulateur car en réalité sous le capot c'est le CPU et la RAM du Mac qui est utilisée, mais sur iPhone les limitations vont se faire sentir. C'est pour ça qu'il faut toujours tester sur device aussi, d'ailleurs.
Pour palier à ça, ben y'a pas de miracle, faut apprendre à coder pour mobile : gestion plus poussée des ressources (relâcher la mémoire au plus tôt quand elle n'est plus nécessaire, etc), optimiser son code (entre autres code de dessin par exemple) si besoin, ne pas demander un framerate de folie mais un truc raisonnable (pas 150fps donc des timers à 1/150e de seconde pour afficher tes écrans, mais plutôt dans les 30 fps c'est bien suffisant en général), ce genre de choses.
Ou encore évidemment si tu redessines tout ton écran toutes les N secondes ou refait des calculs N fois inutilement, ça va se sentir dans les prefs de ton appli sur l'iPhone (alors que le CPU du Mac pourrait suivre, lui)... bref faut pas faire n'importe quoi et s'adapter à l'environnement mobile.
Donc après si ton appli lag à mort et détecte mal les touch & co, c'est d'une part parce que si le simulateur aide à se faire une idée des use cases et du comportement global d'une appli, ce n'est qu'un simulateur, et il a des différences avec un vrai devices (genre mémoire et CPU justement), mais aussi peut-être parce que tu n'as pas respecté les principes de base (genre ne pas appeller drawRect toi même mais setNeedsDisplay, on avait un post avec ce cas y'a pas si longtemps je crois).
C'est vrai que je release pas mal sur dealloc mais je pense que je peux pas releaser comme ça sinon ça va planter dés qu'on voudra faire une deuxième fois la même chose...Trop une usine à gaz mon appli
Bonne fin de soirée
- Laisser des NSLogs traà®ner c'est pas ça qui va non plus plomber ton appli au point de la faire ramer, sauf si t'en as 50 par seconde bien sûr, mais bon un ou 2 qui traà®nent par-ci par là ça va quoi
- Ne pas faire de release dans le dealloc n'est pas une solution. D'une part parce que ça risque d'introduire des fuites mémoires (j'ai dit qu'il fallait gérer efficacement la mémoire pour optimiser pour le développement mobile, j'ai pas dit qu'il fallait faire n'importe quoi ), et en plus ça ne changerait pas le problème (voire l'augmenterai si tu gardes trop de trucs en mémoire et que la RAM sature), faut trouver un compromis. Et de toute façon ça dépend du contexte de ton appli pour savoir ce qu'il est bon de garder en mémoire et ce qu'il est bon de décharger qd tu n'as plus besoin et recharger plus tard si de nouveau nécessaire.
Le fait de venir de C# et .NET n'y change pas grand chose : pour du dev sur Windows Mobile tu aurais sensiblement les mêmes problématiques, dès qu'on commence à faire une appli manipulant un peu de mémoire (quelques UIImages peuvent suffire parfois selon leur taille d'ailleurs) faut prendre en compte les contraintes mobiles, que ce soit un iPhone ou un autre.
Sinon si je suis bien votre propos, aux niveaux des images, il faut toujours prendre les plus petite possibles et dans la plus petite résolution possible?
Pour limiter les dégats, comment peut on faire pour que seule ma mainView soit chargée? En gros, ne charger ma settingsView que quand je flippe quand aller dessus.
Tu peux foutre un delegate dessus pour informer ta mainViewController que l'utilisateur a cliqué sur "Done" dans les settings et relacher "settings" à ce moment là .
Sinon, meme topo si tu bosses en mode "modal" pour ça. Sauf que pas besoin d'implémenter un mécanisme de delegate.
J'ai un seul .xib avec une windows pour 2 subclass de UIView (mainView et settingsView).
Et quand je lance l'appli bah j'ai des logs venant de la méthode awakeFromNib de ma mainView ET de settingsView ce qui indique qu'elles sont chargées en même temps. Ce serait quoi le moyen pour n'en charger qu'une? et pour charger la deuxieme à la demande?
Excusez moi d'être une quiche
@apocalyspo
Mes ombres? c'est des images qui sont légèrement décalées
-mainView  -> 600ko
(un fond de 400ko immobile et que des éléments entre 8 et 20ko mobiles)
-settingsView -> 1,9Mo
tout en png.
C'est que la mainView qui débloque.
@Eaglelouk
J'aimerais bien mais je n'en ai qu'un :-\\
Ya juste des grosses différences entre le simulateur et le device.
J'explique: J'avais un problème avec le player, impossible de corriger dans le code, franchement je voyais pas comment faire. Hé ben là ça fonctionne niquel sur le device sans changer quoi que ce soit.
Pour l'animation il n'y a pas de lag mais plutôt un défaut d'animation: concrètement, quand je lance l'appli, mes image se positionnent d'une certaine façon, puis une fois positionnées, l'animation se lance avec un timer, toute les secondes, et l'anim dure 1 seconde à chaque tour. Ce qui se passe sur le device: le positionnement se fait correctement mais lors de l'animation ça flashe trés souvent et on revoit l'image sur sa position initiale.
C'est pas facile à expliquer, j'espère que vous avez compris ce que je voulais dire. Et ce n'est absolument pas normal, on devrait avoir un mouvement on ne peut plus fluide (ce que j'avais sur le simu)
Dernier point, initialement juste le touchUp est "actif" dans mon appli, le touchesMoved le devient quand un Bool devient YES. Dés que ce Bool passe à YES sur le device, hé ben le touchUp est trés mal intercepté.
C'est quand même le coup du player qui me fait me rendre compte que ça ne venait pas de moi :crackboom:-