總結了一下去年再作gkengine跨平台工作時，遇到的一些坑和解決方案。
ios支援c++的方式是c++（gcc編譯器）和objc混編
ios平台使用xcode作為「編譯器」和「偵錯程式」
visualstudio作為「開發ide」
利用vmware虛擬機器，在win7環境下開乙個mac虛擬機器，一切和ios真機/虛擬機器相關的問題在虛擬機器中搞定。
在win7下開乙個**託管倉庫，vmware橋接網路可以在mac os裡pull**。
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
l d3d是用不了的，需要使用gles2來實現渲染器
l 輸入方式和windows是完全不同的，觸屏vs鍵鼠
l ios和android的輸入訊息驅動方式也有區別，需要分別實現
l 執行緒api，linux可以用pthread
l 各種資料型別定義， 通過define的轉
l win api，一部分win api可以用linux平台的函式封裝
l 模板
l 傳參行為
l 編譯器特性和關鍵字_stdcall _fastcall等等
l switch case只支援8位... 被坑慘了
l ndk 7對unicode支援不好，最終選擇了multibyte
l atl, mfc… gkengine還好都沒有選用
l 各種第三方庫，有原始碼的可以嘗試編譯跨平台（rapidxml等等）
android支援動態鏈結（.so）
ios鎖死了動態鏈結，只能使用靜態鏈結(.a)
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的行為還稍顯不同。
在移動平台上，對這兩個標準庫都支援得很好。因此如果之前的工程如果大量的使用標準庫函式和物件來開發，跨平台時可以事半功倍。
移動平台的記憶體偏小，這一點需要十分注意。容易爆記憶體崩潰。
移動平台顯示卡支援的硬體解碼紋理格式各異：
etc ：所有廠商支援 | 不支援alpha通道
pvr ：powervr | alpha通道支援很爛
dds : nvidia
at2: 高通
跨平台路徑問題
在windows下的路徑分隔符和linux下的路徑分隔符是不一樣的，當直接使用絕對路徑時，跨平台會暴出 no such file or diretory 的異常。比如說要在temp目錄下建立乙個test.txt檔案，在windows下應該這麼寫 file file1 new file c tmp t...
跨平台路徑問題
在windows下的路徑分隔符和linux下的路徑分隔符是不一樣的，當直接使用絕對路徑時，跨平台會暴出 no such file or diretory 的異常。比如說要在temp目錄下建立乙個test.txt檔案，在windows下應該這麼寫 file file1 new file c tmp t...
Erlang程式的跨平台問題
用erlang寫出的程式，如果使用依賴某一作業系統的專有技術，會在其他系統上跑不起來。最近，學用mochiweb過程中，在windows的cygwin中遇到了這個問題。開啟瀏覽器，http localhost 8000 出現網頁，程式執行正常。但是，由於mochiweb是在linux上開發的，使用了...