0

私が取り組んでいるアプリでは、ネットワーク リクエストの完了部分でランダムにクラッシュすることがあります。

イベントのチェーンは次のとおりです。

  1. View Controller を子 VC として追加します。親は子の代理人として登録されます。
  2. 子はデリゲート メソッドを呼び出して、何らかの API を呼び出します。
  3. 親は、メイン キューで応答 JSON データを取得します。
  4. 親は、受信したデータに従って子のビューを完了として更新します。

ただし、最後の部分では、クラッシュがランダムに発生します。再現するのはかなり難しく、Crashlytics は、nil 変数 (子ビュー コントローラーのビュー階層のサブビュー) を参照するためにクラッシュが発生することを示しています。この時点で親は生きています。

子View Controllerの関数を呼び出すとクラッシュするのではなく、関数内のビューを参照するとクラッシュするため、子View Controllerが解放される前にビューが解放されるというのが唯一の推測です。

だから私の質問は、タイトルが言うように、View Controllerがそのビューよりも長生きすることは可能ですか、それとも予想されますか?

これは、UIViewController文書で述べられていることです:

ビュー コントローラーは、そのビューとそれが作成するすべてのサブビューの唯一の所有者です。これらのビューを作成し、ビュー コントローラー自体が解放されたときなどの適切なタイミングでそれらの所有権を放棄する責任があります。

ビューコントローラーの参照カウントが0になった結果、ビューが解放されるといつも思っていました。

更新提示する代わりに、子ビュー コントローラーとして追加しています。何が起こるかについてのより詳細な説明を追加しました。

4

1 に答える 1

0

問題は、View ControllerがViewよりも長生きしていることではありませんが、Queue、つまりクロージャーまたはブロック(あなたの場合はAPI呼び出しメソッドのコールバック)がディスパッチされると、システムはそれを生き続け、強い参照を保持するという事実ですクロージャーまたはブロックの所有者(あなたの場合はView Controller)の割り当てが解除された場合でも、それに。したがって、解決策として、クロージャーまたはブロックで弱い自己を使用できます。

于 2016-11-04T07:10:10.867 に答える