在游戲和VR項目的研發(fā)過程中闭树，加載模塊所帶來的效率開銷和內(nèi)存占用（即“加載效率”、“場景切換速度”等）經(jīng)常是開發(fā)團隊非常頭疼的問題柬赐，它不僅包括資源的加載耗時凰慈，同時也包含場景物件的實例化和資源卸載等。在我們看來钳榨，該模塊的耗時是目前引擎中僅次于渲染的第二大模塊舰罚。因此，我們認(rèn)為非常有必要來跟大家分享一下目前加載模塊的主要性能問題重绷。
我們通過對提交到www.uwa4d.com網(wǎng)站的大量項目進行分析沸停，認(rèn)為目前加載模塊中最為耗時的性能開銷可以歸結(jié)為以下幾類：資源加載、資源卸載昭卓、Object的實例化和代碼的序列化等。今天瘟滨，我們先為大家?guī)碣Y源加載中紋理資源的加載性能分析候醒。
這是侑虎科技第48篇原創(chuàng)文章，歡迎轉(zhuǎn)發(fā)分享杂瘸，未經(jīng)作者授權(quán)請勿轉(zhuǎn)載倒淫。同時如果您有任何獨到的見解或者發(fā)現(xiàn)也歡迎聯(lián)系我們，一起探討败玉。（QQ群465082844）
資源加載
資源加載是加載模塊中最為耗時的部分敌土，其CPU開銷在Unity引擎中主要體現(xiàn)在Loading.UpdatePreloading和Loading.ReadObject兩項中，相信經(jīng)常查看Profiler的朋友對這兩項肯定毫不陌生了运翼。
Loading.UpdatePreloading返干，這一項僅在調(diào)用類似LoadLevel（Async）的接口處出現(xiàn)，主要負(fù)責(zé)卸載當(dāng)前場景的資源血淌，并且加載下一場景中的相關(guān)資源和序列化信息等矩欠。下一場景中，自身所擁有的GameObject和資源越多悠夯，其加載開銷越大癌淮。
在很多項目中，存在另外一種加載方式沦补，即場景為空場景乳蓄，絕大部分資源和GameObject都是通過OnLevelWasLoaded回調(diào)函數(shù)中進行加載、實例化和拼合的夕膀。對于這種情況虚倒，Loading.UpdatePreloading的加載開銷會很小美侦。
Loading.ReadObject，這一項記錄的則是資源加載時的真正資源讀取性能開銷裹刮，基本上引擎的主流資源（紋理資源音榜、網(wǎng)格資源、動畫片段等等）讀取均是通過該項來進行體現(xiàn)捧弃≡穑可以說，這一項很大程度上決定了項目場景的切換效率违霞。正因如此嘴办，我們就當(dāng)前項目中所用的主流資源進行了大量的測試和分析，下面我們將分析結(jié)果與大家一起分享买鸽，希望可以幫到正在進行開發(fā)的你涧郊。
注意事項：本篇文章的資源性能分析主要是針對移動項目而言，因為目前UWA所測評的項目中眼五，移動游戲/應(yīng)用占比在90%以上妆艘。所以，我們選擇首先在移動設(shè)備上針對每種資源的加載性能進行分析和總結(jié)看幼。
資源加載性能測試代碼
以下為我們測試時所使用的測試代碼批旺，我們將每種資源均制作成一定大小的AssetBundle文件，并逐一通過以下代碼在不同設(shè)備上進行加載诵姜，以期得到不同硬件設(shè)備上的資源加載性能比較汽煮。
測試環(huán)境
引擎版本：Unity 5.2版本
測試設(shè)備：五臺不同檔次的移動設(shè)備（Android：紅米2、紅米Note2和三星S6棚唆，iOS：iPhone 5 和 iPhone 6）
紋理資源
紋理資源是項目加載過程中開銷占用最大的資源之一暇赤，其加載效率由其自身大小決定。目前宵凌，決定紋理資源大小的因素主要有三種：分辨率鞋囊、格式和Mipmap是否開啟。
1. 分辨率 & 格式
分辨率和格式是影響紋理資源加載效率的重要因素摆寄，因為這兩項的設(shè)置對紋理資源的大小影響很大失暴。因此，我們對這兩種因素進行了詳細的測試：
測試1：相同格式微饥、不同分辨率的加載效率測試
我們選取了兩張分辨率為2048x2048的普通紋理資源逗扒，并在打成AssetBundle時，將其分辨率最大值分別設(shè)置為512x512欠橘、1024x1024和2048x20248矩肩，紋理格式均設(shè)置為ETC1（Android）和PVRTC（iOS）、且關(guān)閉Mipmap功能。所以黍檩，三組紋理的內(nèi)存占用分別為256KB叉袍、1MB和4MB，其對應(yīng)AssetBundle大小為156KB刽酱、531KB和1.92MB（對于Android平臺）喳逛、175KB、628KB和2.4MB（對于iOS平臺）棵里。Unity 版本為5.2润文，壓縮格式為默認(rèn)的LZMA壓縮。
Android平臺測試紋理：
我們在五種不同檔次的機型上加載這些紋理資源殿怜，為降低偶然性典蝌，每臺設(shè)備上重復(fù)進行十次加載操作并將取其平均值作為最終性能開銷。具體測試結(jié)果如下表所示头谜。
通過上述測試骏掀，我們可以得到以下結(jié)論：
1、紋理資源的分辨率對加載性能影響較大柱告，分辨率越高截驮，其加載越為耗時。設(shè)備性能越差际度，其耗時差別越為明顯侧纯；
2、設(shè)備越好甲脏，加載效率確實越高。但是妹笆，對于硬件支持紋理（ETC1/PVRTC）來說,中高端設(shè)備的加載效率差別已經(jīng)很小块请，比如圖中的紅米Note2和三星S6設(shè)備，差別已經(jīng)很不明顯拳缠。
測試2：不同格式墩新、相同分辨率的加載效率測試
我們選取了兩張分辨率為1024x1024的普通紋理資源，并在打成AssetBundle時窟坐，根據(jù)不同平臺將其紋理格式分別設(shè)置不同格式用于打包海渊。對于Android平臺，我們使用ETC1哲鸳、ETC2臣疑、RGBA16和RGBA32四種格式，對于iOS平臺徙菠，我們使用PVRTC 4BPP讯沈、RGBA16和RGBA32三種格式，同時婿奔，對于每張紋理均關(guān)閉Mipmap功能缺狠。所以问慎，三組紋理的內(nèi)存占用分別為1MB、1MB麻诀、4MB 和 8MB（Android平臺）/1MB言疗、4MB 和 8MB（iOS平臺）惊暴。
Android平臺測試紋理：
與測試1相同，我們在五種不同檔次的機型上重復(fù)進行十次加載操作并將取其平均值作為最終性能開銷笼恰。具體測試結(jié)果如下圖所示。?
Android設(shè)備：
iOS設(shè)備：
通過上述測試囚衔，我們可以得到以下結(jié)論：
1挖腰、紋理資源的格式對加載性能影響同樣較大，Android平臺上练湿，ETC1和ETC2的加載效率最高猴仑。同樣，iOS平臺上肥哎，PVRTC 4BPP的加載效率最高辽俗。
2、RGBA16格式紋理的加載效率同樣很高篡诽，與RGBA32格式相比崖飘，其加載效率與ETC1/PVRTC非常接近，并且設(shè)備越好杈女，加載開銷差別越不明顯朱浴；
3、RGBA32格式紋理的加載效率受硬件設(shè)備的性能影響較大达椰，ETC/PVRTC/RGBA16受硬件設(shè)備的影響較低翰蠢。
注意事項：這里需要指出的是測試中所使用的ETC1和ETC2紋理均為RGB 4Bit格式，所以對于半透明紋理貼圖啰劲，需要兩張ETC1格式的紋理進行支持（一張RGB通道梁沧，一張Alpha通道）。逐一加載兩張ETC1格式的紋理蝇裤，其加載效率要低于RGBA16格式廷支，但可以通過加載方式來進行彌補。這一點我們將在后續(xù)文章中進行詳細說明栓辜。
2. 開啟Mipmap功能
開啟Mipmap功能同樣會增大一部分紋理大小恋拍，一般來說，其內(nèi)存會增加至原始大小的1.33倍啃憎。因此芝囤，我們對開啟Mipmap功能前后的加載性能進行了詳細的測試：
測試3：開啟/關(guān)閉Mipmap功能的加載效率測試
我們?nèi)匀皇褂脙蓮埛直媛蕿?024x1024的普通紋理資源，分別使用ETC1格式、PVRTC格式悯姊、RGBA16格式和RGBA32格式（測試所用紋理與測試2相同）羡藐，并在打成AssetBundle時，一組開啟Mipmap功能悯许，一組關(guān)閉Mipmap功能仆嗦。
與測試1相同，我們在五種不同檔次的機型上重復(fù)進行十次加載操作并將取其平均值作為最終性能開銷先壕。具體測試結(jié)果如下圖所示瘩扼。
Android平臺：
iOS平臺：
通過上述測試，我們可以看出：?開啟Mipmap功能會導(dǎo)致資源加載更為耗時垃僚，且設(shè)備性能越差集绰，其加載效率影響越大。
通過以上性能測試谆棺，我們對于紋理資源的加載建議如下：
1栽燕、嚴(yán)格控制RGBA32和ARGB32紋理的使用，在保證視覺效果的前提下改淑，盡可能采用“夠用就好”的原則碍岔，降低紋理資源的分辨率，以及使用硬件支持的紋理格式朵夏。
2蔼啦、在硬件格式（ETC、PVRTC）無法滿足視覺效果時仰猖，RGBA16格式是一種較為理想的折中選擇捏肢，既可以增加視覺效果，又可以保持較低的加載耗時饥侵。
3猛计、嚴(yán)格檢查紋理資源的Mipmap功能，特別注意UI紋理的Mipmap是否開啟爆捞。在UWA測評過的項目中，有不少項目的UI紋理均開啟了Mipmap功能勾拉，不僅造成了內(nèi)存占用上的浪費煮甥，同時也增加了不小的加載時間。
4藕赞、ETC2對于支持OpenGL ES3.0的Android移動設(shè)備來說成肘，是一個很好的處理半透明的紋理格式。但是斧蜕，如果你的游戲需要在大量OpenGL ES2.0的設(shè)備上進行運行双霍，那么我們不建議使用ETC2格式紋理。因為不僅會造成大量的內(nèi)存占用（ETC2轉(zhuǎn)成RGBA32），同時也增加一定的加載時間洒闸。下圖為測試2中所用的測試紋理在三星S3和S4設(shè)備上加載性能表現(xiàn)染坯。可以看出丘逸，在OpenGL ES2.0設(shè)備上单鹿，ETC2格式紋理的加載要明顯高于ETC1格式，且略高于RGBA16格式紋理深纲。因此仲锄，建議研發(fā)團隊在項目中謹(jǐn)慎使用ETC2格式紋理。
正是由于以上加載效率問題湃鹊，我們在UWA測評報告中加入了對每個檢測到的紋理資源參數(shù)的詳細展示儒喊，以方便開發(fā)團隊可以快速查看資源的使用情況，只需對相關(guān)信息列進行排序币呵，即可定位引發(fā)性能問題的具體資源怀愧。
說明：以上測試數(shù)據(jù)為我們所用的測試紋理加載數(shù)據(jù)，需要指出的是富雅，不同紋理的加載效率是不相同的掸驱，因為其內(nèi)容的不同會造成AssetBundle壓縮包大小的不同，進而造成最終加載效率的不同没佑。這里我們給出的具體性能比較毕贼，其本意是讓大家通過數(shù)據(jù)直觀了解到紋理格式、分辨率和Mipmap功能對加載性能的影響蛤奢。另外鬼癣，我們后續(xù)會進行更多的測試，以期為大家提供更為普遍的測試結(jié)果啤贩。
以上為紋理資源在加載時的性能測試待秃。關(guān)于加載模塊的性能問題，我們會不斷推出網(wǎng)格痹屹、音頻等其他資源的加載性能分析章郁、資源卸載性能分析、資源實例化性能分析志衍、不同加載方式的性能分析等一系列技術(shù)文章暖庄，并對目前UWA所檢測過項目的共性問題進行總結(jié)，以期讓大家對項目的加載效率有更加深入的認(rèn)知楼肪，并提升對加載模塊的掌控能力培廓。
