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

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

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

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

1、支付寶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運營活動作上線，達到快速上線的目的。

2、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%的識別任務都是在客戶端完成的，並且識別過程仍是比較流暢的，只有少許本地沒法識別的狀況纔會上傳到服務端，這樣的作法節省了服務器的資源。經過這樣的活動也引發了很大的關注，網上也不少出現了不少趣聞，因此總體上效果仍是不錯的。

3、總結和展望

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

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

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