在遊戲中，紋理不僅占據大量的包體，也占據了大量的內存。傳統的圖片壓縮格式（如JPEG、PNG等）雖能減少資源大小，但是不能被GPU直接識別，還是需要先加載到內存通過CPU解碼，轉換成RGB/RGBA等能被GPU識別的格式，才能傳送到GPU進行渲染。
為避免這些問題，壓縮紋理，指的是壹種針對GPU的紋理壓縮方案，使紋理能夠直接被GPU識別並進行渲染，它具有以下優點。
傳統的圖片壓縮主要目的是 存儲 和 傳輸 ，為了盡可能的高效壓縮，使用了可變的壓縮比率，因此在解壓時需要解壓更多的像素位才能讀取某個像素的位置，不適合隨機和快速讀取，也發揮不了GPU的並行處理優勢。
而壓縮紋理使用壹個固定的壓縮比率，將紋理劃分成多個像素塊，每個像素塊包含 2*2 或 4*4 個像素，然後對每個像素塊進行壓縮，被壓縮的像素信息存儲在壹個像素集合中，每個像素塊的索引位置存儲在壹個塊索引圖中。讀取時，首先將紋理坐標轉化為塊索引值，然後在像素集合中查找對應的像素塊，最後在這個像素塊中找到紋理顏色值。
因為采用了固定的壓縮比率，GPU內部可以並行處理，從而快速的解壓縮。與之相對的是，紋理的壓縮過程發生在程序運行之前，並不在意編碼速度，因此在壓縮時會遍歷所有可能性，找到和原始像素差值最小的編碼，這也是紋理壓縮耗時較久的原因。
順便說壹下，普通圖片格式中，PNG是無損壓縮，JPEG是有損壓縮。而壓縮紋理都是有損壓縮，只是在絕大部分情況下，手機上看不出來而已。
手機上使用壓縮紋理依賴於OpenGL ES的支持，OpenGL ES 2.0本身並沒有定義任何紋理壓縮格式，它僅提供 glCompressTexImage2D() 方法供應用程序上傳壓縮紋理，壓縮紋理的格式由各個GPU廠商定義和實現。
OpenGL ES 3.0提供了壓縮紋理標準，使各個平臺都可以使用同壹種壓縮紋理，但市面上的設備還需要很長時間才會全部過渡到OpenGL ES 3.0。因此，仍然需要對不同的平臺和設備使用不同的壓縮紋理格式。
手機遊戲中常用的有以下格式。
ETC1把 4*4 的像素塊壓縮成固定的64位編碼（8個字節）， 4*4 像素塊是16個像素，每個像素4字節，壹***占64個字節，所以壓縮比是 64/8=8。但是ETC1只能存儲RGB信息，不適用帶透明度的紋理，為解決這個問題，Creator在ETC1文件中額外寫入了透明度信息，即ETC1+A格式，它的壓縮比是 64/16=4。
ETC1/ETC1+A需要OpenGL ES 2.0（對應WebGL 1.0）環境，目前幾乎所有Android手機都支持ETC1，但是iOS不支持。
ETC1/ETC1+A紋理的長寬可以不相等，但要求是2的冪次方。
ETC2是ETC1的擴展，壓縮比率壹樣，但壓縮質量更高，而且支持透明通道，能完整存儲RGBA信息。
ETC2需要OpenGL ES 3.0（對應WebGL 2.0）環境，目前還有不少低端Android手機不兼容，iOS方面從 iPhone5S 開始都支持OpenGL ES 3.0。
ETC2和ETC1壹樣，長寬可以不相等，但要求是2的冪次方。
Creator中常用的是PVRTC4+A，壓縮比和ETC壹樣，iOS全系列支持，但是Android不支持。另外PVR要求紋理長寬相等（正方形）且是2的冪次方，例如 1280*720 的PNG圖片，轉換後變成 2048*2048 ，這壹點會大大增加內存消耗。在實測中還發現轉換後的圖片質量不如ETC1，存在模糊、毛邊現象，對畫面要求高的遊戲不適合。
壓縮紋理的使用非常簡單，根據構建平臺添加需要的格式即可，具體參見Creator官方文檔，本文不再重復了。
Creator編輯器還提供了轉換壓縮紋理的選項，根據轉換速度分為Fast、Slow等好幾檔，速度越慢則畫面質量越好。但不管選哪個，只影響顯示效果和轉換時長，顯存占用都是壹樣的。壹般情況下，顯存占用就是壓縮紋理的文件大小，例如文件大小是1.5M，則它占用的顯存也是1.5M。
在設置壓縮紋理格式時，目前Creator 2.x版本還需手動壹個壹個設置。如果想壹次性設置所有或部分資源，自己寫個腳本遍歷修改對應的 .meta 文件也比較方便，這裏是壹個我寫好的腳本 壹鍵自動化設置壓縮紋理格式
在實際項目中的測試結果是，單圖、自動圖集、TexturePack合圖加起來超過兩千張圖片的Creator工程，使用PNG時打出來的apk包大小近500M，內存占用1.3G。采用壓縮紋理後，包體大小降到150M，內存占用降到600M。