Est-ce que NSTimer est impacté par la vitesse du processeur, les différentes générations d'iPhone, etc.?

Question

Je suis en train de mettre en œuvre une méthode de compte à rebours dans mon jeu, qui utilisera un compte à rebours de 15 secondes. J'ai cherché différentes façons de le mettre en œuvre et je crois que NSTimer est la meilleure solution.

Cependant, quelqu'un m'a dit que cela peut être impacté par la vitesse du processeur, etc. et ma question est de savoir si c'est vrai et si oui, comment y remédier ?

J'ai vu ceci : NSTimer mais je ne comprends pas pleinement l'impact de cela.

Existe-t-il un autre moyen de garantir 15 secondes de temps d'arrêt sur tous les appareils ?

Answer 1

Je ne comprends pas votre dernière phrase...

Cependant, je crois que vos amis ont raison de dire que c'est légèrement différent par rapport au véritable compte à rebours des secondes, mais je vous assure que la différence est tellement minime qu'elle n'est pas perceptible, surtout pour un jeu.

La raison de la différence est que vous avez défini un NSTimer pour s'exécuter en une seconde, lorsqu'il s'exécute, il met à jour le compte à rebours à l'écran puis se répète. Je suppose que le NSTimer ne commence à se répéter qu'après avoir terminé l'exécution de votre méthode, donc chaque seconde de NSTimer est légèrement plus longue qu'une seconde réelle.

Apple peut être un pas en avant par rapport à moi et invoque la répétition avant l'exécution, cependant, je ne suis pas sûr.

De toute façon, comme je l'ai dit, sauf si vous faites quelque chose de majeur autre que simplement mettre à jour l'écran chaque seconde, vos utilisateurs ne devraient pas remarquer de différence du tout.

Answer 2

NSTimer devrait convenir pour la plupart des fins. Ce ne sera pas exact - la période sera légèrement plus longue que ce que vous avez défini, mais dans de bonnes conditions seulement de très peu - pensez aux millisecondes. Cependant, NSTimer se déclenche via une boucle de runloop, donc sa précision dépend de cette boucle de runloop qui ne doit pas être occupée. Vous pouvez minimiser les problèmes en ayant une boucle de runloop dédiée, sur son propre thread, même si vous verrez toujours la période de votre minuteur s'étendre légèrement si le système est occupé.

Par conséquent, bien qu'il n'y ait pas de relation innée entre la vitesse du CPU et d'autres facteurs similaires, un matériel plus rapide pourra mieux suivre en raison du fait qu'il n'est pas occupé aussi souvent.

Notez également qu'un NSTimer répétitif ne décalera pas de phase - il sera aussi précis réglé sur un intervalle de 1s que sur 15s. La seule mise en garde est que si votre gestionnaire est toujours en cours d'exécution lorsque la prochaine exécution devrait avoir lieu, cette exécution ne se produira pas du tout. Par exemple, si vous prenez 1,1 seconde, l'intervalle entre les déclenchements passera à 2s.

Une alternative aux runloops et aux NSTimers est dispatch_after. Il n'est pas susceptible d'être plus précis cependant, et son patinage dépend toujours de la file d'attente cible (probablement l'une des files d'attente concurrentielles par défaut) qui ne doit pas être occupée lorsqu'elle se déclenche.

Answer 3

Théorie : Le NSTimer n'est pas directement affecté par la vitesse du processeur. Un minuteur fonctionnant pendant 1 minute sur un appareil de génération 2 devrait également représenter 1 minute sur un appareil beaucoup plus récent.

Maintenant, c'était la théorie :), mais en réalité, la vitesse du processeur affecte non seulement vos minuteurs, mais la vitesse générale de votre application (par exemple, à quelle vitesse vos vues changent, à quel moment votre musique commence après avoir appuyé sur un bouton, etc). Le seul (ou meilleur test) est de tester votre application de manière répétée sur les types d'appareils que vous allez cibler. Testez tôt, testez souvent :)

Vous ne pouvez pas (selon mes expériences) garantir exactement le temps T sur n'importe quel appareil. Vous pouvez cependant obtenir des temps qui se rapprochent en moyenne de votre temps attendu T.