“國民”三消游戲《開心消消樂》上線十余年，常年穩坐手游榜單TOP20，今年年初，該游戲正式登錄小游戲平臺后，依然輕松囊括了大批新老玩家青睞。但在實際的平臺遷移過程中，開發團隊也遇到了很多棘手的挑戰和難題，整個移植的過程大概花了100天。

在剛剛落幕的微信小游戲開發者大會上，樂元素開心消消樂技術負責人孔祥一圍繞著《開心消消樂》遷移微信小游戲平臺的流程，就遷移過程中的挑戰、詳細步驟和優化手段進行了詳盡的分享。

以下為分享內容全文：

大家好，我叫孔祥一，來自樂元素，今天為大家分享的內容就是《開心消消樂》團隊把我們APP手游遷移到小游戲的整個過程實錄。

首先，《開心消消樂》這款游戲基本是一款國民游戲，大家都很熟悉，相信在座很多人或者是自己的親友也在玩這款游戲。我們在2014年ios就上線了，到目前為止已經11年以上，我們陸陸續續又發布了安卓版本，以及在2024年上線了鴻蒙版本，目前主線關已經超過1萬關，每周更新30個關卡以上。在這么多的關卡內容上，以及活動玩法的基礎上，這個APP游戲遷移到小游戲工作量是非常大的，因為歷史積累的功能活動、歷史代碼會非常多，并且很多已有的平臺需要兼容，所以工作復雜度還是比較高。

我們遷移主要挑戰就是把APP端的整個技術架構遷移到小游戲端，最核心的地方就是APP以前是用Cocos開發的，Cocos加Lua，現在我們要遷移到小游戲端，小游戲又只能運行在APP中的一個GS環境下，所以在小游戲中如果還用Lua去運行的話，基本是在一個虛擬機中套一個Lua虛擬機的模式。但是我們又不能避免這個模式，否則的話可能APP開發業務和小游戲開發業務需要走兩套代碼，那個開發成本太高，我們是不可能接受的。所以在小游戲端我們選擇的架構也是WebGL上，用Unity導出代碼，并且在業務邏輯都跑在Lua中，小游戲中的Lua運行環境的運行效率也會相對低一些。

主要挑戰的內容，剛才已經敘述了絕大部分挑戰的主要內容，我們把最前期最核心的內容需要提出來，選一個最小級，我們第一版上線，主線關需要上線1005關，后期調整到了2000多關。另外一點，《開心消消樂》是一款已經在運營的游戲，所以我們希望給用戶一個一致的體驗，不管是在APP玩也好，還是在小游戲玩也好，我們希望你的賬號是互通的，數據資產是一致的，參加的一些活動、領取的道具、素材資源，在小游戲也好、在APP都可以通用，所以我們需要一個通用的體系。一些核心的功能、道具、支付等等都需要支持，另外就是在小游戲上我們需要一個比較好的體驗，幀率需要達標、啟動時間需要達標。對我們來說挑戰最大的方面就是時間很短，我們接到任務的時候大概只有3個月的時間，需要盡快上線，因為游戲開發團隊基本上接到的所有任務都是時間很緊張，都需要趕工期、趕市場節奏，所以當時的時間是非常緊的。小游戲的運行性能，因為是在GS環境，運行效率本身就打了一個很大的折扣，平均測算下來，不管是官方宣布的還是我們自己測的，可用性能大概是net5的1/3左右，并且還不能用多線層相關的技術，所以對性能優化的挑戰也非常大。

遷移工作我們主要是這樣設計的，第一個步驟就是先驗證我們的最小功能級，《開心消消樂》核心玩法就是打關，打關要是打不了，后續工作也基本不用做了，UI的展示，主要使用的Spine動畫，如果運行效率非常低，后面的工作基本上所有方案需要推倒重來。在最小驗證集過了以后我們有業務邏輯移植、小游戲平臺能力接入、測試和優化，最后就是上線、功能迭代玩法。

前期最小驗證集對我們來說是挑戰最大的部分，我們的游戲是在Cocos2dx基礎上開發的APP版本，當時是滿足產品的需求以及快速上線驗證，功能開發也很順利。但是隨著這些年運營效果下來，我們發現產品一些新的需求可能不管是對表現力也好、對玩法內容也好，對一些3D建模的需求也好，都有很多需求，所以我們在之前就開始做Cocos向Unity遷移的準備，正好借這個機會，我們也把發行小游戲的時候就把Unity版本導出小游戲作為一個主攻目標。但是客戶上我們也需要驗證運行時能在WebGL上正常跑起來，還好我們Cocos導出的版本只能打關，排除掉一切聯網的功能的這個版本，在WebGL版本上，在高端機上能運行打50幀，低端機上能運行個十幾幀的狀態，至少這是看到一個希望，運行起來沒有太大的問題。在Unity上我也需要驗證，測試了一個典型的Spine動畫，我們放了很多動畫，運行效率上看看是不是能達標，基本上還算是可以，但是還有許多需要優化的動作。

工作流，我們的目標已經確定了，整體框架已經確定了，工作流上確定了核心的兩點，一個是代碼、一個是資源，需要把相關的遷移到WebGL上。在小游戲上，所有運行實時的加載動作都是異步加載，而APP上面的性能會非常好，所以很多都是同步加載的，但是小游戲里面用不了，所以把APP端底層架構，最基礎的文件加載、資源加載都需要遷移。我們也通過分析配置文件、分析Lua代碼，把所有這些引用到的資源可以自動化分類，按不同的障礙名稱、按不同的關卡段分到Unity不同的BundleGroup上，自動化把這個Bundel打出來。

經過以上幾個步驟，基本上可以出一個完整的版本，能在客戶端運行、能在Unity運行，也能導出到Web端，在小游戲上都能運行起來，這都是沒問題的。我們下一步就需要處理平臺差異和適配的問題，就是我們在小游戲平臺有很多第三方接口，首次需要接入進來，接入進來以后也需要接入小程序的API和開發能力，支持登錄、支付、廣告等等相關內容。

第一個版本跑起來了之后，很自然的就會遇到很多問題，主要是卡頓發熱、幀率不高、內存不足經常卡死、卡死報錯，經常卡，然后效果不對，最小驗證集，所以把美術的資源壓縮率非常高，基本上技術是不考慮效果的，只要能跑起來能看到就行。但是這個效果像美術肯定是不認可的，所以后期美術也需要把壓縮紋理往上調，把效果做起來。紋理品質這些方面需要和美術一起共同在效果和資源中間取一個平衡點，爭取能跑起來。

下面也會介紹很多優化的手段，但是優化的前提就是能形成量化，把我們的這些指標能量化出來，后面才能談具體優化的動作、過程和效果。量化的性能分析工具，這也是大家耳熟能詳的，Unity的這一套，Unity Profiler、Memory Profiler、Frame Debugger

，這套工具還是很完備的，這也是我們選Unity的一個原因所在。微信開發者工具也有很多比較成熟的工具，比如Performance，也有提供CPU slowdown的功能，可以放大CPU的運行效果，可以讓我們更容易發現CPU上的問題。在開發機上的跑的效果不管多好多流暢，也不能代表用戶實際體驗的效果，所以最終真機上跑的效果才是我們真正關心的東西，真機Profile+Performance工具導入過來，在Chrome這個工具上能看到這些還原圖，和我們在開發機上看到的效果其實是一致的，這個工具也是非常好用。

對于小游戲的實際真正優化手段，有一些文檔或者開發者最佳實踐上也一條一條列了非常多，我們也是一條一條都做了，但對我們來說最核心的小游戲還是兩點，一個是內存優化、一個是計算優化，其他的基本都是這兩個相優化的擴展或者延伸。小游戲上，尤其是微信小游戲上有一個ios高性能+模式，這是很重要的，因為它決定了我們的可用內存是多少，效率提升是什么樣的，畢竟在ios高性能+的模型下，微信小游戲把小游戲運行在一個單獨的進程中，內存空間完全不一樣，對我們內存使用有很大的幫助。另外就是WASM分包，對內存分化很顯著，降低渲染分別率，這是立竿見影的效果，雖然很簡單，但是對我們的游戲最初在APP端涉及到分辨率就是設計720寬的效果來看，渲染到目標分辨率然后再放大，對幀率的提升以及對內存占用降低是非常明顯的。另外就是預加載資源和用戶數據，在小游戲上非常敏感，不管是使用量也好，還是加載速度也好，尤其是啟動時間，所以能并行的事情我們基本上都并行處理，這樣能極大提高手勢啟動起來的加載速度。

對內存優化的通用手段就是解決內存泄漏問題，因為剛才也提到了虛擬機套虛擬機，這幾層的內存都需要精確控制，Lua也有內存泄漏的問題，GS也有。在初期的移植，我們以快為準，后期逐步迭代的過程中要解決大量內存泄漏的問題。以及資源按需加載，內存還是非常敏感的，壓縮紋理格式、WASM分包，不管是提升加載速度也好、降低內存使用量都非常有幫助。對象池的使用，在游戲上GC的問題還是比較嚴重的。另外就是團結引擎對小游戲的導出也做了很多對標優化工作，所以團結引擎導出還是有比較大的提升效果。

提高GC頻率這塊，在ios和安卓上GC頻率是不一樣的，微信小游戲在JS上有一個10秒鐘自動的GC的流程，在Lua上我們一開始是沒有做的，如果不做的話，在一個大掉落、在一個關卡玩的過程中可能會造成內存的問題，所以后來我們把GC也定時調一下。但是在安卓上這樣調就不可以，安卓有一些低性能的機器，如果要是頻繁GC的話會引起顯著的卡頓，并且安卓對內存的敏感度不如ios這么高，ios大概有1.4G的限制，所以在安卓上我們基本上每局GC一次，在ios上是定時GC。

WASM分包，這也是一個立竿見影效果非常顯著的一個內存優化點，我們的總函數量大概是11萬個函數，首包的函數大概1.8萬，未壓縮的情況下有符號表大概55MB首包，分包之后一個是15.8首包，一個40兆分包，它倆加起來其實都是沒有符號表的，跟有符號表的數量差不多，如果不帶符號表的GS包大概是48兆左右。為什么分包以后會比以前大呢？從右側白色的代碼圖可以看到，真正掉了一行代碼，但是上下有很多相關的準備工作，要檢測函數存不存在、做一些參數準備、做一些異常處理等相關工作，會把這個函數做到冗余的代碼非常多，所以代碼量就上來了。另外一個就是做br壓縮，br壓縮之后可以顯著降低首包下載的大型，可以看到從15.8兆降到3.4兆。分包還有一個最大的優點就是內存降低得非常明顯，因為從官方文檔看看，GS代碼1兆大概對應內存中運行時的占用是10兆，是1：10的關系，所以分包40兆，大概能降低400兆GS代碼的占用，所以對其他功能就會非常友好，把這些內存放在美術素材上，效果提升也非常明顯。

內存優化說完，另一方面就是計算優化，計算優化這塊對我們來說也是一個核心的問題，小游戲性能大概只有net5的1/3，所以計算優化如果不仔細做會有比較大的問題。幾方面，一方面是我們去掉了很多try-cotch函數，變異成WASM后代碼會膨脹，并且很多檢查執勤也非常耗時。另外一個，我們的代碼本身是嵌套虛擬機，所以在參數傳遞時有很多層裝箱、拆箱的過程，所以參數的傳遞量比較大或者參數個數比較多的話，對我們來說影響都不小。另外一個就是調整小游戲的補幀邏輯，《開心消消樂》分兩部分，一個是運行時的邏輯運算、一個是運行時的渲染運算。邏輯運算我們定在固定的數量級上，比如我們就定在30幀，流暢的運行是30幀，但如果某個大掉落非常卡頓的話，這一幀33毫秒不夠算，可能會用的時間更多一些，那就會造成一個卡頓。如果持續卡頓的話，在用戶的角度看來可能就變成一個只占時間的效果，但這不是我們的核心目的，我們希望用戶能見到一個連續的游戲邏輯體驗。所以我們會在計算幀數比較大或者是延遲計算的時候，把下1幀一次算2幀，把這個幀追回來。大家也知道這是一個矛盾的事情，本身是卡頓造成的算不完，算不完還要多算一些新的內容去追這個幀，就更卡頓，這就造成雪崩的問題。在APP端其實這個問題不是很嚴重，因為真正的大降落可能只有1幀、2幀就刷完了，后面可用富余的計算量非常大，所以很快能追回來。在小游戲上就追不回來，真正造成血崩，造成一個連續的像子彈時間的效果，所以我們把這塊也調整了，真正計算幀的時候只追部分的幀，也有可能在1幀中算2幀，稍微能合并的地方合并一下。另外一個部分是優化Luo-C#參數傳遞、JS接口調用，核心問題還是虛擬機嵌套的問題，Lua代碼的執行效率是非常有限的，不是Lua5.3，很多代碼也用不了，所以這邊只能在業務邏輯上優化了很多Lua代碼。

優化Spine動畫的實踐方式，Spine是我們的核心關卡內的表現形式，所有關卡障礙的這些小動物、障礙，絕大多數都是Spine動畫，表現效果也很好，在APP端的優化效果非常明顯，但是在小游戲上就會造成非常多的問題，還是剛才說的計算類問題，還有內存的問題。內存的問題，我們就是優化頂點數、減少網格，同時也能優化計算相關的消耗。另外一方面是替換幀動畫為靜態圖，我們有一些播放一致的Spine動畫，到靜態狀態的時候可能就把它從Spine狀態替換為靜態圖，這樣內存占用也少，有各種各樣的好處。如果能換的話我們肯定都換，有很多能動的東西也換不了，怎么辦呢？就是減幀、抽幀。另外一個特性就是Clip，能遮擋住部分圖源的效果，我們在APP端其實美術用了很多這樣的效果，表現力非常強，但是在小游戲端用不了，所以我們跟美術一起努力，把很多不必要的Clip效果去掉了，必須使用的部分也做了幾部分優化，一個是美術相關的優化、一個是技術相關的，把Clip相關代碼的內存輸出使用上的優化，一會兒也會說到。另外一方面就是使用Mesh動畫，把Spine計算過程中的這些Mesh動畫我們提前算好存起來，然后用靜態的Mesh動畫去播放Spine的整個過程。

關于Spines動畫剛才提到了，它是一個動態的過程，所以需要重新算很多社交點，這些點是動態申請的速度，每一幀都是嚴格匹配的，這就有很多浪費，額外的操作，所以我們把它變成一個串聯共享的靜態，減少這些清理的動作，對函數的性能提升非常明顯，能由8毫秒降到3毫秒以內。Mesh動畫就是提前預渲，把Spine動畫所有三角點提前預算出來，在運行時就不需要再計算了，直接引用靜態的素材資源就可以了，這也是一個用內存換CPU的一個常規技術。然后有一些不能使用的場景，比如說骨骼位置跟業務邏輯相關的，有一些內容，有一些連續顯示進度的星星瓶等效果是不能提前算的，但也有其他優化手段，比如進度是100%，以前是連續流暢的，到現在就分10個進度就好了，也一樣能表現出意圖來，雖然效果上稍微差一些，但基本上是可以接受的。

還有一些方面，就比如說API相關的優化，我們在ios和安卓上對文件操作的性能其實是非常高的，因為現在都是固態的存儲，效率非常高，但是在小游戲上不是這樣的，小游戲上一方面我們是嵌套虛擬機，另一方面小游戲本身對文件操作就有一定限制。我們在對文件操作的時候把一個二進制的數據要寫到文件里，至少得轉成字符串，再通過層層裝箱、封箱、拆箱，從Lua傳到GS，再從GS傳到net5，性能消耗非常明顯，現在這個還原圖是我們一個關卡內達關時的表現，一關在APP端為了做崩潰的時候玩家狀態的恢復，我們是玩家每次操作都需要把當前的斷面狀態存在磁盤上，當APP端及時存儲一點問題都沒有，但是小游戲端就不行了，每一次文件操作從幾十K的數據量都會造成顯著的卡頓，所以這個也不行，我們把小游戲端這些頻繁的文件操作都需要去掉。

同理音效播放也是遇到類似的問題，小游戲對API的封裝調用的時候性能是有限的，所以這塊也需要注意。另外就是游戲對音樂播放本身的功能需求是非常低的，只要能播放，播放完告訴就可以了，我不需要中間插播、回放等功能，所以我們把相關代碼也都裁掉了，對運行效率有所提升，對代碼量也降低了很多。

震動效果是同理的，我們在華為P20機器上的震動效果也能測出來，當時頻繁調用這些震動效果耗時非常多，一次耗時可能20多毫秒，而且小游戲對震動可控制的層次也是比較少的，只有高、中、低三種震動效果，沒有震動曲線這些，這些都不用，所以我分裝成三種函數，這樣對震動相關優化也非常顯著，20多毫秒能降到幾豪邁以內。

Lua代碼這是我們游戲本身的一個特點或者是傳統APP轉到小游戲都是避不開的話題，我們也對比了Lua文本模式，對加載的運行效果其實影響不大，但是大小確實降低了很多。這樣有優點，也有弊端，優點就是代碼相對來說做了一次類似于混淆的動作，占用內存也會減少很多。弊端就是我們在查問題的時候這個對戰是不完整的，是看不到具體的位置，但是如果對這個系統功能比較熟，對自己的代碼比較理解的話能拆出來，但效果也不是很好。但是有另外一個方面，字節碼和文本可以混合使用，把有問題的代碼用文本的方式去執行，這樣對戰信息都是完整的，這是一個比較好的點。

經過以上所有努力，我們8月份正式上線測試，這是當時的現場，整個過程大概有100天，過程中做了非常多的工作，在一些小游戲開發者聽來，100天他們可能開發了好幾款新游戲了，但是對傳統游戲來說我們一點業務邏輯都沒做，只是把原生的遷過來就花了這么多工作。這個工作也是在我們團隊很多部門共同通力配合的情況下，并行執行的情況下才能做到，所以傳統游戲在微信小游戲上還是有一定難度的。

總結起來，在我們遷移過程中最核心的參考資料就是這幾項，一個是微信小游戲的官方API指南，這個幫助非常大。另外一方面，我們用Unity開發小游戲，我們用引擎導出的時候有很多優化項，這個文檔在另外一個網站上，大家也需要關注一下。

總體的一致心得就是這幾點：

1.先做減法，再做加法。把所有能剔除掉的就剔除掉，把最核心能驗證的框架先跑起來，這是我們最核心的一點，如果這一點驗證成功，后面的框架都是沒問題的，如果這一點跑不通，雖然所有問題技術上都能解決，但是技術選型如果要走一次彎路的話，花的時間還是非常多的，所以先做減法，最小集驗證過了，然后后面再加新想、加新的迭代方式去補充相關內容。

2.盡量讓所有任務并行，做好相關支持工作來加速開發進程。小游戲開發可以并行的工作對我們來說是非常多的，引擎可以并行、API接入可以并行、Spine渲染優化可以并行、業務移植可以并行、美術相關的迭代可以并行、產品的設計也可以并行，所以我們把所有東西都并行起來，才能把整個時間往前移。

3.產品做好短期和長期規劃，為此制定可行的開發計劃。《開心消消樂》一款十年的游戲，內容非常多，如果一股腦把所有東西都搬到小游戲上，對我們來說開發壓力也很大，即便技術上實現了，可能也不是產品需求，小游戲的運行策略和APP的運行策略也是不一樣的，所以前期把真正要的東西規劃好，避免彎路，這是非常重要的。

4.與公司內部和外部專家保持交流，以快速獲取有效方案。我們也獲得了微信小游戲團隊的支持、Unity團隊的支持，對我們的幫助也非常大。

我的分享就是這些，謝謝大家！