京東小程式是一個開放技術平臺，正在被越來越多的頭部品牌選擇，用於站內私域流量的營銷和運營。諸如各種日化、奢侈品等品牌對ARVR有較多的訴求，希望京東小程式引擎提供一些底層能力，疊加品牌自主的個性化開發和定製，以支持更加豐富的場景和玩法，比如AR試妝、試戴等。 ...
作者：京東零售 戴旭
京東小程式是一個開放技術平臺，正在被越來越多的頭部品牌選擇，用於站內私域流量的營銷和運營。諸如各種日化、奢侈品等品牌對ARVR有較多的訴求，希望京東小程式引擎提供一些底層能力，疊加品牌自主的個性化開發和定製，以支持更加豐富的場景和玩法，比如AR試妝、試戴等。
我們小程式引擎聯合ARVR團隊，在雙方產研測的努力和協作下，完成了相關能力的設計和開發。整體功能於京東APP11.6.6版本發佈上線，期待為更多的商家和品牌賦能。
體驗路徑和效果（負責相關模塊的產品小姐姐友情錄屏）
技術方案
這裡以人臉識別為例，先介紹整體的技術方案。
概念介紹
技術關鍵詞：相機、實時幀、AR演算法、同層渲染、WebGL。
這幾個關鍵詞裡面，前三個比較好理解，人臉識別，會用相機採集人臉的實時幀數據，調用AR演算法，獲取計算結果，把數據傳輸給小程式前端。
後面兩個關鍵詞和小程式的場景有關係，WebGL技術是小程式為了支持游戲、ARVR等高性能渲染的需求，採用原生的OpenGL實現了一套WebGL的介面。小程式頁面是WebView渲染，而我們既然提到了採用OpenGL原生渲染，就需要把原生組件，正確的插入到Web的視圖層級，同層渲染就是將原生組件和WebView DOM 元素放在一起進行混合渲染的技術，能夠保證原生組件和 DOM 元素在渲染層級、滾動、觸摸事件處理等方面保持一致。
總體流程
小程式引擎在底層原生支持了相機、實時幀、AR、WebGL等能力，同時暴露了若幹 js 的api。小程式開發者通過相關api的調用，執行開啟相機、獲取實時幀數據，調用AR介面，獲取計算結果數據，進行WebGL渲染等操作。簡要的流程如下：
分層設計
從分層的角度看整個技術方案的設計，大致如下：
其中在AR引擎這一層，分為內置和外部AR引擎，也是由於小程式本身是開放的技術平臺，我們採用了介面協議化的設計，支持第三方宿主採用自主的AR引擎，同時提供了相機、實時幀、WebGL等原子化能力，小程式服務商可以構建專有的AR引擎為上層業務賦能。
技術挑戰
WebGL技術原理的篇幅過大，它也不僅僅是為了ARVR這個場景服務，所以包括AR演算法之內，都不在本篇的詳細介紹範圍之內。
在這部分，我們專註於小程式和ARVR疊加的領域：記憶體和幀率的優化。
我們知道在欣賞電視和電影畫面時，只要畫面刷新率達到24幀/秒，就能滿足人們的需求，也就是說我們至少要在中端甚至中低端的機器上達到24幀以上的幀率。
為了保證基本的畫質，相機實時幀的解析度設置為1280*720，以RBGA格式存儲，那麼每一幀的數據是1280*720*4=3686400Byte，約3.5MB，每秒24幀以上的幀率，這個是不小的數據量。總的來說，在性能優化上，我們遇到的主要挑戰如下：
挑戰1，數據從原生傳輸到js，在從js傳遞到原生，如此大的數據量將會成為js和原生通信的瓶頸；
挑戰2，在iOS平臺上，相機output只能指定BGRA格式，因為原始相機實時幀 CMSampleBufferRef對象內包含CVPixelBuffer對象，CoreVideo對象不支持RGBA格式，參考官方文檔
https://developer.apple.com/library/archive/qa/qa1501/_index.html
而WebGL標準的介面不支持BGRA格式，參考文檔：
https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/texImage2D，數據格式的轉換會加重性能的負擔；
挑戰3，即便以24幀為標準，每一幀的處理時間大約只有41ms，需要經歷原生相機生產、數據格式轉換、數據雙向傳輸、ar演算法、webgl繪製等流程，每一環節都很重，我們需要考慮如何利用併發調度優勢，並且保證實時幀的時序不會發生錯亂，因為時序一旦亂了，影像雖然一直在輸出，但是視覺感受是混亂的。
針對上述挑戰，進行了一系列的優化，最終在中低端手機（iPhone8 Plus）上達到平均26~27幀的幀率，整體體驗較為流暢，具體調優下麵詳細介紹。
性能調優
1、數據傳輸優化
原生和js之間傳輸大量的數據會成為性能的瓶頸，數據傳輸優化就是減少數據傳輸頻次，最好是數據保留一份，只傳遞數據的標記。
我們設計了一個NativeBuffer緩存來優化這個問題。主要流程如下
但是在js環境中，最終還是要使用js對象，原生相機實時幀的數據需要被轉換為js對象。那麼如何做才能讓數據只保留一份呢？
NO COPY
iOS端選擇運行小程式的js框架是JavaScriptCore，JavaScriptCore提供了一些C語言的介面方法，可以以NO COPY的方式，把一個void類型的二進位數據指針作為backing store，創建相對應的js對象，一般類型是ArrayBuffer或者TypeArray。也就是說原生和js對象背後的數據是同一份，共用這部分記憶體。
這樣一來我們只需要保證緩存的原始相機實時幀的數據不釋放，那麼js對象引用的這部分數據就會一直有效。那這部分數據要在什麼時候去清理呢？
銷毀
在創建js對象的時候，可以指定一個C的函數指針作為入參。當JavaScriptCore檢測到這個js對象銷毀的時候，會自動觸發該C函數的調用。我們需要按照指定的函數原型實現一個C的方法，在這個函數里去做緩存的清理，可以看一下這個函數的原型：
typedef void (*JSTypedArrayBytesDeallocator)(void* bytes, void* deallocatorContext);
該函數有2個參數，第一個bytes是原始相機實時幀的二進位數據，第二個是上下文環境，這裡我們傳的是NativeBuffer管理類的實例，在這個函數的具體實現中，我們去匹配NativeBuffer管理的緩存地址，找到相關數據進行清理。
寫入優化
前面我們說過，數據流轉是雙向的。原生把相機的數據傳輸到js側，js調用ARVR的人臉檢測介面，還需要把這份數據在傳輸到原生。因為相機和人臉檢測是相互獨立的介面，js拿到相機數據不一定非要調用人臉檢測，調用人臉檢測的數據也不一定非要來自於相機，還可以是一個本地的圖片。
相對應的，我們在NativeBuffer的設計中，提供數據雙向傳遞的介面，getNativeBuffer：id和setNativeBuffer：id。在原生傳遞到js的數據中，我們用了NO Copy的方式去做優化，那麼在js傳遞到原生的數據，由於我們不知道數據來源，所以需要開闢一份新的記憶體空間，調用memcpy複製數據。但是實際上，我們在做數據複製之前，可以用JavaScriptCore提供的介面，從js的ArrayBuffer對象中提取到真實數據的記憶體地址，然後在NativeBuffer緩存池中查找，如果找到了則無需再做數據複製。這樣保證了數據始終只有一份。
數據類型
在實踐的過程中，js端在選擇二進位對象的數據類型的時候，可能會用ArrayBuffer或者TypeArray。一旦js端進行了數據類型轉換，比如ArrayBuffer轉TypeArray，引擎在調用setNativeBuffer的時候，傳遞的是轉換後的數據類型，將會導致setNativeBuffer內部的寫入優化失效，進而在低端機上帶來明顯的卡頓。在這裡，我們統一使用一致的數據類型，不能隨意的轉換數據類型。
2、相機實時幀格式轉換
在技術挑戰中我們提到，iOS平臺上，相機output只能指定為BGRA格式，而WebGL標準的介面不支持該格式。如果不進行格式轉換，會導致紅藍顏色顛倒，紅色物體呈現藍色，藍色物體呈現紅色。所以在數據緩存和傳輸之前，要做格式轉換，我們需要找到一個快速低成本的方法。
要想做數據格式轉換，需要瞭解一些基本的圖像數據在記憶體中的佈局情況，如下圖所示。
這裡我們選取的BGRA和RGBA格式都是32位，也就是每一個像素點是4個位元組。
真實圖像數據由於記憶體對齊的原因，大小並不一定是width*height*4個位元組，CoreVideo框架提供了獲取相機數據寬高的方法，我們要計算出待處理的位元組大小，每4個位元組做一次迴圈，把第一位和第三位做一個調換，就能無需malloc記憶體，把BGRA轉換為RGBA格式。
3、併發調度
在技術挑戰中還提到，每一幀的處理時間大約只有41ms，需要經歷原生相機生產、數據格式轉換、數據雙向傳輸、ar演算法、webgl繪製等這麼多流程，如何利用併發優勢，並且保證實時幀的時序不會發生錯亂呢？
我們為了保證UI主線程的流暢，要儘可能把更多的環節放到子線程執行，這個時候哪怕寫入緩存這樣一個輕量的操作放到主線程都可能會帶來畫面的卡頓。
實時幀的處理、AR演算法分別放在不同的線程，為了保證實時幀時序，均採用串列隊列。
採用了多線程之後，NativeBuffer數據的存儲和清理需要加上線程安全保護。
這樣整體利用了多核的優勢，並保證了調用時序。線程調度和處理流轉如下圖所示：
4、資源管理
理想情況下，原生相機產生一個實時幀數據，JS消耗一個，在中高端機器上，性能能夠滿足需求，整體表現較為平穩，但是在低端機器中，線程搶占非常頻繁，當主線程和子線程發生線程搶占的時候，會導致供需不匹配，一旦實時幀數據消耗不及時，記憶體會產生爆炸式的增長，所以需要限定緩存池的容量，這個一般可以根據實際調試的情況指定一個數值即可。
還有一旦出現記憶體警告或者當緩存滿的時候，需要去清理緩存池，buffer如果正在被使用，就不能去清理，否則可能會出現白屏的現象，我們給buffer加了一個是否被消費的標記，當一個buffer被消費後，它不能以常規的方式清理，需要等待js消費完成之後清理，這個在上面也有介紹。
在頁面退出的時候，引擎需要監聽相關的事情，確保實時幀的監聽被停止，否則會出現多個js相機的監聽事件並存，一個數據被多次消費而引發異常。
結語
京東小程式致力於打造卓越的技術開放平臺，我們在提升性能、用戶體驗上不斷努力，我們也在建設和完善小程式的各種能力，歡迎大家提供寶貴的建議。
