6

このトピックにはさまざまな質問があり、dispatch_async 内で sendSynchronousRequest を使用しないようにというアドバイスがたくさんあります。これは、スレッドをブロックし、GCD がすべての同期 URL 要求を処理するために多くの新しいワーカー スレッドを生成するためです。

iOS 5 の [NSURLConnection sendAsynchronousRequest:queue:completionHandler:] が舞台裏で何をしているのかについて、誰も決定的な答えを持っていないようです。

私が読んだある投稿では、最適化する可能性があり、実行ループを使用する可能性があると述べていますが、リクエストごとに新しいスレッドを作成することはありません。

sendAsynchronousRequest:queue:completionHandler を使用しているときにデバッガーを一時停止すると、スタック トレースは次のようになります。

スクリーンショット

.. sendAsynchronousRequest:queue:completionHandler が実際に sendSynchronousRequest を呼び出しているように見えますが、sync メソッドの代わりに async メソッドを使用すると、まだ大量のスレッドが作成されています。

はい、非同期呼び出しを使用する利点は他にもありますが、この投稿では説明しません。

私が興味を持っているのは、パフォーマンス/スレッド/システムの使用法だけです。さらに悪い場合は、非同期呼び出しを使用する代わりに、dispatch_async 内で同期呼び出しを使用します。

ios4 非同期呼び出しの使用に関するアドバイスも必要ありません。これは純粋に教育目的のためです。

誰かがこれに対する洞察に満ちた答えを持っていますか?

ありがとう

4

2 に答える 2

0

これは実際にはオープンソースです。http://libdispatch.macosforge.org/

Apple の実装より効率的にワーカー スレッドを管理できる可能性はほとんどありません。このコンテキストでは、「非同期」は選択/ポーリングを意味するのではなく、呼び出しがすぐに返されることを意味します。したがって、実装がスレッドを生成していることは驚くべきことではありません。

于 2012-07-23T18:56:36.303 に答える
0

前の回答が述べたように、GCD (libdispatch) と libblocksruntime は両方ともオープン ソースです。内部的には、iOS/OS X は pthread のグローバル プールと、ユーザー コードで作成したアプリ固有のプールを管理します。OS スレッドとディスパッチ タスクの間には 1:N のマッピングがあるため、内部でのスレッドの作成と破棄について心配する必要はありません (心配する必要もありません)。そのために、GCD タスクはバックグラウンド スレッドにパントされるため、呼び出し後にアプリの実行ループで時間を使用しません。

ほとんどの種類の NSURL 操作は I/O バウンドです。これを隠すことができる同時実行性ブードゥーの量はありませんが、Apple 独自の非同期実装がバックグラウンドで同期対応を使用している場合、おそらくそれはすでにかなり高度に最適化されていることを示唆しています。前の回答が言ったこととは反対に、libdispatchはスケーラブルな I/O を内部的kqueueに (OS X/iOS/BSD で) 使用します。 .

可能ではありますが、投資した時間に対する利益はおそらくわずかです。Apple の実装に固執し、スレッドについて心配する必要はありません。

于 2012-09-26T02:32:04.297 に答える