Обновление освобожденного UIWebView из фонового потока

Я думаю, что ваш диагноз, вероятно, неверен, но давайте на мгновение представим, что это не так, и посмотрим, что вы можете с этим сделать.

Если проблема заключалась в доступе к веб-представлению после освобождения в ответ на последовательность вызовов, показанную выше, тогда этот вызов будет исходить от updateDirectionsWithHtml: через ссылку в self.directionsWebView. В этом случае вы должны просто убедиться, что вы не храните устаревший указатель, а устанавливаете его в nil. Тем не менее, я думаю, справедливо поспорить, что вы уже делаете это, так что проблема вряд ли в этом.

Если проблема заключалась в доступе к контроллеру после освобождения диспетчером местоположения, вызывающим метод делегата, то вы должны сначала разорвать связь. Что-то вроде [locationManager setDelegate:nil] должно остановить нежелательный вызов, даже если сам менеджер местоположения переживет ваш контроллер. Но опять же, я подозреваю, что вы уже выпускаете менеджер местоположений до того, как контроллер умирает, и это тоже не проблема.

В этом случае проблема, скорее всего, в другом месте, и, возможно, стоит рассмотреть сообщение об ошибке за чистую монету: возможно ли, что где-то вы вызываете UIKit из фонового потока? Сказать, что среда выполнения запуталась в этом, потому что вы ранее были в фоновом потоке, кажется мне немного сомнительным. Эта ошибка выглядит так, как будто она исходит из чего-то довольно конкретного. Это место может содержать ошибки, но обычно лучше начать с предположения, что ОС работает лучше, чем собственный код.

Не видя остальной части кода, трудно понять, где может быть эта реальная проблема, если она действительно существует. Одна возможность, которая приходит на ум, заключается в том, что вы могли бы каким-то невинным образом использовать свойство, которое на самом деле где-то попадает в пользовательский интерфейс; но я признаю, что это просто праздное предположение.

Обновление:

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

Одна вещь, которая приходит мне в голову, заключается в том, что и performSelectorInBackground, и performSelectorOnMainThread сохраняют свой приемник до тех пор, пока селектор не завершит работу. Таким образом, время освобождения вашего контроллера, вероятно, в результате испорчено (если вы не форсируете его где-то с помощью чрезмерного выпуска).

Судя по трассировке стека, кажется, что dealloc на самом деле вызывается из фонового потока как часть его собственной очистки. Затем это вызывает различные вещи UIKit, которые объясняют ошибку блокировки потока. Но если вызывается performSelectorOnMainThread, это должно продлить время жизни контроллера до тех пор, пока он не вернется в основной поток. Так может быть, все-таки есть переиздание?

Обновление 2:

Это обсуждение становится немного рассеянным, но позвольте мне попытаться обобщить то, что, по моему мнению, происходит:

• Когда вы вызываете [self performSelectorInBackground:...], создается новый поток, и self получает сообщение retain потоком.
• Некоторое время спустя вы нажимаете кнопку «Назад», и ваш контроллер получает сообщение release. Однако, поскольку он был сохранен фоновым потоком, он еще не освобождается.
• Так или иначе фоновый поток завершается, и в этот момент он отправляет сообщение release контроллеру. Счетчик сохранения контроллера падает до 0, и вызывается его метод dealloc. Но поскольку это сообщение исходит из фонового потока, когда он пытается выполнять действия с пользовательским интерфейсом (удаление подвидов), вы получаете ошибку блокировки потока.

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

Интересный вопрос заключается не в том, почему фоновый поток отправляет release, что является естественной частью его жизненного цикла, а в том, почему это уменьшает количество сохранений до 0. Если поток действительно достигает performSelectorOnMainThread, должно быть еще одно сообщение retain, и ваш контроллер должен просуществовать достаточно долго, чтобы освободить основной поток, что должно быть в порядке.

Мне кажется, что есть две возможные причины: либо поток завершается преждевременно, либо он перевыпущен. Но если бы это было последнее, вы бы ожидали, что self уже достигнет dealloc до того, как поток завершится.

Итак, я думаю, вопрос в том, есть ли способ, которым updateDirectionsWithHtml мог бы выйти без вызова performSelectorOnMainThread? Или иначе, есть ли что-то еще, что может привести к преждевременному завершению потока?

Вы назначили себя делегатом на CLLocationManager. Делегаты почти всегда реализуются как слабые ссылки, то есть они не сохраняются. Это означает, что когда ваш контроллер представления выталкивается из стека навигации и освобождается, CLLocationManager теперь имеет неверный указатель, и вы получите сбои и всевозможные ужасные проблемы с отладкой.

Стандартной практикой является установка делегата CLLocationManager в nil в вашем методе dealloc, что гарантирует, что он не попытается вызвать вас после того, как вы ушли. то есть:

- (void)dealloc {
    locationManager.delegate = nil;
    [locationManager stopUpdatingLocation];
    [locationManager release];
    // ...
    [super dealloc];
}

Насколько я могу судить, ваш код performSelectorInBackground и т. д. в порядке, все эти вызовы сохраняют приемник до тех пор, пока селектор не вернется, поэтому я не думаю, что это источник ваших проблем.

Хорошо, я опубликую это как еще один ответ, так как мой предыдущий все еще действителен. Вы чрезмерно освобождаете пул автоматического выпуска.

[pool drain];
[pool release];

слив идентичен выпуску. Из документация:

В среде с подсчетом ссылок этот метод ведет себя так же, как и выпуск. Поскольку пул автоосвобождения не может быть сохранен (см. сохранение), это приводит к освобождению получателя.

Вы должны вызывать только освобождение или слив, а не то и другое одновременно. Чрезмерное освобождение пула приведет к двойному освобождению и снова случайным трудным для отладки проблемам.

Вы можете попробовать NSZombieEnabled для дальнейшей диагностики.

Проблема в том, что окончательный релиз (и, следовательно) Dealloc вызывается в потоке, отличном от основного потока. Есть несколько способов справиться с ситуацией. Один из них — выполнять фоновую обработку другого объекта, который имеет слабую ссылку на контроллер представления. Это может выглядеть примерно так:

@interface MyAppViewController : UIViewController {
  MyAppLocationUpdater *locationUpdater;
}
@property MyAppLocationUpdater* locationUpdater;
@end

@implementation MyAppViewController
@synthesize locationUpdater;
-(void)alloc
{
  [super alloc];
  locationUpdater = [[MyAppLocationUpdator alloc] init];
  locationUpdater.viewController = self;
}

-(void)dealloc
{
  locationUpdater.viewController = nil;
  [locationUpdater release];
}

-(void)locationManager:(CLLocationManager*)manager
   didUpdateToLocation:(CLLocation *)newLocation
          fromLocation:(CLLocation *)oldLocation
{
  [manager stopUpdatingLocation];
  [locationUpdater performSelectorInBackgroundThread: @selector(getDirectionsFromHere:) withObject:newLocation];
}
@end

@interface MyAppLocationUpdater : NSObject {
  // this reference is not retained or released, the view controller is responsible for clearing the field when it is deallocating
  volatile MyAppViewControler *viewController;
}
-(void)getDirectionsFromHere:(CLLocation *)newLocation;
@end

@implementation MyAppLocationUpdater
-(void)getDirectionsFromHere:(CLLocation *)newLocation
{
  // same stuff as before except
  if (viewController != nil) {
    [viewController performSelectorOnMainThread:@selector(updateDirectionsWithHtml:) withObject:directionsOutput waitUntilDone:NO];
  }
  // release pool as before
}

@end

Это может упростить использование NSOperation и NSOperationQueue. В этом случае вы должны настроить одну операцию для создания строки HTML и вторую операцию, которая зависит от первой и помещает HTML в веб-представление. Когда контроллер представления освобождается, вы должны отменить эту вторую операцию. Имейте в виду, что по-прежнему первая операция не может сохранять никаких ссылок на контроллер представления.

Вы пробовали включить проверку зомби? Вы говорите, что «[не выпускать объекты в Dealloc] не является решением, потому что, насколько я могу судить, я просто сливаю эти два объекта сейчас», но это точно описывает, как вы отправляете освобождение уже освобожденному объекту.

Один из способов проверить это — переопределить alloc/dealloc keep/release в ваших объектах проблем и зарегистрировать эти события. Затем вы сможете увидеть, где вызывается каждый из них, и, возможно, обнаружить ранее неизвестный релиз.

У меня также возникает эта проблема, когда я нажимаю кнопку «Назад» слишком рано. Что я сделал, так это добавил [self retain] в тело функции, которая будет вызываться в отдельном потоке, а в viewDidUnload добавил [self release]. Простой. Надеюсь, это тоже поможет.