Podfile: bu nima, sintaksis va CocoaPods orqali kutubxonalarni sozlash

Podfile nima va u nima uchun kerak

Podfile — iOS, macOS, tvOS yoki watchOS loyihasi uchun tashqi bog'liqliklar sanab o'tilgan Ruby tilidagi deklarativ skript. U loyihaning ildiz katalogida joylashgan va CocoaPods paket menejeri uchun yagona konfiguratsiya nuqtasi bo'lib xizmat qiladi. Podfilesiz dasturchilar kutubxonalarni qo'lda yuklab olishlari, ularni loyihaga nusxalashlari va Xcode-da linker bayroqlarini sozlashlari kerak bo'lardi.

CocoaPods Podfile-ni tahlil qiladi va o'rnatilgan kutubxonalarning aniq versiyalarini belgilaydigan yopiq Podfile.lock faylini yaratadi. Bu jamoadagi barcha mashinalarda qurilishlarning takrorlanishini kafolatlaydi: agar bir dasturchi Alamofire-ni 5.9 versiyasiga yangilasa, Podfile.lock bu o'zgarishni qayd etadi va pod install-ni bajaradigan har bir kishi aynan bir xil versiyani oladi. Ushbu mexanizmsiz turli dasturchilar turli xil bog'liqlik versiyalariga ega bo'lishi mumkin, bu esa aniqlash qiyin bo'lgan xatolarga olib keladi.

Podfile uchta asosiy vazifani hal qiladi: versiyalarni nazorat qilish bilan bog'liqliklarni boshqarish, minimal OS versiyasi bilan maqsadli platformani sozlash va Xcode Workspace orqali kutubxonalarni avtomatik integratsiya qilish. Har bir o'rnatishda CocoaPods Pods.xcodeproj faylini yaratadi, u workspace orqali asosiy loyiha bilan bog'lanadi. Dasturchi kutubxonalar qanday ulanganligi haqida o'ylashi shart emas — ularni Podfile-da ko'rsatish kifoya.

Podfile sintaksisi va tuzilishi

Podfile Ruby sintaksisidan foydalanadi, ammo minimal til bilimini talab qiladi. Asosiy tuzilma platformani, qurish maqsadlarini va bog'liqliklar ro'yxatini belgilaydigan direktivalardan iborat. Har bir direktiva Ruby interpretatori kontekstida bajariladi, shuning uchun Podfile murakkab konfiguratsiyalar uchun shartli konstruksiyalarni, sikllarni va o'zgaruvchilarni qo'llab-quvvatlaydi.

Target bloki

Ilovaning har bir qurish maqsadi target bloki ichida tavsiflanadi. Standart Xcode loyihasi uchun bu odatda ilova nomi bilan bitta maqsaddir. Ichma-ich target-lar modul testlari, UI testlari va kengaytmalar uchun ishlatilishi mumkin. Turli target-larning bog'liqliklarini izolyatsiya qilish tavsiya etiladi: asosiy kutubxonalar asosiy target-da, test frameworklari test targetida — shunday qilib ortiqcha bog'liqliklarning ishlab chiqarish versiyasiga tushishining oldi olinadi.

# iOS loyihasi uchun minimal Podfile namunasi
target 'MyApp' do
  use_frameworks!
  pod 'Alamofire', '~> 5.8'
  pod 'Kingfisher', '~> 7.10'
  pod 'SnapKit', '~> 5.6'
end

Platforma direktivalari

Platform direktivasi loyiha quriladigan minimal OS versiyasini belgilaydi. Bu kutubxonalarning mosligiga ta'sir qiluvchi majburiy parametrdir. CocoaPods-dagi kutubxonalar odatda podspec-da o'zlarining minimal OS versiyalarini ko'rsatadi va loyiha platformasi talab qilinganidan past bo'lsa, pod install xato beradi. iOS loyihalari uchun minimal versiya odatda 15.0 va undan yuqori, macOS uchun esa 12.0 va undan yuqori.

platform :ios, '15.0'
platform :macos, '12.0'
platform :tvos, '16.0'

Global va lokal bog'liqliklar

Bog'liqliklar target bloklaridan tashqarida global yoki aniq bir maqsad ichida lokal ko'rsatilishi mumkin. Global podlar loyihaning barcha maqsadlariga ulanadi, bu esa loglash uchun CocoaLumberjack kabi umumiy maqsadli kutubxonalar uchun qulay. Lokal bog'liqliklar test frameworklarini va ishlab chiqarish kodini ajratish uchun foydalidir: testlar uchun Quick va Nimble, analitika uchun Firebase, ma'lumotlarni saqlash uchun Realm.

# Barcha maqsadlar uchun global bog'liqlik
pod 'CocoaLumberjack'

target 'MyApp' do
  # Asosiy ilonining lokal bog'liqliklari
  pod 'Firebase/Crashlytics'
  pod 'Firebase/Analytics'
  pod 'RealmSwift'
end

target 'MyAppTests' do
  # Test frameworklari relizga kirmaydi
  pod 'Quick'
  pod 'Nimble'
end

Bog'liqlik versiyalarini boshqarish

CocoaPods taqqoslash operatorlari orqali versiyalarning moslashuvchan ko'rsatilishini qo'llab-quvvatlaydi. Bu yangilanishlarni nazorat qilish va mos kelmaydigan API o'zgarishlaridan qochish imkonini beradi. To'g'ri operatorni tanlash loyiha barqarorligi uchun juda muhimdir: juda qattiq cheklovlar xato tuzatishlari bilan yangilanishlarni bloklaydi, juda yumshoq cheklovlar esa asosiy yangilanishlarda kutilmagan nosozliklarga olib kelishi mumkin.

Mos yangilanishlar uchun ~> operatoridan foydalanish tavsiya etiladi. U API-ning asosiy o'zgarishlaridan himoya qiladi, shu bilan birga yamalar va kichik yaxshilanishlarni olish imkonini beradi. Masalan, ~> 5.8 5.8.0, 5.8.1, 5.9.0 versiyalariga ruxsat beradi, lekin kritik API o'zgarishlari bo'lishi mumkin bo'lgan 6.0.0 ni bloklaydi.

Podfile.lock fayli aniq versiyalarni belgilaydi va versiya nazorat tizimida saqlanishi kerak. pod update buyrug'i bog'liqliklarni ruxsat etilgan eng so'nggi versiyalarga yangilaydi va lock faylini qayta yozadi, pod install esa qurilishlarning bir xilligini kafolatlash uchun Podfile.lock-dan oldindan belgilangan versiyalardan foydalanadi.

Ishlab chiqish va ishlab chiqarish konfiguratsiyalari

Podfile turli qurish sxemalari uchun direktivalar orqali konfiguratsiyalarning bo'linishini qo'llab-quvvatlaydi. Debug va Release uchun turli xil kutubxona to'plamlarini ulash mumkin, bu esa ishlab chiqarish qurilmasining hajmini sezilarli darajada kamaytiradi va uning kompilyatsiyasini tezlashtiradi. Linterlar, kod generatorlari va disk raskadrovka vositalari faqat Debug konfiguratsiyasida ishlashi kerak.

target 'MyApp' do
  # Faqat Debug uchun: linter va disk raskadrovka
  pod 'SwiftLint', :configurations => ['Debug']
  # Ishlab chiqarish: analitika va monitoring
  pod 'Fabric'
  pod 'TestFairy', :configurations => ['Release']
end

inhibit_all_warnings! direktivasi barcha podlardan ogohlantirishlarni o'chiradi. Bu katta loyihalarda foydali, chunki uchinchi tomon kutubxonalari qurish jurnallarida ko'p shovqin yaratib, o'z ogohlantirishlari va xatolarini topishni qiyinlashtiradi. Tanlab o'chirish uchun inhibit_warnings ma'lum bir podda ishlatilishi mumkin.

Faqat ishlab chiqish bosqichida ishlatiladigan kutubxonalarni Debug konfiguratsiyalari orqali izolyatsiya qilish tavsiya etiladi. SwiftLint, OHHTTPStubs, RevealServer va shunga o'xshash vositalar ishlab chiqarish qurilmasida mavjud bo'lmasligi kerak. Bu nafaqat IPA hajmini kamaytiradi, balki ilonining reliz versiyasida disk raskadrovka ma'lumotlarining tasodifan oshkor etilishini ham oldini oladi. Keraksiz holda Release-da qoldirilgan har bir pod ishga tushirish vaqtini va xotira sarfini oshiradi. Qo'shimcha ravishda, CocoaPods jismoniy qurish maqsadini yaratmasdan umumiy bog'liqliklarni guruhlaydigan abstract_target direktivasini qo'llab-quvvatlaydi.

Modul arxitekturasiga ega katta loyihalar uchun ko'p targetli Podfile tuzilmasidan foydalanish tavsiya etiladi: ilonining har bir moduli izolyatsiya qilingan bog'liqliklar to'plami bilan o'z targetini oladi. Bu inkremental qurilishni tezlashtiradi, chunki bir modul o'zgarganda faqat uning bog'liqliklari qayta quriladi. CocoaPods targetlar o'rtasidagi kesishgan bog'liqliklarni avtomatik hal qilib, har bir kutubxonaning loyihaning barcha modullari uchun yagona versiyada o'rnatilishini kafolatlaydi.

O'rnatishdan keyingi Huklar va qo'shimcha imkoniyatlar

post_install huki barcha podlar o'rnatilgandan so'ng bajariladi. U Xcode loyiha sozlamalarini dasturiy ravishda o'zgartirish imkonini beradi, masalan, alohida targetlar uchun minimal iOS versiyasini sozlash, qurish fazalarini qo'shish yoki kutubxonalarning infoplists fayllarini o'zgartirish. Bu kuchli sozlash mexanizmi bo'lib, unsiz ba'zi uchinchi tomon kutubxonalari to'g'ri sozlanishi mumkin emas.

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # Barcha podlar uchun minimal versiyani majburiy belgilaymiz
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '15.0'
    end
  end
end

use_frameworks! direktivasi statik kutubxonalar o'rniga dinamik frameworklardan foydalanishni faollashtiradi. Bu Swift loyihalari va Swift-da yozilgan kutubxonalar uchun majburiy parametrdir, chunki Swift ijro muhiti dinamik ulanishni talab qiladi. Biroq, Objective-C loyihalari uchun statik frameworklarni qurish uchun use_frameworks! :linkage => :static dan foydalanish mumkin, bu esa ilovaning ishga tushirish vaqtini va paket hajmini kamaytiradi.

O'rnatuvchidagi static_frameworks bayrog'i statik frameworklarni qurish imkonini beradi, bu esa ilovaning ishga tushirish vaqtini qisqartiradi. Static va dynamic o'rtasidagi tanlov loyiha arxitekturasiga bog'liq: dinamik frameworklar uzoqroq yuklanadi, lekin tizimga jarayonlar o'rtasida xotirani ulashish imkonini beradi. Statik frameworklar ixchamroq, lekin har bir nusxa har bir jarayonda alohida xotirani egallaydi.

post_install dan tashqari, Podfile podlar o'rnatilishidan oldin bajariladigan pre_install hukini qo'llab-quvvatlaydi. U integratsiyadan oldin podspec-ni o'zgartirish, masalan, yamalar orqali kutubxonalarning manba kodini o'zgartirish yoki kompilyatorning maxsus bayroqlarini sozlash uchun foydalidir. Huklar Podfile-ni shunchaki bog'liqliklar ro'yxati emas, balki qurish jarayonini avtomatlashtiradigan to'liq konfiguratsiya skriptiga aylantiradi.

source direktivasi CocoaPods Specs omborining URL-manzilini ko'rsatadi. Odatiy bo'lib rasmiy https://github.com/CocoaPods/Specs.git omboridan foydalaniladi, ammo xususiy kutubxonalari bo'lgan loyihalar uchun o'z shaxsiy Specs omborini qo'shish mumkin. Bir nechta source-lar bitta Podfile-da ochiq va xususiy podspeklarni birlashtirish imkonini beradi. Source tartibi muhim: CocoaPods podlarni ko'rsatilgan tartibda qidiradi va birinchi topilgan nusxadan foydalanadi, bu esa ochiq kutubxonalarni xususiy versiyalar bilan almashtirish imkonini beradi.