6月25日，在騰訊舉辦的微信小游戲開發(fā)者大會上，樂元素的祥一分享了《開心消消樂》遷移小游戲平臺的完整歷程。 這款上線超過十年的三消游戲，至今依然保持月活超1.3億、暢銷榜常駐Top20的穩(wěn)定表現。2024年初正式上線微信小游戲后，很快再次吸引了大量玩家關注。 在這場遷移中，他們遇到的最大難題是：原本跑在手機App上的復雜動畫和上萬關卡內容，如何在小游戲這種性能受限的環(huán)境里流暢運行？團隊最終用「先做減法，再做加法」的思路，從剔除冗余功能到并行推進各項開發(fā)，硬是在100天內完成了上線。 以下為分享內容整理，為方便閱讀，內容有所調整。  大家好，我叫祥一，來自樂元素，今天給大家分享《開心消消樂》團隊將APP手游遷移到小游戲的整個過程。 《開心消消樂》是一款國民游戲，相信在座的很多人或者自己的親友都曾玩過這款游戲。 我們在2014年在iOS平臺上線，到目前為止，游戲運營已經有11年以上的時間。我們陸陸續(xù)續(xù)又發(fā)布了安卓版本，并在2024年上線了鴻蒙版本。目前，主線關卡已經超過一萬關，每周會更新30個以上的關卡。 在這么多關卡內容和活動玩法的基礎上，將這款App游戲遷移到小游戲平臺，工作量是非常大的。因為歷史積累下來的功能、活動和代碼非常多，而且還需要兼容已有的平臺，所以整體工作的復雜度比較高。 我們遷移的主要挑戰(zhàn)是將App端的整個技術架構遷移到小游戲端。 App以前是用Cocos加Lua開發(fā)的，現在要遷移到小游戲端，而小游戲只能運行在App中的一個GS環(huán)境下。如果在小游戲中繼續(xù)用Lua去運行，就會形成一個虛擬機中套一個Lua虛擬機的模式。但我們無法避免這種模式，否則App開發(fā)業(yè)務和小游戲開發(fā)業(yè)務就需要走兩套代碼，開發(fā)成本會非常高。 因此，在小游戲端，我們選擇的架構是基于WebGL，用Unity導出代碼，并且業(yè)務邏輯依然跑在Lua中。不過，這種情況下小游戲中Lua的運行效率會相對低一些。 我們在前期把最核心的內容提煉出來，選擇了最小上線規(guī)模。做第一版時，主線關卡需要上線1005關，后期調整到了2010關。 另外，《開心消消樂》是一款已經在運營的游戲，所以我們希望給用戶提供一致的體驗。無論是在App上玩還是在小游戲中玩，我們都希望用戶賬號是互通的，數據資產是一致的，參與的活動、領取的道具和素材資源在兩個平臺都可以通用。 因此，我們需要一個通用的體系，一些核心功能、道具和支付都需要支持。  此外，在小游戲上我們也希望能夠提供良好的體驗，幀率需要達標，啟動時間也需要達標。 對我們來說，挑戰(zhàn)最大的一點是時間非常緊迫。我們接到任務的時候，大約只有三個月的時間需要完成上線，所以當時的時間壓力非常大。 小游戲的運行性能也是一個挑戰(zhàn)，因為它運行在GS環(huán)境下，效率本身就打了很大的折扣。根據官方公布的測試結果和我們自己的測算，可用性能大概只有Net5的三分之一左右，而且還無法使用多線程相關的技術，因此在性能優(yōu)化上面臨很大的挑戰(zhàn)。  遷移工作的第一個步驟是先確認我們的最小驗證集。 《開心消消樂》的核心玩法就是打關，如果打關無法正常進行，后續(xù)工作基本也無法開展。UI的展示主要使用的是Spine動畫，如果運行效率非常低，后續(xù)幾乎所有方案都需要推倒重來。在最小驗證集通過之后，我們開展了業(yè)務邏輯移植、小游戲平臺能力接入、測試和優(yōu)化，最后完成上線并進行功能迭代和玩法優(yōu)化。 前期的最小驗證集對我們來說是挑戰(zhàn)最大的一部分。 我們的游戲是在Cocos2dx基礎上開發(fā)的App版本，當時是為了滿足產品需求以及快速上線驗證，功能開發(fā)也很順利。但隨著這幾年的運營，我們發(fā)現產品在表現力、玩法內容以及3D建模等方面都有了更多新的需求。 因此，我們此前就已經開始準備Cocos向Unity的遷移。這次遷移也借機將發(fā)行小游戲時Unity版本導出小游戲作為主攻目標。不過在客戶端上，我們還需要驗證運行時能否在WebGL上正常運行。  幸運的是，我們Cocos導出的版本在去除聯網功能后，在WebGL版本上高端機可以打出50幀左右，低端機也能達到十幾幀，這讓我們看到了希望，至少運行起來沒有太大問題。 在Unity上，我們同樣需要驗證運行效果。我們測試了一個典型的Spine動畫場景，放入了很多動畫，運行效率基本達標，但仍有不少動作需要進一步優(yōu)化。 工作流的目標和整體框架已確定，接下來的核心工作包括代碼和資源的遷移——相關內容需要遷移到WebGL上。 在小游戲上，所有實時加載動作都是異步加載，而App上由于性能好，很多加載是同步的。這些在小游戲里無法使用，所以App端底層架構中最基礎的文件加載、資源加載都需要重新遷移。 我們通過分析配置文件和Lua代碼，將所有引用到的資源進行自動化分類，按不同的障礙名稱、不同的關卡段分配到Unity的不同BundleGroup上，并自動化生成Bundle。 經過以上幾個步驟，我們基本完成了一個能夠在客戶端、Unity和Web端正常運行的完整版本。下一步就是處理平臺差異和適配的問題。 在小游戲平臺，我們需要首次接入許多第三方接口，還需要對接小程序的API和開發(fā)能力，支持登錄、支付、廣告等相關功能。 第一個版本跑起來后，我們很自然地遇到了很多問題，主要包括卡頓發(fā)熱、幀率不高、內存不足導致的卡死或報錯、效果不符合預期等。 由于最小驗證集階段對美術資源壓縮率要求非常高，技術層面主要是保證跑起來和可見，效果方面美術團隊肯定無法接受。因此，后期需要在美術壓縮紋理上適當提升，逐步完善效果。紋理品質等方面需要與美術團隊一起在效果和資源之間尋找平衡，爭取既能跑起來又能滿足效果要求。 后面還會介紹很多優(yōu)化手段，但優(yōu)化的前提是能夠形成量化指標。只有量化了性能數據，后續(xù)的具體優(yōu)化動作、過程和效果才有依據。 我們使用的性能分析工具大家也比較熟悉，比如Unity的UnityProfiler、MemoryProfiler、FrameDebugger，這些工具比較完備，也是我們選擇Unity的原因之一。 微信開發(fā)者工具也提供了成熟的工具，如Performance工具和CPUslowdown功能，可以放大CPU的運行負擔，幫助我們更容易發(fā)現CPU層面的問題。  在開發(fā)機上跑得再好、再流暢，也不能代表用戶的實際體驗效果，因此最終我們真正關心的是真機上的表現。 將真機Profile和Performance工具導出的數據導入到Chrome工具中后，我們看到的還原效果與開發(fā)機上的效果基本一致，這套工具也非常好用。 對于小游戲的實際優(yōu)化手段，文檔和開發(fā)者最佳實踐中也列出了非常多的細項，我們基本上都一一落實。不過對我們來說，最核心的優(yōu)化還是集中在兩個方面：內存優(yōu)化和計算優(yōu)化。其他大多數優(yōu)化措施都是圍繞這兩點的擴展或延伸。 在小游戲，尤其是微信小游戲上，iOS的高性能+模式非常關鍵。它決定了我們的可用內存和效率提升。 在iOS高性能+模式下，微信小游戲會把小游戲運行在一個單獨的進程中，內存空間的分配完全不同，這對內存使用幫助很大。另外，WASM分包對內存分化效果顯著；降低渲染分辨率也是一種立竿見影的優(yōu)化措施。 雖然方法簡單，但對于我們最初App端設計720寬的渲染效果而言，將渲染降低到目標分辨率再放大，不論是對幀率的提升還是內存占用的降低，都非常明顯。預加載資源和用戶數據在小游戲上也極為敏感，不管是使用量還是加載速度，尤其影響啟動時間。因此，能并行處理的操作我們盡量并行執(zhí)行，以顯著提高加載速度和啟動效率。  在內存優(yōu)化方面，通用的手段主要是解決內存泄漏問題。 由于存在虛擬機套虛擬機的結構，各層內存都必須精確控制，Lua和GS環(huán)境本身也可能出現內存泄漏。初期移植階段我們以速度優(yōu)先，后期在迭代過程中逐步解決了大量內存泄漏問題。同時，資源按需加載、壓縮紋理格式、WASM分包等措施都對提升加載速度、降低內存占用有明顯幫助。對象池的使用也能緩解GC的壓力。 Unity對小游戲導出的優(yōu)化工作也做了很多對標改進，因此通過Unity導出在性能上有明顯提升。對于GC頻率，iOS和安卓的處理策略不同。微信小游戲在JS層會每10秒自動GC一次，但在Lua上我們起初沒有設置定時GC，這導致大掉落或關卡運行時可能引發(fā)內存問題。后來我們在iOS上定時GC，在安卓上考慮到低性能設備無法頻繁GC，只在每局結束后觸發(fā)一次GC。 WASM分包是效果顯著的內存優(yōu)化點。我們的總函數量大約11萬個，首包包含約1.8萬個函數，未壓縮情況下帶符號表的包大小約55MB。分包后首包約15.8MB，分包文件約40MB，兩者不帶符號表時容量接近不分包時的體積。分包后代碼量反而增加，是因為引入了大量相關檢測、參數準備、異常處理等工作，導致代碼存在冗余。 此外，通過br壓縮可顯著降低首包體積，從15.8MB壓縮到3.4MB。分包最大好處在于內存占用大幅降低。官方文檔指出GS代碼約1MB對應內存占用10MB，分包40MB大約能降低400MB的GS內存占用，為美術素材等留出空間，效果提升明顯。 在計算優(yōu)化方面，我們重點解決了幾個問題。 小游戲性能大約只有Net5的三分之一，計算優(yōu)化如果不到位，性能壓力會很大。我們去掉了大量try-catch函數，因為WASM轉換后代碼膨脹且檢查開銷高。虛擬機嵌套結構導致參數傳遞存在多層裝箱、拆箱，參數量大或參數個數多時影響更為明顯。  我們也調整了小游戲的補幀邏輯。《開心消消樂》的運行邏輯分為邏輯運算和渲染運算。邏輯幀定在30幀，如果大掉落時單幀運算超時，可能會出現卡頓。若持續(xù)卡頓，在用戶體驗上就像進入“子彈時間”。在App端，大掉落通常只影響1至2幀，很快能追回。但在小游戲上無法追幀，會導致連鎖卡頓。 因此我們優(yōu)化補幀策略，僅追部分幀，合并可合并的邏輯，減少雪崩現象。同時，我們優(yōu)化了Lua-C#參數傳遞和JS接口調用，重點在業(yè)務邏輯上改進Lua代碼結構，以應對Lua執(zhí)行效率的局限。 在優(yōu)化Spine動畫的實踐中，我們始終圍繞兩個核心問題展開：計算消耗和內存占用。 Spine是《開心消消樂》關卡內的主要表現形式，所有關卡障礙和小動物絕大多數都采用Spine動畫。在App端，Spine動畫表現效果好，優(yōu)化空間大，但在小游戲端，這類動畫帶來了明顯的計算壓力和內存問題。 在內存方面，我們的優(yōu)化措施包括降低頂點數、減少網格，以減輕計算負擔。同時，在播放一致的Spine動畫進入靜止狀態(tài)后，我們會將其替換為靜態(tài)圖，以降低內存占用和計算開銷。對于可以替換的部分，我們盡量替換；對于無法替換的動態(tài)內容，我們采取減幀或抽幀的方式減少開銷。 另一個重點是去除或優(yōu)化Clip效果。在App端，美術為了表現力大量使用Clip，但小游戲端無法很好支持，因此我們和美術團隊一起去除了不必要的Clip，并對必須保留的Clip進行了美術和技術兩方面的優(yōu)化，包括減少內存輸出和提高使用效率。  此外，我們引入了Mesh動畫，將Spine動畫計算過程中的三角形網格預先計算好并存儲起來，運行時直接引用靜態(tài)Mesh資源，以內存換取CPU性能。這種方法在無法提前計算骨骼位置、需要與業(yè)務邏輯緊密關聯的場景中無法使用，例如連續(xù)顯示進度的星星瓶等。但我們在這些場景中也進行了優(yōu)化，將連續(xù)進度細化為10個階段，以降低計算壓力，效果基本能達到預期。 在API相關優(yōu)化方面，小游戲對文件操作和API調用性能有限，且嵌套虛擬機結構增加了開銷。在App端，為實現崩潰狀態(tài)恢復，玩家每次操作都需將狀態(tài)寫入磁盤。這在小游戲端導致明顯卡頓，因此我們去掉了小游戲端的頻繁文件操作。 同理，音效播放也受到類似限制，我們簡化了音樂播放功能，裁剪掉不必要的代碼以提升效率并減少代碼量。震動效果也經過優(yōu)化，在小游戲中只保留高、中、低三種震動等級，去掉曲線控制，通過封裝函數將震動耗時從20毫秒以上降到幾毫秒以內。 Lua代碼優(yōu)化也是重點。我們對比了Lua文本模式，發(fā)現加載效率影響不大，但文本代碼體積更小，內存占用更低。雖然查錯時可讀性下降，但結合字節(jié)碼和文本混用，能在保持性能的同時確保定位問題時信息完整。 經過上述各項優(yōu)化，我們在約100天內完成遷移并于8月上線測試。這期間沒有新增業(yè)務邏輯，僅完成從原生到小游戲的遷移，工作量之大可見一斑。這離不開團隊各部門的協(xié)同配合和多任務并行推進。 總結經驗，我們的核心做法包括： 1.先做減法，再做加法。優(yōu)先剔除一切不必要內容，驗證最小可用框架。一旦驗證通過，再逐步補充新功能。技術選型如果一開始走彎路，代價會非常高。 2.盡量讓所有任務并行，做好相關支持工作來加速開發(fā)進程。引擎優(yōu)化、API接入、Spine渲染優(yōu)化、業(yè)務移植、美術迭代、產品設計均可并行。只有把所有東西都并行起來，才能把整個時間往前移。 3.產品做好短期和長期規(guī)劃，為此制定可行的開發(fā)計劃。《開心消消樂》作為運營十年的游戲，內容量龐大，必須規(guī)劃好哪些內容真正需要遷移到小游戲平臺，避免無效開發(fā)。 4.與公司內部和外部專家保持交流，以快速獲取有效方案。項目過程中，我們得到了微信小游戲團隊和Unity團隊的大力支持，極大推動了方案落地。  以上就是我的分享，謝謝大家！ |
|
|
