gkENGINE跨平台的心酸血淚史
總結了一下去年再作gkENGINE跨平台工作時，遇到的一些坑和解決方案。
開發環境選擇
IOS
IOS支持C++的方式是C++（GCC編譯器）和objC混編
IOS平台使用xcode作為“編譯器”和“調試器”
VisualStudio作為“開發IDE”
利用VMWARE虛擬機，在WIN7環境下開一個MAC虛擬機，一切和IOS真機/虛擬機相關的問題在虛擬機中搞定。
在WIN7下開一個代碼托管倉庫，VMWARE橋接網絡可以在MAC OS里pull代碼。
ANDROID
ANDROID支持C++的方式是NDK。Android2.3之后支持純原生代碼。
NDK的官方開發流是geek范兒：手寫mk文件，調用windows版的gcc編譯器直接編譯出可在arm架構上跑的二進制。然后使用gdb server進行真機調試。
可以通過vs-android方案，將手寫mk文件的步驟，變為熟悉的vs管理工程。通過MSBuild擴展出一個Android平台（對應WIN32/WIN64）編譯選項。同時配合Android-SDK和ANT，可以直接生成用於真機安裝的APK包。
參考工程
COCOS2D-X
POWERVR SDK
跨平台不得不改的幾個模塊
渲染API
l D3D是用不了的，需要使用GLES2來實現渲染器
輸入
l 輸入方式和WINDOWS是完全不同的，觸屏VS鍵鼠
l IOS和ANDROID的輸入消息驅動方式也有區別，需要分別實現
操作系統打交道的
l 線程API，Linux可以用pthread
l 各種數據類型定義， 通過DEFINE的轉
l WIN API，一部分WIN API可以用LINUX平台的函數封裝
GCC和MSVC編譯器不同的脾氣
l 模板
l 傳參行為
l 編譯器特性和關鍵字_stdcall _fastcall等等
l switch case只支持8位... 被坑慘了
UNICODE和MULTIBYTE
l NDK 7對UNICODE支持不好，最終選擇了MULTIBYTE
WINDOWS的專有庫
l ATL, MFC… gkENGINE還好都沒有選用
l 各種第三方庫，有源碼的可以嘗試編譯跨平台（rapidXML等等）
庫的封裝
ANDROID支持動態鏈接（.so）
IOS鎖死了動態鏈接，只能使用靜態鏈接(.a)
資源引用
IOS需要把文件按目錄結構打進APP包中，用一個obj系統提供的bundle路徑來作為root路徑引用文件
ANDROID的數據可以類似IOS一樣，統一打進APK包中。安裝后直接位於APK程序位置。也可以放置於SD卡中，索引SDCARD路徑的方法可能會根據機型有不同。
文件系統
IOS真機的文件系統式HFS+，該文件系統對文件名是大小寫敏感的！ 而MAC OS可以是HFS，大小寫不敏感。這是一個大坑。資源和路徑可能需要全部處理為小寫。
LINUX系統不支持“\”作為路徑分割，因此在路徑索引和源代碼中，一律要使用“/”。
渲染器
渲染器需要使用openGL ES/ES2來實現。
在WINDOWS平台上可使用POWERVR SDK提供的GLES2模擬庫來模擬，該庫是對OPENGL的封裝。COCOS2D-X也使用這種方式。使用WINDOWS模擬器的最大優勢在於， 可以脫離於移動平台，直接在WINDOWS平台下開發。在發布里程碑版本時再針對移動平台編譯，解決部分問題。提高開發和調試效率。
在ANDROID和IOS中，OPENGLES2的行為還稍顯不同。
C標准庫和C++標准庫
在移動平台上，對這兩個標准庫都支持得很好。因此如果之前的工程如果大量的使用標准庫函數和對象來開發，跨平台時可以事半功倍。
規格
移動平台的內存偏小，這一點需要十分注意。容易爆內存崩潰。
移動平台顯卡支持的硬件解碼紋理格式各異：
ETC ：所有廠商支持 | 不支持ALPHA通道
PVR ：POWERVR | ALPHA通道支持很爛
DDS : NVIDIA
AT2: 高通