无码人妻精一区二区三区,eeuss影院www在线观看,无码精品久久久久久人妻中字,日韩av高清在线看片

測試說明

測試軟件

1. 微信 6.6.3
2. Chrome for Android 64.0.3282.137

測試使用的 Demo 可以通過 GitHub 下載。

測試設(shè)備

小米 Note3，使用驍龍 660，算是這兩年比較主流的中端芯片，雖然性能在高負荷場景下跟旗艦芯片如驍龍 835 還有一定距離，不過大部分場景下也已經(jīng)夠用。

測試環(huán)境

設(shè)備電量在 60% 以上，處于充足狀態(tài)，并使用風扇進行輔助散熱，避免因為電量不足或者過熱導(dǎo)致設(shè)備鎖核降頻，從而引起測試數(shù)據(jù)的波動，無法獲得可以對比的測試結(jié)果。

頁面在 Chrome 上運行在全屏的 WebApp 模式下，如果沒有額外說明，Canvas 的渲染分辨率使用設(shè)備的屏幕分辨率 1080p。

幀率獲取

adb shell "dumpsys SurfaceFlinger --latency 'TARGET_WINDOW_NAME'"

使用上述命令可以獲取目標窗口最近 127 幀的更新時間戳，然后用腳本計算出這 127 幀渲染過程中的平均幀率。

另外代碼中也通過計算 JavaScript 中每幀調(diào)用的次數(shù)和時間間隔來計算幀率，然后通過控制臺打印輸出類似下面的信息，實際驗證兩者的結(jié)果基本一致。

WebGL Aqua framerate:1.55fps, program:44, draw call:118

本文的測試數(shù)據(jù)使用第一種方法。

測試數(shù)據(jù)

WebGL Compute

模擬鳥群的運動，包含大量的物理運動計算，實際上是測試 JavaScript 的計算性能。

可以對 numBoids （guimark3.js）參數(shù)進行修改，改變鳥群的數(shù)量，鳥群數(shù)量越大，JavaScript 計算的耗時就越大。

WebGL Aqua

繪制的場景有一定的復(fù)雜度，包含了約 30 個模型，使用了 44 個 Program，當參數(shù)設(shè)定為 500 條魚時，需要調(diào)用 600 多個 Draw Call（不使用 Instance Rendering 的情況下）。

可以配置的參數(shù)如下：

1. fishSetting 可以修改魚的數(shù)量（aquarium-common.js）；
2. antialias 可以選擇開啟或者關(guān)閉抗鋸齒（webgl.js）；
3. TRYUSEWEBGL2 可以選擇是否使用 Instance Rendering（wxhelper.js）;
4. 使用 GetCanvasSizeUseWindowRatio(720/600) 或者 GetWindowSizeInPx 選擇不同的渲染分辨率（aquarium.js - setCanvasSize）；

1. 小游戲不支持抗鋸齒，無論設(shè)置 antialias 參數(shù)為 true 或者 false，結(jié)果都是 false，Chrome 默認是打開抗鋸齒，需要顯式關(guān)閉；
2. 小游戲目前并不支持 WebGL2，WebGL2 新增的 API 并沒有實現(xiàn)；
3. 小游戲只能使用屏幕像素大小的渲染分辨率；
4. 小游戲在 100 ~ 200 條魚時幀率反而更低，反復(fù)驗證過幾次均是如此，懷疑踩到了什么坑，應(yīng)該不是性能瓶頸；
5. 小游戲最高幀率不會達到 60，最多就是 58 ~ 59，或許是 requestAnimationFrame 的實現(xiàn)有些問題；

Canvas Bitmap

類似雷電的小游戲，多個小位圖的重復(fù)繪制，主要測試 Canvas.drawImage 的性能，跟微信開發(fā)工具自帶的樣例游戲類似。

可以對 enemiesCount（guimark3.js），改變敵機的數(shù)量，從而增加或者減少 drawImage 的調(diào)用次數(shù)。

性能分析

渲染流水線

在 Chrome 渲染流水線里面，Canvas 元素的更新跟其他 DOM 元素的內(nèi)容更新一樣，都需要走非合成器動畫的渲染流水線。而非合成器動畫渲染流水線過于復(fù)雜和冗長，比較小游戲簡單和直接的渲染流水線，會有較多的 Overhead。

不過假設(shè)網(wǎng)頁的運行條件跟小游戲一樣，頁面只有一個 Canvas 元素而不存在其他 DOM 元素，這些 Overhead 其實每個環(huán)節(jié)的耗時都很小，加上 Chrome 多線程高并發(fā)的流水線設(shè)計，實際上大部分開銷都可以忽略不計，對整體性能的影響微乎其微。

WebGL Compute 的測試結(jié)果也驗證了這一點，該 Demo 只有一個 Draw Call，所以我們基本可以忽略繪制部分的影響，JavaScript 計算的開銷也可以認為是基本相同，在小游戲和 Chrome 的性能測試結(jié)果基本一致的情況下，我們可以推斷出渲染流水線本身不會造成明顯的性能差異。

關(guān)于 Chrome 非合成器動畫的渲染流水線可以參考我的文章 - 瀏覽器渲染流水線解析與網(wǎng)頁動畫性能優(yōu)化。

JavaScript Computing

我們把 JavaScript Computing 定義為除了 Native API（2D Canvas，WebGL，etc...）外的其它純 JavaScript 代碼運行的耗時。

小游戲和 Chrome 都使用 v8 虛擬機運行 JavaScript 代碼，理論上 JavaScript 計算的性能不會存在較大差異，些微的差別可能來源自 v8 的版本差異，WebGL Compute 的測試結(jié)果也驗證了這一點。

WebGL

Chrome 對比小游戲 WebGL 繪制的差別在于：

1. 小游戲的 WebGL 調(diào)用會直接調(diào)用對應(yīng)的 GL API，Chrome 使用了跨進程/線程的 CommandBuffer 機制，WebGL 調(diào)用會先被 Encode Command 到 Buffer 里面，然后在另外一個獨立的 GPU 線程中 Decode Command，再調(diào)用相應(yīng)的 GL API；
2. 小游戲的主 Canvas 直接繪制在 GLSurfaceView 上，Chrome 會為每個 Canvas 元素分配額外的 Texture 作為 Render Target，然后再把該 Texture 合成到 Window 上，這意味著 Chrome 需要做一次 Render Target 的切換和多一次緩存拷貝，會增加一些 GPU 開銷；

在 WebGL Aqua 這個 Demo 中，計算部分的開銷很小，大部分是繪制的開銷，Chrome 的多線程模型并沒有帶來多少并發(fā)的優(yōu)勢，只是抵消了 CommandBuffer 機制帶來的一些 Overhead，不過額外的 Render Target 切換和緩存拷貝的影響看起來也很小，Chrome 和小游戲的性能基本持平，甚至 Chrome 還稍微好一些。如果是計算和繪制開銷比較平均的場景，Chrome 可能會有更大的性能優(yōu)勢。

2D Canvas

Chrome 對比小游戲 2D Canvas 繪制的差別在于：

1. Chrome 每一個 2D Canvas Draw Call，特別是 drawImage 的調(diào)用，因為瀏覽器運行環(huán)境復(fù)雜性的原因，有較大的 Overhead，包括 Image 對象的類型檢查和轉(zhuǎn)型，Dirty Rect 的計算，DOM 對象的交互，Image URL 的 Origin Check 安全檢查，等等，而這些在小游戲運行環(huán)境下都是可以省略或者優(yōu)化的；
2. Chrome 使用 Skia 作為 2D 繪圖引擎，Skia 作為一個通用，完備，可外部配置的 2D 繪圖引擎，支持不同的光柵化后端實現(xiàn)（CPU，GL，Vulkan），支持復(fù)雜的內(nèi)存管理和資源緩存機制，但是也帶來了較高的 per drawImage 的開銷，小游戲高度定制的 2D 繪圖引擎可以容易地規(guī)避掉這些開銷；

因為 Chrome 運行環(huán)境中較高的 per drawImage 的開銷，我們可以在 Canvas Bitmap 測試中看到當 drawImage 的調(diào)用次數(shù)非常高時，Chrome 的 Renderer 線程會被嚴重阻塞而導(dǎo)致幀率下降幅度大大高于小游戲的下降幅度。

WebGL 理論上 Chrome 也會多一些 Overhead，只是 WebGL API 相比 2D Canvas API 的實現(xiàn)要簡單很多，所以這些 Oveahead 實際影響非常小，并沒有 2D Canvas 那么明顯。

總結(jié)和優(yōu)化建議

總結(jié)

1. Chrome 和小游戲因為渲染流水線不同帶來的影響很小，基本上可以忽略（在沒有其他 DOM 元素的條件下）；
2. Chrome 和小游戲都使用 v8 作為 JavaScript 虛擬機，JavaScript 的計算性能基本一致；
3. Chrome 和小游戲的 WebGL 渲染性能在都關(guān)閉抗鋸齒的條件下基本一致，Chrome 還略微超出，另外 Chrome 可以通過降低渲染分辨率和使用 Instance Rendering 等方式進一步提升性能；
4. Chrome 和小游戲在 2D Canvas 繪制場景中，如果 drawImage 的每幀調(diào)用次數(shù)在正常范圍內(nèi)，性能差別不大，如果 drawImage 調(diào)用次數(shù)非常高，Chrome 的性能下降幅度更大；

H5 游戲的優(yōu)化建議

1. 如果渲染場景比較復(fù)雜，WebGL 建議關(guān)閉抗鋸齒，打開/關(guān)閉抗鋸齒在 5.x 寸屏上對渲染效果的影響微乎其微，并且小游戲和原生手游也沒有使用抗鋸齒，關(guān)閉抗鋸齒對于復(fù)雜的渲染場景可以帶來非常明顯的性能提升；
2. 如果渲染場景非常復(fù)雜，可以考慮使用較低的渲染分辨率，降低分辨率可以帶來明顯的性能提升，600 ~ 720p 在 5.x 寸屏上比起原生分辨率雖然畫面會略微模糊一些，但是整體渲染效果還是可以接受的；
3. 如果渲染場景存在同一個 Mesh 的大量重復(fù)繪制，建議使用 Instance Rendering，Instance Rendering 可以大幅降低 GL API 調(diào)用次數(shù)，減少 GL API 調(diào)用的 CPU 開銷，帶來較大程度的性能提升；
4. 如果 2D 游戲場景中的每幀 Image 繪制次數(shù)達到幾千的量級，建議使用 WebGL 替代 2D Canvas（大部分 2D 游戲應(yīng)該也就幾百的量級，就不需要考慮這個）；