AJAX 非同期と同期

同期は続行する前に結果が返されるまで待つ必要があります。通常、非同期の結果を監視する必要はありません。
同期は直線のキューであり、非同期はキューになく、それぞれ独自の道を進みます。

1. 同期と非同期の違いは何ですか?

同期: リクエストを送信します -> サーバーの処理を待ちます -> 処理して戻った後、この期間はクライアント ブラウザは何もできません

非同期: リクエストはイベントによってトリガーされます ->これはブラウザが引き続き実行できることです 他のことを行います) ->処理済み

2. どのような状況で使用されますか?

1. ひたむきさ: 現在できることは 1 つだけで、他のことは現在のことが完了するまで待ってから次のことを続ける必要があります。

2. 中途半端: 同時に複数のことを行うことができます。左手でスペースバーを押し、右手でマウスを打ち続け、目は同時に画面を見なければなりません。とても難しいです。

Ajax は、リクエストを送信するときに同期と非同期に分けられます。

非同期送信方法は、最も一般的に使用され、ユーザーへのサーバー取得によって生じる時間遅延を回避します。非同期送信中は、バックグラウンドで静かに送信されるだけなので、ユーザーは待ち時間を感じさせずに、自分の作業を行うことができます。送信されるデータ量が多い場合、サーバーの取得時間は長くなりますが、ユーザーはページ上の操作に集中しており、サーバーが何をしたかを知らないため、ユーザーに良い体験を提供します。

非同期送信方法はその逆で、同期リクエストが発行された後、ブラウザはサーバーが取得を完了して結果を返すのを待っています。このとき、マウスは待機状態に変わり、リクエストがまだ応答されていないことをユーザーに通知します。ユーザーができることは 1 つだけです。待ってください... ユーザーはすでに修正ページの読み込みを待つことに慣れていますが、Ajax でのリクエストの同期時間は通常、ページ全体の読み込み時間よりも長くはありませんが、それがどれほど苦痛であるかを知っておく必要があります。何もせずただ受動的に待つこと。したがって、この同期リクエストは注意して使用する必要があります...

この時点で、非同期リクエストは非常に優れているので、なぜ非同期リクエストを使用しないのかという疑問を持たなければなりません。ただ、同期リクエストは行わないでください。はは、そのような状況がある場合は、このステップでのリクエストの結果が次のリクエストの前提となるため、ユーザーが今後行うことは決まります。センス。それでは、同期リクエストと非同期リクエストのどちらを使用するべきだと思いますか?当然のことですが、次のステップをより有意義なものにするために、親愛なるユーザーのために少し待ってみてはいかがでしょうか。

同期リクエストと非同期リクエストにはそれぞれ独自の用途があります。適切に使用されるかどうかが問題です。ポイントAJAX の長所と短所 aAjax 長所と短所:

長所:
従来の Web アプリケーションでは、ユーザーはフォーム (Form) に入力し、フォームを送信するときに Web サーバーにリクエストを送信できます。サーバーは受信フォームを受信して​​処理し、新しい Web ページを返します。このアプローチでは、2 つのページの HTML コードのほとんどが同じであることが多いため、多くの帯域幅が無駄になります。アプリケーションの各対話ではサーバーにリクエストを送信する必要があるため、アプリケーションの応答時間はサーバーの応答時間に依存します。その結果、ユーザー インターフェイスの応答性はネイティブ アプリよりもはるかに低くなります。

これとは異なり、AJAX アプリケーションは、SOAP またはその他の XML ベースの Web サービス インターフェイスを使用して、必要なデータのみをサーバーに送信および取得することができ、クライアント上で JavaScript を使用してサーバーからの応答を処理します。サーバーとブラウザーの間で交換されるデータが少なくなるため、結果としてアプリケーションの応答性が向上します。同時に、リクエストを発行したクライアント マシン上で多くの処理作業を完了できるため、Web サーバーの処理時間も短縮されます。

Ajax を使用する最大の利点は、ページ全体を更新せずにデータを維持できることです。これにより、Web アプリケーションはユーザーのアクションにより迅速に応答できるようになり、変更されていない情報がネットワーク上に送信されることがなくなります。 Ajax はブラウザーのプラグインを必要としませんが、ユーザーがブラウザーで JavaScript を実行できるようにする必要があります。 DHTML アプリケーションと同様に、Ajax アプリケーションはさまざまなブラウザーやプラットフォームで厳密にテストする必要があります。 Ajax が成熟するにつれて、Ajax の使用を簡素化するいくつかのプログラム ライブラリも登場しました。同様に、JavaScript をサポートしていないユーザーに代替機能を提供する別の支援プログラミング テクノロジが登場しました。

短所:

Ajax の使用に対する主な批判は、ブラウザの「戻る」ボタンの通常の動作を壊す可能性があるということです。動的に更新されるページの場合、ブラウザーは履歴に静的なページしか記憶できないため、ユーザーは前のページの状態に戻ることはできません。完全に読み取られたページと動的に変更されたページの違いは非常に微妙です。多くの場合、ユーザーは「戻る」ボタンをクリックして前の操作をキャンセルできることを望んでいますが、Ajax アプリケーションではこれは不可能です。こちらです。ただし、開発者はこの問題を解決するためにさまざまな方法を考え出しました。そのほとんどは、ユーザーが履歴にアクセスするために戻るボタンをクリックしたときにページ上の変更を再現するために、非表示の IFRAME を作成または使用する方法です。 (たとえば、ユーザーが Google マップでクリックして戻ると、非表示の IFRAME が検索され、検索結果が Ajax 要素に反映され、アプリケーションの状態がその時点の状態に復元されます。)

関連する点は次のとおりです。動的ページ更新を使用すると、ユーザーが特定の状態をお気に入りに保存することが困難になります。この問題に対する解決策も登場しており、そのほとんどは URL フラグメント識別子 (URL の # の後の部分、アンカーと呼ばれることが多い) を使用して追跡し、ユーザーが指定されたアプリケーションの状態に戻ることを可能にします。 (多くのブラウザーでは、JavaScript でアンカーを動的に更新できるため、Ajax アプリケーションは表示されたコンテンツを更新しながらアンカーを更新できます。) これらのソリューションは、「戻る」ボタンをサポートしないことをめぐる議論の多くも解決します。 Ajax を開発する場合、ネットワーク遅延 (ユーザーのリクエストからサーバーの応答までの時間) を慎重に考慮する必要があります。ユーザーに明確な応答を与えない [5]、データを適切に事前に読み込まない [6]、または XMLHttpRequest [7] を不適切に処理すると、ユーザーは遅延を感じます。これはユーザーにとって見たくないことであり、理解できないことです。 8]。一般的な解決策は、視覚的なコンポーネントを使用して、システムがバックグラウンド操作を実行し、データとコンテンツを読み取っていることをユーザーに伝えることです。たとえば、一部のハンドヘルド デバイス (携帯電話、PDA など) は AJAX をサポートできません。JavaScript で作られた Ajax エンジンは、ページの更新ほど明らかではないため、JavaScript の互換性とデバッグがすべて問題になります。リロードすると、ユーザーにトラブルが発生しやすくなります。ユーザーは、現在のデータが新しいのか、更新されたのかわかりません。既存の解決策には、関連する場所でのプロンプト、データの更新が含まれます。エリアのデザインがより明白になり、プロンプトが後でユーザーに表示されます。データの更新など。ストリーミング メディアのサポートは FLASH や Java アプレットほど良くありません。