歡迎關注富途web開發團隊,缺人從衆html
原文連接:查看git
小遊戲是小程序的一個類目,小遊戲是微信開放給小程序的更多的能力,讓小程序開發者有了開發遊戲的能力。小遊戲沒有WXSS、WXML、多頁面等內容,但加了一些渲染、文件系統以及後臺多線程的功能。github
小遊戲的運行環境是小程序環境的擴展,基本思路也是封裝必要的 WEB 接口提供給用戶,儘量追求和 WEB 一樣的開發體驗。小遊戲在小程序環境的基礎上提供了 WebGL 接口的封裝,使得渲染能力和性能有了大幅度提高。不過因爲這些接口都是微信團隊經過自研的原生實現封裝的,因此並不能夠等同爲瀏覽器環境。web
小遊戲的運行環境在 iOS 上是 JavaScriptCore(注:webkit的一個重要組成部分,主要是對JS進行解析和提供執行環境。),在 Android 上是 V8 (這個不用多說Node.js目前使用的就是V8)。可是兩個都沒有 BOM 和 DOM 的運行環境,沒有全局的 document
和 window
對象。算法
小遊戲 VS H5遊戲 VS 小程序對比圖canvas
主要目的提供 BOM 和 DOM 的運行環境。小程序
由上圖能夠看出,由於沒有 BOM 和 DOM 的運行環境,沒有全局的 document
和 window
對象。爲了讓基於瀏覽器環境(上圖的H5遊戲)的第三方代碼更快地適配小遊戲運行環境,因此就有了適配器(Adapter)。它是用微信 API 模擬 BOM 和 DOM 的代碼組成的庫,抽象的代碼層,能夠根據本身的須要去實現相關方法。api
例如,簡單實現document.creatElement
方法:瀏覽器
var document = {
createElement: function (tagName) {
tagName = tagName.toLowerCase()
if (tagName === 'canvas') {
return wx.createCanvas()
}
else if (tagName === 'image') {
return wx.createImage()
}
}
}
複製代碼
Adapter是否使用由開發者本身決定。不使用Adapter時,能夠經過微信提供的API實現相應的方法,但不能使用 DOM API 來建立 Canvas 和 Image 等元素。緩存
有的遊戲引擎是直接調用DOM API,和訪問DOM屬性 ,因此記得使用Adapter讓遊戲引擎適配小遊戲的運行環境,保證遊戲引擎在調用 DOM API 和訪問 DOM 屬性時不會產生錯誤。
微信官方實現了一個 weapp-adapter 小遊戲適配器,但僅僅只針對遊戲引擎可能訪問的屬性和調用的方法進行了模擬,也不保證全部遊戲引擎都能經過 weapp-adapter 能順利無縫接入小遊戲。這裏將 weapp-adapter 適配器提供給開發者,更多地是讓開發者做爲參考,讓開發者能夠根據須要在 weapp-adapter 的基礎上進行擴展,以適配本身項目使用的遊戲引擎。weapp-adapter 會預先調用 wx.createCanvas()
建立一個上屏 Canvas,並暴露爲一個全局變量 canvas
。
require('./weapp-adapter');
var context = canvas.getContext('2d');
context.fillStyle = 'red';
context.fillRect(0, 0, 100, 100);
複製代碼
weapp-adapter 適配器提供瞭如下對象和方法:
其實官方文檔裏面還有不少 ,感興趣能夠查看官方 API文檔。
小遊戲提供了 CommonJS 風格的模塊 API,能夠經過 module.exports
和 exports
導出模塊,經過 require
引入模塊。這裏就不用多解釋了,其實你們按正常的編碼習慣編碼就能夠了。
module.exports = function (canvas, x, y) {
var image = new Image()
image.onload = function () {
var context = canvas.getContext('2d')
context.drawImage(image, x, y)
}
image.src = 'res/image/logo.png'
}
複製代碼
因此小遊戲對編碼方面的基礎能力仍是很友善的。
這裏列出部分已提供的 API 能力,更詳細的能力及官方實例可訪問 API文檔。
你們對 Canvas 的優化或者對離屏畫布不瞭解的能夠看這篇文章 Canvas 最佳實踐(性能篇)。
遊戲引擎是指一些已編寫好的可編輯電腦遊戲系統或者一些交互式實時圖像應用程序的核心組件。這些系統爲遊戲設計者提供各類編寫遊戲所需的各類工具,其目的在於讓遊戲設計者能容易和快速地作出遊戲程式而不用由零開始。
Cocos、Egret、Laya 已經完成了自身引擎及其工具對小遊戲的適配和支持:
從開發者的反饋來講,Layabox原本就是面向大型遊戲的H5遊戲引擎,性能優點是毋庸質疑的。
工具鏈的提供與支持也是一種選擇考量要素,好比UI編輯器、粒子編輯器、骨骼編輯器、場景編輯器等等,若是引擎方直接提供或支持,那麼將會較大的提高研發效率。Egret、Layabox、Cocos2d-JS這三個引擎在工具鏈方面提供足夠全面的支撐。
Egret成名比較早,發展得比較快,各方面的資源而比較多,提供了全套開發流工具。
用遊戲引擎的優勢:開發快,可維護性高
用遊戲引擎的缺點:犧牲一些性能,小遊戲用不用引擎幾乎感覺不到性能差別。大遊戲爲了開發效率和可維護性,通常都會使用遊戲引擎。
本次主要實現的是跳一跳小遊戲。遊戲大概以下:
跳一跳如何技術實現能夠參考:這篇文章
經過requestAnimationFrame
循環調用必定次數來實現動畫效果。遊戲的邏輯經過監聽全局的canvas
對象實現。
分層按順序疊加繪至畫布,先將背景繪上,經過算法計算出臺階位置,結合上一次的位置用requestAnimationFrame
實現移位生成新的臺階,機器人單獨抽離出來的,沒有和臺階一塊兒實現,經過位置計算,獲得機器人的位置,繪製字臺階上,最後將頂層的樹葉繪製上。
首先,小遊戲使用JavaScript語言開發,不存在HTML,CSS,因此須要對JavaScript語言,Canvas對象操做熟練。
其次,和H5版遊戲開發區別並不大,可是小遊戲支持的庫較少,而且大部分H5版開發所使用的到的庫是不支持的。
還有,就是H5版遊戲的實現方式選擇性更多,好比跳一跳原版是使用createjs
開發,而小遊戲版並不能支持全部的引擎,只能經過上面的幾個引擎改造適配。
爲何要優化? 其實爲了提升頁面加載速度,減小遊戲運行中的卡頓,使動畫看起來更流暢,遊戲的流暢程度及畫面直接影響了用戶體驗。
如下提供了幾個優化方案。
小遊戲的優化文檔並未指出,在api中提供一個性能管理器,經過獲取性能管理器可以調用 API 加快觸發 GC ,GC 時機是由 JavaScrpitCore / V8 來控制的,不能保證調用後立刻觸發 GC。
小程序端,官方不建議頻繁調用 setData
,大圖片和長列表圖片,都有可能致使 iOS 客戶端內存佔用上升,從而觸發系統回收小程序頁面。
儘可能減少代碼包的大小,代碼包直接影響了下載速度,從而影響用戶的首次打開體驗。
控制代碼包內圖片資源,小程序代碼包通過編譯後,會放在微信的 CDN 上供用戶下載,CDN 開啓了 GZIP 壓縮,因此用戶下載的是壓縮後的 GZIP 包,其大小比代碼包原體積會更小。 但咱們分析數據發現,不一樣小程序之間的代碼包壓縮比差別也挺大的,部分能夠達到 30%,而部分只有 80%,而形成這部分差別的一個緣由,就是圖片資源的使用。GZIP 對基於文本資源的壓縮效果最好,在壓縮較大文件時每每可高達 70%-80% 的壓縮率,而若是對已經壓縮的資源(例如大多數的圖片格式)則效果甚微。
及時清理沒有使用到的代碼和資源,小程序打包是會將工程下全部文件都打入代碼包內,也就是說,這些沒有被實際使用到的庫文件和資源也會被打入到代碼包裏,從而影響到總體代碼包的大小。
使用 requestAnimationFrame
實現動畫時,調整到合適的渲染fps(幀率)。
小遊戲中圖片對尺寸限制在2048像素,長寬要小於等於2048像素。
小遊戲對外沒有開放註冊入口,如今能使用的是前兩天在小程序中開放的遊戲類目,將小程序類別設定爲遊戲類目可開發小遊戲,不肯定之後是否以這種方式註冊,或者是單獨開放小遊戲的註冊入口,二者目前沒發現有什麼區別。
官方目前沒有提供對外發布,登陸後臺可以點擊發布,可是須要上傳軟件著做權證書等一系列,因此沒有進行下去,不肯定可否對外發布成功。
關於小遊戲體積問題,小遊戲的體積不得大於 4M,緩存不得大於 50M。 具體的解釋爲:本地的代碼和資源不得超過 4M。單個小遊戲項目緩存的文件不能超過 50M,目前當緩存超過 50M 時後續的資源將不會緩存,將來新版的 AssetsManager 將會容許開發者自定義哪些資源須要緩存的機制。不容許從服務器下載腳本文件。
不容許動態執行代碼的能力,eval
、setTimeout
和 setInterval
函數的第一個參數不能爲字符串,Function
構造函數的參數不能爲字符串。
遊戲邏輯沒處理好,動畫有點不流暢,有延時問題。