3

私は、NSURLConnections を扱ういくつかのアプリケーションを使用してきました。NSOperationベスト プラクティスを調査しているときに、これを使用しNSOperationQueueて対処する方法を示す多くの例がオンラインであることに気付きました。

また、stackoverflow で、NSURLConnection:sendAsynchronousRequestおよびsendSynchronousRequest.

現在、次のように初期化を行っています。

[[NSURLConnection alloc] initWithRequest:request delegate:self];

これを行っている間、メイン スレッドとデリゲート メソッドの呼び出しを監視しました。

connectionDidFinishLoading、connectionDidReceiveResponse、connectionDidReceiveDataおよびconnectionDidFailWithError

私が Apples のドキュメントで読んだことすべてと私のテストは、これがデフォルトの動作で非同期であることを証明しています。

より経験豊富な Objective C プログラマーから、他のオプションがベスト プラクティスに使用される場合、または非同期動作を実現するための最も単純な方法として私が見ているものよりも正しい場合を知りたいですか?

これは私がここに投稿した最初の質問です。さらに情報が必要な場合は、お問い合わせください。

4

2 に答える 2

2

リストする方法は、非同期転送の従来の手段であり、それらを使用するアプリは、プロセッサ (したがって電力) の使用効率が高くなります。

このsendAsynchronousRequestメソッドは iOS 5 で追加された比較的新しいメソッドです。ベスト プラクティスに関しては、データ デリゲート メソッドで作成されたリクエストをキャンセルできることと、データ デリゲート メソッドで作成されたリクエストを前者はできません。ただし、接続をキャンセルしたくないことがわかっている場合は、整頓されているため、読みやすさとブロックベースのバグの可能性が高いため、sendAsynchronousRequest間違いなく有利になります。

ベスト プラクティスとして、sendSynchronousRequest常に回避する必要があります。メイン スレッドで使用すると、ユーザー インターフェイスがブロックされます。より一般的な目的で作成した他のスレッドまたはキューで使用する場合は、それをブロックします。そのための特別なキューまたはスレッドを作成したり、に投稿したりするとNSOperationQueue、通常の非同期投稿よりも実際の利点は得られず、Apple の標準 WWDC コメントによると、アプリの電力効率は低下します。

への参照sendSynchronousRequestは、おそらく iOS 5 以前のパターンの名残です。a が表示されている場所ならどこでもsendSynchronousRequest、 asendAsynchronousRequestを同じように簡単に実装して、より効率的に実行できます。もともと含まれていたのは、直線的に流れる必要があるコードを適応させる場合があり、ブロックがなく、非同期呼び出しを実装するための「本質的に直線的な」方法がないためだと思います。今はそれを使う正当な理由が思いつかない。

于 2012-07-06T01:14:35.090 に答える