Universal Link 前端部署采坑記

言：

文章會適當說一些如何開發iOS上的universal link，但類似的文章太多了一艘一大堆，每篇都介紹的挺清楚，因此也不是重點

本文更加會側重從前端的角度，將整個universal link 部署應用到wap app中的一些策略和一些問題解決辦法

其實整個Universal Link沒啥難的，真正上線過Universal link的人這些應該都趟過一遍了，本文主要是我們team去應用Universal link的時候一些文檔沉淀和記錄

Schema VS Universal Link

Deeplink相關的技術，在wap中喚起app其實應用最最廣泛的并不是Universal Link，而是直接Schema跳轉

location.href?=?'schema://xxxx'

并且一般各大APP都會給自己做一套路由體系，這樣其實可以直接在schema頭后面對接路由體系，做到一行schema定位打開任意App內功能界面（我就不詳細扯路由的事了）

-?(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;
????}
}

如果單純為了實現deeplink -- 在WAP上打開App，并且傳遞來數據信息，定位App內的具體邏輯，那么Schema就夠了，其實沒必要上Universal Link，Schema相當于是很特殊的Url，他是schema://xxx這種樣子，如果安裝了APP才能支撐跳轉這種Schema Url，如果沒安裝APP就沒任何效果，而Universal Link則是把普通url，長http://xxx.xxx.xxx/xxx這樣的Normal Url，如果安裝了App，就能像Schema一樣傳遞給App，延續App內邏輯，如果沒裝App，則還會繼續在瀏覽器里跳轉這個Normal Url

Schema的弊端

Schema無法判斷是否安裝App

一定會有這樣的產品需求的：

如果已經安裝App，則打開App
如果沒有安裝App，則前往下載App

瀏覽器實際上是沒有能力判斷手機里是否安裝了某個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）

首先發起跳轉Schema

如果沒安裝App，會打開App失敗，沒效果
如果安裝App，會成功打開App

延遲1000ms

如果沒安裝App，Schema打開失敗，等1000秒后會自動跳轉
如果安裝App，App會打開，當前網頁會被暫停，這延遲代碼不會執行

聰明的人會發現，這樣有個風險，如果用戶打開APP成功后，又手動切回瀏覽器，那么延遲1000ms的代碼依然會執行，安卓會跳出下載apk包得提示，iOS會又再度跳到Appstore，但這個瑕疵也不是太大的問題，所以這種做法被普遍采用，運用在各種安裝就跳轉，不安裝就下載的用戶場景。

安卓這么用挺好，iOS有個討厭的彈框

如果用戶沒有安裝App，那么他一定會經歷2個事情

schema打開app，但是失敗
延遲后，跳轉下載App

在第一個環節，安卓上schema打開失敗，沒有任何反映，也沒有任何提示，一切順利，但是iOS就不同了。

schema會彈個可惡的跳轉失敗的框

1504334347900

然后再延遲后彈跳轉AppStore的框

1504334376521

Schema被很多App禁止，比如微信手百

Schema被廣泛使用，從瀏覽器中喚起打開專門的App，但這并不被很多App認可，比如微信，手機百度，他們本身除了瀏覽網頁以外有其他的使用場景，所以站在微信/手百的角度，并不希望用戶為了看一些分享和內容就跳出微信/手百的App，于是這些客戶端攔截了Schema，使得所有Schema都無法生效。

于是不得已，廣大開發者只好針對，微信/手百，等特殊UA信息，展現出蒙層，引導用戶用系統/外部瀏覽器打開

Universal Link 解決 Schema的弊端

開篇就說了，如果你單純為了能讓wap打開App，Schema就能做到了，Universal Link的意義則是把普通url，也賦予了能打開App的能力，而不必編寫專門的Schema Url去喚起App

Schema 的2個弊端確實能通過Universal Link解決

不同于Schema，在沒裝App的時候，Universal Link他也是一個合法的url鏈接，瀏覽器可以正常跳轉，因此不會出現在iOS上討人厭的框

Universal Link目前還沒有基于iOS的UI/WKWebView的應用進行攔截，所以目前看還是能突破微信/手百的封鎖。（以后，不好說啊~）

Universal Link 開發

類似的話題，隨便搜搜Universal Link能搜到一大堆，我這里就略微多啰嗦兩句，一般各大教程里會反復說的，我盡量一帶而過，多說點我遇到的坑

配置apple-app-association

究竟哪些的url會被識別為Universal Link，全看這個apple-app-association文件

Apple Document UniversalLinks.html

你的域名必須支持Https
域名根目錄下放這個文件apple-app-association，不帶任何后綴
文件為json保存為文本即可
json按著官網要求填寫即可

怎么寫json其實沒啥可教的，滿世界的文章都教你咋寫了，我們看個例子，點下面的鏈接，你的瀏覽器就會自動把知乎的apple-app-association的json file給down下來

知乎的 apple-app-association 文件

劃重點

有心人可能看到，知乎的Universal Link配置的是 oia.zhihu.com 這個域名，并且對這個域名下比如/answers /questions /people 等urlpath進行了識別，也就是說，知乎的universal link，只有當你訪問 https://oia.zhihu.com/questions/xxxx，在移動端會觸發Universal Link，而知乎正經的Urlhttps//www.zhihu.com/questions/xxx是不會觸發Universal Link的，知乎為什么制作，為什么不把他的主域名配置Universal Link，這是由于Universal Link的一個大坑所致

PS.

apple-app-association 你可以看完全了知乎的json file，會發現里面也不止是 universal link

蘋果的一些其他功能都和apple-app-association有關，都需要配置這個文件，增加更多json字段信息

比如Hand off 還有一些跨Web&App的分享

測試是否正確

蘋果官方提供了一個網站來測試你配置的域名apple-app-association是否正常work

https://search.developer.apple.com/appsearch-validation-tool/

這個網站有點SB，就是你用他測試不通過，其實Universal Link也可能不生效的，比如我把知乎的oia.zhihu.com輸入進去，他就沒感應到，認為沒有。我搜索的時候，發現也有人發現了這個問題，反正可以當個參考

配置iOS App工程

開發者中心證書打開Associated Domains
工程配置Associated Domains
將你apple-app-association所在域名配置進去
給你的工程像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];?//?轉化為App路由
????}
????return?YES;
}

恩比較千篇一律，我不多說了

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的運作流程完全由系統控制了

Universal Link 采坑

整個Universal Link其實真要只是開發完成，完全寫不了幾行代碼，就差不多搞定了，不過還真是踩了幾個坑

跨域

前端開發經常面臨跨域問題，恩Universal Link也有跨域問題，但不一樣的是，Universal Link，必須要求跨域，如果不跨域，就不行，就失效，就不工作。（iOS 9.2之后的改動，蘋果就這么規定這么設計的）

這也是上面拿知乎舉例子的時候重點強調的一個問題，知乎為什么使用oia.zhihu.com做Universal Link？

假如當前網頁的域名是 A
當前網頁發起跳轉的域名是 B
必須要求 B 和 A 是不同域名，才會觸發Universal Link
如果B 和 A 是相同域名，只會繼續在當前WebView里面進行跳轉，哪怕你的Universal Link一切正常，根本不會打開App

是不是不太好理解，那直接拿知乎舉例子

https://www.zhihu.com/question/22914651

知乎的一般網頁URL都是www.zhihu.com域名，你在微信朋友圈看到了知乎的問題分享，如果copy url 你就能看到這樣的鏈接

微信里其實是屏蔽Schema的，但是你依然能看到大大的一個按鈕App內打開，這確實就是通過Universal Link來實現的，但如果知乎把Universal Link 配在了www.zhihu.com域名，那么即便已經安裝了App，Universal Link也是不會生效的。

一般的公司都會有自己的主域名，比如知乎的www.zhihu.com，在各處分享傳播的時候，也都是直接分享基于主域名的url，但為了解決蘋果強制要求跨域才生效的問題，Universal Link就不能配置在主域名下，于是知乎才會準備一個oia.zhihu.com域名，專為Universal Link使用，不會跟任何主動傳播分享的域名撞車，從而在任何活動WAP頁面里，都能順利讓Universal Link生效。

簡單一句話

只有當前webview的url域名，與跳轉目標url域名不一致時，Universal Link 才生效

apple-app-association 覆蓋

我們業務機房的集群是大部門下幾條業務線共用的，有一整套云服務系統來進行機房集群的管理，有統一的接入層進行分發。雖然是不同的產品線，不同的服務，但是共享分布式的機房進行運作的。

很多Universal Link的教學文章是這么寫的

將json命名為 apple-app-association 不要亂改名
將file 上傳到域名所在的服務器根目錄下

于是我就將我們文庫的apple-app-association，上傳到我準備的wenkuUniversal域名的所在機器的根目錄下。（因為機房都是分布式的，所以其實就是upload的全部門下的很多機器上）

同部門另一個產品線閱讀后來也開始嘗試Universal Link，也要把他們寫好的apple-app-association上傳到他們的yueduUniversal域名所在的機器的根目錄下。

因為都是同樣的文件名，又因為整個事業部機器實際上是共用的，因此就發生了覆蓋。

解決辦法

共用同一個 apple-app-association

因為apple-app-association的具體內容里有App 的Bundle ID在，因此可以簡單的把2個json file 進行merge，你的App bundle 生效你的link，我的App bundle生效我的link

但其實并不推薦，畢竟雙方都要小心在更新的時候，不能覆蓋對方，并且這樣做也很不合理，apple-app-association也不止為universal link 一個feature工作，當面臨跨app / web share 甚至hand off的時候，共用一個json file 還是有坑

接入層分發不同json file

2個產品線的link域名其實是不一樣的，只不過恰巧這兩個域名最重打到得機器是同一個或者說有重疊，因此產生了覆蓋，完全可以將json文件保存成各自的名字，在接入層對域名進行分發

最終App也是通過Get請求去拉取apple-app-association的，只要Get到，并且ssl安全性上符合要求（強制https）就沒問題

隱藏的坑：apple-app-association被覆蓋后如何更新

我們線上已經work的Universal Link功能，突然有一天發現壞了，查了一圈最后查到被閱讀覆蓋了，那就修復唄，修復倒是沒問題，問題在于修復后的universal link，用戶必須重新安裝一次app，才能重新work，這個太坑了啊

所以關鍵是需要掌握apple-app-association的更新時機，反復重新殺APP重開完全沒用，刪了APP重裝確實有用，但不可能讓用戶這么去做

https://stackoverflow.com/questions/35187576/does-the-apple-app-site-association-json-file-ever-get-updated-in-app

這里解釋了，每次App安裝后的第一次Launch，會拉取apple-app-association，除此之外在Appstore每次App的版本更新后的第一次Launch，也會拉取apple-app-association。

也就是說，一旦不小心因為意外apple-app-association，想要挽回又讓那部分用戶無感，App再發一個版本就好了

Universal Link 會因為用戶行為而失效

Universal Link 觸發后打開App，這時候App的狀態欄右上角會有文字提示來自XXApp，可以點狀態欄的文字快速返回原來的AP

如果用戶點了返回微信，就會被蘋果記住，認為用戶并不需要跳出原App打開新App，因此這個App的Universal Link會被關閉，再也無效。

想要開啟也不是不行，讓用戶重新用safari打開，universal link的頁面，然后會出現很像蘋果smart bar的東西，那個東西點了后就能打開（我是看到的，我沒親自操作過）

Universal Link 業務部署

知乎的apple-app-association可以看到里面有一大堆的WAP的URL，比如/answers /questions /people等，知乎都將它一一映射到App得對應界面里，問題/回答/人詳情頁。這是因為知乎的WAP站和APP的功能幾乎是一致的。因此知乎的Universal Link的使用方式，可以說是很經典的遵循著蘋果的原始設計初衷通用鏈接，將wap url，變成通用url，同樣的url，對應著2個跳轉，web跳轉/app跳轉，但是他們是同一個功能。

我們產品線面臨的情況不一樣，我們的產品線文庫，他的WAP和APP功能差異非常大，可以說除了文檔閱讀頁/view，WAP與APP都有這個功能，其他的功能WAP是WAP的，APP是APP的，形態和場景都有明顯差異。除了/view這個功能，我們可以按著通用鏈接的設計，將APP閱讀頁跳轉，與WAP閱讀頁跳轉進行統一。其他時候Universal Link對于我們業務來說就是一個更強大的Schema（突破舊Schema局限的=），他只需要跳轉到APP，他沒有合法的WAP Url可以讓瀏覽器在沒有安裝App的情況下繼續跳轉。

我們的Universal Link 業務部署

我們的Universal Link就像知乎一樣，沒有選擇我們的主域名，而是選了一個完全沒在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)?{
????????????//地址匹配+頁面跳轉
????????????NSString?*router;
????????????if?([pathComponents[1]?isEqualToString:@"view"])?{
????????????????router?=?@"xxx";//生成打開APP閱讀頁的專屬Router
????????????}?else?if?([pathComponents[1]?isEqualToString:@"_iosuniversallink"])?{
????????????????router?=?@"xxx";//解析出APP能識別的任意路由，
????????????}
????????????if?(router?&&?router.length?>?0)?{
????????????????[[WKDispatcher?sharedInstance]?operationObjectFromRouteURL:router];//無論是閱讀頁路由還是任意路由，發起跳轉
????????????}
????????????return?YES;
????????}
????}
????return?NO;
}

可以看出來我只打開了這個域名下https://xxx.xxx.xxx/view/* 和 https://xxx.xxx.xxx/_iosuniversallink/*2個Universal Link Path.對沒錯，不像知乎那么多。

/view/* 后面的*直接是閱讀頁ID，用于快速生成閱讀頁路由，發起跳轉
/_iosuniversallink/* 后面的*其實應該填寫的是我們App已經設計好的路由字符串，識別出路由字符串后，發起跳轉

其實可以看出來/_iosuniversallink是完全包含/view的，因為APP閱讀頁天然也是包含在我們的路由規則內的，只要這里有路由策略，擴展力已經足夠支持任意APP頁面了，因此apple-app-association只配置了2個，但是如果有計劃外的特殊case，大不了更新一下，也沒多大事。

為了統一WAP&APP，為了通用鏈接的效果

我剛才提到，我們選擇的Universal Link的域名其實是一個沒有實際頁面的域名，也就是說https://xxx.xxx.xxx/view/*這個url，如果沒安裝APP因此觸發WebView繼續跳轉原地址，會直接404。處理很簡單，重定向一下

router.use('/view',?function?(req,?res,?next)?{
????var?path?=?req.path;
????res.redirect('https://wk.baidu.com/view'?+?path?+?'?st=1#1');
});

整個效果就是

跳轉https://xxx.xxx.xxx/view/*

已安裝App

打開App 觸發handleUniversalLink
走到/view/分支，拼接閱讀頁路由
跳轉

未安裝App

WebView原地跳轉https://xxx.xxx.xxx/view/*
命中服務器的重定向邏輯
重定向到https://wk.baidu.com/view/*
打開我們的WAP閱讀頁

這就是為啥明明/_iosuniversallink是完全包含/view能力的，但還是要把/view/單獨處理的原因，為的是實現WAP與APP的統一設計，為了通用鏈接這個初衷

不為了統一WAP&APP 只拿來當強化版Schema使用

同樣的道理，https://xxx.xxx.xxx/_iosuniversallink/*這個url，也沒有實際的頁面，如果不進行重定向，也會直接返回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就是我們為iOS下載App準備的專門的WAP單頁面，這個頁面打開后會自動延遲500ms，發起跳轉appstore

整個效果就是

跳轉https://xxx.xxx.xxx/_iosuniversallink/*

已安裝App

打開App 觸發handleUniversalLink
走到/_iosuniversallink/分支，拼接出任意App內的界面路由
跳轉界面

未安裝App

WebView原地跳轉https://xxx.xxx.xxx/_iosuniversallink/*
命中服務器的重定向邏輯
重定向到https://wk.baidu.com/topic/naiosappstore
naiosappstore頁面會延遲跳轉AppStore
打開AppStore下載

這個設計看起來就是完美解決了PM得需求

如果已安裝App，跳轉對應界面
如果沒安裝App，跳轉App下載界面

解決了舊Schema模式下的弊端問題：

Schema無法判斷是否安裝App，只能采用setTimeout的Trick方式
Schema的Trick方式會有一個丑陋的錯誤跳轉彈框
Schema無法在微信/手百等App內，打開我們自己的App

簡單的說，這樣設計的初衷就是，我不為了通用鏈接這一目的來使用Universal Link，來統一WAP&APP的URL跳轉，我就為了把Universal Link當做加強版Schema來使用

作者：折騰范兒_味精
鏈接：http://www.jianshu.com/p/55ac5c5c5b59
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

近大家反饋微信登陸失敗,提示語未,“由于應用universal link校驗不通過，無法完成微信登陸”，特開此貼，解決此問題

具體情況如下圖：

微信開放平臺移動應用 SDK 更新提醒

為適配iOS系統版本更新，微信開放平臺在2019年9月對移動應用iOS SDK進行了升級，詳見SDK更新公告。為提升平臺安全性、避免開發者的應用后續受到影響，平臺將于近期開始逐步對iOS 舊版本 SDK能力（版本號低于1.8.6.1）進行階梯式調整，具體計劃如下：

2020年3月20日起對舊版本 SDK發起的分享增加“未驗證應用”安全提示
從2020年3月20日起，開始對未更新SDK的移動應用（版本號低于1.8.6.1）灰度上線安全提示，即用戶分享后，將不展示分享源App信息。
2.2020年6月1日起限制舊版本 SDK 使用微信分享、微信登錄、打開小程序、一次性訂閱消息等能力

關于openSDK1.8.6的更新說明
配置應用的Universal Links
1）根據蘋果文檔配置你應用的Universal Links
微信對Universal Links配置要求
a）Universal Links必須支持https
b）Universal Links配置的paths不能帶query參數
c）微信使用Universal Links拉起第三方App時，會在Universal Links末尾拼接路徑和參數，因此App配置的paths必須加上通配符/*

示例:

{ 
"appID": "8P7343TG54.com.tencent.xin.SDKSample",    
"paths": ["/sdksample/*"]
}

在Xcode中配置關聯域名

打開Associated Domains開關，將Universal Links域名加到配置上

檢查確認App的Universal Links配置成功，通過上述SDK接入成功驗證指引操作

配置universal link 對iOS開發者來說并不難，但服務端配置就涉及購買域名，https購買，以及配置apple-app-site-association
我自己用的是【Xinstall】的服務（之前用過這家的內測服務）,登陸注冊以后就可以免費使用了。不需要進行復雜的配置操作，直接生成universal link鏈接

自動配置

.iOS端需要的設置

非代碼相關

1.1 首先AppID下的Associated Domains要開啟的

1.2 Xcode TARGETS ->Signing&Capabilites 下添加Associated Domains

1.3 搞一個apple-app-site-association文件[創建一個空白文件（必須純文本，命名為apple-app-site-association，去除后綴名)]交給后臺或者運維人員

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "KEAAAAA.com.baidu.syoraoooo",
                "paths": ["*"]
            }
        ]
    }
}

期中 appID 稍微注意一下 
KEAAAAA為蘋果賬號的團隊ID在蘋果開發者網站查看 
com.baidu.syoraoooo為BundleID

Info.plist里添加 LSApplicationQueriesSchemes weixin weixinULAPI

代碼相關

1.4 AppDelegate.m

@interface AppDelegate ()<WXApiDelegate>
...didFinishLaunchingWithOptions...{
//向微信注冊
[WXApi registerApp:APP_ID 
       universalLink:UNIVERSAL_LINK];
}
...

#pragma mark --- 微信相關
- (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(@"微信授權成功");
   [[NSNotificationCenter defaultCenter]postNotificationName:WechatAuthorizationSucceededNoti object:@{@"code": response.code}];
 break;
   case WXErrCodeCommon:/**< 普通錯誤類型    */ 
                break;
   case WXErrCodeUserCancel:/**< 用戶點擊取消并返回    */
                break;
.....
        }
    }
}

1.5 SceneDelegate.m

@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(@"微信授權成功");
     [[NSNotificationCenter defaultCenter]
     postNotificationName:WechatAuthorizationSucceededNoti 
     object:@{@"code": response.code}];
                break;
      case WXErrCodeCommon:/**< 普通錯誤類型    */  
                break;
      case WXErrCodeUserCancel:/**< 用戶點擊取消并返回    */
                break;
....
        }
    }
}

二.服務端需要的設置

2.1

apple-app-site-association文件保存的位置 根目錄下。etc.https://test.com/apple-app-site-association

.well-known文件夾下(推薦，蘋果在iOS9.3更改了通用鏈接的請求文件的位置，但是仍然支持上面的路徑)。在根目錄新建.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;
}

我們的運維人員一開始沒有加 default_type 我這邊拿到 https://www.test.com/.well-known/apple-app-site-association 放到瀏覽器中直接下載下來了這個文件

同時我在Xcode里調用微信的自檢函數也是不通過的

//在register之前打開log, 后續可以根據log排查問題
[WXApi startLogByLevel:WXLogLevelDetail logBlock:^(NSString *log) {
       NSLog(@"WeChatSDK: %@", log);
}];
//務必在調用自檢函數前注冊
 [WXApi registerApp:APP_ID universalLink:UNIVERSAL_LINK];
//調用自檢函數
[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.