11

Scenario: Abbiamo un progetto XCode per un gioco iOS con circa 7000+ file.Miglioramento dei tempi di costruzione su XCode 4.5 per un enorme progetto di gioco

Solo 1000+ file sono codice. Il resto di loro sono immagini, suoni, dati di livello, XIB, plists, file di configurazione, ecc.

È un'app universale quindi, abbiamo un set separato di risorse per il vecchio iPhone, retina iPhone, iPad ecc. Abbiamo anche PNG e PVRTC per alcune cose come le immagini BG ecc. Per fare il miglior uso di hardware diverso.

Problema:

In questo momento il progetto dura circa

42 secondi per pulire (Cmd - Shift - K)

8,3 minuti per un completo ricostruzione (Cmd - B) (Durante la ricostruzione, metà della barra di avanzamento si riempie in 1 min)

aaaand ... 5 minuti 36 per la corsa (Cmd - R) ??

Successivamente, ho premuto "Stop" e fatto clic su "Esegui" di nuovo senza fare assolutamente qualcos'altro. e ci sono voluti 2 minuti e 40 secondi per "Esegui di nuovo"

Ho visto anche le risorse copiate di nuovo, alcuni file di nuovo creati come mostrato da XCode sopra la barra di avanzamento.

Qualsiasi soluzione per ridurre il tempo in una qualsiasi di queste fasi è molto apprezzata. Per favore ?

P.S. Il progetto è stato avviato durante i 3 giorni di XCode e abbiamo aggiornato automaticamente il file xcodeproj ogni volta che esce un nuovo XCode.

+0

Non sto cercando un pulsante magico. Ma dato che XCode non mi fornisce alcuna informazione durante la fase di compilazione/compilazione, sto cercando soluzioni come: esiste una modalità dettagliata che posso attivare ?, fare build a riga di comando mi aiuta a risolvere perché ci vuole così tanto tempo? e così via –

+0

Hai qualche aggiornamento per noi, in merito a quali fasi di compilazione sono le più costose in base al log di costruzione? – Mecki

+0

@Mecki grazie mille per la tua direzione! Sono riuscito a capire alcuni passaggi per ridurre il tempo di costruzione/esecuzione di metà o 1/3. 1) La convalida del prodotto richiedeva molto tempo. Qualcuno aveva impostato la validazione del prodotto costruito 'ON' nelle impostazioni di destinazione. L'ho spento. (Atleast per 'Debug' per ora) 2) Trovato che la generazione di file dSYM richiedeva troppo tempo. Quindi seguiva questa domanda - http://stackoverflow.com/q/8454937/121067 3) Inoltre c'erano troppi avvisi (1000+) in tutto il progetto a causa di pratiche di codifica incurante. Basta averne disattivati ​​molti manualmente. –

risposta

6

Non è possibile risolvere un problema se la causa del problema è sconosciuta. "La mia macchina non parte più, c'è un modo per farla ripartire?"; molto probabilmente, ma solo se è nota la ragione per cui attualmente rifiuta l'avvio. Sembra un po 'come speri che ci sia un interruttore magico in Xcode chiamato "Build fast" e attivandolo, tutto diventa molto più veloce.Se ci fosse un tale switch, non pensi che sarebbe abilitato di default? Non pensi che sarebbe in realtà sempre abilitato?

Mi chiedo anche perché hai codificato questa domanda con "compiler" e "compiler-optimization". Secondo la tua stessa affermazione, la compilazione richiede solo un minuto su un tempo di costruzione di 8,3 minuti, quindi in che modo ridurre ulteriormente i tempi di compilazione rende il processo complessivo molto più veloce? Anche se il tempo di compilazione è stato ridotto a zero, questo ti lascerebbe comunque con 7.3 minuti di tempo di costruzione. Non ottimizzare alla fine sbagliata.

È come l'ottimizzazione del codice. Se il tuo codice è troppo lento, tutte le ottimizzazioni sono inutili se non lo fai dove nel tuo codice viene speso la maggior parte del tuo tempo. Ottimizzare un pezzo di codice per eseguire dieci volte più velocemente non farà nulla per le prestazioni complessive se solo lo 0,1% di tutti i tempi viene speso in quel pezzo di codice. Il primo passo dell'ottimizzazione del codice è la profilazione del codice e la scoperta di quanto tempo è trascorso su quale pezzo di codice.

Quindi, per rendere più rapido il processo di creazione, il primo e più importante passaggio è scoprire perché esattamente i tempi di costruzione sono lenti al momento. Senza quella conoscenza, tutte le risposte che le persone potrebbero dare qui stanno solo indovinando nel blu. Una volta che sai esattamente dove si trova il problema, puoi tornare indietro e chiedere precisamente come fare un passo più veloce. Si inizia ottimizzando il passo più lento, poi il secondo più lento e così via.

Date un'occhiata al log di compilazione in Xcode

enter image description here

Assicurarsi di selezionare "Tutti i messaggi", altrimenti si vedrà solo avvertimenti ed errori, o solo errori. Ora avvia una nuova build, seleziona il nuovo log che si apre a sinistra e continua a monitorare questo registro. Vedrai esattamente quando Xcode sta avviando un'operazione e quando si avvicina alla prossima operazione. Questo dovrebbe darti una prima impressione di quali compiti richiedono molto tempo per essere completati. E una volta che ci hai detto quali sono quelle attività, possiamo iniziare a formulare suggerimenti su come potresti essere in grado di rendere questa attività un po 'più veloce.

+0

Fantastico, grazie per il registro Compile. Stavo infatti cercando dei modi in cui posso capire in quali fasi, il compilatore impiega più tempo. Lo eseguirò e ti farò sapere. –

+2

-1. Gli ultimi due paragrafi sono utili, il resto mi viene incontro come maleducato e condiscendente. – TarkaDaal

+2

@TarkaDaal Sì, sarebbe certamente meno maleducato se avessi appena chiuso questa domanda, come fa la maggior parte delle persone se la domanda non contiene abbastanza informazioni per essere risolta. Preferisco piuttosto educare le persone a fare buone domande in futuro, dal momento che li aiuterà a ottenere risposte migliori e ad ottenere quelle più velocemente. Il PO non lo considera maleducato e piuttosto considero il tuo commento molto scortese. – Mecki

7

Quello che stai cercando è migliorare la compilazione e il tempo di avvio per debug, giusto? Che ne dici di creare un target diverso per ogni piattaforma? Quindi mantieni lo stesso codice ma impacchetti solo un sottoinsieme di risorse a scopo di debug a seconda del dispositivo di debug.

Per fare ciò, andare sul target attuale, fare clic con il tasto destro e duplicare. Mantieni intatto il tuo vero bersaglio, è quello grasso! Per il nuovo target, diciamo che è retina per iPad, vai a "crea fasi" -> "copia risorse bundle" e rimuovi tutte le risorse che non sono correlate a Retina iPad. Fai lo stesso per ogni piattaforma.

Quindi in alto a sinistra di Xcode, selezionare il target corretto per il dispositivo specifico. Forse, puoi definire quale dispositivo è accettato per un bersaglio.

Se si utilizza l'integrazione continua, lasciare che la macchina di compilazione compilare il bersaglio grasso di notte.

+1

Perché avrebbe bisogno di un target diverso per piattaforma? Puoi semplicemente dire a Xcode di costruire solo per la tua piattaforma corrente quando avvii il target in un debugger (questo è il BTW predefinito), quindi Xcode non verrà realmente creato per tutte le piattaforme a meno che non si faccia una build di distribuzione. Anche il tuo suggerimento influenza solo il tempo di compilazione e l'interrogante ha detto che compilare è solo uno di quegli 8+ minuti. Anche se è possibile effettuare l'istante di compilazione, deve comunque attendere 7 minuti. – Mecki

+0

No, con un target diverso, puoi dire che non desideri che le risorse della retina iPhone nell'app vengano inviate al tuo dispositivo retina iPad. L'ipa sarà più piccolo e più veloce da caricare sul tuo iPad. La chiave qui è ** risorse ** –

+0

Questo è solo il caso, se ci sono risorse diverse per dispositivi retina e non-retina, il che potrebbe non essere il caso. Per esempio. per risparmiare spazio, tutte le immagini possono esistere solo in qualità di retina e vengono ridimensionate al caricamento o anche quando vengono disegnate. Soprattutto per i giochi OpenGL, dove la maggior parte delle risorse sono caricate come texture, non è raro avere un solo set di texture per entrambi i dispositivi (le texture retina spesso ti fanno guadagnare poco o niente, ulteriore OpenGL può essere utilizzato per ridimensionare le trame sulla GPU in quasi non c'è tempo). – Mecki