3

cocoaのUrlオブジェクトを使用してWebから外部リソースを取得する機能があります。また、シミュレーターでは正常に動作しますが、デバイス自体で失敗することがあります（これは、Googleクエリであるため、リソースは明らかに存在します）。これにより、ハードウェアに内部タイムアウトの障壁があると私は信じますが、そのような障壁が存在するかどうかを読んでいません。

他の誰かが同様の問題に遭遇しましたか？または、タイムアウトが文書化されているか、変更できるかどうかを知っていますか？

4

5 に答える 5

5

iPhone OS は、アプリが応答しなくなったと思われる場合 (基本的には、メイン スレッドが数秒間ブロックされた場合)、アプリを終了します。これは終了時にも重要です。終了時に保存すると、保存を完了するためのウィンドウが非常に小さくなります。これは、OS が他のことを行っている可能性があるという事実によって悪化します。OS の終了に時間がかかりすぎると、アプリが強制終了され、ユーザーにはアプリが保存に失敗したように見えます。

シミュレーターではなく、ハードウェアで時間に関連するものをテストすることを強くお勧めします。シミュレーターは迅速なターンアラウンド デバッグに最適ですが、実際のハードウェアでのパフォーマンスを表すものではありません。

重い作業を行う場合は、別のスレッドで実行して、UI がユーザーと OS に応答し続けるようにします。

于 2008-10-04T03:27:34.367 に答える
4

iPhoneは、アプリケーションの起動にタイムアウトを課します。したがって、applicationDidFinishLaunchingで大規模な処理を実行すると、たとえば、アプリケーションが終了し、クラッシュログが生成されます。残念ながら、公式ドキュメントにはその記載がありません。

起動プロセスが完了した後、関数の実行時間を制限するタイムアウトを認識していません。メインスレッドで30秒間スリープ状態にしてデバイスで試してみましたが、正常に動作します。

于 2008-10-06T13:31:36.223 に答える
4

applicationDidFinishLaunchingで大きなファイルを読み取っているときに、このタイムアウトに気づきました。私のアプリは起動中に終了します。コンソールに、ログメッセージが表示されました。

Sun Mar  1 10:41:03 unknown SpringBoard[22] <Warning>: <myappid>.* failed to launch in time

私の解決策はperformSelector: withObject: afterDelay: 0.0、appliationDidFinishLaunchingからすばやく戻り、runloopのファイルロードをキューに入れるために使用することでした。これにより、新しいスレッドを設定したり、マルチスレッドの複雑さに対処したりする必要がなくなります。

于 2009-03-01T18:19:50.087 に答える
1

NSUrlRequest を使用している場合は、タイムアウト間隔に達していないことを確認してください。お使いの携帯電話のインターネット接続は、シミュレーターよりも遅い場合があります。

ドキュメントから：

+ (id)requestWithURL:(NSURL *)theURL cachePolicy:(NSURLRequestCachePolicy)cachePolicy timeoutInterval:(NSTimeInterval)timeoutInterval

Parameters
theURL
The URL for the new request.

cachePolicy
The cache policy for the new request.

timeoutInterval
The timeout interval for the new request, in seconds.

Return Value
The newly created URL request.
于 2008-10-06T05:38:50.920 に答える
1

iPhone OS がメモリを使いすぎるとアプリを強制終了することはわかっているので、アプリが長時間イベントに応答しない場合に同じポリシーを使用しても驚かないでしょう。

デスクトップ アプリを作成している場合、問題は回転する虹色のビーチ ボール カーソルとして現れ、アプリはマウス クリックに応答しません。Mac OS X はアプリを終了しませんが、Dock でそのアイコンを ctrl を押しながらクリックすると、アプリを強制終了するよう提案します。

ここでの主な問題は、イベント処理スレッドを拘束していることです。次の 2 つのオプションがあります。

  1. ノンブロッキング I/O を使用するため、Web リクエストを 1 回の呼び出しで実行する代わりに、バックグラウンドでデータをフェッチし、完了時に指定したメソッドを呼び出す API を使用します。
  2. 別のスレッドでブロッキング I/O を使用します。現在行っているのと同じように Web 要求を実行しますが、別のスレッドで実行し、完了したらメイン スレッドに通知します。
于 2008-10-04T02:56:36.333 に答える