Чому ми використовуємо use

106

Я багато разів використовував use_frameworksCocoaPods Podfile. Мені просто цікаво, чому ми цим користуємось? Я не міг отримати прямої відповіді на це.

Приклад:

platform :ios, '8.0'
use_frameworks!

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

— харикриста
джерело

1

Ви маєте на увазі use_frameworks! З окликом? Відтоді мене це завжди бентежило! означає НЕ.

— Габріель Дженсен

120

use_frameworksповідомляє CocoaPods, що ви хочете використовувати Frameworks замість статичних бібліотек. Оскільки Swift не підтримує статичні бібліотеки, вам доведеться використовувати рамки.

В іншій відповіді я пояснив відмінності між статичними бібліотеками та рамками:

Какао Touch Frameworks

Вони завжди з відкритим кодом і будуватимуться так само, як і ваш додаток. (Тому Xcode іноді компілює його під час запуску програми та завжди після очищення проекту.) Фреймворки підтримують лише iOS 8 та новіші версії, але ви можете використовувати Swift та Objective-C у фреймворці.

Статичні бібліотеки Cocoa Touch

Як випливає з назви, вони статичні. Отже, вони вже скомпільовані, коли ви імпортуєте їх у свій проект. Ви можете поділитися ними з іншими, не показуючи їм свого коду. Зверніть увагу, що статичні бібліотеки наразі не підтримують Swift. Вам доведеться використовувати Objective-C у бібліотеці. Сам додаток все ще можна писати Swift.

Джерела: Моя інша відповідь | Блог AddThis.com

— FelixSFD
джерело

3

Довга історія в примітках до випуску blog.cocoapods.org/CocoaPods-0.36

— Хайме Агудо,

7

статичні бібліотеки тепер підтримують швидку роботу з Xcode 9 beta 4 - CocoaPods оновлюється, щоб підтримати це, див. github.com/CocoaPods/CocoaPods/issues/6899

— JosephH

Сортування та солодкий опис. Це дійсно корисно

— Піюш,

76

use_frameworks!розповідає стручкам какао використовувати динамічні бібліотеки, і в якийсь момент він був дуже поширеним, зокрема завдяки швидкій непідтримці статичних бібліотек, тобто вибору не було - однак вам часто це більше не потрібно use_frameworks!.

Починаючи з Xcode 9 beta 4 та CocoaPods 1.5.0, зараз підтримуються швидкі статичні бібліотеки. Основною перевагою є швидший час запуску програми, особливо якщо у вас багато стручків - iOS 10 і 11 не найшвидші, коли у вас багато дилібів.

CocoaPods 1.5.0 був випущений на початку квітня 2018 року , так що вам , можливо , буде потрібно оновити , щоб отримати його: sudo gem install cocoapods.

Я знайшов кілька стручків, які ще не працюють належним чином зі статичними бібліотеками, тому ваш пробіг може відрізнятися.

— ДжозефH
джерело

2

Я зробив це, а потім зіткнувся з тими ж No such moduleпомилками. Це проблема в тих какаодах?

— Альпер,

3

Мені довелося додати use_modular_headers!до мого Podfile, щоб змусити його працювати з стручками, які, мабуть, вимагають цього, але ще не вмикають його самі.

— Адріан

4

@JosephH "Основна перевага - швидший час запуску програми". Це, судячи з усього, суперечить документації Apple Dynamic Library, яка висуває те саме твердження про DLL: "мінімізація використання пам'яті після її запуску пришвидшує запуск програми". Чи мається на увазі тут те, що dll призведе до пришвидшення часу запуску, якщо використовувана бібліотека не потрібна під час запуску, або це популярна бібліотека, і тому вона вже завантажена в пам’ять?

— TolkienWASP

3

@TolkienWASP Ця сторінка, схоже, стосується macOS, а не iOS. Але так, якщо DLL завантажується лише після запуску, то dll буде виграшем. На жаль, у випадку iOS, у ситуаціях, коли я бачив, що всі бібліотеки DLL завантажуються до завершення запуску програми, тож це робить роботу повільнішою. Існує принаймні одна дискусія WWDC на тему оптимізації часу запуску додатків iOS, і в ній чітко згадується щось на кшталт переконання, що у вас не більше 3 або 4 dll.

— JosephH

1

Я думаю, що це відео, на яке посилається вище: developer.apple.com/videos/play/wwdc2016/406. Я б радив вам використовувати змінну середовища DYLD_PRINT_STATISTICS для вимірювання швидкості запуску вашого додатка та побачити, що для вас найкраще.

— iMacHumphries

2

use_frameworksзаявляє, що ви хочете використовувати динамічні фреймворки , замість статичних бібліотек .

З випущеними Xcode 9.0 і CocoaPods 1.5.0 ви можете використовувати статичні бібліотеки зі швидким використанням, якщо не використовуєте use_frameworks.

Однією з проблем use_frameworksє те, що всі ваші фреймворки в Pods / Products - це фреймворки.

Ось відповідна стаття: Основний огляд статичних та динамічних фреймворків на ios

— містдон
джерело

4

> One performance with use_frameworks is that all your framework in Pods/Products is frameworks. Один виступ що?

— Alex Zavatone

2

Cocoapod's ^[About] use_frameworks! відповідає за тип двійкового файлу :

якщо use_frameworks!це присутнє -dynamic framework
якщо use_frameworks!це немає -static library

use_frameworks!має відображення в Mach-O Type^[Про] у відповідній цілі Podsпроекту.

Хронологія:

CocoaPods 0,36 введені , use_frameworks!які ви повинні були використовувати для Swift стручка
CocoaPods 1.5.0 та Xcode 9 дозволили вам вибрати

[Словник]

— yoAlex5
джерело

-1

Додавання

use_frameworks!

у Podfile означає, що ми хочемо, щоб перераховані рамки динамічно встановлювались замість них як статичні.

— К'яра
джерело

Дякуємо, але, будь ласка, надайте більше подробиць про динамічну та статичну інсталяцію.

— BuffK

Чому ми використовуємо use_frameworks у CocoaPods?

Какао Touch Frameworks

Статичні бібліотеки Cocoa Touch