0

プラグイン システムを使用してアプリケーションを作成しています。プラグインはメイン スレッドで動作する必要があります (これは質問の一部ではありません。この要件を削除する必要があるという回答をたくさん探しているわけではありません)。

プラグインは非同期で初期化されるため、起動時に 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...
    });
});

これは、送信された操作はプラグインのロードが完了するまで開始されないことを意味しますが、新しい操作は実際に処理される前に 2 つのキューを通過します。これは大きなオーバーヘッドですか？最初にキューに入れ、キューイングを気にしないメソッドの実装の準備ができたら、メソッドの実装を交換する価値はありますか? これを行うのはよりトリッキーであり、それだけの価値があるかどうかはわかりません。

最後に、この種の問題に適した設計パターンはありますか? おそらく、依存関係のある NSOperations と NSOperationQueues を使用する必要がありますか? それとも、基本的な GCD 操作よりもオーバーヘッドが高くなりますか?

4

1 に答える 1

2

「二重のオーバーヘッド」は実際には非常に低いですが、これに使用できる、より直観的な、わずかに優れた設計パターンがあります。操作キューを作成し、それを使用dispatch_set_target_queue(queue, dispatch_get_main_queue())して、本質的にメイン キューのサブキューを作成します。これにより、クロスサブミットを行う必要がなく、メイン スレッドで確実に実行されます。プラグイン操作を操作キューに直接送信するだけです。

于 2012-10-16T17:54:09.550 に答える