本文轉載自京東零售官方共享設計平臺 Jelly

作者ID：蹤躍、snandy、張宇

“大師，要如何才能做出一款人見人愛，讓人愛不釋手的小遊戲呢？”清晨的微風吹來，柔和的陽光難擋絲絲涼意，大師輕拂白髯，著那龍頭柺杖朝前一指，湖裡便泛起了漣漪。眾人定睛細視，不禁失聲叫道：“好俊的一條鯰魚！”且看它的遍體紅麟，萬分俊俏，真不愧為攪動 H5 遊戲世界的魔王，前端浪潮的領舞者！諸位看官，閒言少敘，我們便來仔細瞧瞧此等神魚終究有幾多斤兩。

第一章 舉棋不定

技術選型

“來需求啦！”，D 哥風風火火地從衛生間出來，碰到剛沏了一杯咖啡的小 Y，見面就是一巴掌（以示友好），咖啡溢位了幾滴。

“咱們這次的需求挺有意思，待會兒叫上小Z，咱們在會議室碰一下，看看怎麼做。”

“你把我咖啡搞灑了！”

十分鐘後，三人都來到了會議室。

D 哥先介紹需求：“

這次是要做一款互動性比較強的 H5 小遊戲

。 是開局給金幣，使用者用金幣購買 joy，買來的 joy 會按照一定速率產生金幣收益；合成兩隻相同等級的 joy 可以升一級，級別越高，每秒收益的金幣也就越多。”

Y：“賺了那麼多金幣有錘子用？”小Y不改急躁本色，要求D哥快點。

D哥不緊不慢，整理了一下衣領接著介紹：“金幣是遊戲中的虛擬資產，唯一的作用就是購買 joy ，有了 joy 你就可以不斷升級，而達到一定級別後，會觸發隨機事件得到京豆。。。”

Y：“喔！這才對嘛！”

D哥看了小Y一眼：“我剛剛評估了一下，這次需求的在於動畫的製作上，動畫很多也很酷炫，

咱們得選擇一種方式，保證我們的遊戲既好看又流暢

，我想聽聽你們的想法。”

Y：“ 就行！咱們要在 H5 上開發，當然要用 H5 的畫布。並且這也是當前的主流，想實現什麼效果都沒有問題，純手寫程式碼，只要程式碼寫好點，一定能保證程式的流暢性。”

Z：“Canvas 我不是很熟練”，小Z低聲說到，“並且這次的動畫不是有點多？”

D：“沒錯，我也擔心這一點，動畫多是個大問題，寫起來複雜，之後的除錯也會比較麻煩。小 Z，你之前好像有做過 H5 上的動畫？”

Z：“是的，我之前用過 ，不過 lottie 弊端比較明顯，用 AE 生成的檔案太大，對動畫元素多的場景太不友好。咱們這個需求恐怕用不上， 怎麼樣？”

Y：“那不和 Canvas 一個樣？動畫多起來要人命喲！你會畫嗎？”

D：“嗯，我們要爭取做到又快又好地開發，畢竟還有其他需求，不能在細節上花費過多的時間，但是也不能不注重細節。”

Y：“ 加 GIF 吧要不。”

……。。

Z：“要不回去調研一下？”

D：“行，咱們先各自回去研究一下，看看用哪種技術實現起來好一點，散會。”

傍晚，三個人再次來到了會議室。淡橙色的陽光鋪灑在會議桌上，溫暖的氛圍讓小Z想起了童年放學後愉快玩耍的日子。

D：“怎麼樣？有成果嗎？”D哥又是一巴掌（以示友好）。

Y：“別說，真讓我發現一個還不錯的工具！”

Z：“嗯嗯，我也有收穫。”

D：“好！我有個提議，我們便效仿昔日的周郎與孔明，把自己的想法寫到紙上。。。”

Y：“不是寫到手心嗎？”

D：“嗯。。。你寫手心也行，寫完後大家同時亮出，看同也不同。”

於是，三人拿出紙筆，寫下了自己這一下午調研的最終成果。

D：“攤開吧。”

D 哥話音一落，三張白紙便鋪在了一處，上面出奇一致地各自寫著： ！

Y：“媽耶，就是他了！”

第二章 明察秋毫

原理探究

要說這 究竟是什麼來路，為什麼這三人能夠在彼此不知情的情況下都去選擇了它？

D：“小Z，

說說你的理由，為什麼選 Cocos 呢？”

Z：“嗯嗯，那我先說下。咱們的目的是做一款 H5 手遊，動畫多，動畫效果酷炫，遊戲流暢性要求高，考慮到咱們的人力成本有限，能找到一套成熟的技術方案或者技術提供平臺是最好不過的了，我們可以站在巨人的肩膀上，既減少開發時間，又能有效地避免相容性問題和各種 bug 的出現。我朝著這個方向探索了一下，發現了不少優秀的平臺，比如咱們國內做的不錯的白鷺引擎，可以支援微信小遊戲，百度小遊戲等的開發，再比如。。。”

Y：“讓你說為什麼選 Cocos 呢，你說別的幹啥，我來說吧！這種問題肯定是先逛論壇，我逛了一下午論壇，大牛們的口徑很統一，

Cocos 做這種小遊戲沒問題，技術成熟，

案例豐富

，用過都說好。

像《夢幻西遊》、《率土之濱》、《最終幻想》還有《開心消消樂》都是用 Cocos 搞的，還有一些其他的，給你們看官網的介紹圖。”

D：“嗯，好，確實有很多成熟的已經落地的知名遊戲。有了前人開路，我們在開發中遇到的問題應該可以迅速找到解決方案。你們有研究 Cocos 的和沒？”

Y：“哎！又來，這麼枯燥的東西讓小Z說吧。”

大家把目光轉向了小 Z，作為團隊中的保守一派，小Z平時不怎麼發言，對待新技術的探索不如小Y有激情，但是比較熱衷於研究已有技術的底層原理和來龍去脈，越古老的東西他反倒越有興趣。發現大家都在看他，小Z的臉不爭氣地變紅了。

Y：“你害羞個錘子！”

Z：“嗯嗯，那我說下我調研到的一些內容。咱們從剛剛到現在所說的 Cocos 其實是一種廣義的說法，指的更多的是 Cocos 這個品牌或者說是我們要選用的技術棧方向是 Cocos。實際上 Cocos 就是指一個遊戲引擎，開發這個引擎的團隊在2011年底成立，研發出了該引擎和一系列產品，包括遊戲編輯器 和全球流行的開源引擎框架 Cocos2d-x 等。

如果我們確定使用這個技術棧，那麼我們後續要用到的應該是 Cocos Creator 遊戲編輯器。

它提供了一個完整的遊戲開發解決方案，包含了輕量高效的引擎，以及能讓你更快速開發遊戲所需要的各種圖形介面工具。

是這樣的：”

Z：“我再接著說下 Cocos Creator 遊戲編輯器的工作原理。先看我從官網弄來的這張圖，二位可以捋順一下游戲編輯器整個的”

Y：“太複雜了，不看，不看，你直接說。”

Z：“咳，行，簡單說來分為四步：

一、匯入資源；二、搭建場景；三、編寫指令碼；四、預覽釋出。”

Y：“再具體點呢。”

Z：“第一步匯入的資源可以是圖片、圖集、聲音、TypeScript 指令碼、JavaScript 指令碼或者已有專案等。匯入後，開始編輯場景。”

Y：“等一下，什麼是場景？”

Z：“在 Cocos Creator 中，遊戲場景（ Scene ）是開發時組織遊戲內容的中心，也是呈現給玩家所有遊戲內容的載體。

遊戲場景中一般會包括以下內容：

場景影象和文字

角色

以元件形式附加在場景節點上的遊戲邏輯指令碼

當玩家運行遊戲時，就會載入遊戲場景，遊戲場景載入後就會自動執行所包含元件的遊戲指令碼，實現各種各樣開發者設定的邏輯功能。

所以除了資源以外，遊戲場景是一切內容創作的基礎。

可以簡單地把場景理解成一個總的節點，掛到這個總節點下的其他資源便都屬於這個場景，我們可以預覽一個場景下的動畫，不同場景的動畫可以切換。比如你玩遊戲過了第一關，到了第二關，就是一個場景切換。”

Y：“明白！”

Z：“第三步是編寫指令碼，目前 Cocos Creator 支援 和 兩種指令碼語言。透過編寫指令碼元件，並將它賦予到場景節點中來驅動場景中的物體。對了，剛剛我們說到掛在場景下面的其他資源，在 Cocos 中都叫（ Node ），可以看下這張圖。”

Z：“我們在第一步匯入的資源放在了左下角的資源管理器裡並建立了一個場景 helloworld，雙擊這個場景檔案就可以進入第二步：編輯場景。雙擊後，左上角那裡的層級管理器就會展示當前場景的掛載情況，可以直接拖拽資源管理器中的圖片等資源到該場景下，也可以直接在場景下面新建空節點。

靜態資源準備好了，我們需要讓動畫動起來或者讓節點之間有所聯絡，就可以進入第三步：編寫指令碼。我們在資源管理器中引入指令碼 HelloWorld。ts，雙擊層級管理器中的某一個節點，在右側的屬性檢查器中就可以把指令碼掛載到這個節點上了。至於想實現什麼樣的邏輯和動畫，就取決於需求和指令碼的開發細節了。”

“嗯，介紹得很詳細。”D哥向小Z投來讚許的目光，“最後一步和就比較容易明白了，

看來 Cocos Creator 想得很全面，從開始開發到最後的釋出都一體化了。

”

Z：“嗯嗯，是的，並且他這個

釋出支援，開發好的小遊戲可以在各種小遊戲平臺釋出。

”

D：“行，現在我們已經瞭解了 Cocos 和一些基本的開發流程，不過雖然他有很多成熟的作品，但是我們用起來真的會很順手嗎？我們只是一個 H5 頁面，放很多動畫的話，會不會造成不太好的使用者體驗？”

Y：“啊哈！這個不會，我問了論壇裡的大佬們，他們說 Cocos 引擎使用了 webGL（Web Graphics Library）， 是一種 3D 繪圖標準，允許工程師使用 JS 去呼叫部分封裝過的 OpenGL 標準介面提供硬體級別的 3D 圖形加速功能。官網也有圖介紹了這個，你們看。”

D：“好的，沒問題，那我做一下總結。

Cocos 開發遊戲技術方案成熟，出色產品較多，開發流程一體化方便快捷，並且底層架構優秀，可以快速渲染圖形，不存在效能問題的後顧之憂。

那咱們就選它了？”

眾人：“嗯嗯！就它了，開幹！”

第三章 小試牛刀

快速入門

第二天，三個人都來得很早，小Y習慣性地去搞了一杯咖啡，小心翼翼地端到了工位上。

Y：“D哥，demo 跑完了沒？”

D 哥睡眼惺忪，顯然昨晚又熬夜了。“沒有啊，什麼 demo ？昨晚趕一個專案，沒騰出時間。”

Y：“就 Cocos 官網上的那個 。你得注意身體啊，小心猝死！”

……

Z：“那個 demo 我跑了，蠻有意思的，待會兒早會給你們演示一下？”

D：“可以。”

上午的會議室資源相對寬鬆，來到了會議室後，小Z就開始演示自己昨晚跑的 demo 。

Z：“因為這個是官網上的，我就不詳細說每個細節了，先來看下最終效果”

Y：“我去，你這一下子就 Game Over 了啊。”

Z：“咳，別在意這些細節。我來介紹一下這個小 demo ，就挑我認為重點的說兩點吧。

一是主角的運動實現，二是 prefab 的使用。

紫色的小怪獸就是我們遊戲的主角，我們現在要讓他不斷跳躍，並且可以左右移動。按照我們昨天說的，編輯器使用的前兩步是匯入資源和搭建場景，這兩步完成後，我們得到了一個場景和一隻靜止在場景中的小怪獸。”

Z：“接下來我們在資源管理器中建立一個指令碼準備駕馭這隻小怪獸。並開始 coding 。”

Z：“先定義小怪獸的屬性，包括跳躍高度，跳躍持續時間，最大移動速度和加速度。這裡要注意初始值的設定最好是一個兜底值。”

Z：“接下來編寫跳躍程式碼，這裡涉及到了緩動（ cc。tween ）系統，在 Cocos Creator 中，cc。tween 可以對任何物件進行操作，並且可以對物件的任意屬性進行緩動。by 方法的作用是對屬性進行相對值計算，表示的是變化值。比如在跳躍上升階段，y 的值為跳躍高度，是一個正值，則小怪獸的高度會相對於當前高度增加，下落的時候 y 的值是一個負值，小怪獸會在跳躍最高點的基礎上減少自己的 y 值，也就下落了。”

Z：“onLoad 方法會在場景載入後立刻執行，所以初始化相關的操作和邏輯都會放在這裡面。我們首先將迴圈跳躍的動作傳給了 jumpAction 變數，然後將其插入到 cc。tween 對小怪獸進行緩動的佇列中，再呼叫 start 開始執行 cc。tween，從而讓小怪獸一直跳躍。”

Z：“接下來新增鍵盤輸入，用 A 和 D 來控制它的跳躍方向。新增鍵盤事件響應函式 onKeyUp 和 onKeyDown。”

Z：“然後修改 onLoad 方法，在其中加入向左和向右加速的開關，以及小怪獸當前在水平方向的速度。最後再呼叫 cc。systemEvent，在場景載入後就開始監聽鍵盤輸入。”

Z：“最後修改 update 方法中的內容，新增加速度、速度和小怪獸當前位置的設定。update 會在場景載入後每幀呼叫一次，我們一般把需要經常計算或及時更新的邏輯內容放在 update 中。在我們的遊戲裡，根據鍵盤輸入獲得加速度方向後，就需要每幀在 update 中計算主角的速度和位置。”

Z：“到這裡程式碼實現就完成了，我們可以在屬性檢查器中修改小怪獸的各項屬性來最佳化遊戲體驗。”

Z：“然後，我再來說一下 。對於需要重複生成的節點，我們可以將它儲存成 prefab（預製資源），作為我們動態生成節點時使用的模板。在場景中編輯好節點後，直接將節點從

層級管理器

拖到

資源管理器

就可以把這個節點轉變為一個預製資源。”

D：“打斷一下哈，你說這個 prefab 是一個模板？”

Z：“嗯嗯，是的。比如我們這個 demo 中的星星，是要不斷重複出現的，但是圖案、大小、顏色每次都一致，不同的只是每次出現的位置。這種情況下，我們就可以用一個模板，包含所有的屬性，需要的時候就用這個模板建立一個節點，再修改一下這個節點的某個屬性（在這個 demo 裡是位置屬性），就可以了。在 Cocos 裡 prefab 就是起到模板的作用，被稱作 ‘預製資源’。”

D：“好的，請繼續。”

Z：“剛剛也有說到，建立 prefab 的過程很簡單，我們先編輯一個節點，然後把節點從層級管理器拖拽到資源管理器，讓這個節點變成一個“資源”，一個 prefab 也就製作成功了，當我們想要在 A 節點上使用這個 prefab 的時候，先在 A 節點的掛載指令碼中宣告一個 prefab 屬性，再在編輯器介面把資源管理器中的 prefab 拖拽到 A 節點屬性管理器中，就可以在指令碼中使用這個 prefab 了。程式碼是這樣的。”

D：“行，我基本瞭解了。。。誒？小Y ，你是不是睡著了？”

Z：“我說怎麼這麼安靜。。。”

D 哥拍醒了小Y ：“快起來，你的咖啡涼啦！”

Y：“啊？說完了嗎？這麼快！我可沒睡覺啊。”

D：“行了，別狡辯了，都聽到你打呼嚕了。。。”

第四章 風起雲湧

專案開發

北方的秋，天高雲淡。一場風雨過後，樹葉都變成了金黃。距離上次開會已經過去一月有餘，幾個人都在忙著自己手上的任務。這天早晨，D 哥穿上了羽絨服，依舊風風火火地走進了辦公室。

D：“做的怎麼樣了，小夥子們？”

Y：“快來看，小 Z 這個主操作區域差不多了。”

D 哥脫下衣服，掛在了公用衣架上，用手拍了拍衣服上面的灰塵。

Y：“你快點兒撒！要我說，咱們這個專案，弄好了肯定得火！”

D 哥來到了小 Z 旁邊，一起看他這幾天的開發成果。

D：“還真不錯，我看你這裡面實現了移動、合成、購買和回收功能是吧？”

D 哥給兩位的任務分配是小Y負責頁面上半部分，小Z負責下半部分。所以在這裡直接針對下半部分的格子區域進行詢問。

Z：“嗯嗯，是的，我來簡單介紹一下。這幾個功能的實現都是依賴於 Cocos 。在 Cocos 中其實是有著豐富的元件體系的，我們之前掛到了節點上的指令碼也可以稱作為指令碼元件。在這裡，我使用的碰撞元件就是用來監測節點之間是否發生碰撞的。選中一個節點，在它的屬性管理器中就可以建立一個下面這樣的 。”

Z：“節點被碰撞的過程中，會觸發如下幾個回撥函式。”

Z：“這裡我遇到了一個坑，官方文件沒有提到 other 和 self 這兩個形參的含義，而我又未細緻思考，理所當然地把 other 當作了主動碰撞的節點， self 當作了被碰撞的節點。結果出現了各種詭異的表現。實際上 other 代表上層的節點，self 代表下層的節點。這個可以記錄下。”

D：

“上層節點和下層節點具體是指什麼？”

Y：“這你還要問，一看就沒認真學習新知識！Cocos 在渲染節點的時候，先渲染的節點在下層，後渲染的節點在上層。層級管理器中，靠上的節點先渲染，所以在下層，靠下的節點後渲染，所以在上層。比如這裡，joy 節點靠上，所以優先渲染；light 節點靠下，所以後渲染，出來的效果就是 joy 節點在 light 節點的下層。”

Z：“嗯嗯，有了碰撞元件做基礎，實現這幾個功能就簡單很多了。比如說‘移動’，當格子中沒有 joy 存在的時候，我會放一個 joy 的影子在裡面。這個影子作為一個節點，被移動的 joy 是另一個節點，一旦兩個節點發生碰撞，我就會根據這兩個節點的屬性以及碰撞的回撥函式來做出接下來的操作。”

D：“我理解一下，我看你這裡是判斷了節點的 level 屬性為0，所以你應該是當沒有 joy 存在時，把那個影子節點的 level 設定為0了，而有等級的 joy 的 level 一定大於0。碰撞發生時，一旦發現有等級為0的 joy 我們就可以斷定，是一隻有等級的 joy 要被移動到空格子裡啦。”

Z：“沒錯，不愧是D哥，一看就懂。”

Y：“你這個 moveJoy 函式是咋寫的，給我們瞧瞧啊。”

Z：“可以，

這裡我是用到了 Cocos 提供的方法 cc.tween

。”

Y：“這裡我懂，我來說。你先請求後端介面，通知到後端我們要進行移動了。一旦介面調通，便開始展示前端動畫。

這裡你利用人們的視覺能力的侷限性製造了一個假象

，讓人們覺得是把 A 放到了空格子 B 裡，實際上不是，你是先把 A 變成了 B 的樣子，放回了 A 自己的格子裡 ，再把 B 變成了 A 的樣子，放到剛剛 A 所在的位置，最後把 B 移動回自己的格子。”

Z：“嗯嗯，小 Y 說的沒錯，這裡我考慮了一下，如果實打實地把 A 節點放到 B 節點，就需要銷燬 B 節點，並且要在 A 節點原來的位置再建立一個新節點。這樣太浪費效能，並且如果使用者操作一旦快起來，恐怕很容易造成卡頓等問題。”

Z：“除了移動操作，其他幾個操作也都是用了相似的方法，都是用 cc。tween 來控制動畫的展現。”

D：“能再詳細解釋一下上面這個移動動畫的程式碼嗎？我沒有在這做很深入的研究。”

Z：“好的，那

我就解釋一下 這個函式。

第一行 cc。tween（staticNode） 呼叫方法 tween 並傳入我們的被碰撞節點，因為被碰撞節點是靜止不動的，所以我給它命名為 staticNode 。接下來的 call ，to 這些方法，都是鏈式相接的，可以保證在前一個方法執行過後，才會執行後面的方法，得益於這種鏈式結構，我們動畫的先後順序才是可控的。”

D：“是說傳遞了 staticNode 進去，之後的動作就都是控制這個節點的了嗎？”

Z：“沒錯，像程式碼裡面的 to 方法，可以傳入兩個引數，第一個引數表示動畫時間，第二個引數表示該節點將要達到的狀態，都是針對 staticNode 來操作的。不過像 call 方法，實際上就是去執行一下 call 裡面定義的回撥函式的內容，所以我直接把控制 movingNode 的操作寫在裡面了。這樣直接控制了兩個節點的一連串的動作。”

D：“好的，明白。其他幾種操作也都是用這種方法寫的是吧。”

Z：“嗯嗯，是的，比如合成操作，程式碼是這樣。介面呼叫成功後，開始展示動效：兩個 joy 彼此分開再合在一起，同時產生一個光圈特效。兩個 joy 是兩個不同的節點，利用 cc。tween 分別處理位置及光圈等元素。以 staticNode 為例，使用 by 方法先相對當前位置右移，再相對移動後的位置左移，之後提升等級、更新圖片並展示光圈特效。”

D：“好，看來 的功能還是很強大的，我感覺利用這個方法可以做任何動效了。”

Y：“這樣寫其實很麻煩的！”

D：“小 Y 你還有什麼簡單的方法嗎？”

Y：“當然，

其實 Cocos 還提供了另一種比較簡單的動畫實現方式，就是利用它自帶的動畫編輯器。

你看上半部分那個掉落的寶箱，就是我用動畫編輯器搞出來的。執行軌跡完全按照自由落體設定，十分逼真。”

D：“哦？講講看。”

Y：“看下面這張圖。我們選中 box 節點，在下方就可以直接透過動畫編輯器來編輯它。區域1裡展示的是動畫中需要變化的屬性，我們要讓寶箱掉落後上下浮動，所以改變的屬性是 y 的值；區域2代表一幀動畫，每一楨的屬性改變就構成了整個動畫過程；區域3是節點的所有屬性值，我們要改變區域1中的 y 就在這裡直接改就行。”

D：“嗯，的確看起來很簡單，不過難點應該在每一幀的數值選取上吧，

你是如何實現你的自由落體的？

”

Y：“首先，回想起來高中的物理知識，不過我當初沒想起來，就直接百度了。初速度為0，公式是

H = 1/2 gt^2

，我們可以求出每隔 t 秒，下落了多少距離，然後根據兩楨之間的時間間隔 t 來確定出寶箱的 y 值。”

D：“不過這樣的話，從一幀到另一幀的過程中是勻速運動嗎，速度就是（y2 - y1）/t ？

Y：“是的，不過由於我們的 t 是足夠小的，我在這令 t = 1/6s ，在這 1/6s 內的勻速運動根本無法被人感知到，我們看起來就是一個逐漸加速的過程。”

D：“不錯，看來你們兩個都基本掌握了使用 Cocos 開發動畫的一些要領，從目前的成果來看，我們當時選擇這個技術棧來開發也是沒有錯的，繼續加油！”

第五章 塵埃落定

專案完成了

轉眼到了冬天，凜冽的西伯利亞北風吹來，很多同事都感冒了。小 Y 一早便來到公司，坐在辦公桌前享受著今日份咖啡和八九點鐘太陽饋贈的溫柔的光熱。

Y：“上線！上線！這些日子 all in 開發太累了，頭都禿了！”

的確，正像小 Y 說的，幾個月艱苦的開發，大家都有些累了，同時也終於迎來了最後的時刻。

D：“咱們再做最後一次全流程，懷著要把遊戲玩壞的想法走一遍，看看有沒有什麼隱藏的 bug 沒解決，如果沒問題，明早就正式上線。”

Z：“嗯嗯！”

Y：“哎呀！完蛋！”

小 Y 的一聲驚呼嚇出了D哥和小Z的兩身冷汗。都趕緊湊了過去。

D：“怎麼了？”

Y：“早飯忘記吃了。”

D & Z：“靠！”

……

Y：“哎呀！這次真完蛋了！咱們沒有限制多指操作！如果同時拖動兩隻 joy 進行合成，會顯示異常。”

Z：“我之前寫了一段處理多指操作的邏輯，不過效果不好，就沒加上去。”

D：“哪裡不好？”

Z：“我的思路是設定一個全域性開關，一旦觸碰發生，就關閉開關讓其他所有的觸碰不再生效，只有當前的觸碰停止後才打開開關。”

D：“思路是正確的，不過你在這個過程中應該還是用到了 Cocos 提供的觸控監聽事件，並且你要實現這個功能，需要把所有的情況都考慮到，一旦漏掉了哪個節點或者哪種情況，你的開關可能就會失靈。“

Z：”是的，我自測的時候就發現如果操作過於頻繁，會導致我的開關無法再次開啟的情況發生。“

D：”我覺得這個問題比較常規，咱們先趕緊去查查，Cocos 有沒有給我們提供相應的解決方案。“

Z：“好。”

……

Y：“找到啦！”

D：“這麼快？說話的功夫就找到了嗎？”

Y：“當然！這個問題官方就有提供解決辦法，只不過也是最近幾個版本才加上的。”

D：“我們的版本支援嗎？”

Y：“支援。”

D：“好！快試試！”

三個人興奮又忐忑地把程式碼加到了程式裡。

D：“就一行？”

Y：“就一行！”

……

Y：“成功了！”

D：“不錯，我們接著測試，看看還能找到其他的什麼漏洞不。一直測試到上線，爭取不留 bug！”

Y & Z：“嗯嗯！”

又是一個清晨，大師端坐在湖邊，早已被凍得結實的冰層被快速地劈裂開來，一道紅光躍起。

大師：“魚兒，回來了。”

Cocos：“是呢，是呢。”

大師：“這一趟，可有收穫？”

Cocos：“有呢，有呢。發生了很多事情呢……”

———— End ————

https：//jelly。jd。com/article/5fbe616a7482df01463e27e3

複製連結在瀏覽器中開啟，即可檢視作者原文，交流更多研發經驗喔！