作為一款VR實(shí)時(shí)操作游戲App，我們需要根據(jù)重力感應(yīng)系統(tǒng)，實(shí)時(shí)監(jiān)控手機(jī)的角度，并渲染出相應(yīng)位置的VR圖像，因此在不同 Android 設(shè)備之間，由于使用的芯片組和不同架構(gòu)的GPU，游戲性能會(huì)因此受到影響。舉例來說：游戲在 Galaxy S20+ 上可能以 60fps 的速度渲染，但它在HUAWEI P50 Pro上的表現(xiàn)可能與前者大相徑庭。 由于新版本的手機(jī)具有良好的配置，而游戲需要考慮基于底層硬件的運(yùn)行情況。
如果玩家遇到幀速率下降或加載時(shí)間變慢，他們很快就會(huì)對(duì)游戲失去興趣。如果游戲耗盡電池電量或設(shè)備過熱，我們也會(huì)流失處于長途旅行中的游戲玩家。如果提前預(yù)渲染不必要的游戲素材，會(huì)大大增加游戲的啟動(dòng)時(shí)間，導(dǎo)致玩家失去耐心。如果幀率和手機(jī)不能適配，在運(yùn)行時(shí)會(huì)由于手機(jī)自我保護(hù)機(jī)制造成閃退，帶來極差的游戲體驗(yàn)。
基于此，我們需要對(duì)代碼進(jìn)行優(yōu)化以適配市場(chǎng)上不同手機(jī)的不同幀率運(yùn)行。
所遇到的挑戰(zhàn)
首先我們使用Streamline 獲取在 Android 設(shè)備上運(yùn)行的游戲的配置文件，在運(yùn)行測(cè)試場(chǎng)景時(shí)將 CPU 和 GPU性能計(jì)數(shù)器活動(dòng)可視化，以準(zhǔn)確了解設(shè)備處理 CPU 和 GPU 工作負(fù)載，從而去定位幀速率下降的主要問題。
以下的幀率分析圖表顯示了應(yīng)用程序如何隨時(shí)間運(yùn)行。
在下面的圖中，我們可以看到執(zhí)行引擎周期與 FPS 下降之間的相關(guān)性。顯然GPU 正忙于算術(shù)運(yùn)算，并且著色器可能過于復(fù)雜。
為了測(cè)試在不同設(shè)備中的幀率情況，使用友盟+U-APM測(cè)試不同機(jī)型上的卡頓狀況，發(fā)現(xiàn)在onSurfaceCreated函數(shù)中進(jìn)行渲染時(shí)出現(xiàn)卡頓， 應(yīng)證了前文的分析，可以確定GPU是在算數(shù)運(yùn)算過程中發(fā)生了卡頓：
因?yàn)椴煌O(shè)備有不同的性能預(yù)期，所以需要為每個(gè)設(shè)備設(shè)置自己的性能預(yù)算。例如，已知設(shè)備中 GPU 的最高頻率，并且提供目標(biāo)幀速率，則可以計(jì)算每幀 GPU 成本的絕對(duì)限制。
數(shù)學(xué)公式: $ 每幀 GPU 成本 = GPU 最高頻率 / 目標(biāo)幀率 $
CPU 到 GPU 的調(diào)度存在一定的約束，由于調(diào)度上存在限制所以我們無法達(dá)到目標(biāo)幀率。另外，由于 CPU-GPU 接口上的工作負(fù)載序列化，渲染過程是異步進(jìn)行的。CPU 將新的渲染工作放入隊(duì)列，稍后由 GPU 處理。
數(shù)據(jù)資源問題
CPU 控制渲染過程并且實(shí)時(shí)提供最新的數(shù)據(jù)，例如每一幀的變換和燈光位置。然而，GPU 處理是異步的。這意味著數(shù)據(jù)資源會(huì)被排隊(duì)的命令引用，并在命令流中停留一段時(shí)間。而程序中的OpenGL ES 需要渲染以反映進(jìn)行繪制調(diào)用時(shí)資源的狀態(tài)，因此在引用它們的 GPU 工作負(fù)載完成之前無法修改資源。
調(diào)試過程
我們?cè)龀鰢L試，對(duì)引用資源進(jìn)行代碼上的編輯優(yōu)化，然而當(dāng)我們嘗試修改這部分內(nèi)容時(shí)，會(huì)觸發(fā)該部分的新副本的創(chuàng)建。這將能夠一定程度上實(shí)現(xiàn)我們的目標(biāo)，但是會(huì)產(chǎn)生大量的 CPU 開銷。
于是我們使用Streamline查明高 CPU 負(fù)載的實(shí)例。在圖形驅(qū)動(dòng)程序內(nèi)部libGLES_Mali.so路徑函數(shù), 視圖中看到極高的占用時(shí)間。
由于我們希望在不同手機(jī)上適配不同幀率運(yùn)行，所以需要查明libGLES_Mali.so是否在不同機(jī)型的設(shè)備上都產(chǎn)生了極高的占用時(shí)間，此處采用了友盟+U-APM來檢測(cè)用戶在不同機(jī)型上的函數(shù)占用比例。
經(jīng)友盟+ U-APM自定義異常測(cè)試，下列機(jī)型會(huì)產(chǎn)生高libGLES_Mali.so占用的問題，因此我們需要基于底層硬件的運(yùn)行情況來解決流暢性問題，同時(shí)由于存在問題的機(jī)型不止一種，我們需要從內(nèi)存層面著手，考慮如何調(diào)用較少的內(nèi)存緩存區(qū)并及時(shí)釋放內(nèi)存。
解決方案及優(yōu)化
基于前文的分析，我們首先嘗試從緩沖區(qū)入手進(jìn)行優(yōu)化。單緩沖區(qū)方案• 使用glMapBufferRange和GL_MAP_UNSYNCHRONIZED.然后使用單個(gè)緩沖區(qū)內(nèi)的子區(qū)域構(gòu)建旋轉(zhuǎn)。這避免了對(duì)多個(gè)緩沖區(qū)的需求，但是這一方案仍然存在一些問題，我們?nèi)孕枰幚砉芾碜訁^(qū)域依賴項(xiàng)，這一部分的代碼給我們帶來了額外的工作量。多緩沖區(qū)方案• 我們嘗試在系統(tǒng)中創(chuàng)建多個(gè)緩沖區(qū)，并以循環(huán)方式使用緩沖區(qū)。通過計(jì)算我們得到了適合的緩沖區(qū)的數(shù)目，在之后的幀中，代碼可以去重新使用這些循環(huán)緩沖區(qū)。由于我們使用了大量的循環(huán)緩沖區(qū)，那么大量的日志記錄和數(shù)據(jù)庫寫入是非常有必要的。但是有幾個(gè)因素會(huì)導(dǎo)致此處的性能不佳：１. 產(chǎn)生了額外的內(nèi)存使用和GC壓力２. Android 操作系統(tǒng)實(shí)際上是將日志消息寫入日志而并非文件，這需要額外的時(shí)間。３. 如果只有一次調(diào)用，那么這里的性能消耗微乎其微。但是由于使用了循環(huán)緩沖區(qū)，所以這里需要用到多次調(diào)用。我們會(huì)在基于c#中的 Mono 分析器中啟用內(nèi)存分配跟蹤函數(shù)用于定位問題：
$ adb shell setprop debug.mono.profile log:calls,alloc
我們可以看到該方法在每次調(diào)用時(shí)都花費(fèi)時(shí)間：
Method call summary Total(ms) Self(ms) Calls Method name 782 5 100 MyApp.MainActivity:Log (string,object[]) 775 3 100 Android.Util.Log:Debug (string,string,object[]) 634 10 100 Android.Util.Log:Debug (string,string)
在這里定位到我們的日志記錄花費(fèi)了大量時(shí)間，我們的下一步方向可能需要改進(jìn)單個(gè)調(diào)用，或者尋求全新的解決方案。
log:alloc還讓我們看到內(nèi)存分配；日志調(diào)用直接導(dǎo)致了大量的不合理內(nèi)存分配：
Allocation summary Bytes Count Average Type name 41784 839 49 System.String 4280 144 29 System.Object[]
硬件加速
最后嘗試引入硬件加速，獲得了一個(gè)新的繪圖模型來將應(yīng)用程序渲染到屏幕上。它引入了 DisplayList 結(jié)構(gòu)并且記錄視圖的繪圖命令以加快渲染速度。
同時(shí)，可以將 View 渲染到屏幕外緩沖區(qū)并隨心所欲地修改它而不用擔(dān)心被引用的問題。此功能主要適用于動(dòng)畫，非常適合解決我們的幀率問題,可以更快地為復(fù)雜的視圖設(shè)置動(dòng)畫。
如果沒有圖層，在更改動(dòng)畫屬性后，動(dòng)畫視圖將使其無效。對(duì)于復(fù)雜的視圖，這種失效會(huì)傳播到所有的子視圖，它們反過來會(huì)重繪自己。
在使用由硬件支持的視圖層后，GPU 會(huì)為視圖創(chuàng)建紋理。因此我們可以在我們的屏幕上為復(fù)雜的視圖設(shè)置動(dòng)畫，并且使動(dòng)畫更加流暢。
代碼示例：
// Using the Object animator view.setLayerType(View.LAYER_TYPE_HARDWARE, null); ObjectAnimator objectAnimator = ObjectAnimator.ofFloat(view, View.TRANSLATION_X, 20f); objectAnimator.addListener(new AnimatorListenerAdapter() { @Override public void onAnimationEnd(Animator animation) { view.setLayerType(View.LAYER_TYPE_NONE, null); } }); objectAnimator.start(); // Using the Property animator view.animate().translationX(20f).withLayer().start();
另外還有幾點(diǎn)在使用硬件層中仍需注意：
（1）在使用之后進(jìn)行清理:
硬件層會(huì)占用GPU上的空間。在上面的 ObjectAnimator代碼中，偵聽器會(huì)在動(dòng)畫結(jié)束時(shí)移除圖層。在 Property animator 示例中，withLayers() 方法會(huì)在開始時(shí)自動(dòng)創(chuàng)建圖層并在動(dòng)畫結(jié)束時(shí)將其刪除。
（2）需要將硬件層更新可視化：
使用開發(fā)人員選項(xiàng)，可以啟用“顯示硬件層更新”。如果在應(yīng)用硬件層后更改視圖，它將使硬件層無效并將視圖重新渲染到該屏幕外緩沖區(qū)。
硬件加速優(yōu)化
但是由此帶來了一個(gè)問題是，在不需要快速渲染的界面，比如滾動(dòng)欄, 硬件層也會(huì)更快地渲染它們。當(dāng)將 ViewPager 滾動(dòng)到兩側(cè)時(shí)，它的頁面在整個(gè)滾動(dòng)階段會(huì)以綠色突出顯示。
因此當(dāng)我滾動(dòng) ViewPager 時(shí)，我使用 DDMS 運(yùn)行 TraceView，按名稱對(duì)方法調(diào)用進(jìn)行排序，搜索“android/view/View.setLayerType”，然后跟蹤它的引用:
ViewPager#enableLayers(): private void enableLayers(boolean enable) { final int childCount = getChildCount(); for (int i = 0; i < childCount; i++) { final int layerType = enable ? ViewCompat.LAYER_TYPE_HARDWARE : ViewCompat.LAYER_TYPE_NONE; ViewCompat.setLayerType(getChildAt(i), layerType, null); } }
該方法負(fù)責(zé)為 ViewPager 的孩子啟用/禁用硬件層。它從 ViewPaper#setScrollState() 調(diào)用一次：
private void setScrollState(int newState) { if (mScrollState == newState) { return; } mScrollState = newState; if (mPageTransformer != null) { enableLayers(newState != SCROLL_STATE_IDLE); } if (mOnPageChangeListener != null) { mOnPageChangeListener.onPageScrollStateChanged(newState); } }
正如代碼中所示，當(dāng)滾動(dòng)狀態(tài)為 IDLE 時(shí)硬件被禁用，否則在 DRAGGING 或 SETTLING 時(shí)啟用。PageTransformer 旨在“使用動(dòng)畫屬性將自定義轉(zhuǎn)換應(yīng)用于頁面視圖”（Source）。
基于我們的需求，只在渲染動(dòng)畫的時(shí)候啟用硬件層，所以我想覆蓋ViewPager 方法，但由于它們是私有的，我們無法修改這個(gè)方法。
所以我采取了另外的解決方案：在 ViewPage#setScrollState() 上，在調(diào)用 enableLayers() 之后，我們還會(huì)調(diào)用 OnPageChangeListener#onPageScrollStateChanged()。所以我設(shè)置了一個(gè)監(jiān)聽器，當(dāng) ViewPager 的滾動(dòng)狀態(tài)不同于 IDLE 時(shí)，它將所有 ViewPager 的孩子的圖層類型重置為 NONE：
@Override public void onPageScrollStateChanged(int scrollState) { // A small hack to remove the HW layer that the viewpager add to each page when scrolling. if (scrollState != ViewPager.SCROLL_STATE_IDLE) { final int childCount = <your_viewpager>.getChildCount(); for (int i = 0; i < childCount; i++) <your_viewpager>.getChildAt(i).setLayerType(View.LAYER_TYPE_NONE, null); } }
這樣，在 ViewPager#setScrollState() 為頁面設(shè)置了一個(gè)硬件層之后——我將它們重新設(shè)置為 NONE，這將禁用硬件層，因此而導(dǎo)致的幀率區(qū)別主要顯示在 Nexus上。
