在移動手機端VR應用需要更多的組件支持。首先是傳感器能夠跟蹤記錄用戶頭部的運動，CPU驅動VR應用程序（大多都是在后臺運行），GPU負責處理和計算來生成正確的顯示圖像，向用戶或觀察者呈現變換后的內容。

所有這些組件需要密切協作才能給用戶提供逼真的使用體驗。眾所周知都會有一定延遲時間，這段時間被命名為“motion to photon latency”（即從用戶運動開始到相應畫面顯示到屏幕上所花的時間）。盡管它是一個專業術語，但是卻很好的描述了問題：伴隨用戶頭部的運動，VR設備何時能夠意識到并給用戶展示正確的場景。

在真實世界中，這種情形很普遍以至于我們都沒有意識到——否則我們就會經常走路撞墻了。然而將一個手機掛在頭部前端顯示VR場景，想要達到同樣的效果是非常困難的。原因有很多種：計算機運行的時鐘頻率是固定的，流水線采用串行處理數據，最明顯的就是最終圖像渲染花費的時間。

我們作為一個GPU IP研發公司，當然非常有興趣優化我們的顯卡處理流水線以降低延遲，減少PowerVR顯卡處理器渲染最終顯示圖像所耗費的時間。

對于Android系統和設備的組件要求

最終在安卓屏幕上顯示的內容要采用組件的形式完成渲染。通常會有幾個廠家自定義符合自己要求的圖像，它們有自己的系統UI（顯示狀態欄和導航欄等）和前臺應用程序（在設置的緩沖區中完成圖像的渲染）。

這些緩沖區會被一個“消費者”線程所占用并且會直接反應在屏幕的顯示效果上，大多數情況下在一個系統級應用中這個“消費者”線程通常被稱為SurfaceFlinger服務。

如果硬件支持SurfaceFlinger就可以決定將這些緩沖區中渲染的圖像直接在屏幕上顯示（以正確的組織布局）。這個模式被稱為硬件組件而且需要硬件顯示設備的直接支持。如果硬件顯示上不支持這個組織布局，SurfaceFlinger服務會采用一個幀緩沖器，利用GPU完成所有圖像的渲染并保存在幀緩沖器中，最后像正常情況一樣在顯示器上完成圖像組件的展示。

生成者線程和消費者線程都是相互高度獨立的——實際上他們是不同的進程，采用跨進程的方式實現數據通信。現在如果一方出現錯誤，就會出現混亂和意想不到的問題。

舉個例子生產者對一個正在向用戶顯示的幀緩沖區進行渲染操作，那么用戶就會產生視覺沖突，這種情況稱為“撕裂”效應。屏幕上的圖像一半是過時的內容，而另一部分是重新經過渲染的圖像。“撕裂”效應很容易判別，因為屏幕上會有明顯的切割線。

一個簡單的動畫展示“撕裂”效應

為了防止“撕裂”效應，有兩個關鍵因素是必須的。首先就是各部分之間要保證適當的同步，其次就是采用雙緩沖技術。

同步操作可以采用安卓“Native Syncs”框架來實現，這個框架的一些標準和規范讓它能夠應用于安卓系統，它們借助內核空間來實現系統全局同步，在用戶模式下使用文件描述符可以實現不同進程間的數據共享。

它們也是非復用的二進制同步機制，僅有“無信號”和“有信號”兩個狀態，并且只有一種狀態的轉換就是從“無信號”到“有信號”（狀態是不可逆的）。

雙緩沖技術可以實現在舊的圖像內容正在被消費者線程所占用的同時，生產者可以渲染新的圖像內容。當生產者完成渲染操作，兩個緩沖區就會被轉換，消費者則調用最新渲染的圖像內容，與此同時生產者則開始渲染剛剛還在被消費者線程調用的圖像內容。

上面這兩種機制都是必須的，這樣才能在安卓系統上實現流暢的圖像輸出，但是不幸的是這仍然還有額外的延遲花銷。

就在三月份Khronos Group組織發布了“KHR可變的渲染緩沖器EGL擴展”規范，我們利用這個規范實現了上述單緩沖器渲染功能。

這個擴展標準需要GPU驅動和安卓操作系統的支持，正如我之前解釋的那樣，安卓系統很長時間一直都組織這種模式的操作，因為這樣會產生圖像“撕裂”效應。

那么當我們使用新的單緩沖器技術模式時如何組織“撕裂”效應的發生呢？

屏幕技術

回答這個問題之前我們需要了解一下顯示器是如何工作的。GPU驅動會向顯示器驅動推送一個幀緩沖數據包，采用的數據格式是顯示器能夠解析的。這就可能對幀緩沖數據格式有不同的要求，例如特殊的形變或者紋理對齊。

顯示器會在下一畫面顯示新的幀緩沖圖像，假設顯示器從頂部到底部刷新新的圖像，“beam（刷新分割線）”又從顯示器屏幕底部返回到頂部，“vsync”或者垂直同步能夠及時的實現就比較關鍵了。