優化這件事兒我以前很少會在意，因為一直做手機遊戲，手機硬體的更新速度非常的快，更快的計算能力，更強的渲染能力，更大的記憶體。這就導緻了如果你不是做一個大型遊戲的話，幾乎是不太用考慮優化的。
直到我開始做微信小遊戲，作為一個小遊戲是有諸多的限制的，計算能力，渲染能力，尤其是對遊戲大小的限制（不能超過4M），這些限制讓我不得不重新的轉變一些之前做遊戲的想法。
剛開始做完精緻1010時，其實也沒太在意遊戲的優化，因為遊戲本來就比較小，再加上使用簡約的風格，素材資源比較少，是以整個遊戲運作起來還是挺流暢的。但是，當我開始不停的為這個小遊戲進行擴充增加更多的内容時，問題出現了。
7月4号，我更新了一個新的遊戲模式：闖關模式。相當于将原有的遊戲擴充了一倍的内容。
我們看一下下方的兩張小遊戲背景的資料統計圖。這裡有兩項比較重要的資料：
總耗時：是指從玩家點選遊戲圖示到正式進入到遊戲中的時間。
CPU: 是指遊戲運作中所需要消耗的計算量。
可以看到在增加了闖關模式之後，遊戲的啟動時間和 CPU 都開始上升。其中最嚴重的莫過于啟動時間的提升，最高值達到 9 秒鐘，想一個如果一個玩家打開一個小遊戲需要等待 9 秒鐘的時間才能進的去的話，很可能就不會再次打開它了。
針對上述的問題，我開始着手對遊戲進行優化，首先看了一下官方文檔的優化建議。
官方優化建議在這裡：https://gamemaker.weixin.qq.com/doc/minigame/optimize.html
内容相對較少，隻有一些原則，缺少具體詳細的指導。但是至少是有了一些方向了，于是我開始踏上了小遊戲優化的旅程。
下面記錄的就是我針對一個已上線的微信小遊戲的優化操作。
精簡遊戲資源
每一個被導入的遊戲資源最終都會包含在遊戲的包體中，在遊戲開發的過程中會導入很多的資源，包含各種的圖檔，音效，數字等等，有些資源最終沒有被用到，這時候要仔細的檢查這些導入的資源，找到并删除那些沒有用到的資源，以避免它們增加遊戲的大小。
遊戲中的最多的資源類型就是圖檔，對于圖檔資源我們要堅持一個原則：盡可能以最小的圖檔達到預期的效果。
比如說遊戲中的對話框背景圖，原來使用的是一張 380x580 的圓角矩形圖檔，在等比例的縮小一倍後，最終使用了 190x290 的圖檔。
雖然邊角和陰影有部分的細節損失，但是總體上是可接受的，這樣原來的一張大圖就縮減了一半的大小。
對于圖檔資源的另一個原則就是：複用。隻要能重複使用同一張圖檔的地方，那就一定要重複使用同一張圖檔。
如圖，在優化後的精緻1010的首頁中，8個按鈕隻使用了兩種類型的圖檔，一個是長的圓角矩形（用于聲音和震感按鈕），一個是方的圓角矩形（用于剩餘的所有按鈕）。通過調整圖檔的大小和顔色，就可以做出不同的按鈕了。
這裡我使用的是圓角矩形， 因為圓角矩形在大幅度的放大或者縮小後，圓角處會出問題，是以使用了兩種類型的圓角矩形，如果使用方腳矩形的話，那麼所有的按鈕複用一張圖檔就可以搞定了。
精簡遊戲邏輯
遊戲邏輯指的就是我們的積木塊了。
首先删除遊戲中沒有用到的積木。仔細檢查遊戲中的邏輯積木，删除無用的或閑置的遊戲積木，平時對于無用的積木塊要及時的删除，不要放在那裡，養成好習慣。
其次還是要堅持“複用”的原則，對于重複的邏輯通過使用“函數”或者“通知”進行複用，避免多次使用重複的積木塊。
使用函數來複用邏輯
舉個例子，在精緻1010中拖拽的方塊不滿足放置要求是會退回到原位置的，因為包含多種不滿足要求的情況，是以有很多的“如果，否則”積木塊，對于所有不滿足的情況其實都重複用到了相同的兩塊積木。
對于這種情況，我們就可以将重複的積木制作成一個函數。
可以看到這個函數中設定了多個參數，這樣對于所有需要移動縮小功能的地方，就都可以使用這個函數了。
最後使用函數來替換原來重複使用的積木塊。
使用通知來複用邏輯
使用函數有一定的限制，尤其是對于局部變量來說， 将局部變量以參數的形式傳遞給函數時，在函數内對局部變量的修改不會被儲存。比如說一個局部變量 10，當作參數傳入函數中，在函數内對局部變量進行加倍處理，最終結果應該是 20，但是函數執行完畢後，這個局部變量的值依然是 10，是以對于函數内處理的變量隻能夠使用全局變量。
那麼對于需要處理局部變量的重複積木，我們可以通過使用“通知”來進行複用。
如圖，這是更換主題中的部分邏輯代碼，可以看到紅框框出的代碼是重複使用的，這裡我們可以将重複的代碼放到一個通知中處理。
對于需要用到重複積木的地方，我們隻需要向自己發送一個通知即可。這樣原來的這部分代碼就通過複用被精簡了一半。
這裡有一點需要注意一下：目前的微信小遊戲開發工具的積木塊的數量是有上限的。
這是我前些天在增加新内容時遇到的問題，項目無法進行儲存了，咨詢過開發團隊，才知道是代碼超出了限制。
是以要好好斟酌每一個需要使用的積木塊，盡可能的以最少的積木塊實作想要的功能。
另外有一點需要考慮的是，目前的代碼限制決定了你将要開發的遊戲的體量， 如果你想要通過微信小遊戲開發工具做一個比較大的遊戲，那麼就需要提前考慮一下這個代碼限制了。
合理規劃場景
在增加闖關模式時我原來的方案是重新建立一個場景，專門用于闖關模式。這樣經典模式和闖關模式兩個場景就能夠各自獨立。在後續不論是針對哪個模式進行修改也好，擴充也好，隻需要到其對應的場景中進行開發即可。
多建立一個場景，就相當于多了非常多的資源， 兩種遊戲模式之間，其實有非常多的東西都是可以共用的。但是，由于很多的資源和積木邏輯無法跨場景共用， 是以很多的内容就隻能通過複制粘貼再建立一份了，這就導緻了遊戲中包含大量的重複的代碼和資源。
在遇到了最大代碼限制之後，我不得不重新考慮場景的規劃，将這兩個場景合二為一。
如圖， 我将原來的“經典模式”和“關卡模式”兩個場景合并到了一個“遊戲”場景。在合并之後，節省了大量的代碼空間，後來才能夠增加“編輯”場景，實作使用者自定義關卡的功能。
這裡的一點提示就是不要不加節制的使用場景， 如果能使用一個場景搞定的事情，那就不要用更多場景了。
減少遊戲中的精靈數目
遊戲場景中的精靈的數量決定了渲染和計算需要的消耗量。總體上來講，精靈的數目越多需要的渲染和計算的量就越多。是以為了提升總體的性能，就需要盡量的精簡遊戲中的精靈的數量。
點選調試遊戲，可以在“全局變量”選項中看到目前場景中的精靈數。
如圖，在優化之前，初始場景中的精靈數目是 325。雖然遊戲的界面看似非常簡單，但是精靈數目卻非常的多。
我們的目标就是在保證遊戲效果的基礎上盡量的精簡遊戲中的精靈數目，為此我做了如下的優化。
原本遊戲中的這個 10x10 的網格是使用單個格子拼出來的， 是以畫出這樣一張網格就需要 100 個精靈。 我更換了一種方式，直接導入一個畫好的 10 x 10 的網格圖檔，這樣一個展示網格隻需要使用 1 個精靈就可以了，這樣一下就縮減了 99 個精靈。
另外遊戲中的所有的形狀原本都是使用單個方塊拼成的，現在我直接将形狀制作成一張圖檔，這樣就又能夠減少非常多的精靈。
最終經過優化後，場景中的精靈數目減少了一百多，這還是在後續增加了新功能之後的精靈數目。
同時從CPU的名額中可以明顯看的出來，優化後，消耗大幅下降，因為更少的精靈數目，就意味着更少的CPU消耗。
建立一個精簡的初始場景
“遊戲啟動時間”是小遊戲中的一個非常重要的名額，它意味着從玩家打開到正式進入遊戲需要多長時間，通常這個時間越短越好。
決定這個時間長短的因素很多，包括遊戲的大小，資源的多少，網絡的狀況，玩家手機的性能等等，其中大部分因素其實是不可控的，除了我們上述提到的各種優化方法之外，還有一個方式可以幫助我們提升遊戲的啟動速度，就是建立一個盡可能簡單的啟動場景。
原來的啟動場景。
新增的精簡的啟動場景。
如圖我為遊戲增加了一個非常簡單的啟動場景，隻包含了一個小螞蟻的圖示和很少量的積木塊。這樣場景的打開速度就會比原來快很多，因為需要加載的資源和積木塊都非常的少。
另外，不要忘了在作品設定中選擇資源在“切換場景時加載”。
這樣由于啟動的場景資源非常的少，就可以很快的加載完畢并打開了，然後我們再從啟動場景加載打開後面資源比較多的場景。
最後，總結一下，對于微信小遊戲的優化，我們可以從下列幾個方面着手：
- 精簡遊戲資源
- 精簡遊戲邏輯
- 合理規劃場景
- 減少遊戲中的精靈數目
- 建立一個精簡的初始場景
通過這些優化操作，我成功地将精緻1010的啟動時間和性能消耗都降了下來，希望這些優化操作也能夠給你提供一些參考。
優化是一件永無止境的事情，我認為最好的優化是應該在制作之前進行的，因為一個更優的想法，一個更合理的規劃要勝過這些事後的補救措施。