¿Por qué usamos use_frameworks en CocoaPods?

105

Lo he usado use_frameworksen CocoaPods Podfilemuchas veces. Me pregunto por qué lo usamos. No pude obtener la respuesta directa.

Ejemplo:

platform :ios, '8.0'
use_frameworks!

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

— harikrista
fuente

1

¿Te refieres a use_frameworks! ¿CON el signo de exclamación? ¡Siempre he estado confundido sobre eso desde entonces! significa NO.

— Gabriel Jensen

120

use_frameworksle dice a CocoaPods que desea utilizar Frameworks en lugar de Bibliotecas estáticas. Dado que Swift no es compatible con las bibliotecas estáticas, debe utilizar marcos.

En otra respuesta, expliqué las diferencias entre las bibliotecas estáticas y los marcos:

Estructuras Cocoa Touch

Siempre son de código abierto y se crearán como su aplicación. (Por lo tanto, Xcode a veces lo compilará, cuando ejecute su aplicación y siempre después de limpiar el proyecto). Los marcos solo son compatibles con iOS 8 y versiones posteriores, pero puede usar Swift y Objective-C en el marco.

Bibliotecas estáticas Cocoa Touch

Como dice el nombre, son estáticos. Entonces, ya están compilados cuando los importa a su proyecto. Puede compartirlos con otras personas sin mostrarles su código. Tenga en cuenta que las bibliotecas estáticas actualmente no son compatibles con Swift. Tendrá que usar Objective-C dentro de la biblioteca. La aplicación en sí todavía se puede escribir en Swift.

Fuentes: Mi otra respuesta | Blog de AddThis.com

— FelixSFD
fuente

3

Larga historia en las notas de la versión blog.cocoapods.org/CocoaPods-0.36

— Jaime Agudo

7

las bibliotecas estáticas ahora admiten swift a partir de Xcode 9 beta 4: CocoaPods se está actualizando para admitir esto, consulte github.com/CocoaPods/CocoaPods/issues/6899

— JosephH

Descripción ordenada y dulce. Es realmente útil

— Piyush

76

use_frameworks!le dice a las mazorcas de cacao que usen bibliotecas dinámicas, y fue muy frecuente en un momento debido, en particular, a que Swift no admite bibliotecas estáticas, lo que significa que no había otra opción, sin embargo, a menudo ya no las necesita use_frameworks!.

A partir de Xcode 9 beta 4 y CocoaPods 1.5.0, ahora se admiten bibliotecas estáticas rápidas. La principal ventaja son los tiempos de inicio de la aplicación más rápidos, especialmente si tiene muchos pods: iOS 10 y 11 no son los más rápidos cuando tiene muchos dylibs.

CocoaPods 1.5.0 fue lanzado a principios de abril 2018 , por lo que puede que tenga que actualizar conseguirlo: sudo gem install cocoapods.

Sin embargo, encontré varios pods que aún no funcionan correctamente con bibliotecas estáticas, por lo que su kilometraje puede variar.

— JosephH
fuente

2

Hice eso y luego me encontré con los mismos No such moduleerrores. ¿Es eso un problema en esos cocoapods?

— Alper

3

Tuve que agregar use_modular_headers!a mi Podfile para que funcione con pods que presumiblemente lo requieren pero que aún no lo habilitan por sí mismos.

— Adrian

4

@JosephH "La principal ventaja son los tiempos de inicio de la aplicación más rápidos". Esto parece estar en contradicción con la documentación de la Biblioteca dinámica de Apple, que hace la misma afirmación de las DLL: "minimizar el uso de memoria una vez que se lanza hace que la aplicación se inicie más rápido". ¿La implicación aquí es que los dll darán como resultado tiempos de inicio más rápidos si la biblioteca que se está utilizando no es necesaria en el momento del lanzamiento, o es una biblioteca popular y, por lo tanto, ya está cargada en la memoria?

— TolkienWASP

3

@TolkienWASP Esa página parece ser sobre macOS en lugar de iOS. Pero, sí, si la DLL no se carga hasta después del inicio, la dll sería una victoria. Lamentablemente, en el caso de iOS, en las situaciones en las que he visto que todas las DLL se cargan antes de que la aplicación termine de iniciarse, eso hace que las cosas sean más lentas. Hay al menos una charla en la WWDC sobre el tema de la optimización de los tiempos de inicio de la aplicación iOS y mencionó explícitamente algo en la línea de asegurarse de que no tenga más de 3 o 4 dlls.

— JosephH

1

Creo que este es el video mencionado anteriormente: developer.apple.com/videos/play/wwdc2016/406 Le animo a que use la variable de entorno DYLD_PRINT_STATISTICS para medir la velocidad de inicio de su aplicación y ver qué es lo mejor para usted.

— iMacHumphries

2

use_frameworksdeclara que desea utilizar marcos dinámicos , en lugar de bibliotecas estáticas .

Con Xcode 9.0 y CocoaPods 1.5.0 lanzados, puede usar bibliotecas estáticas con rapidez si no las usa use_frameworks.

Un problema con use_frameworkses que todo su marco en Pods / Productos son marcos.

Aquí hay un artículo relacionado: Descripción básica de marcos estáticos y dinámicos en ios

— Mistdon
fuente

4

> ¿ One performance with use_frameworks is that all your framework in Pods/Products is frameworks. Una actuación qué?

— Alex Zavatone

2

^{[Acerca de] de} Cocoapod use_frameworks!es responsable del tipo de binario:

si use_frameworks!está presente -dynamic framework
si nouse_frameworks! está presente -static library

use_frameworks!tiene un reflejo en Mach-O Type^{[Acerca de]} en un objetivo correspondiente del Podsproyecto.

Línea de tiempo:

Se introdujo CocoaPods 0.36use_frameworks! que tenías que usar para Swift Pod
CocoaPods 1.5.0 y Xcode 9 le permitieron elegir

[Vocabulario]

— yoAlex5
fuente

-1

Añadiendo

use_frameworks!

en Podfile significa que queremos que los marcos enumerados se instalen dinámicamente en lugar de marcos estáticos.

— Chiara
fuente

Gracias, pero proporcione más detalles sobre la instalación dinámica frente a la instalación estática.

— BuffK