前段時間寫了個J2ME的RPG遊戲，當然，裏面總少不了一張大的地圖，於是，在J2ME中該如何處理這張大地圖成了一個頭痛的問題之一，後來在網上找了許多的方法，可是最終也沒有一種比較有效的方法。此處有一篇文章 （ http://www.51cto.com/art/200703/43134.htm）可以有效地防止用大地圖時掉幀 ，可惜針對的是MIDP1.0的，而且在裏面對每個磚還都要自己用g.drawImage方法畫出，而在MIDP2.0上磚是直接貼在TiledLayer上的然後一次性畫出，所以對於MIDP2.0來說這種方法就不是很適合的，除非你願意捨棄MIDP2.0簡便的方法而使用MIDP1.0。
當然，對於用於RPG的大地圖，我們總不能一次性地把整個都畫於屏幕上，這樣會使內存吃不消，即使內存受得住，估計玩的時候也會卡死，玩遊戲本來就是娛樂，這樣子那還有心情玩。
到目前爲止，我仍沒有找到一種特別有效的方法來處理大地圖，但可以從一些方面對遊戲先進一些優化處理，使其跟小地圖運行效率差別不太大。
我的做法：
1、切分大地圖爲小地圖，在各小地圖進行切換，每次只加載需要的小地圖
2、如果有很多層（TiledLayer），而且每層都有一張地圖（int數組），則不凡把所有int數組組成合成一個int數組（然後針對每張地圖再用%，/把int數組的值給拆分出來）。
3、在需要更新畫面的時候只更新屏幕大小,試下用repaint(int,int,int,int)和flushGrapihcs(int,int,int,int)而不是repaint()和flushGraphics()。
PS：事實上，對於第二點及第三點能否提高遊戲的運行效率到目前爲止我也不能完全確定，第二點中每張圖一個int數組只是使遊戲的大小變大，據我查的一些資料，遊戲的大小跟遊戲的運行速度沒有什麼大的關聯的（除非真機有做出嚴格限制），而用%，/拆分大地圖無疑也要做很多額外的運算，不過無可否認，每張圖一個int數組總會使代碼量增加，這樣運行時代碼所佔內存總會比較大（除非從外面讀取地圖而不是把地圖數據寫進代碼）這樣總會使運行速度下降。而第三點只更新屏幕大小範圍，有些人提倡這麼做，有些人則反對，反對原因是使用那兩個方法更新屏幕大小範圍增加了程序運算量，反而影響遊戲運行速度。不管怎樣，我嘗試了一次畫整一張大地圖以及用上面三種方法改進，而前者的運行速度跟後面真的沒法比。
實際上，只要使用第一種方法就可以使整個遊戲的運行速度提高好幾倍甚至好幾十倍。
如果你還有什麼好的改進方法，請聯繫我，謝謝。