Perché usiamo use_frameworks in CocoaPods?

105

Ho usato use_frameworksCocoaPods Podfilemolte volte. Mi chiedo solo perché lo usiamo? Non sono riuscito a ottenere una risposta diretta.

Esempio:

platform :ios, '8.0'
use_frameworks!

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

— harikrista
fonte

1

Vuoi dire use_frameworks! CON il punto esclamativo? Da allora sono sempre stato confuso su questo! significa NON.

— Gabriel Jensen

120

use_frameworksdice a CocoaPods che vuoi usare Frameworks invece di Static Libraries. Poiché Swift non supporta le librerie statiche, devi utilizzare i framework.

In un'altra risposta, ho spiegato le differenze tra le librerie statiche e i framework:

Cocoa Touch Frameworks

Sono sempre open source e verranno creati proprio come la tua app. (Quindi Xcode a volte lo compila, quando esegui la tua app e sempre dopo aver ripulito il progetto.) I framework supportano solo iOS 8 e versioni successive, ma puoi usare Swift e Objective-C nel framework.

Librerie statiche Cocoa Touch

Come dice il nome, sono statici. Quindi sono già compilati, quando li importi nel tuo progetto. Puoi condividerli con altri senza mostrare loro il tuo codice. Tieni presente che le librerie statiche attualmente non supportano Swift. Dovrai usare Objective-C all'interno della libreria. L'app stessa può ancora essere scritta in Swift.

Fonti: l' altra mia risposta | Blog di AddThis.com

— FelixSFD
fonte

3

Lunga storia sulle note di rilascio blog.cocoapods.org/CocoaPods-0.36

— Jaime Agudo

7

le librerie statiche ora supportano swift a partire da Xcode 9 beta 4 - CocoaPods è in fase di aggiornamento per supportare questo, vedere github.com/CocoaPods/CocoaPods/issues/6899

— JosephH

Descrizione gentile e dolce. È davvero utile

— Piyush

76

use_frameworks!dice ai baccelli di cacao di utilizzare le librerie dinamiche, e ad un certo punto era molto diffuso a causa in particolare del fatto che swift non supportava le librerie statiche, il che significa che non c'era scelta, tuttavia spesso non ne haiuse_frameworks! più bisogno .

A partire da Xcode 9 beta 4 e CocoaPods 1.5.0, ora sono supportate le librerie statiche rapide. Il vantaggio principale sono i tempi di avvio delle app più rapidi, in particolare se si hanno molti pod: iOS 10 e 11 non sono i più veloci quando si hanno molti dylibs.

CocoaPods 1.5.0 è stato rilasciato all'inizio di aprile 2018 , quindi potrebbe essere necessario eseguire l'aggiornamento a ottenerlo: sudo gem install cocoapods.

Tuttavia, ho trovato diversi pod che non funzionano ancora correttamente con le librerie statiche, quindi il tuo chilometraggio potrebbe variare.

— JosephH
fonte

2

L'ho fatto e poi sono incappato negli stessi No such moduleerrori. È un problema in quei cocoapodi?

— Alper

3

Ho dovuto aggiungere use_modular_headers!al mio Podfile per farlo funzionare con i pod che presumibilmente lo richiedono ma non lo abilitano ancora da soli.

— Adrian

4

@JosephH "Il vantaggio principale sono tempi di avvio delle app più rapidi". Questo sembra essere in contraddizione con la documentazione della libreria dinamica di Apple, che fa la stessa affermazione delle dll: "ridurre al minimo il suo utilizzo della memoria una volta avviata rende l'avvio dell'app più veloce". L'implicazione qui è che le dll comporteranno tempi di avvio più rapidi se la libreria utilizzata non è richiesta al momento del lancio, o è una libreria popolare e quindi è già caricata in memoria?

— TolkienWASP

3

@TolkienWASP Quella pagina sembra riguardare macOS piuttosto che iOS. Ma sì, se la DLL non viene caricata fino a dopo l'avvio, la DLL sarebbe una vittoria. Purtroppo nel caso di iOS nelle situazioni in cui ho visto tutte le DLL vengono caricate prima che l'app finisca di avviarsi, ciò rende le cose più lente. C'è almeno un discorso del WWDC sull'argomento dell'ottimizzazione dei tempi di avvio delle app iOS e ha menzionato esplicitamente qualcosa sulla falsariga di assicurarsi di non avere più di 3 o 4 dll.

— JosephH,

1

Penso che questo sia il video a cui si fa riferimento sopra: developer.apple.com/videos/play/wwdc2016/406 Ti incoraggio a utilizzare la variabile d'ambiente DYLD_PRINT_STATISTICS per misurare la velocità di avvio della tua app e vedere cosa è meglio per te.

— iMacHumphries

2

use_frameworksdichiara che si desidera utilizzare framework dinamici , invece di librerie statiche .

Con Xcode 9.0 e CocoaPods 1.5.0 rilasciati, puoi utilizzare le librerie statiche con swift se non le usi use_frameworks.

Un problema use_frameworksè che tutti i tuoi framework in Pod / Prodotti sono framework.

Di seguito è riportato un articolo correlato: Panoramica di base dei framework statici e dinamici su ios

— mistdon
fonte

4

> One performance with use_frameworks is that all your framework in Pods/Products is frameworks. Uno spettacolo cosa?

— Alex Zavatone

2

Cocoapod's ^[About] use_frameworks! è responsabile del tipo di binario:

se use_frameworks!è presente -dynamic framework
se nonuse_frameworks! è presente -static library

use_frameworks!ha una riflessione in Mach-O Type^[About] in un target corrispondente del Podsprogetto.

Sequenza temporale:

CocoaPods 0.36 ha introdotto use_frameworks!che dovevi usare per Swift pod
CocoaPods 1.5.0 e Xcode 9 ti hanno permesso di scegliere

[Vocabolario]

— yoAlex5
fonte

-1

Aggiunta

use_frameworks!

nel Podfile significa che vogliamo che i framework elencati vengano installati dinamicamente invece come framework statici.

— Chiara
fonte

Grazie ma fornisci maggiori dettagli sull'installazione dinamica rispetto all'installazione statica.

— BuffK