背景
再過不久又是農曆新年，近幾年在新年期間除了春晚之外，還有一個新的全民活動，那便是支付寶 AR 掃福。支付寶從 2017 年新春開始，五福的玩法變得有趣起來，陸續推出 AR 實景紅包：通過将紅包藏在特定場景中，打開 AR 相機進行尋找，這種新穎的基于 LBS 的紅包方式引起一股熱潮。
在 2018 年春節，支付寶将科技元素更新，推出了全民 AR 掃任意福的活動，通過掃福來集福，不管你是商店買的福，還是手寫福，支付寶都可以将它們認出來。随了掃福以外，支付寶中還有大量的此類需求，如銀行卡識别、身份證識别等，xMedia 多媒體端智能應用架構便由此衍生出來。
「端智能」
AR 掃福即使在網絡狀況并不好的情況下，識别速度都非常快，而且和一般的上傳圖檔進行識别的流程不同，并不需要使用者選擇圖檔并上傳的操作。為什麼？除了算法與模型優化之外，還有一個很重要的原因就是識别引擎運作在端上，這也是最近端上AI越來越火爆的一個原因，我們稱之為“端智能”。為什麼要将引擎運作在端上？和一般運作在雲端的智能化有什麼差別？
引擎之是以運作在端上而不是雲端，主要有兩大原因：一是由于端上湧現出大量的需求雲端無法滿足，在很多場景下端上的優勢明顯；二是由于端自身條件成熟。
- 端上識别引擎的優勢：
| 優勢點 | 具體資訊 |
|---|---|
| 成本 | AI 不是一個成本很低的計算，對于掃福這類大型的活動，如果所有計算都部署在雲端，那伺服器的流量、計算及存儲成本将是不可想象的。但移動端本身就包含這些資源，有海量的本地邊緣計算能力。 |
| 體驗 | 現在的掃福平均時間是數百毫秒，如果走雲端的方式，圖檔資料在網絡傳輸方面的耗時将極大影響體驗，遇到網絡不好的情況時更是糟糕。很多人都有過新年搶火車票的經驗，在同一時間大量的流量湧入時，等待使用者的是無盡的轉圈與重試。端上既不存在大資料的網絡傳輸，也不存在大量的并發通路，是以這種場景的體驗會好很多。 |
| 隐私 | 大資料時代人們對個人隐私的意識越來越強，雲端可能面臨着敏感資料上傳的風險，比如前段時間火爆的換臉應用ZAO，它需要上傳一張人臉的照片，就是這點讓很多人放棄了使用。而如果是純端上的運算，所有的資料都儲存在使用者的手機上，并不會像雲端一樣存在敏感資料上傳的風險。 |
- 端上條件成熟：
除了端雲對比的優勢以外，另外一個更重要的原因是端上條件成熟，足以很好的支撐智能化的計算。主要有下面幾個方面的原因：
- 一是終端裝置算力的增強，強大的 CPU 和 GPU 可以進行非常複雜的運算，還有很多專門的 AI 晶片內建在手機中，算力進一步加強。
- 第二點是移動端 AI 引擎的發展，如支付寶的 xNN，Google 的 TensorFlow Lite 等，讓 AI 運作在移動端成為了可能。同時模型壓縮技術的發展也讓過去雲端動辄數百兆的模型可以被壓縮到幾兆以内，讓模型存儲于手機端成為了可能。
- 最後端上有很多類似于五福的實時類應用場景興起，比如支付寶的 AR 識花/識車等，都是針對視訊流進行識别。
AI 為業務帶來了非常多的創新，而業務的蓬勃發展也驅動了AI技術的迅速發展，如何讓這些場景迅速在移動端落地便成為極其重要的事情，xMedia 端智能應用架構便是為解決這個問題而産生。
端智能應用架構 xMedia
「端智能流程」
既然 AI 運作在端上，那麼以掃福為例，整體的開發流程是什麼樣？來看下面這張流程圖：
主要分成兩部分，首先是針對掃福場景的模型如何産生。這點和雲端的模型制作差別不大，一般由算法工程師負責，包含資料采集、算法設計、模型訓練、模型壓縮、模型部署等步驟。
待模型完成之後，接下來就到了端上的工作，它由移動端開發工程師負責。首先是資料的采集，如掃福需要打開相機，有些場景還需要其它傳感器的資料用于靜止判斷等。采集到資料之後，不能直接将圖像給到引擎，為什麼？因為原始的圖像分辨率很高，可能是 1080P，引擎不可能直接對這樣的圖像進行處理，需要先對圖像進行裁剪縮放等操作。另外還有檢測區域的處理，隻有位于螢幕中心位置的區域才會被傳遞到算法，這是為了優化性能。在運作過程中，也不能夠将所有采集的資料直接傳遞到後面進行處理，需要一定的排程政策，比如如何控制算法處理的幀率等。接下來才到 AI 引擎，引擎計算出來結果之後，也不能夠直接傳回給業務，而是需要一些處理才能展示出來，比如掃福中的 AR 動畫。
整個互動過程看似簡單，但其中涉及到非常多的細節。比如：下一幀過來時，上一幀還沒有處理完怎麼辦？系統發熱嚴重怎麼辦？覆寫率太低怎麼辦？等等。由此可見，移動端多媒體AI應用能否成功，除了需要一個好的模型，還依賴于資源的排程、資料的同步、部署模型的快捷程度及如何觸達到更多的使用者，這需要算法工程師與移動開發工程師共同的努力。
除了 AR 掃福為外，支付寶中還有很多其它類似的智能化需求，xMedia 架構便是為了解決各種場景都存在的這些共性問題。
「挑戰」
從前面掃福的流程中來看，端上的AI應用場景面臨着一些挑戰，主要包含以下四個方面：
**• 工程效率與門檻
• 終端軟硬體多樣性
• 終端資源與算法
• 端智能的局限性**
對于工程效率與門檻，網際網路時代最重要的成功條件之一，天下武功，唯快不破，這類挑戰是如何以彈性靈活的方式完成各種各樣的業務需求，如何在不發版本的情況下部署及更新模型，技術資源較少的垂直場景業務如何快速接入？解決思路主要有兩種，一種是能力原子化，可以讓業務快速友善的通過某種方式來組合業務。第二種思路是垂直場景的封裝，将 OCR 銀行卡/身份證等場景封裝成可以直接使用的元件，降低這類場景的使用門檻。
面臨的第二個挑戰是終端軟硬體多樣性，Android 開發同學深有體會，數以千計的機型，GPU 型号 50+，相容性與覆寫率問題簡單是開發者的惡夢。這類挑戰主要表現為如何能夠讓業務觸達到更用的使用者，讓低端機也能夠獲得較好的體驗。對于這點主要是通過不同次元的配置政策來解決多樣性問題，針對各種 GPU 特性的相容處理。
第三個挑戰是終端資源與算法，所面臨的問題是如何能夠做到效果與電量之間的平衡，比如支付寶 AR 掃福，如果掃福一分鐘耗電 30%，那麼支付寶将面臨着使用者無盡的口水。解決這個問題除了算法本身的極緻優化以外，還有一些自适應的排程政策，接下來會有詳細的描述。
雖說端上智能在很多場景下有非常多的優點，但相對雲端仍然存在一定的局限性，識别率與處理能力上無法達到雲端的效果，端上面臨這點可以通過端雲結合的思路來處理。
如前面所說，支付寶中越來越多其它的智能化業務也同樣面臨着這些問題，如何解決這些共性的問題便成了 xMedia架構所面臨的最重要的任務，這些挑戰的解決方案也構成了該架構的主要特性。
「xMedia 技術大圖」
為了解決前面提到的各種挑戰，xMedia 架構逐漸演變成下面的架構，最重要的部分位于架構層與能力層。
先來看看能力層，前面提到，架構的思路是将處理能力原子化，并快速友善的将這些能力組合起來描述整個業務場景。它有些類似于AI引擎中的各種算子，不同的是AI引擎中的算子粒度非常細，而這裡算子更加抽象，比如檢測/分類算法、OCR 通用算法、圖像識别能力等，它面向的是業務的開發者，而不是算法工程師。同時還有一個不同點，這裡的算子不僅僅是算法的封裝，它還包含渲染能力及資料源的采集能力等，是以為了加以區分，我們稱這些原子化的能力為
functor
。業務将這些原子化的
functor
組裝起來完成需求，如何組裝便是架構層的工作。
架構層類似于AI中的模型，在AI中，模型是将各種各樣算子組合成一張有向無環圖，用于描述算法的整體處理流程。在xMedia中，我們将前面能力層的各種
functor
通過協定組裝成圖，來描述整體業務的處理流程。因為這些
functor
不僅包含了算法，還包含渲染，采集等，是以可以構成完整的處理流程。除了将這些表達業務的圖建構起來以外，架構層還需要負責算法的排程控制、資料同步、參數動态配置等事情。概括來說，能力層負責
functor
，架構層負責将
functor
以最高效的方式運作起來。
在接口層，xMedia 提供了多種 API，包含端上的 Android/iOS 平台，為了便于前端使用，H5 與支付寶小程式的 API 也有提供。對于外部使用者來說，xMedia 也通過 mPaaS 獨立輸出（mPaaS 是螞蟻金服提供的完整 APP 解決方案，在大量的銀行及保險公司 APP 中使用）。
因為特性較多，篇幅有限，接下來我們選擇其中三個方面來介紹，這三個方面粗略的涉及到業務開發的完整流程：
- 如何靈活應對需求
- 如何讓算法更好的運作
- 如何提升覆寫率
1. 如何靈活應對需求
前一節提過，為了應對複雜的業務需求，主要思路為兩點：
- 将能力原子化成
functor
- 通過協定将業務流程用上面的
functor
以下圖的處理流程為例：
圖中分為上下兩個部分，上面部分運作在用戶端，有多個業務入口。業務将流程描述的協定傳入架構，架構将該協定解析成由
functor
組裝。針對不同的業務，該協定可以從雲端進行配置。
圖一般由三部分組成，輸入、中間處理和輸出。輸入可以是麥克風、相機、傳感器等資料，這些資料被采集之後輸入到後面的處理
functor
中，因為這些輸入源都是抽象出來的算子，也即
functor
，它們可以非常友善的進行擴充，當有其它類型的輸入資料時，都可以将擴充後的
functor
加入圖中。中間部分一般是算法類的
functor
，如推理、OCR、圖像識别等，它們是輸入資料的消費者，每個
functor
處理完這幀的資料之後會傳到圖的下一個節點。最後一部分負責将輸出結果展示給使用者，比如将手勢或者姿态的關鍵點疊加到相機幀上，或者 AR 場景中 3D 模型合成至相機幀中。
由于
functor
可以自由擴充并組裝到圖中，這便為業務帶來了靈活性，與各種深度學習的架構思路一緻，通過擴充算子來增加架構的能力，通過模型檔案将算子組合來完成不同的算法功能。
手勢檢測
接下來我們以一個線上例子來說明如何應用。
以螞蟻莊園運動會的小雞操為例（可以通過支付寶-螞蟻莊園-運動會-手保健操體驗），這是一個手勢識别的場景，通過 AI 引擎檢測使用者相機中采集到的手勢，當使用者的手勢與 UI 上提示的手勢一緻時即判定成功。那麼，除了手勢識别的模型之外，該場景如何用前面所說的思路？
下圖是該業務的一個協定描述檔案示意圖，它描述了整個業務的流程，比如每個步驟具體由哪個
functor
來執行，它的參數是什麼，
functor
輸出的資料流向哪個
functor
等：
xMedia 架構根據描述檔案，運作時生成如下所示的流程圖，該圖從資料源開始生成資料，并将資料傳輸至每個
functor
處理，最後通過預覽的
functor
渲染至螢幕上。
通過這種方式，可以非常好的解決業務的靈活性問題。我們要做的就是不斷的擴充原子化能力及擴充架構層的控制能力。而業務方除了提供模型以外，用協定就可以較快的将需求描述清楚，動态更新也變會非常友善。
在這個示例中，協定描述了整體業務的流程，但除去業務流程以外，還有一些非常重要的因素決定業務的最終體驗，如：資料的同步、運作排程、覆寫率如何提升等，接下來我們來看其中一個非常重要的部分——算法的排程。
2. 自适應排程
注意看前面的小雞操示例，它将采集到的相機幀傳遞給算法，可是由于相機幀率一般為 30fps，如果将每一幀都交給算法去處理，由于連續幀之間相差不大，造成算法處理的結果存在大量重複，算法按照 30fps 來處理時大部分的資料無效。同時高幀率會造成非常高的 CPU，導緻發熱嚴重，電量以肉眼可見的速度向下掉。
如果幀率不夠，又會導緻算法不能及時的檢測出結果，進而影響使用者體驗，是以選擇一個合适的幀率非常重要。但由于機型的多樣性，不同機器對不同的算法處理能力不同，是以不能夠為所有的機器選擇相同的幀率，那該怎麼辦？
最直接的辦法是針對高中低端機，針對不同算法分别配置一個事先驗證好的幀率，這個方法簡單粗暴。但這個粗暴的辦法會面臨新的問題：
- 如果此時手機本身其它業務占用了較高的 CPU，與測試時環境不同怎麼辦？
- Android 成千上萬的機器如何配置，即使降低次元，也是非常繁重的體力活。
- 對于新出來的機器如何配置？
為了解決這些問題，看似需要一種可以動态根據目前機器進行設定幀率的方法。有一種思路是直接根據 CPU、記憶體等硬體參數來将機器劃分成不同級别，為不同級别的機器配置不同的幀率，這樣看似可以節省大量的手工配置工作。但另外一個問題，手機背景任務不同，有時背景任務很輕，有時任務很重，甚至會出現 CPU 降頻等可能，僅根據機器的配置來進行幀率的控制并不能達到最好的效果，需要一種更加“動态”的方式來選擇幀率。
在這裡，為了控制能耗，在不影響使用者體驗的情況下，我們通過始終将 CPU 控制到某個較低的水準來完成幀率的選擇，進而達到自适應的算法排程的目的。這個思路很像空調的溫度調節，可以将室内控制在一個固定的溫度，這在工業控制中很常見，是以通過算法将 CPU 控制在一個固定值來達到自動控制幀率的目的。主要包含下面三個方面：
首先引入 CPU 監控子產品，實時擷取目前 CPU，用其作為算法的輸入。
接着将 CPU 設定在一個期望的值，通過算法來動态的進行控制，算法以目前 CPU 和目前幀率作為輸入，計算出下一次算法的幀率。
最後，為了保證使用者體驗，額外設定最大與最小幀率，以防止出現異常。
我們通過下面這張圖來看看該方法調節的效果，圖分為上下兩個部分，上半部分是 CPU 随時間變化的曲線，下半部分是算法輸出的時間間隔随時間的變化曲線。（這裡注意一下，為什麼不是幀率？其實兩個是一樣的東西，幀率與間隔互為倒數，而間隔比較直覺，是以這裡讓算法輸出下一幀的間隔。）這張圖以一個示例來表示算法控制的有效性。
可以看到，曲線可以分成幾段：
- 第一段，在 241s 之前，CPU 維持在一個較低的水準，45% 左右，而時間間隔處于 250ms 左右。
- 第二段，在 241s 時突然 CPU 因為其它任務加壓 20%，導緻整體 CPU 迅速上升到 65%，但随後又回落至 45%。此時下半部分的時間間隔也發生了變化，間隔從 250ms 快速升到 1700ms 左右，這正是導緻上半部分中 CPU 迅速回落的原因，處理的間隔增大引起幀率降低，是以 CPU 回落。
- 第三段，840s 左右其它任務對 CPU 的加壓消失，是以 CPU 迅速下降至 20% 左右，但随後又升至 45% 左右，回到初始的水準。下半部分的時間間隔也同樣下降到 250ms，随後穩定，它也正是導緻 CPU 上升的真正原因。
由此可見，該方法可以通過自動控制幀率的方式将 CPU 控制在一個适合的水準，達到體驗與手機發熱的平衡。通過這種自适應排程的方式，也使得各種不同機器都可以自适應的獲得非常好的使用者體驗，同時也會防止手機發熱導緻的耗電問題。
3. 覆寫率
第三方面我們來聊下覆寫率。所有的業務都希望将它精心設計的體驗能夠傳達給更多的使用者，這裡以一個 AR 場景來描述 xMedia 架構中做了哪些事情來提升覆寫率。以 AR 為例是因為它比較典型，能夠很好的說明機器的多樣性對覆寫率提升的影響。
觀察上述視訊，該 AR 算法簡單的說是用視覺的方式來定位目前手機處于空間中的什麼位置，比如這個由花組成的穿越門，利用算法可以将它始終放置在地面的某處。在算法已經優化完的前提下，現在華為 P9 Plus 上 18ms 左右一幀，這裡講述 xMedia 架構層在 Android 上的優化。
先來看看上圖描述的整體流程：相機采集資料之後有兩步操作，一步操作是将相機幀渲染成紋理，同時将幀資料進行預處理，随後同傳感器資料一起傳給算法。算法處理完傳回目前手機的位置，并将該位置用于 3D 場景渲染。接下來這步是關鍵，與前面手勢識别例子不同的是，這裡的資料需要同步。什麼是同步？它指的是 3D 渲染的場景與相機渲染的場景是同一幀資料。是以整體一幀的處理時間就取決于相機的渲染與算法＋3D 渲染的最大時間，整體幀率也由此決定。
這個流程看起來并不算特别複雜，那問題在哪裡呢？有過 Android 相機開發經驗的同學可能知道，擷取相機的資料有兩種方式：
- 一種是直接擷取每一幀的 YUV 資料
- 另外一種是擷取每一幀的紋理
看起來很美好，YUV 資料直接傳給算法，相機紋理用于相機渲染，兩條路處理完之後直接合成即可。然而，它們最大的問題在于，這兩份資料是不同步的。也就是說擷取到的 YUV 資料可能是幾幀之前的，無法與擷取的相機紋理對應，兩者之間根本沒有對應關系。是以如果要同步處理，隻能夠選擇其中一種擷取相機幀資料的方式。
那麼究竟選擇哪一種方式？估計你已經猜到，答案是不能夠簡單的選擇，需要多種政策配合。
多政策适配
對于兩種不同擷取資料的方式，處理鍊路完全不同，如下圖所示：
第一種方式是直接擷取每一幀的 YUV 資料，這種方式對于算法來說比較容易處理，直接傳遞給算法計算出目前相機的位姿，并由 3D 引擎渲染出目前場景。而對于相機渲染來說就沒那麼友善了，需要将 YUV 資料上傳至 GPU 并且渲染出紋理幀，最後與前面的 3D 場景進行合成。這種方式較為直覺。
而對于擷取每一幀相機紋理的方式，與上面方式完全不同。于相機幀而言，因為本身拿到的就已經是紋理，是以渲染紋理實景這步不用處理，可以直接拿來使用。對算法來說就麻煩的多，由于算法需要的是相機資料，紋理無法直接使用，是以需要從 GPU 中讀出 YUV 資料至 CPU 中，讀出的方式也較為複雜，接下來會較長的描述。
政策選型
前面分别介紹了兩種方式的處理方法，那麼應該怎麼選擇？主要思路是根據 GPU 的特點處理，但 Android 平台上僅就 GPU 而言就有 50+ 種，選擇變得困難了很多。但好在經過統計，機型占比絕大部分的 GPU 可以劃分為兩大類：
- 針對 Adreno 類型的大部分 GPU，上傳紋理的能力強，直接渲染YUV資料并無太大性能問題，可以将相機采集的 YUV 資料一邊渲染，一邊傳給算法運算後再進行 3D 引擎渲染，待兩者完成後合成。是以這種類型的 GPU 選擇第一種方式。對于大部分高通平台的機器均是搭載的此類 GPU，占比達到 50% 左右。
- 針對 Mali 類型的 GPU，上傳紋理的能力很差，在不進行算法處理的情況下，僅渲染相機采集回調的 YUV 資料，就存在延時的情況，卡頓明顯，更不用說加上算法的處理。是以對于此種類型的GPU不能夠使用第一種方式。針對該部分機型，渲染時直接使用相機預覽回調的
GLES11Ext.GL_TEXTURE_EXTERNAL_OES
接着使用
glReadPixels
的方式從 GPU 中讀出這一幀紋理，但這裡不能夠簡單的進行讀取，有以下幾個原因：
- 通常從相機中拿出來的紋理較大，如 1280x720，而算法需要的卻很小，比如隻需要 300x300，完整的從 GPU 中讀出資料非常耗時。
- 算法隻需要 YUV 資料中的 Y 通道，是以讀出所有的資料存在大量的浪費。
-
glReadPixels
正是基于以上原因，在讀取之前需要先進行一次渲染，渲染做了幾件事情：
- 将資料進行裁剪、縮放到目标尺寸。
- 去除 UV 通道，隻保留 Y 通道。
- 将 Y 通道以特定的方式進行排列，以保證
glReadPixels
通過這一次渲染之後，再用
glReadPixels
讀出資料便是僅有 Y 通道且裁剪之後的資料，可以直接輸出給算法進行處理，這兩部分耗時一般在 5-10ms。
算法計算出相機位姿後等待引擎渲染完畢，得到一幀場景幀，再與相機預覽的紋理進行合成得到最終幀。華為和 MTK 的機器大部分搭載的是 Mali 的 GPU，占比大概 40% 左右。
不同機型根據其搭載的 GPU 來配置合适的政策，這樣可以讓覆寫率大幅度提升。但這樣仍然還不夠，還需要配合其它的方式讓覆寫率進一步提升。
并行+緩存
耗時較多的部分在兩處，一處是 GPU 渲染，一處是算法（運作在 CPU 端），而這兩部分并不完全互相依賴，可以通過并行來提升性能。另外，使用多級 FBO 來緩存多幀相機幀，并緩存 YUV 資料也可以提升一部分的性能 。但注意一點，過多的 FBO 緩存也有圖形記憶體開銷和二次渲染開銷。一般來說最多二級，視配置而定。
通過這兩步處理之後，整體的算法可以達到 75% 以上，并且保持 22fps 的幀率。下圖是完整的政策：
降級算法
在成千上萬的 Android 機器面前，75% 的覆寫率對于這樣一種耗時的算法來說已經較高，但仍然有大量的機器無法覆寫。是以為了保證剩下這一部分使用者也能觸達，我們通過算法降級來達到更高的覆寫率，如這裡根據陀螺儀計算出相機的角度，放棄最後的幀資料同步等，最終可以使整體覆寫率達到 99% 以上，當然這是以犧牲部分體驗為代價了。
xMedia 應用場景
最後，除了在支付寶新春掃五福以外，我們将應用場景歸納為以下四類：
- 智能互動
- 智能服務
- 智能推理
- 風控安全
智能推理主要用于支付寶中小程式智能預加載，首頁腰封推薦等；風控安全包含内容安全檢測、視訊鑒黃等。目前我們先簡單介紹前兩類應用場景：
「智能互動」
智能互動是利用算法與使用者進行互動，主要用于 AR 中，利用 AR 來替代傳統的觸摸互動，帶來完全不同的體驗。比如前面提到的 AR 掃福與小雞操就是這類場景，小雞操可以在
支付寶-螞蟻莊園-運動會-手保健操
中體驗。
覆寫率中描述的螞蟻森林的 AR 看樹活動，可以通過下面的方式進行體驗。
另外一個基于頭部的互動是頸保健操，可以從
支付寶-小目标-頸保健操
進行體驗，适合辦公室人群，每天給自己定個目标鍛煉頸椎，緩解疲勞。
上面這些互動方式均采用 AR/AI，體驗與傳統的互動方式有很大的不同。
「智能服務」
第二類是智能服務類，主要是垂直場景的應用，與支付寶業務緊密關聯的，比如銀行卡 OCR 識别、身份證 OCR、理賠寶等，可以通過下面幾個視訊來體驗，不再一一贅述。端上的識别具有識别準确率高、速度快、模型等特點，很多垂直場景在支付寶小程式中也已經開放。
如何體驗支付寶端上智能化能力？
目前，xMedia 在 mPaaS 中已得到相應的落地應用。基于 App 端與小程式場景的關聯，實作“資料計算分析+分析決策引擎+mPaaS 場景”的智能化分析及營運能力。
除此之外，借助如智能創意文案、智能分流、智能投放、AB 實驗等能力，形成全面自動化的營銷流程，真正提升營銷自動化水準。
同時歡迎大家使用釘釘搜尋群号“23124039”加入 mPaaS 技術交流群，期待與你交流。