紅魔電競(jìng)平板評(píng)測(cè)：大屏幕硬實(shí)力
前言：三年的疫情因?yàn)橐暇W(wǎng)課的原因激活了平板市場(chǎng)，如今網(wǎng)課的時(shí)代已經(jīng)過(guò)去，大家的生活都恢復(fù)到了正軌，這也就意味著，真正考驗(yàn)平板電腦生存的環(huán)境來(lái)了。也就是面對(duì)著這種殘酷的
說(shuō)起，「前端性能優(yōu)化」，大家可能第一時(shí)間就會(huì)從網(wǎng)絡(luò)/資源加載/壓縮資源等角度考慮。
正如下面所展示的一樣。
圖片
圖片
圖片
上面所列的措施，是我們常規(guī)優(yōu)化方案。針對(duì)上面的內(nèi)容我們有機(jī)會(huì)來(lái)講講該如何做。
而今天呢，我們和大家嘮嘮利用WebAssembly來(lái)優(yōu)化前端渲染鏈路或者針對(duì)關(guān)鍵節(jié)點(diǎn)進(jìn)行調(diào)優(yōu)處理。
WebAssembly是一種「二進(jìn)制指令格式」，旨在在瀏覽器中高效執(zhí)行。
WebAssembly的一個(gè)最具說(shuō)服力的特點(diǎn)是其在「計(jì)算密集型任務(wù)」中的性能提升。例如，在對(duì)龐大數(shù)據(jù)集進(jìn)行復(fù)雜的統(tǒng)計(jì)計(jì)算時(shí)，WebAssembly 可能比常規(guī)的 JavaScript 快得多。這是因?yàn)?nbsp;WebAssembly 的高度優(yōu)化設(shè)計(jì)使得代碼執(zhí)行速度遠(yuǎn)遠(yuǎn)超過(guò) JavaScript。
WebAssembly 的另一個(gè)優(yōu)點(diǎn)是其「可移植性」。跨平臺(tái)應(yīng)用程序的開發(fā)變得非常簡(jiǎn)單，因?yàn)榭梢詮亩喾N語(yǔ)言生成 WebAssembly 代碼，并在任何平臺(tái)上執(zhí)行。
最后，「安全性」也是 WebAssembly 架構(gòu)中的一個(gè)重要考慮因素。由于 WebAssembly 提供了沙箱執(zhí)行環(huán)境，代碼無(wú)法訪問(wèn)敏感數(shù)據(jù)或運(yùn)行惡意代碼。
下面是了解和學(xué)習(xí)WebAssembly的RoadMap。
圖片
進(jìn)入正題之前，我們還是和之前一樣，使用我們自己的腳手架-f_cli_f[1]構(gòu)建一個(gè)以Vite為打包工具的前端項(xiàng)目。
在本地合適的目錄下執(zhí)行如下代碼：
npx f_cli_f create wasm_preformance然后，我們?cè)趐ages中新建如下的目錄結(jié)構(gòu)：
圖片
其中wasm存放的是我們已經(jīng)構(gòu)建好的wasm的資源。
由于我們?cè)陧?xiàng)目中會(huì)用到Web Worker，所以我們還需要對(duì)其做一定的配置。
而今天，我們?cè)俳榻B另外一種更加優(yōu)雅的方式 - Comlink[2]。
Comlink是一個(gè)由Google Chrome Labs開發(fā)的輕量級(jí)庫(kù)，它旨在簡(jiǎn)化Web Worker與主線程之間的通信，讓我們能夠充分利用多線程處理的威力，提升前端應(yīng)用性能。
由于，我們是用Vite搭建的前端項(xiàng)目，所以我們還需要在項(xiàng)目中借助vite-plugin-comlink[3]。
我們可以通過(guò)如下代碼安裝對(duì)應(yīng)的依賴。
yarn add -D vite-plugin-comlinkyarn add comlink然后，將對(duì)應(yīng)的庫(kù)配置到vite.config.js中。
import { comlink } from "vite-plugin-comlink";export default { plugins: [comlink()], worker: { plugins: () => [comlink()], },};這里有一點(diǎn)需要額外注意，comlink要放置在plugins第一個(gè)位置。
針對(duì)TypeScript項(xiàng)目，我們還需要在vite-env.d.ts中新增/// <reference types="vite-plugin-comlink/client" />。
然后我們就可以用優(yōu)雅的方式來(lái)使用WebWorker了。
圖片
可以看到，使用了comlink后，我們?cè)谑褂枚嗑€程能力時(shí)，不需要寫那么多模板代碼，而是通過(guò)Promise來(lái)接收從子線程返回的數(shù)據(jù)。
如果看過(guò)我們之前的文章(Rust 賦能前端 -- 寫一個(gè) File 轉(zhuǎn) Img 的功能)就對(duì)這塊不會(huì)陌生。
在Vite項(xiàng)目中使用WebAssembly我們需要配置vite-plugin-wasm[4]和vite-plugin-top-level-await[5]
然后，也是需要在vite.config.js的plugin和worker中進(jìn)行相關(guān)處理。這里就不展開說(shuō)明了。之前的文章有過(guò)解釋。
在講項(xiàng)目頁(yè)面結(jié)構(gòu)時(shí)說(shuō)過(guò)，我們?cè)诮M件目錄中特意有一個(gè)wasm目錄用于存放編譯好的wasm信息。
我們選擇wasm代碼和前端項(xiàng)目分離的方式，也就是我們會(huì)重新啟動(dòng)一個(gè)Rust項(xiàng)目。
通過(guò)如下代碼在合適的文件目錄下執(zhí)行。
cargo new --lib rust_comformation2web然后，因?yàn)槲覀兿胍裄ust編譯成wasm并且還需要操作對(duì)應(yīng)的dom等。所以，我們需要按照對(duì)應(yīng)的crate。
所以，我們來(lái)更新對(duì)應(yīng)的Cargo.toml。
[package]name = "rust_comformation2web"version = "0.1.0"edition = "2021"[lib]crate-type = ["cdylib"][dependencies]wasm-bindgen = "0.2.92"console_error_panic_hook = "0.1.7"js-sys = "0.3.69"[dependencies.web-sys]version = "0.3.69"features = [ 'Document', 'TextMetrics', 'CanvasRenderingContext2d', 'HtmlCanvasElement', 'Window']然后，我們就可以在src/lib.rs寫我們對(duì)應(yīng)的代碼了。
如果對(duì)自己的代碼質(zhì)量不是很放心，并且又不想寫Test模塊了，我們將Rust所在的文件目錄，構(gòu)建成一個(gè)Node項(xiàng)目（通過(guò)npm init），并配合對(duì)應(yīng)的打包軟件(Webpack)來(lái)直接驗(yàn)證wasm的效果。
圖片
對(duì)應(yīng)的webpack.config.js的配置如下：
const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');const webpack = require('webpack');const WasmPackPlugin = require("@wasm-tool/wasm-pack-plugin");module.exports = { entry: './index.js', output: { path: path.resolve(__dirname, 'dist'), filename: 'index.js', }, plugins: [ new HtmlWebpackPlugin({ template: 'index.html' }), new WasmPackPlugin({ crateDirectory: path.resolve(__dirname, ".") }), // 讓這個(gè)示例在不包含`TextEncoder`或`TextDecoder`的Edge瀏覽器中正常工作。 new webpack.ProvidePlugin({ TextDecoder: ['text-encoding', 'TextDecoder'], TextEncoder: ['text-encoding', 'TextEncoder'] }) ], mode: 'development', experiments: { asyncWebAssembly: true }};然后，我們?cè)趐ackage.json新增兩個(gè)命令
"scripts": { "build": "webpack", "serve": "webpack serve" },我們就可以通過(guò)yarn serve查看效果亦或者yarn build執(zhí)行對(duì)應(yīng)的rust打包。
能夠?qū)崿F(xiàn)這一切的功勞都是-@wasm-tool/wasm-pack-plugin[6]所賜予的。
但是呢，我們對(duì)Rust編譯處理不使用之前的yarn build，而是使用cargo自己的構(gòu)建工具 - wasm-pack[7]。
wasm-pack build --target web --release如果一切都正常的話，對(duì)應(yīng)的wasm就會(huì)被打包到pkg文件夾下面了。
然后，我們就可以將所有文件復(fù)制到Vite項(xiàng)目中的wasm/xx目錄下。
最后，我們就可以在React組件中通過(guò)。
import init, { fib } from './wasm/xx';引入對(duì)應(yīng)的wasm函數(shù)了。
前面鋪墊了那么多，其實(shí)為了更好的講下面的內(nèi)容，我們先把一些和邏輯代碼不相關(guān)的配置內(nèi)容提前介紹了，這樣我們就可以將更過(guò)的注意力放在代碼實(shí)現(xiàn)上了。
圖片
當(dāng)執(zhí)行一個(gè)處理耗時(shí)任務(wù)時(shí)，WebAssembly/JS WebWorker/JS主線程三者的執(zhí)行時(shí)間是由低到高排列的。
WebAssembly < JS WebWorker<JS主線程。
針對(duì)上面的我們有幾點(diǎn)需要注意：
我們都知道JS是單進(jìn)程的，所以我們?cè)谔幚硪恍┨幚砗臅r(shí)任務(wù)就會(huì)很吃力。當(dāng)然，我們也可以借助Web Worker來(lái)開啟新的子線程來(lái)緩解主線程的計(jì)算壓力。但是，在一些計(jì)算量特別大的功能面前，一切的計(jì)算都是收效甚微的。
其實(shí)，將一些處理耗時(shí)任務(wù)放置到Web Worker中只是不想讓耗時(shí)任務(wù)過(guò)多的占用主線程資源，從而讓頁(yè)面沒(méi)有卡頓的感覺(jué)。這就是大家所熟悉的瀏覽器在 1 秒鐘內(nèi)完成 60 次圖像的繪制，用戶才會(huì)感覺(jué)頁(yè)面順暢。
為了在前端環(huán)境模擬處理耗時(shí)任務(wù)，我們采用在前端環(huán)境中執(zhí)行一個(gè)fibonacci的計(jì)算過(guò)程。
在WasmPerformance的index.tsx中有如下的頁(yè)面操作。
圖片
也就是說(shuō)，我們?cè)贘S主線程/JS WebWorker/WebAssembly中分別執(zhí)行一個(gè)耗時(shí)的fibonacci。
我們?cè)趖ool.ts中構(gòu)建了一個(gè)最簡(jiǎn)單的fibonacci函數(shù)。
function fibJS(n: number): number { if (n < 2) { return n; } return fibJS(n - 1) + fibJS(n - 2);}對(duì)應(yīng)的頁(yè)面代碼如下：
圖片
從上面我們看到幾個(gè)關(guān)鍵的點(diǎn)：
我們用state來(lái)維護(hù)計(jì)算的結(jié)果和時(shí)間。
const [calculateInfo, setCalculateInfo] = useState<CalculateInfo>({ js: { result: 0, executionTime: 0 }, wasm: { result: 0, executionTime: 0 }, webworker: { result: 0, executionTime: 0 }, });然后，我們?cè)趆andleCalculate中執(zhí)行不同的操作邏輯。
圖片
其中measureExecutionTime是我們?cè)趖ool定義的用于檢測(cè)指定函數(shù)被執(zhí)行時(shí)的所用時(shí)間的函數(shù)。
function measureExecutionTime<T extends (...args: any[]) => any>( fn: T): (...args: Parameters<T>) => { result: ReturnType<T>; executionTime: number } { return function (...args: Parameters<T>): { result: ReturnType<T>; executionTime: number } { const start = performance.now(); const result = fn.apply(this, args); const end = performance.now(); const executionTime = end - start; return { result, executionTime }; };}還有，我們?cè)趆andleCalculate在接收到type為3時(shí)，是觸發(fā)了一個(gè)wasm版本的fibonacci函數(shù)。
由于，對(duì)應(yīng)的Rust代碼如下：
use wasm_bindgen::prelude::*;#[wasm_bindgen]pub fn fib(n: usize) -> usize { match n { 0 => 0, 1 => 1, _ => fib(n - 1) + fib(n - 2), }}而上面的Rust代碼會(huì)通過(guò)wasm-pack build --target web --release進(jìn)行打包處理，并且打包后的相關(guān)內(nèi)容被復(fù)制到了前端項(xiàng)目中wasm/calculate。
然后在組件中通過(guò)import init, { fib } from './wasm/calculate';方式來(lái)導(dǎo)入。
圖片
圖片
我們寫了兩個(gè)示例：
無(wú)論是哪種情況，我們可以得出一個(gè)比較明顯的情況。
在圖像處理的部分功能點(diǎn)上，WebAssembly的性能遠(yuǎn)高于JS。
因?yàn)椋覀冞@里沒(méi)做WebAssembly的內(nèi)存優(yōu)化，當(dāng)處理數(shù)據(jù)「超級(jí)大」時(shí)，由于數(shù)據(jù)傳輸?shù)膯?wèn)題，反而WebAssembly的執(zhí)行時(shí)間會(huì)比JS長(zhǎng)。但是呢，這塊不在我們的討論范圍內(nèi)。后期有機(jī)會(huì)寫相關(guān)的文章。
下面，我們就按照上面的示例來(lái)分別講講它們的代碼實(shí)現(xiàn)。有些代碼的邏輯其實(shí)很簡(jiǎn)單，我們已經(jīng)有對(duì)應(yīng)的注釋，所以也不會(huì)用多余的篇幅解釋。
對(duì)應(yīng)的頁(yè)面結(jié)構(gòu)如下：
圖片
我們還是用了一個(gè)state來(lái)維護(hù)狀態(tài)信息。
const [drawInfo, setDrawInfo] = useState<DrawInfo>({ js: { url: '', executionTime: 0 }, wasm: { url: '', executionTime: 0 }, js_circle: { url: '', executionTime: 0 }, wasm_circle: { url: '', executionTime: 0 }, });然后在handleDraw中處理事件邏輯。
圖片
其中drawTextToCanvas是利用JS來(lái)繪制文本到Canvas，而drawTextToCanvasWasm是利用wasm處理相關(guān)邏輯。
圖片
該函數(shù)定義在tool.ts中，然后就是接收一個(gè)String類型的數(shù)據(jù)，并將其渲染到Canvas中。
圖片
然后，別忘記在頭部引入對(duì)應(yīng)的crate。
use wasm_bindgen::prelude::*;use wasm_bindgen::JsCast;use web_sys::{CanvasRenderingContext2d, HtmlCanvasElement};extern crate console_error_panic_hook;use std::panic;其實(shí)這塊的邏輯，和之前我們講的Rust 賦能前端 -- 寫一個(gè) File 轉(zhuǎn) Img 的功能的核心功能是類似的。
該函數(shù)通過(guò)wasm-pack編譯到pkg中，然后我們復(fù)制對(duì)應(yīng)的文件到React項(xiàng)目的wasm/draw中。
然后我們通過(guò)如下代碼：
import init4Draw, { draw_text_to_canvas as drawTextToCanvasWasm, draw_circle_to_canvas as drawCircleToCanvasWasm,} from './wasm/draw';進(jìn)行函數(shù)的導(dǎo)入。
對(duì)應(yīng)的頁(yè)面結(jié)構(gòu)和事件回調(diào)和之前是類似的，我們就省略了這部分的解釋。
該部分也是定義在tool.ts中：
圖片
此函數(shù)的處理過(guò)程和drawText是一樣的。
針對(duì)圖片操作，不單單只有繪制文本/繪制圖案，其實(shí)我們還可以做類似(裁剪/新增水印/圖片翻轉(zhuǎn)等)。
我們可以借助一些成熟的WebAssembly來(lái)做上述的操作。這里呢，給大家推薦一個(gè)庫(kù)Photon[9]。
Photon 是一個(gè)高性能的圖像處理庫(kù)，用 Rust 編寫并可編譯為 WebAssembly，既可以在本地使用 Web 也可以在 Web 上使用。
這是它能做相關(guān)功能：
圖片
寫到這里呢，我們就不在羅列相關(guān)代碼了。所以，我們給出一些針對(duì)音視頻的優(yōu)化的解決方案。
在這里我們介紹一種wasm庫(kù)-ffmpeg.wasm[10]。
ffmpeg.wasm 是 FFmpeg[11] 的針對(duì) WebAssembly / JavaScript 端口，支持在瀏覽器中錄制、轉(zhuǎn)換和流式傳輸視頻和音頻。它利用 Emscripten 來(lái)轉(zhuǎn)譯 FFmpeg 源代碼和許多庫(kù)得到。
具體的功能和庫(kù)如下：
圖片
得益于WebAssembly極致的內(nèi)存管理,然后其二進(jìn)制特性，WebAssembly 提供接近本地執(zhí)行速度的性能，使得復(fù)雜的游戲邏輯和高幀率的圖形渲染可以在瀏覽器中高效運(yùn)行。
還得之前我們寫過(guò)Game = Rust + WebAssembly + 瀏覽器。
圖片
還有，如果我們想要更多的效果，我們可以選擇使用bevy[12] - 一款基于Rust的數(shù)據(jù)驅(qū)動(dòng)的游戲引擎。
然后我們還在itch.io[13]查看哪些游戲是用Rust寫的。
圖片
本文鏈接：http://m.www897cc.com/showinfo-26-92743-0.html寶貝，帶上WebAssembly，換個(gè)姿勢(shì)來(lái)優(yōu)化你的前端應(yīng)用
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)