Статические переменные управления памятью Objective-C/iPhone

Вы можете не выпускать их, и это нормально, поскольку приложение все равно закрывается. Какао на iPhone уже делает это, он не удаляет все полностью, он просто позволяет приложению улететь.

Или вы можете удалить его из appWillTerminate или другой функции выключения.

Вы захотите взглянуть на «Создание синглтона» в центре разработки iPhone, чтобы узнать, как правильно реализовать этот шаблон. Вы не будете выпускать свой синглтон, просто позволите ему умереть, когда приложение завершится.

Кроме того, если вы многопоточны, вы, вероятно, захотите заключить этот выделенный адрес в @synchronize (self) {}

Здесь полный текст:

Некоторые классы Foundation и Application Kit создать синглтон объекты. В «строгой» реализации единственный допустимый экземпляр класса в текущем процесс. Но вы также можете иметь больше гибкая реализация singleton в который фабричный метод всегда возвращает тот же экземпляр, но вы можете выделить и инициализировать дополнительные Класс NSFileManager подходит этот последний шаблон, тогда как UIAapplication соответствует первому. когда вы просите экземпляр UIApplication, он передает вам ссылка на единственный экземпляр, выделить и инициализировать его, если он еще не существует.

Одноэлементный объект действует как своего рода центр управления, направляющий или координирует услуги учебный класс. Ваш класс должен генерировать одиночный экземпляр, а не несколько случаев, когда есть концептуально только один экземпляр (как с, например, NSWorkspace). Вы используйте экземпляры singleton, а не фабричные методы или функции, когда возможно, что может быть несколько экземпляров в один день.

Чтобы создать синглтон в качестве единственного допустимый экземпляр класса в текущий процесс, вам необходимо иметь реализация похожа на Листинг 2-15. Этот код выполняет следующие действия:

Объявляет статический экземпляр вашего одиночный объект и инициализируйте его ноль. В вашем методе фабрики классов для класс (названный примерно так «SharedInstance» или «sharedManager»), генерировать экземпляр класса, но только если статический экземпляр равен нулю. Переопределите метод allocWithZone: на убедитесь, что другой экземпляр не выделяется, если кто-то пытается выделить и инициализировать экземпляр вашего class напрямую вместо использования метод фабрики классов. Вместо этого просто вернуть общий объект. Осуществлять методы базового протокола copyWithZone :, освободить, сохранить, keepCount и autorelease для выполнения соответствующие вещи для обеспечения синглтона статус. (Последние четыре из них методы применяются к коду, управляемому памятью, а не к коду со сборкой мусора.) Листинг 2-15. Строгая реализация статический синглтон MyGizmoClass

 *sharedGizmoManager = nil;  
 + (MyGizmoClass*)sharedManager {
     if (sharedGizmoManager == nil) {
         sharedGizmoManager = [[super allocWithZone:NULL] init];
     }
     return sharedGizmoManager; }  
 + (id)allocWithZone:(NSZone *)zone {
     return [[self sharedManager] retain]; }

 - (id)copyWithZone:(NSZone *)zone {
     return self; }

 - (id)retain {
     return self; }

 - (NSUInteger)retainCount {
     return NSUIntegerMax;  //denotes an object that cannot be released }

 - (void)release {
     //do nothing }

 - (id)autorelease {
     return self; }

Если вам нужен синглтон-экземпляр (созданный и контролируется фабрикой классов метод), но также есть возможность при необходимости создайте другие экземпляры через выделение и инициализацию, не переопределяйте allocWithZone: и другие методы, следующие за ним, как показано на Листинг 2-15.

ОБНОВЛЕНИЕ: Теперь есть гораздо более простой способ создать синглтон

+ (MyClass*)sharedInstance
{
  static MyClass* _sharedInstance = nil;
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
    _sharedInstance = [[MyClass alloc] init];
  });

  return _sharedInstance;
}

. Используя этот новый стиль, вам не нужно беспокоиться о @syncronize или переопределении методы управления памятью.