Ⅰ 如何漢化軟體app
所謂的游戲漢化軟體遠遠沒有我們想像的那麼簡單，它不僅能夠幫助我們進行游戲的漢化，而且它還具有很多相互之間的交互功能，而且
游戲漢化軟體
所具有的框架，是其他軟體中都不能夠具備的，在我們使用漢化軟體得時候，我們不僅要保證質量，而且也要提高漢化的速度。
一、名詞解釋：
文件夾、目錄：現在的Mac和Windows都把用來分類存放文件的容器叫做文件夾，但在iPhone，無法稱其為文件夾，只能叫做繼續沿用Linux、Unix系統的說法叫做目錄了，特此解釋，我把在Mac或者Windows下的操作稱作文件夾，在iPhone或者其安裝程序壓縮包內的操作稱作目錄，以免大家對於兩種說法感到混亂。
二、拆包ipa
在網上下載的iOS游戲都是後綴為ipa的文件，要想漢化，第一步就是把這個ipa文件給拆包。拆包方法很簡單，其實這個ipa文件就是個zip包，把後綴ipa改成zip，然後用winrar 或者 7z打開就可以解壓拆包了。
三、尋找資源
拆包完畢之後就是在拆開的文件裡面尋找游戲的相關資源：圖片、文本和字型檔(漢化過程一般不會去修改音頻資源，視頻的話遇到有字幕的就添加中文字幕)。
四、那麼該如何尋找呢?
首先，iOS游戲的圖片資源一般就是png格式和jpg格式，拆包後一般能在拆包出來的文件裡面可以找到很多png和jpg格式的圖片。直接用photoshop打開修改即可。不過應用
游戲漢化軟體
有時候打開的png圖片一片空白，因為這不是標準的png格式圖片，需要用工具轉換一下。
1.可以使用fixpngWindows來轉換，使用方法：把要轉換的原始png放在png文件夾，然後執行iPhoneFixPng.exe，點擊轉換按鈕，等轉換過程結束，會彈出提示，轉換好的文件在fixed文件夾。
2.可以使用ifunboxs 或者 itools直接在安裝好的游戲裡面進行導出。註：在ifunboxs裡面直接把png圖片拖出來即可，而itools需要在png圖片上右鍵，然後選擇「轉換並導出」。
說明：轉換後的png圖片修改後直接可以使用，無需再轉回非標准格式的png圖片。
另外，PVR格式也是iOS游戲經常使用的一種圖片格式。對於PVR圖片可以使用texturepacker轉換成png圖片。
用PVR Viewer可以打開PVR圖片文件，查看圖片然後保存成png圖片。
說明：PVR轉換成png圖片可也可直接使用，不用轉回PVR文件，但注意文件名要一致，如aaa.pvr-->aaa.png。
其次，文本資源大都存放在.strings和.plist後綴的文件裡面，如Localizable.strings，在軟體的安裝目錄下一般會有名稱為*.lproj的文件夾，文本資源一般會存放在裡面。那如何編輯修正這種格式的文本呢?用記事本肯定是不行的，因為它其實是一種二進制格式的xml文件，我們可以使用plist Editor for windows來編輯。注意：編輯的時候修改string欄位即可，請勿修改key欄位。
Ⅱ 紋理壓縮簡介 DXT PVR ETC
參考
為什麼需要紋理壓縮
移動端紋理壓縮格式
干貨：Unity游戲開發圖片紋理壓縮方案
Creator使用壓縮紋理
常用紋理和紋理壓縮格式
移動設備的紋理壓縮方案
各種移動GPU壓縮紋理的使用方法
在軟體開發，特別是三維應用中，紋理隨處可見，但受限於網路環境和硬體能力，紋理也是一大瓶頸。而且在一般的三維應用中，紋理所佔大小基本都會在1/2以上，模型中往往超過2/3。或許你會說，紋理不就是一張圖嗎，有那麼重要嗎？如下兩張對比圖，可能你會認為前者逼格高，但對於正常人而言，後者顯然要好很多。正是有了紋理，如同在骨架上賦予了皮膚，讓我們的應用更加的逼真，貼近現實。
而你能想像到嗎？如上的模型一共有三張紋理，其中之一效果如下：
紋理的拼接是紋理壓縮的開始，採用不同的壓縮方式對紋理最終的大小影響也是顯著的。比如上面的這張紋理在不同壓縮格式下的大小差別也是非常顯著的（原始文件為tga格式，通過Photoshop轉換為其他格式，默認選項）：
不同於png、jgp這種硬碟壓縮方式而言，DXT,ETC等紋理壓縮方式可以在游戲運行中無需CPU解壓就被GPU直接采樣，可以極大的減少內存和帶寬的佔用，提升運行效率，對移動游戲而言更是如此。
1.DXT
DXT是一種有損紋理壓縮演算法，微軟的Direct中支持，DXT的格式包括DXT1~DXT5，其中DXT1和DXT5較為多見，後面會做詳細討論。可以說DXT是目前應用最廣泛的紋理壓縮格式，可以認為所有的PC端顯卡都支持DXT壓縮，維基網路記錄，該專利有效期到2017年10月2號。
DXT演算法非常容易理解，而且整體看上去效果不錯，但如果對局部特寫，會發現在細節上會有很多丟失，這也是演算法本身導致的，畢竟每個塊只有兩個顏色，而其他顏色都是在這兩個顏色區間的差值，如果當前區域內還有其他顯著顏色則必然會有丟失。
另外一個問題就是DXT3和DXT5之間的對比，相比DXT1不支持透明度（但支持是否透明），DXT5要大一倍（多了64bit），和之前顏色保存方案一樣對透明度也保存了兩個16位的顏色和對應的調色板，對RGBA的效果也得到了保證，但DXT3思路不一樣，它是對每一個像素保存了4bit的透明度，同樣也是多了64bit，但此時畢竟只有16個透明度選項，相比DXT5，在壓縮率上相當，但對透明色的處理不夠細膩，因此在實用性上並不推薦DXT3。
盡管DXT在細節上有明顯硬傷，在總體效果不錯，而且確實是一種強大的壓縮方式，所以在多數紋理壓縮選擇中都是最佳方案，幾乎可以認為是PC下的標准壓縮格式。
2.PVR&ETC
也許是出於專利和商業角度，也許確實DXT在移動端確實無法滿足要求，DXT並沒有在移動端得到很大的支持，相反，在iOS設備中支持的是PVR壓縮，在Android中支持的是ETC壓縮。
DXT在細節上缺陷明顯，最重要的原因是當把紋理分為4*4像素的區域塊後，每個塊之間都是獨立的，盡管這極大的簡化了壓縮演算法，但卻丟失了相鄰塊之間這種普遍的相似性。這是演算法本身導致的，而PVR則會考慮該區域塊對應的右側，下側和右下側的三個區域塊的關聯性。
從現實的角度來看，受制於專利和硬體廠商，我們並沒太多選擇的餘地，Android下就要用ETC，iOS下只能PVR，而在PC上不用DXT估計就要被嘲諷了。但這也是一個很棘手的問題，比如在WebGL下，特別是Android下差異化很大，是否支持紋理壓縮，甚至在同一個設備不同的瀏覽器，因為驅動的不一致，可能系統自帶的會支持ETC壓縮，而微信等QQ瀏覽器下並不支持。而且華為的手機貌似在瀏覽器級別下都不支持ETC（硬體支持，還是驅動的問題）。而如果在移動設備上不用壓縮，顯存是有限的，除非你在數據量上做出犧牲，怎麼解決都很矛盾，相比而言，iOS下則要舒服很多。
Unity官網對每個平台默認的紋理壓縮格式以及使用建議給出了 詳細描述 ，需要注意的是：在不同移動GPU平台下選擇GPU支持的壓縮紋理，就可以在不需要CPU解壓的情況下直接被GPU采樣，節省CPU內存和帶寬，也可以節省存儲的體積。 如果目標平台不支持設置的壓縮格式，紋理將解壓為RGBA32或者RGB24，浪費CPU時間和內存 。
參考 幾種主流貼圖壓縮演算法的實現原理
從IOS9(A8架構)Apple 手機開始支持ASTC壓縮格式 ，如果考慮放棄Apple 6代之前的手機兼容問題了，可以直接使用了。相對於PVRTC2/4而言，ASTC(4X4)的壓縮比會增加到0.25，不過顯示效果也會好很多，而且不需要把圖片設置為方形。
Using ASTC Texture Compression for Game Assets 說明的比較詳細，也給出了一些使用上的建議，即針對不同貼圖類型給出不同的壓縮方案。
1. laya問答 H5游戲能使用壓縮紋理（ETC，PVR等）嗎？
Q:H5游戲能使用壓縮紋理（ETC，PVR等）嗎？
A:部分瀏覽器會不支持（比如safari）
Q:那laya裡面能根據不同瀏覽器（或不同平台）使用不同壓縮格式的紋理嗎？
A:你自己是可以獲取到當前是哪個瀏覽器的，自行處理即可
2. LAYA Runtme目前支持 ETC/DXT或者PVR這類格式嗎?在文檔中沒有找到這類的說明
LayaAir目前暫時還不支持ETC/DXT/PVR這類格式！關注layaAir的版本引擎更新日誌即可，支持了我們會及時告知！
3. Egret 內存分析-RES載入資源後存在雙份內存無法釋放的問題
支持pvr、etc已經在計劃中。
Ⅲ 一個操作讓游戲內存立減50+%-CocosCreator性能優化之壓縮紋理
在游戲中，紋理不僅占據大量的包體，也占據了大量的內存。傳統的圖片壓縮格式（如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。