Podfile: คืออะไร ไวยากรณ์ และการกำหนดค่าคลังผ่าน CocoaPods

Podfile คืออะไรและทำไมต้องใช้

Podfile คือสคริปต์แบบประกาศที่เขียนด้วยภาษา Ruby ซึ่งแสดงรายการ Dependency ภายนอกสำหรับโปรเจกต์ iOS, macOS, tvOS หรือ watchOS อยู่ในไดเรกทอรีรากของโปรเจกต์และทำหน้าที่เป็นจุดกำหนดค่าเดียวสำหรับตัวจัดการแพ็กเกจ CocoaPods หากไม่มี Podfile นักพัฒนาจะต้องดาวน์โหลดคลังด้วยตนเอง คัดลอกไปยังโปรเจกต์ และกำหนดค่า linker flags ใน Xcode

CocoaPods วิเคราะห์ Podfile และสร้างไฟล์ Podfile.lock ที่ล็อกเวอร์ชันที่แน่นอนของ คลัง ที่ติดตั้ง สิ่งนี้รับประกันการบิลด์ที่สามารถทำซ้ำได้บนเครื่องทั้งหมดของทีมพัฒนา: หากนักพัฒนาคนหนึ่งอัปเดต Alamofire เป็นเวอร์ชัน 5.9 Podfile.lock จะล็อกการเปลี่ยนแปลงนี้ และคนอื่นๆ ทั้งหมดที่รัน pod install จะได้รับเวอร์ชันเดียวกันทุกประการ หากไม่มีกลไกนี้ นักพัฒนาที่แตกต่างกันอาจมีเวอร์ชัน Dependency ที่แตกต่างกัน ซึ่งนำไปสู่บักที่ค้นหายาก

Podfile แก้ปัญหาหลักสามประการ: การจัดการ Dependency ด้วยการควบคุมเวอร์ชัน การกำหนดค่าแพลตฟอร์มเป้าหมายด้วยเวอร์ชัน OS ขั้นต่ำ และการรวมคลังอัตโนมัติผ่าน Xcode Workspace ในการติดตั้งแต่ละครั้ง CocoaPods จะสร้างไฟล์ Pods.xcodeproj ที่เชื่อมโยงกับโปรเจกต์หลักผ่าน workspace นักพัฒนาไม่จำเป็นต้องคิดว่าคลังเชื่อมต่อกันอย่างไร — เพียงระบุใน Podfile ก็พอ

ไวยากรณ์และโครงสร้างของ Podfile

Podfile ใช้ไวยากรณ์ Ruby แต่ต้องการความรู้ภาษาเพียงเล็กน้อย โครงสร้างพื้นฐานประกอบด้วย คำสั่ง ที่กำหนดแพลตฟอร์ม เป้าหมายการบิลด์ และรายการ Dependency แต่ละคำสั่งถูกดำเนินการในบริบทของอินเทอร์พรีเตอร์ Ruby ดังนั้น Podfile รองรับโครงสร้างแบบมีเงื่อนไข ลูป และตัวแปรสำหรับการกำหนดค่าที่ซับซ้อน

บล็อก target

แต่ละเป้าหมายการบิลด์แอปถูกอธิบายภายในบล็อก target สำหรับโปรเจกต์ Xcode มาตรฐาน มักจะมีหนึ่งเป้าหมายพร้อมชื่อแอป เป้าหมายแบบซ้อนสามารถใช้สำหรับการทดสอบหน่วย การทดสอบ UI และส่วนขยาย แนะนำให้แยก Dependency ของเป้าหมายต่างๆ: คลังหลักในเป้าหมายหลัก เฟรมเวิร์กทดสอบในเป้าหมายทดสอบ เพื่อหลีกเลี่ยง Dependency ที่ไม่จำเป็นในการผลิต

# ตัวอย่าง Podfile ขั้นต่ำสำหรับโปรเจกต์ iOS
target 'MyApp' do
  use_frameworks!
  pod 'Alamofire', '~> 5.8'
  pod 'Kingfisher', '~> 7.10'
  pod 'SnapKit', '~> 5.6'
end

คำสั่งแพลตฟอร์ม

คำสั่ง platform กำหนด เวอร์ชัน OS ขั้นต่ำ ที่โปรเจกต์ถูกบิลด์สำหรับ นี่คือพารามิเตอร์บังคับที่มีผลต่อความเข้ากันได้ของคลัง คลังใน CocoaPods มักจะระบุเวอร์ชัน OS ขั้นต่ำใน podspec และหากแพลตฟอร์มโปรเจกต์ต่ำกว่าที่กำหนด pod install จะแสดงข้อผิดพลาด สำหรับโปรเจกต์ iOS เวอร์ชันขั้นต่ำโดยทั่วไปคือ 15.0 ขึ้นไป สำหรับ macOS — 12.0 ขึ้นไป

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

Dependency ส่วนกลางและท้องถิ่น

Dependency สามารถระบุได้ทั่วโลกนอกบล็อก target หรือภายในเป้าหมายเฉพาะ pods ส่วนกลางเชื่อมต่อกับทุกเป้าหมายของโปรเจกต์ ซึ่งสะดวกสำหรับคลังวัตถุประสงค์ทั่วไปเช่น CocoaLumberjack สำหรับการบันทึก Dependency ท้องถิ่นมีประโยชน์สำหรับการแยกเฟรมเวิร์กทดสอบและโค้ดการผลิต: Quick และ Nimble สำหรับการทดสอบ Firebase สำหรับการวิเคราะห์ Realm สำหรับการจัดเก็บข้อมูล

# Dependency ส่วนกลางสำหรับทุกเป้าหมาย
pod 'CocoaLumberjack'

target 'MyApp' do
  # Dependency ท้องถิ่นของแอปหลัก
  pod 'Firebase/Crashlytics'
  pod 'Firebase/Analytics'
  pod 'RealmSwift'
end

target 'MyAppTests' do
  # เฟรมเวิร์กทดสอบจะไม่รวมในการเผยแพร่
  pod 'Quick'
  pod 'Nimble'
end

การจัดการเวอร์ชัน Dependency

CocoaPods รองรับการระบุ เวอร์ชัน แบบยืดหยุ่นผ่านตัวดำเนินการเปรียบเทียบ สิ่งนี้ช่วยให้ควบคุมการอัปเดตและหลีกเลี่ยงการเปลี่ยนแปลง API ที่เข้ากันไม่ได้ การเลือกตัวดำเนินการที่ถูกต้องมีความสำคัญต่อความเสถียรของโปรเจกต์: ข้อจำกัดที่เข้มงวดเกินไปจะบล็อกการอัปเดตที่มีการแก้ไขบัก ในขณะที่ข้อจำกัดที่หลวมเกินไปอาจทำให้เกิดความเสียหายที่ไม่คาดคิดจากการอัปเดตหลัก

แนะนำให้ใช้ ตัวดำเนินการ ~> สำหรับการอัปเดตที่เข้ากันได้ มันป้องกันการเปลี่ยนแปลง API หลักในขณะที่อนุญาตให้แพตช์และการปรับปรุงเล็กน้อย ตัวอย่างเช่น ~> 5.8 อนุญาตเวอร์ชัน 5.8.0, 5.8.1, 5.9.0 แต่บล็อก 6.0.0 ซึ่งอาจมีการเปลี่ยนแปลง API ที่สำคัญ

ไฟล์ Podfile.lock ล็อกเวอร์ชันที่แน่นอนและต้องเก็บไว้ในระบบควบคุม เวอร์ชัน คำสั่ง pod update อัปเดต Dependency เป็นเวอร์ชันล่าสุดที่อนุญาตและเขียนทับไฟล์ล็อก ในขณะที่ pod install ใช้เวอร์ชันที่ล็อกแล้วจาก Podfile.lock เพื่อรับประกันการบิลด์ที่เหมือนกัน

การกำหนดค่าสำหรับพัฒนาและผลิต

Podfile รองรับการแยก การกำหนดค่า ผ่านคำสั่งสำหรับแผนการบิลด์ต่างๆ สามารถเชื่อมต่อชุดคลังที่แตกต่างกันสำหรับ Debug และ Release ซึ่งช่วยลดขนาดการบิลด์สำหรับการผลิตอย่างมากและเร่งการคอมไพล์ Linter เครื่องกำเนิดโค้ด และเครื่องมือดีบักควรทำงานเฉพาะในการกำหนดค่า Debug

target 'MyApp' do
  # เฉพาะ Debug: linter และดีบัก
  pod 'SwiftLint', :configurations => ['Debug']
  # การผลิต: การวิเคราะห์และการตรวจสอบ
  pod 'Fabric'
  pod 'TestFairy', :configurations => ['Release']
end

คำสั่ง inhibit_all_warnings! ปิดคำเตือนจาก pods ทั้งหมด มีประโยชน์สำหรับโปรเจกต์ขนาดใหญ่ที่คลังของบุคคลที่สามสร้างเสียงรบกวนมากในบันทึกการบิลด์ ทำให้ยากต่อการค้นหาคำเตือนและข้อผิดพลาดของคุณเอง สำหรับการปิดคำเตือนแบบเลือก สามารถใช้ inhibit_warnings บน pod เฉพาะ

คลังที่ใช้เฉพาะระหว่าง การพัฒนา ควรแยกผ่านการกำหนดค่า Debug SwiftLint, OHHTTPStubs, RevealServer และเครื่องมือที่คล้ายกันไม่ควรพร้อมใช้งานในการบิลด์สำหรับการผลิต สิ่งนี้ไม่เพียงลดขนาด IPA แต่ยังป้องกันการเปิดเผยข้อมูลดีบักโดยไม่ตั้งใจในเวอร์ชันเผยแพร่ของแอป แต่ละ pod ที่เหลือใน Release โดยไม่จำเป็นเพิ่มเวลาเริ่มต้นและการใช้หน่วยความจำ นอกจากนี้ CocoaPods รองรับคำสั่ง abstract_target ซึ่งจัดกลุ่ม Dependency ร่วมกันโดยไม่สร้างเป้าหมายการบิลด์ทางกายภาพ

สำหรับโปรเจกต์ขนาดใหญ่ที่มีสถาปัตยกรรมแบบโมดูล แนะนำให้ใช้โครงสร้าง Podfile หลายเป้าหมาย: แต่ละโมดูลแอปได้รับเป้าหมายของตัวเองพร้อมชุด Dependency ที่แยกออกจากกัน สิ่งนี้เร่งการบิลด์แบบเพิ่มหน่วยเพราะเมื่อเปลี่ยนโมดูลหนึ่ง เฉพาะ Dependency ของมันเท่านั้นที่ถูกบิลด์ใหม่ CocoaPods แก้ไข Dependency ที่ทับซ้อนกันระหว่างเป้าหมายโดยอัตโนมัติ รับประกันว่าคลังแต่ละแห่งถูกติดตั้งในเวอร์ชันเดียวทั่วทุกโมดูลของโปรเจกต์

Post-Install Hooks และความสามารถเพิ่มเติม

Hook post_install ถูกดำเนินการหลังจากติดตั้ง pods ทั้งหมด มันอนุญาตให้เปลี่ยนการตั้งค่าโปรเจกต์ Xcode โดยทางโปรแกรม เช่น การตั้งค่าเวอร์ชัน iOS ขั้นต่ำสำหรับเป้าหมายแต่ละรายการ การเพิ่มเฟสการบิลด์ หรือการแก้ไข info plists ของคลัง นี่คือกลไกการปรับแต่งที่ทรงพลังโดยที่หากไม่มี คลังของบุคคลที่สามบางแห่งไม่สามารถกำหนดค่าได้อย่างถูกต้อง

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # บังคับตั้งค่าเวอร์ชันขั้นต่ำสำหรับ pods ทั้งหมด
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '15.0'
    end
  end
end

คำสั่ง use_frameworks! เปิดใช้งานเฟรมเวิร์กไดนามิกแทนคลังแบบสแตติก นี่คือพารามิเตอร์บังคับสำหรับโปรเจกต์ Swift และคลังที่เขียนด้วย Swift เนื่องจากรันไทม์ Swift ต้องการการเชื่อมโยงแบบไดนามิก อย่างไรก็ตาม สำหรับโปรเจกต์ Objective-C สามารถใช้ use_frameworks! :linkage => :static เพื่อบิลด์เฟรมเวิร์กแบบสแตติก ซึ่งลดเวลาเริ่มต้นแอปและขนาดบันเดิล

แฟล็ก static_frameworks ในตัวติดตั้งอนุญาตให้บิลด์เฟรมเวิร์กแบบสแตติก ลดเวลาเริ่มต้นแอป ตัวเลือกระหว่าง static และ dynamic ขึ้นอยู่กับสถาปัตยกรรมของโปรเจกต์: เฟรมเวิร์กแบบไดนามิกใช้เวลาโหลดนานกว่าแต่ปล่อยให้ระบบแบ่งปันหน่วยความจำระหว่างกระบวนการต่างๆ เฟรมเวิร์กแบบสแตติกกระทัดรัดกว่า แต่สำเนาแต่ละชุดใช้หน่วยความจำแยกกันในแต่ละกระบวนการ

นอกจาก post_install แล้ว Podfile ยังรองรับ hook pre_install ซึ่งถูกดำเนินการก่อนการติดตั้ง pod มีประโยชน์สำหรับการแก้ไข podspecs ก่อนการรวม ตัวอย่างเช่น การเปลี่ยนซอร์สโค้ดของคลังผ่านแพตช์ หรือการกำหนดค่าแฟล็กคอมไพเลอร์เฉพาะ Hook ทำให้ Podfile ไม่ใช่แค่รายการ Dependency แต่เป็นสคริปต์กำหนดค่าที่สมบูรณ์ซึ่งทำให้กระบวนการบิลด์เป็นอัตโนมัติ

คำสั่ง source ระบุ URL ของที่เก็บ CocoaPods Specs โดยค่าเริ่มต้นจะใช้ที่เก็บอย่างเป็นทางการ https://github.com/CocoaPods/Specs.git แต่สำหรับโปรเจกต์ที่มีคลังส่วนตัว สามารถเพิ่มที่เก็บ Specs ส่วนตัวได้ หลายคำสั่ง source อนุญาตให้รวม podspecs สาธารณะและส่วนตัวใน Podfile เดียวกัน ลำดับของ source สำคัญ: CocoaPods ค้นหา pods ตามลำดับที่ระบุและใช้อินสแตนซ์แรกที่พบ ซึ่งอนุญาตให้แทนที่คลังสาธารณะด้วยเวอร์ชันส่วนตัว