NSOperationQueue партии SLRequests

Question

Привет для проекта, я работаю я должен выполнить н-SLRequest в фоновом режиме, так что я учил, чтобы добавить эти запросы к NSOperationQueue как код ниже показывают

- (void)performBatchRequest:(void(^)(void))completion 
{ 
    NSURL *url = [NSURL URLWithString:@"https://api.twitter.com/1.1/direct_messages/new.json"]; 

    NSOperationQueue *queue = [[NSOperationQueue alloc] init]; 

    ACAccount *account = [self getStoredAccount]; 

    for (NSDictionary *user in self.inviteList) 
    { 
    [queue addOperationWithBlock:^ 
    { 
     NSDictionary *params = @{@"screen_name" :user[@"name"],@"text":@"message" } 

     SLRequest *inviteRequest = [SLRequest requestForServiceType:SLServiceTypeTwitter 
                 requestMethod:SLRequestMethodPOST 
                   URL:url 
                 parameters:]; 

     [inviteRequest setAccount:account]; 

     [inviteRequest performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error) 
     { 
      if (error) 
      { 
       NSLog(@"Errror"); 
      } 
     }]; 
    }]; 
    } 
    self.inviteList = nil; 
    if (completion) 
    { 
     completion(); 
    } 
} 

сейчас Мне интересно, если это лучший подход, который я могу использовать для выполнения нескольких SLRequest в фоновом режиме. Любое предложение/исправление действительно оценено

Answer 1

Ваш обработчик завершения не будет работать так, как вы ожидаете: поскольку все запросы запускаются асинхронно, вы немедленно достигаете оператора if (completion) { completion(); }, но ничего не завершено.

Существует ряд подходов к обработке таких асинхронных шаблонов. Цель состоит в том, чтобы сигнализировать о завершении ряда асинхронных задач. Один простой способ - настроить счетчик, изначально равный числу задач. Всякий раз, когда одна из задач заканчивается (или выходит из строя), увеличивается счетчик на один (тщательно синхронизированный, например, выполняется в выделенной очереди или в основном потоке). Когда счетчик достигнет нуля, вызовите обработчик завершения.

В противном случае подход является жизнеспособным.

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

NSOperationQueue имеет свойство maxConcurrentOperations, которое по умолчанию равно числу ЦП.

Максимальные одновременные запросы, вероятно, будут два (для очередей с привязкой к ЦП и двух ядер). Во всяком случае, в вашем сценарии это все равно. Однако оптимальное количество одновременных запросов зависит от многих факторов, которые могут быть вне вашего контроля: сервер или качество соединения, например.

Если у вас есть очень большие данные для передачи, я бы установил 1 - поскольку ограничивающим фактором является пропускная способность - не латентность.

В противном случае, до 4 или 5. Чем больше одновременных запросов, тем больше памяти используется в вашем приложении!

Примечание: NSULRConnection может накладывать верхний предел максимальных одновременных запросов в зависимости от хоста или IP-адреса или других факторов.

Вывод:

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

Оставьте это на двоих и будьте счастливы. ;)