2012-04-13 2 views
0

Мы интегрировали facebook в приложение для загрузки фотографий. Это отлично работает, но в последнее время с помощью инструмента XCode Alloc для отслеживания утечек памяти мы обнаружили то, что кажется ужасным. Мы запускаем процесс загрузки в отдельном потоке отправки. Затем мы загружаем наш метод загрузки facebook в пул автоматического выпуска. Когда вызывается загрузка, изображение переходит к соответствующему профилю FB. Но при загрузке NSKeyValueMethodForPattern создается и хранится около 500 КБ. Затем большой, - [NSConcreteMutableData appendBytes: length] get создается и потребляет около 4,5 МБ в зависимости от размера изображения. Эти два создаются для каждого загруженного изображения и НИКОГДА НЕ РАСПРОСТРАНЯЕТСЯ! Я в затруднении с этим. Точки Alloc инструмент к ниже как виновникаУжасная утечка памяти интеграции IOS Facebook

- (FBRequest*)openUrl:(NSString *)url params:(NSMutableDictionary *)params 
      httpMethod:(NSString *)httpMethod delegate:(id<FBRequestDelegate>)delegate 
{ 
    [params setValue:@"json" forKey:@"format"]; 
    [params setValue:kSDK forKey:@"sdk"]; 
    [params setValue:kSDKVersion forKey:@"sdk_version"]; 
    if ([self isSessionValid]) { 
     [params setValue:self.accessToken forKey:@"access_token"]; 
    } 

    [_request release]; 
    _request = [[FBRequest getRequestWithParams:params 
            httpMethod:httpMethod 
             delegate:delegate 
            requestURL:url] retain]; 
    [_request connect]; // <<<< SAYING THIS IS 100% cause 
    return _request; 
} 

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

backgroundQueue = dispatch_queue_create("com.somecomp.appnameo.bgqueue", NULL); 

dispatch_async(backgroundQueue, ^(void) { 
    NSAutoreleasePool *loopPool = [[NSAutoreleasePool alloc] init]; 
    NSData *imageNSData = [NSData dataWithContentsOfFile:[NSString stringWithFormat:@"%@/%@", docDir, self.fileName]]; 
    UIImage *img = [[UIImage alloc] initWithData:imageNSData]; 

    fbResponse = 0; 
    //[facebook requestWithGraphPath:@"me" andDelegate:self]; 
    [[delegate facebook] requestWithGraphPath:@"me/permissions" andDelegate:self]; 
    NSMutableDictionary *params = [NSMutableDictionary dictionaryWithObjectsAndKeys: 
            //@"Sent From Some APP!", @"name", 
            self.postTitle, @"caption", 
            // string, @"description", 
            img, @"picture", 
            //@"my photo's caption text here.", @"message", 
            nil]; 

    [img release]; 

    [[delegate facebook] requestWithMethodName:@"photos.upload" 
            andParams:params 
           andHttpMethod:@"POST" 
            andDelegate:self]; 
    [loopPool drain]; 
}); 

Есть ли что-нибудь еще, что я могу сделать, чтобы освободить этих меморитов? Я не новичок в этом, но я не согласен с этим. Любая помощь здесь будет фантастической!

Спасибо! - Jim

+0

Когда вы в последний раз обновили свой код FBConnect? Посмотрите на этот метод на github, строка 167: https://github.com/facebook/facebook-ios-sdk/blob/master/src/Facebook.m – danh

+0

Я только что обновил код прошлой ночью и имел все виды рекурсии проблемы, узнайте, что я обновился прямо в ошибке рекурсии. С тех пор я снова обновляюсь после потери 5 часов в моей жизни. По-прежнему имеет ту же проблему. – mejim707

ответ

0

Посмотрите мои комментарии о том, что код FBConnect устарел, но я сомневаюсь, что более старые версии имели такую ​​вопиющую утечку (для каждого подключения).

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

+0

Вы здесь очень хорошо делаете. Я попытаюсь отправить это обратно в основное, но я помещаю его в дополнительный поток, потому что я использую таймер ожидания, чтобы дождаться ответа от Facebook, прежде чем продолжить. Я хочу отметить, что фотографии были загружены или нет. Если вы не загружены, я хочу предупредить пользователя. Может быть, более подходящий метод? Таймеры, если они используются в основном потоке, заставляют приложение приостанавливаться, пока выполняется ожидание. Однако на вторичном потоке ожидания прозрачны для пользователя, и приложение работает быстро и без проблем. Спасибо! – mejim707

+0

Я пробовал это, и даже если я не загружаю его, он строит распределение людей точно так же. 8 изображений = около 80 МБ. Я понятия не имею, что делать. – mejim707

+0

Запускаете ли вы статический анализатор? Product-> Анализ. Это может дать некоторые дополнительные подсказки. – danh