h5 обычно вызывает эту потребность в приложениях. В эпоху, когда мобильные устройства являются королем, h5 играет важную роль в перенаправлении трафика приложений.
Метод вызова, который мы сейчас используем, — это схема URL-адресов (поддерживается платформами iOS и Android). Вам нужно только зарегистрировать схему во время разработки собственного приложения, и тогда, когда пользователь нажмет на такую ссылку, он автоматически перейдет к приложению.
Три варианта возбужденияiframe
var last = Date.now(), doc = window.document, ifr = doc.createElement('iframe');//Создаем скрытый iframe ifr.src =nativeUrl;ifr.style.cssText = 'display:none;border :0;ширина:0;высота:0;';doc.body.appendChild(ifr);setTimeout(function() { doc.body.removeChild(ifr); //setTimeout меньше 2000 обычно является ошибкой вызова if (Date.now() - Last < 2000) { if (typeof onFail == 'function') { onFail() } else; { //Всплывающие подсказки или обработка загрузки и т. д.} } else { if (typeof onSuccess == 'function') { onSuccess() } }}; 1000);Принцип вызова решения iframe таков: когда программа переключается в фоновый режим, таймер будет задерживаться (еще одна ситуация, когда таймер работает неточно). Если приложение пробуждается, веб-страница неизбежно переходит в фоновый режим. Если пользователь переключается обратно из приложения, время обычно превышает 2 секунды; если приложение не пробуждается, веб-страница не переходит в фоновый режим. время, и время не будет превышать 2 с.
window.location.href переходит напрямую
window.location.href = NativeUrl;
тег вызывает
<a href=nativeUrl>Отменить приложение</a>
Браузерное тестирование трёх сценариев вызова
iframe вызывает результаты теста приложения
window.location.href вызывает результаты теста приложения
тег вызывает результаты теста приложения
iframe и window.location.href вызывают контраст
iframe, window.location.href и тег вызывают сравнение между тремя
Анализ результатов испытанийВо-первых, протестированные модели и браузеры ограничены, и приведенные выше результаты предназначены только для справки.
Сравнивая iframe evoction и location.href, мы можем найти:
Судя по приведенному выше сравнительному анализу, более уместно использовать iframe для Android и window.location.href для ios.
Разница между прямым вызовом и вызовом, управляемым событиями, при входе на страницу
Между этими двумя сценариями возбуждения в Android существуют очевидные различия, независимо от того, вызвано ли оно iframe или location.href, в качестве примера возьмем Chrome Xiaomi 1s:
<a id=goApp href=javascript:void(0);>Нажмите меня, чтобы открыть приложение</a>
Привязка событий вручную вызывает вызов:
//Успешно вызван window.onload = function () { $('#goApp').on(click, function () { window.lib.callapp(nativeUrl);//iframe //window.location.href =nativeUrl; });};Введите страницу для прямого вызова:
//Ошибочный вызов window.onload = function () { window.lib.callapp(nativeUrl);//iframe //window.location.href =nativeUrl;};Привязать событие, js Evoke
//Ошибочный вызов window.onload = function () { $('#goApp').on(click, function () { window.lib.callapp(nativeUrl);//iframe //window.location.href = ownUrl; }); $('#goApp).trigger('клик');};Первоначально я думал, что метод $('#goApp).trigger('click'); тот же, что и щелчок вручную, но фактическая производительность такова, что производительность событий, запускаемых js, так же недопустима, как и прямой переход на страницу.
Из справочного сообщения в блоге мы видим, что платформа Android и разные производители приложений сильно различаются. Например, Chrome больше не поддерживает переходы по схеме через js (непользовательские клики), установку адресов iframe src и т. д. с 25 и. далее. Таким образом, по-прежнему существует большая разница между запуском js и прямыми нажатиями пользователя, которая может быть аналогична ограничениям на воспроизведение звука.
наконецПосле вышеуказанного тестирования и анализа было установлено, что более целесообразно использовать window.location.href для ios и iframe для Android. Когда мы используем iframe для вызова, мы обычно обрабатываем сбой вызова путем прямой загрузки. Однако здесь есть проблема: браузер не может определить, был ли вызов успешным. вызов прошел успешно, браузер все равно всплывает. Опыт загрузки информации очень плохой. Конечно, нам также необходимо обрабатывать некоторые функции обратного вызова при успехе или сбое. Возможно, наш сценарий нужно только вызвать и не требует загрузки после сбоя.
Что касается использования location.href для вызова собственного приложения на iPhone, метод перехода на промежуточную страницу может быть лучше, чем прямая обработка текущей страницы.
Выше приведено все содержание этой статьи. Я надеюсь, что она будет полезна для изучения всеми. Я также надеюсь, что все поддержат сеть VeVb Wulin.