3

didReceiveMemoryWarning などを実装している小さなアプリの開発中ですが、実装しているものをテストするための最良の方法をよく理解していないように感じます。

まず、どうやらシミュレーターでは、この質問によると、そのアプリがフォアグラウンドに戻されるまで、フォアグラウンドにないアプリに対して didReceiveMemoryWarning はトリガーされません- 実際、それは私自身の経験と一致しますが、私は傾向がありました意味がないので無視してください。(フォアグラウンドに戻り、おそらくそのデータが再び必要になるまで、メモリのクリアを遅らせたいのはなぜですか?) これは実際のハードウェアの動作と一致しますか? もしそうなら、didReceiveMemoryWarning に加えて applicationWillEnterBackground のタスクをクリーンアップすることは理にかなっていますか?

第二に、一般的に、実際のハードウェアで発生する可能性が高い方法でメモリ警告をトリガーするような方法で、シミュレーターで「メモリ警告のシミュレート」メニュー項目をトリガーするための適切な戦略は何ですか?

4

2 に答える 2

3

Q1: これは実際のハードウェアの動作と一致しますか?

  • A: はい、シミュレーターと実際のデバイスは、この点で同じように動作します (たとえば、アプリが中断され、バックグラウンド タスクを実行していない場合、アプリは を受け取りませんapplicationDidReceiveMemoryWarning)。

Q2: でタスクをクリーンアップするのは理にかなっていapplicationWillEnterBackgroundますか?

  • A1: アプリが完全な再起動の準備をしなければならない場合に限ります。アプリが中断されたままで、ユーザーが他のアプリで多くのことを行っている場合、アプリが完全にアンロードされる可能性があります。タスク スイッチャーにアプリがまだ表示されていても、ユーザーが次にアプリをアクティブにすると、アプリのデリゲートが承りますapplication:didFinishLaunchingWithOptions:（ありません applicationWillEnterForeground:）。
  • A2: メモリのクリーンアップは気にしませんが、applicationWillEnterBackground終了するまでにユーザー設定やその他のものを保存して、次にアプリが起動されたときにどこから取得するかをアプリが認識できるようにする必要があります。

Q3: [Simulate Memory Warning] メニュー項目をトリガーするための適切な戦略は何ですか?

  • A1: アプリごとに異なるので、一般的な戦略を策定できるかどうかは疑問です。
  • A2: 特定のケースを使用するには: 私のアプリでは、applicationDidReceiveMemoryWarningメモリの負荷を軽減するためにアプリ デリゲートを使用しません。代わりに、メモリの警告が送信されたときに、iOSviewDidUnloadが含まれていない特定のビュー コントローラーでも呼び出すという事実に依存しています。使用する。したがって、私は通常、メモリ警告シミュレーションを使用して、View ControllerviewDidLoadとviewDidUnloadが正しくバランスが取れているかどうかをテストします。
  • A3: 具体例: 私のアプリはタブを使用しているため、私のお気に入りのシナリオは、1) テスト対象のビュー コントローラー (VC) でタブを表示することです。2) 別のタブに移動します。3) メモリ警告をシミュレートします (iOS はviewDidUnloadテスト対象の VC で呼び出します)。4) 元のタブに戻ります (iOS はviewDidLoadテスト中の VC で呼び出します)。
  • A4: 同様のアプローチを使用する場合は、iOS によってどのビューがアンロードされる可能性があるかをアプリで把握する必要があります。私の（限られた）経験では、これらは異なるタブのビューなど、無関係なビューになる傾向があります。
于 2012-12-31T17:51:12.117 に答える
1

これがあなたの2番目の質問に対する私の答えです-それはあなたの最初の質問にも一種の答えです：

「メモリ警告のシミュレート」機能を使用して、子View Controllerが十分なメモリを消費し、その親がリソースを解放しなければならない問題を効果的に再現しました。

たとえば、カメラ/写真ライブラリを表示する子ビューコントローラ（つまり、UIImagePickerController）について考えてみます。これはかなりの量のメモリを使用します。ピッカーコントローラーが使用可能なメモリよりも多くのメモリを消費する場合、親のView Controllerがアンロードされ、親のView Controllerが再度表示されると（子がポップされたとき）、親のviewDidLoadが再度呼び出されます。これは、viewDidLoadで設定された変数が再度設定され、メモリリークや不正なポインタが発生する可能性があることを意味します。

「SimulateMemoryWarning」はこれらの問題を見つけるのに役立ちます。子ViewControllerに移動し、[Simulate Memory Warning]を選択してから、View Controllerをポップして、問題を確認します。

「didReceiveMemoryWarning」は、その時点で実際にメモリを解放しようとするよりも、発生したことを通知する方が適切であることに注意してください（imho）。

于 2012-12-31T15:02:55.453 に答える