iOS和android遊戲紋理優化和記憶體優化(cocos2d-x)
1、紋理壓縮。 就像windows下的dds圖片一樣,使用紋理壓縮可以極大的減少圖片載入時間(意味著不會有圖片載入時的卡頓),記憶體消耗(以pvrtc4為例,記憶體直接減少到原來的八分之一),和遊戲渲染效能。 ios下毫無疑問是pvr了(pvrtc4) ,android下比較變態,顯示卡不同,支援的紋理壓縮格式也不相同,一般來說etc1的格式(pkm或ktx副檔名)是opengles2.0均支援的格式。 但是這個僅僅是理論上支援,永遠不要高估山寨機的效能,在某些山寨機(或者是聯想這樣的準山寨機)etc1的圖片也無法正常顯示,甚至是會崩潰。
所以android下不推薦使用紋理壓縮格式。這樣比較保險點。
2、關於紋理記憶體優化沒有太多可說的了,無非就是減少畫素位數(RGBA888-->RGB565),減少圖片大小,合理使用圖片(即使釋放資源)
3、圖片載入速度也是比較關鍵的一點。 能使用紋理壓縮固然很好,不能使用的話,有兩個解決方法,使用非同步載入(可以解決卡頓的問題),合理預載入圖片。
4、圖片體積,這個關係到最終安裝包的大小。雖然現在手遊的安裝包越來越大,但是小一些總是好事。 同樣,ios下使用pvrtc4的圖片,一些顏色過渡明顯的,使用png圖片,如果沒有半透明則使用jpg圖片。
android下不考慮使用壓縮紋理。 則顏色位數少的使用png8的圖片格式,顏色位數較多的如果非半透明使用jpg圖片,如果含有半透明使用原始png圖片(一般來說這種圖片不會很多)。 總體來說,使用png8和jpg來減少圖片體積大小。 同樣圖片體積小了也有助於提高載入速度。
5、關於webp格式。這個我之前測試過,不知道現在有沒有改進。 雖然他支援半透明,並且擁有比jpg更優的壓縮比,但是由於純cpu解壓,所以載入速度非常悲劇。暫不考慮
6、關於上文提到的png8的格式,這個是一個調色盤格式,也就是說如果顏色位數小於256的話,圖片就不會失真。這個不要用photoshop的轉換,那個演算法很挫,效果很糟糕。推薦一個線上工具和一個命令列工具進行批處理。 使用命令列工具轉換的png8絕大多數情況與原圖一直,除非半透明漸變過渡非常強的圖,這樣會有明顯的波紋。
命令列版本 pngquant, 使用方法很簡單 pngquant.exe --force --verbose --ext .png --ordered --speed=1 --quality=50-90 xxxx.png
其中--ext指定輸出字尾,直接指定.png就是覆蓋原檔案
7、關於jpg的壓縮,jpg圖片雖然很小了,但是還是可以進一步壓縮的。使用Image Optimizer工具可以使圖片進一步減少(10%~60%)
8、使用2d骨骼動畫甚至是3d動畫,可以有效減少紋理所佔的記憶體和載入消耗,雖然會增加一些cpu運算的消耗,但是手遊應該不會出現同屏多少模型的情況。 尤其是一些全屏光效,拿2d圖片幀幾乎無法處理,但是3d光效就可以輕易搞定。
------------------------------------------------------------------------------------------------------------------------------
1、2d遊戲最佔記憶體的無疑是圖片資源。
2、cocos2d-x不同平臺讀取紋理的機制不同。ios下面使用CGImage,android和windows下是直接呼叫png庫。我測試了下,使用png庫直接讀取png會比CGImage還要節約1mb左右記憶體(圖片所佔記憶體4mb)但是速度要比CGImage慢一倍。時間和空間如何取捨就看實際情況了。不過最佳的選擇似乎是pvr(即使android版本,即使不使用pvrtc4)。
3、一般來說,我們可以直接使用 w * h * bpp得到一張紋理所佔的記憶體,比如一張1024*1024格式為argb8888,那麼他所佔的記憶體就是1024*1024*4=4mb。之前看到有部落格提到jpg會開闢3倍與此的記憶體(先轉換為png,然後解析png),但是新的ios系統似乎沒有這個問題。jpg與png所消耗的記憶體幾乎相同,並且jpg解析速度更快(幾乎都是4mb解析+4mb紋理資料,而jpg解析時間是png的一半),但是這樣反而很怪異,因為jpg是沒有透明色的,一個畫素最多3位元組,而png一個畫素4位元組,jpg紋理應該佔用記憶體更小才對,後來看了下cocos2d的ios載入圖片的程式碼,它把所有紋理轉換成rgba8888格式,所以無論是jpg還是png,佔用的都是4位元組。正因cocos2d對其他紋理支援不夠好,pvr才會顯得那麼高效。
4、pvr格式可以被顯示卡所認可,而不需要開闢臨時記憶體來讀取,所以即便同為argb8888格式的圖片,pvr也會比png有效率,雖然不會節約程式穩定執行時的記憶體,但是會避免載入大量圖片時的記憶體暴漲。 並且如果是ios裝置的話,可以使用pvrtc4格式的圖片,這個格式相當於windows下的dds圖片,是可以被顯示卡直接支援的。它是有失真壓縮,一個畫素只佔4位,不過如果不是有漸變半透明色的話,一般效果可以接受,而其節約的記憶體和cpu時間非常非常顯著。
5、pvr也不是萬金油。android裝置下雖然可以使用pvr格式,但是不能使用pvrtc4,希望通過pvr像ios裝置上一樣真正減少遊戲記憶體是不太可行的。
6、pvr.ccz其實就是pvr圖片zip打包下,程式讀的時候還是先解壓出pvr資源,然後再讀取pvr。不過由於壓縮下可以極大的減小圖片體積,所以雖然多瞭解壓過程也不會有特別多的cpu消耗。
7、一張jpg圖片實際載入過程記憶體消耗,以一張1024*1024 argb8888 500k的jpg圖片為例: a.讀取圖片檔案(消耗圖片大小記憶體,500k) b、解析jpg資料(cgimage, 4mb) c、釋放500k的圖片記憶體 d、opengl紋理資料(4mb) e、釋放cgimage的4mb記憶體。 注意,這個過程不是必然的順序執行,釋放cgimage記憶體的實際是有系統決定的,會很快,但是不一定是立即執行。 所以記憶體會瞬間飆升9mb左右,然後減少5mb,穩定到4mb左右
png圖片的載入過程與此相同
pvr圖片可以節約解析圖片資料到紋理這一步的消耗。也就是說讀取pvr圖片資源(等價於解壓pvr.ccz到記憶體,如果是1024*1024 argb8888格式的話,那麼圖片大小就是4mb,ccz壓縮後圖片1mb左右)消耗4mb,將pvr圖片資料提交給顯示卡消耗4mb。然後釋放檔案資料4mb。這麼看似乎跟Png從記憶體佔用上相比也不是非常有優勢。(注意這裡說的pvr是指pvr封裝的argb8888,與pvrtc4的效能有天壤之別)
8、由於最終消耗記憶體的都是紋理資料,所以只要紋理資料格式是一定的,無論圖片是什麼格式消耗的記憶體都是一樣的。比如使用Png8圖片,體積會減少70%,但是記憶體佔用與png24/png32是等價的(讀取的時候會內部把調色盤還原成真彩色,也就是說,雖然png8是一個畫素只佔8位,但是讀取到記憶體中的時候會將調色盤顏色還原,依然需要開闢1024*1024*4位元組的空間存放紋理資料)。 當然有無透明色,cocos2d的處理還是有區別的。如果是無透明色,可以使用png24,那麼所需開闢的紋理空間就是3mb。
這裡還有一點需要說明,一般我們處理windows下的dds紋理的時候,都習慣將其按2的整次冪對其,雖然圖片內容只有900*900,但是圖片大小卻是1024*1024。那我們讀取這個圖片所消耗的記憶體就是4mb,按2的整次冪對其是有助於提高執行效率的,但是不是非常必須的。ios和android的裝置都支援非2的整次冪的紋理。所以如果是png圖片,那麼它該多大就多大。此時消耗的記憶體就只有900*900*4=3mb。
9、不要過於迷信所謂的去除alpha通道以節約記憶體。這個還要實際分析下具體結果。 我測試過(分別用cocos2d-x和鬼火3d引擎),rgba8888和rgb888格式的png圖片顯示所消耗的記憶體是一樣的。24點陣圖片雖然讀取的時候開闢的記憶體只有3mb(1024*1024*3,注意如果是用CGImage讀取的話,那這個值就是4mb),但是glTexImage2D提交給顯示卡後依然會增加4mb記憶體。可能跟顯示卡的資料對齊有關。
這裡我測試還有一個詭異的地方,如果是用pvr的npot圖片的話,rgb888要比rgba8888所消耗的記憶體要小,但是pot圖片兩者又是一樣的(png圖片兩種情況都是一樣的)。可能是powervr顯示卡有特殊處理。
10、rgb565和rgb5551的圖片所消耗的記憶體是rgba8888的一半,如果沒有透明漸變的話,視覺上也看不出什麼區別。一些大的背景圖可以優先選擇這種格式。
11、pvr圖片載入速度要比png和jpg快3~5倍(同樣1024*1024 argb8888),png消耗的時間可能是700ms左右,但是pvr只需要100ms左右。如果是pvr.ccz壓縮下,消耗的時間是200ms左右。可見pvr在載入速度上還是有非常大的優勢的。這個應該是因為png和jpg需要把圖片資料還原為rgba,但是pvr可以直接把圖片資料傳遞給顯示卡。pvrtc4的圖片是可以被powervr顯示卡直接支援的。
總結下:
1、最終決定圖片佔用記憶體的是它的畫素格式和大小,與其副檔名無關。png8 png32 jpg pvr只要其畫素格式都是argb8888,那麼最終圖片佔用的記憶體是一樣的。
2、如果不是pvrtc4的格式,那麼不要擴充套件成2的整次冪,因為圖片越小,佔用記憶體越小
3、單單去除透明通道不會減少圖片所消耗的記憶體,png和jpg圖片也無法減少圖片體積,所以不推薦rgb888的格式。替代選擇rgb565和rgb5551。
5、小心載入圖片時臨時開闢的紋理資料造成的記憶體飆高,可以考慮加入記憶體池,及時的開闢和釋放緩衝區。
6、如果是為了減少圖片體積可以選擇:1、jpg--壓縮比最高,質量較好,但是不支援半透明 2、png8--同樣圖片會比jpg略大一些,使用ImageAlpha進行轉換,視覺上幾乎看不出差別。 這兩種圖片格式都可以極大的減少圖片體積(減少70%~80%),但是無助於減少記憶體
7、如果是為了減少記憶體可以選擇:1、沒有透明色的圖片統一轉換為rgb565格式,這個時候無法使用png8了,所以png和pvr.ccz圖片大小几乎相同,pvr.ccz速度更快,所以推薦pvr.ccz的rgb565格式 2、如果透明色僅僅是進行關鍵色標註,而沒有漸變混合,那麼推薦rgb5551 (r5_a1)的pvr.ccz格式
8、可以考慮寫個打包系統,統一把資原始檔打包,而不是單個檔案用pvr.ccz進行zip壓縮,這樣可以獲得更高的效率。(比如我封裝了下暴雪的mpq打包,其讀取速度與本地檔案讀取速度相當,這樣就可以獲得最佳的讀取效率)