背景
對于APP來說，回流分享頁是最好的最便宜的也是最病毒式的拉新方式。讓新使用者去下載下傳APP是重要的。對老使用者來說，可以直接調起APP也是提升使用者體驗和讓使用者有侵入式體驗的重要手段。是以我們一起來看看有哪些方式可以喚起APP的
概念叙述
調起APP在不同平台用不同的方式，主要就分3個 * URI Scheme * universal Link * Android App Links 現在還是有很多第三方來協助你處理這個事情，通過接入他們的SDK和用戶端代碼來處理，但是萬變不離其宗，所有的第三方也離不開這3種方式。
URI Scheme:
URI Scheme 是iOS，Android平台都支援，隻需要原生APP開發時注冊 scheme ， 使用者點選到此類連結時，會自動喚醒APP，借助于 URL Router 機制，則還可以跳轉至指定頁面。
1.<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
：是scheme的名稱，代表着協定名稱。
：它包含 authority 和 path。
：可選項目，隔開或&隔開的鍵值對=
：可選項目包，其它額外的辨別資訊 例如： git://github.com/user/project-name.git ftp://user1:1234@位址 musically://musical?id=xxxx&key=xxxx
2.universal Link:
iOS9 後推出的一項功能，通用連結，對于前端即通路一個https的url,如果這個url帶有你送出給開發平台的配置檔案中比對規則的内容，iOS系統會去嘗試打開你的app，如果打不開，系統就會在浏覽器中轉向你要通路的連結。
universal Link 工作方式如下：
通路web link
iOS通路 https://xxxxxxx/apple-app-site-association 并解析，擷取檔案中的資訊(App的Team ID和Bundle ID)
通過Bundle ID 檢查本地是否存在對應app，和檢查PATH資訊等，如果有app打開app，如果沒有則跳轉對應web link(可通過代碼實作跳去app Stroe)
3.Android App Links:
在2015年的Google I/O大會上，Android M宣布了一個新特性：App Links讓使用者在點選一個普通web連結的時候可以打開指定APP的指定頁面，前提是這個APP已經安裝并且經過了驗證，否則會顯示一個打開确認選項的彈出框，隻支援Android M以上系統。
簡單的說就是建立APP和某個連結的關聯，避免系統在處理該類型連結時彈出選擇框。彈框最常見的就是浏覽器打開時的選擇框。彈出選擇框是應用注冊了相應scheme，applinks的作用是避免在打開自己域名的連結時彈出選擇（前提是注冊了相應scheme），可以實作直接打開自己關聯的app。
對比/優劣
URI Scheme: 根據圖檔可以看到URI Scheme的相容性是最高，在使用的過程中，會發現有很多限制:
當要被喚起的app沒有安裝時，這個連結就會出錯。在國内非常雜亂的浏覽器中，會出錯的現象會很多種類型。
當注冊有多個scheme相同的時候，目前沒有辦法區分。
不支援從其他app中的UIWebView中跳轉到目标app 也就因為會有這些原因，apple和android都出現了自己第二套解決方案。
universal Link 從連結上看來，是一個web link，是以也就解決了當沒有app時，跳轉也不會出現報錯，是以相對Scheme優勢就提現出來了.
當已經安裝app，不需要加載任何web頁面，app就會立即啟動；app沒有安裝，就會跳去對應的web link。
universal Link 是從伺服器上查詢是哪個app需要被打開，是以不會存在沖突問題
universal Link 支援從其他app中的UIWebView中跳轉到目标app
隐私性，提供universal Link給别的app進行app間的交流，然而對方并不能夠用這個方法去檢測你的app是否被安裝。 當然universal Link也不是十全十美的,缺陷也是存在的:
會記住使用者的選擇：在使用者點選了Universal link之後，iOS會去檢測使用者最近一次是選擇了直接打開app還是打開網站。一旦使用者點選了這個選項，他就會通過safiri打開你的網站。并且在之後的操作中，預設一直延續這個選擇，除非使用者從你的webpage上通過點選Smart App Banner上的OPEN按鈕來打開。
app link 和 universal Link 差異不大。也是為了更好的提供調起app出現的google的方案。優點與 universal Link 差不多，缺點主要如下：
國内的支援相對較差，在有的浏覽器或者手機ROM中并不能連結至APP，而是在浏覽器中打開了對應的連結。
在詢問是否用APP打開對應的連結時，如果選擇了“取消”并且“記住選擇”被勾上，那麼下次你再次想連結至APP時就不會有任何反應
無論哪一種方式目前都沒有解決幾個問題： * 如果裝置上沒有安裝這個app的時候，安裝完畢後，無法保留住此時使用者停留的上下文。 * 因為web沒有辦法監聽到APP是否安裝，是以都需要通過一些手段來相容調起app或者是去下載下傳頁
使用 & 需要注意的内容
1.URI Scheme：
使用: 這種方式是當期使用最廣泛，也是最簡單的，但是需要手機，APP支援 URI Scheme 。
需要注意的内容 & 遇到的問題： 其實使用URI Scheme 部分前端沒有太多可以排查的問題，會遇到的問題主要是兩個部分。1. 在android的相容性處理（國内的浏覽器無力吐槽ing），2. 當沒有安裝app的情況，URI Scheme 會有各種報錯，也需要處理…
2.universal Link & app Links
使用：對于有app的使用者，隻是打開一個連接配接，但是需要注意的是需要考慮到沒有APP的使用者。(個人的解決方案：針對域名來判斷，當域名為特定的universal Link 的域名，則跳轉去下載下傳頁面）
需要注意的内容 & 遇到的問題：
● apple-app-site-association 和 assetlinks.json 的配置
● 需要保證使用的連結跨域(universal Link)
● 直接将universal Link 貼入浏覽器的url中不會生效
● window.onload 或者使用者沒有任何事件觸發的情況下，universal Link也不會生效
兩大平台的特殊處理(facebook & twitter)
facebook 和 twitter 作為國外的兩大資訊聚合平台，對于在他們app中調起app也有自己的一套方式。 根據要求通過添加META頭來處理打開APP facebook:
<meta property="fb:app_id" content="xxxxxx" />
<meta property="og:type" content="xxxx"/>
<meta property="og:title" content="xxx" />
<meta property="al:ios:url" content="{{ uri scheme }}" />
<meta property="al:android:url" content="{{ uri scheme }}" />
<meta property="al:ios:app_store_id" content="{{app_store_id}}" />
<meta property="al:ios:app_name" content="{{xxx}}" />
<meta property="al:android:app_name" content="{{xxx}}" />
<meta property="al:android:package" content="{{android:package}}" />
twitter:
<meta name="twitter:card" content="app" />
<meta name="twitter:site" content="xxxxx" />
<meta name="twitter:title" content="xxxxx" />
<meta name="twitter:description" content="xxxxxxx" />
<meta name="twitter:image" content="xxxx" />
<meta name="twitter:app:name:iphone" content="xxx">
<meta name="twitter:app:id:iphone" content="xxx">
<meta name="twitter:app:url:iphone" content="{{Scheme}}">
<meta name="twitter:app:name:ipad" content="xxx">
<meta name="twitter:app:id:ipad" content="xxx">
<meta name="twitter:app:url:ipad" content="{{Scheme}}">
<meta name="twitter:app:name:googleplay" content="xxx">
<meta name="twitter:app:id:googleplay" content="xxx">
<meta name="twitter:app:url:googleplay" content="{{Scheme}}">
使用 checkList(前端)
1.scheme
iOS 和 android 是否已經支援 此scheme
js處理相容代碼
2.universal Link (apple-app-site-association 官方文檔)
HTTPS的域名
iOS9 以上
universal Link 是否跨域
universal Link的落地頁是否是下載下傳頁面
apple-app-site-association 配置在 host的根目錄和.well-known下
官方檢測: apple-app-site-association 檢測
apple-app-site-association會在第一次打開app或者更新app時候會去拉去,是以确認是否更新了apple-app-site-association後沒有更新過app
檢查apple-app-site-association paths 大小寫敏感 支援通配符
該裝置的使用者選擇了直接打開app還是打開網站，如果選擇打開網站，需要通過smart banner 重新啟用
跳轉處理是否是在使用者事件中觸發，而不是進入頁面後直接觸發
3.app links (android app links官方文檔)
跳轉後的落地頁是否是下載下傳頁面
assetlinks.json 配置在 host的.well-known下
官方生成/檢測: android app links檢測
4.facebook (facebook app link官方文檔)
将需要的meta頭資訊填充完畢
檢測連結 分享調試器 – Facebook for Developers , 确認分享連結中擷取到了所需要的meta頭
分享過的連結會有緩存，在檢測中清楚緩存
如果web和wap連結一緻，确認在web中也添加了相同的meta頭，facebook會預設從web中擷取
5.twitter (Twitter app card官方文檔)
檢測連結 Twitter app card 檢測
連結
webview如何屏蔽universal Link
apple-app-site-association 官方文檔
apple-app-site-association 檢測
android app links官方文檔
android app links檢測
facebook app link官方文檔
分享調試器 – Facebook for Developers
Twitter app card官方文檔
Twitter app card 檢測
原文釋出時間為：2018-09-9
本文來自雲栖社群合作夥伴“
前端大學”，了解相關資訊可以關注“
”。