首先把所有有關屏幕的參數都定義成private final int型變量。這裡之所以加上final 修飾符，是因為不希望變量附初值後，它們的值會發生變化；之所以不加static修飾符，是因為要在其函數中初始化變量，而不是在定義時就初始化好了。先用getHeight()和getWidth()函數取得當前手機屏幕的高度和寬度，再計算出需要的偏移量addX和addY，然後加到各屏幕參數上，這樣游戲內容就會居中顯示了。圖2與圖3是效果比較圖。
圖2：矯正前
圖3：矯正後
還有一點需要注意，用getHeight()取得的並不是手機屏幕的真實高度，而是手機屏幕的高度減去Command標簽高度，因為屏幕需要留出地方顯示Command標簽。
合理使用內存
本來使用Java編程是不需要關心內存使用的，因為Java有它引以為豪的垃圾處理機制。但到了J2ME裡，情況發生了變化，因為手機的內存只有屈指可數的幾百K，再也不能像在J2SE裡那樣大手大腳了。否則就會發現，即使程序沒有任何語法和邏輯錯誤，也不能在模擬器中運行。下面給出合理使用內存的幾個建議：
1．盡可能使用本地變量代替類成員，減少對象的創建，最好能重新利用對象；
2．不要試圖在初始化的時候把所有Form或者Canvas對象都讀入內存中，而應該在需要的時候再創建，雖然這樣在顯示上會有一些延遲，但是總比程序不能運行或者內存溢出要好；
3．一旦對象不需要使用就及時將其置為null，以便能夠被垃圾處理器回收，適當的時候調用System.gc()語句提示虛擬機調用垃圾處理器；
4．必須記住Java的內存管理是有向邊機制，所以對於不使用的對象，千萬不要讓正在使用的對象指向它，以免內存得不到回收；
5．盡量使圖片占有的字節數小一點，可以使用Fireworks在保證圖片質量同時減小圖片的大小；
即使做到上面幾點，也不能保證程序不會發生內存洩漏，因為手機內存畢竟那麼少。所以我提出最後一個建議，就是先完成游戲的主體部分，使它能夠正常運行並沒有內存洩漏，再慢慢擴展游戲，給它加上封面和其它功能。一旦發現內存不足，再去掉部分功能。
使游戲更有魅力
編寫游戲當然希望它能吸引人，我覺得下面幾個地方值得大家注意：
1．注意控制游戲的節奏
原來我在削除方塊的時候，什麼都不做就直接刪除，然後開始一個新的循環，讓等待的方塊往下掉。在實際運行的時候感覺效果不是很好，因為削得越快，上面的方塊也掉得越快，讓游戲者有一種措手不及的感覺。後來我在刪除方塊的時候，用空循環停頓了幾秒鐘，這樣就給了游戲者一個反應時間，感覺就好些了，而且如果連削的話，反應時間會更長，這樣使得游戲者在玩游戲時有一種輕松的感覺。再後來，我將空循環改成對屏幕上的方塊遍歷三次，讓被刪的方塊閃爍，使得游戲者能夠看清楚被刪除的方塊，欣賞到自己的成果，這樣又增加了游戲的吸引力。
2．利用圖片實現豐富多彩的表達效果
在J2ME中如果不能控制文字的大小和字體，那麼這將使游戲的效果大打折扣。不過，可以通過把各種特殊的文字做成圖片的方法來解決這個問題。有些地方我們也可以用圖片來取代文字，使得游戲更加生動，比如在等級欄用五角星來表示游戲的難度。使用圖片還有一個好處就是增加游戲的通用性，使得游戲在不同手機上的顯示基本相同。另外，如果出現字體顏色在模擬器中顯示正常，而在手機上顯示不正常的情況，也可以用這種方式解決。
3．讓游戲能夠自動調整難度
我使用如下函數，使得游戲難度不斷加大。
private void giveLevel()
{if(level<=10)
{ levelSleep=600-(level - 1) * 50;
if(levelSleep<200)levelSleep=200;
levelDelTask=200+(level-1)*100;
if(levelDelTask>1000)levelDelTask=1000;//畫等級--五角星
paintStar();
}
else{gameWin();}
}
level表示游戲等級，levelSleep表示方塊下落一個的等待時間，levelDelTask表示過一關需要刪除的方塊數，也可以理解為過一關需要完成的任務。上面的計算公式可以保證游戲會越來越難，增加了游戲的吸引力。
