分享迴流調起實戰

分享閉環的意義

看了最近熱播電視劇《創業時代》，感覺了一波創業的波折、守業的艱辛。對於初創產品需求主要是：1）品牌感知，2）引導下載APP體驗，追求更多的是下載量。對於已經基本成型的產品來說須要，關注更多的是，手機生態中所提供服務使用的連貫性，追求更多的則是DAU/MAU。

從最近AppStore中APP更新頻率來看，明顯能夠感覺到如今市場對APP的重視程度。然而當下APP之間競爭激烈，好不容易吸引過來的用戶不想輕易被別的APP搶走，但又想夾縫中求生存費勁形式想從別人家的APP中導流來本身APP，在這樣的矛盾和糟糕環境中，分享和分享迴流一直倍受老闆和業界關注。

分享邏輯閉環能夠拆解來看一下，如圖：

APP_A 通常指的是非社交平臺APP，APP_B通常是帶有社交屬性的APP，能夠簡單理解爲：XXAPP跟微信的關係。現階段微信一家獨大，微信作了鏈接一切的事情，被公認爲是傳播最有效的渠道。各家也是想法設法充分利用好這個平臺。

上圖中兩個虛線框，按照需求關係『分享功能』是有較穩定的解決方案(NA有分享SDK或配置，H5能夠藉助NA進行功能實現)，不在本文討論範圍。『迴流功能』則是須要集成大前端（FE\Android\Ios）全部力量進行攻破的課題。

Native現狀梳理

調起APP方案梳理

場景	調起原理	外部調用方式	下載	參數攜帶
Android瀏覽器	<data android:scheme="myscheme://" />	1. location.href="myscheme://xxx" 2. <iframe src='myscheme://xxx'>	1. location.href="myhost://xxx.apk" 2. location.href="應用市場（下表）"	URL攔截
IOS瀏覽器	Universal Links （IOS9+） 1. 建立apple-app-site-association 2. Xcode的capabilities配置域名信息 3. AppDelegate.m 中支持	1. 訪問配置的域名(a.com) 2. 跨域訪問（b.com 跳轉 a.com）	location.href="itunes.apple.com/tw/app/id12…"	URL解析：userActivity.activityType.webpageURL
IOS瀏覽器	Scheme：- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url	location.href="myscheme://xxx"	同上	URL攔截
微信	白名單機制 1. 白名單內的支持調起 2.其餘若是在應用寶發佈，能夠經過應用寶間接調起	location.href="a.app.qq.com/o/simple.js…"	攜帶給應用寶，交給他們處理	location.href="a.app.qq.com/o/simple.js…"

Android 各大應用市場Scheme

平臺	sheme	正則
小米	mimarket://details?id=xxx&back=true	/\(.Android.(MI|Mi|Redmi|HM NOTE| 201\d{4} Build).*)|Android.*XiaoMi/
sumsung	samsungapps://ProductDetail/xxxx	/\(.Android.(SAMSUNG|SM-|GT-).*)/
華爲	appmarket://details?id=xxxx	/\(.Android.(HUAWEI|HONOR|HW-
oppo	oppomarket://details?packagename=xxxx	/Android.*(OPPO|A31.? Build|R\d+(Plus)? Build)|Android.*OppoBrowser|^OPPO/
vivo	vivomarket://details?id=xxxx	/\(.Android.(vivo|VIVO).*)/

調起流程設計

說明：設計方案是按照兩個域名的方案設計。A.COM 和 Universal Link(Ulink) 分別是兩個不一樣域名

調起實戰

機緣本次項目調起功能的實現，從源頭深刻了解並實現了調起功能，實戰過程當中的幾個點總結起來跟你們一塊兒分享。

微信攔截調起咋回事

2018年初，微信幹了一件蛋疼的事情，Universal link進行白名單機制。以前限制了scheme開發者不得不轉向Ulink方案，可是這樣一來徹底把微信內調起封死。若是想調起，須要進入其白名單，具體方法不得而知。

白名單Android同窗反編譯分析出來的，具體怎麼作的若有微信同窗，歡迎出來批評指正，願聽其詳。

微信限制後有三個方案：

• 右上角三個點，瀏覽器打開；
• 跳轉應用寶，鏈接scheme；
• IOS直接跳轉Appstore打開，但沒法攜帶參數。

域名須要幾個

域名是一個可選項。

無域名方案

也就是所謂的scheme方案，安卓&IOS均可以經過scheme方案來實現。

想到一個問題：若是定義本身APP的schema爲一個別人APP的sheme（如wx://）它會調起誰？實戰發現，會調起後安裝的APP。如此使用scheme，想必會產生一系列問題。也許這是IOS使用ulink的考慮出發點。

爲了避免必要的衝突scheme命名仍是要多考慮一層的。

單域名方案（A.com）

直接打開頁面沒法跳轉對應的Ulink（由於iOS 9.2以後規定，Ulink必須跨域訪問才能生效）。但實踐證實當單域的時候，分享到微信，再次選擇用瀏覽器打開，若是已經安裝APP，會自動調起。這是比較完美的用戶體驗。

從別的頁面跳轉到當前單域名下，理論上由於IOS9+的Universal Link使得調起的用戶體驗更加流暢，因此理論上有一個域名，IOS配置沒問題就能夠調起。實戰過程當中遇到兩個蛋疼的問題：

• 有些用戶會長按複製URL在瀏覽器直接打開沒法調起，沒法調起；
• 若是剛好安裝了APP，合做方頁面（B.com）跳轉到頁面（A.com）不會看到頁面直接調起，合做方通常對這種行爲很是反感，由於直接跳離了他們APP。

多域名方案（A1.com & A2.com）

爲了解決單域名的兩個痛點，降級體驗。A2.com做爲Ulink的配置，先進入A1.com的頁面，多一步點擊操做，而後跳轉A2.com頁面進行後面邏輯操做。

調起是怎麼請求的

iframe or location

H5調起NA的第一種模式是scheme。

不論iframe仍是location，其實本質都是要發出一個scheme請求，APP能夠監聽到提早約定好的協議，進而啓動APP。若是沒安裝APP，也指望不會對用戶體驗形成傷害。

iframe的特色是頁面不會跳轉，當前訪問頁面無感知（具體實現以下），不過遺憾的是IOS9以後就不支持了。

let last;
 
let invoke = function(scheme) {
    last = +Date.now();
    let $node = document.createElement('iframe');
    $node.style.display = 'none';
    $node.src = scheme ;
    let body = document.body || document.getElementsByTagName('body')[0];
    body.appendChild($node);
    setTimeout(function() {
        body.removeChild($node);
        $node = null;
    }, 10);
};
 
 
invoke(scheme);
setTimeout(function() {
  // 防爆點
  if (Date.now() - last < 1600) {
    location.href = unifiedDownloadURL;
  }
}, 1500);

複製代碼

location的特色是history可能會發生變化，同時些特殊APP的webview發現未知協議還會跳轉到一個錯誤頁面，不過IOS若是scheme的話只能這麼搞了。

因此個人結論：Android iframe & IOS src

前端跳轉 or 服務端跳轉

H5調起NA的另外一種模式是Universal Link。

在啓動服務端方案以前，設計了一版純前端的方案。A2.com配置Ulink ，A1.com-A2.com的過程當中如圖，1）須要一箇中間頁承載，2）須要手動出發跳轉下載或者定時促發，這不是用戶指望看到的。

爲了減小用戶感知，將A2.com對應的中間頁跟下載頁URL打包，訪問A1.com後，點擊跳轉A2服務端提供接口，直接302跳轉對應下載ULR（固然也能夠Nginx配置轉發，但爲了可維護性，建議寫到業務中）

中間頁的意義

經過上述服務端跳轉來說，也許中間頁是沒有存在乎義的。要麼調起，要麼跳轉下載，徹底不需一箇中間頁。仔細想一下仍是有兩個弊端的：

• 調用複雜。抽離調起方法，但若是但業務多地方，or多業務多產品線引用的時候，就顯得有點冗餘。這時候若是有一箇中間頁，調用方只須要跳轉過來便可
• 缺乏品牌宣傳。如業務初期，無外部落地頁，好比一個海報加一個二維碼想調起，這個時候若是沒安裝APP的時候，也沒有品牌宣傳直接引導到APPstore或者直接下載，略顯強硬。這就要根據業務具體狀況來看中間頁存在的意義。

調起的極致化體驗

二次分享

在微信中有如圖的幾種分享狀態，第一個是APP分享後的，後面兩個是對分享的再次分享的不一樣狀態。這須要進行一些微信的配置，才能達到2圖的效果。後面有機會可詳細分享。

監聽來源，引導迴流

最近發現一些APP，從A應用跳轉到B應用，B應用裏會提示返回A應用的提示。跳轉原理是一致的都是監聽別人調起而後，調起別人，理論上都是scheme的具體應用。

判斷APP是否安裝

有些應用爲了考慮更多的兼容性，選用上面提到的中間頁方案。這個時候是當即打開？仍是當即下載？若是知道應用在手機裏安裝的狀態，對於用戶體驗來說應該是較爲重大的提高。惋惜系統沒有提供這樣的接口，H5跟NA都沒法準確獲取。不過能夠開動腦筋，利用服務端，經過對APP打開狀況對設備號、登陸狀態、設備標識、IP等信息記錄，打開下載頁的時候，準確提示用戶是下載仍是打開。後面有機會的話常識去作一下。

總結

本人最近參與作了一個創新型APP，關於調起這塊進行了全方位的瞭解。

關於技術選擇：初期選擇：IOS單域名、Android Scheme調起，服務端302分發下載鏈接，在分享出來的落地頁上突出品牌宣傳，完成調起功能。後期產品作大了，引入中間頁通用方案，提供更加通用解決方案。

關於用戶體驗：這個社會爲了利益，無奈讓開發者夾縫中生存找解決方案。這無異於早些年JS的 升級過程，須要顛覆性產品不斷涌現，好比騰訊、百度提出的小程序生態。這是一個須要時間的過程...持續關注。

參考文檔

• 【Android】Scheme詳解
• iOS9 Universal Links
• Universal Link 前端部署採坑記

歡迎留言溝通交流。若有須要轉載或者引用，辛苦標註一下，互相幫助。