2345游戲中心游戲中心大全游戲軟件平臺

　　6月8日，Unity技術開放日（Unity Open Day）正式在北京舉辦，會上來自Unity的技術專家、完美世界《誅仙手游》客戶端負責人、《放置少女》技術專家、FunPlus 引擎技術負責人等嘉賓，將帶來關于游戲管線渲染，性能優化、技術落地等實用技術分享

　　6月8日，Unity技術開放日（Unity Open Day）正式在北京舉辦，會上來自Unity的技術專家、完美世界《誅仙手游》客戶端負責人、《放置少女》技術專家、FunPlus 引擎技術負責人等嘉賓，將帶來關于游戲管線渲染，性能優化、技術落地等實用技術分享。

　　在活動中，Unity中國引擎底層架構技術主管趙亮以“Unity小游戲開發簡介”為題進行了精彩的分享。

　　小游戲是一種嵌在宿主應用內部，無需下載安裝，可以即點即玩的游戲產品形式。在國內小游戲用戶的規模龐大，在移動游戲市場里是一個不小的占比，大約占了20%左右，因此Unity也在逐步加大對于移動端小游戲的支持。

　　首先，我們介紹一下當前主流的小游戲平臺，以及他們采用的技術方案。接下來介紹一下即點即玩小游戲需要用到的資源流式加載，然后，我們分別介紹兩種小游戲技術方案，一種是Native Instant Game，另一種是WebGL，最后我們介紹一下我們未來的工作方向。

　　目前，我們國內有很多小游戲平臺，有微信、QQ、抖音游戲中心大全、頭條、快手，還有Oppo、Vivo、華為、榮耀、支付寶、淘寶、百度、233樂園，在這里我們簡單介紹一下比較具有代表性的兩個平臺：微信、抖音以及他們采用的技術方案。

　　微信是從2017年12月開始發布一個叫《跳一跳》的小游戲然后開始爆發，這里有一些公開的數據。2019年1月起開發者數量就已經超過10萬，2019年5月份的時候用戶過億，在2021年的時候，據說流水過千萬的產品已經超過了50款。

　　這張圖上面展示了微信小游戲的品類，隨著時間的發展趨勢，我們可以看出，小游戲品類近年逐漸從超休閑向中重度發展，例如像MMO、策略類的游戲也開始往小游戲平臺上來。

　　大家可以關注一下微信的公開課，上面有一些開發者分享了使用Unity去開發小游戲的經驗。在上一季有《我叫MT2》的分享，這一季還會有《小小蟻國》的案例分享。

　　在抖音的平臺上面，巨量算數調研發現，小游戲的受歡迎程度僅次于App游戲，同時小游戲用戶規模較大，特征也比較顯著，大多是這種18-40歲的年輕男性比較多，消費能力還是可以的。

　　然后在宿主應用中去實現一個即點即玩的小游戲，目前主要有兩種技術方案，一種是基于瀏覽器的內核，使用Web Assembly再加上WebGL的方案，另一種是在安卓上實現的這個Native Instant Game。

　　WebGL方案的同時支持iOS、安卓兩個操作系統，大部分的小游戲平臺都采用了這個方案。Native Instant Game僅僅能支持安卓系統，不過它有它的好處，它的好處是游戲的品質可以媲美原生App，目前抖音、頭條、快手已經集成了這個方案，支付寶也在集成的過程中。

　　前面提到了小游戲從超休閑往中重度不斷發展，小游戲中用到的資產的越來越多2345游戲中心，有一些小游戲資產打包之后有幾百兆，甚至1G以上，所以說小游戲其實越來越不小了。為了讓玩家可以即點即玩，減少等待下載的時間，需要對這個資源進行按需的、流式的下載跟加載。

　　對于一個游戲開發者來說，管理好這個資源的流式加載，還是需要投入不少的開發時間。因此，我們在引擎側開發了這個Autostreaming的功能，讓引擎底層自動的去處理好這個流式加載。

　　這里我們簡單介紹一下這個Autostreaming的自動流式加載的工作原理。這個Editor里面，我們提供了工具，可以在打包的時候自動分離出重度資源，例如像Texture、Mash、Audio、Animation等，這些資源會被部署到云上面去。在分離出重度資源之后，游戲的首包A/B包會大大減小，因此，可以讓小游戲快速的下載、加載。

　　在游戲運行的時候，引擎會根據需要自動從云上去下載資源，開發者不用修改游戲的邏輯，可以像往常一樣同步的去Instant一個profile。然后，這些Texture、Mash會在一個后臺隊列里自動的被下載跟加載。

　　在這里，我們以一款線上的WebGL小游戲為案例，看一看這個Autostreaming的效果。首先，我們可以看到首包中的數據減少了很多，從42M降到了6.8M，因此大大減少了啟動的耗時，從40秒降到了不到八秒，用戶打的A/B也減小了一些。

　　在這個案例里面，因為我們只選擇了一部分貼圖做Autostreaming。所以瘦身的程度還不是很大，另一處很重要的收益來自于內存，內存占用減少了75M，這個內存對于WebGL在iOS平臺上是很珍貴的，后面我們會詳細的聊這一點。減小的原因，主要是被剝離的重度資源有的更加合理的生命周期，沒有開啟Autostreaming，這些紋理游戲軟件平臺、加載后等依然會占用一部分內存。

　　例如首包的內存，還有A/B沒有被Unload之后的內存，這是WebGL平臺一個比較特殊的地方，它沒有一個真正的文件系統，只有一個內存中的文件系統，所以說一個文件進來之后，就得先放到內存里面去，跟我們在原生的App上不一樣，原生的App這個文件還是一個文件，你在讀的時候只是每次會讀取一塊，我們只要用一個內存緩存放到一個窗口就可以去訪問這個文件。

　　接下來我們先簡單介紹一下Native Instant Game的一個方案。它的優點很明顯，它可以直接對標原生的App，跟原生的App性能是一樣的，體驗也是一樣的，支持多線也支持Vulkan。原聲App用的插件它也都可以用，它可以采用同步的方式去訪問沙盒中的文件，訪問的效率比較高，同時占的內存也比較少，它以一個獨立的紫禁城運行在沙河之中，不會干擾宿主的運行，引入一些穩定性或者是安全的問題。

　　對于Native Instant Game，我們提供了完整的提審、發布、更新方案，所以對于移動游戲開發者來說，適配Native Instant Game的成本很低，只要做好資源的流式加載，不需要再做一些額外的適配與性能優化。

　　這里有一張截屏，來自抖音平臺上面的一個小游戲叫做《古董就是玩》，它的材質品質比較高，我們曾經也嘗試將這款游戲配套到WebGL平臺，那個畫質的降低還是比較明顯的。所以說，這也就是Native Instant Game的一個優點。

　　當然，講了這么多優點，它的缺點也比較明顯，就是他目前沒辦法支持iOS這個平臺，iOS平臺還是很重要的，所以微信沒有集成這個方案，字節和快手這些平臺選擇另一個策略，就是兩個方案都支持，在iOS上使用WebGL的方案，在安卓上，既支持WebGL，也支持Native Instant Game。

　　所以有些游戲想追求性能天花板更高的話，就可以Native Instant Game，假如它是追求受眾更多，我的游戲品質還沒達到這個性能天花板的上限，那我可以選用WebGL的一個方案去做。

　　這張圖上面我們簡單介紹一下Native Instant Game的工作原理，我們首先把每個小游戲都要運用到的這種運行實庫、默認資源打包在一起，作為一個共享的引擎包，方便這個宿主App提前準備好，從而減少每個小游戲啟動時候等待下載的時間。這個共享的引擎包大約有9Mb，具體包含了這些東西，有運行時庫運例如像Unity.so、Mono.os這種東西，還有一些通用的.Nel的dll、System.dll、Unity Engine.dll這種東西，然后還有Unity default resource.

　　有了這個共享的引擎包之后，開發者對小游戲平臺進行打包的時候，這個游戲基本上打包成兩部分就可以了。首先是一個很小的首包，基本上在5~10M左右，可以方便小游戲快速的下載跟加載。它里面主要包含這個游戲本身的邏輯，以及一些第三方的SO插件。

　　另一部分就是游戲啟動之后的流式加載資源，當用戶使用前面提到的Autostreaming工具，Unity Editor會自動拆分出這些比較重度的資源部署到這個UOS上面去，UOS今天上午我們同事應該介紹過。

　　同時，我們會生成一個描述文件，里面包含了游戲的名稱，首包的UAL地址、引擎的UAL地址，以及這些文件的Jersey信息。這個信息可以提供給宿主的客戶端加載一個小游戲的時候去使用，也可以供這個開發者去向平臺去提審，他只要提審這個Jersey文件就好了，然后平臺可以通過這個Jersey文件知道你是哪一個游戲。

　　當宿主的客戶端選擇去啟動一個小游戲的時候，他會根據剛剛提到的Jersey文件里面的描述，下載到游戲的首包，然后還有前面提到的這個共享的引擎包，宿主通常都會提前下載解壓準備好。然后，客戶端把這個首包解壓到小游戲對應的這個文件夾里面去，然后通過一個很小的Instant Game Launching啟動這個小游戲就好了。

　　所以說，宿主的App它集成了這個Native Instant Game的能力游戲軟件平臺，對宿主APK增加其實是很小的，因為這個Instant Game Launch本身并不大，邏輯不復雜。然后當unity小游戲運行的時候，他會根據自己的需要，自動的從云端去下載這些所需的資源。這個是針對Autostreaming的情況，假如不是Autostreaming，那用戶就要需要自己去下載。

　　接下來我們就更為詳細的介紹一下WebGL的方案，它的方案優點很明顯，支持安卓也支持iOS，但是WebGL方案限制很多，在這里我們會用更多的篇幅來介紹WebGL。

　　首先，我們來看一看平臺的特點。這個WebGL在iOS平臺上的時候，內存十分受限，低檔機不能超過1G的內存，高檔機上限大概在1.4G左右，一旦超過這個限制很可能就會觸發操作系統的Out for memory然后迫使這個進程重啟。從CPU這邊的性能來看的話，WebGL的運行效率比原生的app要慢三倍左右，它目前只支持單線程，不支持多線程，所以WebGL小游戲的CPU性能比原生的app要低不少。

　　在圖形API上面，它只支持WebGL1和WebGL2，所以說有一些高級特性跟優化沒辦法使用，例如computer shader這種。剛剛前面也提到，它沒有文件系統，所以需要更大的內存去模擬文件系統，這也導致Unitycrash機制受到很大影響，crash文件無法被同步訪問。

　　由于這個CPU測性能比較弱，在iOS上當這個游戲復雜度提高，計算量增大的時候，手機很容易過熱。對于網絡API它也有限制，它只支持websocket，所以說這一點需要開發者進行適配，因為以上這幾種限制，導致它能使用的插件也比較有限。還有一點，iOS對WebGL平臺的支持也不盡如人意，我們經常需要為iOS平臺做一些特殊的優化，寫一些特別的workround。

　　總的來說，對于WebGL方案的話，iOS平臺的問題比安卓平臺的問題要更多一些，因此在接下來我們更多的都關注在iOS平臺上，如何去profile與優化小游戲，只要iOS平臺優化好了，之后安卓平臺基本上問題不大。

　　這里我們就使用一個案例，分別打包成一個原生的app跟一個WebGL的小游戲來去對比內存、CPU、GPU的差異，我們測試使用的手機是一個iphone12。我們先看一下內存，左邊是原生App，右邊是iOS上WebGL小游戲，我們可以看到總的內存占用多了450M左右，然后增大的地方一個是WASM的加載與編譯，占到了370M，然后還有WASM heap里面有一些Unallocated的地方多出來90M，然后File System多了60M。

　　WASM的加載與編譯主要是因為除了WASM文件本身之外，瀏覽器的內核在代碼編譯執行的時候也會產生更多的內存消耗，相關的緩存、GIT的優化都會使用比較多的內存。假如一個WASM是30M，它加載進來之后可能會有300M，漲了十倍左右。

　　然后多出來的是WASM heap中間的Unallocated部分，WASM heap的大小，它是從一個預設值開始，然后以一定的步長去逐步擴容，但這個擴容的方式比較傻，它需要復制整個areabuffer，所以說在它擴容的時候，會產生一個很高的內存峰值。假如我們從400M擴容到500M，意味著在擴容的時候，400M也在500M也在，總共會有一個900M的峰值。

　　所以說我們在這里就建議開發者，根據這個游戲實際的內存峰值，在開始的時候，設一個比較大的預設值，但這樣會帶來另一個問題，就是它通常在尾部會有一段尚未分配的地方，也就是我們看到的這90M的地方。然后是文件系統會多使用內存，這個是剛剛提到的，瀏覽器的一個沙盒機制，導致這個WebGL無法訪問本地的文件，它為了瀏覽器的安全，只能就是說使用javascript加inndexDB去模擬文件系統。WASM去訪問javascript、javascript再去訪問inndexDB，在這里的話就是說，它不能夠像Native的文件系統那樣直接使用一小塊內存，然后逐漸的去訪問一個大的文件。

　　還有一處值得我們注意的地方，就是mono heap和Emspripten malloc分配的這個空閑空間，在WebGL上面mono heap是由Auto CPP去分配管理，其他的native內存包含引擎的native heap或者第三方庫都是由Emspripten malloc來分配管理，這兩個討厭的地方是，它們都是只增不減而且相互獨立，空閑的空間無法共享，所以說我們要注意控制各自的峰值，誰的峰值高了都不行，因為他高了之后，他降下來之后空余出來的內存，假如mono heap空出來了之后，Emspripten那邊就用不到。

　　最后，我們看到WebGL這邊相比原生的app也有一部分地方內存占用有減少。比較顯著的是這個native heap的IL2Cpp Runtime，從101M降到了35.3M。這里主要是因為我們針對WebGL平臺做了優化，后面會比較詳細的介紹這一塊的東西。Asset相關的部分也有降低，因為我們資源壓縮格式進行了調整，還有一些差異就來自于引擎底層的內存分配器，在不同的平臺上面行為跟策略有些不一樣2345游戲中心。

　　看完內存之后，我們先來看一下CPU。從之前在網上面看別人的Benchmark研究就是說webassembly的執行效率大約是原生app的三分之一左右，我們也拿了一款真實的小游戲做了測試，在iphone12上測的。

　　從這個timeline profile我們可以看出來，原生App每幀耗時大概是在3.5毫秒左右，WebGL小游戲耗時需要到十個毫秒，所以總體看來，WebGL小游戲的CPU性能跟原生app相比確實是差了三倍，印證了之前Benchmark的結果。

　　再往后我們看一下GPU的對比，這邊的話，去除這個空白網頁本身的GPU消耗，對于一個游戲，WebGL跟原生app的GPU性能差距其實不算大，相比較CPU跟內存，GPU這一塊我們可以假定認為WebGL小游戲的GPU能力跟原生app基本差不多。

　　然后簡單介紹一下，WebGL小游戲的開發或者是移植，近幾年已經有大量的成功案例，所以說新進來的開發者不用很擔心，這邊之前已經有很多大家的經驗在里面，或者之前踩過的坑都已經處理好了。我們Unity這邊有一個官方的qq群，大家有興趣的話可以加進來。微信他們因為支持WebGL小游戲也要支持Unity，所以他們也整理了很詳盡的教程，前面提到，他們公開課上也有一些開發者分享了一些使用unity開發小游戲的一些經驗。

　　為了減輕WebGL平臺這些限制對小游戲開發的影響的，我們在引擎側也做了很多的優化跟改進。我們優化了內存的占用、繪制的效率、嘗試進一步給引擎代碼瘦身，我們也在不斷的優化小游戲的啟動速度。

　　接下來我們來看一下在內存方面我們做過的優化工作，主要一個是IL2CPP的運行時內存占用，我們這塊優化的比較多，一個案例就是我們從64M一直降到了33M，然后我們還優化了DynamicVBO pool的復用機制，可以減少粒子系統這些內存占用，我們這邊測試的一個案例的是從59M降到了38M。后面提到了一些代碼輕量化或者是資源裁剪也會幫助減少運行時的內存占用。

　　這里我們來詳細介紹一下IL2CPP運行時的內存優化。首先，我們來分析一下IL2CPP運行時主要的內存開銷，從這個表格里面我們可以看出來，它主要是三塊內容，一個是Metadata，這個是我們在運行時構建的元數據結構，里面主要是一些IL2CPPClass還有它的一些成員變量，第二個是global-metadata.dat，這個是我們打包時生成的元數據序列化文件，在WebGL平臺上面會被完整的下載到內存中間來，再然后是一個哈希表，這個哈希表是用來加速元數據訪問。

　　目前，我們優化主要是針對Metadata部分，這里采用的方式是針對IL2CPP的Class，還有它的一些成員變量進行延遲加載。這個成員變量里面主要是Methodinfo占比最大，在IL2CPP之前的實現當中，在使用到某個類型的時候，我們就把這個類型完全的給初始化了，包括它所有的函數、接口、事件、屬性、虛表這些東西游戲中心大全，但是后來分析發現，腳本代碼在運行中間通常只會用到很少的一部分原數據，只有在一些反射或者是虛函數調用的時候才會訪問。

　　這里有一個例子，我們有一個數組類型，它有155個方法，25個虛函數，實現了六個接口，但實際運行中間，只會用到其中很小的一部分，所以說我們的優化思路就是，去延遲加載這些元數據，真正等到使用的時候才會去初始化、分配內存。

　　總之，右邊的圖我們可以看出來，這里除了Fields之外的其他信息都可以進行延遲加載。Fields信息就是說，在構建這個對象實例的時候就需要，因為他決定了這個對象實例的內存布局。我們這里延遲加載的力度基本上就可以精確到諸個方法。延遲加載也會帶來一個比較小的開銷，就是說它訪問之前需要做一次非空的判斷，我們目前還沒有profile出來這會帶來一些性能回退。

　　在這里，我們拿兩個實際案例來對比一下優化前和優化后的內存占用，可以看到，第一個案例是從63.8降到了33M，第二個是從11M降到了6.5M。除了我們剛剛提到的Metadata內存降低之外，我們可以看到就是說這個Hashtable也降了。

　　除了上面說的內存優化之外，我們在繪制這邊也做了很多優化工作，在WebGL2上面，我們剛剛提到它不支持computer shader，所以說GPU skinning不能使用，我們在這里通過transform feedback支持了GPU Skinning，在我們的測試案例中把這個幀率從15幀提高到了24幀。

　　然后我們還優化了Shader Compiler，可以把non-const global的變量移到這個函數集中間。很奇怪的是這樣移過來之后，我們的幀率可以從23幀提到了55幀。還有這種像Immediate Const Buffer的轉換，我們把它實名成const，并且賦予一個初始值，然后就可以把這個幀率從32fps升到37fps，這都是一些實際工作過程中發現的這些細節的地方。

　　這里面我們還提供了一個配置的max vislble light值，之前的默認值設成32，但32這個值太大了，把它改成16甚至更小的值之后，性能會有很大的提升。

　　前面還說到了iOS平臺對WebGL的支持不夠好，所以說針對iOS平臺我們也做了一些特殊的walkround，優化了urpbatch在iOS上的行為，避免使用過多uniform變量，否則iOS設備上的性能會急劇下降，然后在iOS14.x-15.4版本上有一個bug，所以說針對這些版本我們對于同一個canvas不去共享IB和VB，這樣可以改善UI這邊的渲染性能。

　　這里介紹一下我們在WebGL2上面通過這個transform feedback來實現的GPU skinning游戲軟件平臺，在這里我們可以看到，打開了GPU skinning后每一幀的耗時，大家可以看到上面的數字，左邊是每幀的耗時游戲軟件平臺，中間是近期它耗時的最小值，右邊是近期耗時的最大值，我們只關注左邊這個數字就好了。左邊是開啟了transform feedback的GPU skinning之后，平均每幀大概在42毫秒，假如沒有開啟它，每幀需要消耗大概67毫秒。

　　接下來我們來看一下引擎代碼的輕量化，從前面的內存分析我們知道30M的一個WASM加載的時候會占300多兆的內存，所以說我們希望生成的WASM越小越好。之前Unity裁剪的方法有這種Managed Code Strip、Engine Code Strip，它們是通過靜態分析依賴的方式去做strip，然后以函數為顆粒度，我們在這里會更加深入的去分析，我們生成的WASM代碼，看看除了這兩個Strip之外，是不是還有更多的優化空間。

　　這里我們分析了兩個案例，他們游戲的WASM指令數大概都是在1200萬左右。可以看得出來都IL2CPP在里面占了大頭達到60%，引擎的c++代碼大概占了40%左右。我們按照模塊進行排序，可以看到其中比較重的模塊有physx、Particle System、Sqlite、Mecanim這些。

　　目前通過分析發現的問題有像這個案例二，它是一個消除類的游戲，沒有使用到很多physx的仿真，僅僅只是在UI上使用了physx的射線檢測，然后又因為這個原因，引入了一個龐大的physx庫，這是很不合理的。然后我們還發現這個WASM里面有很多模板展開的代碼，就是說拿空間換時間，在某些平臺上面可能是比較不錯的策略，但對于WebGL這個平臺，我們內存特別緊張，所以在這個平臺上不是一個好的策略，針對WebGL平臺不使用這么多的模板。

　　所以目前，我們針對這個代碼裁剪作為工作，就是把一部分的模板改成了函數參數，不去給它進行展開，然后的話用宏去剔除一些WebGL項目中用不到的模板跟函數，例如像Sqlite，還有physx的一部分功能，以及像computer shader的這種目前不支持的東西也可以把它先踢出去，未來我們還會繼續去清理啟動流程、主循環里面這些不必要的步驟。還有就是IL2CPP代碼的生成占了60%，這一塊我們要探索怎么去把這個東西優化掉一些。

　　現在我們看一下加快啟動速度，這里我們主要做了兩件事情，一個是說跟平臺合作，讓平臺去提供一個中文字體，這樣就避免了每個小游戲里面都自己需要打包一個中文字體，這可以節省5M到10M左右的下載時間。還有，我們可以動態的去裁剪這個unity default resource，因為default resource里面的些資源不見得每個小游戲都得用，目前看來，對于大部分游戲我們可以把default resource從3.5M降到400K左右。我們之前還嘗試過通過WASM snapshot的方式進行加載，不過這個方案我們還沒跑通。

　　接下來聊一下未來工作的方向，接下來我們主要的有兩塊東西，一個是多線程，還有一個是WebGPU，除了這些之外我們還會再探索一些像webAssembly上面的SIMD支持，然后甚至嘗試讓WebGL平臺也去支持burst。

　　Unity其實現在就已經可以打開WebG的多線程，從瀏覽器中截下來的profile可以看到，打開的多線程之后，這些job從主線程轉移到了Webwork上面。

　　然后這里還是針對之前那個測試案例嘗試使用多線程，在使用多線毫秒降到了每幀消耗大概是在38-40毫秒。

　　但是目前Unity的多線程實現的還不夠穩定、不夠完善。例如切換場景的時候可能會Crash，我們目前還不支持Render THread，因為這個Web worker訪問不了DOM，然后之前我們也可以講到，打開了多線程之后，左邊這個內存增加了，從1.25G增到了1.69G，內存增加的比較厲害。然后還有一個限制，目前WebGL的多線程只能支持native代碼還不支持C#代碼，這些都是我們未來努力解決的問題。

　　然后就是WebGPU，今年四月份的時候，然后Chrom的113就已經支持WebGPU，我們目前正在集成，一邊集成一邊研究如何去重構我們的GFS device接口層使它更加接近于現代圖形API，從更多發揮出WebGPU的性能優勢，今天就介紹到這里，謝謝大家。