Zéro est Idéal

Idéalement, votre application de kiosque devrait utiliser 0% du CPU lorsqu'elle n'est pas utilisée activement. Il est peu probable que vous y parveniez sans effort considérable, mais même une cible d'utilisation de 5 à 10 % est bonne.

Avec une utilisation constante du CPU à 150%, l'application serait probablement considérée comme défectueuse par les examinateurs de l'App Store de Mac d'Apple - et par de nombreux clients.

Astuces: Décharger vers le bon framework

Si votre application de kiosque anime ou affiche du contenu en mouvement comme des publicités ou des films, faites autant que possible avec AVFoundation/QuickTime. Cela déchargera généralement le traitement vers le GPU et permettra au CPU de rester inactif.

Pour d'autres animations, assurez-vous d'adopter CoreGraphics et CoreAnimation. Ils amélioreront considérablement l'impact énergétique de votre application.

Guide de l'efficacité énergétique pour les apps Mac

Étudiez le Guide de l'efficacité énergétique pour les apps Mac d'Apple. L'introduction expose les intentions d'Apple:

Votre Obligation en tant que Développeur

Même de petites inefficacités dans les apps s'accumulent à travers le système, affectant significativement la durée de vie de la batterie, les performances, la réactivité et la température. En tant que développeur d'applications, vous avez l'obligation de vous assurer que votre application fonctionne aussi efficacement que possible. Utilisez des API recommandées afin que le système puisse prendre des décisions intelligentes sur la meilleure façon de gérer votre application et les ressources qu'elle utilise. Dans la mesure du possible, évitez les mises à jour inutiles de l'interface utilisateur et de l'E/S. Les opérations intensives en énergie doivent être sous le contrôle de l'utilisateur. Si un utilisateur lance un rendu iMovie important, un lot Automator, une conversion avec Compressor, ou une compilation Xcode, par exemple, l'utilisateur ne devrait pas être surpris si l'activité consomme de l'énergie. Efforcez-vous de rendre votre application absolument inactif lorsqu'elle ne répond pas à une entrée utilisateur.

Utilisez les outils de développement pour profiler l'impact énergétique de votre application et demandez de l'aide sur Stack Overflow pour trouver des moyens de réduire la charge CPU. Bonne chance!

150% du CPU total, bien sûr, ne serait pas seulement totalement inacceptable - mais physiquement impossible.
Je sais que la plupart des sportifs semblent penser qu'ils peuvent donner au moins 110% chaque fois qu'ils sont interviewés, mais personne ne leur a signalé les faits simples, je suppose ;-)

Le Moniteur d'activité montre l'utilisation du CPU des applications individuelles par cœur [y compris les cœurs virtuels], donc 150% correspondent réellement (pour un i7, avec 4 cœurs + hyperthreading) à 150 / 8 = 18,75% de la capacité totale de la machine.

Le total Système + Utilisateur en dessous des chiffres individuels est une représentation plus précise de l'utilisation globale de la machine et une addition rapide des chiffres vous donne une idée approximative de l'état réel des choses.

En prenant ceci comme exemple, les pourcentages visibles s'élèvent à environ 120, pourtant la figure Système + Utilisateur n'est que de 5,3%
Je dispose de 24 cœurs virtuels [2 x 6-core CPUs + hyperthreading] donc 120 / 24 = 5 [assez proche pour prendre en compte les processus plus bas dans la liste]

À 18,75% de la capacité totale de la machine, je ne vois pas que cela vaille la peine d'optimiser - à moins qu'un autre processus nécessite une portion significative de la capacité restante.

Sauf si vous avez un problème, ne faites pas d’optimisation prématurée serait mon conseil. Le matériel fonctionnera à 100 % d'utilisation (ou 800 % d'un seul thread dans le cas de votre matériel) sans aucun effet néfaste et sauf si vous avez des effets bloquants - vos animations et fonctions du kiosque pourraient même ne pas se dégrader lorsque le CPU est totalement occupé 24/7.

S'il y a des choses faciles à faire pour réduire l'utilisation du CPU, allez-y, mais le i7 a 4 cœurs physiques et calcule la charge du CPU par rapport à 8 cœurs virtuels. Votre matériel va idéalement jusqu'à 800 % et vous êtes seulement à 150 % actuellement ? Il semble que vos spécifications pour le matériel sont largement surdimensionnées pour une situation d'utilisation unique de kiosque. Si vous avez choisi une pile technologique et êtes satisfait du contenu du kiosque en termes d'animation, de capacité à effectuer la tâche pour laquelle vous l'avez "embauché" - je ne me préoccuperais pas de certaines "meilleures pratiques" imposées de l'extérieur, même si c'est les directives d'Apple pour être un codeur efficace (qui sont EXCELLENTES en passant).

Sur n'importe quel système, vous ne voudrez pas dépasser 80 % d'utilisation si vous ne pouvez pas évaluer, mesurer, réagir et corriger les utilisations explosives. Il s'agit d'une ligne directrice, et bien sûr, quand vous pouvez faire mieux, vous devriez le faire.

Je suppose que vous avez réellement des outils d'accès à distance en place pour pousser les mises à jour et mesurer le CPU au fil du temps et réagir, mais l'interactivité du kiosque semble être faible sur la liste des priorités de "nous perdons de l'argent" lorsque le système ralentit.

• Combien de temps un utilisateur interagit-il avec le kiosque ?
• De l'argent est-il gagné ou perdu et à quel taux est-ce estimé ?
• Que se passe-t-il lorsque le système devient contraint par le CPU (en raison de processus en arrière-plan ou de modifications dans l'application) ?

Toute "meilleure pratique" est vraiment un point de départ pour évaluer les choses. Il n'y a aucune raison de ne pas laisser un ordinateur fonctionner à 100 % d'utilisation si le thread principal n'est pas bloqué et que le système dans son ensemble se dégrade de manière élégante.