整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
言：
文章會(huì)適當(dāng)說一些如何開發(fā)iOS上的universal link，但類似的文章太多了一艘一大堆，每篇都介紹的挺清楚，因此也不是重點(diǎn)
本文更加會(huì)側(cè)重從前端的角度，將整個(gè)universal link 部署應(yīng)用到wap app中的一些策略和一些問題解決辦法
其實(shí)整個(gè)Universal Link沒啥難的，真正上線過Universal link的人這些應(yīng)該都趟過一遍了，本文主要是我們team去應(yīng)用Universal link的時(shí)候一些文檔沉淀和記錄
Schema VS Universal Link
Deeplink相關(guān)的技術(shù)，在wap中喚起app其實(shí)應(yīng)用最最廣泛的并不是Universal Link，而是直接Schema跳轉(zhuǎn)
location.href?=?'schema://xxxx'
并且一般各大APP都會(huì)給自己做一套路由體系，這樣其實(shí)可以直接在schema頭后面對(duì)接路由體系，做到一行schema定位打開任意App內(nèi)功能界面（我就不詳細(xì)扯路由的事了）
-?(BOOL)application:(UIApplication?*)application?openURL:(NSURL?*)url?sourceApplication:(NSString?*)sourceApplication?annotation:(id)annotation?{
????if?([[url?absoluteString]?hasPrefix:@"schema://"])?{
????????[[WKDispatcher?sharedInstance]?operationObjectFromRouteURL:[url?absoluteString]];//路由
????????return?YES;
????}
}如果單純?yōu)榱藢?shí)現(xiàn)deeplink -- 在WAP上打開App，并且傳遞來數(shù)據(jù)信息，定位App內(nèi)的具體邏輯，那么Schema就夠了，其實(shí)沒必要上Universal Link，Schema相當(dāng)于是很特殊的Url，他是schema://xxx這種樣子，如果安裝了APP才能支撐跳轉(zhuǎn)這種Schema Url，如果沒安裝APP就沒任何效果，而Universal Link則是把普通url，長http://xxx.xxx.xxx/xxx這樣的Normal Url，如果安裝了App，就能像Schema一樣傳遞給App，延續(xù)App內(nèi)邏輯，如果沒裝App，則還會(huì)繼續(xù)在瀏覽器里跳轉(zhuǎn)這個(gè)Normal Url
Schema的弊端
Schema無法判斷是否安裝App
一定會(huì)有這樣的產(chǎn)品需求的：
如果已經(jīng)安裝App，則打開App
如果沒有安裝App，則前往下載App
瀏覽器實(shí)際上是沒有能力判斷手機(jī)里是否安裝了某個(gè)App的，所以聰明的程序員們選擇了討巧的方法
try?{
????var?appSchema?=?'schema://xxxx';
????if?($.os.ios)?{
????????location.href?=?openNALocation;?//location.href?打開schema
????}
????else?{
????????$('body').append('');?//iFrame?打開?schema
????}?
}catch?(e)?{}
//延遲1000秒
setTimeout(function?()?{
????if?($.os.ios)?{
????????location.href?=?`https://itunes.apple.com/us/app/idxxxxxxx?mt=8`;
????}
????else?{
????????location.href?=?`https://xxx.xxx.xxx/xxx/xxx.apk`;//直接apk下載link
????}?
}，1000）首先發(fā)起跳轉(zhuǎn)Schema
如果沒安裝App，會(huì)打開App失敗，沒效果
如果安裝App，會(huì)成功打開App
延遲1000ms
如果沒安裝App，Schema打開失敗，等1000秒后會(huì)自動(dòng)跳轉(zhuǎn)
如果安裝App，App會(huì)打開，當(dāng)前網(wǎng)頁會(huì)被暫停，這延遲代碼不會(huì)執(zhí)行
聰明的人會(huì)發(fā)現(xiàn)，這樣有個(gè)風(fēng)險(xiǎn)，如果用戶打開APP成功后，又手動(dòng)切回瀏覽器，那么延遲1000ms的代碼依然會(huì)執(zhí)行，安卓會(huì)跳出下載apk包得提示，iOS會(huì)又再度跳到Appstore，但這個(gè)瑕疵也不是太大的問題，所以這種做法被普遍采用，運(yùn)用在各種安裝就跳轉(zhuǎn)，不安裝就下載的用戶場景。
安卓這么用挺好，iOS有個(gè)討厭的彈框
如果用戶沒有安裝App，那么他一定會(huì)經(jīng)歷2個(gè)事情
schema打開app，但是失敗
延遲后，跳轉(zhuǎn)下載App
在第一個(gè)環(huán)節(jié)，安卓上schema打開失敗，沒有任何反映，也沒有任何提示，一切順利，但是iOS就不同了。
schema會(huì)彈個(gè)可惡的跳轉(zhuǎn)失敗的框
1504334347900
然后再延遲后彈跳轉(zhuǎn)AppStore的框
1504334376521
Schema被很多App禁止，比如微信手百
Schema被廣泛使用，從瀏覽器中喚起打開專門的App，但這并不被很多App認(rèn)可，比如微信，手機(jī)百度，他們本身除了瀏覽網(wǎng)頁以外有其他的使用場景，所以站在微信/手百的角度，并不希望用戶為了看一些分享和內(nèi)容就跳出微信/手百的App，于是這些客戶端攔截了Schema，使得所有Schema都無法生效。
于是不得已，廣大開發(fā)者只好針對(duì)，微信/手百，等特殊UA信息，展現(xiàn)出蒙層，引導(dǎo)用戶用系統(tǒng)/外部瀏覽器打開
Universal Link 解決 Schema的弊端
開篇就說了，如果你單純?yōu)榱四茏寃ap打開App，Schema就能做到了，Universal Link的意義則是把普通url，也賦予了能打開App的能力，而不必編寫專門的Schema Url去喚起App
Schema 的2個(gè)弊端確實(shí)能通過Universal Link解決
不同于Schema，在沒裝App的時(shí)候，Universal Link他也是一個(gè)合法的url鏈接，瀏覽器可以正常跳轉(zhuǎn)，因此不會(huì)出現(xiàn)在iOS上討人厭的框
Universal Link目前還沒有基于iOS的UI/WKWebView的應(yīng)用進(jìn)行攔截，所以目前看還是能突破微信/手百的封鎖。（以后，不好說啊~）
Universal Link 開發(fā)
類似的話題，隨便搜搜Universal Link能搜到一大堆，我這里就略微多啰嗦兩句，一般各大教程里會(huì)反復(fù)說的，我盡量一帶而過，多說點(diǎn)我遇到的坑
配置apple-app-association
究竟哪些的url會(huì)被識(shí)別為Universal Link，全看這個(gè)apple-app-association文件
Apple Document UniversalLinks.html
你的域名必須支持Https
域名根目錄下放這個(gè)文件apple-app-association，不帶任何后綴
文件為json保存為文本即可
json按著官網(wǎng)要求填寫即可
怎么寫json其實(shí)沒啥可教的，滿世界的文章都教你咋寫了，我們看個(gè)例子，點(diǎn)下面的鏈接，你的瀏覽器就會(huì)自動(dòng)把知乎的apple-app-association的json file給down下來
知乎的 apple-app-association 文件
劃重點(diǎn)
有心人可能看到，知乎的Universal Link配置的是 oia.zhihu.com 這個(gè)域名，并且對(duì)這個(gè)域名下比如/answers /questions /people 等urlpath進(jìn)行了識(shí)別，也就是說，知乎的universal link，只有當(dāng)你訪問 https://oia.zhihu.com/questions/xxxx，在移動(dòng)端會(huì)觸發(fā)Universal Link，而知乎正經(jīng)的Urlhttps//www.zhihu.com/questions/xxx是不會(huì)觸發(fā)Universal Link的，知乎為什么制作，為什么不把他的主域名配置Universal Link，這是由于Universal Link的一個(gè)大坑所致
PS.
apple-app-association 你可以看完全了知乎的json file，會(huì)發(fā)現(xiàn)里面也不止是 universal link
蘋果的一些其他功能都和apple-app-association有關(guān)，都需要配置這個(gè)文件，增加更多json字段信息
比如Hand off 還有一些跨Web&App的分享
測(cè)試是否正確
蘋果官方提供了一個(gè)網(wǎng)站來測(cè)試你配置的域名apple-app-association是否正常work
https://search.developer.apple.com/appsearch-validation-tool/
這個(gè)網(wǎng)站有點(diǎn)SB，就是你用他測(cè)試不通過，其實(shí)Universal Link也可能不生效的，比如我把知乎的oia.zhihu.com輸入進(jìn)去，他就沒感應(yīng)到，認(rèn)為沒有。我搜索的時(shí)候，發(fā)現(xiàn)也有人發(fā)現(xiàn)了這個(gè)問題，反正可以當(dāng)個(gè)參考
配置iOS App工程
開發(fā)者中心證書打開Associated Domains
工程配置Associated Domains
將你apple-app-association所在域名配置進(jìn)去
給你的工程像Schema的OpenUrl一樣，編寫App被喚醒后的處理邏輯
#pragma?mark?Universal?Links
-?(BOOL)application:(UIApplication?*)application?continueUserActivity:(NSUserActivity?*)userActivity?restorationHandler:(void?(^)(NSArray?*?_Nullable))restorationHandler?{
????if?([userActivity.activityType?isEqualToString:NSUserActivityTypeBrowsingWeb])?{
????????NSURL?*webUrl?=?userActivity.webpageURL;
????????[self?handleUniversalLink:webUrl];?//?轉(zhuǎn)化為App路由
????}
????return?YES;
}恩比較千篇一律，我不多說了
Universal Link的基本運(yùn)作流程
APP第一次啟動(dòng) or APP更新版本后第一次啟動(dòng)
APP向工程里配置的域名發(fā)起Get請(qǐng)求拉取apple-app-association Json File
APP將apple-app-association注冊(cè)給系統(tǒng)
由任意webview發(fā)起跳轉(zhuǎn)的url，如果命中了apple-app-association注冊(cè)過的通用鏈接
打開App，觸發(fā)Universal Link delegate
沒命中，webview繼續(xù)跳轉(zhuǎn)url
在你進(jìn)行apple-app-association 以及 App工程的配置之后，整個(gè)Universal Link的運(yùn)作流程完全由系統(tǒng)控制了
Universal Link 采坑
整個(gè)Universal Link其實(shí)真要只是開發(fā)完成，完全寫不了幾行代碼，就差不多搞定了，不過還真是踩了幾個(gè)坑
跨域
前端開發(fā)經(jīng)常面臨跨域問題，恩Universal Link也有跨域問題，但不一樣的是，Universal Link，必須要求跨域，如果不跨域，就不行，就失效，就不工作。（iOS 9.2之后的改動(dòng)，蘋果就這么規(guī)定這么設(shè)計(jì)的）
這也是上面拿知乎舉例子的時(shí)候重點(diǎn)強(qiáng)調(diào)的一個(gè)問題，知乎為什么使用oia.zhihu.com做Universal Link？
假如當(dāng)前網(wǎng)頁的域名是 A
當(dāng)前網(wǎng)頁發(fā)起跳轉(zhuǎn)的域名是 B
必須要求 B 和 A 是不同域名，才會(huì)觸發(fā)Universal Link
如果B 和 A 是相同域名，只會(huì)繼續(xù)在當(dāng)前WebView里面進(jìn)行跳轉(zhuǎn)，哪怕你的Universal Link一切正常，根本不會(huì)打開App
是不是不太好理解，那直接拿知乎舉例子
https://www.zhihu.com/question/22914651
知乎的一般網(wǎng)頁URL都是www.zhihu.com域名，你在微信朋友圈看到了知乎的問題分享，如果copy url 你就能看到這樣的鏈接
微信里其實(shí)是屏蔽Schema的，但是你依然能看到大大的一個(gè)按鈕App內(nèi)打開，這確實(shí)就是通過Universal Link來實(shí)現(xiàn)的，但如果知乎把Universal Link 配在了www.zhihu.com域名，那么即便已經(jīng)安裝了App，Universal Link也是不會(huì)生效的。
一般的公司都會(huì)有自己的主域名，比如知乎的www.zhihu.com，在各處分享傳播的時(shí)候，也都是直接分享基于主域名的url，但為了解決蘋果強(qiáng)制要求跨域才生效的問題，Universal Link就不能配置在主域名下，于是知乎才會(huì)準(zhǔn)備一個(gè)oia.zhihu.com域名，專為Universal Link使用，不會(huì)跟任何主動(dòng)傳播分享的域名撞車，從而在任何活動(dòng)WAP頁面里，都能順利讓Universal Link生效。
簡單一句話
只有當(dāng)前webview的url域名，與跳轉(zhuǎn)目標(biāo)url域名不一致時(shí)，Universal Link 才生效
apple-app-association 覆蓋
我們業(yè)務(wù)機(jī)房的集群是大部門下幾條業(yè)務(wù)線共用的，有一整套云服務(wù)系統(tǒng)來進(jìn)行機(jī)房集群的管理，有統(tǒng)一的接入層進(jìn)行分發(fā)。雖然是不同的產(chǎn)品線，不同的服務(wù)，但是共享分布式的機(jī)房進(jìn)行運(yùn)作的。
很多Universal Link的教學(xué)文章是這么寫的
將json命名為 apple-app-association 不要亂改名
將file 上傳到域名所在的服務(wù)器根目錄下
于是我就將我們文庫的apple-app-association，上傳到我準(zhǔn)備的wenkuUniversal域名的所在機(jī)器的根目錄下。（因?yàn)闄C(jī)房都是分布式的，所以其實(shí)就是upload的全部門下的很多機(jī)器上）
同部門另一個(gè)產(chǎn)品線閱讀后來也開始嘗試Universal Link，也要把他們寫好的apple-app-association上傳到他們的yueduUniversal域名所在的機(jī)器的根目錄下。
因?yàn)槎际峭瑯拥奈募忠驗(yàn)檎麄€(gè)事業(yè)部機(jī)器實(shí)際上是共用的，因此就發(fā)生了覆蓋。
解決辦法
共用同一個(gè) apple-app-association
因?yàn)閍pple-app-association的具體內(nèi)容里有App 的Bundle ID在，因此可以簡單的把2個(gè)json file 進(jìn)行merge，你的App bundle 生效你的link，我的App bundle生效我的link
但其實(shí)并不推薦，畢竟雙方都要小心在更新的時(shí)候，不能覆蓋對(duì)方，并且這樣做也很不合理，apple-app-association也不止為universal link 一個(gè)feature工作，當(dāng)面臨跨app / web share 甚至hand off的時(shí)候，共用一個(gè)json file 還是有坑
接入層分發(fā)不同json file
2個(gè)產(chǎn)品線的link域名其實(shí)是不一樣的，只不過恰巧這兩個(gè)域名最重打到得機(jī)器是同一個(gè)或者說有重疊，因此產(chǎn)生了覆蓋，完全可以將json文件保存成各自的名字，在接入層對(duì)域名進(jìn)行分發(fā)
最終App也是通過Get請(qǐng)求去拉取apple-app-association的，只要Get到，并且ssl安全性上符合要求（強(qiáng)制https）就沒問題
隱藏的坑：apple-app-association被覆蓋后如何更新
我們線上已經(jīng)work的Universal Link功能，突然有一天發(fā)現(xiàn)壞了，查了一圈最后查到被閱讀覆蓋了，那就修復(fù)唄，修復(fù)倒是沒問題，問題在于修復(fù)后的universal link，用戶必須重新安裝一次app，才能重新work，這個(gè)太坑了啊
所以關(guān)鍵是需要掌握apple-app-association的更新時(shí)機(jī)，反復(fù)重新殺APP重開完全沒用，刪了APP重裝確實(shí)有用，但不可能讓用戶這么去做
https://stackoverflow.com/questions/35187576/does-the-apple-app-site-association-json-file-ever-get-updated-in-app
這里解釋了，每次App安裝后的第一次Launch，會(huì)拉取apple-app-association，除此之外在Appstore每次App的版本更新后的第一次Launch，也會(huì)拉取apple-app-association。
也就是說，一旦不小心因?yàn)橐馔鈇pple-app-association，想要挽回又讓那部分用戶無感，App再發(fā)一個(gè)版本就好了
Universal Link 會(huì)因?yàn)橛脩粜袨槎?/strong>
Universal Link 觸發(fā)后打開App，這時(shí)候App的狀態(tài)欄右上角會(huì)有文字提示來自XXApp，可以點(diǎn)狀態(tài)欄的文字快速返回原來的AP
如果用戶點(diǎn)了返回微信，就會(huì)被蘋果記住，認(rèn)為用戶并不需要跳出原App打開新App，因此這個(gè)App的Universal Link會(huì)被關(guān)閉，再也無效。
想要開啟也不是不行，讓用戶重新用safari打開，universal link的頁面，然后會(huì)出現(xiàn)很像蘋果smart bar的東西，那個(gè)東西點(diǎn)了后就能打開（我是看到的，我沒親自操作過）
Universal Link 業(yè)務(wù)部署
知乎的apple-app-association可以看到里面有一大堆的WAP的URL，比如/answers /questions /people等，知乎都將它一一映射到App得對(duì)應(yīng)界面里，問題/回答/人詳情頁。這是因?yàn)橹醯腤AP站和APP的功能幾乎是一致的。因此知乎的Universal Link的使用方式，可以說是很經(jīng)典的遵循著蘋果的原始設(shè)計(jì)初衷通用鏈接，將wap url，變成通用url，同樣的url，對(duì)應(yīng)著2個(gè)跳轉(zhuǎn)，web跳轉(zhuǎn)/app跳轉(zhuǎn)，但是他們是同一個(gè)功能。
我們產(chǎn)品線面臨的情況不一樣，我們的產(chǎn)品線文庫，他的WAP和APP功能差異非常大，可以說除了文檔閱讀頁/view，WAP與APP都有這個(gè)功能，其他的功能WAP是WAP的，APP是APP的，形態(tài)和場景都有明顯差異。除了/view這個(gè)功能，我們可以按著通用鏈接的設(shè)計(jì)，將APP閱讀頁跳轉(zhuǎn)，與WAP閱讀頁跳轉(zhuǎn)進(jìn)行統(tǒng)一。其他時(shí)候Universal Link對(duì)于我們業(yè)務(wù)來說就是一個(gè)更強(qiáng)大的Schema（突破舊Schema局限的=），他只需要跳轉(zhuǎn)到APP，他沒有合法的WAP Url可以讓瀏覽器在沒有安裝App的情況下繼續(xù)跳轉(zhuǎn)。
我們的Universal Link 業(yè)務(wù)部署
我們的Universal Link就像知乎一樣，沒有選擇我們的主域名，而是選了一個(gè)完全沒在WAP上有任何頁面和流量的域名，我們的apple-app-association是這么寫的
{
????"appID":?"xxxxxx.xxx.xxx.xxxxx",
????"paths":[?"/view/*",
??????????????"/_iosuniversallink/*"]
},我們的AppDelegate中具體handleUniversalLink的邏輯是這么寫的
-?(BOOL)handleUniversalLink:(NSURL?*)url?{
????NSURLComponents?*components?=?[NSURLComponents?componentsWithURL:url?resolvingAgainstBaseURL:YES];
????NSString?*host?=?components.host;
????if?([host?isEqualToString:@"xxx.xxx.xxx"])?{?//host判斷，雖然沒啥意義
????????if?(pathComponents.count?>=?3)?{
????????????//地址匹配+頁面跳轉(zhuǎn)
????????????NSString?*router;
????????????if?([pathComponents[1]?isEqualToString:@"view"])?{
????????????????router?=?@"xxx";//生成打開APP閱讀頁的專屬Router
????????????}?else?if?([pathComponents[1]?isEqualToString:@"_iosuniversallink"])?{
????????????????router?=?@"xxx";//解析出APP能識(shí)別的任意路由，
????????????}
????????????if?(router?&&?router.length?>?0)?{
????????????????[[WKDispatcher?sharedInstance]?operationObjectFromRouteURL:router];//無論是閱讀頁路由還是任意路由，發(fā)起跳轉(zhuǎn)
????????????}
????????????return?YES;
????????}
????}
????return?NO;
}可以看出來我只打開了這個(gè)域名下https://xxx.xxx.xxx/view/* 和 https://xxx.xxx.xxx/_iosuniversallink/*2個(gè)Universal Link Path.對(duì)沒錯(cuò)，不像知乎那么多。
/view/* 后面的*直接是閱讀頁ID，用于快速生成閱讀頁路由，發(fā)起跳轉(zhuǎn)
/_iosuniversallink/* 后面的*其實(shí)應(yīng)該填寫的是我們App已經(jīng)設(shè)計(jì)好的路由字符串，識(shí)別出路由字符串后，發(fā)起跳轉(zhuǎn)
其實(shí)可以看出來/_iosuniversallink是完全包含/view的，因?yàn)锳PP閱讀頁天然也是包含在我們的路由規(guī)則內(nèi)的，只要這里有路由策略，擴(kuò)展力已經(jīng)足夠支持任意APP頁面了，因此apple-app-association只配置了2個(gè)，但是如果有計(jì)劃外的特殊case，大不了更新一下，也沒多大事。
為了統(tǒng)一WAP&APP，為了通用鏈接的效果
我剛才提到，我們選擇的Universal Link的域名其實(shí)是一個(gè)沒有實(shí)際頁面的域名，也就是說https://xxx.xxx.xxx/view/*這個(gè)url，如果沒安裝APP因此觸發(fā)WebView繼續(xù)跳轉(zhuǎn)原地址，會(huì)直接404。處理很簡單，重定向一下
router.use('/view',?function?(req,?res,?next)?{
????var?path?=?req.path;
????res.redirect('https://wk.baidu.com/view'?+?path?+?'?st=1#1');
});整個(gè)效果就是
跳轉(zhuǎn)https://xxx.xxx.xxx/view/*
已安裝App
打開App 觸發(fā)handleUniversalLink
走到/view/分支，拼接閱讀頁路由
跳轉(zhuǎn)
未安裝App
WebView原地跳轉(zhuǎn)https://xxx.xxx.xxx/view/*
命中服務(wù)器的重定向邏輯
重定向到https://wk.baidu.com/view/*
打開我們的WAP閱讀頁
這就是為啥明明/_iosuniversallink是完全包含/view能力的，但還是要把/view/單獨(dú)處理的原因，為的是實(shí)現(xiàn)WAP與APP的統(tǒng)一設(shè)計(jì)，為了通用鏈接這個(gè)初衷
不為了統(tǒng)一WAP&APP 只拿來當(dāng)強(qiáng)化版Schema使用
同樣的道理，https://xxx.xxx.xxx/_iosuniversallink/*這個(gè)url，也沒有實(shí)際的頁面，如果不進(jìn)行重定向，也會(huì)直接返回404，因此看一眼重定向的代碼
????router.use('/_iosuniversallink',?function?(req,?res,?next)?{
????????var?redirecturl?=?'https://wk.baidu.com/topic/naiosappstore';
????????res.redirect(redirecturl);
????});解釋一下https://wk.baidu.com/topic/naiosappstore就是我們?yōu)閕OS下載App準(zhǔn)備的專門的WAP單頁面，這個(gè)頁面打開后會(huì)自動(dòng)延遲500ms，發(fā)起跳轉(zhuǎn)appstore
整個(gè)效果就是
跳轉(zhuǎn)https://xxx.xxx.xxx/_iosuniversallink/*
已安裝App
打開App 觸發(fā)handleUniversalLink
走到/_iosuniversallink/分支，拼接出任意App內(nèi)的界面路由
跳轉(zhuǎn)界面
未安裝App
WebView原地跳轉(zhuǎn)https://xxx.xxx.xxx/_iosuniversallink/*
命中服務(wù)器的重定向邏輯
重定向到https://wk.baidu.com/topic/naiosappstore
naiosappstore頁面會(huì)延遲跳轉(zhuǎn)AppStore
打開AppStore下載
這個(gè)設(shè)計(jì)看起來就是完美解決了PM得需求
如果已安裝App，跳轉(zhuǎn)對(duì)應(yīng)界面
如果沒安裝App，跳轉(zhuǎn)App下載界面
解決了舊Schema模式下的弊端問題：
Schema無法判斷是否安裝App，只能采用setTimeout的Trick方式
Schema的Trick方式會(huì)有一個(gè)丑陋的錯(cuò)誤跳轉(zhuǎn)彈框
Schema無法在微信/手百等App內(nèi)，打開我們自己的App
簡單的說，這樣設(shè)計(jì)的初衷就是，我不為了通用鏈接這一目的來使用Universal Link，來統(tǒng)一WAP&APP的URL跳轉(zhuǎn)，我就為了把Universal Link當(dāng)做加強(qiáng)版Schema來使用
作者：折騰范兒_味精
鏈接：http://www.jianshu.com/p/55ac5c5c5b59
來源：簡書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
近大家反饋微信登陸失敗,提示語未,“由于應(yīng)用universal link校驗(yàn)不通過，無法完成微信登陸”，特開此貼，解決此問題
具體情況如下圖：
微信開放平臺(tái)移動(dòng)應(yīng)用 SDK 更新提醒
為適配iOS系統(tǒng)版本更新，微信開放平臺(tái)在2019年9月對(duì)移動(dòng)應(yīng)用iOS SDK進(jìn)行了升級(jí)，詳見SDK更新公告。為提升平臺(tái)安全性、避免開發(fā)者的應(yīng)用后續(xù)受到影響，平臺(tái)將于近期開始逐步對(duì)iOS 舊版本 SDK能力（版本號(hào)低于1.8.6.1）進(jìn)行階梯式調(diào)整，具體計(jì)劃如下：
關(guān)于openSDK1.8.6的更新說明
配置應(yīng)用的Universal Links
1）根據(jù) 蘋果文檔 配置你應(yīng)用的Universal Links
微信對(duì)Universal Links配置要求
a）Universal Links必須支持https
b）Universal Links配置的paths不能帶query參數(shù)
c）微信使用Universal Links拉起第三方App時(shí)，會(huì)在Universal Links末尾拼接路徑和參數(shù)，因此App配置的paths必須加上通配符/*
示例:
{
"appID": "8P7343TG54.com.tencent.xin.SDKSample",
"paths": ["/sdksample/*"]
}
在Xcode中配置關(guān)聯(lián)域名
打開Associated Domains開關(guān)，將Universal Links域名加到配置上
檢查確認(rèn)App的Universal Links配置成功，通過上述SDK接入成功驗(yàn)證指引操作
配置universal link 對(duì)iOS開發(fā)者來說并不難，但服務(wù)端配置就涉及購買域名，https購買，以及配置apple-app-site-association
我自己用的是【Xinstall】的服務(wù)（之前用過這家的內(nèi)測(cè)服務(wù)）,登陸注冊(cè)以后就可以免費(fèi)使用了。不需要進(jìn)行復(fù)雜的配置操作，直接生成universal link鏈接
自動(dòng)配置
非代碼相關(guān)
{
"applinks": {
"apps": [],
"details": [
{
"appID": "KEAAAAA.com.baidu.syoraoooo",
"paths": ["*"]
}
]
}
}
期中 appID 稍微注意一下
KEAAAAA為蘋果賬號(hào)的團(tuán)隊(duì)ID在蘋果開發(fā)者網(wǎng)站查看
com.baidu.syoraoooo為BundleID
Info.plist里添加 LSApplicationQueriesSchemes weixin weixinULAPI
代碼相關(guān)
@interface AppDelegate ()<WXApiDelegate>
...didFinishLaunchingWithOptions...{
//向微信注冊(cè)
[WXApi registerApp:APP_ID
universalLink:UNIVERSAL_LINK];
}
...
#pragma mark --- 微信相關(guān)
- (BOOL)application:(UIApplication *)application
handleOpenURL:(NSURL *)url {
return [WXApi handleOpenURL:url
delegate:self];
}
- (BOOL)application:(UIApplication *)application
openURL:(NSURL *)url
sourceApplication:(NSString *)sourceApplication
annotation:(id)annotation
{
return [WXApi handleOpenURL:url
delegate:self
];
}
- (BOOL)application:(UIApplication *)application
continueUserActivity:(NSUserActivity *)userActivity
restorationHandler:(void(^)(NSArray<id<UIUserActivityRestoring>> * __nullable restorableObjects))
restorationHandler
{
return [WXApi handleOpenUniversalLink:userActivity
delegate:self];
}
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options
{
if ([url.scheme isEqualToString:APP_ID]) {
return [WXApi handleOpenURL:url delegate:self];
}
return YES;
}
-(void) onResp:(BaseResp*)resp{
if([resp isKindOfClass:[SendAuthResp class]])
{
SendAuthResp *response =
(SendAuthResp *)resp;
switch (response.errCode) {
case WXSuccess:/**< 成功 */
LDLog(@"微信授權(quán)成功");
[[NSNotificationCenter defaultCenter]postNotificationName:WechatAuthorizationSucceededNoti object:@{@"code": response.code}];
break;
case WXErrCodeCommon:/**< 普通錯(cuò)誤類型 */
break;
case WXErrCodeUserCancel:/**< 用戶點(diǎn)擊取消并返回 */
break;
.....
}
}
}
@interface SceneDelegate ()<WXApiDelegate>
- (void)scene:(UIScene *)scene
continueUserActivity:(NSUserActivity *)
userActivity
{
[WXApi handleOpenUniversalLink:
userActivity delegate:self];
}
-(void) onResp:(BaseResp*)resp{
if([resp isKindOfClass:[SendAuthResp class]]) {
SendAuthResp *response =
(SendAuthResp *)resp;
switch (response.errCode) {
case WXSuccess:/**< 成功 */
LDLog(@"微信授權(quán)成功");
[[NSNotificationCenter defaultCenter]
postNotificationName:WechatAuthorizationSucceededNoti
object:@{@"code": response.code}];
break;
case WXErrCodeCommon:/**< 普通錯(cuò)誤類型 */
break;
case WXErrCodeUserCancel:/**< 用戶點(diǎn)擊取消并返回 */
break;
....
}
}
}
apple-app-site-association文件保存的位置 根目錄下。etc.https://test.com/apple-app-site-association
.well-known文件夾下(推薦，蘋果在iOS9.3更改了通用鏈接的請(qǐng)求文件的位置，但是仍然支持上面的路徑)。在根目錄新建.well-known文件夾(不要忘記前面的.)。etc.https://test.com/.well-known/apple-app-site-association
NGINX配置：
location ~ /apple-app-site-association
{
default_type application/json;
alias /home/XXX/utils/apple-app-site-association;
}
我們的運(yùn)維人員一開始 沒有加 default_type 我這邊拿到 https://www.test.com/.well-known/apple-app-site-association 放到瀏覽器中 直接下載下來了這個(gè)文件
同時(shí)我在Xcode里調(diào)用微信的自檢函數(shù) 也是不通過的
//在register之前打開log, 后續(xù)可以根據(jù)log排查問題
[WXApi startLogByLevel:WXLogLevelDetail logBlock:^(NSString *log) {
NSLog(@"WeChatSDK: %@", log);
}];
//務(wù)必在調(diào)用自檢函數(shù)前注冊(cè)
[WXApi registerApp:APP_ID universalLink:UNIVERSAL_LINK];
//調(diào)用自檢函數(shù)
[WXApi checkUniversalLinkReady:^(WXULCheckStep step, WXCheckULStepResult* result) {
NSLog(@"%@, %u, %@, %@", @(step), result.success, result.errorInfo, result.suggestion);
}];
...0, 1, check passed,
...1, 1, check passed,
...2, 1, check passed,
...WeChatSDK: wxlog:set property list
...3, 1, check passed,
...WeChatSDK: wxlog:launch app with ul only success
...4, 1, check passed,
...WeChatSDK: wxlog:Successfully starting WeChat with the universal link.
...PBItemCollectionServicer connection disconnected.
在打開 https://www.test.com/.well-known/apple-app-site-association 就是一個(gè)json數(shù)據(jù)了 同時(shí)微信的自檢函數(shù)全部通過
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
