
背景
對于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
本文來自雲栖社群合作夥伴“
前端大學”,了解相關資訊可以關注“
”。