Kami memiliki masalah yang sama dan kami memperbaikinya. Dua kali.
Bangun tambahan (mesin bangun yang sama):
sebelum: ~ 10m setelah: ~ 35s
BAGAIMANA?
Mari kita mulai dengan pengalaman kita terlebih dahulu. Kami memiliki proyek Swift / Obj-C yang besar dan itulah yang menjadi perhatian utama: waktu pembangunan lambat dan Anda harus membuat proyek baru untuk mengimplementasikan fitur baru (secara harfiah). Poin bonus untuk penyorotan sintaks yang tidak berfungsi.
Teori
Untuk benar-benar memperbaiki ini, Anda harus benar - benar memahami cara kerja sistem build. Misalnya, mari coba cuplikan kode ini:
import FacebookSDK
import RxSwift
import PinLayout
dan bayangkan Anda menggunakan semua impor ini dalam file Anda. Dan juga file ini tergantung pada file lain, yang tergantung pada perpustakaan lain, yang pada gilirannya menggunakan perpustakaan lain dll.
Jadi untuk mengkompilasi file Anda Xcode harus mengkompilasi setiap perpustakaan yang Anda sebutkan dan setiap file tergantung, jadi jika Anda mengubah salah satu dari file "inti" Xcode harus membangun kembali seluruh proyek secara harfiah.
Build Xcode multi-threaded , tetapi terdiri dari banyak pohon single-threaded .
Jadi pada langkah pertama setiap build tambahan Xcode menentukan file mana yang harus dikompilasi ulang dan membangun pohon AST . Jika Anda mengubah file yang bertindak sebagai " dapat diandalkan " pada file lain, maka setiap file lain yang bertindak sebagai " tergantung " harus dikompilasi ulang.
Jadi saran pertama adalah untuk menurunkan kopling . Bagian-bagian proyek Anda harus independen satu sama lain.
Obj-C / Swift bridge
Masalah dengan pohon-pohon itu jika Anda menggunakan jembatan Obj-C / Swift, Xcode harus melalui fase lebih dari biasanya:
Dunia yang sempurna:
- Membangun kode Obj-C
- Buat kode Swift
Obj-C / Swift bridge:
- [REPEATABLE STEP] Buat kode Swift, yang diperlukan untuk mengkompilasi kode Obj-C
- [REPEATABLE STEP] Buat kode Obj-C, yang diperlukan untuk mengkompilasi kode Swift
- Ulangi 1 & 2 hingga Anda hanya memiliki kode Swift & Obj-C yang tersisa
- Buat kode Obj-C
- Buat kode Swift
Jadi, jika Anda mengubah sesuatu dari langkah 1 atau 2, pada dasarnya Anda dalam masalah. Solusi terbaik adalah meminimalkan Obj-C / Swift Bridge (dan menghapusnya dari proyek Anda).
Jika Anda tidak memiliki Obj-C / Swift Bridge, itu luar biasa dan Anda bisa melanjutkan ke langkah berikutnya:
Manajer Paket Swift
Saatnya pindah ke SwiftPM (atau setidaknya mengkonfigurasi Cocoapod Anda lebih baik).
Masalahnya, sebagian besar kerangka kerja dengan konfigurasi Cocoapods standar menyeret banyak hal yang tidak Anda butuhkan.
Untuk menguji ini buat proyek kosong dengan hanya satu ketergantungan seperti PinLayout, misalnya dan coba tulis kode ini dengan Cocoapods (konfigurasi default) dan SwiftPM.
import PinLayout
final class TestViewController: UIViewController {
}
Spoiler: Cocoapods akan mengkompilasi kode ini, karena Cocoapods akan mengimpor SETIAP IMPOR PinLayout (termasuk UIKit) dan SwiftPM tidak akan melakukannya karena SwiftPM mengimpor kerangka kerja secara atom.
Retas kotor
Apakah Anda ingat Xcode build multi-threaded?
Nah, Anda dapat menyalahgunakannya, jika Anda dapat membagi proyek Anda menjadi banyak bagian independen dan mengimpor semuanya sebagai kerangka kerja independen ke proyek Anda. Itu memang menurunkan kopling dan itu sebenarnya solusi pertama yang kami gunakan, tapi itu sebenarnya tidak terlalu efektif, karena kami hanya bisa mengurangi waktu build tambahan menjadi ~ 4-5m yang TIDAK ADA dibandingkan dengan metode pertama.