h5喚起app這種需求是常見(jiàn)的。在移動(dòng)為王的時(shí)代，h5在app導(dǎo)流上發(fā)揮著重要的作用。

目前我們采用的喚起方式是url scheme(iOS，Android平臺(tái)都支持)，只需原生APP開(kāi)發(fā)時(shí)注冊(cè)scheme， 那么用戶點(diǎn)擊到此類鏈接時(shí)，會(huì)自動(dòng)跳到APP。

三種喚起方案

iframe

var last = Date.now(),
    doc = window.document,
    ifr = doc.createElement('iframe');

//創(chuàng)建一個(gè)隱藏的iframe
ifr.src = nativeUrl;
ifr.style.cssText = 'display:none;border:0;width:0;height: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方案的喚起原理是: 程序切換到后臺(tái)時(shí)，計(jì)時(shí)器會(huì)被推遲(計(jì)時(shí)器不準(zhǔn)的又一種情況)。如果app被喚醒那么網(wǎng)頁(yè)必然就進(jìn)入了后臺(tái)，如果用戶從app切回來(lái)，那么時(shí)間一般會(huì)超過(guò)2s;若app沒(méi)有被喚起，那么網(wǎng)頁(yè)不會(huì)進(jìn)入后臺(tái)，setTimeout基本準(zhǔn)時(shí)觸發(fā)，那么時(shí)間不會(huì)超過(guò)2s。

window.location.href直接跳轉(zhuǎn)

window.location.href = nativeUrl;

a標(biāo)簽喚起

<a href="nativeUrl">喚起app</a>

三種喚起方案的瀏覽器測(cè)試

1. X表示喚起失敗，√表示喚起成功
2. 紅色標(biāo)記表示進(jìn)入頁(yè)面直接喚起，綠色表示人工事件操作后喚起
3. ios測(cè)試機(jī):iphone 6p;android測(cè)試機(jī):小米1s

iframe喚起app測(cè)試結(jié)果

window.location.href喚起app測(cè)試結(jié)果

a標(biāo)簽喚起app測(cè)試結(jié)果

iframe和window.location.href喚起對(duì)比

iframe、window.location.href和a標(biāo)簽喚起三者對(duì)比

測(cè)試結(jié)果分析

首先測(cè)試的機(jī)型和瀏覽器有限，上述結(jié)果僅作參考.

對(duì)比iframe喚起和location.href，我們可以發(fā)現(xiàn)：

1. 對(duì)于ios來(lái)說(shuō)，location.href跳轉(zhuǎn)更合適，因?yàn)檫@種方式可以在Safari中成功喚起app。Safari作為iphone默認(rèn)瀏覽器其重要性就不用多說(shuō)了，而對(duì)于微信和qq客戶端，ios中這兩種方式都沒(méi)有什么卵用==
2. 對(duì)于Android來(lái)說(shuō)，在進(jìn)入頁(yè)面直接喚起的情況下，iframe和location.href是一樣的，但是如果是事件驅(qū)動(dòng)的喚起，iframe喚起的表現(xiàn)比location.href要更好一點(diǎn)。
3. 通過(guò)測(cè)試可以發(fā)現(xiàn)，進(jìn)入頁(yè)面直接喚起和事件驅(qū)動(dòng)的喚起，對(duì)于很多瀏覽器，兩者的表現(xiàn)是不同的，簡(jiǎn)單來(lái)說(shuō)，直接喚起的失敗更多。

通過(guò)上述對(duì)比分析，Android使用iframe喚起，ios采用window.location.href喚起更合適一點(diǎn)。

進(jìn)入頁(yè)面直接喚起和事件驅(qū)動(dòng)喚起的區(qū)別

這兩種喚起場(chǎng)景在Android中有明顯的區(qū)別，無(wú)論是iframe的方式喚起還是location.href,以小米1s的chrome為例:

<a id="goApp" href="javascript:void(0);">點(diǎn)我打開(kāi)APP</a>

綁定事件 人工驅(qū)動(dòng)喚起：

//成功喚起
window.onload = function () {
    $('#goApp').on("click", function () {
        window.lib.callapp("nativeUrl");//iframe
        //window.location.href = nativeUrl;
    });
};

進(jìn)入頁(yè)面直接喚起：

//喚起失敗
window.onload = function () {
    window.lib.callapp("nativeUrl");//iframe
    //window.location.href = nativeUrl;
};

綁定事件，js喚起

//喚起失敗
window.onload = function () {
    $('#goApp').on("click", function () {
        window.lib.callapp("nativeUrl");//iframe
        //window.location.href = nativeUrl;
    });

    $('#goApp).trigger('click');
};

原本我以為$('#goApp).trigger('click');的方式和人工點(diǎn)擊是一樣的，而實(shí)際表現(xiàn)是，js觸發(fā)事件的表現(xiàn)和頁(yè)面直接跳轉(zhuǎn)一樣無(wú)效。

從參考的博文中看到 Android平臺(tái)和各個(gè)app廠商差異很大，比如Chrome從25及以后就不再支持通過(guò)js觸發(fā)（非用戶點(diǎn)擊），設(shè)置iframe src地址等來(lái)觸發(fā)scheme跳轉(zhuǎn)。所以js觸發(fā)和直接用戶點(diǎn)擊區(qū)別還是很大的，跟音頻播放的限制異曲同工吧。

最后

經(jīng)過(guò)上述的測(cè)試和分析，基本敲定ios用window.location.href的方式喚起比較合適，Android用iframe喚起比較合適。我們?cè)谑褂胕frame喚起時(shí)，一般對(duì)喚起失敗的處理是直接下載，但是這里就有一個(gè)問(wèn)題，就是瀏覽器無(wú)法檢測(cè)到喚起是否成功，即，如果我喚起成功后返回瀏覽器，瀏覽器還是會(huì)彈出下載信息，這個(gè)體驗(yàn)很差。當(dāng)然我們也需要處理一些成功或失敗的回調(diào)函數(shù)，說(shuō)不定我們的場(chǎng)景只需要喚起而并不需要失敗后的下載呢。

關(guān)于使用location.href喚起iphone手機(jī)上的原生app，跳轉(zhuǎn)中間頁(yè)的處理方式可能也比當(dāng)前頁(yè)直接處理更好一點(diǎn)。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。