-前言-
小遊戲之所以稱爲小遊戲，首先它的資源量就被限制在一個很小的區間，在微信及QQ小遊戲上包大小有4M要求，即使使用分包也只能擴展到8M的大小，這與我們一般的APP遊戲的資源兩級是不能比的。不過隨着小遊戲的發展，我們可以將資源放到CDN，通過遠程拉取的方式加載資源，這與我們以前的頁遊相當。接下來就具體討論下小遊戲的加載優化有哪些及資源分配的細節。
-正文-
我們平時製作小遊戲一般都不會使用微信開發者工具開發小遊戲，這之後所有代碼出現都是關於Laya的代碼，不過思路基本相似。
聲音資源
聲音資源一般是偏大的資源類型，一般我們將這部分資源直接放到CDN上，需要使用的時候加載，我們在入口場景初始化前是不會對其加載的。
圖集資源
圖集分類
圖集資源資源是我們最需要好好管理的資源類型，因爲隨着項目的改進，會不斷增刪資源，要適時的刪除不需要的資源。在資源分配的時候，首場景的資源放到一個圖集之中。之後按功能及邏輯緊密性分配不同圖集之中，分配資源屬於哪個圖集之中需要注意另一個問題。一個圖集中的所有文件碎圖都隸屬於同一個Texture紋理對象，如果同一功能面板內的資源來自多個不同圖集，會導致多次切換紋理及增加drallcall次數，我們需要在圖集分類及優化渲染之間做好平衡。
一般項目圖集資源分類包括
- 加載界面資源
- 首次場景資源
- 其餘功能資源
圖集過大的一些問題
當我們實在一個文件夾中的圖片太多並且也無法拆分時，Laya會自動根據單圖集最大尺寸生成多張圖片及一個配置文件。這裏有一個問題就是一般我們的加載都是可以並行加載，根據不同平臺，並行數量不同，但是來源於同一個配置文件的圖集圖片是不能並行加載的，是完全的串行加載。這會使得加載非常緩慢。下面是對於圖集文件加載完成的邏輯，當我們.atlas文件加載完成後會加載對應圖片文件，這部分是加載一個處理一個圖片並生成紋理。因此我們應該儘量避免單個圖集大於我們所定義的最大圖集大小。解決方案可以修改這部分源代碼或者修改最大圖集大小，不過都不是最好的方式，管理好我們的圖集纔是解決之道。
//當圖集文件加載完成後加載對應Image邏輯
else if (type==="atlas"){
if (!data.url && !data._setContext){
if (!this._data){
this._data=data;
//省略部分代碼
toloadPics.reverse();
data.toLoads=toloadPics;
data.pics=[];
}
this.event(/*laya.events.Event.PROGRESS*/"progress",0.3+1 / toloadPics.length *0.6);
return this._loadImage(toloadPics.pop());
}else {
this._data.pics.push(data);
if (this._data.toLoads.length > 0){
this.event(/*laya.events.Event.PROGRESS*/"progress",0.3+1 / this._data.toLoads.length *0.6);
return this._loadImage(this._data.toLoads.pop());
};
//省略解析圖片代碼
delete this._data.pics;
this.complete(this._data);
}
}
另外當我們一個圖集過大的時候，解析時間也會隨之增大，所以合理控制圖集大小是非常必要的。這裏需要說明的是，圖片加載完成後並不是這個Load結束的時候，正真結束的時候是在我們解析圖集完成之後。
圖集壓縮
圖集是一個相對較大的資源類型，在發佈的時候我們都需要對圖集進行壓縮，Laya壓縮使用的pngquant（png），guetzli（jpg），我們也可以使用別的壓縮軟件及開源程序。一般壓縮都是將png32數據有損壓縮到png8，壓縮也要適當，不然也會出現失真問題。
配置文件
小遊戲配置文件一般使用json文件，一個是Web環境天生很好支持json，另一個json相對於其他數據文件大小也更小。不過在我們生成配置文件的時候也應該儘量簡潔，儘量避免json寫死數據，配置文件應該是公式參數而不是公式結果。另外當配置文件過多的時候也應該達到資源整合，避免過高的Http請求。配置文件也需要進行壓縮，不過沒有很好的壓縮方式，一般都是通過JSON接口轉成JSON對象再轉json字符串就完成了壓縮。
加載優化
前面說的這麼多都是關於資源分配的東西，都是加載之前的東西。關於加載優化一般都是按需加載。小遊戲加載分兩種加載情況：
- 完全放到小遊戲平臺CDN，進入小遊戲由平臺API拉取我們所有資源到小遊戲的執行域
- 除了代碼所有資源放到開發者的自己的CDN中。
上面兩種方式都各有利弊。首先如果我們把所有資源放到平臺哪裏，我們很難在資源加載部分做數據分析，因爲不瞭解各個平臺是如何加載資源的，我只肯定我們的資源肯定都是放到他們的CDN上的，所以肯定拉取速度也跟節點及自己的網速相關，這是一個不可控的過程。我個人還是推薦將資源放到自己的CDN中，當代碼加載完成後，執行到我們的邏輯中，我們就可以監控玩家的加載情況。
加載日誌
加載的時候我們需要記錄玩家加載進度、加載時間、當前網路狀況，在分析數據的時候將網絡極差的剔除分析對我們的優化有更好的幫助。
按需加載
我們的遊戲框架一定要實現的就是每個功能模塊開始執行邏輯之前加載對應要使用的資源對象。我們進入遊戲的那個加載階段也只是加載我們遊戲一開始必要的資源，這個資源不一定是完全確定的，可能需要根據玩家不同進度去加載不同資源。
加載中的邏輯代碼
資源加載是一個異步的過程，並不會阻塞我的主線程執行，因此當我們加載資源的時候可以初始化我們的數據模塊，及任何不需要用到資源的邏輯相關代碼。等到資源真正加載好的時候，我們只需要把蓋在遊戲場景前的畫面去掉就無縫連接到我們的正真的遊戲場景。