1

Flashアプリは、リモートの宛先から50個程度のファイルをロードする必要があります。通常のネットワーク状態では、これは問題ありません。ただし、一部のユーザーは、読み込みフェーズ中にアプリケーションが「動作を停止した」と報告し始めました。

ネットワーク品質を3パケットのうち1パケットがバーストでドロップされるまで低下させたいくつかのテストの後、エラーレポートを再現することができました。ファイアバグを見ると、いくつかのファイル(50のうち1から3)がロードを開始しているように見えますが、完了していません。ActionScriptでエラーが発生することはなく、ファイルが完了しないという明らかなパターンはありません。

誰かが以前に状況に遭遇し、これらの状況に対処するための原因や修正を見つけたことがありますか?

ローダーがロードを停止してロードプロセスを再開するかどうかを手動で確認するものを書くのはそれほど難しいことではありませんが、正しいエラーイベントをリッスンしていないのではないかと思っていました(現在、進行状況、完了、IOErrorsをリッスンしています)または他の解決策がある場合は?

乾杯マーク

4

6 に答える 6

1

このすべての読み込みをどのように処理していますか?ローダー(またはURLLoaderなどのサブクラス)を使用しているだけですか、それともこれらすべてを処理するライブラリを使用していますか?

GreensockのLoaderMaxBulkLoaderは、大量の読み込みを行うときに使用するものです。BulkLoaderよりもLoaderMaxを使い始めたのは、いくつかの優れた機能があるためです。

于 2010-07-30T03:25:13.193 に答える
1

久しぶりの別アカウントからのフォローアップです。

ご提案いただきありがとうございます。サーバーが時間内に応答しない場合、またはクライアントが X 時間バイトを受信しなくなった場合に、ロードのスケジュールを変更するという回避策があります。最悪の場合、これはユーザーがもう少し待たなければならないことを意味します。

ただし、リクエストが静かに失敗する原因はまだ謎です。

@Danyal - 良い提案です。ローダーが管理されているため、これは当てはまらないと思いますが、100%確実に確認する必要があります。

于 2010-08-11T18:07:23.243 に答える
0

raixは、厳密に言えば、ロードライブラリではありませんが、複数のXMLドキュメントをロードし、エラーやタイムアウトの処理を含む型付きの値を出力する例があります。

以下のコードは、XMLドキュメントをロードし、10秒後に静的バージョンにフォールバックします(ただし、2つの間に別のXMLロードを簡単に連鎖させることができます)。

Observable.xml(new URLRequest(xmlDocumentURL))
    .timeout(10000, Observable.returnValue(defaultProductCategories))
    .subscribe(function(xml : XML) : void
    {
        trace("Either way, we have an XML document");
    });
于 2010-08-11T18:13:42.080 に答える
0

これらのリクエストを一度にすべて行うと、読み込みがタイムアウトになり、ファイルが読み込まれなくなる可能性があります。多くの場合、サーバーは、処理できる同時要求の数に制限があります。

したがって、すべてのアイテムを開始してすべてが終了するまで待つのではなく、アイテムを次々とロードするようにロードを管理することをお勧めします。

于 2010-07-30T04:57:04.610 に答える
0

ローダーへの参照を維持していることを確認しましたか? ローダーを弱いリスナーを持つローカル変数として定義している場合、ロード プロセスが完了する前にローダーがガベージ コレクションされる可能性があり、エラーは発生しません。

于 2010-08-02T17:18:31.340 に答える
0

PHPファイルによって提供されるURLからロードするadobe Airモバイルアプリケーションがあります。私のローダーは黙って失敗し、データを返しません (汎用ローダーまたは Greensock を使用)。だから私はあなたがやったことを、サイレントフェイルをチェックして単純に再試行するだけでやりました。これは機能しましたが、これがいかにばかげているかがわかりました。さらに、デバッグ シミュレーターとは対照的に、モバイル デバイスでは状況が悪化しました。

これが私が修正として見つけたもの、または少なくとも失敗の量を大幅に軽減したものです。

古い方法: 私の PHP ファイルでは、データベース クエリを実行し、XML にフォーマットされたデータをパッケージ化し、任意のバイナリを Base64 に変換してから、ヘッダー情報を送信しechoてから、完成した XML を送信していました。

新しい方法: 私がしたことは、すぐにヘッダー情報をできるだけ早く送信し、次に PHP を実行しflush();てから、データベース クエリ、xml のパッケージ化とエンコードを実行echoし、完成した XML を出力することでした。

これまでのところ修正されているようですが、まだ失敗をチェックしていますが、それよりもはるかに少ないです。

私のサーバーは、これらの要求を十分に処理できます。また、予備のフラッシュが必要であると考えるほど大きな XML をパッケージ化していません。さらに、その URL を Web ブラウザーから読み込むと、常にすべて正常に動作します。だからこそ、私はそれが問題だとは決して考えませんでした。

現在修正されている理由は、ヘッダーをできるだけ早く送信することで、アプリケーションがその要求が確認され、データが来ることを認識しているためだと思います。HTTP リクエストは、タイムアウトのために (少なくとも AS3 では) 非常に短命であり、大量の失敗を引き起こしているようです。

于 2012-07-09T19:40:57.160 に答える