從正月初五起至正月初九，我們每天將推送一個主題的「舊文回顧」，涉及運營、策劃、美術、技術、營銷等領域，今天為技術篇。
微信小遊戲在2017年12月28日正式上線。相對於傳統的H5遊戲，小遊戲的優勢十分明顯，擁有微信龐大的用戶量以及更好的兼容性，在天生適合微信社交生態的同時還不用擔心被屏蔽。無疑，這或許是一個巨大的風口。不過在現階段若想抓住這波紅利，開發者所面臨的挑戰也是明顯的，產品品質定位該如何定位？H5遊戲和小遊戲的匹配度究竟是怎樣的？開發過程中會開發者可能會遇到哪些坑？這些都是目前急需解決的問題。
在1月4日的葡萄學院中，我們請來了Cocos 引擎創始人王哲和Cocos核心技術凌華彬（Panda），針對微信小遊戲進行了技術方面的介紹。此次課程主要介紹了微信小遊戲的基本架構，並對相關開發知識、開發環境以及資源管理等方面進行了乾貨分享。
以下為課程內容整理：
今天我們在希望向大家分享一下小遊戲的概論，主要包括一些入門的相關知識。我們將內容分成了6個部分，分別是：
1.如何正確了解小遊戲？
2.小遊戲開發需要哪些知識？
3.小遊戲開發環境
4.小遊戲的資源管理
5.HTML 5發布為小遊戲
6.小結
為方便大家理解，第一部分先講一下小遊戲到底是什麼。
相信這個群裡的所有聽眾基本上都不會對這幾款小遊戲感到陌生。目前整體來看，第一波上線的小遊戲更多以休閒類為主。例如《跳一跳》，應該是目前最流行的產品，雖然它只是一款單機。
此外，除棋牌類遊戲，能夠支持好友對戰功能的只有《歡樂坦克大戰》和《Q寵大樂鬥》兩款產品。
當然，對於棋牌來說，小遊戲可能也會為其帶來一波新浪潮。近一段時間棋牌類遊戲由於房卡棋牌等模式的興起也非常流行，小遊戲上線後，大家拉個群，發一個小遊戲的連結，就可以進行遊戲了。這種便利會給棋牌行業帶來很大的增益。
這張圖應該可以反映目前所有的小遊戲用戶入口，可以分成4類：
1.聊天入口。 用戶可以將小遊戲分享連結直接推到群聊或與朋友的會話中，直接將他們拉進小遊戲中。
2.搜索入口。 玩家可以通過下拉微信聊天記錄，或在專門的小程序頁面對特定小遊戲進行搜索。若想利用這個入口，遊戲需要有較好的口碑，當然如果名字起得太長太難，可能也會影響這個入口的使用效果。
3.微信小遊戲列表入口。 玩家可以去這個列表中去尋找、發現新的小遊戲。
4.朋友圈。 從我的直覺來看，這個入口與聊天入口將會是最重要的2個小遊戲入口。但是通過群聊的聊天分享，我認為是比朋友圈更重要的入口。也就是小遊戲立項的時候務必、務必要做好通過社交拉新用戶進入遊戲的設計。
在小遊戲裡，除了遊戲本身的邏輯開發和引擎使用外，對微信目前開放社交API的使用，以及怎樣去設計社交，都會對遊戲的傳播效果造成影響。分享點的刺激是有講究的，在早期遊戲裡，遊戲更多是以「戰力」、「等級」這些數值向的設計分享點，而現在， 遊戲分享點則更多在於「情感之上」，這些都是在遊戲設計過程中值得思考的內容。 提醒一點，80後和90後觸發分享的情感點是不一樣的，我不能說更多，但是遊戲製作人自己應該加以揣摩。
回到小遊戲上，在講技術之前，我們要去理解小遊戲的趨勢架構是如何的。小遊戲不等於原生遊戲，也不等於HTML 5遊戲。現在一些媒體經常會講：「小遊戲是H5遊戲的春天。」嚴格來說，這麼講不是太準確。
標準的 HTML 5 遊戲是什麼呢？標準H5遊戲是Facebook Instant Games、愛微遊、QQ空間的那些遊戲 。這些是在瀏覽器裡跑H5的遊戲； 但是小遊戲本質是Runtime遊戲，它跟小程序類似，結構是小程序+遊戲庫API。
在這個架構之上，他會有更多優勢。首先它會比H5遊戲更穩定；其次小遊戲跳出重進後，用戶不用像在H5遊戲裡那樣進行重新登錄；另外小遊戲可以調用微信的原生用戶，在轉發、支付等方面也固定了接口，可以說對整個微信生態建設是有很大幫助的。當然對於我們來說一定要注意的是，雖然小遊戲的調試環境是在瀏覽器當中，但這只是其 HTML 5 兼容性的體驗，它真正在微信當中時是用 Runtime的。
我們自己很清楚H5和小遊戲之間在技術結構上的差異，但現在如果說小遊戲不是H5遊戲又會被人噴， 於是我們今天發明了一個新名詞：HTML 5 技術棧。 它包含了所有純H5和類H5的技術解決方案。
《拳皇命運KO不服》由國外引擎Createjs製作；《全民大樂鬥》是目前唯一一款帶有成長元素的小遊戲，由Laya引擎製作
這張圖我想表達的是，在原生遊戲中，可能還有一些遊戲在用自研引擎來製作，但在小遊戲中，已經沒有自研引擎的身影了。所以不管是國內的Cocos、Laya、Egret這些H5引擎，還是用國外的Phaser、Createjs，基本上都是可以直接用的。
需要注意，特別是小公司，大家最好使用已經被微信適配證明過的引擎，特別是現在微信小遊戲開發文檔只有中文版本，海外的引擎可能並不能幫助你多少，除非你的研發團隊能吃透他們的英文文檔而且忍受帶時差的論壇技術支持。而且在這次上線的遊戲中，除了華夏樂遊與飛魚科技外，其他都是騰訊自研的，你不知道他們在研發過程中究竟踩了多少坑，改了多少東西。
對於3種遊戲的對比，我來嚴格列舉一下他們之中區別。首先，他們的入口都不同，這也就代表了它們的用戶屬性是不同的。比如，可能很多小遊戲用戶並不是原生遊戲玩家，作為非玩家它們對於遊戲產品的需求也會與玩家不太一樣，對於「VIP1-VIP15」、「首充大禮包」、「首充3倍」，它們或許就不會那麼敏感。當然，這些都是值得去繼續揣摩的事情。
在流量成本上，小遊戲和HTML 5的崛起有一定原因源於其低於原生遊戲的流量成本。實際上遊戲品類沒有什麼變化，變的是流量成本，當某一模式的流量成本過高了，行業就會有動力去挖掘一個新平臺，去獲取一批新的遊戲用戶。PC端遊到PC頁遊，PC頁遊到手機原生、再到手機頁遊，表面上看是一件技術驅動市場變化的事情，但本質上是流量成本驅動技術迭代、進而驅動市場變化。這個本質要理解清楚。
在開發的時候，CP也要注意性能的約束。純H5遊戲在性能和佔用內存上都是約束性最高的，所以如果往往H5遊戲做小遊戲移植版本，不論用哪個引擎，適配工作都會進展得相對順利。當然需要注意， 諸如CSS、DOM是不能用於小遊戲開發的。 但是反過來，如果你移植一款手機原生遊戲到微信小遊戲，就得非常小心內存使用的問題了。
其實原生遊戲移植到小遊戲也有一些案例，比如《保衛蘿蔔》，但一定要注意，在移植原生遊戲過程中一定要注意性能和內存上的問題，如果控制不好很可能程序就會崩潰。其實有不少曾經的客戶過來問我，如果原生遊戲是用C++這些語言寫的，能不能直接移植到小遊戲上。 很遺憾，不行，目前必須通過手工去翻譯，因為今天微信提供的標準接口只有JavaScript。
我出於個人技術傾向、項目歷史的原因，非常強烈地不喜歡那些通過編譯器去轉化不同程式語言的方案，因為這些方案並不「自然」，表面上看是省了很多移植開發量，但在調試和優化階段會有無數的坑等著你。所以最優的方案，我仍然建議大家用 JavaScript 重新移植遊戲，不論你的原生遊戲是Cocos C++, Lua還是Unity的。
接下來我來講述一下小遊戲的相關知識，希望能夠幫助大家能夠順利上手開發。
這張圖是小遊戲目前可以使用的技術棧。最上層是各家遊戲引擎，經過微信驗證後，都是可以提供給大家嘗試的。中間一層是小遊戲的底層，是小遊戲所藉助的 HTML 5 的技術棧。
為什麼說它是 HTML 5 技術棧？因為小遊戲並沒有完全使用 HTML 5 標準，它只是模擬這些的接口，從而更好地完成 HTML 5 向小遊戲的移植工作。最下面這部分是微信自己的API，之後會對它進行展開講解。
首先是底層的技術，它包括JavaScript代碼和Canvas 2D、WebGL 1.0的API。這2個API都是和Web上的API是一致的，這也是微信想要拉攏H5開發者所作出的努力。微信同樣也很快地與國內的幾個主要引擎商進行了合作，讓各家引擎可以第一時間支持微信小遊戲的發布。同時微信小遊戲Runtime也開發了一個Adapter，並且移植了一些海外諸如Phaser, Three.JS, CreatreJS等H5引擎到小遊戲環境裡面。
上層我們建議大家通過遊戲引擎來開發，這是出於對成本的考量，因為遊戲引擎可以為大家儘可能縮短研發周期、降低項目成本和風險。現在微信所試驗過的就是上圖所列出的6個引擎，這些大家都是可以去嘗試的。
除此之外還有微信小遊戲的SDK，這些雖然是是微信所提供最底層的東西，但實際上是除去引擎外大家需要去關注的部分。在遊戲玩法邏輯研發之外，這些接口都是要去研究的，這才能讓遊戲擁有更好的社交玩法。具體這些接口的詳細功能大家可以參閱微信的文檔。目前可以看到，僅小遊戲所擁有的直接分享功能和即點即玩的特性讓它在傳播和進入門檻上都擁有極大的潛力。
這是《跳一跳》和《星途Go》好友排行榜的例子，包括遊戲裡的排行榜和每個關卡的排行榜。
這個例子是《坦克大戰》中的邀請對戰，當你把邀請發到群裡後，進入的玩家可以選擇陣營，形成3對3模式。
直接接受邀請是微信所做的最大創新。在原生遊戲中，玩家點擊邀請連結後首先要下載安裝，之後還要互加好友，隨後才可以進行匹配，整體流程路徑很長，流量轉化成本也很高。然而在小遊戲場景下，當你的好友點開你的分享連結後，可以直接進入遊戲，這是一個突破，大家需要在這方面考慮更多。
我剛剛仔細檢查了一下微信小遊戲的API，有轉發邀請，但是並沒有獲取其他微信好友暱稱、備註名、分數的排行榜API。大家可以再檢查確認一下，如果的確是在今天沒有這個公開的API，那麼遊戲設計為好友排行榜競爭的玩法時候則需要注意一下。不過目前在騰訊遊戲中都可以使用，未來這個API也有可能會出現。
接下來我會進入更加技術的一個環節，讓大家更了解如何去適應小遊戲的開發環境。
這張圖是小遊戲的運行框架，它不是微信官方給出的，是我們自己分析得出的。首先，最底層是iOS安卓的硬體、系統等內容，這些提供了系統層級別接口。微信在這基礎上開發了微信安卓版和iOS版，其中包含了包括用戶、支付、文件、多媒體等各種模塊。
然而在在這樣一個原生應用中，沒有瀏覽器的加持H5程序又怎樣運行JavaScript代碼呢？這是通過JS VM在安卓上集成V8引擎，在iOS上集成JavaScript Core引擎去執行JS代碼的。
微信僅僅執行JS代碼還不足以讓開發者的小程序運行起來，因為開發者所調用的用戶轉發文件系統這些接口都是不存在於JS VM中的。實際上，它是通過綁定的接口來講微信原生接口橋接到JS接口上的。當你調用這些JS接口時，實際上就是在調用原生接口來達成功能。如果大家對綁定技術感興趣，可以去關注我們開源的JSB技術，這也是目前遊戲引擎當中唯一開源的實現技術。
這裡我們就不深入細講了，繼續討論微信小遊戲是怎樣提供接近於瀏覽器環境以及怎樣跟遊戲引擎相結合。
這張圖比上一張多了一個Adapter，我將小遊戲總結為2部分：圖形渲染API以及微信API。右邊的Adapter是微信官方提供的適配腳本，它提供了右邊2個API不存在的一些瀏覽器API，這些往往是大家開發遊戲所依賴的API。比如，創建Image，這樣才可以使用貼圖；Audio是播放功能；LocalStorage是存儲；使用WebSocket來做網絡調用等。
在小遊戲原始環境的圖形渲染API和微信API的基礎上，加上Adapter之後，就跟瀏覽器的環境非常接近了。
在此基礎上，微信提供了一個完整的Runtime，接近於瀏覽器的環境，但並不等同。遊戲引擎的工作就是進一步抹平瀏覽器和微信環境的差異。比如在Cocos引擎中，你可以直接切換HTML 5版本和小遊戲版本，不需要做任何遊戲代碼上的修改。也就是說你 用JS寫的遊戲，一份代碼就可以同時在小遊戲平臺和原生平臺上運行。
總結一下，微信的三大接口：
1.渲染接口
2.微信功能接口
3.Adapter接口
除了抹除瀏覽器和小遊戲之間的差異外，遊戲引擎還可以帶來成本上的巨大降低。就像上圖寫的，成本降低主要來自於3個方面：
1.Framework中，當我們遊戲引擎封裝了更高層的API，開發遊戲會更加便利，這就使得人力成本降低
2.編輯器層面中，一個好的編輯器可以明顯提高程序、美術、策劃之間的協同效率。
3.在兼容性層面中，遊戲引擎帶來的設備兼容性和穩定運行效率可以降低大家的維護成本，加上剛才提到的跨平臺能力，可以給大家帶來更強大的渠道和流量。
所有這些人力成本、維護成本的降低以及跨平臺所帶來的豐富流量，可以讓大家的項目以更低的開發成本完成遊戲，繼而盈利。
當你希望在微信小遊戲環境中使用第三方庫的時候，很多第三方庫會遇到問題。比如JQuery，它就使用了DOM的API，DOM API在微信小遊戲中是不存在的，而且也無法模擬，因為根本就沒有DOM樹。
純JS的第三方庫是絕對不會有問題的。 當然，有一些第三方庫使用ES6來編寫的，這個時候你要注意去掉「ES6轉ES5」的標籤，在微信開發者工具的詳情頁面中可以找到。 總之，原則是使用DOM API的第三方庫請不要使用，JS的第三方庫可以隨意使用。
依賴於網絡的第三方庫，像Protocol Buffer，這些在加載的部分是需要定製的，需要加載部分API適配到微信小遊戲所適配的API上，比如wx.request.downloadFile。
第四個部分，我想分享的是小遊戲的資源管理，這是小遊戲目前和瀏覽器環境差異最大的另一個方面。
首先為大家介紹一下小遊戲資源管的分布方式。大家如果使用過開發者工具的話會注意到，當你開發一個小遊戲的時候，你如果點預覽，它會有一個上傳的過程，之後掃它提供的二維碼就可以測試這個小遊戲。實際上這個上傳的過程就是將你的小遊戲包上傳到CDN內。在你的用戶掃這個二維碼時，實際上是從微信的CDN下載這個小遊戲包到他的手機上，並執行。
這是最簡單的版本，讓我們來看一下相對複雜一點的。
微信小遊戲為了能夠提升首包加載速度，將包體限制在了4M，這顯然對很多HTML 5 遊戲來說是不足夠的。所以大家就需要將一些資源文件放到自己的遠程伺服器中。也就是這張圖所體現的訪問關係：當用戶掃你二維碼的時候，會讓小遊戲包下載到微信，然後微信內小遊戲包代碼在執行過程中會請求遠程伺服器資源。
不同用戶會將不同的資源下載到他自己的沙河環境當中，並且不同小遊戲之間的資源緩存也是相互分割的。這樣就可以保障不同用戶和不同小遊戲間的資源不會互相衝突。
H5開發者會非常在意首場景的加載體驗，微信小遊戲也非常需要注意這一點。小遊戲在下載過程中會將包首先完整下載，然後才會進行詳細的代碼完整初始化。在初始化之後再去加載遠程資源，再去啟動場景。
這與瀏覽器有很大的區別。瀏覽器永遠是按需加載，當它需要一個資源的時候才會加載一個資源。所以大家一定要在小遊戲當中控制好自己的包體大小。
經過一段時間研究並與微信團隊進行溝通後，我們得出了一個目前較好的資源解決方案。我們會將代碼包放在小遊戲包內，所有的資源都放在開發者的Server上。這樣，當代碼請求某個資源時，就會動態進行動態下載，這樣才能滿足按需加載的需求。
所以這張圖和上面那種圖沒有太大區別，唯一需要注意的是，在微信CDN上儲存代碼包，在開發者Server中儲存詳細的小遊戲資源。 值得注意的是，你的代碼是不能夠放到自己的Server上的，微信小遊戲禁止在微信CDN以外的域名中加載它的代碼。
接下來我解釋一下Cocos Creator是加載微信小遊戲時的資源策略。首先，我們同樣從微信的CDN當中下載代碼包。下載完成後，當你的代碼需要某些資源時，我們會先從大包裡去查找。若內置資源沒有，我們會去查找資源緩存（稍後解釋）。如果資源緩存也沒有，我們會從遠程伺服器去下載。數據下載後，我們會將數據自動緩存到資源環境中。這樣便形成了一個緩存機制。
我們這樣做的原因是，小遊戲環境是實際上是沒有類似瀏覽器的緩存和資源過期機制的。 在瀏覽器中，當用戶請求一個頁面時，第一次請求會下載所有資源，一段時間後，第二次請求時它會自動檢查所有資源是否過期，如果沒有過期則會從本地緩存空間中下載該資源，這對於開發者和用戶都是透明的。 但小遊戲沒有這樣的機制 ，所以當你的信息再去請求資源時，每次都會重新下載該資源，不管你這個資源此前下載過多少次。所產生耗電量和加載時間對於用戶來說都是不可接受的，所以我們在Cocos Creator當中內建了一個更完整的解決方案。
如何去處理資源過期的問題呢？如果說資源URL是完全一致的話，在邏輯當中是不會下載新資源的，這就會導致Bug。我們所推薦的解決方案是， 在Cocos Creator打包時會有一個「MD5 CASH」選項，勾選後我們會為所有文件名打上MD5碼。 這樣當文件更新後，文件名就會變化，這就一款為服務端URL會變化，這時代碼包在請求時就會被認定為一個新的資源，這樣就完成了資源緩存和更新機制。
同時我們還提供了API讓開發者刪除資源緩存，這樣在大版本更新時，如果緩存資源過多，你就可以先去清除緩存，然後再去更新所有資源。
當然，用戶如果覺得我們的資源管理方案不太適合你，你也可以去自己設計一個合適自己的資源管理方案。這些方案所以來的API微信都有提供，即微信文件API和微信網絡API。網絡API可以讓用戶將文件下載到緩存空間中；文件API可以支持文件的重命名、刪除等操作。
相信很多朋友關注的是，如果我已經有H5遊戲了，我怎樣把這個H5遊戲發布到小遊戲當中。這個其實是微信團隊非常關注的事情，他們希望大家的H5遊戲可以去針對微信做了社交玩法後發布到微信小遊戲環境當中。我們繼續以Cocos Creator為例來看如何將已有遊戲發布到小遊戲。
這張圖是我們編輯器的截圖，在這裡面可以去編輯場景、UI，可以進行資源的管理、發布、打包。
用Cocos發布小程序需要這幾個步驟：
1.你可以從你的小程序公眾平臺上找到App ID並輸入，然後將發布平臺修改為WechatGame。
2.點擊右下角build構建，你就會看到下面這個界面：
3.出現該畫面就說明在Cocos Creator構建完成後，就可以直接在微信開發者工具裡看到你的項目了。這個過程不需要用戶去修改任何配置文件。
4.當調起微信開發者工具之後，你就可以做預覽操作，在手機上測試微信小遊戲了。
總結一下知識點。
首先，微信提供遊戲上的支持，並且提供了龐大用戶基礎和用戶分享API，這肯定會催生出完全不同的遊戲體驗。我認為社交性玩法在微信上會有更大的發揮空間，會比以往的社交平臺都要大。
其次，我們講到了微信小遊戲和瀏覽器環境的2大差異：API支持和資源加載。
另外，我們推薦大家使用遊戲引擎，加速遊戲的開發和迭代，從而降低產品風險。
同時，小遊戲、手機頁遊、PC頁遊其實都依賴於HTML 5 的技術棧，包括Cocos Creator原生發布也都依賴於此。HTML 5 引擎提供了基於HTLM 5技術棧的跨平臺發布，為大家提供了更多選擇和可能性。
今天我們所說的HTML 5技術棧包括手機頁遊、手機原生和PC頁遊。手機頁遊包括QQ空間、微信小遊戲、釐米秀這些Runtime方案，Facebook Instant Games這種純H5方案以及愛微遊、瘋狂遊樂場這些H5渠道等。手機原生包括各種JSB、Runtime打包遊戲、微端遊戲等。第三個是PC頁遊，因為Flash之前宣布2020年停止更新，所以很多PC頁遊上的Flash遊戲現在也在轉成HTML 5 遊戲。
簡單計算一下，我用手機原生遊戲市場規模除以PC端遊規模，再乘以PC頁遊規模，粗略算出手機頁遊的市場空間可以打到每年280億人民幣。如果說，手機頁遊和PC頁遊互為此消彼長的話，向上取整則可能會有500億的市場空間。中國遊戲產業規模佔全球遊戲市場的25%，當然這個數還在上升，算上這一方面，H5技術棧可以支撐全球手機頁遊 + 部分手機原生 + PC頁遊市場，理論市場容量上限可以達到2000億人民幣。所以說，現在做這方面的技術儲備其實是非常有價值的。
1.作為個人開發者，利用微信的用戶和支付功能，而不是將微信作為一個引流工具，能否從遊戲中獲得較好的收益？另外，Cocos和微信支付對接中是否有坑？
關於支付：微信小遊戲目前還沒有與iOS打通，具體什麼時候打通我也不太清楚。所以說能否從遊戲中獲得較好的收益，這個問題應該由微信來回答，因為這些數據如今都是保密的，包括DAU、留存率、安卓目前的收益率、用戶畫像，像用戶畫像是需要你們去自己琢磨的。
關於引流：我不確認微信是否允許這麼做。但這肯定不是微信小遊戲團隊希望看到的結果
關於Cocos和微信支付對接：這種支付SDK對接根本就不是我關心的層面。就Cocos來說，與微信對接沒有什麼坑，只是純粹的SDK調用。我相信包括其他引擎也不會有什麼坑，因為實在是太簡單了。
2.微信小遊戲的優勢和劣勢有哪些？如何繞開劣勢？
優勢在於其龐大用戶基數與其社交性玩法，流量成本會很低。目前來看，若想造成病毒式的傳播，目前可能也就在Facebook、微信、QQ這種大的社交平臺上可以比較容易地實現。
當前劣勢可能還是在於對非遊玩家特點的理解上。我認為大部分微信小遊戲用戶很可能原來並不是傳統意義上的遊戲玩家。這些玩家的遊戲化需求、情感、樂趣，都和我們以往理解的手遊玩家不一樣。當然我認為也不能把這一點完全看成劣勢，因為就算是非遊戲玩家也是有遊戲化需求的。問題關鍵在於怎樣正確理解、切入、服務這些大量的非遊戲用戶。現在小遊戲剛剛起步，所有人都在摸索這件事情，誰能先利用好這個平臺的用戶特點，誰就能成為這個新領域的巨頭。
3.目前包括已上線的十幾款小遊戲都是以輕度休閒為主，處於試水階段，如何看待重度網遊在小程序的發展潛力和前景？
我從2個方向來講。
首先，其實在PC頁遊發展上也可以看到，都是從休閒遊戲（偷菜搶車位、抓奴隸）開始的，再將用戶培養到一定程度後才慢慢出現重度頁遊。手機頁遊也是如此，不要想著第一天就可以直接跳躍到重度遊戲。行業發展規則必然是要先去培養和教育用戶，然後再過渡到做中度、重度遊戲，我認為不會有非常快的跳躍。
其次，微信小遊戲很多玩家都是非遊戲玩家，他們目前對於重度遊戲可能並不會很感冒。如果是重度遊戲玩家，他為什麼要去玩小遊戲？到底小遊戲用戶裡有多少是重度玩家？重度玩家為什麼要玩微信小遊戲，而不是已有的《傳奇霸業》《奇蹟MU覺醒》等重度的微信精品遊戲，理由是什麼？這現在都是需要去摸索和探討的問題。其實就算是Facebook Instant Games目前也是主要由輕度休閒遊戲組成的。
其實就現在PC平臺來看，目前很多PC端遊的品類也沒有完全移到頁遊上面，典型如FPS、MOBA遊戲，在PC頁遊上是看不到的。平臺屬性還是天然就決定了的。端遊和PC端遊的用戶場景是不同的，像之前很多掛機類頁遊之所以能崛起，就是因為在很多場景下用戶不具備安裝客戶端的條件，同時也無法投入過多精力去進行端遊，比如在辦公室中。目前來看，手機原聲遊戲和手機頁遊的用戶場景確實有所重疊，但這都需要進一步地探討並優化。
4.小程序對初始包大小限制比較嚴格，目前看官方的《四川麻將》感覺很粗糙，如何突破這個限制？
初始包大小限制就是4M。粗不粗糙和初始包大小是沒有關係的，你可以首場景加載4M初始包 + 10M資源，只不過加載速度會慢而已，你的代碼加載更多也沒有問題。我認為可能《四川麻將》粗糙的原因可能在於開發者更多考慮了用戶的等待時間體驗。我們也是建議儘量控制首場景的大小，在之後的遊戲中逐漸加載更多資源，為用戶提供一種漸進加載的遊戲體驗。
5.微信小遊戲不支持熱更新了嗎？
熱更新在 HTML 5 遊戲中是不存在的，因為是沒有本地文件的，你永遠可以更新自己的伺服器內容，讓用戶得到更新的資源。對於小遊戲來說最關鍵的是，你能不能熱更新你的代碼包。你的代碼包會存儲在微信CDN中，你必須向微信CDN提交更新申請，至於具體的審核過程，還需要看後面微信官方所給出的具體方案。
6.小遊戲內存控制在多少比較合適？
這需要看用戶手機的硬體情況，開發者可以做的就是儘量控制不要讓內存佔用持續增長，維持在某一個峰值以下。我認為控制在100M以下比較安全。H5遊戲一般是控制在150M以內，200M也是可以跑，但不安全。安卓一般內存會比蘋果手機要大，所以在測試的時候優先測試蘋果手機，尤其是 iPhone 6，如果沒有崩潰現象，基本上就是可以了。
葉子豬每日行業播報系葉子豬遊戲網出品的資訊欄目，僅作於匯聚網際網路遊戲行業的每日資訊，如需查看文章出處可點擊閱讀原文。