carnage deployement

@importer@importer Membre
juillet 2009 modifié dans Apple Developer Programs #1
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:

Loading program into debugger...<br />No symbol table is loaded.  Use the &quot;file&quot; command.<br />No symbol table is loaded.  Use the &quot;file&quot; 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?

Réponses

  • 07:45 modifié #2
    Le log est totalement normal.
    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 :D 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.
  • @importer@importer Membre
    07:45 modifié #3
    Le touch c'est sur la mainView qui contient une imageView qui recouvre tout. C'est bizarre pcq le touch est mal intercepté mais le touchMoved fonctionne nickel (j'ai 2 méthodes différentes sur les 2 évènement). L'image qui disparait, ça peut venir de quoi?
    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
  • AliGatorAliGator Membre, Modérateur
    07:45 modifié #4
    Voilà  pourquoi l'on dit que lorsqu'on développe sur iPhone (ou mobile), faut pas croire que c'est du tout cuit et que c'est le même process que le dev sur Mac (ou PC).
    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).
  • @importer@importer Membre
    07:45 modifié #5
    ouahah, ça fait peur tout ça. C'est vrai que je ne suis pas habitué à  ce genre de développement (à  la base je viens de C#.Net...). Est ce possible que les problèmes que je rencontre viennent (en partie, totalement?) du fait qu'il me reste 2-3 log qui se baladent à  chaque seconde? n'ayant jamais eu ce problème auparavant je n'y aurais même pas songé mais bon, parraitrait que.
    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 :p
    Bonne fin de soirée
  • AliGatorAliGator Membre, Modérateur
    07:45 modifié #6
    Bah heu :
    - 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 :D), 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.
  • @importer@importer Membre
    07:45 modifié #7
    Conclusion: me plonger dans le "memory management" :-\\
  • GreensourceGreensource Membre
    07:45 modifié #8
    Prend ça avec le sourire au contraire, tu sera bien plus fier de toi avec un code propre.

    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?
  • @importer@importer Membre
    07:45 modifié #9
    Est ce que mon appli lag du fait qu'il y a 11 UIImageView qui se superposent?? J'espère que non parce que je ne peux pas les enlever sinon l'appli n'a plus aucun sens. Sur ces 11 éléments 6 (3 éléments + leur ombre) sont en mouvement en permanence (géré par 1 timer lancé sur quasi sur awakeFromNib(le timer tourne toutes les secondes)).

    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.
  • 07:45 modifié #10
    Bha à  chaque fois que l'user clique sur "Settings" par exemple, tu alloc ton SettingsViewController.
    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.
  • apocaalypsoapocaalypso Membre
    07:45 modifié #11
    Tes ombres tu les fais comment ?
  • @importer@importer Membre
    juillet 2009 modifié #12
    Hmm ça m'a l'air simple comme ça, mais bon. Je ne passe pas par les viewController en fait :crackboom:-...
    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
  • apocaalypsoapocaalypso Membre
    07:45 modifié #13
    Ah d'accord, parce que moi c'était pareil, j'avais plein de boules (9) qui bougeaient sur l'écran que je dessinais avec le drawRect et j'utilisais CGContextSetShadowWithColor() pour leur faire un ombre. Et j'ai été très supris de voir à  quel point ça laggait ! Même en optimisant jusqu'au bout mon code. Mais dès que j'ai enlever le CGContextSetShadowWithColor() sur mes boules, tous les lags on disparus...
  • 07:45 modifié #14
    Sépare les deux XIB @importer, ça sera mieux et plus propre :D
  • @importer@importer Membre
    07:45 modifié #15
    ouahh je viens de regarder le poids total des images:
    -mainView     -> 600ko
    (un fond de 400ko immobile et que des éléments entre 8 et 20ko mobiles)
    -settingsView -> 1,9Mo :o
    tout en png.
    C'est que la mainView qui débloque.

    @Eaglelouk
    J'aimerais bien mais je n'en ai qu'un :-\\
  • 07:45 modifié #16
    Bha t'en fais 2! xD
  • @importer@importer Membre
    07:45 modifié #17
    Pfff, ça a rien à  voir avec ma gestion mémoire.
    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:-
  • allianallian Membre
    07:45 modifié #18
    Pourtant c'est fort risqué que cela vienne de la mémoire, moi aussi j'ai dév presque toute ma première appli sur le simulateur et le jour où j'ai testé sur le device j'ai eut les memes soucis, tout laggait à  non plus finir, j'ai donc du tout revoir en profondeur, et pour te dire certaines anim fonctionnent mieux sur le device maintenant donc t'en fais pas, tu va réussir.
Connectez-vous ou Inscrivez-vous pour répondre.