作者：京東零售 戴旭

京東小程式是一個開放技術平臺，正在被越來越多的頭部品牌選擇，用于站內私域流量的營銷和運營，諸如各種榷訓、奢侈品等品牌對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相機的監聽事件并存，一個資料被多次消費而引發例外，

結語

京東小程式致力于打造卓越的技術開放平臺，我們在提升性能、用戶體驗上不斷努力，我們也在建設和完善小程式的各種能力，歡迎大家提供寶貴的建議，

標籤：其他

上一篇：Android Studio的安裝及環境配置

下一篇：返回列表