在這個流量爲王的互聯網背景下,移動端的H5頁面顯然在導流上承擔着重要做用,在H5頁面上,咱們對引流的需求有兩種:web
從運營角度來看,引導已下載用戶打開App,能提升用戶粘性和活躍度,而用戶在App內的產品體驗天然也比H5頁面要好;引導未下載用戶下載App並進入指定頁面,顯然能給用戶更好的產品初體驗。算法
這裏其實就解釋了咱們作H5喚醒App並直達指定頁面的必要性。瀏覽器
喚醒App這件事,在不一樣平臺要採用不一樣的方法,主要是這三個:微信
URL Scheme是iOS、Android都兼容的機制,只須要原生App開發時註冊Scheme便可,用戶點擊此類連接時,會自動喚醒App,並藉助URL Router機制跳轉到指定頁面。app
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ] <scheme name>:是scheme的名稱,表明着協議名稱。 <hierarchical part>:它包含 authority 和 path。 <query>:可選項目,隔開或&隔開的鍵值對<key>=<value> <fragmentg> :可選項目包,其它額外的標識信息
儘管URL Scheme兼容性高,但卻存在許多限制,好比:搜索引擎
正是因爲這些限制的存在,蘋果和安卓都不約而同發佈了本身的第二套方案:iOS的Universal Link、Android的App Links。spa
Universal Link是iOS9後蘋果推出的通用連接技術,可以方便的經過一個https連接來打開App指定頁面,不須要額外的判斷,若是沒有安裝App,能夠跳轉到自定義地址。code
相對Scheme的優點在於,Universal Link是一個Web Link,所以少了不少麻煩:blog
Android M以上版本能夠經過App Links,讓用戶在點擊一個連接時跳轉到App的指定頁面,前提是這個App已經安裝並通過驗證。App Links的最大的做用,就是能夠避免從頁面喚醒App時出現的選擇瀏覽器選項框,前提是必須註冊相應的Scheme,就能夠實現直接打開關聯的App。索引
實際上App Links和Universal Links差別不大,但相對來講有不一樣的限制:
這幾種方式不管哪一種都沒法解決這幾個問題:
那麼怎樣實現用戶安裝App後進入指定頁面呢?
衆所周知,蘋果出於用戶隱私的保護,設置了名爲沙盒的機制:應用只能訪問它聲明能夠訪問的資源,但沙盒也阻礙了應用間合理的信息共享。
但也不是徹底沒辦法,好比使用模糊匹配,儘量收集設備的特徵,將Web和App上的信息點配合算法作一個匹配是能夠作到的,但準確率和成功率就取決於算法自己。若是App自己業務需求不高,那麼低精度的方案也能夠知足,但若是業務上須要一個能作到一對一精準匹配的方案,那麼精準度不夠高顯然會影響業務的開展。
若是嫌精準度不夠高或者實現難度太大的話,能夠交給專業的第三方去作,畢竟這幾項技術是基於系統平臺的,Android 及 iOS 每一個系統版本的迭代後,配置方式都會有新的變化,且安卓機型衆多,瀏覽器衆多等也會致使出現兼容問題,開發者自行研發的話,資源配置以及系統更新後的維護成本是比較高的,還要考慮各類各樣的跳轉場景問題。
直接採用第三方SDK的好處就是,資源配置、兼容方面的適配這些事情均可以交給它們去作,畢竟這些供應商自己就是專業作這項服務的,它們提供的服務在穩定性和精準度方面也是經受過市場檢驗的,至少在精準匹配方面,有些已經能在邀請分享方面作到一對一匹配,集成SDK也花不了多少時間,十幾分鍾就能夠搞定。
國內外提供這項技術的第三方服務商:
國內有:openinstall
國外有:Branch