Il est courant que h5 évoque ce besoin dans les applications. À une époque où le mobile est roi, h5 joue un rôle important dans le détournement du trafic des applications.
La méthode d'évocation que nous utilisons actuellement est le schéma d'URL (pris en charge par les plates-formes iOS et Android). Il vous suffit d'enregistrer le schéma lors du développement de l'application native, puis lorsque l'utilisateur clique sur un tel lien, il accède automatiquement à l'application.
Trois options d'excitationiframe
var last = Date.now(), doc = window.document, ifr = doc.createElement('iframe');//Créer un iframe caché ifr.src = nativeUrl;ifr.style.cssText = 'display:none;border :0;largeur:0;hauteur:0;';doc.body.appendChild(ifr);setTimeout(function() { doc.body.removeChild(ifr); //setTimeout inférieur à 2000 est généralement un échec d'appel if (Date.now() - last < 2000) { if (typeof onFail == 'function') { onFail( } else) { //Invites contextuelles ou traitement du téléchargement, etc.} } else { if (typeof onSuccess == 'function') { onSuccess( } }}, 1000);Le principe d'évocation de la solution iframe est le suivant : lorsque le programme passe en arrière-plan, le timer sera retardé (une autre situation où le timer est inexact). Si l'application est réveillée, la page Web entrera inévitablement en arrière-plan. Si l'utilisateur quitte l'application, le temps dépassera généralement 2 secondes ; si l'application n'est pas réveillée, la page Web n'entrera pas en arrière-plan. setTimeout est essentiellement déclenché. Temps, et le temps ne dépassera pas 2s.
window.location.href saute directement
window.location.href = nativeUrl;
un tag évoque
<a href=nativeUrl>Révoquer l'application</a>
Test par navigateur de trois scénarios d'évocation
iframe évoque les résultats des tests d'application
window.location.href évoque les résultats des tests d'application
une balise évoque les résultats des tests de l'application
iframe et window.location.href évoquent le contraste
iframe, window.location.href et une balise évoquent une comparaison entre les trois
Analyse des résultats des testsPremièrement, les modèles et navigateurs testés sont limités et les résultats ci-dessus sont uniquement à titre de référence.
En comparant l'évocation iframe et location.href, nous pouvons trouver :
Grâce à l'analyse comparative ci-dessus, il est plus approprié d'utiliser iframe pour Android et window.location.href pour iOS.
La différence entre l'évocation directe et l'évocation événementielle lors de l'entrée dans la page
Il existe des différences évidentes entre ces deux scénarios d'éveil sous Android, qu'il soit évoqué par iframe ou location.href, prenons comme exemple le chrome des Xiaomi 1s :
<a id=goApp href=javascript:void(0);>Cliquez sur moi pour ouvrir l'application</a>
Les événements de liaison pilotent manuellement l’évocation :
// window.onload = function () { $('#goApp').on(click, function () { window.lib.callapp(nativeUrl);//iframe //window.location.href = nativeUrl; });};Entrez dans la page pour appeler directement :
//Échec du rappel window.onload = function () { window.lib.callapp(nativeUrl);//iframe //window.location.href = nativeUrl;};Lier un événement, js évoque
//Échec du rappel window.onload = function () { $('#goApp').on(click, function () { window.lib.callapp(nativeUrl);//iframe //window.location.href = nativeUrl; }); $('#goApp).trigger('cliquez');};À l'origine, je pensais que la méthode $('#goApp).trigger('click'); était la même que le clic manuel, mais les performances réelles sont que les performances des événements déclenchés par js sont aussi invalides qu'un saut de page direct.
À partir du billet de blog de référence, nous pouvons voir que la plate-forme Android et les différents fabricants d'applications sont très différents. Par exemple, Chrome ne prend plus en charge les sauts de schéma de déclenchement via js (clics non-utilisateurs), la définition des adresses src iframe, etc. en avant. Par conséquent, il existe toujours une grande différence entre le déclenchement js et les clics directs de l'utilisateur, qui peut être similaire aux restrictions sur la lecture audio.
enfinAprès les tests et analyses ci-dessus, il a été essentiellement déterminé qu'il est plus approprié d'utiliser window.location.href pour iOS et iframe pour Android. Lorsque nous utilisons iframe pour évoquer, nous gérons généralement l'échec de l'évocation en téléchargeant directement. Cependant, il y a un problème ici, c'est-à-dire que le navigateur ne peut pas détecter si l'évocation a réussi. l'évocation est réussie, le navigateur apparaîtra toujours. L'expérience de téléchargement des informations est très mauvaise. Bien sûr, nous devons également gérer certaines fonctions de rappel de réussite ou d'échec. Peut-être que notre scénario doit simplement être évoqué et ne nécessite pas de téléchargement après un échec.
Concernant l'utilisation de location.href pour évoquer l'application native sur l'iPhone, la méthode de passage à la page intermédiaire peut être meilleure que le traitement direct de la page actuelle.
Ce qui précède représente l’intégralité du contenu de cet article. J’espère qu’il sera utile à l’étude de chacun. J’espère également que tout le monde soutiendra le réseau VeVb Wulin.