リクエストを保持しているのは何ですか?(おそらく、オペレーション キュー?誰が知っていますか?)
一般に、あなたが提案しているように見える「ファイアアンドフォーゲットアンドギブミーコールバック」メソッドは悪い考えです。要求以外に何も VC を保持していない場合、(アプリの構造が少しばかげていない限り) VC は受信したデータで何もすることができないため、続行する理由はありません。
また、間違っているように感じます: リクエストが VC を所有しているのか、それとも VC がリクエストを所有しているのか? 私は後者を期待しているので、VCもリクエストを保持する必要があります。
いくつかの例外があります:
- CAAnimation.delegate は保持されます。おそらく、アニメーションがある時点で完了するためです (繰り返しのアニメーションの場合はどうなるかわかりません)。同じことがUIKitのアニメーションデリゲートにも当てはまるかもしれません
- NSTimer は、おそらく NSInvocation が行うため、そのターゲットを保持します。(これを回避するために「弱いタイマー」クラスを作成しました。)
- CADisplayLink は、おそらく NSTimer のように、そのターゲットを保持します。
これらのケースでは、ターゲットを保持しない「弱いプロキシ」クラスを使用して回避することがよくあります (そして、これを少し簡単にするために、NSTimer/CADisplayLink の周りに「弱いタイマー」ラッパーを書きました)。
あなたがすべきことは、開始したリクエストを追跡し、dealloc で次のようなことを行うことです。
request.delegate = nil;
[request cancel];
self.request = nil;
同様に、適切なタイミングで通知/アクション/KVO コールバックの登録を解除する必要があります。例外があります:
- リリース後にコールバックが送信されないことが確実な場合は、気にする必要がないため、テキスト フィールド デリゲートとボタン アクション/ターゲットをクリアする必要はありません。
例外には例外があります。
- UIWebView (少なくとも古い OS では) は、おそらく Web スレッドに関係する何か他のものによっても保持されます。Web ビューがまだロードされている間に VC が消えると、クラッシュする可能性があります。
- UIScrollView のスクロール コールバックも、ビューが VC の有効期間を過ぎても保持されるようにします。これをテストするには、たとえば、[Done] を押しながらフリックを開始して [Done] を放します。