メモリ不足のために終了したアプリを iOS システムが再起動する条件を理解しようとしています。ただし、十分なメモリ プレッシャを作成するのは困難でした。
現在、私のアプローチは、Xcode を介してアプリを起動し、バックグラウンドで実行し、メモリを消費するヘルパー アプリを起動することです。iOSシステムがそれを強制終了するまで、NSTimerループにメモリのビットを割り当てます。運が良ければ、メインのアプリが「メモリ不足のため終了しました」と Xcode が教えてくれます。
これを達成するためのより信頼できる方法を探しています。この目的に適したメモリ割り当て手法またはプライベート API はありますか?
あなたが説明した動作には少し驚いていますが、いくつかの考えがあります。
私の知る限り、iOS は、アプリが破棄される順序について保証したり、すべてのバックグラウンド アプリが破棄されることを保証したりしません (または、メモリ プレッシャ状態を緩和するのに十分な数のアプリを破棄しようとするだけであるかどうかも保証しません)。iOS および Mavericks でのメモリ不足状態の処理にはいくつかの手がかりがありますが、私はそれを保証できません。しかし、OS はいくつかの複雑なロジックに関与しているため、特定のアプリを確実に破棄するために実行する必要がある手順について、確固たる主張をすることを躊躇します.
バックグラウンド アプリが破棄される順序の問題は、ヘルパー アプリのクラッシュを許可しているという事実の影響を受けます。ヘルパー アプリの割り当て試行を満たすのに十分な速さでバックグラウンド アプリが破棄されない可能性があります。したがって、iOS がメイン アプリを放棄する前に、ヘルパー アプリがクラッシュする可能性があります。
メモリ警告を受け取ったときに、要求したすべてのメモリを解放してプロセスを再開するように、ヘルパー アプリの設計を少し変更することをお勧めします。私の「Cause Memory Pressure」アプリでは、メモリ警告を受け取ったときに割り当てを停止してから、割り当てを再開するプロセスまで、実際には数秒待ちます。
しかし、要するに、ヘルパー アプリがクラッシュしないようにして、メモリ プレッシャ システムを完全に実行できるようにする必要があると思います。
Xcodeのデバッガーがアプリが終了したことを報告するのを待っていると説明しています。デバッガーを介さずに、メイン アプリをデバイス上で直接実行して、実験を繰り返すことをお勧めします。アプリがデバッガーにアタッチされているという事実が、どのアプリを投棄するかを決定する際の優先度の計算に実際に影響を与える可能性があると理論的に考えられるため、これをお勧めします。
アプリは強制終了されるため、OS がアプリを再起動するために何らかの操作 (バックグラウンドNSURLSession、プッシュ通知など) を行った場合、デバッグ セッションはとにかく失われてしまうため、デバッガーを介して実行しても意味がありません。したがって、「OS がアプリを再起動したらどうなるか」という質問を観察するために、デバッガーを介して実行しても意味がありません。
個人的には、アプリの投棄や再起動などの動作を診断するときは、Xcode デバイス オーガナイザーを使用して、そこでデバイスのコンソールを観察します。コンソールでアプリの NSLog ステートメントを観察したり、アプリが投棄されたり、アプリが再起動されたりするのを監視できます (OS が実際にアプリを再起動しようとしている場合)。
達成したいことは、状態を適切に保存したかどうかをテストすることだと思います。そのため、再起動すると元の場所に戻ります。
私がお勧めするのは、フラグを設定することです。これにより、アプリがバックグラウンドに移動したことを検出すると (applicationDidEnterBackground:)、さらに時間を要求し、すべての状態の変更を行い、スピン ループで停止して終了します。 、または `exit(0)' を実行します。アプリが Xcode で「停止」したことを確認できるはずです。その後、アプリを再起動できます。