1

ビューのカスタム階層があります。各ビューはその子を保持します。親以外の誰もビューを保持しません。ビューのdeallocが呼び出されると、[子リリース]が呼び出されます。ビューを破棄して関連リソースを削除したい場合は、次のように呼び出します。

[mainView release];
[resourceManager deleteRelatedResources];

ほとんどの場合、それはうまく機能し、呼び出しの順序は次のとおりです。

  1. mainViewdealloc;
  2. mainViewの子のdealloc;
  3. mainViewの孫のdeallocなど。
  4. deleteRelatedResources

しかし時々（約1％の時間）私は別の注文をします：

  1. mainViewdealloc;
  2. deleteRelatedResources
  3. mainViewの子のdealloc;
  4. mainViewの孫のdeallocなど。

私は、リソース管理のためのdeallocの呼び出しに依存しないようにAppleからの推奨を見つけました。[子どもの釈放]の直後ではなく、子どもの意見のデロックが呼ばれる可能性があるというのは本当ですか？回避策はありますか？（私のプロジェクトは、リソース管理スキームを変更するには行き過ぎです）。

4

2 に答える 2

4

dealloc呼び出しの順序は不確定です。異なるクラス間の実装で順序に依存するコードがある場合はdealloc、そのコードが壊れていると考えてください。

確かに、注文を保証するために非常に長い時間を費やすことができるという回避策があります。しかし、回避策は防弾ではなく、穴をより深く掘り下げるだけです。

あなたが想定できる唯一のことは、Aでリリースされたオブジェクトdeallocは常にAの後に割り当てが解除されるということです。いつ？あなたは明確に知ることはできません。

（1つの問題は、どのオブジェクトもいつでも自由にretain/autoreleasedできることです。）

潜在的に迅速な修正の1つは、無効化パターンを追加することです。つまり、dealloc依存リソース管理を使用してすべてのクラスにメソッドを実装し、そのメソッドの呼び出しを制御することで、リソース管理を排除します。

次に、次のようなことを行います。

[myObject invalidateAllResources]; // traverses object graph, in order, invalidating resources

[myObject release]; // do the normal release-maybe-dealloc dance
于 2013-01-29T17:26:38.327 に答える
0

私の推測では、mainViewの子ビューの一部は、何らかの理由（アニメーション、またはその他の用途）で他の場所に保持されているため、すぐに割り当て解除されません。

これをテストするには、ビューの割り当てが解除されたときにビューの子のretainCountをチェックします。

于 2013-01-29T18:50:20.020 に答える