Jeg er på en del av min utviklingsprosess for å spore opp krasj og minnelekkasjer. Som en strategi, setter du noen NSLog meldinger eller varsler om noe slikt til didReceiveMemoryWarning:? Dokumentasjonen for denne metoden er ganske sparsom. Er det riktig å si at før en krasj vil skje, vil UIViewController utløse denne metoden? Er det et utgangspunkt før du selv går videre med instrumenter?
iOS: hjelpsomhet didReceiveMemoryWarning:
OK, flere ting å merke seg:
- didReceiveMemoryWarning vil bli kalt før en ut-av-minne krasj. Ikke andre krasjer. Hvis du håndterer advarselen riktig og frigjøre minne, så kan du unngå out-of-minne tilstand og ikke krasje.
- Du kan manuelt utløse et minne advarsel i simulatoren under Hardware menyen. Anbefaler å gjøre dette for å teste din håndtering av didReceiveMemoryWarning.
- Instrumenter hjelper deg å feilsøke lekkasjer (men ikke alle av dem) - det er egentlig ikke så nyttig for krasj.
- Nei, jeg personlig bruker NSLog - jeg bare bruddpunkt minne advarsler når jeg debugging.
Hvis brukeren igjen noen apps åpner du vil ha svært lite minne til din disposisjon. Så noen ganger didReceiveMemoryWarningkan kalles av systemet bare etter 1 MB bruk.
Systemet kaller denne metoden på alle vis kontrollere, hvis du plasserer en NSLog i hver av dine vise kontrollerne, vil du legge merke til det.
Deretter automatisk metoden viewDidUnloadvil bli oppringt av systemet på alle vis kontrollere (ikke dealloc). Så du må legge alle fradeling instruksjoner der.
Du må gjøre en masse eksperimenter fordi hvis din app er komplekset vil du møte mange krasjer før håndtere det godt.
UPDATE
Per iOS 6, UIViewControllerutsikten ikke lenger er losset i respons til minne advarsler. I stedet bare gjøre ditt beste for å frigjøre noen ressurser du kan med rimelighet gjenskape (f.eks bufrede data) når didReceiveMemoryWarningkalles.
OPPDATERING
Jeg skrev mitt opprinnelige svar da jeg var en sint ung mann; tidene har forandret seg, og i utgangspunktet er det galt.
Hvis du har en app med en enkelt visning kontrolleren og du får et minne advarsel, er det ikke mye du kan gjøre. Men ting endrer seg dramatisk hvis du har flere visnings kontrollere, fordi du kan lesse alt staten knyttet til ikke-forreste kontrollere. Faktisk [UIViewController didReceiveMemoryWarning]vil prod deg i riktig retning ved lossing dine ikke-synlige visninger for deg (surprise!). Når det forreste visningen kontrolleren er avvist, er den underliggende syn på nytt og på det meste brukeren bør bare være klar over en forsinkelse selv om internt app kan ha gjort en fullstendig omstart.
Dette er ikke noen detaljer du enkelt kan ettermontere, må du holde minnebruken i tankene fra begynnelsen og designe din Multi app til rent unloadable UIViewControllerstykker. Faktisk er det verdt å holde koden din er kompatibel med simulator bare å bruke minnet advarsel funksjonen.
Når minnet er rikelig, er ingenting ubelastet og alt er silkemyk, og når det er lite minne ting fortsette å jobbe, om enn saktere. Nå vil jeg si at denne løsningen for å endelig minnet problemet er ideelt.
For å dra nytte av dette minnet privaten lure, overbelaste UIViewControllermetoder
viewDidLoad, viewDidUnloadog
viewWillUnload(iOS5, nyttig hvis lossing staten krever visningene for å fortsatt eksistere, for eksempel hvis du ikke vil lekke dine OpenGL teksturer og gjengi buffer, på iOS4 kan du simulere dette ved overbelastning didReceiveMemoryWarningog sporing ditt syn synlighet).
ORIGINAL, MER bilious ANSWER
didReceiveMemoryWarning er helt ubrukelig.
Det er ingen garanti for at hvis du frigjøre minne (selv alt av det) at du ikke vil bli drept.
I min bitter erfaring det vanligvis fungerer som dette på 2.x / 3.0:
mediaserverd lekker en haug med minne
min app blir drept
Dessverre reaper aldri tenker på å drepe mediaserverd.
Så hvis minnebruken er ikke din feil, du har egentlig bare to valg:
be brukeren om å starte på nytt (bruker antar det er din skyld, skriver en omfattende gjennomgang)
håper den skyldige krasjer (mediaserverd ofte forplikter!)
Formålet med didReceiveMemoryWarning er å gi deg en sjanse til å frigjøre minne eller pop visninger for å unngå en kollisjon. Du vil ikke motta den til enhver forutsigbar punktet fordi det avhenger av hva brukeren gjør. For eksempel, hvis brukeren er å lytte til iPod, er det mindre tilgjengelig minne og du vil motta det før.
Den generelle tommelfingerregel er at du har om 8 MB RAM for å arbeide med. Når du kommer nær at du kan forvente at arrangementet skal heves. Hvis du tar opp så mye RAM bevisst bør du ha en plan for å gjøre noe med det.













