Grand Central Dispatch 지연 실행 디자인 패턴

Question

플러그인 시스템으로 애플리케이션을 작성 중입니다. 플러그인은 주 스레드에서 작동해야합니다 (이것은 질문의 일부가 아니며이 요구 사항을 제거해야한다고 대답하는 내용을 찾고있는 것이 아닙니다).

플러그인은 비동기 적으로 초기화되어 시작시 UI가 몇 초 동안 멈추지 않지만 다른 코드는 실행 후 플러그인과 즉시 상호 작용하기 시작합니다. 이것은 분명히 플러그인이 로딩을 마칠 때까지 지연되어야합니다. 여기

이는 제출 된 작업이 플러그인로드가 완료 될 때까지, 그러나, 새로운 작업이 거치게됩니다 시작되지 않습니다 것을 의미합니다

// Create operation queue 
dispatch_queue_t queue = dispatch_queue_create(...); 
dispatch_suspend(queue); 

// Load the plugins 
dispatch_group_t group = dispatch_group_create(); 
for each plugin { 
    dispatch_group_async(group, dispatch_get_main_queue(), ^{ 
     load... 
    }); 
} 
dispatch_group_notify(group, dispatch_get_main_queue(), ^{ 
    dispatch_resume(queue); 
}); 

// Add operations that interact with the plugins 
dispatch_async(queue, ^{ 
    dispatch_async(dispatch_get_main_queue(), ^{ 
     operation... 
    }); 
}); 

... 내가 지금까지있어 무엇인가 큐가 실제로 처리되기 전에. 이것은 큰 오버 헤드입니까? 큐잉 할 가치가 있을까요? 그리고 큐잉을 방해하지 않는 메소드를 구현할 때 메소드 구현을 교체할까요? 이렇게하는 것이 더 까다로울 것이고, 그럴만 한 가치가 있는지 나는 모른다.

마지막으로 이러한 유형의 문제에 대한 더 나은 디자인 패턴이 있습니까? 아마도 NSOperations 및 NSOperationQueues 종속성을 사용해야합니까? 아니면 기본 GCD 작업보다 높은 오버 헤드가 있습니까?

Answer 1

"이중 오버 헤드"는 실제로 실제로는 낮지 만 더 직관적 인 약간 더 나은 디자인 패턴이 있습니다. 작업 대기열을 만든 다음 dispatch_set_target_queue(queue, dispatch_get_main_queue())을 사용하여 본질적으로 기본 대기열의 하위 대기열로 만듭니다. 이렇게하면 크로스 스레드를 요구하지 않고 메인 스레드에서 실행되도록 보장 할 수 있습니다. 플러그인 작업을 작업 큐에 직접 제출하면됩니다.