iPhone アプリケーションには複数のタブがあり、各タブを選択するとネットワーク接続がトリガーされます。以前は、接続ごとに新しいスレッドを切り離していました。そして、いくつかの非常に迅速なタブ切り替えの後、アプリケーションが応答しなくなりました。ここで、スレッドの数を制御し、アプリケーションが応答しなくなることを許可しない操作キューを使用することにしました。ただし、クイック スイッチが少なくてもアプリが応答しなくなります (ただし、応答しない状態からの回復は速くなります)。xcode からデバイス上でアプリを実行し、いくつかのクイック スイッチを切り替えて一時停止し、スレッドの数を確認しました。そして、私が見つけたのは、次のスタックを持つスレッドがいくつかあるということです:
0 __workq_kernreturn
2 _init_cpu_capabilities
これらのスレッドとは何か、それらを取り除く方法はありますか?
NSOperationQueueを使用する大きな利点の1つは、スレッドを忘れて、システムにそのことを心配させることができることです。問題の根本は、不要になった複数の操作を同時に実行していることのようです。特定のスレッドについて心配するのではなく、それらの操作を終了させて、コンピューティングリソースを使い果たしないようにすることを検討してください。
私の推測では、これらのスレッドはGrandCentralDispatchによって管理されています。GCDは、ブロック（および操作）を処理するためのワーカースレッドを作成し、それについて可能な限り効率的になります。
問題の重要な部分は、ワーカースレッドの内部/プライベート実装にあるとは限りません。操作ごとに 1 つのスレッドを作成すると多くのコストがかかるため、適切な実装ではスレッド プールを使用する可能性があります。操作は、アイドル状態のスレッドを再利用して保持できます。
重要な部分 (おそらく) は、選択した実装の公開 API を使用することにあります。
この場合にサポートする明白な実装の 1 つは、操作の取り消しです-[NSOperation cancel]。保留中または未完了のリクエストがあるビューから誰かが移動した場合は、単純にキャンセルします (キャッシュ用のデータが必要でない限り)。
多くの実装では、リクエストの頻度を減らすことでメリットが得られる場合もあります。たとえば、サーバーの結果が 1 時間に約 1 回しか更新されない場合、「約 1 分ごと」にリクエストしても意味がありません。
最後のポイント: 接続はワーカー スレッド自体を使用できます。問題がある場合は、これを減らすために使用している API を確認してください。