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

在剛剛落幕的微信小游戲開發(fā)者大會(huì)上，樂元素開心消消樂技術(shù)負(fù)責(zé)人孔祥一圍繞著《開心消消樂》遷移微信小游戲平臺(tái)的流程，就遷移過程中的挑戰(zhàn)、詳細(xì)步驟和優(yōu)化手段進(jìn)行了詳盡的分享。

以下為分享內(nèi)容全文：

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

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

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

主要挑戰(zhàn)的內(nèi)容，剛才已經(jīng)敘述了絕大部分挑戰(zhàn)的主要內(nèi)容，我們把最前期最核心的內(nèi)容需要提出來，選一個(gè)最小級(jí)，我們第一版上線，主線關(guān)需要上線1005關(guān)，后期調(diào)整到了2000多關(guān)。另外一點(diǎn)，《開心消消樂》是一款已經(jīng)在運(yùn)營的游戲，所以我們希望給用戶一個(gè)一致的體驗(yàn)，不管是在APP玩也好，還是在小游戲玩也好，我們希望你的賬號(hào)是互通的，數(shù)據(jù)資產(chǎn)是一致的，參加的一些活動(dòng)、領(lǐng)取的道具、素材資源，在小游戲也好、在APP都可以通用，所以我們需要一個(gè)通用的體系。一些核心的功能、道具、支付等等都需要支持，另外就是在小游戲上我們需要一個(gè)比較好的體驗(yàn)，幀率需要達(dá)標(biāo)、啟動(dòng)時(shí)間需要達(dá)標(biāo)。對(duì)我們來說挑戰(zhàn)最大的方面就是時(shí)間很短，我們接到任務(wù)的時(shí)候大概只有3個(gè)月的時(shí)間，需要盡快上線，因?yàn)橛螒蜷_發(fā)團(tuán)隊(duì)基本上接到的所有任務(wù)都是時(shí)間很緊張，都需要趕工期、趕市場節(jié)奏，所以當(dāng)時(shí)的時(shí)間是非常緊的。小游戲的運(yùn)行性能，因?yàn)槭窃贕S環(huán)境，運(yùn)行效率本身就打了一個(gè)很大的折扣，平均測算下來，不管是官方宣布的還是我們自己測的，可用性能大概是net5的1/3左右，并且還不能用多線層相關(guān)的技術(shù)，所以對(duì)性能優(yōu)化的挑戰(zhàn)也非常大。

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

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

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

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

第一個(gè)版本跑起來了之后，很自然的就會(huì)遇到很多問題，主要是卡頓發(fā)熱、幀率不高、內(nèi)存不足經(jīng)常卡死、卡死報(bào)錯(cuò)，經(jīng)常卡，然后效果不對(duì)，最小驗(yàn)證集，所以把美術(shù)的資源壓縮率非常高，基本上技術(shù)是不考慮效果的，只要能跑起來能看到就行。但是這個(gè)效果像美術(shù)肯定是不認(rèn)可的，所以后期美術(shù)也需要把壓縮紋理往上調(diào)，把效果做起來。紋理品質(zhì)這些方面需要和美術(shù)一起共同在效果和資源中間取一個(gè)平衡點(diǎn)，爭取能跑起來。

下面也會(huì)介紹很多優(yōu)化的手段，但是優(yōu)化的前提就是能形成量化，把我們的這些指標(biāo)能量化出來，后面才能談具體優(yōu)化的動(dòng)作、過程和效果。量化的性能分析工具，這也是大家耳熟能詳?shù)模琔nity的這一套，Unity Profiler、Memory Profiler、Frame Debugger

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

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

對(duì)內(nèi)存優(yōu)化的通用手段就是解決內(nèi)存泄漏問題，因?yàn)閯偛乓蔡岬搅颂摂M機(jī)套虛擬機(jī)，這幾層的內(nèi)存都需要精確控制，Lua也有內(nèi)存泄漏的問題，GS也有。在初期的移植，我們以快為準(zhǔn)，后期逐步迭代的過程中要解決大量內(nèi)存泄漏的問題。以及資源按需加載，內(nèi)存還是非常敏感的，壓縮紋理格式、WASM分包，不管是提升加載速度也好、降低內(nèi)存使用量都非常有幫助。對(duì)象池的使用，在游戲上GC的問題還是比較嚴(yán)重的。另外就是團(tuán)結(jié)引擎對(duì)小游戲的導(dǎo)出也做了很多對(duì)標(biāo)優(yōu)化工作，所以團(tuán)結(jié)引擎導(dǎo)出還是有比較大的提升效果。

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

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

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

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

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

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

同理音效播放也是遇到類似的問題，小游戲?qū)PI的封裝調(diào)用的時(shí)候性能是有限的，所以這塊也需要注意。另外就是游戲?qū)σ魳凡シ疟旧淼墓δ苄枨笫欠浅５偷模灰懿シ牛シ磐旮嬖V就可以了，我不需要中間插播、回放等功能，所以我們把相關(guān)代碼也都裁掉了，對(duì)運(yùn)行效率有所提升，對(duì)代碼量也降低了很多。

震動(dòng)效果是同理的，我們在華為P20機(jī)器上的震動(dòng)效果也能測出來，當(dāng)時(shí)頻繁調(diào)用這些震動(dòng)效果耗時(shí)非常多，一次耗時(shí)可能20多毫秒，而且小游戲?qū)φ饎?dòng)可控制的層次也是比較少的，只有高、中、低三種震動(dòng)效果，沒有震動(dòng)曲線這些，這些都不用，所以我分裝成三種函數(shù)，這樣對(duì)震動(dòng)相關(guān)優(yōu)化也非常顯著，20多毫秒能降到幾豪邁以內(nèi)。

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

經(jīng)過以上所有努力，我們8月份正式上線測試，這是當(dāng)時(shí)的現(xiàn)場，整個(gè)過程大概有100天，過程中做了非常多的工作，在一些小游戲開發(fā)者聽來，100天他們可能開發(fā)了好幾款新游戲了，但是對(duì)傳統(tǒng)游戲來說我們一點(diǎn)業(yè)務(wù)邏輯都沒做，只是把原生的遷過來就花了這么多工作。這個(gè)工作也是在我們團(tuán)隊(duì)很多部門共同通力配合的情況下，并行執(zhí)行的情況下才能做到，所以傳統(tǒng)游戲在微信小游戲上還是有一定難度的。

總結(jié)起來，在我們遷移過程中最核心的參考資料就是這幾項(xiàng)，一個(gè)是微信小游戲的官方API指南，這個(gè)幫助非常大。另外一方面，我們用Unity開發(fā)小游戲，我們用引擎導(dǎo)出的時(shí)候有很多優(yōu)化項(xiàng)，這個(gè)文檔在另外一個(gè)網(wǎng)站上，大家也需要關(guān)注一下。

總體的一致心得就是這幾點(diǎn)：

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

2.盡量讓所有任務(wù)并行，做好相關(guān)支持工作來加速開發(fā)進(jìn)程。小游戲開發(fā)可以并行的工作對(duì)我們來說是非常多的，引擎可以并行、API接入可以并行、Spine渲染優(yōu)化可以并行、業(yè)務(wù)移植可以并行、美術(shù)相關(guān)的迭代可以并行、產(chǎn)品的設(shè)計(jì)也可以并行，所以我們把所有東西都并行起來，才能把整個(gè)時(shí)間往前移。

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

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

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