2

私はこの回答を読んだばかりで（回答は削除されました）、ハングした後にアプリがクラッシュするのを見たことがあると確信しているので、読んだ内容は理にかなっています。

メインスレッドを長時間ブロックすると、OSがアプリを強制終了します。

ただし、いくつかのテストを作成したところ、それぞれ約2〜5分待った後、アプリがクラッシュする原因にはならなかったことがわかりました。ブレークポイントは、メインスレッドで実行していることを確認しました。

  • 誰かが私が読んだものを確認または反証することができますか、または私がブロックされていない多くのオプションを選択しただけですか？

  • 非ブロッキングオプションを選択した場合、誰かがこれらが非ブロッキングである理由を説明できますか？

while (true) { /*Nothing*/ }

while (true) { NSLog(@"nothing"); }

for(;;);

sleep(100000000);

while(true) { sleep(1); }
4

2 に答える 2

2

iOSは、またはのUIApplicationDelegateようないくつかの方法で時間がかかりすぎる場合にのみアプリを強制終了します。アプリケーションのデバッグバージョンでは強制されませんが、通常は5秒以内に戻ります。application:didFinishLaunchingWithOptions:applicationDidEnterBackground:

これらのメソッドの外部でメインスレッドをブロックしても、アプリケーションは終了しません。

于 2012-06-13T14:50:59.830 に答える
0

あなたが参照している答えは正しくありません。クラッシュは、彼がメインスレッドをブロックしているためではなく、メモリが不足しているためです。あなたが与えた例のどれもスレッドをブロックしないと私は信じています。スレッドを実際にブロックする方法は、再帰を使用するか、メインキューを引数としてメインスレッドからdispatch_syncを呼び出すことです。これによりデッドロックが発生しますが、そのためにアプリケーションが終了することはないと思います（間違っている可能性はありますが）。

では、なぜこれらのノンブロッキングなのですか？ブロッキングの定義方法によって異なります。4番目を除いて提供したすべての例は、コードが次の行に進むのを妨げるだけです。これは完全に問題ありません。sleep(10000000)与えられた秒数で正しく戻るので、これよりもさらに弱いのですが、なぜこれが問題を引き起こすのでしょうか？

于 2012-06-13T14:46:49.480 に答える