微信小遊戲程式碼總包提升至20M，雲測試提供更多服務

在2021年微信公開課-分論壇小遊戲專場上微信公開課講師 lucia介紹了小遊戲在過去的一年裡做了哪些能力升級，比如資源容量擴容、提供多人聯機服務，雲測試服務升級等等。以下是其分享實錄：


大家好，我是微信公開課講師lucia。接下來我將分享關於調優遊戲體驗方面的內容，幫助大家進一步提升遊戲品質。小遊戲的品質在整個研發週期都至關重要，在研發的每個階段，開發者的關注點也有所不同。比如在開發階段，大家往往會關注平臺所提供的基礎能力；在測試和調優階段，大家會關注是否有一些簡單易用的調優工具；小遊戲上線之後，大家又需要對各種留存、新進資料進行分析，優化遊戲體驗。因此為了幫助大家進一步調優遊戲品質，我們在基礎能力、調優工具和線上分析這些內容上，進行了多方位的升級。


首先是對基礎能力的兩個升級。一個是資源容量擴容，另一個是提供了多人聯機的匹配服務，我們詳細來看一下。我們先來看容量擴容方面的調整。隨著越來越多的重度小遊戲加入微信平臺，為了更好的為大家提供支援，我們將程式碼包總包大小從16兆提升到了20兆。為了保證小遊戲的啟動效能，依舊能夠維持在一個高水平，首包大小依舊限制在4兆以內。但是在分包載入上就不再做任何限制，也為開發者提供更加豐富的操作空間。當然這裡我們依舊建議首包儘量小一點，最好能夠在兩兆左右。開發者可以使用動圖等無感知的二次載入策略，來優化下載過程。


另外在檔案快取上，本地使用者檔案和本地快取檔案的儲存大小，也提升到了200兆。支援開發者做更大體量的遊戲，本地也能儲存更多的內容。檔案快取容量的提升。首先從開發者角度看，研發上可以做到無感知接入，並且更大的快取空間也意味著快取的命中率變高，可以提升流量的複用性。

其次從內容角度上，遊戲設計師可以為玩家提供豐富的遊戲內勤。以重度遊戲中的MMORPG遊戲為例，不僅可以新增更多玩法內容，也可以提升遊戲世界的探索空間。最後從使用者體驗角度上，玩家減少了載入的頻次，保證了整個體驗的連貫性，也提升了沉浸感。最後拿新軒轅傳奇這個具體的小遊戲來說，程式碼包和檔案快取的提升，讓這款幾乎不可能實現的小遊戲最終成功上線。

下面我們再來看新加入的多人聯機匹配服務。之前我們的玩家已經可以邀請自己的好友對戰，平臺也具有對局房間和幀同步的能力。現在我們為了滿足多人聯機的需求，在平臺側加入了通用的遊戲匹配服務，開發者不需要自己再去寫一個匹配服務，就可以很方便的實現遊戲匹配的功能。


另一方面，玩家也可以和好友之外的世界玩家來進行互動。當然，這個遊戲匹配服務的接入方式也很簡單。首先開發者可以自定義匹配的規則，比如依靠某些資料定好每一局遊戲的人數和隊伍數量，然後使用幾個簡單的微信API就實現了遊戲的自動匹配能力。這裡也有一個簡單的例子可以看一下，這個就是匹配服務的簡單演示過程。大家可以感受到有了匹配服務，整個遊戲的可玩性也變得更高了。接入匹配服務的更加詳細的介紹，都在我們的微信小遊戲文件中，各位開發者可以之後查閱詳細的瞭解一下這方面的內容。相信這個能力的加入也會給玩家帶來比較好的遊戲體驗。


第二部分是工具上的升級，這部分主要是針對雲測試服務。雲測試服務6月份全量開放以來，已經有2600多款小遊戲參與使用，也幫助了1200多個開發者發現了潛在的效能問題。


右圖這個折線圖是一個典型的例子，是使用雲測試來提升小遊戲的啟動效能的。我們可以清晰的看到他們使用雲測試協助優化之後，資料方面提升了很多，最重要的是相比以往我們使用現網資料來進行優化，使用雲測試優化整個週期是大大縮短了的。因為現網資料的延遲性可能優化一次需要一週的時間，現在使用雲測試只需要1到2天，而且可以馬上知道優化效果。

不僅如此，因為雲測試的裝置機型很多。對於一些沒有足夠裝置的開發者來說，使用雲測試可以解決很多的問題。而且一次測試可以得到幾十臺裝置的效能資料，優化的效率當然也就非常高了。但是在上線這段時間我們也發現了一些問題，比如測試排隊的問題，很多開發者想要測試很小的問題，需要排隊很久。針對這個問題，我們在硬體層面上將裝置叢集數量翻了一倍，裝置數量也達到了200多臺，極大的縮短了排隊的時間。當然除了排隊時間，覆蓋到的裝置的型號也有了一倍的提升。針對排隊問題，我們也建議開發者在週一或者週二，或者是上午的時間提交測試。因為往往在週中或者下午的時間，排隊測試的小遊戲會比較多，所以排隊的時間相對來說也會比較久。


另一個問題是測試場景覆蓋率還不夠高的問題。針對這個問題，我們一方面對測試所用到的智慧探索演算法，進行了全面的升級，覆蓋率也提升了30%。另一方面在測試框架上也支援測試用例集，使得自定義測試指令碼的編寫變得更加簡單和規範。另外，還有報告內容解讀困難的問題。因為一下子從幾十臺裝置中快速定位到潛在的效能問題，確實存在難。因此我們也上線了測試評分的功能，給大家提供了一個定量的指標，也就可以很快的發現問題。


此外我們也上線了歷史報告對比的功能，方便大家檢視每次優化之後的關鍵指標的差異。另外，我們也推出了指定裝置排程這一個全新的測試模式。和之前的模式相比，在這個模式下開發者不需要排隊，所以如果開發者覺得原來的模式排隊時間比較長，也可以使用這個模式先測試一次。這兩種模式是可以同時測試的，測試的次數上也不會有影響。另外在這個模式下，開發者可以選擇自己想要測試的裝置機型。而且提供了兩種測試時長供大家選擇。但是為了避免裝置搶佔過度的問題，我們也限制了一次測試的機型不超過三臺，我們比較建議當開發者有想要驗證測試指令碼，或者是想要驗證特定機型下效能問題的時候來使用這個模式。


另外這個模式還有一個新的特性，就是它支援iOS CPU Profile的能力，我們來看一下這個能力，在前期因為缺少iOS CPU Profile的能力，很多開發者在面臨iOS效能瓶頸時無所適從。這個時候有些開發者可能會通過打點統計的方式來計算熱點函式，但是顯然這個方式代價很大，統計的力度比較粗，效果也就不夠理想。現在我們所提供的iOS CPU Profile的能力，是從JS引擎層面獲得效能資料。首先它的粒度很細，其次無論是從準確性、效率還是易用性方面都做到了極致。開發者只需要在程式碼中加入兩行程式碼就能得到效能資料，此外，我們也進一步消除了iOS和安卓的profile協議的差異，可以做到在雲測試中下載下來的profile檔案，無論是安卓還是iOS系統的，都可以直接載入到微信開發者工具中來檢視。


第三部分主要是針對大家對線上場景的分析的需求，我們主要推出了自定義場景分析、實時日誌和資料開放三個能力。首先是自定義場景分析。相信有很多開發者很好奇，自己投放的廣告的效果怎麼樣？使用者在小遊戲的哪個頁面流失比較多？這些疑問都可以通過自定義場景分析來得到解答。它提供了在遊戲中埋點上報的功能，開發者可以在後臺檢測到所上報的資料，針對各個場景中使用者行為進行個性化的統計和分析，來幫助遊戲調優。舉個例子：某款小遊戲想要了解在復活介面來看，分享的成功率和廣告的觀看率是怎麼樣的以便後續制定更好的策略。他們使用自定義場景分析，只需要在程式碼裡面加入幾行埋點程式碼，就可以得到線上的對應資料，也就能更清晰和帶有資料支援的來調優自己的小遊戲。


其次是實時日誌方面。實時日誌是開發者用來排查小遊戲線上錯誤的一種有效手段，在之前當小遊戲遇到線上錯誤時，開發者往往只能通過logmanager讓玩家主動反饋，自己是無法及時捕捉到錯誤。現在我們提供了實時日誌的功能，開發者就可以在程式碼的關鍵節點埋點，自動的上報日誌，接著就可以在後臺管理端進行查詢，來及時的發現遊戲的異常表現。


同樣我們也來舉一個例子。比如某款小遊戲線上上一直遇到白屏問題。但是這個問題比較難以復現，所以一直沒有辦法得到解決。這個過程中使用者流失很多，但是在接入實時日誌之後，白屏問題觸發的整個過程都可以在後臺清晰的看到，那也就很快的能夠定位到具體的問題得到解決，最後使用者流失率極大的降低了。

最後是資料開放。之前我們在微信小遊戲資料助手和小遊戲後臺，提供了豐富的小戲資料分析圖表，也深受開發者的好評。但是一些開發者主體下可能存在多個小遊戲，他們也就希望將這多個小遊戲的資料結合起來，綜合分析做到更深層次和定製化的效果。所以現在我們把圖表中的這些原始資料開放給大家，並集中在圖中所示的資料介面中。開發者可以通過介面來獲取資料、自行分析。現在從介面中獲取到的小遊戲的活躍數，現在已經可以從這個介面中獲取小遊戲的活躍資料、註冊資料、付費資料和分享資料這四種型別的資料。


就像大家從圖中看到的這樣，在每個類別下也有著更加細緻的資料屬性，大家可以檢視文件來詳細的瞭解和使用。另外，還有更多的資料我們正在逐步的開放。


最後做一個總結，我們在整個研發週期中對大家所關注的基礎能力、調優工具和線上分析能力做了升級。在基礎能力上對資源容量進行了擴容，並提供了多人聯機的匹配服務，支援大家做出內容更加豐富的小遊戲；在調優工具上，我們針對雲測試服務進行了全面的升級，並支援了iOS CPU Profile的能力，助力大家快速定位效能瓶頸，提升調優效率；最後我們還提供了自定義場景分析和實時日誌的能力，並開放了一些資料助手和後臺管理端的資料，大家可以針對線上遊戲的表現進行分析和調優。

我的分享就到這裡，謝謝大家！