Objective-C: prestazioni di bridging rapido per la codebase esistente

Question

Una domanda di prestazioni per gli sviluppatori che hanno esperienza con l'aggiunta rapida di codebase Objective-C esistenti.

La mia premessa è: alla fine Bridging-Header.h potrebbe diventare veramente grande (potrebbe finire contenente tutti 1.5K esistenti classi Objective-C (dare o prendere lezioni di quelli che non saranno accessibili da Swift)) e viceversa per PRODUCT-Swift.h generato intestazione.

Temo che le prestazioni della compilazione possano diminuire drasticamente: ogni volta che una delle classi incluse è stata modificata, dovrà ricompilare tutti i file .swift.

È questo il caso? In tal caso, c'è un modo per ottimizzare le prestazioni?

Chiarimento: Immaginate che hai incluso il tuo intere classi di progetto in .pch di file, ora ogni cambio di classe attiverà ricompilazione dell'intero progetto. È simile al modo in cui funziona Bridging-Header.h?

Answer 1

Se ci si aspetta molto churn nei file di intestazione, consiglierei i moduli. Suddividendo il codice Swift in moduli, ognuno con la propria intestazione di bridging, si dovrebbe ridurre drasticamente il tempo di ricostruzione di Swift. Probabilmente otterrai anche miglioramenti nei tempi di ricostruzione di Swift se non è necessario prendere in considerazione tutte le funzioni interne dell'intero sistema.

I moduli sembrano essere dove Swift vuole andare per l'organizzazione del programma. Non sto dicendo che sono molto forti ancora; sembrano ancora piuttosto confusi. Ma sono probabilmente lo strumento migliore per questo lavoro. La buona notizia è che dovresti essere in grado di migrare frammentario quando incontri problemi. Non dovresti dover rielaborare in modo massiccio l'intero progetto in una volta sola. Sicuramente non consiglierei di scappare e creare 100 moduli diversi il primo giorno. Cerca solo alcuni grandi che potrebbero segmentare bene il tuo programma.