前端喚醒APP

需求源來

由於工做須要,咱們常常會在自家產品的APP裏開發一些h5的活動的頁面,做爲營收重要的一部分,咱們確定要想盡辦法擴大傳播範圍,因此分享活動是必不可少又是很關鍵的一步,可是不少信息不能直接在外部瀏覽器經過請求獲取,因此咱們須要有一個專門的分享按鈕提供給用戶在外部瀏覽器打開,引導喚醒APP進入頁面,

URL Scheme —— 喚端媒介

URL Scheme是一種協議媒介, 就是應用將其自身」綁定」到一個自定義 URL scheme 上，該 scheme 用於從瀏覽器或其餘應用中啓動本應用,並且通常都有本身的一套路由體系,能夠經過不停的參數到達任意界面

標準的格式是

[scheme:][//host:port][path][?query][#fragment]

• scheme : 協議名稱 - 必須
• host : 協議地址 - 必須
• port : 協議的端口，能夠不填
• path : 協議路徑，可用 / 鏈接多個
• query : 攜帶的參數可用 & 鏈接多個
• fragment : 錨點

固然裏面的特殊字符也須要先進行url編碼,具體怎麼在APP自定義scheme就不屬於這篇文章的範圍,咱們講講瀏覽器是怎麼調用的

使用

<a href="[scheme:][//host:port][path][?query][#fragment]">打開應用</a>

或者動態建立一個隱藏式跳轉,大致流程無非就是幾種

• 新建一個隱藏的 iframe ，地址指向scheme(除了低版本手機基本被廢棄了)
• 使用 window.location 或者 window.location.href直接跳轉
• 新建一個隱藏的 a 標籤，地址指向打開的url，並觸發打開連接事件

當遇到某些場景下一個方法不能使用的話,就能夠考慮其餘的兼容方案試試了

判斷是否喚醒成功及備用方案

能成功喚醒APP的前提是,用戶設備上已經安裝了該應用,退一步來講即便沒有安裝也但願能夠引導用戶去下載咱們的APP,可是熟悉上面的方法的話也能知道,他們無法告訴頁面當前是否喚醒成功或者用戶是否安裝過應用,這時候咱們一般會利用一些事件觸發來判斷是否可能的狀況

pagehide

離開網頁有多種方式。如點擊一個連接，刷新頁面，提交表單，關閉瀏覽器等。.

onpagehide 事件有時能夠替代 onunload 事件，但 onunload 事件觸發後沒法緩存頁面。

object.addEventListener("pagehide", myScript);

visibilitychange

瀏覽器標籤頁被隱藏或顯示的時候會觸發visibilitychange事件.

document.addEventListener("visibilitychange", function() {
  console.log( document.visibilityState );
});

document.hidden

經過document.hidden屬性,可判斷頁面是否可見。 若是不可見，則document.hidden爲true. 若是可見， 則爲false。

function handleVisibilityChange() {
  if (document.hidden) {
    pauseSimulation();
  } else  {
    startSimulation();
  }
}

document.addEventListener("visibilitychange", handleVisibilityChange, false);

利用這些事件結合定時器,能夠限定時間內自動觸發下載引導,固然也取決於瀏覽器API兼容性和系統性能等不可控因素

侷限

並非全部都支持scheme方法喚醒應用,例如微信瀏覽器等官方對全部的分享連接作了屏蔽,會經過白名單控制是否容許微信內喚醒,如今基本只能在瀏覽器使用.APP都不會但願用戶能夠選擇離開

並且系統或者瀏覽器的支持方式也不同,有些會先詢問用戶是否容許打開應用,有些是直接喚醒

在 iOS 12.3版本之後,safari有一個bug,前後使用scheme和download app會喚醒APP以後再進入App store,用universal link能夠解決這個問題

Universal Links

Seamlessly link to content inside your app, or on your website in iOS 9 or later. With universal links, you can always give users the most integrated mobile experience, even when your app isn’t installed on their device.

iOS 9.0 以上才支持的新特性,能夠經過https連接來打開APP（手機中已經安裝此APP）,或者跳轉到https連接（手機中沒有安裝此APP）,用戶體驗比scheme卓越,能夠不通過確認框直接喚醒APP,甚至支持在微信喚醒不須要配置白名單.

關於openSDK1.8.6的更新說明

格式跟普通URL同樣

https://xxx.xxx.xxx/xxx

若是用戶已經安裝過應用則直接喚醒,不然就跳去地址進行下載引導

配置

• 擁有一個支持 https 的域名
• 在開發者中心，Identifiers 下 AppIDs 找到本身的 App ID，編輯打開 Associated Domains 服務。
• 打開工程配置中的 Associated Domains ，在其中的 Domains 中填入你想支持的域名，必須以 applinks: 爲前綴
• 配置 apple-app-site-association 文件，文件名必須爲 apple-app-site-association ，不帶任何後綴
• 上傳該文件到你的 HTTPS 服務器的 根目錄 或者 .well-known 目錄下

Universal Link的基本運做流程

• APP第一次啓動 or APP更新版本後第一次啓動
• APP向工程裏配置的域名發起Get請求拉取apple-app-association Json File
• APP將apple-app-association註冊給系統
• 由任意webview發起跳轉的url，若是命中了apple-app-association註冊過的通用連接
• 打開App，觸發Universal Link delegate
• 沒命中，webview繼續跳轉url

在你進行apple-app-association 以及 App工程的配置以後，整個Universal Link的運做流程徹底由系統控制了

坑

1. 域名問題Universal Link 支持的域名最多隻能支持到二級域名，若是你用到了三級域名，Universal Link 喚端是不會生效的。
2. 跨域問題IOS 9.2 之後，必需要觸發跨域才能支持 Universal Link 喚端。IOS 那邊有這樣一個判斷，若是你要打開的 Universal Link 和 當前頁面是同一域名，ios 尊重用戶最可能的意圖，直接打開連接所對應的頁面。若是不在同一域名下，則在你的 APP 中打開連接，也就是執行具體的喚端操做。
3. Universal Link 是空頁面Universal Link 本質上是個空頁面，若是未安裝 APP，Universal Link 被當作普通的頁面連接，天然會跳到 404 頁面，因此咱們須要將它綁定到咱們的中轉頁或者下載頁。

區別

1. iOS 9.0是一個區分點,由於Universal Links在這以後才支持
2. schema能夠喚醒多個不一樣的APP,由於應用都是自定義的,可是Universal Links使用標準的https連接到本身的域名,因此每一個APP的Universal Links都是惟一的
3. schema 會彈窗詢問, Universal Links省去這一步
4. schema會被應用攔截,Universal Links目前能夠突破攔截

應用寶

跳轉到應用寶後會自動根據設備是否已裝APP去執行打開或者下載操做,固然APP得是上傳到應用寶才行,並且只能是騰訊系的APP才支持,若是是其餘的應用依然是隻能走瀏覽器引導