Pourquoi utilisons-nous use_frameworks dans CocoaPods?

108

J'ai utilisé plusieurs fois use_frameworksdans CocoaPods Podfile. Je me demande simplement pourquoi l'utilisons-nous? Je n'ai pas pu obtenir la réponse directe.

Exemple:

platform :ios, '8.0'
use_frameworks!

target "CityWhether" do
    pod 'Alamofire'
    pod 'SwiftyJSON'
end

— harikrista
source

1

Voulez-vous dire use_frameworks! AVEC le point d'exclamation? J'ai toujours été confus à ce sujet depuis! signifie NON.

— Gabriel Jensen

121

use_frameworksindique à CocoaPods que vous souhaitez utiliser Frameworks au lieu de bibliothèques statiques. Puisque Swift ne prend pas en charge les bibliothèques statiques, vous devez utiliser des frameworks.

Dans une autre réponse, j'ai expliqué les différences entre les bibliothèques statiques et les cadres:

Cadres Cocoa Touch

Ils sont toujours open-source et seront construits comme votre application. (Donc Xcode le compilera parfois, lorsque vous exécutez votre application et toujours après avoir nettoyé le projet.) Frameworks ne prend en charge qu'iOS 8 et plus récent, mais vous pouvez utiliser Swift et Objective-C dans le framework.

Bibliothèques statiques Cocoa Touch

Comme son nom l'indique, ils sont statiques. Ils sont donc déjà compilés, lorsque vous les importez dans votre projet. Vous pouvez les partager avec d'autres sans leur montrer votre code. Notez que les bibliothèques statiques ne prennent actuellement pas en charge Swift. Vous devrez utiliser Objective-C dans la bibliothèque. L'application elle-même peut toujours être écrite en Swift.

Sources: Mon autre réponse | Blog AddThis.com

— FelixSFD
source

3

Longue histoire sur les notes de publication blog.cocoapods.org/CocoaPods-0.36

— Jaime Agudo

7

les bibliothèques statiques prennent désormais en charge swift à partir de Xcode 9 beta 4 - CocoaPods est en cours de mise à jour pour prendre en charge cela, voir github.com/CocoaPods/CocoaPods/issues/6899

— JosephH

Sort et douce description.it est vraiment utile

— Piyush

76

use_frameworks!dit aux cabosses de cacao d'utiliser des bibliothèques dynamiques, et était très répandue à un moment donné en raison notamment de la rapidité ne prenant pas en charge les bibliothèques statiques, ce qui signifie qu'il n'y avait pas le choix - mais vous n'en avez souvent plus besoin use_frameworks!.

Depuis Xcode 9 beta 4 et CocoaPods 1.5.0, les bibliothèques statiques Swift sont désormais prises en charge. Le principal avantage est des temps de démarrage plus rapides des applications, en particulier si vous avez beaucoup de pods - iOS 10 et 11 ne sont pas les plus rapides lorsque vous avez de nombreux dylibs.

CocoaPods 1.5.0 a été libéré au début Avril 2018 , de sorte que vous devrez peut - être passer à l' obtenir: sudo gem install cocoapods.

Cependant, j'ai trouvé plusieurs pods qui ne fonctionnent pas correctement avec les bibliothèques statiques, donc votre kilométrage peut varier.

— JosephH
source

2

Je l'ai fait et j'ai rencontré les mêmes No such moduleerreurs. Est-ce un problème dans ces cocoapodes?

— Alper

3

J'ai dû ajouter use_modular_headers!à mon Podfile afin de le faire fonctionner avec des pods qui en ont vraisemblablement besoin mais qui ne l'activent pas encore eux-mêmes.

— Adrian

4

@JosephH "Le principal avantage est un temps de démarrage plus rapide des applications". Cela semble aller en contradiction avec la documentation de la bibliothèque dynamique d' Apple - qui fait la même déclaration des dll: "minimiser son utilisation de la mémoire une fois qu'elle est lancée accélère le lancement de l'application". Est-ce que l'implication ici que les dll entraîneront des temps de lancement plus rapides si la bibliothèque utilisée n'est pas requise au moment du lancement, ou c'est une bibliothèque populaire et donc déjà chargée en mémoire?

— TolkienWASP

3

@TolkienWASP Cette page semble concerner macOS plutôt qu'iOS. Mais, oui, si la DLL n'est chargée qu'après le démarrage, la DLL serait une victoire. Malheureusement, dans le cas iOS, dans les situations où j'ai vu toutes les DLL sont chargées avant la fin du lancement de l'application, ce qui ralentit les choses. Il y a au moins un discours de la WWDC sur l'optimisation des temps de démarrage des applications iOS et il a explicitement mentionné quelque chose dans le sens de s'assurer que vous n'avez pas plus de 3 ou 4 dll.

— JosephH

1

Je pense que c'est la vidéo référencée ci-dessus: developer.apple.com/videos/play/wwdc2016/406 Je vous encourage à utiliser la variable d'environnement DYLD_PRINT_STATISTICS pour mesurer la vitesse de lancement de votre application et voir ce qui est le mieux pour vous.

— iMacHumphries le

2

use_frameworksdéclare que vous souhaitez utiliser des frameworks dynamiques au lieu de bibliothèques statiques .

Avec la sortie de Xcode 9.0 et CocoaPods 1.5.0, vous pouvez utiliser des bibliothèques statiques avec swift si vous ne les utilisez pas use_frameworks.

Un problème avec use_frameworksest que tous vos frameworks dans Pods / Products sont des frameworks.

Voici un article connexe: Présentation de base des frameworks statiques et dynamiques sur iOS

— mistdon
source

4

> One performance with use_frameworks is that all your framework in Pods/Products is frameworks. Une performance quoi?

— Alex Zavatone

2

^[About] de Cocoapod use_frameworks!est responsable du type de binaire:

si use_frameworks!est présent -dynamic framework
si use_frameworks!n'est pas présent -static library

use_frameworks!a une réflexion dans Mach-O Type^[About] dans une cible correspondante du Podsprojet.

Chronologie:

CocoaPods 0.36 introduit use_frameworks!que vous deviez utiliser pour Swift Pod
CocoaPods 1.5.0 et Xcode 9 vous ont permis d'avoir le choix

[Vocabulaire]

— yoAlex5
source

-1

Ajouter

use_frameworks!

dans le Podfile signifie que nous voulons que les frameworks listés soient installés dynamiquement à la place en tant que frameworks statiques.

— Chiara
source

Merci, mais veuillez donner plus de détails sur l'installation dynamique par rapport à l'installation statique.

— BuffK