La synchronisation doit attendre le retour du résultat avant de continuer. Le fonctionnement asynchrone n'a pas besoin d'attendre. Généralement, il est nécessaire de surveiller le résultat asynchrone.
La synchronisation est une file d'attente en ligne droite, l'asynchrone n'est pas dans une file d'attente et chacun suit son propre chemin.
1. Quelle est la différence entre synchrone et asynchrone ?
Synchrone : Soumettre la demande -> Attendre le traitement du serveur -> Retour après traitement. Pendant cette période, le navigateur client ne peut rien faire
Asynchrone : Le la requête est déclenchée par un événement ->Traitement du serveur (cela signifie que le navigateur peut encore faire autre chose) ->Traitement terminé
2 Dans quelles circonstances est-il utilisé ?
1. Détermination : vous ne pouvez faire qu'une seule chose pour le moment, et les autres choses doivent attendre que la chose en cours soit terminée avant de pouvoir passer à la chose suivante.
2. Sans enthousiasme : vous pouvez faire plusieurs choses en même temps : votre main gauche appuie sur la barre d'espace, votre main droite peut continuer à appuyer sur la souris et vos yeux doivent regarder l'écran en même temps. en même temps, ce qui est très dur.
Lorsque Ajax envoie une requête, elle est divisée en synchrone et asynchrone :
La méthode de transmission asynchrone est la plus couramment utilisée et la méthode par défaut Cela évite le délai apporté à l'utilisateur par la récupération du serveur. Lors d'une transmission asynchrone, elle se déroule simplement en coulisses et l'utilisateur peut toujours faire ce qu'il fait sans donner à l'utilisateur le sentiment d'attendre. Lorsque la quantité de données transmises est importante, le temps de récupération du serveur sera plus long, mais l'utilisateur ne le sait pas. L'utilisateur est toujours concentré sur les opérations sur la page et ne sait pas ce que le serveur a fait, il le donne donc. utilisateur une bonne expérience.
La méthode de transmission asynchrone est l'inverse. C'est comme au moment du chargement de la page. Une fois la requête synchrone émise, le navigateur attend que le serveur termine la récupération et renvoie le résultat. À ce moment-là, la souris se transformera en une forme d'attente, rappelant à notre utilisateur que la demande n'a pas encore reçu de réponse. Vous ne pouvez rien faire et nos utilisateurs ne peuvent rien faire. attendez... Bien que l'utilisateur ait déjà Vous avez l'habitude d'attendre le chargement de la page de rectification Bien que le temps de synchronisation des requêtes en Ajax ne soit généralement pas plus long que le temps de chargement de la page entière, il faut savoir à quel point c'est pénible. ne rien faire et attendre passivement. Par conséquent, cette requête synchrone doit être utilisée avec prudence...
À ce stade, nous devons nous poser la question, puisque les requêtes asynchrones sont si bonnes, pourquoi ne pas utiliser des requêtes asynchrones ? Ne faites simplement pas de demandes synchrones. Haha, ne soyez pas trop pressé. S'il y a une telle situation, le résultat de notre demande à cette étape est la prémisse de la prochaine demande. Seule la connaissance du résultat de cette étape de la demande déterminera ce que l'utilisateur fera à l'avenir. sens. Alors pensez-vous que vous devriez utiliser des requêtes synchrones ou des requêtes asynchrones ? Évidemment, synchronisez la requête Afin de donner plus de sens à la prochaine étape, pourquoi ne pas attendre un instant pour nos chers utilisateurs ?
Les requêtes synchrones et asynchrones ont leurs propres utilisations. Il n'y a pas de bonne ou de mauvaise distinction. Il s'agit simplement de savoir si elles sont utilisées de manière appropriée ou non
.Avantages et inconvénients d'Ajax 🎜> Les applications Web traditionnelles permettent aux utilisateurs de remplir des formulaires et, lorsque le formulaire est soumis, une demande est envoyée au Web. serveur. Le serveur reçoit et traite le formulaire entrant, puis renvoie une nouvelle page Web. Cette approche gaspille beaucoup de bande passante car la plupart du code HTML des deux pages est souvent le même. Puisque chaque interaction avec l'application nécessite l'envoi d'une requête au serveur, le temps de réponse de l'application dépend du temps de réponse du serveur. Cela se traduit par une interface utilisateur beaucoup moins réactive que les applications natives. Contrairement à cela, une application AJAX ne peut envoyer et récupérer les données nécessaires qu'au serveur. Elle utilise SOAP ou une autre interface de service Web basée sur XML et utilise JavaScript sur le client pour traiter la réponse du serveur. Parce que beaucoup moins de données sont échangées entre le serveur et le navigateur, nous constatons ainsi des applications plus réactives. Dans le même temps, de nombreux travaux de traitement peuvent être effectués sur la machine client qui effectue la demande, ce qui réduit également le temps de traitement du serveur Web.
Inconvénients :
La principale critique de l'utilisation d'Ajax est qu'il peut perturber le comportement normal du bouton de retour du navigateur. Dans le cas de pages mises à jour dynamiquement, l'utilisateur ne peut pas revenir à l'état de la page précédente car le navigateur ne peut mémoriser que les pages statiques de l'historique. La différence entre une page entièrement lue et une page modifiée dynamiquement est très subtile : les utilisateurs souhaitent souvent pouvoir annuler leur opération précédente en cliquant sur le bouton retour, mais dans une application Ajax, cela n'est pas possible. Faites ceci. Cependant, les développeurs ont trouvé différentes façons de résoudre ce problème, la plupart consistant à créer ou à utiliser un IFRAME caché pour reproduire les modifications sur la page lorsque l'utilisateur clique sur le bouton Précédent pour accéder à l'historique. (Par exemple, lorsque l'utilisateur clique à nouveau dans Google Maps, il recherche dans un IFRAME masqué, puis reflète les résultats de la recherche sur l'élément Ajax pour restaurer l'état de l'application tel qu'il était à ce moment-là.)
Un point connexe est que l'utilisation de mises à jour dynamiques de pages rend difficile pour les utilisateurs d'enregistrer un état spécifique dans les favoris. Des solutions à ce problème ont également émergé, dont la plupart utilisent des identifiants de fragments d'URL (souvent appelés ancres, la partie après le # dans l'URL) pour garder une trace et permettre à l'utilisateur de revenir à un état d'application spécifié. (De nombreux navigateurs permettent à JavaScript de mettre à jour dynamiquement les ancres, ce qui permet aux applications Ajax de mettre à jour les ancres tout en mettant à jour le contenu affiché.) Ces solutions résolvent également de nombreux arguments concernant la non prise en charge d'un bouton de retour. Lors du développement d'Ajax, la latence du réseau (le temps entre la requête d'un utilisateur et la réponse du serveur) doit être soigneusement prise en compte. Ne pas donner aux utilisateurs une réponse claire [5], ne pas pré-lire correctement les données [6] ou gérer incorrectement XMLHttpRequest [7] entraînera un sentiment de retard des utilisateurs, ce que les utilisateurs ne veulent pas voir et ne peuvent pas comprendre [8]. ]. Une solution courante consiste à utiliser un composant visuel pour indiquer à l'utilisateur que le système effectue des opérations en arrière-plan et lit des données et du contenu.
Certains appareils portables (tels que les téléphones mobiles, les PDA, etc.) ne prennent pas encore bien en charge Ajax ; les moteurs Ajax créés avec JavaScript, la compatibilité JavaScript et les DeBugs sont des casse-tête ; les changements de page ne sont pas aussi évidents qu'un rechargement d'actualisation, il est donc facile de causer des problèmes aux utilisateurs - les utilisateurs ne savent pas si les données actuelles sont nouvelles ou si elles ont été mises à jour. Les solutions existantes incluent : Les invites de localisation et les zones de mise à jour des données sont conçues pour ; être plus évident, et les utilisateurs sont informés des mises à jour des données, etc. ; la prise en charge du streaming multimédia n'est pas aussi bonne que celle de FLASH et de l'applet Java
