使用者流失高是運營不給力？你還需要關注一下效能問題

小遊戲的開發者都會非常關注新進、留存、付費等與使用者體驗密切相關的小遊戲運營資料。

而想要資料“好看”，即使用者體驗更好，遊戲效能就是不能忽視的一環。

在小遊戲公開課上，官方團隊就首次給出了“效能優化指南”，從工具助力、平臺舉措等，幫助開發者優化小遊戲效能。

1、小遊戲資料助手“效能模組”：沒有接入成本，手機掃碼即可進入，並提供自動的效能監控，幫助開發者更全面地把握效能資料；

2、即將釋出新的服務能力“小遊戲測試雲服務”：將大為節省做測試的人力，也增加了測試機型的覆蓋面。在測試完任務後，可以同時得到效能測試的報告以及相容性測試的報告。


此外，小遊戲團隊還對如何進行效能優化給出了一些實用建議：

1、下載程式碼包階段可以儘量精簡包內資源，可以使用平臺側提供的分包或者引擎外掛能力；

2、框架、環境的準備和首屏渲染準備階段，可以藉助平臺側提供的預下載能力，儘可能地降低首屏需要的資源數目，儘快的進行渲染。

意猶未盡？小遊戲效能優化實戰指南全文請收好——



大家好，很高興來到這裡給大家做一個技術相關的分享。今天由我和我的同事蔡凌波共同為大家分享，我們的分享主題是小遊戲效能優化指南。


我們的分享主要分兩部分，首先由我為大家介紹小遊戲效能的概況，效能分析工具以及未來的規劃；第二部分，由我的同事介紹小遊戲常見的效能問題和比較好的優化手段。

作為小遊戲的開發者，我們會非常關注小遊戲的運營資料。比如新進、留存、付費等等。那麼我們為什麼要做遊戲的效能優化呢？我認為這些資料背後的核心點是在於使用者的體驗，而從開發的角度看，遊戲效能又是最能影響使用者體驗的部分。

舉例，如果遊戲啟動沒有優化好，需要很久才能看到遊戲的畫面。很有可能很多玩家在沒有等到遊戲載入完就已經產生了流失。

又例如我們在平臺中發現有很多玩法非常有趣，品質也很不錯的小遊戲，但實際玩的過程中會發現玩了幾分鐘手機就變得非常燙。我們還發現有些場景非常精美的小遊戲，但玩著玩著會突然彈出一個提示記憶體佔過大出現閃退。

由此可見，遊戲的效能是非常影響遊戲體驗的。因此，作為開發者需要優化遊戲效能，並且也只有在比較好的遊戲效能之上才能構建出更加豐富、有趣的小遊戲出來。

小遊戲效能概況

遊戲的效能優化本身是一個非常複雜的話題。有沒有一些好的優化工具能夠幫助我們做遊戲的效能優化呢？

首先，我為大家介紹的第一個分析工具是小遊戲資料助手中的效能模組。

這個模組產生的背景是這樣的，我們和開發者溝通過程中發現開發者經常會有這樣一些疑問：

我的遊戲已經發布到線上，現網玩家真實的使用者體驗是怎樣的，玩家需要多少秒才能進入遊戲，這個過程中又有多少使用者產生了流失。

也有一些開發者給我們反饋，現在對使用者體驗和遊戲效能缺乏一個比較好的監控手段，往往需要通過玩家的反饋來感知到遊戲中不好的效能。有沒有一些更加高效、可靠的效能監控手段呢？

帶著這樣的疑問，我們今年7月份在小遊戲資料助手中增加了效能模組，從小遊戲底層框架做了自動資料埋點，大家不需要做任何接入工作就可以使用這個服務，沒有任何接入成本。可以通過手機掃碼進入到小遊戲資料助手，開啟效能皮膚，直接看到小遊戲目前的執行狀況。

其次，我們的資料面向全網遊戲海量玩家的真實效能取樣資料，因此開發者能夠對效能資料有更全面的把握。

最後，在資料之上我們做了自動的效能監控，對於出現問題的效能指標給予開發者提醒，並給出我們比較推薦的優化手段和工具指引。

實際工作中如何結合小遊戲的效能模組為效能優化服務？從功能上看，小遊戲資料助手的效能模組主要分概覽和詳情兩部分。

首先可以在概覽上看到目前小遊戲執行的整體情況，它就像一個儀表盤，可以在其中看到一些關鍵效能資料。比如遊戲的啟動速度，遊戲在啟動過程中使用者的留存，遊戲在執行過程中的CPU、記憶體、網路延遲等相關資料。

我們希望開發者看到資料後對遊戲執行效能有直觀感受。在這些資料的背後關聯的是使用者體驗。比如我們能夠知道使用者究竟需要多少秒才能開啟遊戲，而在每一秒鐘產生使用者的流失有多少。

我們也能知道使用者在不同的機型情況下執行遊戲的流暢程度怎麼樣。除了本身的資料包表外，還提供了效能監控。比如左邊（見PPT）檢測到遊戲載入時間高於評估標準。

這種情況下，我們會發現這個問題，並且告知開發者，最後給出平臺中比較好的優化實踐引導開發者做這方面的優化。

小遊戲效能分析工具

如果在效能概況中真的發現自己的遊戲出現效能問題時，下一步該如何做這裡面資料的解讀和進一步的效能優化呢？

我們提供了效能詳情，對資料和維度做了進一步細化和拆解。這裡的目的是為了讓開發者能夠進一步定位效能的瓶頸。

比如效能資料為釋出後，有開發者看到開啟留存率只有60%。這個開發者感到非常疑惑，因為他的程式碼包不到2兆，為什麼啟動速度到十幾秒，而且留存只有60%。

經過效能詳情分析，發現這個遊戲在程式碼包載入完後和首屏載入前還做了許多開發者自己資源的載入，開發者意識到程式碼包的重要性，但沒有意識到首屏畫面對於玩家的重要性。

在這個角度，微信小遊戲資料助手為開發者發現了這樣一個問題。

我們經常會收到開發者關於遊戲記憶體的問題。有開發者會問到，在現網執行中，有玩家給我們反饋為什麼會玩著玩著突然出現一個彈框說記憶體佔過大出現閃退。開發者這時候沒有辦法判定這是個別的使用者行為還是真的記憶體出現了問題。

通過執行效能分析，我們看到這款遊戲的記憶體佔用達到600兆，我們也可以看到在現網執行過程中有接近20%的使用者是因為這個原因而產生了閃退。

因此我們可以肯定的告訴開發者，這是一個記憶體效能問題。由此，開發者做了更進一步的效能分析，發現是某一個資源釋放的原因，由此解決了問題。

由此可見，微信小遊戲效能助手可以提供自動監控手段，還能為資料進一步分析提供幫助，讓我們去發現效能的瓶頸。

微信小遊戲資料助手的效能模組本質是資料服務，也是效能監控工具。然而如果發現問題時僅僅靠現網資料分析是不夠的，往往需要用各種效能分析工具，找到效能真正的問題所在。

在以往和開發者的溝通過程中，我們發現大家在做效能優化時，常常遇到這麼一個問題：我手頭上的硬體裝置是不夠，同時我也沒有辦法對每一個版本、每一個裝置做相關的效能測試，尤其是對一些小的開發團隊來說，這個測試是很耗費人力時間成本的。

為了解決這樣一個痛點，我們即將釋出新的服務能力：小遊戲測試雲服務。

在這個解決方案裡提供了雲真機測試叢集，這個測試叢集裡涵蓋了超過80%主流品牌機型。另一方面，開發者除了可以自己編寫測試指令碼外，也可以直接利用到平臺所提供的一鍵測試。

以這樣的方式節省了大家做測試的人力，同時也增加了測試機型的覆蓋面。在測試完任務後，可以同時得到效能測試的報告以及相容性測試的報告。

左圖是特定一臺機型下的效能測試報告，我們除了能知道測試過程中整體的效能概況，更重要的是知道關鍵指標隨時間的變化趨勢.

最終我們還提供了遊戲出現效能異常的時候對應的截圖去方便大家定位問題。右圖則是相容性測試報告，主要是用來檢測小遊戲在不同裝置上是否出現黑屏/jserror這樣一些比較嚴重的適配問題。

小遊戲工具鏈未來規劃

這裡是微信小遊戲關於效能優化工具鏈的規劃。今年7月我們在微信小遊戲效能助手給到大家基礎效能指標、評價標準、優化指南，9月份會開放測試雲服務為大家提供效能測試、相容性測試，10月份會對小遊戲資料助手效能模組做進一步升級和優化。

這其中也是瞭解到開發者的一些痛點，我們希望能夠讓開發者可以自定義場景做對比分析，也可以對不同的小遊戲版本之間做分析，最後還會對效能監控做進一步優化，讓開發者可以更加靈活的定製監控策略。

以上是我關於效能分析工具的介紹。在實際工作中，除了瞭解這些分析工具之外，我們又會遇到哪些實際的效能問題呢？這其中有沒有一些值得推薦給大家的優化手段呢？接下來由我的同事蔡凌波為大家做進一步的分享，感謝大家收聽，謝謝！



各位開發者，大家好，我是微信公開課講師蔡凌波，今天想跟大家分享的主題是小遊戲的效能。為什麼要以這個主題來進行分享呢？


是因為小遊戲的效能直接關乎到使用者的留存和開發者直接的收益情況。

小遊戲啟動效能

啟動效能關乎到小遊戲的使用者能不能真正進入到小遊戲；而執行時期的效能關乎到使用者在進入小遊戲後會不會因為網路延遲或卡頓等現象再次流失。

我們首先來看一下啟動效能，我會從背景、分析、方案、案例幾方面加以闡述。

從這個折線圖可以看到隨著啟動時間的延長，使用者的流失數目越來越高，底部陰影面積是使用者流失的總人數。我們如果提升了啟動速度，就能降低使用者流失數目，進而降低流失率。

右邊的圖是小遊戲的啟動漏斗情況。這個漏斗包含了小遊戲首次啟動和二次啟動情況。大家可以猜測一下，如果一個小遊戲啟動時間大概5s左右，那它的使用者流失率大概多少？會達到20%-30%。

在廣告場景下，由於小遊戲大部分是首次啟動，所以使用者流失會更多。廣告場景下，小遊戲啟動時間7s左右時間，使用者流失率會達到30%-50%。因此我們一定要優化啟動效能。

那啟動具體分成哪些階段，又從哪裡能看到小遊戲具體的啟動效能呢？

從中間的流程圖可以看到，小遊戲的啟動主要包含了以下幾個階段，主要包含了下載程式碼包、框架和環境準備、js注入和首屏渲染準備階段。

小遊戲資料助手上可以看到小遊戲的留存情況，各個階段的留存率具體是什麼意思呢？程式碼包的留存率是指我們下載或載入完程式碼包之後使用者數與初始使用者數的比值；首屏留存率則是首屏留存使用者數與初始使用者數的比值。

小遊戲資料助手上的啟動耗時具體是指什麼呢？程式碼包載入耗時是指從啟動開始到程式碼包下載完成階段的耗時；

剩餘階段的耗時則會被計算成首屏渲染耗時。小遊戲資料助手上面的總耗時則是指整個階段的完整耗時。我們已經知道啟動階段具體包含什麼，也知道怎麼檢視自己當前小遊戲的效能。

那我們應該如何去提升啟動效能呢？

平臺側已經有一些舉措來提升啟動效能。比如安卓平臺會進行程式預載入，我們也會提前進行基礎庫的注入。安卓平臺還會生成CodeCache來提升二次啟動速度。

從開發者的角度可以從以下三個階段提升啟動效能，包括下載程式碼包、框架和環境準備以及首屏渲染階段。首先我們來看下載程式碼包階段。

從左邊這張圖中可以看到程式碼包大小和下載時間基本呈現線性分佈形式（見PPT），如果我們想要優化程式碼包的下載耗時，就需要降低程式碼包的大小。

降低首包大小主要有以下幾個手段：精簡包內資源，包括程式碼資源、圖片資源，比如使用圖集方式；使用平臺側提供的分包能力和引擎外掛能力。引擎外掛能力是什麼呢？

小遊戲程式碼包構成中引擎佔據了非常大的比重。 我們提供的能力呢，就是直接將這份引擎程式碼直接在客戶端快取，讓不同的小遊戲能夠共用。啟動一個新的小遊戲時，只需要下載各自少量的業務邏輯程式碼就可以，這樣就能極大的提升啟動速度。

除了下載程式碼包階段，在框架、環境準備以及首屏渲染準備階段，我們能做一些什麼事情？平臺側提供了預下載能力。

首屏渲染準備階段主要包含檔案下載、檔案處理兩個部分，而在框架和環境準備期間是CPU密集時期。如果把檔案下載部分和框架、環境準備並行執行，就能充分利用上這段網路空閒時期，來提升大家的啟動速度。預下載資源以及分包資訊，可以直接在game.json裡進行配置，某大dau小遊戲接入預下載能力之後啟動耗時降低了600毫秒。

除了接入預下載能力之外，我們還可以降低首屏渲染需要的資源數目， 儘快地進行渲染。我們已經知道了啟動優化手段，接下來具體以一個案例形式看一下。

以星途為例，星途首先精簡自己的程式碼，使用圖集方式，使程式碼包大小從3.7兆直接降到1.6兆，啟動耗時從5s降低到2.5s，流失率有50%的降低。之後星途又接入了引擎外掛能力，下載耗時又有一定程度的降低，流失率降低了60%。除了技術手段進行啟動優化之外，從產品或者設計角度有沒有辦法提升啟動效能？

星途的啟動流程，是一個小火箭冉冉升起的過程，星途利用這個動畫時間下載自己的資源，這樣就能儘可能地精簡首包大小。

再簡單小結一下如何提升啟動效能。

首先，下載程式碼包階段可以儘量精簡包內資源，可以使用平臺側提供的分包或者引擎外掛能力；框架、環境的準備和首屏渲染準備階段，可以接入平臺側提供的預下載能力，也要儘可能地降低首屏需要的資源數目，儘快的進行渲染。

小遊戲執行優化效能

已經優化了啟動效能，執行過程中的網路延遲或卡頓等問題就成了使用者流失的第二個攔路虎，我們也要儘可能優化執行時期的效能。

我將主要從CPU耗時優化、記憶體、網路幾方面加以闡述，為大家介紹一下如何排查這些方面的問題以及具體的優化手段。

小遊戲資料助手上面已經可以展示各自小遊戲的CPU均值情況，接下來我們也會將卡幀和低幀的資料展示出來。

那針對卡幀的情況，如何去排查熱點函式呢？

Android 7.0.6之後，開發版和體驗版我們提供了CPU Profile的功能， profile檔案能使用微信開發者工具或者Chrome瀏覽器開啟，檢視js函式的耗時情況。

以圖中為例，可以很明顯地看到updaleAnimator 這個函式耗時非常長，是我們需要重點優化的。記憶體方面，安卓7.0.6之後提供了記憶體快照，能夠檢視到js記憶體。

接下來將要釋出的版本上，會在效能皮膚上為大家提供更多記憶體情況的展示，比如會展示出Graphics/Java/Native記憶體，能夠讓大家更有針對性的優化。

在知道了小遊戲的記憶體情況之後，平臺側提供什麼樣的介面呢？

在切換場景等情景下，要及時呼叫平臺層提供的triggerGC介面清理記憶體，同時我們也會提供onMemoryWaring的介面，為大家提供記憶體吃緊的預警。

在網路方面，小遊戲資料助手已經有了網路效能的概覽介紹，還提供錯誤分析功能。以某一個介面為例，錯誤率已經達到11%多，我們應該儘早排查問題。

除了網路介面的錯誤分析，小遊戲資料助手上還展示了網路介面延遲情況。以某一個介面為例，延遲已經達到將近6s，大概率這個介面已經掛掉，需要提高警惕，儘早排查問題。

同時，平臺側還提供幀同步整套能力，對於RTS、MOBA、IO類的小遊戲可以考慮接入。這套幀同步方案的優勢在於無須開發後臺，可以無縫接入。底層採用UDP實現，效能方面優異一些。

我們再簡單小結一下小遊戲執行時期有什麼方法和手段提升效能。

在耗時方面Android平臺提供了CPU Profile工具，讓大家檢視js的耗時。記憶體方面提供了js的記憶體快照功能，接下來的Android版本也會為大家提供更多的記憶體資料。

此外，平臺側還提供了記憶體清理和告警介面。網路方面，小遊戲資料助手提供了網路介面錯誤以及耗時統計，平臺側也提供了幀同步整套方案。

我的分享到這裡，如果大家有什麼效能方面的問題，歡迎在開發者效能論壇上與我們保持溝通和聯絡，謝謝大家！


原文：https://mp.weixin.qq.com/s/sWe8rZ-xKDT70TSbZMD6ag