2011-09-30 10 views
7

Sto creando un'applicazione con più animazioni. Ci sono 50 pagine e su ogni pagina c'è un'animazione diversa e ogni animazione usa molte immagini.Come risolvere il crash di memoria

Sto usando UIPresentModelViewController per la presentazione delle viste e sto cambiando le immagini usando NSTimer.

Quando ho swipe continuamente l'applicazione si blocca con questo messaggio: -

Program received signal: “0”. 
Data Formatters temporarily unavailable, will re-try after a 'continue'. 

(Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib") 

ho cercato un sacco, ma non abbiamo trovato nessuna soluzioni adeguate a questo problema.

+1

Hai provato a eseguire "Analyzer" per vedere se rileva eventuali perdite? – 5StringRyan

+0

@HansGruber: Sì, abbiamo provato a funzionare con perdite di memoria, ma non abbiamo trovato alcuna fuga. Qualsiasi altra soluzione sullo stesso per favore .. Grazie .. –

+0

L'analizzatore e le perdite sono strumenti diversi. C'è un analizzatore di clang statico che puoi usare per trovare non solo perdite di memoria ma anche altri punti problematici nel codice. È una buona idea eseguirlo periodicamente. Si noti che l'analizzatore clang statico non funziona sotto gli strumenti e non è uno strumento di profilazione. Lo troverai sotto il menu Prodotti. "Prodotti> Analizza". Le perdite invece sono uno strumento di profilazione per monitorare gli oggetti per vedere se non vengono rilasciati dopo che tutti i riferimenti all'oggetto sono stati rimossi. – Sam

risposta

0

Basta controllare all'interno del codice che si stanno facendo un errore con l'aggiunta di nuova visione ogni volta ma ha dimenticato di rilasciarlo ...

+0

Grazie per la tua risposta, ma abbiamo usato IBOutlet in XIB e modificando le immagini su di esso .... Per favore suggeriscici qualcosa di più .. Grazie .. –

+0

Puoi aggiungere un po 'di codice, quindi è facile rilevare l'errore . –

0

È necessario guardare (e forse post) l'analisi dello stack quando si crash. E il codice che cambia l'immagine. Questo suona come la memoria gonfia (non una vera perdita in quanto qualcuno si riferisce ancora alla memoria). La voce di menu Analizza potrebbe catturare qualcosa (e dovresti eseguirla definitivamente), ma potrebbe essere necessario eseguire lo strumento di assegnazione e controllare i controlli di heap. Vedi http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ per ulteriori informazioni.

0

Questo suona come una sovrapposizione di stack per me. Nella sezione "Other C Flags" delle impostazioni del linguaggio C/C++ del progetto, aggiungere un flag per "-fstack-check" e vedere se questo restituisce una ricorsione indesiderata.

0

Il segnale 0 è in genere dovuto alla memoria bassa poiché l'app utilizza troppa memoria. Controlla se il metodo di avviso memoria è chiamato o meno.

thingy dati formattatore è riuscito a caricare potrebbe essere dovuto al non c'è abbastanza memoria per caricare esso ..

+0

Questa risposta è corretta, se ottieni un segnale 0 hai esaurito tutta la memoria dell'app disponibile. È necessario tornare indietro e riscrivere il codice in modo che non tenga tutte le immagini decompresse nella memoria allo stesso tempo. Questa è la causa più probabile di esaurimento della memoria, perché le immagini decompresse sono ENORMI! – MoDJ

0

50 viste come te descrivono suoni come un grande spreco di memoria. Quindi sospetto che la gestione della memoria stia scaricando alcune visualizzazioni. Poi, quando il tuo programma ha bisogno delle viste, non ci sono e il tuo programma si arresta in modo anomalo. Il messaggio di errore non si adatta perfettamente a questo, ma potrebbe non dirti esattamente quale sia il problema.

Considerare il seguente scenario possibile e vedere se si adatta a come è stato codificato questo programma.

Per consentire al sistema operativo di gestire la memoria, è possibile scaricare le viste e ricaricarle se necessario. Al termine, vengono richiamati i metodi viewDidUnload, loadView e viewDidLoad.

viewDidUnload:

Questo metodo è chiamato come controparte del metodo viewDidLoad. Viene chiamato durante le condizioni di memoria insufficiente quando il controller di visualizzazione deve rilasciare la sua vista e tutti gli oggetti associati a quella vista per liberare memoria. Poiché i controller di visualizzazione spesso memorizzano riferimenti a viste e altri oggetti correlati alla vista, è necessario utilizzare questo metodo per rinunciare alla proprietà in tali oggetti in modo che la memoria per essi possa essere recuperata. Dovresti farlo solo per oggetti che puoi facilmente ricreare in seguito, nel tuo metodo viewDidLoad o da altre parti della tua applicazione. Non utilizzare questo metodo per rilasciare dati utente o altre informazioni che non possono essere facilmente ricreate.

loadview:

Il controller di visualizzare le chiamate questo metodo quando la proprietà View è richiesta ma è attualmente pari a zero. Se si creano le viste manualmente, è necessario sovrascrivere questo metodo e utilizzarlo per creare le viste. Se si utilizza Interface Builder per creare le viste e inizializzare il controller della vista, ovvero inizializzare la vista utilizzando il metodo initWithNibName: bundle:, impostare direttamente le proprietà nibName e nibBundle oppure creare entrambe le viste e il controller di visualizzazione in Interface Builder- quindi non devi ignorare questo metodo.

Controllare l'UIView Classe di riferimento -

viewDidLoad:

Questo metodo viene chiamato dopo che il controller della vista ha caricato i suoi panorami associati nella memoria. Questo metodo viene chiamato indipendentemente dal fatto che le viste siano state memorizzate in un file pennino o create a livello di codice nel metodo loadView. Questo metodo è più comunemente utilizzato per eseguire ulteriori passaggi di inizializzazione su viste caricate dai file pennino.

È possibile che queste viste siano state inizializzate inavvertitamente nei metodi di inizializzazione anziché nei metodi loadView. Se l'operazione è stata eseguita, quando il sistema operativo scarica una vista (viene visualizzato viewDidUnload), la memoria associata alla vista e tutte le sottoview (tutte le immagini e le animazioni) verranno scaricate. Ciò consente di risparmiare memoria, ma quando è necessario riapparire una di quelle viste non caricate, loadView verrà chiamato per primo se la vista è stata precedentemente scaricata. Se la configurazione della vista viene eseguita nei metodi init piuttosto che in loadView, la vista non verrà nuovamente impostata. Ma se l'impostazione della vista viene eseguita in metodo loadView, può essere ripristinata dopo che la gestione della memoria lo ha scaricato.

+0

viewDidUnload è obsoleto in iOS 6.0. Le viste non vengono più eliminate in condizioni di memoria insufficiente e quindi questo metodo non viene mai chiamato. – Bastian

0

C'è un modo semplice per scoprire perdite difficili da trovare tramite gli strumenti delle perdite e così via: l'analizzatore Zombies. Mostra ogni memoria non collegata nel tuo programma e puoi facilmente individuare perdite e ottimizzare il codice in pochi minuti.

0

Se stai utilizzando molte immagini per una singola animazione, stai sbagliando. Dovresti avere una o più immagini molto grandi e quindi mostrare solo una parte di quell'immagine. In questo modo puoi caricare pochissime immagini, ma avere lo stesso effetto di avere molte immagini.

Cerca in cocos2d o in altri framework che sono popolari per la creazione di giochi, in quanto saranno molto più efficienti per le animazioni rispetto a UIKit.

0

Individuare il motivo di arresto anomalo della memoria con lo strumento Strumento e quindi rifattorizzare il codice con le migliori pratiche con il modello di progettazione consigliato. Non c'è una soluzione unica per questo. Grazie.

Problemi correlati