WWDC案例解讀：大衆點評相機直接掃描支付是怎麼實現的

背景

去年12月4日，Apple CEO Tim Cook 和王興共同出如今上海的一家老字號生煎店「大壺春」，現場用大衆點評App體驗了iOS 11新功能，包括用地圖找店訂座、用相機掃碼點餐及Apple Pay付款等一條龍便利服務。

在今年的WWDC上，大衆點評App更進一步：Apple技術人員在「Create Great Customer Experience Using Wallet and Apple Pay」演講中專門重點演示瞭如何用iPhone相機直接掃碼點餐下單，並使用Apple Pay支付閉環的全流程。這背後的技術是怎麼實現的呢？

實現方案

相機掃碼

從iOS 7開始，系統就經過AVFoundation賦予了App「相機掃碼」的能力。不過當時只能經過代碼的形式，構建AVCaptureDevice，並設置輸出類型爲AVMetadataObjectTypeQRCode，來實如今App內部的二維碼識別。 然而，整個iOS系統在此後的幾年一直沒有系統級的掃碼入口，直到iOS 11發佈，Apple終於在系統「相機」App內提供了二維碼掃描識別並跳轉到對應URL的能力。

Universal-Link

Universal-Link是iOS 9以後推出的，能夠實現URL和App之間的無縫鏈接，在此以前是自定義的URL Scheme。和自定義URL Scheme對比，Universal-Link有以下優點：

• 惟一性：Universal-Link使用標準的HTTP協議URL，擁有惟一性。
• 安全性：App能夠控制處理哪些URL。
• 簡單靈活：URL對於H5和App是通用的，若是沒有安裝App，就會跳轉到Safari打開對應H5。
• 私密性：在跳轉以前並不須要知道用戶是否安裝目標App。

結合「相機掃碼」和Universal-Link，咱們就能夠作到從系統「相機掃碼」直接喚起App了。

具體方案：將一個Universal-Link連接對應的二維碼做爲物料投放，用戶直接使用系統「相機」掃描此二維碼，若是裝有大衆點評App，會出現「是否用大衆點評打開」的提示框，點擊即進入App。以下所示：

面臨挑戰

上述方案是咱們基於iOS系統現有能力作出的最佳實踐，然而現實世界總有不少「意外驚喜」等待着咱們：

• 物料已經大規模投放出去了，沒辦法修改怎麼辦？
• 整個流程發起是經過「相機掃碼」進行，業務如何知道入口在哪？
• Universal-Link在微信裏不能跳怎麼辦？

咱們知道Universal-Link的生效主要依賴兩部分：

• AppTarget的Capabilities中配置的Associated Domains，用以控制Universal-Link下的Domain。
• 部署在WebServer上的Apple-App-Site-Association，用以控制對應Domain下的Path。

也就是說，在大型工程化項目中使用Universal-Link，URL必須遵循必定的規則，才能作到全部業務共同使用互不干擾，點評App在引入Universal-Link時也制定了使用規範。

然而因爲對應的物料已經大量投放，物料中二維碼的URL在投放時並無考慮Universal-Link的適配，沒法遵循上面的「最佳實踐」，而從新更換物料的成本又很是高，時間上也不容許。

因此咱們只好「另闢蹊徑」實現這個功能了。因爲Universal-Link自己對URL沒有任何限制，理論上咱們能夠經過部署配置把任意一條URL變成Universal-Link。

這樣一來，投放出去的物料二維碼就沒法遵循咱們已經定義好的Universal-Link使用規範，但這也是咱們必須接受的「妥協」，在局部犧牲一些規範性換來重要功能的實現。

事情到此尚未徹底結束，這種實現方式會帶來另外一個問題：這條物料二維碼對應URL在WebView內打開的行爲會發生改變。

按照Apple官方的解釋：Universal-Link由用戶「主動」觸發，例如在郵件，記事本或是其它App中經過openURL喚起App打開這個URL；而若是用戶處在Safari瀏覽器內直接輸入或是點擊連接打開這個URL，系統會在同源（Domain）頁面下直接打開，非同源頁面則會直接喚起App。

換句話說，若是在App內的WebView打開非同源某個頁面，而後又在這個頁面上點擊了Universal-Link連接，這會變成一次對系統openURL方法的直接調用，若是不作處理有可能會跳出App，即便處理過大部分App也會在此時打開一個新的頁面。

這顯然不是咱們但願獲得的結果，但咱們又必須將這些URL配置成Universal-Link。最終在很是困難的狀況下，咱們和業務同窗達成共識：對於這批特殊的投放物料二維碼，業務系統保證URL使用場景的惟一性，不會在除二維碼以外的其它場景使用這批特徵URL，繞過App內WebView打開異常的Case。

這樣咱們完成了「對於既有投放二維碼的iOS相機掃碼喚起App」實現。

在這個特殊的場景中，整個流程的發起始自於App外，業務很是須要了解當前處於「相機掃碼喚起App」的場景。

遺憾的是iOS系統除了userActivity的相關回調以外，並無一個明確的App啓動路徑標識，咱們只能知道App是經過Universal-Link的方式被喚醒了。

因爲啓動節點在App控制權範圍之外，任何Native埋點的方式都不能在此時生效，咱們惟一能夠拿到的是那條被喚醒的URL，缺少足夠的上下文多是全部啓動相關業務最難以處理的部分。

因爲問題1的解決，咱們知道這條URL在App Scope內是有場景惟一性的，因此咱們能夠據此來比較Tricky的判斷當前的場景。 拿到當前啓動場景標識以後，就要考慮如何告知業務。

最簡單的方式就是經過修改URL，告知業務具體特徵，但做爲一個通用平臺型App直接修改業務方的原始URL顯然不是合適的行爲，並且可能形成沒必要要的麻煩，Header，Cookie，JSBridge等均可以考慮做爲與H5的通訊方式。

到此爲止，咱們完成了「從系統相機掃碼喚起App進入相應頁面」。然而，在國內微信纔是各類二維碼最大的掃描入口，在今年的1月份，微信完全關閉了Universal-Link的跳轉行爲，任何Universal-Link在微信裏都不能往外跳了。

「撿了芝麻，丟了西瓜」，這個ROI對咱們來講過於沉重不能接受。考慮在Universal-Link誕生之前，咱們都是經過openSchema的方式喚起App，「綜合連接」是當時H5在微信喚起App的主要方式，咱們能夠在Universal-Link頁面內再套一層綜合連接，並在此區分用戶場景，完成從微信喚起App的「初心」。

結語

大衆點評App參與了過去多屆WWDC的現場演示，從iOS 6的PassKit開始，經歷Flat Design，MessageKit，MapKit，SiriKit，ApplePay到WWDC2018的ApplePay閃付。咱們積累了豐富的與Apple溝通合做經驗，既有駐場Apple Campus的封閉式開發，也有在IAPM的Face2Face，更多時候是在安化路492號的遠程合做。

一般BD同窗都會基於點評App現有功能和Apple提供的新能力，找到需求點。這種基於外部系統升級適配的二次開發，總會遇到各類問題。有些問題會比較容易能夠直接解決，有些問題會挑戰咱們設定的邊界須要咱們作出妥協，還有些問題沒法正面突破只能規避。

二進制世界老是由輸入，計算，輸出來定義。合理規劃總體架構，明確劃分輸入輸出邊界，儘可能減小外部依賴，可讓咱們在缺乏上下文，不能端到端掌控總體流程的狀況下依舊遊刃有餘。

團隊介紹

點評平臺移動研發中心整體負責大衆點評APP。依託平臺能力，咱們不斷輸出高質量服務：Shark，Picasso，Logan，MCI，移動之家，Appkit等，在這裏和「最好的合做夥伴「以「最嚴格的標準」作「最複雜的業務」，經受考驗，砥礪前行，共同打造業界領先的移動開發團隊。

若是對咱們團隊感興趣，能夠關注咱們的專欄。