ios - Quand devrions-nous utiliser des "binaires incorporés" plutôt que des "Frameworks liés" dans Xcode?



embedded-binary (2)

Il y a une bonne question sur la différence entre ces deux options comme décrit dans Link Binary avec les bibliothèques VS Embed Frameworks .

On dirait que nous avons des options pour les utiliser tous les deux, il suffit de se demander dans quel cas nous devrions mieux utiliser les binaires intégrés, ou plutôt que les frameworks liés.

Des exemples solides pour répondre à cela plus clair? Merci

https://ffff65535.com


En bref,

  • bibliothèques système, les lier;
  • Bibliothèques tierces, les incorporer.

Pourquoi?

  • Si vous essayez d'intégrer des bibliothèques système, vous ne les trouverez pas dans la liste déroulante.
  • Si vous liez des bibliothèques tierces, vous aurez probablement un plantage.

La question que vous avez liée fait référence à la fonctionnalité "Link Binary With Libraries", qui est quelque peu différente d'un binaire intégré.

"Link Binary with Libraries" signifie ce que vous attendez d'un linkage: que le binaire soit une bibliothèque statique, une bibliothèque dynamique ou un framework, il sera lié à votre code objet au moment de la liaison après la compilation.

Quand vous pensez à un lien avec une bibliothèque statique, ce qui se passe est assez clair: l'éditeur de liens copie le code de la bibliothèque (par exemple libFoo.a ) dans votre binaire de sortie. Votre fichier de sortie augmente en taille mais n'a pas besoin de résoudre les dépendances externes au moment de l'exécution. Tout ce que votre programme doit exécuter (par rapport à la bibliothèque statique) est présent après sa construction.

Avec une bibliothèque dynamique (.dylib, ou une structure fournie par le système), on s'attend à ce que la bibliothèque que vous liez soit présente quelque part dans le chemin du chargeur de bibliothèque dynamique du système lorsque vous exécutez votre programme. De cette façon, vous n'avez pas le temps de copier toutes les bibliothèques externes tierces dans votre binaire, et tous les différents programmes sur un ordinateur qui lient aussi cette bibliothèque seront en mesure de le trouver, ce qui économise un minimum d'espace disque, mais aussi l'espace mémoire potentiel, en fonction de comment et où le système met en cache les bibliothèques.

Un framework ressemble beaucoup à une bibliothèque dynamique, mais peut contenir des ressources dans sa structure de répertoires (images, audio, autres frameworks, etc.). Dans ce cas, un simple fichier de bibliothèque statique ou un fichier .dylib ne le coupera pas. Vous devrez peut-être lier un framework juste pour pouvoir trouver ce dont il a besoin pour fonctionner correctement.

Lorsque vous vous connectez à un framework tiers (dites quelque chose que vous avez téléchargé depuis github et que vous avez construit vous-même), il se peut qu'il ne soit pas présent sur le système sur lequel vous avez l'intention de tourner. Dans ce cas, vous ne liez pas seulement le framework, mais vous l'intégrez également dans votre bundle d'application en utilisant la phase "Copy Frameworks". Lorsque votre programme s'exécute, l'éditeur d'exécution (alias le résolveur) cherchera dans votre bundle en plus du chemin du chargeur système, trouvera le framework incorporé et le liera pour que votre application dispose du code dont elle a besoin pour fonctionner.

Enfin, ce qui est correctement un "binaire intégré" est un exécutable que vous intégrez tous deux dans votre paquet d'application via une phase de copie de fichiers, et que vous exécutez vous-même, peut-être avec un appel à popen() ou similaire. Le fichier binaire intégré peut être appelé par votre programme, mais il n'est pas lié à celui-ci. C'est une entité entièrement externe (comme les programmes dans le répertoire /bin ).

En pratique, pour les bibliothèques et les frameworks fournis par le système, vous les lierez et c'est tout ce que vous devez faire.

Si vous avez besoin de lier une bibliothèque que vous avez construite et qui n'a pas besoin de ressources intégrées (c'est-à-dire qui ne nécessite pas l'existence d'une structure), vous pouvez simplement lier une bibliothèque statique. Si vous trouvez que vous avez plusieurs modules dans votre programme qui veulent utiliser le même code de bibliothèque, le convertir en un framework ou une bibliothèque dynamique et en enchaîner peut économiser de l'espace et peut être pratique (en particulier si l'utilisation de la mémoire est un problème).

Enfin, les frameworks peuvent inclure non seulement des ressources, mais aussi des en-têtes et / ou des fichiers de licence. L'utilisation d'un framework pour transmettre ces fichiers est en fait un mécanisme de distribution si pratique que vous voudrez peut-être incorporer un framework juste pour que ces éléments puissent être associés à votre binaire (par exemple, les conditions de licence peuvent rendre cela obligatoire).

--- MODIFIER ---

Adam Johns a posté la question suivante en commentaire:

C'est une excellente réponse. Il y a quelque chose que je suis encore un peu confus, cependant. Qu'est-ce que cela signifie d'exécuter le binaire vous-même? Voulez-vous dire simplement en utilisant le code du framework intégré? Je sais que vous avez mentionné popen (), mais vous dites que mon application appelle popen ()? Je ne sais pas vraiment ce que ça veut dire.

Je dis qu'un binaire intégré est juste un autre fichier de ressource dans votre paquet, comme un fichier audio ou une image, bien que le fichier soit à la place un outil de ligne de commande exécutable. La fonction popen() ( man popen partir de votre terminal pour en savoir plus) vous permet d'exécuter des programmes arbitraires à partir d'un autre programme en cours d'exécution. La fonction system() est une autre manière. Il y en a d'autres, et je donnerai ici un exemple historique qui pourrait rendre plus clair l'utilisation d'un binaire incorporé:

Comme vous le savez probablement, lorsque vous lancez une application sur Mac OS X, elle est lancée avec un ID utilisateur de l'utilisateur actuel. Sous la plupart des installations courantes, il s'agit de l'utilisateur admin utilisateur par défaut, à qui est attribué l'ID utilisateur 501 .

Sur les systèmes d'exploitation basés sur Unix, seul l'utilisateur root (ID utilisateur 0 ) a un accès complet à l'ensemble du système de fichiers. Parfois, il arrive qu'un programme d'installation lancé par l'utilisateur de bureau doit installer des fichiers dans un répertoire privilégié (les pilotes par exemple). Dans ce cas, le programme d'application doit transférer ses privilèges à l'utilisateur root afin qu'il puisse écrire dans ces répertoires restreints.

Pour faciliter cela dans les systèmes d'exploitation via OS X 10.7, Apple a fourni dans son API Authorization Services la fonction AuthorizationExecuteWithPrivileges() (ceci est maintenant obsolète, mais reste un exemple utile).

AuthorizationExecuteWithPrivileges() pris comme argument un chemin vers un outil de ligne de commande à exécuter en tant que root . L'outil de ligne de commande était un script shell exécutable ou un fichier binaire compilé que vous avez écrit pour exécuter votre logique d'installation. Cet outil a été installé dans votre ensemble d'applications, comme n'importe quel autre fichier de ressources.

Lorsqu'il est appelé, le système d'exploitation affiche une boîte de dialogue d'autorisation demandant le mot de passe de l'utilisateur (vous l'avez déjà vu!) Et, lorsqu'il est entré, exécute le programme en tant que root au nom de votre application. Ce processus est similaire à l'exécution d'un programme avec popen() vous-même, bien que popen() seul ne vous donne pas l'avantage d'une escalade de privilèges.





embedded-binary