Programování pro iOS - 31. Správa paměti v rámcích - MujMAC.cz - Apple, Mac OS X, Apple iPod

2. března 2011, 00.00 | Zařízení s operačním systémem iOS mají obvykle nouzi o operační paměť. Třída UIViewController – a díky dědičnosti také všechny její podtřídy – tento požadavek pomáhá plnit zajímavým a docela efektivním způsobem, který si dnes vysvětlíme podrobněji.

Jak už jsme si ukázali dříve při psaní naší bouřlivé aplikace, zařízení s operačním systémem iOS obvykle mají poměrně nouzi o operační paměť; při programování to musíme brát v úvahu a snažit se sestavovat takový kód, který není pokud možno na operační paměť příliš náročný, a hlavně který v případě potřeby může uvolnit z operační paměti všechny objekty, které lze snadno programově obnovit.

Automatické uvolňování rámců

Třída UIViewController – a díky dědičnosti také všechny její podtřídy – tento požadavek pomáhá plnit zajímavým a docela efektivním způsobem: pokud se aplikace od operačního systému dozví, že je zapotřebí řešit dočasný nedostatek paměti, "momentálně neviditelné" řídicí objekty rámců prostě a jednoduše uvolní své rámce, tedy fakticky provedou příkaz

self.view=nil;

Jelikož atribut view je definován s modifikátorem retain:

@property(nonatomic, retain) UIView *view;

znamená to, že kořenový rámec dostane zprávu release a (není-li držen ještě odjinud, a to by být zásadně neměl) bude, spolu se všemi rámci, jež jsou mu v hierarchii podřízeny, uvolněn z paměti. Řídicí objekt pak dostane ještě zprávu

-(void)viewDidUnload;

v jejíž implementaci může uvolnit a/nebo vynulovat vlastní případné odkazy na rámce. Pokud jsme v metodě viewDidLoad vytvořili nějaké pomocné paměťové oblasti, zde je zapotřebí je uvolnit.

Nové načtení rámců, odkazy na rámce z kódu

Samozřejmě, že jakmile bude příště kořenový rámec zapotřebí – tedy až kdokoli řídicímu objektu pošle zprávu view, nejspíše ve chvíli, kdy bude třeba rámce zobrazit – řídicí objekt je automaticky znovu načte, stejně jako napoprvé po jeho vytvoření. Pošle tedy sám sobě zprávu loadView, jejíž standardní implementace rámce načte z odpovídajícího NIBu (případně, pokud jsme tuto zprávu překryli vlastní implementací, jež rámce vytvoří nějakým jiným způsobem), a potom ještě pošle sám sobě zprávu viewDidLoad pro inicializaci nově načtených rámců.

Je tedy vždy třeba mít na paměti, že i pokud sám řídicí objekt zůstává v paměti (a např. u řídicího objektu kořenového rámce aplikace to platí absolutně – ten v běžných konfiguracích není uvolněn nikdy, dokud aplikace běží, a mj. také tedy ani nemá smysl pro něj implementovat korektní metodu dealloc), rámce, jež reprezentují jeho grafické uživatelské rozhraní, mohou být opakovaně uvolňovány a znovu načítány.

Speciálně z toho plyne, že pokud používáme objekty grafického uživatelského rozhraní pro vlastní ukládání dat (což není správné a což bychom obecně dělat neměli – data patří do "modelu" ve struktuře MVC, nikoli do "view"), musíme si na to dát pozor – a také si musíme dát pozor na to, aby naše outlety odpovídající objekt přidržely, dokud jeho hodnotu nenačteme.

Obecně je kupříkladu zcela v pořádku takováto deklarace

@interface MyVC:UIViewController
@property (assign) IBOutlet UITextView *text;
@end

v níž "text" je propojen v NIBu s nějakým textovým polem uvnitř hierarchie rámců, již řídicí objekt spravuje. To proto, že textové pole je součástí hierarchie rámců, a nemusíme je tedy "retainovat"; o to se postará nadřízený rámec sám (jak už víme dávno, rámec vždy "retainuje" všechna svá subview).

Jenže pozor! Musíme si naopak dát důkladný pozor na to, abychom k takovémuto objektu nepřistupovali v době, kdy jsou rámce odstraněny – pokud bychom měli někde v kódu nějaké text.text=@"" a pokud by tento kód proběhl po uvolnění rámců, aplikace by samozřejmě spadla! Je proto v takovémto případě rozhodně žádoucí zároveň implementovat metodu viewDidUnload nějak zhruba takto:

-(void)viewDidUnload
  [super viewDidUnload];
  self.text=nil;
}

Pak je vše v pořádku – pokud jsou rámce pro úsporu paměti odstraněny, je obsahem proměnné text hodnota nil, a příkaz text.text=@"" je naprosto v pořádku (a neudělá nic). Při příštím načtení NIBu se proměnná text automaticky opět naváže na odpovídající objekt.

Ale ještě jednou pozor! Pokud totiž používáme pro outlety obyčejné instanční proměnné (a nikoli atributy, deklarované pomocí direktivy @property), zdálo by se, že adekvátní kód bude

-(void)viewDidUnload
  ...
  text=nil; // probably wrong
}

jenže tomu tak není. Musíme mít totiž na paměti to, že při načítání NIBu se outlety navazují pomocí metody setValue:forKey: z mechanismu KVC ("Key-Value Coding"), který jsme si podrobněji popisovali před časem. V praxi to znamená, že se při nastavení vazby provede implicitní "retain" (stejně, jako kdybychom použili atribut deklarovaný jako @property (retain) ...). Proto je zapotřebí v těchto případech objekt buď explicitně uvolnit

-(void)viewDidUnload
  ...
  [text release],text=nil; // better
}

nebo, což je asi nejflexibilnější a nejspolehlivější, byť malinko nepohodlné, použít opět KVC:

-(void)viewDidUnload
  ...
  [self setValue:nil forKey:@"text"]; // probably best
}

jež má navíc tu výhodu, že bude korektně pracovat i v případě, pokud někdy později instanční proměnnou nahradíme deklarovaným atributem.

Údaje, uložené v rámcích

Další potenciální problém (o němž jsme se již zběžně zmínili) nastane v případě, že obsah nějakého prvku GUI – např. právě textového pole – neudržujeme průběžně v modelu (jako by tomu vždy správně mělo být). Při nedostatku paměti totiž pak ve chvíli, kdy naše rámce nejsou viditelné (např. proto, že jsou překryty jinými rámci, instalovanými pomocí funkce presentModalViewController:animated:), můžeme o textové pole – a tedy i o jeho obsah – nenávratně přijít!

Pokud máme důvody k tomu, abychom hodnoty třeba i jen dočasně uchovávali v GUI a nikoli v modelu, musíme se tedy navíc postarat (a) o to, aby naše textové pole přežilo až do chvíle, kdy se viewDidUnload zavolá, (b) zde musíme jeho hodnotu uložit do modelu, (c) a pak je nesmíme zapomenout uvolnit, aby zbytečně nezabíralo paměť. K tomu ještě navíc samozřejmě také nesmíme zapomenout použít metodu viewDidLoad pro inicializaci nově vytvořeného textového pole.

Celé by to tedy mohlo vypadat nějak takto, pokud si pro zjednodušení model implementujeme jako další atribut řídicího objektu (v praxi bychom to tak samozřejmě asi nedělali, model v reálných aplikacích je téměř vždy reprezentován samostatným objektem či spíše skupinou objektů):

@interface MyVC:UIViewController
@property (retain) IBOutlet UITextView *text;
@property (copy) NSString *model;
@end
@implementation MyVC
@synthesize text,model;
...
-(void)viewDidLoad {
  if (self.model) self.text.text=self.model;
}
-(void)viewDidUnload
  self.model=self.text.text;
  self.text=nil;
}
...
@end