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

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

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

導讀一、背景隨著互動游戲業務 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://www.www897cc.com/showinfo-26-70412-0.html互動游戲團隊如何將性能體驗優化做到TOP級別

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

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

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

標簽：

熱門焦點

K60 Pro官方停產第三方瞬間漲價

雖然沒有官方宣布，但Redmi的一些高管也已經透露了，Redmi K60 Pro已經停產且不會補貨，這一切都是為了即將到來的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機在停產之后
2023年Q2用戶偏好榜：12+256G版本成新主流

3月份的性能榜、性價比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機潮已經過去，最明顯的肯定就是大內存和存儲的機型了，另外部分中端機也取消了屏幕塑料支架
6月安卓手機性能榜：vivo/iQOO霸占旗艦排行榜前三

2023年上半年已經正式過去了，我們也迎來了安兔兔V10版本，在新的驍龍8Gen3和天璣9300發布之前，性能榜的榜單大體會以驍龍8Gen2和天璣9200+為主，至于那顆3.36GHz的驍龍8Gen2領先
印度登月最關鍵一步！月船三號今晚進入環月軌道

8月5日消息，據印度官方消息，月船三號將于北京時間今晚21時30分左右開始近月制動進入環月軌道。這是該探測器能夠成功的最關鍵步驟之一，如果成功將開始圍
Raft算法：保障分布式系統共識的穩健之道

1. 什么是Raft算法？Raft 是英文”Reliable、Replicated、Redundant、And Fault-Tolerant”（“可靠、可復制、可冗余、可容錯”）的首字母縮寫。Raft算法是一種用于在分布式系統
SpringBoot中使用Cache提升接口性能詳解

環境：springboot2.3.12.RELEASE + JSR107 + Ehcache + JPASpring 框架從 3.1 開始，對 Spring 應用程序提供了透明式添加緩存的支持。和事務支持一樣，抽象緩存允許一致地使用各
讓我們一起聊聊文件的操作

文件【1】文件是什么？文件是保存數據的地方，是數據源的一種，比如大家經常使用的word文檔、txt文件、excel文件、jpg文件...都是文件。文件最主要的作用就是保存數據，它既可以保
余承東:AI大模型技術的發展將會帶來下一代智能終端操作系統的智慧體驗

8月4日消息，2023年華為開發者大會（HDC.Together）今天正式開幕，華為發布HarmonyOS 4、全新升級的鴻蒙開發套件、HarmonyOS Next開發者預覽版本等一系列
與兆芯合作聯想推出全新旗艦版筆記本電腦開天N7系列

聯想與兆芯合作推出全新聯想旗艦版筆記本電腦開天 N7系列。這個系列采用兆芯KX-6640MA處理器平臺，KX-6640MA 處理器是采用了陸家嘴架構，16nm 工藝，4 核 4 線