Pourquoi les appareils de développement vous donnent-ils plus de ressources qu'un appareil classique?

9

J'ai créé une application qui fonctionne sur mon iPod Touch de 4e génération et sur mon iPod touch de 5e génération.

Nous étions sur le point de publier, lorsque nous avons trouvé un crash qui se produit après qu'un appareil non développeur exécute l'application *.

L'idée est venue qu'un appareil enregistré en tant que «appareil développeur» donne à votre application plus de ressources à utiliser. Cela ne me semble pas juste, car je ne pouvais penser à aucune raison qui existerait - j'ai l'impression que c'est plus probablement un problème avec le profilage de construction ou d'approvisionnement.

Cependant, cela a déclenché une discussion. Pourquoi des appareils tels que des kits de développement de console de jeu, des appareils qui ont plus de capacités que la plate-forme cible, existent-ils en premier lieu? Bien sûr, il est agréable de tester un programme sous contrainte, mais une représentation plus précise de la plate-forme cible n'aurait-elle pas plus de sens?

TL; DR - Pourquoi les kits de développement ont-ils plus de ressources que les plateformes cibles?

* Avec un appareil non développeur étant> 3ème génération. Appareil iOS qui télécharge l'application depuis notre serveur, pas directement depuis un ordinateur sur lequel l'application et le xcode sont installés.

_{Notez qu'il y a une autre question qui se lit similaire, mais elle est en fait différente, car cette autre question concerne le simulateur, et je comprends qu'il existe des différences énormes entre l'utilisation d'un simulateur et un appareil réel.}

ios development

— Katamaritaco
source

7

@gnat - Ce message n'est pas un double de Pourquoi il est nécessaire de tester mon application iPhone . Je comprends qu'il y a d'énormes différences entre l'utilisation d'un simulateur et d'un appareil réel ...

— Katamaritaco

8

L'environnement de développement (pour n'importe quoi - que ce soit une application Java autonome, un environnement mobile ou un périphérique intégré) a généralement la capacité de faire un débogage à distance, une journalisation améliorée et d'autres types d'introspection de l'environnement (on ne veut généralement pas pour ajouter tous les crochets d'un analyseur logique sur un périphérique intégré de production).

Ces choses supplémentaires nécessitent des ressources supplémentaires. L'ouverture d'un débogueur distant contre un vm ou un autre environnement distant nécessite des ressources à l'autre extrémité. Dans le domaine très limité du mobile, il est possible que ces ressources supplémentaires le placent au-dessus de la limite accordée à une application standard. Ainsi, plus de ressources sont accordées à l'environnement de développement afin qu'il n'atteigne pas la limite de ressources lorsqu'il commence à effectuer une journalisation ou un débogage supplémentaire.

Cela va plus loin au point que vous devez toujours tester quelque chose dans un miroir de l'environnement de production. Il ne suffit pas de croire qu'il fonctionne sur les machines du développeur avec tous leurs réglages et différentes variables pour vérifier qu'il fonctionne correctement en production.

1

Oui, QA doit toujours tester dans un environnement d'utilisateur final et non dans un environnement de développement.

— 17 du 26

Il y a quelques années, j'étais impliqué dans un projet qui devait développer deux cartes CPU complètement différentes. L'ingénieur matériel qui a fait la carte avec laquelle j'étais très impliqué a mis un tas de connecteurs de test sur sa carte, souscrivant une assurance pour la phase de débogage, pour s'assurer que nous pourrions tester quoi que ce soit. Il a pris beaucoup de statique pour gaspiller des biens immobiliers et de l'argent. L'autre type n'a pas gaspillé autant d'argent et de biens immobiliers. Chose amusante: nous n'avons jamais eu besoin des connecteurs de notre carte. L'intégration de l'autre carte aurait été un véritable cauchemar, car RIEN NE POURRAIT ÊTRE PROBÉ. Pensez "assurance".

— John R. Strohm

@ JohnR.Strohm Pour un développement, le sondage est bon. Tout ce que j'essaie de dire, c'est que s'il était conçu pour avoir une carte de production différente de la carte de développement, il faudrait également tester à nouveau avec celle de production après avoir réussi avec celle de développement (et sonder si nécessaire).

Cela a beaucoup de sens pour un «kit de développement» typique. Par curiosité, dans le cas d'iOS, tout iDevice peut être utilisé comme un «appareil de développeur». Comment peut-il y avoir une différence avec deux pièces du même matériel?

— Katamaritaco

1

@Katamaritaco simplement parce qu'il s'agit du même appareil physique ne signifie pas que l'application dispose des mêmes autorisations dans iOS. La possibilité d'effectuer des opérations telles que le débogage à distance peut modifier les ressources auxquelles une application a accès.

5

Il vous permet de créer une preuve de concept gourmande en ressources que vous pourrez ensuite optimiser.

Cela n'a aucun sens de planter une application car elle dépasse la limite de mémoire de 5 octets (ce qui peut être résolu en définissant l'optimiseur pour économiser de l'espace dans la version mais vous exécutez une version de débogage),

afficher un avertissement dans le journal lorsque vous dépassez la limite de consommation pendant le test sera agréable ici.

— monstre à cliquet
source

1

C'est en partie une question de «confiance». Les développeurs sont supposés savoir ce qu'ils font et ont donc un accès sans restriction à l'appareil et à toutes ses ressources. Cela peut être d'une grande aide pour les petites entreprises et les équipes de développement, où les ressources inutilisées sont des ressources gaspillées.

Dans un environnement d'entreprise plus vaste, ou en particulier le grand public, ce type d'accès devient un handicap, en raison de problèmes de sécurité et de la nécessité de bien jouer avec d'autres applications qui nécessitent également des ressources.

Ce n'est pas vraiment une nouvelle idée. J'ai deux machines au travail. Sur ma machine de développeur, j'ai un accès administratif, mais il est isolé d'Internet. Mon autre machine, que j'utilise pour le courrier électronique, Office et l'accès à Internet, ne me donne même pas la possibilité d'installer des programmes.

C'est pourquoi vous devez tester votre application sur un appareil non développeur avant de la déployer, pour vous assurer qu'elle se comporte correctement. :)

— Robert Harvey
source

0

Avec iOS, un appareil activé pour le développement vous permet d'exécuter directement des versions de débogage, qui peuvent contenir un ensemble différent de bogues du compilateur qu'une version de version, ainsi que d'exécuter des applications sous un nœud de débogage, ce qui peut modifier subtilement le calendrier des threads et l'utilisation de la mémoire, qui peut également afficher / masquer divers problèmes de thread et de fuite de mémoire.

Un périphérique de développement ne serait pas d'une grande utilité sans capacité de débogage, et un périphérique utilisateur avec capacité de débogage présenterait un problème de sécurité des applications et des données d'application (plus) grave.

— hotpaw2
source