瀏覽器中喚起native app || 跳轉到應用商城下載（二） 之universal links

這波能反殺發表於2019-03-04
瀏覽器APP

上一篇文章

在ios9出來以後，我們發現越來越多的應用能夠直接繞過微信的遮蔽，從其內建瀏覽器中直接喚起app。相比於通過彈窗提示讓使用者到瀏覽器中操作的方式，這無疑是極大的提高了使用者體驗與流量匯入。因此，在ios上實現直接從微信中喚起app變得非常必要。

而其中的關鍵，就在於通用連結universal links：一種能夠方便通過傳統HTTP連結來啟動app的方式，可以通過相同的網址開啟網站和app。

對於ios開發者來說，可以很輕鬆在網上找到非常多給自己的app配置universal links的教程文章，這裡推薦
www.cocoachina.com/ios/2015090…

這篇文章的主要目的，就是從前端角度來聊一聊universal links的運用。

無論是Android還是ios應用，都能夠通過一定的方式捕獲瀏覽器正在進行的url跳轉。我們知道在頁面中通常有如下三種方式能夠訪問別的連結

  • 通過html中的a標籤 
    <a href="universal links">action</a>複製程式碼

  • 通過js的location方法

    window.location = `universal links`;複製程式碼

  • 通過iframe標籤，一般情況下我們會通過js建立一個iframe標籤，並通過設定iframe的src屬性實現跳轉

    var iframe = document.createElement(`iframe`);
iframe.style.cssText = `width: 0; height: 0`;
document.body.appendChild(iframe);
iframe.src = `universal links`;複製程式碼

為了能夠在js中控制跳轉行為，我們基本不會通過a標籤的方式，而選擇2，3種。不過比較頭疼的是，並不是所有手機版本的瀏覽器都能夠毫無顧忌的使用這兩種方式，比如在ios8中，據說他們ios開發通過通常使用的方式，無法捕獲window.location的跳轉，因此我們得采用iframe的方式來實現喚起。而在Android上瀏覽器的表現就更加雜亂不一，因此如果想要兼顧所有的瀏覽器，從測試角度來說，這是一個比較大的工作量。

而universal links如果能夠實現從微信中直接喚起app，那麼微信以外的瀏覽器的複雜場景我們都不需要考慮了。因此這簡直就是一件利國利民的好事，從開發到測試的工作量都大大降低。

讀過上一篇文章的同學應該知道，單單從瀏覽器層面，我們無法精準的判斷本地是否安裝了app。這給我們實現這一需求造成了非常多的困擾。而從ios9.2開始，針對universal links，有一個非常重要的改動，通俗來說，就是必須通過訪問不同的url連結，我們才能在微信中喚起本地app。

在上面我們介紹過，universal links能夠使用和訪問普通網頁一樣的http連結，喚起我們自己的app。比如我們訪問一個頁面http://www.test.com/gold能夠在瀏覽器中開啟一個頁面，而當我們在手機瀏覽器中，通過上面的三種方式嘗試訪問同樣的地址http://www.test.com/gold，只要本地安裝了指定的app，就可以開啟app中的對應頁面。但是9.2的改動之後就不行了，在9.2之後，我們必須使用2個不同的域名，並且這2個域名指向同一個頁面，我們才能夠在微信中喚起app。

如果我們僅僅只是配置了一個域名，那麼當我們在微信中開啟這個網頁，並且在頁面中訪問自身時，頁面僅僅相當於一次重新整理，而app並不會被喚起。而點選在瀏覽器中開啟時，會喚起app。

對於不瞭解的人來說，這是一個深坑，而當我們瞭解了其中的細節，那麼我們就能夠利用這一點，完美的實現有則喚起，無則下載的需求。

假如我們有一個app，demoAPP。我們的ios同事已經配置好了universal links，2個域名分別為a.com, b.com。另外我們有一個宣傳頁面，在瀏覽器中，a.com/activity與b.com/activity都能夠訪問該宣傳頁面。

為了規範統一，我們規定將該宣傳頁面從demoAPP分享出來時，頁面地址使用a.com/activity，而在當我們想要喚起demoAPP時，使用b.com/activity.

另外，在實踐中我發現如下特性，如果本地安裝了demoAPP，那麼a.com/activity中喚起app之後，不會發生任何變化。而如果本地沒有安裝demoAPP，頁面會跳轉到b.com/activity，當到了這個頁面，我們已經知道無法喚起，因此直接下載即可。

因此根據這個特性，我們有了如下的實踐方案

var openURL = {
    open: `b.com/activity`,
    down: `downloadurl`
},
// 開啟app的按鈕
btn = document.querySelector(`.open-app`),
curURL = window.location.href;
if (/b.com/ig.test(curURL)) {
    window.location = openURL.down;
    return;
}

btn.onclick(function() {
    window.location = `b.com/activity`;
})複製程式碼

是不是很簡單！

當然在具體實現上，還有許多繁瑣的細枝末節需要我們一步一步去完善。這裡只是提供了一個思路。從整體來說，這個需求並不是一個簡單的任務，我們需要後端同學配置2套域名，需要ios同事配合，甚至還需要和產品不停的溝通，因為有一些確實無法實現的東西需要他們理解。

第三方

老實說，如果自己勞心勞力想要比較完善的實現這麼個需求，真的吃力不討好，需要配合的部門太多，耗時太多，最後的效果還並不是很好，很多使用者還對這種彈窗下載提示真的深惡痛絕。因此，通過第三方的解決方案無疑是最好的辦法。

這裡推薦2個第三方方案，具體的優勢，實現與配置方式在他們網站中都有詳細的講解，如果真的有接到這個需求的同學，強烈建議參考。當然，如果有資料隱私這方面的考慮的話，就還是自己老老實實的做相容吧，反正方案就是這2篇文章說的這些。

磨窗
www.magicwindow.cn/

deepshare
deepshare.io/redirect-on…

我知道有的同學會想吐槽，說了這麼多，原來還是第三方才是最佳方案，幹嘛不直接說得了！那麼我只能說，這麼想的同學，肯定不知道經驗這個東西，在撕b上到底有多重要！！

最後！公眾號求一波關注！！！！搜尋isreact可以找到我

相關文章