一、提升效能核心要素 

1、將OPENGL 介面進行穿透呼叫，下面對opengl穿透做個小結

2、在arm開發板上開啟kvm特性，這個qcom&mtk都是實現了的，只需要開啟開關即可

二、ANDROID OPENGL 業務實現細節解釋

1、  OPENGL命令佇列是確定了，可是命令的引數，有的是系統給的，有的是上一個命令計算的結果，例如紋理操作，首先呼叫API建立一個紋理，得到紋理標記，然後後面再使用API操作該紋理時，就是使用這個紋理標記的。因此如果遇到這個建立紋理的API，則要把以前積累的API佇列傳到host端，依次執行，最後得到這個API的結果，然後回傳，這個過程是迴圈執行，直到遇到最終

2、  OPENGL命令佇列有時候根據一個API的結果會有變化的，APP的四個繪製過程只是把系統給的引數計算完，如果遇到需要API計算引數的，同樣會先把積壓的API計算完，然後根據結果選擇分支路徑。所以ANDROID系統的那四個過程並不是完全獨立的，它們之間有一些重疊。最好的APP，就要把這種重疊降低到最少。APP想要執行效率高，就是要非常利索的一次生成命令佇列，減少打斷。

三、opengl 遠端呼叫技術小結。

A：業務層面

1、  本來是一幀的命令佇列一次性傳遞，但由於有打斷，所以實際情況是一幀的命令佇列分批傳遞。

2、  一些特殊的

3、  一些特殊的API會由於業務約束被分解為數個API進行遠端呼叫，這個情況會在opengl 1.0中非常常見，後續的版本則會少一些。

4、  API1.0 = 271 API2.0=208 EGLAPI=43 遠端呼叫API=25 總共547個介面，只熟悉其中核心的43+25+50？+50？來個介面，生僻或者看名字就知道幹啥的就沒有細細研究。

B：技術層面

1、  每個API中通過包裝API標記、引數，得到位元組序列，寫入PIPE驅動。

2、  由於

3、  QEMU得到地址後，經過地址轉換，獲得遠端資料，也是分批寫入socket的。

4、  OPENGL THREAD也會分幾次接收到遠端資料，解析得到API標記和引數。

5、  依次根據API標記呼叫API。

6、  得到結果後由OPENGL THREAD寫入socket。

7、  QEMU從socket得到結果，經過地址轉換，將數值寫入相關記憶體區域。

8、  VM讀PIPE驅動得到結果後，一次遠端呼叫結束。（其中VM讀PIPE驅動和OPENGL THREAD 執行是並行執行的）

C：效能層面

1、  普通應用一幀的耗時在10-30毫秒，特殊應用一幀的耗時就非常差了。

2、  一次遠端呼叫的耗時在3571.9微秒，去掉OPENGL API執行時間耗時在2367.8微秒。

D：優化層面

1、  業務方面：檢查每個API是否有無效操作，去掉無效操作，應該能大幅提升效能。

2、  技術方面：去掉socket技術，去掉一個程序，將OPENGL THREAD合進QEMU，應該能較小的提升效能。

*我的github有原始碼，2016年初完成的，貢獻給社群，效能比Android真機差一點，15MS左右的延遲

很多朋友私信問效能怎麼樣

1、操作桌面、一般的app都是比較流暢的

2、操作複雜的遊戲APP比較卡，會出現丟幀現象

3、使用gfxinfo工具檢測效能，會看見15～20MS的延遲每一幀

很多朋友私信問有沒有完成過程

1、需要實體機的程式碼，調通kvm特性

2、下載google android原始碼，最好是android 5.0 ，因為我只在那上面試過，這份程式碼是vm android，核心使用goldfish版本

3、將qemu交叉編譯到實體機上，嘗試跑通android 虛擬機器，這個過程有很多BUG要解，耐心點，最好使用我提供的qemu版本，我在那上面解過BUG，且我的qemu是從標準qemu分支拉出來的，最重要的我這個qemu能穿透opengl介面，有GPU虛擬化方案和input虛擬化辦法，並沒有使用android模擬器的qemu，你們可以試一試android的qemu

4、將我提供的OpenglRender編出來，執行在實體機中，它通過socket與qemu通訊，執行一系列的opengl操作，並將虛擬機器顯示在一張surface中，最終虛擬機器介面會出現在實體機中

5、對android比較熟悉的人，會很快實現的，當時我實現這個的時候對android一竅不通，一步一步的摸索

6、android虛擬機器雙系統論文地址http://systems.cs.columbia.edu/projects/kvm-arm/

   各種裝置虛擬化理論http://www.virtualopensystems.com/