iOS: disponibilità del didReceiveMemoryWarning:

Se l'utente ha lasciato alcune applicazioni aprire avrete poca memoria a disposizione. Così a volte didReceiveMemoryWarningpuò essere chiamato dal sistema solo dopo 1 MB di utilizzo.

Il sistema chiama questo metodo su tutti i controller di vista, se si inserisce un NSLog in ciascuno dei vostri controller di vista, si noterà che.

Quindi automaticamente il metodo viewDidUnloadverrà chiamato dal sistema su tutti i controller di vista (non dealloc). Quindi devi mettere tutte le istruzioni deallocazione in là.

Devi fare un sacco di esperimenti, perché se la vostra applicazione è complessa si faccia sacco di incidenti prima di riuscire bene.

AGGIORNAMENTO Come di iOS 6, UIViewControllervista non sono più scaricata in risposta ad avvisi di memoria. Invece solo fare del tuo meglio per liberare tutte le risorse che si può ragionevolmente ricreare (ad esempio, i dati memorizzati nella cache), quando didReceiveMemoryWarningviene chiamato.

UPDATE
Ho scritto la mia risposta originale quando ero un giovane arrabbiato; i tempi sono cambiati e in fondo, è sbagliato.

Se si dispone di un app con un solo controller della vista e si riceve un avviso di memoria, non c'è molto che si può fare. Ma le cose cambiano drasticamente se si dispone di più controller di vista, perché si può scaricare tutto lo stato associato con i controllori non in primo piano. In realtà [UIViewController didReceiveMemoryWarning]vi prod nella direzione giusta scaricando le vostre opinioni non visibili per voi (sorpresa!). Quando il controller della vista in primo piano è respinta, la vista sottostante viene ricaricato e al massimo l'utente dovrebbe essere solo a conoscenza di un ritardo, anche se internamente la vostra applicazione potrebbe aver fatto un riavvio completo.

Questo non è un dettaglio si può facilmente retrofit, è necessario tenere utilizzo della memoria in mente fin dall'inizio e progettare il multiview applicazione in modo pulito scarrabili UIViewControllerpezzi. In realtà vale la pena di mantenere il codice compatibile con il simulatore solo per usare la sua funzione di avviso di memoria.

Quando la memoria è abbondante, niente viene scaricato e tutto è liscia come la seta, e quando la memoria è bassa le cose continuare a lavorare, anche se più lentamente. Ora direi che questa soluzione al problema memoria finita è l'ideale.

Per usufruire di questo salone di memoria di trucco, sovraccaricare i UIViewControllermetodi viewDidLoad, viewDidUnloade viewWillUnload(iOS5, utile se lo stato lo scarico richiede l'immagine per esistono ancora, per esempio, se non si vuole far trapelare le texture OpenGL e il rendering di buffer, in iOS4 è possibile simulare questo da sovraccarico didReceiveMemoryWarninge il monitoraggio visibilità del tuo vista).

ORIGINALE, risposta più bilioso

didReceiveMemoryWarning è assolutamente inutile.

Non c'è alcuna garanzia che se si liberare memoria (anche tutto) che non sarà possibile ottenere uccisi.

Nella mia esperienza amara di solito funziona così su 2.x / 3.0:

1. mediaserverd perde un po 'di memoria

2. la mia app viene ucciso

Purtroppo, il mietitore non pensa mai di uccidere mediaserverd.

Quindi, se l'utilizzo della memoria non è colpa tua, hai davvero avuto solo due scelte:

1. chiedere all'utente di riavviare il sistema (utente si assume è colpa tua, scrive una recensione feroce)

2. spero che il colpevole si blocca (mediaserverd obbliga spesso!)

Lo scopo di didReceiveMemoryWarning è quello di dare la possibilità di liberare la memoria o pop di vista al fine di evitare un incidente. Non riceverai in qualsiasi punto prevedibile perché dipende da ciò che l'utente sta facendo. Ad esempio, se l'utente sta ascoltando l'iPod, si riduce la memoria disponibile e riceverai prima.

La regola generale è che si hanno circa 8 MB di RAM con cui lavorare. Quando si arriva vicino a quello ci si può aspettare l'evento di essere sollevato. Se sta assumendo up che tanta RAM deliberatamente si dovrebbe avere un piano per fare qualcosa al riguardo.