一、提升性能核心要素?

?

1、將OPENGL 接口進(jìn)行穿透調(diào)用，下面對(duì)opengl穿透做個(gè)小結(jié)

2、在arm開發(fā)板上打開kvm特性，這個(gè)qcom&mtk都是實(shí)現(xiàn)了的，只需要打開開關(guān)即可

?

二、ANDROID OPENGL 業(yè)務(wù)實(shí)現(xiàn)細(xì)節(jié)解釋

?

1、 ?OPENGL命令隊(duì)列是確定了，可是命令的參數(shù)，有的是系統(tǒng)給的，有的是上一個(gè)命令計(jì)算的結(jié)果，例如紋理操作，首先調(diào)用API創(chuàng)建一個(gè)紋理，得到紋理標(biāo)記，然后后面再使用API操作該紋理時(shí)，就是使用這個(gè)紋理標(biāo)記的。因此如果遇到這個(gè)創(chuàng)建紋理的API，則要把以前積累的API隊(duì)列傳到host端，依次執(zhí)行，最后得到這個(gè)API的結(jié)果，然后回傳，這個(gè)過程是循環(huán)執(zhí)行，直到遇到最終API后，把剩余的API隊(duì)列傳到HOST端，這一幀才算完。

2、 ?OPENGL命令隊(duì)列有時(shí)候根據(jù)一個(gè)API的結(jié)果會(huì)有變化的，APP的四個(gè)繪制過程只是把系統(tǒng)給的參數(shù)計(jì)算完，如果遇到需要API計(jì)算參數(shù)的，同樣會(huì)先把積壓的API計(jì)算完，然后根據(jù)結(jié)果選擇分支路徑。所以ANDROID系統(tǒng)的那四個(gè)過程并不是完全獨(dú)立的，它們之間有一些重疊。最好的APP，就要把這種重疊降低到最少。APP想要運(yùn)行效率高，就是要非常利索的一次生成命令隊(duì)列，減少打斷。

?

三、opengl 遠(yuǎn)程調(diào)用技術(shù)小結(jié)。

A：業(yè)務(wù)層面

1、??本來是一幀的命令隊(duì)列一次性傳遞，但由于有打斷，所以實(shí)際情況是一幀的命令隊(duì)列分批傳遞。

2、??一些特殊的API耗時(shí)比較嚴(yán)重；一些接口并不需要回傳參數(shù)；一些接口是遠(yuǎn)程調(diào)用特有的，例如合成過程都綜合在一個(gè)遠(yuǎn)程“接口”中，后端一遇到這種標(biāo)記就知道要合成了。

3、??一些特殊的API會(huì)由于業(yè)務(wù)約束被分解為數(shù)個(gè)API進(jìn)行遠(yuǎn)程調(diào)用，這個(gè)情況會(huì)在opengl 1.0中非常常見，后續(xù)的版本則會(huì)少一些。

4、??API1.0 = 271 API2.0=208 EGLAPI=43 遠(yuǎn)程調(diào)用API=25?總共547個(gè)接口，只熟悉其中核心的43+25+50？+50？來個(gè)接口，生僻或者看名字就知道干啥的就沒有細(xì)細(xì)研究。

?

B：技術(shù)層面

1、??每個(gè)API中通過包裝API標(biāo)記、參數(shù)，得到字節(jié)序列，寫入PIPE驅(qū)動(dòng)。

2、??由于VM內(nèi)存頁(yè)分配不是連續(xù)的，PIPE驅(qū)動(dòng)會(huì)把遠(yuǎn)程數(shù)據(jù)地址分幾次傳遞給QEMU。

3、??QEMU得到地址后，經(jīng)過地址轉(zhuǎn)換，獲得遠(yuǎn)程數(shù)據(jù)，也是分批寫入socket的。

4、??OPENGL THREAD也會(huì)分幾次接收到遠(yuǎn)程數(shù)據(jù)，解析得到API標(biāo)記和參數(shù)。

5、??依次根據(jù)API標(biāo)記調(diào)用API。

6、??得到結(jié)果后由OPENGL THREAD寫入socket。

7、??QEMU從socket得到結(jié)果，經(jīng)過地址轉(zhuǎn)換，將數(shù)值寫入相關(guān)內(nèi)存區(qū)域。

8、??VM讀PIPE驅(qū)動(dòng)得到結(jié)果后，一次遠(yuǎn)程調(diào)用結(jié)束。（其中VM讀PIPE驅(qū)動(dòng)和OPENGL THREAD 執(zhí)行是并行運(yùn)行的）

?

C：性能層面

1、??普通應(yīng)用一幀的耗時(shí)在10-30毫秒，特殊應(yīng)用一幀的耗時(shí)就非常差了。

2、??一次遠(yuǎn)程調(diào)用的耗時(shí)在3571.9微秒，去掉OPENGL API執(zhí)行時(shí)間耗時(shí)在2367.8微秒。

?

D：優(yōu)化層面

1、??業(yè)務(wù)方面：檢查每個(gè)API是否有無效操作，去掉無效操作，應(yīng)該能大幅提升性能。

2、??技術(shù)方面：去掉socket技術(shù)，去掉一個(gè)進(jìn)程，將OPENGL THREAD合進(jìn)QEMU，應(yīng)該能較小的提升性能。

?

?

?

*我的github有源碼，2016年初完成的，貢獻(xiàn)給社區(qū)，性能比Android真機(jī)差一點(diǎn)，15MS左右的延遲

?

很多朋友私信問性能怎么樣

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

2、操作復(fù)雜的游戲APP比較卡，會(huì)出現(xiàn)丟幀現(xiàn)象

3、使用gfxinfo工具檢測(cè)性能，會(huì)看見15～20MS的延遲每一幀

?

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

1、需要實(shí)體機(jī)的代碼，調(diào)通kvm特性

2、下載google android源碼，最好是android 5.0 ，因?yàn)槲抑辉谀巧厦嬖囘^，這份代碼是vm android，內(nèi)核使用goldfish版本

3、將qemu交叉編譯到實(shí)體機(jī)上，嘗試跑通android 虛擬機(jī)，這個(gè)過程有很多BUG要解，耐心點(diǎn)，最好使用我提供的qemu版本，我在那上面解過BUG，且我的qemu是從標(biāo)準(zhǔn)qemu分支拉出來的，最重要的我這個(gè)qemu能穿透opengl接口，有GPU虛擬化方案和input虛擬化辦法，并沒有使用android模擬器的qemu，你們可以試一試android的qemu

4、將我提供的OpenglRender編出來，運(yùn)行在實(shí)體機(jī)中，它通過socket與qemu通信，執(zhí)行一系列的opengl操作，并將虛擬機(jī)顯示在一張surface中，最終虛擬機(jī)界面會(huì)出現(xiàn)在實(shí)體機(jī)中

5、對(duì)android比較熟悉的人，會(huì)很快實(shí)現(xiàn)的，當(dāng)時(shí)我實(shí)現(xiàn)這個(gè)的時(shí)候?qū)ndroid一竅不通，一步一步的摸索

6、android虛擬機(jī)雙系統(tǒng)論文地址http://systems.cs.columbia.edu/projects/kvm-arm/

???各種設(shè)備虛擬化理論http://www.virtualopensystems.com/
————————————————
版權(quán)聲明：本文為CSDN博主「pppaass」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/pppaass/article/details/51416694

總結(jié)

以上是生活随笔為你收集整理的QEMU KVM 虚拟机移植之性能提高篇小结（android 虚拟机双系统方案）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。