從“掃月亮”到“掃福字”，扒一扒背後的支付寶AR框架體系

承智關於支付寶AR框架體系和實踐的分享主要分爲以下三個部分：

1. 支付寶AR框架體系
2. AR實踐案例分享
3. 總結和展望

在本次分享中，來自螞蟻金服支付寶多媒體技術部獵鷹團隊的技術專家承智爲大家解密了支付寶AR紅包背後的技術。在他的演講中首先分享了支付寶對於AR技術需求的一些特點，之後分享了在對支付寶AR框架體系進行設計時遇到的一些問題和挑戰，以及支付寶多媒體獵鷹團隊是如何滿足產品運營需求的，並結合四個具體的案例分享了在支付寶AR實踐中遇到的一些問題和收穫的經驗，最後對於支付寶AR技術的發展進行了總結和展望。

一、支付寶AR框架體系

支付寶AR需求特點
現在AR技術已經成爲了一個比較熱門的話題，很多公司都在AR方面投入了大量的人力和物力進行產品研發。而支付寶對於AR技術的需求存在着自身的特點，正如下圖中所展示的，支付寶AR的運營活動其實特別多，這些活動有基於人臉的、人手的還有基於圖片和logo的，活動形式比較多樣而且所需識別的對象也非常豐富。而一般對於活動運營而言，時效性的要求也比較強，往往只能留給開發一到兩週的時間，所以支付寶對於AR框架體系設計的要求是比較高的。

總結一下，支付寶AR框架的設計大致有以下幾點需求：

運營方面對於時效性的需求，因爲需要讓活動可以隨時上線，所以實時性要求比較高，一般需要在幾天或者幾周的時間內完成開發，並且需要不依賴客戶端的發佈。

針對不同的場景識別需要具有動態的能力，識別logo、物體或者圖像採用的技術是不一樣的，所以必須通過動態配置的方式選擇配置的參數實現對於對象的高效識別，進而達到運營的要求。

SDK輕巧，目前支付寶的體量已經非常大了，所以在實現SDK時需要儘量做到輕巧。目前的經驗是識別引擎200+K；渲染引擎400K，總體而言對於支付寶的增量不會很大。

AR框架體系結構
針對於支付寶AR框架的總體設計要求，支付寶多媒體獵鷹團隊設計出瞭如下圖所示的AR框架客戶端體系結構。AR框架結構主要分爲三層，從下向上依次爲：核心層、接口層和應用層。

在AR框架客戶端體系結構的最下面是核心層，這一層大致包括5個模塊：

• ARConfig，也就是配置文件，配置文件的目的就是當運營活動出現的時候，通過對於配置文件的解析就可以對應地選擇不同的識別引擎以及渲染方式。
• ARBrain，就是整體的識別工廠，這裏麪包括了目前比較主流的一些識別方法。
• ARRender，這是主要的渲染模塊，包括了對於2D圖像序列、3D圖像模塊素材的渲染以及對視頻、純圖像和語音進行播放的功能。
• ARDevice，這部分包括兩個主要的功能：因爲在渲染的過程中往往會遇到機型適配的問題，所以這裏將會使用黑白名單機制對於機型進行管控；而對於一些特定的場景可能還需要管理手機的硬件設備，比如像陀螺儀和手機的傳感器等，這些也都是在ARDevice中進行管理的。
• ARResource，這部分就是資源管理模塊，它主要用於管理識別的素材、動畫渲染的素材以及在整個AR活動中會用到的資源素材。

支付寶AR框架客戶端體系結構的中間是接口層，接口層橋接了各種業務和底層的算法，會根據不同的業務形態總結抽象出幾種對外呈現的接口方式供外面調用。AR框架的最上層就是對接的各個業務方的應用層，比如“掃月亮”、“掃logo”等應用以及對外開放數據之後的一些ISV的應用。

AR引擎動態配置
具體而言，怎樣才能夠獲得動態化的能力呢？其實在下圖中可以看到，想要獲得動態化的能力最主要的就是在識別引擎中涵蓋了一些識別的方法，包括了針對於顏色的、形狀的、目前比較主流的海報的互動、基於特徵點的以及對於形狀比較單一或者比較特殊的對象等等識別的方法。而對於一些客戶端做不了的事情，比如春節期間的一些福字識別或者聖誕節期間聖誕樹的識別這些也會由客戶端將圖片上傳到服務端，在雲端進行識別。

結合客戶端和服務端兩種模式的識別達到一種比較通用的識別手段，然後在進行具體配置的時候，可以通過配置文件選擇某一種具體的識別方法，比如上圖中最左邊的配置文件，可以選定使用feature point的方式來達成識別的目的。在識別完成之後，可以跳轉到一個動畫，或者進行動畫跟蹤、具體渲染等，最後再跳轉到H5頁面。與此同時，配置文件也會指定識別過程中用到的一些素材包和識別包的路徑，然後引擎就會在相應的目錄加載相應的資源。每一種識別的方法都會有單獨的配置文件，該文件會表明識別對象的名稱、大小，以及在多大的尺度和旋轉角度下進行識別，所以這是和識別方法緊密相關的，可以將一些識別方法的參數單獨列出來，儘量做到不用修改代碼而只需要修改配置文件實現動態推送的能力。

AR研發流程
這部分介紹的主要是AR底層的設計相關的內容。從整體來看，一個AR的項目從開發到上線可以抽象成爲以下的四步：

1. 線下素材製作過程，如果一個AR活動需要上線，那麼就需要準備兩部分的素材，一部分是動畫呈現的素材，比如像圖像序列以及3D模型；同時還需要有互動的素材，比如需要識別的對象是什麼，如果需要用到識別模型，那麼就會需要有一個離線的訓練模型。
2. 當所有素材準備好之後會將它們推送到雲端的素材中心和配置中心，素材中心存儲了識別的素材包和呈現的素材包，而配置中心則配置了相應活動的信息以及AR引擎裏面所需要用到的配置文件信息。
3. 在活動開啓的時候，支付寶APP的客戶端會主動地從服務端拉取相關的資源，在將資源拉取到本地之後進行實時的渲染。
4. 最終將AR效果呈現給支付寶客戶端的用戶。
   
   整體來看，AR研發最主要的工作就集中在第一部分，也就是怎樣製作素材以及如何將識別和跟蹤這部分功能在線下驗證完成之後實時地推送上線。如果整個流程進行的比較順利的話，可能只需要幾天的時間就能將一個AR運營活動做上線，達到快速上線的目的。

二、AR實踐案例分享

接下來承智分享了2016年支付寶所做的與AR相關的四個案例，並且重點分享了春節期間支付寶推出的掃福字集福卡活動案例。

AR實踐1：掃月亮

支付寶AR運營活動的首次的嘗試就是在2016年中秋節的時候做的掃月亮的活動，當時需要識別月亮以及一些圓形的物體。

而掃月亮這個識別流程大致分爲以下三部分內容：

1. 因爲在進行實景拍攝時，月亮的成像一般都比較小，所以用到了亮點檢測模塊，然後簡單地做了場景分析，把明顯拍攝的不是月亮的圖片進行過濾。
2. 第二部分就是支付寶官方也會推出一些海報，而海報的呈現一般都比較大，所以這裏用到了白圓檢測的算法。
3. 因爲中秋節那段時間的天氣不是很好，所以有可能出現看不到月亮的情況，而爲了增加互動的話題，市場和運營提出要求，希望允許識別除了月亮以外的圓形的物體，於是還需要使用到圓形物體檢測算法。
   
   總之，將上述三個部分整合到了一起，從而實現了對於圖片快速地進行識別。當時大概處理一幀的時間也就在100毫秒以內，往往在用戶擡手機的過程中對象已經被識別出來了，但是人的視覺可能都還沒有識別出來，因爲識別太靈敏可能給用戶造成一種假象的感覺，所以做了延遲3秒的處理，並且設定了不會在擡手機的過程中進行圖像識別。除此之外，對於圓形檢測而言也有很多方法，比如隨機選擇多個點擬合成一個圓形來進行匹配。而其實在客戶端的開發過程中，速度和計算量要求會非常高，所以這裏使用了簡化後的方法：首先使用顏色分割將物體區分出來，提取邊緣後使用近似圓檢測。

掃月亮活動整體的效果還是不錯的，在微博上引起了比較大的熱議，同時一些圖像的網站也藉此進行了宣傳。

AR實踐2：掃1212集四寶

掃月亮活動之後，也有很多的業務方開始積極主動地去開拓相關的應用場景。所以在雙12的時候，支付寶也進行了線下引流，通過在線下商圈張貼海報引出“掃1212集四寶”的活動。因爲是主要針對線下商圈的場景，所以這次活動的宣傳量並不是特別大，但是活動現場的熱度還是不錯的。

當時的需求是識別“1212”這四個字，但是在實際線上測試的時候發現，海報樣式是非常豐富的，總共大約有20多種樣式，因爲角度、遠近和光線等因素，導致攝像頭採集的像素可能比較低，所以實拍圖片的識別難度比較大。所以最後採取的策略是近景識別“1212”四個字，遠景則對於整個海報進行識別。整個客戶端大概支持了對於20多種圖片的識別，在杭州銀泰百貨進行實測的時候也進行了動態改進，不斷調整線上配置的模型包，實時地提升整體用戶的體驗和算法功能。如果不具備這樣動態調整的能力，而是將代碼靜態地放在客戶端，那麼這樣一旦上線以後，就很難做到修改和更正，所以引擎的動態化在一些運營的場景裏面是十分重要的。

對於這次活動總體效果而言，客戶端對於20張海報圖的整體識別率接近90%。沒有能夠達到特別高的識別率是因爲在線下的場景裏面可能存在距離比較遠等因素的影響，一些情況下，可能人眼能夠識別到，但是機器卻因爲像素比較低而無法準確地識別。識別的速度大約在每幀130毫秒左右，所以整體用戶體驗還是比較流暢的，當時還有很多地方電視臺對這次活動進行了採訪報道。

AR實踐3：AR實景紅包

接下來重點分享一下支付寶去年做的與AR實景紅包相關的一些實踐。支付寶去年推出的AR實景紅包也算是一次比較大膽的嘗試，其實在業務討論的階段，初期的方案與一些像Pokemon GO 一樣的已有產品比較類似，想通過LBS和手機傳感器來實現互動。但是在開發過程中卻遇到了一個問題，就是如果想在某一個樓層發放紅包或者只針對拍攝這個樓的時候才能發放和領取紅包的話，通過現有的技術是無法解決的，因爲LBS的定位不能滿足這樣的需求，在一棟樓裏面，LSB無法區分出某一層。面對這樣的問題，支付寶多媒體獵鷹團隊提出了這樣的一個方式就是基於拍攝圖片的比對來實現目的，比如用戶在藏紅包的時候對着這個物體拍攝的，領取的人也必須來到這個地方，找到這個物體才能拍攝並領取紅包。基於這樣的邏輯，支付寶技術團隊一起將AR實景紅包實現並完成上線。AR實景紅包的一個優點就是可以幫助商家進行品牌宣傳，因爲需要藏和找紅包都需要拍攝圖片，商家可以將自己的logo或者產品作爲線索圖進行推廣。

AR紅包框架

AR紅包框架背後的邏輯主要是兩個部分：一部分就是藏紅包的過程，另一部分就是找紅包的過程。在藏紅包的過程中爲了避免很多存在歧義的場景，比如隨處可見的白牆以及比較暗的區域等，支付寶多媒體技術團隊在這裏面加上了一個評估過程。如果用戶想要發AR紅包，首先就需要判斷這個場景適不適合發紅包，是不是需要讓光線更加明亮一點，因爲特別暗的場景不適合藏紅包；另外一方面就是評估紋理是不是足夠豐富，因爲如果紋理特徵比較少的話，無論是後續的識別還是做區分度，都是不利的，所以在藏紅包的時候對這一部分特徵進行了限定。如果滿足以上條件的限定的話，就會將圖片上傳到服務端，在服務端進行特徵提取，然後合成一張線索圖。

而在找紅包的時候，當用戶選完一個紅包之後，線索圖以及紅包的特徵碼會被客戶端拉取到本地，後續的圖片比對都是在本地完成的。這樣做的好處就是用戶在找紅包的過程中，可以進行實時的計算，如果將這個圖片傳到服務端可能數據傳輸來回的時間達不到產品的需求，另外也達不到對於用戶體驗以及準確性上的需求了，所以在客戶端對於圖像進行實時匹配的優勢還是很大的。在本地匹配成功之後會將對應的圖片傳到服務端進行二次校驗，進行二次校驗的主要目的是爲了保證安全性，因爲可能出現惡意用戶繞開支付寶入口，直接調用後臺服務的情況，所以這裏面的二次校驗主要是針對一些作弊行爲進行了特殊處理。

AR紅包的挑戰

其實在AR實景紅包的背後也遇到了很多的挑戰：

• 圖片比對準確性，在實景紅包推出來之後，很多研究人員也在研究圖片的比對是基於什麼樣的算法。其實在最開始支付寶多媒體技術團隊也考慮了很多種算法，比如基於顏色、形狀的算法，但是測試後發現旋轉、遠近、角度等因素對於這些算法的影響都比較大，並且造成誤檢非常多。所有後來就採用了比較傳統的基於特徵點匹配的方式進行實現。
• 算法性能和CPU佔用率問題，圖像識別對於客戶端的算法性能要求是比較高的，如果對於圖像的每一幀都進行計算的話，手機CPU佔用率會很高，導致產生髮熱問題。可能出現在找紅包的過程中，持續地找了幾分鐘，由於計算量會很大，導致手機發熱的問題非常嚴重。針對於這個問題，支付寶採用了抽幀的方式，大概一秒鐘處理3到4幀的計算量，雖然對於整體計算流程的影響不會非常大，但是將整體的計算量降下來了，使得CPU維持在佔用率30%左右的水平。
• 圖片流量的問題，在藏紅包和找紅包的過程中都需要傳輸圖片，而在傳圖的時候就涉及流量大小問題。爲了幫助用戶節約流量，並將傳輸速度提升上去，支付寶在傳圖過程中用到了智能壓縮的方式，將傳圖過程消耗的整體流量降低下來。
• 渲染兼容性問題，因爲目前安卓機型特別多，從統計數據來看，支付寶用戶大概會使用到2000多種機型，因爲不同的手機能夠支持的渲染的版本和能力是不一樣的，所以在做3D渲染的時候就會遇到兼容性的問題。因此AR紅包對渲染兼容性的處理使用了手機黑白名單的機制，將一些性能比較好的、比較主流的機型列在白名單裏面，這樣的機型會使用正常的3D渲染方式；而對於一些性能比較差的、支持能力也不是特別好的機型，則可能採用降級的方式，可能會採用2D渲染方式跑動整體的流程，只不過在呈現的效果上面則會差一點。
• PS冒領問題，在AR實景紅包上線之後，遇到了一個比較大的問題就是PS冒領問題。最開始推出AR實景紅包的時候，支付寶做的提示圖會比較簡單一些，就是使用簡單的橫條紋做了提示圖，但是也有一些PS愛好者通過PS軟件把橫條紋P掉，然後恢復出原圖大概的模樣，並拍攝這個圖冒領其他人發的紅包。針對於PS冒領問題，解決方式就是使用自動化生成網格提示圖的方式，使得每個紅包的提示圖都是不一樣的，提示圖的難度增加了，所以很難從提示圖恢復出原有圖片的模樣，但是目前而言在網上尋找相似圖片的作弊手段還是比較難避免的。

AR紅包效果

最終AR實景紅包上線的時候，影響還是比較大的。可以從最初的界面上看出，圖上定位點周圍的區域都佈滿了紅包，當然這是個人的玩法，而影響比較大的就是隨着商家對活動的關注，很多商家也願意嘗試加入進來，所以後來就有二三十家主流商家加入進來，也創造了新的營銷方式，就是通過拍攝自己的logo進行宣傳。

AR實踐4：掃福集福

2017年春節，支付寶推出的紅包活動是掃福集福，關於這個活動大家瞭解比較多的就是掃描網頁上或者門貼上的福字，但是其實在這背後還涉及到很多複雜的需求。

在支付寶技術團隊實現AR掃福時面臨着一些主要的挑戰：

• 多識別任務併發，在掃一掃的入口不僅僅需要識別福字還要識別不同的海報，而且一些商家的紅包也是通過掃一掃的入口傳一張圖到後臺進行識別的，所以這是一個多任務併發的過程。
• 掃福字請求高併發，因爲春節掃福集福活動的關注量比較大，所以掃福字的請求數也比較高，每秒需要處理的計算量也是非常大的。
• 福字識別的挑戰，當時提出的需求是福字識別不僅僅需要能識別網頁上的福字，而且對於一些手寫的福字或者牆上貼的福字也都要進行識別，因爲需要識別的福字樣式非常豐富，所以從福字本身的識別難度上來看也存在一定的挑戰。

春節期間的掃福活動還和可口可樂進行了深入的合作，所以也需要支持對於可口可樂7種福娃的掃描。上圖中最上面的一行圖片就是可口可樂福娃的海報樣式，顧客通過掃描線下購買的可口可樂產品上的福娃，就能領取相應的紅包或者福卡。與此同時，支付寶在海外以及港澳臺等地區也進行了大規模的海報宣傳攻勢，所以也需要對於這些特殊定製的海報進行支持，當用戶在海外機場或者在海外消費的時候，看到這些宣傳海報使用支付寶掃一掃也能夠獲取福卡。所以對於識別而言，除了需要識別開放性的福字，也需要對於大約14種海報的樣式進行識別。

AR掃福框架設計

爲了滿足上述的需求，支付寶掃紅包客戶端的識別策略也採用了分幀處理的模式。

首先在第一幀的時候進行對於海報的識別，大概就是對於之前提到的14種海報進行識別，而且每幀處理的時間大概控制在100毫秒以內，所以能夠非常迅速地判斷當前拍攝的是不是海報。

在下一幀的時候就需要判斷手機是不是靜止的，因爲有時候在客戶端識別不成功，需要將圖片傳到服務端去，就需要判斷當前手機是否處於靜止狀態。而靜止判斷也有很多種方式，比如通過手機的陀螺儀以及傳感器等進行判斷，而支付寶技術團隊則使用的是通過圖像判斷，使用圖像前後幀的差異大小判斷，如果在兩到三秒連續的時間內圖像的差異不是很大，那麼就認爲當前用戶的意圖是想要拍攝一張圖片併發送到服務器端進行識別，所以在第二幀進行的是圖像靜止判斷處理。如果靜止判斷成功，就會將圖片傳到服務器端進行識別。

第三個步驟，就是本地福字檢測。爲了應對可能出現的服務端壓力扛不住的情況，需要做一個基於本地客戶端的緊急預案，於是支付寶多媒體獵鷹團隊在客戶端做了基於LBP的福字檢測的本地備案算法。本地福字檢測的目的就是爲服務端分流，而且這一功能會在需要的時候打開。其實在活動初期的時候這個開關是處於關閉狀態的，所以掃紅包的過程只有前面的海報識別和傳圖到服務端這兩個步驟，當活動進行到第二天的時候因爲服務端壓力比較大，纔將三個步驟全部開啓。這種策略的好處就是爲用戶提供的整體體驗不會存在卡頓情況，因爲每個模塊處理完成也就是在100毫秒以內，所以每秒也能進行大約10次的嘗試，平均下來每個模塊大約也有三次機會。支付寶AR掃福框架的反應速度和流暢性都得到了很好的保證，而客戶端福字識別的模塊的加入也能夠進行分流，幫助服務端減輕了負擔。

活動效果

最終達到的效果就是在同時開啓客戶端和服務端的福字識別之後，識別的峯值達到了14WTPS。活動開啓的第一天預估的峯值大概在1萬左右，但是由於用戶參與的熱情很高，所以在活動開啓一天之後就達到了服務端識別能力的上限，於是就立刻開啓了客戶端的本地識別。但是這也同時帶來了一些問題，因爲客戶端的識別能力有限，所以一些不是福字的圖像會被誤識別成福字，而這些都是在後續開發的時候在技術包裝和儲備上面需要進一步完善的地方。

但是總體活動效果上看還是不錯的，能夠把大多數用戶拍的福字識別出來，少量的誤識在產品上是可以被接受的。整體上70%的識別任務都是在客戶端完成的，而且識別過程還是比較流暢的，只有少量本地無法識別的情況纔會上傳到服務端，這樣的做法節省了服務器的資源。通過這樣的活動也引起了很大的關注，網上也很多出現了很多趣聞，所以整體上效果還是不錯的。

三、總結和展望

以上就是目前支付寶AR技術的一些分享，那麼未來支付寶的AR技術將會朝着什麼樣的方向發展呢？

承智談到支付寶多媒體獵鷹團隊首先會在現有的基礎之上完善已有的AR技術，並和其他技術團隊一起努力打造一個AR的開放平臺，希望能通過這樣的平臺使更多的開發者和AR技術愛好者能夠參與進來，創造出更多的創新性場景，並通過這樣的平臺爲用戶和商家建立相互連接的關係，使大家都能夠從AR開放平臺上受益，創造出更多的價值。

原文來自：雲棲社區；原文鏈接：https://yq.aliyun.com/articles/71084
點擊閱讀更多，查看更多詳情