2009-03-23 5 views
6

У меня есть приложение для iPhone, которое получает предупреждения о памяти, поэтому я пытаюсь найти утечки, более эффективно использовать память и т. Д. С помощью инструментов. Помимо всего прочего, я пытаюсь вытащить любые объекты с автореализацией и заменить на ручные объекты alloc/init/release. Однако некоторые вызовы API не имеют версии «init» (см. Код ниже). Я правда есть некоторые основные недопонимания:Использование инструментов Утечки и объект Alloc: Являются ли автореализованные объекты подсчитаны как утечки?

  1. Если я называю в "по API и получить обратно по существу autoreleased объекты, могут ли эти объекты отображаются как течи инструменты? Кажется, что я вижу это поведение в Инструментах.

  2. Если да, то 2, следует ли игнорировать, если нет альтернативы «без авторекламы», и я использую API, который мне нужен? Кроме того, если этот код получает много имен, должен ли я полностью переосмыслить алгоритм?

Вот какой код полезности из моего приложения, получившего много имен. В основном определяет, являются ли две даты значимо «равными». Я оставил в коде с комментариями, чтобы вы могли видеть типы улучшений, которые я буду делать в своей кодовой базе. этот DID уменьшает утечки памяти при последующем запуске в Инструментах, когда я начал вручную создавать NSDate (и выпускать), которые помогли. Тем не менее, я до сих пор объекты дата компонентов, которые я считаю протечка ... но это API вызова (извините за код форматирования, но я не могу показаться, чтобы улучшить его на SO):

+ (BOOL)isDayEqualToDay:(NSDate*)date anotherDate:(NSDate*)anotherDate 
{ 

    NSCalendar *cal = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; 
    //NSCalendar *cal; 
    NSDateComponents *componentsFromDate, *componentsFromAnotherDate; 
    NSUInteger unitFlags = NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit;  
    //cal = [NSCalendar currentCalendar]; 
    componentsFromDate = [cal components:unitFlags fromDate:date]; 
    componentsFromAnotherDate = [cal components:unitFlags fromDate:anotherDate]; 

    BOOL bDatesEqual = ([componentsFromDate year] == [componentsFromAnotherDate year] && 
         [componentsFromDate month] == [componentsFromAnotherDate month] && 
         [componentsFromDate day] == [componentsFromAnotherDate day]); 

    [cal release]; 

    return bDatesEqual; 

    /* 
    return (
     [componentsFromDate year] == [componentsFromAnotherDate year] && 
     [componentsFromDate month] == [componentsFromAnotherDate month] && 
     [componentsFromDate day] == [componentsFromAnotherDate day] 
    );*/ 
} 

Я думаю, компонентыFromDate и componentsFromAnotherDate отображаются как утечки, но есть только объекты, по существу возвращенные из вызова API NSData (autoreleased). Не уверен, что еще я мог сделать, чтобы сделать это более эффективным, и я задаю себе вопрос о том, как лучше всего использовать инструменты. Предложения?

ответ

4

Автореализованный объект не должен отображаться как утечка памяти. Иногда API-интерфейсы имеют утечки памяти внутри них. Вы должны подать отчет об ошибке с помощью apple. Особенно подозрительны новые классы, такие как NSCalendar и NSDateComponenets.

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

3

При использовании таких вещей, как GCD, есть пул авторезистов, но вы не можете узнать, когда (если когда-либо) пул автозапуска по умолчанию сливается. Если вы уверены, что атореализованные объекты не выпускаются, убедитесь, что вы понимаете, что вы используете threading api. Если память обслуживает меня правильно, вызовы GCD (dispatch_async) сортируют для вас пулы авторефератов, НО фактическое истощение пула может занять много времени. С другой стороны, NSOperations позволяет вам создавать пулы автообновлений.

Я видел обнаружение утечки памяти в Инструментах, основанных на 10-секундных интервалах, приводит к ложным сообщениям об утечке памяти из-за продолжительной задержки до того, как пул автоматического выпуска был выведен из строя. Поэтому попробуйте обернуть нарушивший код в:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 
... [your code] ... 
[pool drain]; 

Я бы рекомендовал не пытаться заменить все автореализаторы на ручные версии. Использование autorelease приводит к подсчету баланса с сохранением/освобождением в одном месте. Создание объекта, а затем автореализация его сразу же предотвращает множество ошибок памяти, на мой взгляд. Быстро, легко. Вы будете забывать выпустить материал при выполнении ручных вызовов. Особенно опасны условия при ручном выпуске.

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

+0

Кажется, что нет возможности использовать инструменты для отладки GDC. Может быть, другой способ? –

 Смежные вопросы

  • Нет связанных вопросов^_^