當前位置：首頁 > 科技 > 軟件

互動游戲團隊如何將性能體驗優化做到TOP級別

來源：責編：時間：2024-02-01 12:47:58 274觀看

導讀一、背景隨著互動游戲業務 DAU 量級增加，性能和體驗重要性也越發重要，好的性能和體驗不僅可以增加用戶使用體感，也可以增加用戶對于互動游戲的使用粘性。對現狀分析，主要存在首屏渲染速度慢、打開頁面存在白屏、頁面加載

一、背景

隨著互動游戲業務 DAU 量級增加，性能和體驗重要性也越發重要，好的性能和體驗不僅可以增加用戶使用體感，也可以增加用戶對于互動游戲的使用粘性。

對現狀分析，主要存在首屏渲染速度慢、打開頁面存在白屏、頁面加載過多資源等問題，核心手段是增加骨架、接口優先級調整、預渲染、減小包體積等。

優化后，互動游戲簽到功能做到同類業務性能體驗 Top 級別，下面是優化后數據：

首屏渲染速度：優化后提升首屏渲染速度 39%。
首屏骨架：骨架體積大小減少 44%（壓縮后減少 50%）。
首次加載總資源：資源總體積優化后，大小減少 69%。

二、骨架

骨架屏是指在頁面加載時，臨時顯示出頁面的主要結構，可以讓用戶在等待頁面加載完成時，得到視覺上的反饋，提升頁面的用戶體驗。

圖片

骨架示意圖vs數據渲染

圖片

可以看出在接口返回數據之前，可以先使用骨架得到一些界面反饋。

三、緩存

雖然骨架屏可以讓用戶在視覺上得到反饋，畢竟不是真實的數據，總體還是有一些簡陋，用戶也可能并不知道這塊區域實際渲染的是什么樣的內容，若是網絡環境不好，很可能會長時間的停留在骨架屏階段，為了增強一些體感，使用緩存進一步對頁面進行優化。

圖片

使用緩存渲染具備以下優勢：

與骨架屏相比，緩存渲染十分接近用戶最終所見，因為每次接口返回數據都會更新緩存，用戶再次進入時看到的都是自己上次進入時的數據。
當用戶處在弱網或者斷網等不可抗力的環境中時，可以得到較為完整的頁面數據展示，可以很好減弱用戶環境帶來的網絡營銷。

使用緩存注意事項：

一些緩存渲染應屏蔽事件響應，避免造成不必要的報錯和客訴。比如商品的緩存渲染，由于商品存在下架、優惠券調整等情況，緩存的數據和實際數據會存在一定的偏差。
緩存渲染邏輯需要更加前置，不應該將緩存渲染的邏輯放在原本的位置，這樣會拖慢渲染的時機。

四、接口后置

瀏覽器對同一時間內的請求數量是有限制的，既并發請求限制。當一個頁面首次渲染時需要瀏覽器發起很多接口請求，用于填充頁面渲染需要的數據，若是對于頁面渲染時的請求數量不加以控制，便可能導致一些問題出現。

現在有 home 和 info 兩個接口，home 接口返回的數據是首屏渲染需要依賴的，info 接口返回的數據則不是首屏必須依賴的。假設現在還有一些其他請求占據了并發請求限制的數量，導致 home 接口請求變慢。

圖片

若是 info 接口響應慢，長時間占據這瀏覽器的請求進程，會導致頁面首屏渲染速度更慢，那么就需要有個一套方案可以根據接口的優先級進行加載順序控制，可以將順序變為如下。

圖片

方案：當頁面加載完成后一定時間后，進行低優先級接口的請求，或者觸發頁面的滾動、點擊等時立即進行接口請求。

此方案適用于：確定接口延遲加載并不會阻塞用戶的交互和操作。

將其封裝為一個 hooks，便于復用，直接先看代碼再解釋：

import { useRM, createRM } from 'xxx'const listen = (type: string, listener: () => void) => {  const l = () => {    listener()    document.removeEventListener(type, l)  }  document.addEventListener(type, l)}const pageFlowModule = createRM(  {    assemble(state) {      const reactionObserver = () => {        state.isUserReactioned = true      }      ;['scroll', 'mousedown', 'touchstart'].forEach((type) => {        listen(type, reactionObserver)      })      setTimeout(reactionObserver, 4000)    },  },  { isUserReactioned: false },)pageFlowModule.actions.assemble()export const usePageFlow = () => {  const [state] = useRM(pageFlowModule)  return state}

使用：

import { usePageFlow } from 'xxx'const Demo = () => {    const { isUserReactioned } = usePageFlow()    const fetchHanlder = useCallback(() => {        // 接口請求數據    }, [])    useEffect(() => {        if(isUserReactioned) {            fetchHanlder()        }    }, [isUserReactioned, fetchHanlder])    return <div>{/* 渲染接口返回的數據 */}</div>}

從上面代碼可以看到，會將一些非首屏需要的請求后置，后置的接口可以在頁面加載完成 4s 后自動觸發調用，也會在用戶有觸屏、滾動頁面等行為的時觸發接口的調用。

五、骨架優化

簽到和許愿樹目前主文檔中除了骨架部分還包含了一些公共的 JS 和 CSS，對不同資源類型進行拆分、匯總后發現，不管是簽到還是許愿樹，實際包含 HTML + JS 部分僅占極小比例，大量的流量消耗在了 CSS 上。

對 HTML 中 CSS 部分再進行梳理發現，文件中包含的除了骨架的 CSS 部分和公共組件庫的 CSS 部分之外，還包含了大量彈框的 CSS。這三類中，骨架的 CSS 要保留，公共組件庫的 CSS 可以拆分但是難度較大，剩下的就是彈框或者非骨架部分的 CSS。

需要把彈框部分組件做異步加載，保證預渲染的時候這部分 CSS 文件不會被加載到。
拆分骨架組件，把骨架組件從業務組件中剝離，預渲染的時候只渲染和加載骨架部分，不加載其余主文件部分 CSS，進一步縮小骨架。

圖片

六、localStorage性能問題

在做優化之前，并未意識到 localStorage 所隱藏的性能問題，業務中使用了大量的本地存儲，使用 Performance 記錄一下存儲消耗的時間。

記錄核心代碼：

export const setMallFlowStoreData = (data: any) => {  performance.mark('start_localstorage_operation')  // localStorage 操作.....  performance.mark('end_localstorage_operation')  performance.measure('localstorage_operation_duration', 'start_localstorage_operation', 'end_localstorage_operation')}

輸出記錄的時間：

const entries = performance.getEntriesByName('localstorage_operation_duration')const TOTAL_TIME = entries.reduce((current, next) => {return current + next?.duration}, 0)console.log('全部記錄:', entries, '共耗時:', TOTAL_TIME)

輸出結果：

可以看到通過 localStorage 進行一次存儲操作，大致需要耗時 0.2-0.5ms 之間，若是當頁面存在大量的前端的存儲操作時，低端機型在存儲操作上消耗甚至達到 10-20ms，若是代碼寫的不合理，導致頁面 reload、反復觸發獲取操作等情況，這個時間又將會成倍的增加。

接下來先一起看看為何會存在性能方面的問題和解決方案。

存儲數據

問題：

localStorage 的存儲是同步的操作，因此在存儲大量數據時，可能會導致阻塞 UI 線程，影響用戶體驗。

方案：

核心思路便是將同步操作轉換為異步操作，這樣就不會阻塞 UI 線程。

使用 Web Worker ，會增加一些項目維護的復雜度，且其是 HTML5 標準中新增的技術，存在一定的兼容性（ChatGPT 給的，應該是錯誤答案，并未在 MDN 中看到）。

圖片

使用 setTimeout、setInterval，兼容性絕對的好，但是并未從根本解決問題。
不用 localStorage，直接上 IndexDB，但是由于代碼項目原因，不能改動原有的太多邏輯。

綜合解決方案和歷史原因，只能退而求其次選擇 setTimeout 的方式解決這個問題。

讀取數據

問題：

每次讀取 localStorage 數據時，都需要從磁盤中讀取數據，因此在處理大量數據時，可能會出現性能問題。

方案：

可以將數據進行放到內存中緩存處理，在用戶的整個操作周期內只從 localStorage 獲取一次數據，需要注意的是每次對數據進行操作時，需要將 localStorage 和內存緩存的數據同步更新。

數據類型轉換

問題：

在存儲和讀取數據時，需要將數據進行序列化和反序列化操作。這些操作可能會導致性能問題。

方案：

使用 JSON.stringify() 和 JSON.parse() 函數來處理數據的序列化和反序列化。

經過對 localStorage 存儲優化以后，在紅米 note 11 上面進行了簡單測試，首屏打開速度提升，對于整體提升首屏提升約 2%。

七、動效執行時機

頁面存在漸入漸現的動效，在頁面首次加載時，由于漸現動效的存在，會延遲用戶感知該模塊，從而導致感覺頁面存在更多時間的白屏，動效如下：

圖片

核心問題是首次渲染直出 DOM 結構，不走漸現動效便可，這個比較偏向于邏輯處理，屬于體驗優化的范疇，主打的就是在后續有相關首屏動效時，有意識對其做一下處理，保證首屏首次渲染的完整讀。

八、渲染模塊的取舍

首先看一下兩種狀態各自的樣式：未簽到 VS 已簽到。

圖片

簽到業務的日歷會根據用戶當天簽到狀態進行渲染，存在已簽到和未簽到兩種渲染邏輯，由于當前的架構限制，并不能在預渲染時感用戶的簽到狀態，導致日歷部分的渲染會滯后，嚴重影響頁面的首屏渲染速度。

第一版本優化

將簽到狀態進行緩存，當用戶進入簽到時的大致流程如下：

圖片

當用戶進入頁面時，會優先獲取緩存中的數據進行渲染，確保用戶可以第一時間看到日歷部分的渲染，這里需要注意：

緩存需要結合用戶 token 一起判斷，避免造成切換賬號時造成數據污染。
若是用戶第一次進入或者當天未簽到，會使用系統時間作為小日歷上的數字展示，當用戶修改了系統時間設置時，日期判斷會存在誤差。

緩存數據必然會先于接口響應數據，因此頁面第一時間看到的肯定是緩存數據（沒有緩存數據，會默認使用未簽到數據）所渲染的頁面，那么當接口響應完成時，需要使用真實的數據觸發頁面的 rerender，需要注意處理，避免造成頁面閃爍。

雖然這樣做可以提高頁面的渲染體感，當進入頁面時，頂部區域還是會存在一定時間的空白，畢竟還是需要執行 JS 后才能執行骨架渲染邏輯，本質提升速度為：接口響應時間 - JS 執行時間，在低端機表現會較為好一些，高端機體感并非太明顯。

第二版優化

日歷部分由于已簽到和未簽到的樣式存在著較大的出入，不能像某些競品一樣：已簽、未簽的整體頁面布局并未有區分，使用一套公用的渲染邏輯，這樣也導致簽到業務需要將渲染日歷部分的動作滯后，那么核心就是怎么解決這個問題。

綜合考慮后，決定將未簽到樣式作為預渲染時直接生成 DOM，這樣可以保證用戶未簽到的狀態下進入到頁面可以第一時間對的狀態，也可以更快的完成首屏的渲染。

若是用戶已簽到，便在此基礎之上復用今日簽到的邏輯，就是會在簽到完成后展示一個小的動效，將小日歷變成大日歷的樣式。這樣做的好處可以是獲取到用戶真實狀態后，自動切換到大日歷狀態，效果如下。

圖片

結合用戶行為分析：多數用戶一天不會多次訪問，也就是在即不怎么犧牲高頻率訪問用戶的體驗之下，提高了絕大多數用戶的體驗。

九、首屏數據優先請求

前置小知識：最大并發請求數

為了避免瀏覽器過度占用系統資源，瀏覽器對于同一域名下的請求數量是有一定限制的，也就是常見的瀏覽器最大請求數量。

以 Chrome 瀏覽器舉例：同一域名下，HTTP 協議最多允許同時存在 6 個 TCP 連接進行，HTTPS 協議最多為 4 個。

業務現狀

簽到進入頁面共計加載許多接口。

其中首屏渲染需要的幾個核心接口如圖紅色標記所示，核心的接口滯后會導致頁面數據渲染的更慢，嚴重影響體驗，那么到底影響多少呢？可以在瀏覽器 Network 中查看 Waterfall。

圖片

核心接口是在其他完成后開始，是因為其沒有趕上瀏覽器第一批次接口請求隊列中，需要等待前面某些接口結束后，才會將其放到請求隊列中。

動作

有了問題，接下來便是如何做：

首先是制定方案，如何確保接口的請求可以搭上瀏覽器請求隊列的第一班車，本質是將之前散落在各個組件內的 useEffect 中的初始化邏輯進行提取，統一觸發。
梳理接口和首屏渲染的關聯度，確定哪些接口的優先級權重更高。

核心代碼如下：

export const StartModule = createRM(  {    init() {      SigninTopModule?.actions?.getHomeData()      AdModule?.actions?.reqAdInfoList()      HomeModule?.actions?.getBubbleList()    },  })

在頁面初始化時執行 StartModule?.actions?.init()，將核心接口優化執行，通過控制接口請求順序，簽到業務在此提升了大致 6-8% 的首屏渲染速度。

十、字體使用和優化

字體加載和優化是前端開發中的一個重要問題，特別是在移動端和低網絡狀況下。下面是一些字體加載和優化的技巧。

FOUT問題

通過設置 Font-Display 屬性可以控制字體加載時的顯示效果，包括 Auto、Swap、Block、FallBack 和 Optional 幾種模式，可以減少字體加載時間和防止文本閃爍。

設置屬性為FallBack時效果：

圖片

可以看到日期存在明顯的 FOUT（無樣式文本閃現）問題，設置 Swap 也是類似效果，并不符合預期。

設置屬性為 Block 時效果：

圖片

可以看到第一時間并沒有渲染日期，而是有點的短暫空白，因為其可以避免 FOUT，字體文件必須在后臺下載完全后，文本才能顯示。

最終選擇了 font-display: block；效果會更好一些。

注意，并不是整個頁面都使用 Block 屬性，對于一些非首屏關鍵渲染的樣式，使用 fallback 更為合適一些，因為其會使用瀏覽器默認字體，所以還是需要結合業務、場景合理使用。

字體庫大小，你得懂

先看一個 GPT 對于簽到業務常用字體庫打下的統計：

DIN Condensed 字體庫的大小在幾百KB 到幾MB之間
Helvetica Neue 字體庫的大小在幾MB到十幾MB之間

也就是這兩種字體的大小，如果不加以處理，全部加載的大小在幾 MB 到十幾 MB 之間，對于前端項目而言，這是挺夸張的一件事。

可以和設計人員溝通，將字體庫中常用的字體導出，前端項目僅僅引入需要的字體就好，比如 DIN Condensed 字體都是使用在阿拉伯數字上，并不會在其他字上使用，那么只需要將阿拉伯數字導出即可。比如漢字，根據《現代漢語通用字表》（GB/T 13000-2018），常用漢字（包括簡體字和繁體字）共計 3500 個，其中常用的一般是指前 1000 個左右的漢字，那么在使用字體庫的時候，是不是可以默認只需要導出部分即可。

經過處理后的字體庫大小如下圖：

圖片

字體庫數量，你得控制

上面說了一個字體庫的大小是多大，就算是經過處理，最少也會有 30KB 大小，所以項目引入的字體種類是需要控制的，不能設計同學使用了多少種類字體設計，我們就要照單全收。

當設計同學新增字體庫時，如果字體使用在 3 次以內，是不是可以使用圖片來代替文字，或者使用現有的字體庫來平替。

十一、慎用三方庫

業務中存在一些簡單的校驗、轉換和動效并不需要引入三方庫，尤其是因為一個較為簡單的功能引入了一個較為大且冷門的庫時，不僅會增加項目的打包體積，還會增加項目后續維護的溝通、學習成本。

例如下面一個簡單切換動效：

圖片

是一個比較常規的切換動效，卻在項目中引入了一個第三方庫來實現，該庫的使用也是有一些學習成本，因為其具備實現比較復雜的動效能力，在業務動效具備一定復雜度且非首屏的場景下，是可以考慮引入使用的，否則類似這種首屏便需要加載的動效，還是慎重。

上述的切換動效 CSS 實現代碼如下：

@keyframes bigScale {  0% {    opacity: 0;    transform: scale(0.95);  }  to {    transform: scale(1);    opacity: 1;  }}@keyframes smallScale {  0% {    transform: scale(1);    opacity: 1;  }  to {    transform: scale(0.95);    opacity: 0;  }}.squareInCenter {  animation: 0.3s linear 0s 1 normal forwards running bigScale;}.squareOutCenter {  animation: 0.3s linear 0s 1 normal forwards running smallScale;}

在業務開發的過程中，尤其是 C 端的頁面，在實現功能時對于引入額外的庫是一件需要十分謹慎的事情，在內部就看到不少項目在引入關于日期處理方面的庫時，DayJS、MomentJS 同時都會引用到項目中，B 端項目都不能忍，更何況 C 端項目。

十二、總結

本文僅僅介紹得物前端增長團隊在互動游戲側一些體驗優化實踐心得，后續還在不斷迭代和優化，將實踐經驗應用擴大至多個業務中，將整個互動游戲性能體驗優化至 TOP 級別。

本文鏈接：http://m.www897cc.com/showinfo-26-70412-0.html互動游戲團隊如何將性能體驗優化做到TOP級別

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：解放數據處理瓶頸：vaex模塊加速大規模數據處理！

下一篇：轉轉基于MQ的分布式重試框架設計方案

標簽：

熱門焦點

紅魔電競平板評測：大屏幕硬實力

前言：三年的疫情因為要上網課的原因激活了平板市場，如今網課的時代已經過去，大家的生活都恢復到了正軌，這也就意味著，真正考驗平板電腦生存的環境來了。也就是面對著這種殘酷的
7月安卓手機好評榜：三星S23Ultra好評率第一

性能榜和性價比榜之后，我們來看最后的安卓手機好評榜，數據來源安兔兔評測，收集時間2023年7月1日至7月31日，僅限國內市場。第一名：三星Galaxy S23 Ultra好評率：95.71%在即將迎來新
6月安卓手機性價比榜：Note 12 Turbo斷層式碾壓

6月份有一個618，雖然這是京東周年慶的日子，但別的電商也都不約而同的跟進了，反正促銷沒壞處，廠商和用戶都能滿意。618期間一些產品也出現了歷史低價，那么各個價位段的產品性價比
三言兩語說透柯里化和反柯里化

JavaScript中的柯里化(Currying)和反柯里化(Uncurrying)是兩種很有用的技術，可以幫助我們寫出更加優雅、泛用的函數。本文將首先介紹柯里化和反柯里化的概念、實現原理和應用
只需五步，使用start.spring.io快速入門Spring編程

步驟1打開https://start.spring.io/，按照屏幕截圖中的內容創建項目，添加 Spring Web 依賴項，并單擊“生成”按鈕下載 .zip 文件，為下一步做準備。請在進入步驟2之前進行解壓。圖
三星Galaxy Z Fold5今日亮相：厚度縮減但仍略顯厚重

據官方此前宣布，三星將于7月26日也就是今天在韓國首爾舉辦Unpacked活動，屆時將帶來帶來包括Galaxy Buds 3、Galaxy Watch 6、Galaxy Tab S9、Galaxy
自研Exynos回歸！三星Galaxy S24系列將提供Exynos和驍龍雙版本

年初，全新的三星Galaxy S23系列發布，包含Galaxy S23、Galaxy S23+和Galaxy S23 Ultra三個版本，全系搭載超頻版驍龍8 Gen 2，雖同樣采用臺積電4nm工藝制
iQOO Neo8系列或定檔5月23日：首發天璣9200+ 安卓跑分王者

去年10月，iQOO推出了iQOO Neo7系列機型，不僅搭載了天璣9000+，而且是同價位唯一一款天璣9000+直屏旗艦，一經上市便受到了用戶的廣泛關注。在時隔半年后，
朋友圈可以修改可見范圍了蘋果用戶可率先體驗

近日，iOS用戶迎來微信8.0.27正式版更新，除了可更換二維碼背景外，還新增了多項實用功能。在新版微信中，朋友圈終于可以修改可見范圍，簡單來說就是已發布的朋友圈