Comment invoquer une application en HTML5

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.

iframe

 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

1. X signifie que l'éveil a échoué, √ signifie que l'éveil a réussi.
2. La marque rouge indique qu'elle sera évoquée directement après l'entrée dans la page, et la marque verte indique qu'elle sera évoquée après une opération manuelle d'événement.
3. Machine de test iOS : iPhone 6P ; Machine de test Android : Xiaomi 1s.

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

Premiè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 :

1. Pour iOS, le saut location.href est plus approprié, car cette méthode peut évoquer avec succès l'application dans Safari. Inutile de dire l'importance de Safari comme navigateur par défaut pour iPhone, mais pour les clients WeChat et QQ, ces deux méthodes dans iOS sont inutiles ==
2. Pour Android, lorsque la page est directement invoquée, iframe et location.href sont identiques, mais si elle est pilotée par des événements, iframe évoque mieux que location.href.
3. Grâce aux tests, nous avons constaté que pour de nombreux navigateurs, les performances de l'évocation directe lors de l'entrée dans la page et de l'évocation basée sur les événements sont différentes. En termes simples, l'évocation directe échoue davantage.

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.

Aprè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.