畢業(yè)設(shè)計---基于j2me的java游戲

1、<p><b>　　摘 要</b></p><p>　　Java良好的跨平臺特性在移動平臺的開發(fā)中顯示出了巨大的威力。Java語言面向?qū)ο蟮膬?yōu)勢也使得開發(fā)游戲變得非常容易。</p><p>　　隨著手機的日益普及、Java功能在移動設(shè)備上的實現(xiàn)，Java應(yīng)用程序產(chǎn)生的手機增值服務(wù)逐漸體現(xiàn)出其影響力，對豐富人們的生活內(nèi)容、提供快捷的資訊起著不可忽視的作用。本

2、論文著眼于J2ME技術(shù)的應(yīng)用，開發(fā)一款可商用的手機游戲程序——坦克大戰(zhàn)。本程序的界面和運作方式繼承于日本任天堂公司在20世紀(jì)80年代開發(fā)的Battle City游戲，將老少皆宜的經(jīng)典作品移植到手機上來，為更流行的硬件平臺提供應(yīng)用軟件。</p><p>　　本論文介紹了任天堂紅白機的軟硬件特性、J2ME的相關(guān)技術(shù)及本程序的結(jié)構(gòu)分析和具體功能的實現(xiàn)。</p><p>　　[關(guān)鍵字]：J2ME，

3、手機游戲，Java，坦克大戰(zhàn)</p><p><b>　　ABSTRACT</b></p><p>　　Java has an advantage of running in different platforms that shows its power in developing for the mobile device. The advantage of ob

4、ject-oriented of Java makes development of games easily.</p><p>　　When cell phone is getting ever more popular nowadays, with the implementation of Java technology on mobile equipment, increment of capital o

5、n communication service exhibits its force on people’s everyday life, providing them ever fast information just in hand. This dissertation focuses on implementation of J2ME technology and has developed a commercial game

6、suite run on mobile phones—Tank. This application inherits many characters of the old fashioned game Battle City which developed by Nintend</p><p>　　This dissertation introduces the characteristic of Nintend

7、o FC machine and its software, J2ME and its relative technology as well as this program’s structure and analysis of implementation in details. </p><p>　　[Keywords]: J2ME, mobile game, Java, tank, Battle City

8、.</p><p><b>　　引　　言</b></p><p>　　自從Java問世以來,Sun公司已經(jīng)成功的將Java平臺技術(shù)推廣到臺式計算機與服務(wù)器。隨著移動電話及PDA的日益普及,Sun更致力于將Java技術(shù)向移動設(shè)備這個方向發(fā)展.</p><p>　　Sun 在1999年6月時推出了 Java 2袖珍版 (J2ME)來滿足消費電子和嵌

9、入設(shè)備的需要。J2ME是為了那些使用有限的能源、有限的網(wǎng)絡(luò)連接 (常常是無線連接)以及有限圖形用戶界面能力的設(shè)備開發(fā)的。它最初的目標(biāo)是 16位或 32位處理器，16 MHz時鐘頻率，512K或更少內(nèi)存的設(shè)備。</p><p>　　近幾年，由于微處理器性能的大幅提升，加上無線通訊技術(shù)的突破，手持式移動設(shè)備開始受到大眾的青睞。短短幾年內(nèi)，手機已經(jīng)升級了幾代產(chǎn)品，普及率逐年攀升，生產(chǎn)效率不斷上升，產(chǎn)品價格比個人電腦的摩

10、爾定律有更驚人的下調(diào)，以至手機是大多是城市居民不可缺少的一件隨身設(shè)備。繼短信、彩信等服務(wù)之后，中國移動提供基于Java的百寶箱業(yè)務(wù)，應(yīng)用產(chǎn)品遍及商務(wù)應(yīng)用、信息獲取、英漢互譯、游戲娛樂等多媒體領(lǐng)域。根據(jù)官方公布的統(tǒng)計數(shù)據(jù)，我國移動電話用戶已突破3億。依托這樣的市場，一旦無線Java應(yīng)用大規(guī)模開展起來，將會創(chuàng)造出比短信業(yè)務(wù)更為驚人的利潤。Java語言原先的開發(fā)目的與市場的需求不謀而合，并且也已經(jīng)成為手機應(yīng)用程序開發(fā)的標(biāo)準(zhǔn)，國際大公司如Nok

11、ia、Motorola及Siemens等所設(shè)計的手機內(nèi)都加入Java程序的支持，可見在不久的將來，Java將會成為移動設(shè)備上最熱門的語言。</p><p>　　手機中將Java語言引入，作為一種通用的開發(fā)標(biāo)準(zhǔn)，并將向市場推廣普及僅僅短短幾年，J2ME仍是一種新型的技術(shù)，中文資料除臺灣出版過相關(guān)書籍外，國內(nèi)相關(guān)介紹資源很有限，國內(nèi)J2ME開發(fā)商也屈指可數(shù)，名聲較響的Digital-Red公司也僅成立于1999年。本

12、文可算是對新技術(shù)的一些嘗試，代表對無線平臺應(yīng)用程序推廣的一些努力。</p><p><b>　　本論文中：</b></p><p>　　第一章 介紹游戲機軟硬件歷史、Java語言、J2ME及其相關(guān)技術(shù)；</p><p>　　第二章 介紹了開發(fā)工具和相關(guān)軟硬件環(huán)境的背景；</p><p>　　第三章 分析該作品設(shè)計的思想和

13、流程，介紹總體結(jié)構(gòu)；</p><p>　　第四章 并詳細(xì)闡述有關(guān)重點實現(xiàn)細(xì)節(jié)；</p><p>　　第五章 提及了開發(fā)過程、心得體會、經(jīng)驗和感想。</p><p><b>　　目 錄</b></p><p>　　摘 要- I -</p><p>　　Abstract - I -&l

14、t;/p><p>　　引　　言- 2 -</p><p>　　第一章　 緒 論- 3 -</p><p>　　1.1 手機軟件現(xiàn)狀- 3 -</p><p>　　1.2 游戲業(yè)務(wù)及J2ME概況- 3 -</p><p>　　1.3 任天堂(Nintendo)的8位FC機器和Battle City背景介紹-

15、 5 -</p><p>　　1.4 本章小結(jié)- 5 -</p><p>　　第二章 開發(fā)環(huán)境及相關(guān)技術(shù)的介紹- 6 -</p><p>　　2.1 開發(fā)環(huán)境- 6 -</p><p>　　2.2 Java語言的特點- 6 -</p><p>　　2.3 關(guān)于JBuilder9- 6 -</

16、p><p>　　2.4 關(guān)于Wireless Tool Kit- 7 -</p><p>　　2.5 Java Appication Manager- 7 -</p><p>　　2.6 本章小結(jié)- 7 -</p><p>　　第三章 程序結(jié)構(gòu)、思想和相關(guān)技術(shù)- 8 -</p><p>　　3.1 本程

17、序需解決的有關(guān)技術(shù)問題- 8 -</p><p>　　3.2 程序流程- 9 -</p><p>　　3.3 繪圖與MIDP2.0新增的GameCanvas包- 11 -</p><p>　　3.3.1 提供低級繪制的Canvas類- 11 -</p><p>　　3.3.2 Graphics類- 11 -</p>

18、;<p>　　3.3.3 PNG格式- 11 -</p><p>　　3.3.4 Game包中的新功能- 12 -</p><p>　　3.3.5 有關(guān)繪圖的一些技術(shù)- 13 -</p><p>　　3.4 坦克的控制和敵方的智能運行- 13 -</p><p>　　3.5 子彈的運行和控制- 14 -<

19、;/p><p>　　3.6 RMS數(shù)據(jù)庫系統(tǒng)- 15 -</p><p>　　3.7 內(nèi)存使用的最佳化- 16 -</p><p>　　3.8 混淆器(Obfuscator)的使用- 17 -</p><p>　　3.9 模擬器的相關(guān)調(diào)試- 17 -</p><p>　　3.10 本章小結(jié)- 18 -&

20、lt;/p><p>　　第四章 程序分析和具體實現(xiàn)- 19 -</p><p>　　4.1 游戲進(jìn)入前的選擇- 19 -</p><p>　　4.2 主游戲邏輯及其涉及到的若干類- 20 -</p><p>　　4.3 坦克的共同行為- 22 -</p><p>　　4.4 玩家坦克的功能屬性- 23 -

21、</p><p>　　4.5 敵人坦克的功能屬性- 23 -</p><p>　　4.6 子彈的運行和控制- 25 -</p><p>　　4.7 記分系統(tǒng)- 26 -</p><p>　　4.8 本章小結(jié)- 28 -</p><p>　　第五章 總 結(jié)- 29 -</p>&

22、lt;p>　　5.1 本程序的總結(jié)和展望- 29 -</p><p>　　5.2 經(jīng)驗和感想- 29 -</p><p>　　致 謝- 31 -</p><p>　　參考文獻(xiàn)- 32 -</p><p><b>　　第一章　　緒 論</b></p><p>　　1.1

23、手機軟件現(xiàn)狀</p><p>　　在信息社會中，手機及其他無線設(shè)備越來越多的走進(jìn)普通百姓的工作和生活，隨著信息網(wǎng)絡(luò)化的不斷進(jìn)展，手機及其他無線設(shè)備上網(wǎng)絡(luò)勢在必行。但是傳統(tǒng)手機存在以下弊端：</p><p>　　1. 傳統(tǒng)手機出廠時均由硬件廠商固化程序，程序不能增加、刪除，有了錯誤也不能更新、修改，若要增加新功能必須另換一部手機。</p><p>　　2. 傳統(tǒng)手

24、機訪問互聯(lián)網(wǎng)是通過WAP(Wireless Application Protocal)，所有網(wǎng)絡(luò)資源必須接通網(wǎng)絡(luò)才能在線訪問，非常耗時、費用亦很高。</p><p>　　而Java技術(shù)在無線應(yīng)用方面的優(yōu)勢非常明顯：</p><p>　　1. 應(yīng)用程序可按需下載，而不是購買由硬件商提供的套件，可升級空間大。</p><p>　　2. Java技術(shù)提供了一個類庫，它

25、使的應(yīng)用開發(fā)商可以創(chuàng)建更為直覺、豐富的用戶界面(GUI)；</p><p>　　3. Java技術(shù)使網(wǎng)絡(luò)帶寬的應(yīng)用更為有效，因為應(yīng)用程序可以下載到器件上，并在本地運行，僅僅是在連接到服務(wù)器時才會占用網(wǎng)絡(luò)帶寬。</p><p>　　基于以上分析，Java手機將是未來手機的發(fā)展方向，是業(yè)界的熱點。</p><p>　　1.2 游戲業(yè)務(wù)及J2ME概況</p>

26、<p>　　雖然 Java 已經(jīng)被用到許多企業(yè)級軟體上，可是其實骨子里面還是非常適合用在嵌入式系統(tǒng)之中。Java平臺演進(jìn)到Java2后，Java平臺分別針對不同領(lǐng)域的需求被分成四個版本，亦即J2EE、J2SE、J2ME以及JavaCard(其結(jié)構(gòu)示意圖見圖1-1)。其中J2ME定位在消費性電子產(chǎn)品的應(yīng)用上。這個版本針對資源有限的電子消費產(chǎn)品的需求精簡核心類庫，并提供了模塊化的架構(gòu)讓不同類型產(chǎn)品能夠隨時增加支持的能力。這個版

27、本的應(yīng)用層面相當(dāng)廣泛，會是未來Java平臺發(fā)展的重點項目。J2ME 在設(shè)計其規(guī)格的時候，遵循著“對各種不同的裝置而造出一個單一的開發(fā)系統(tǒng)是沒有意義的事”這個基本原則。于是 J2ME 先將所有的嵌入式裝置大體上區(qū)分為兩種：一種是運算功能有限、電力供應(yīng)也有限的嵌入式裝置(比方說PDA 、手機)；另外一種則是運算能力相對較佳、在電力供應(yīng)上相對比較充足的嵌入式裝置 (比方說冷氣機、電冰箱、電視機上盒 (set-top box))。因為這兩種型態(tài)

28、的嵌入式裝置，所以Java 引入了一個叫做Configuration 的概念，把上述運算功能有限、電力有限的嵌入式裝置定義在Connected L</p><p>　　縱觀IT產(chǎn)業(yè)的歷史，就像軍事的發(fā)展時常推動計算機的演化一樣，計算機游戲已經(jīng)成為技術(shù)創(chuàng)新背后的動力之一。計算機游戲者渴望更加強大的硬件計算能力；渴望不受不同的軟件的限制——無論是將圖形強制在人工智能（AI）上 還是網(wǎng)絡(luò)安全性。游戲開發(fā)者和玩家常常是前

29、沿計算機技術(shù)的最早的采用者。由于他們的創(chuàng)新天性，游戲不再是由大型采購公司控制的技術(shù)產(chǎn)品——游戲領(lǐng)域總是有充足的空間給那些在這方面有天分的單個創(chuàng)新者。</p><p>　　手機游戲的盈利主要是由于它們的涉及面很廣。手機已經(jīng)與現(xiàn)代生活方式緊緊地結(jié)合在一起。他們是最普遍攜帶的個人用品中僅次于鑰匙和錢包的東西。傳統(tǒng)的臺式機游戲?qū)⒛繕?biāo)鎖定在低級趣味的人和青少年身上，而手機游戲則每個人都可以訪問的到——隨時，隨地。盡管每個手

30、機游戲都不貴，但是巨大的使用量（如：每人每星期一個新游戲）將使得這個市場商機無限。但是，對于開發(fā)者來說，將控制臺游戲遷移到手機游戲工程很大。因為他們所面向的對象、生活方式和分布式模型都有著極大的區(qū)別。</p><p>　　一個成功的手機游戲大多具有以下特征： </p><p>　　·易于學(xué)習(xí): 既然手機游戲面向的是普通消費者而不是計算機專家，那么他們不可能深入的學(xué)習(xí)游戲技巧。消費

31、者不會花幾個小時去研究一個3元的手動操作的游戲。保持游戲的簡單是最基本的要求。 </p><p>　　·可中斷性: 多任務(wù)處理是手機生活方式的基本特征。手機用戶常常在任務(wù)（如等一個電子郵件或者等車）之間有一小段時間。而游戲、日歷管理、通訊和工作數(shù)據(jù)訪問使用的是同一個設(shè)備。所以一個好的手機游戲應(yīng)該提供短時間的娛樂功能，并且允許用戶在游戲和工作模式之間順利切換。 </p><p>　

32、　·基于訂閱：手機游戲的盈利成功取決于他們巨大的使用量。一開始開發(fā)和設(shè)計每個游戲都是昂貴的。如果一個手機游戲開發(fā)者要贏利的話，重要的是：同一個游戲引擎，多個標(biāo)題，基本的故事情節(jié)類似?；谟嗛喌挠螒蚴遣粩喈a(chǎn)生收入的最好方法。 </p><p>　　·豐富的社會交互: 不管一個游戲設(shè)計得多好，只要玩家找到了它的根本模式或者玩完了所有的游戲路徑很快就會厭煩這個游戲。對于一個基于訂閱的游戲，重要的是與

33、別的玩家合作以增強所玩游戲的智力和隨機性。在今天紛繁復(fù)雜的多玩家游戲中具有豐富社會交互的游戲證明是成功的。 </p><p>　　·利用手機技術(shù)的優(yōu)點： 巨額的手機技術(shù)研發(fā)費用都花在提高設(shè)備和網(wǎng)絡(luò)的可用性和可靠性上面。因此，手機設(shè)備硬件和網(wǎng)絡(luò)協(xié)議與桌面/控制臺世界（如全球定位系統(tǒng)(GPS)擴展、條形碼掃描儀、和短消息服務(wù)(SMS)/多媒體信息服務(wù)(MMS)通訊）有著非常大的差別。好的手機游戲應(yīng)該利用那些

34、更新的設(shè)備特征和網(wǎng)絡(luò)基礎(chǔ)設(shè)備的優(yōu)點。 </p><p>　　·無違法內(nèi)容：既然所有年齡/性別的人群都玩手機游戲并且常常在公共/工作場合，就應(yīng)該避免明顯的暴力或者色情內(nèi)容。</p><p>　　1.3 任天堂(Nintendo)的8位FC機器和Battle City背景介紹</p><p>　　FC(Family Computer)主機在歐美又稱Ninte

35、ndo Entertainment System（可譯作任天堂娛樂平臺即NES）。FC主機在游戲業(yè)界造成的巨大沖擊眾所周知，這款主機在當(dāng)時事實上幾乎占領(lǐng)了世界各地多個國家的整個游戲市場，并使得逐漸沒落的北美游戲市場再度復(fù)蘇。這款主機的性能比當(dāng)時的多數(shù)主機都要強大，而價格上卻便宜得多。主機所采用得處理器為CMOS 6502，一款已經(jīng)淘汰的70年代中期產(chǎn)品。由于其價格便宜且極易使用，經(jīng)過任天堂的改造后又煥發(fā)了全新活力。6502 芯片cpu

36、主頻為8 bit，12 MHz，內(nèi)存8k，畫面 52色，同屏最多顯示其中的13色，聲音2個矩波,1個三角波，1個雜音，1個PCM音頻(見圖1-2)。</p><p>　　Battle City是其發(fā)售卡帶中的一款力作，設(shè)置了35個關(guān)卡，可以雙人操縱，畫面設(shè)置了若干種類的建筑物和阻擋物，以消滅所有敵人為通關(guān)條件，并有接寶物等增加游戲效果的設(shè)置，畫面精美，音效杰出，在PC機的80386處理器仍未面世的當(dāng)時，能在硬件上

37、運行這樣的2D程序不得不令人驚嘆，難怪常有人說游戲程序是最大限度發(fā)揮硬件水平的載體。其游戲界面如圖1-3所示。</p><p>　　1.4 本章小結(jié)：</p><p>　　引言和第一章中介紹了手機在無線應(yīng)用方向的當(dāng)今概況，并介紹了游戲業(yè)務(wù)在當(dāng)前社會的發(fā)展?jié)摿?。分析了J2ME在手機軟件開發(fā)中起的重要作用，描述了本論文的相關(guān)背景。</p><p>　　第二章 開發(fā)環(huán)境

38、及相關(guān)技術(shù)的介紹</p><p><b>　　2.1 開發(fā)環(huán)境</b></p><p>　　操作系統(tǒng)：Microsoft Windows XP</p><p>　　程序語言：Java 2</p><p>　　開發(fā)包： Java(TM) 2 Standard Edition (build 1.4.1_02-b06)

39、 Sun Micro. J2ME Wireless Tool Kit 2.1</p><p>　　IDE: Borland Jbuilder 9</p><p>　　2.2 Java語言的特點</p><p><b>　　1. 平臺無關(guān)性</b></p><p>　　Java引進(jìn)虛擬機原理，并運

40、行于虛擬機，實現(xiàn)不同平臺之間的Java接口。使用Java編寫的程序能在世界范圍內(nèi)共享。Java的數(shù)據(jù)類型與機器無關(guān)。</p><p><b>　　2. 安全性</b></p><p>　　Java的編程類似C++,但舍棄了C++的指針對存儲器地址的直接操作，程序運行時，內(nèi)存由操作系統(tǒng)分配，這樣可以避免病毒通過指針入侵系統(tǒng)。它提供了安全管理器，防止程序的非法訪問。<

41、;/p><p><b>　　3. 面向?qū)ο?lt;/b></p><p>　　Java吸收了C++面向?qū)ο蟮母拍?，將?shù)據(jù)封裝于類中，實現(xiàn)了程序的簡潔性和便于維護(hù)性，使程序代碼可以只需一次編譯就可反復(fù)利用。</p><p><b>　　4. 分布式</b></p><p>　　Java建立在TCP/IP網(wǎng)絡(luò)平臺

42、上，提供了用HTTP和FTP協(xié)議傳送和接收信息的庫函數(shù)，使用其相關(guān)技術(shù)可以十分方便的構(gòu)建分布式應(yīng)用系統(tǒng)。</p><p><b>　　5. 健壯性</b></p><p>　　Java致力與檢查程序在編譯和運行時的錯誤，并自動回收內(nèi)存，減少了內(nèi)存出錯的可能性。Java取消了C語言的結(jié)構(gòu)、指針、#define語句、多重繼承、goto語句、操作符、重載等不易被掌握的特性，

43、提供垃圾收集器自動回收不用的內(nèi)存空間。</p><p>　　2.3 關(guān)于JBuilder9</p><p>　　JBuilder是目前最好的Java開發(fā)工具之一，在協(xié)同管理、對J2EE和XML的支持等方面均走在其他產(chǎn)品的前面。JBuilder是遵循Sun公司J2EE標(biāo)準(zhǔn)的可視化集成開發(fā)工具。Jbuilder是一種處于市場領(lǐng)先地位的跨平臺環(huán)境，主要用于構(gòu)建具有行業(yè)實力的企業(yè)Java應(yīng)用程序

44、。JBuilder集成了Borland公司開發(fā)工具系列的優(yōu)秀特性，使得使用過C++Builder,Delphi的程序員很容易的過度到JBuilder的開發(fā)環(huán)境當(dāng)中。由于Java技術(shù)的發(fā)展迅速，經(jīng)常有新的組件推出或新的錯誤修正，致使JBuilder的版本升級很快。當(dāng)兩年前還是JBuilder6時，現(xiàn)今已推出了9、10的版本。</p><p>　　2.4 關(guān)于Wireless Tool Kit</p>

45、<p>　　WTK(Wireless Tool Kit)是Sun公司針對J2ME推出的用于手機和Palm等移動設(shè)備的開發(fā)包，是除手機廠商的專用開發(fā)包外唯一的手機模擬器開發(fā)包。它通用性高，開發(fā)出的應(yīng)用程序可保證能運行在大部分設(shè)備上，而不像專用廠商具有一定的不兼容性。雖然它沒有強大的功能和完善的調(diào)試手段，但它提供運行模擬器的最基本組件，是其他IDE需集成采用的必備元素。</p><p>　　2.5 Ja

46、va Appication Manager</p><p>　　手機中負(fù)責(zé)調(diào)配程序運行資源的管理后臺是Java Application Manager。它所使用的傳輸媒體可以是紅外線、網(wǎng)絡(luò)、以及其他可用來傳輸?shù)拿襟w。Java Application Manager 會從網(wǎng)絡(luò)上下載代表該Application Suite 的JAR 檔，接著在手機上安裝此MIDlet Suite，然后在手機開始執(zhí)行該應(yīng)用程序。整個詳

47、細(xì)的運作流程如圖2-1所示。</p><p>　　2.6 本章小結(jié)：</p><p>　　第二章介紹了Java語言的特點、本程序的開發(fā)環(huán)境及其相關(guān)工具的原理和使用。</p><p>　　第三章 程序結(jié)構(gòu)、思想和相關(guān)技術(shù)</p><p>　　3.1 本程序需解決的有關(guān)技術(shù)問題</p><p>　　1. 游戲程序是一

48、項精度要求很高的程序系統(tǒng)，因為其代碼利用率很高。一個實時運行的最終作品，每秒都會運行成千上萬行程序，繪圖事件、鍵盤事件都會以極高的頻率在后臺等待響應(yīng)，若有絲毫的差別都將很容易導(dǎo)致程序在運行不久后可能出現(xiàn)嚴(yán)重錯誤，甚至死循環(huán)。因此，其邏輯設(shè)計應(yīng)當(dāng)相當(dāng)嚴(yán)謹(jǐn)，需將所有可能發(fā)生的事件及意外情況考慮在設(shè)計中。</p><p>　　2. 游戲中為了美觀，適用性強，可能需要采用外部文件引入的圖片貼圖，有關(guān)貼圖，在MIDP2.

49、0中提供了用于增強游戲功能的game包，使得解決靜態(tài)或動態(tài)、畫面背景、屏幕刷新的雙緩沖等都有較好的解決方案。</p><p>　　3. 己方坦克的運行可以通過鍵盤響應(yīng)事件控制，但敵方則因為是自動運行，就需要有一定其一定的智能性；同時，出現(xiàn)在屏幕上的敵方可能會有較多的數(shù)量，這需要為每個敵方開辟一個線程以便能讓其獨立運行。Java的多線程能力為實現(xiàn)這樣的游戲提供了可能。敵人坦克的運行算法也需要進(jìn)行適當(dāng)?shù)脑O(shè)置，以免游

50、戲過于簡單，單調(diào)。</p><p>　　4. 對于雙方坦克發(fā)出的子彈的控制也需要對其跟蹤控制，子彈也需要處在獨立的線程中。敵方子彈僅需要掃描用戶坦克，而用戶坦克需要在每一步掃描所有的敵方坦克。這需要對所有的對象有較好的控制。另外，子彈在運行過程中也需要實時掃描是否碰撞到了相關(guān)障礙物或屏幕邊界。如此過多的線程同時在本來效率就不高的KVM虛擬機上運行，也許會導(dǎo)致程序的緩慢。</p><p>

51、　　5. 雙方的坦克在前進(jìn)時也需要考慮到是否碰撞到相關(guān)物體或?qū)Ψ教箍?，以免重疊運行，造成許多物理上不可能的情況，缺乏真實感。每一次刷新頁面、每前進(jìn)一步都需要將所有的周圍環(huán)境都進(jìn)行掃描。</p><p>　　6. 游戲的結(jié)束、開始、動態(tài)信息畫面作為構(gòu)成一個完美程序都是必不可少的重要部分。良好的用戶界面更是吸引用戶的硬指標(biāo)，相關(guān)的美術(shù)構(gòu)圖也需要有一定的考慮。</p><p>　　7. 游

52、戲的地圖不可能通過繪圖來解決。否則，不僅難于控制和處理過多的元素，也會因過多的大型圖片而不能限制程序的大小，失去手機上程序的原則和Java的優(yōu)勢。同時，地圖關(guān)卡不宜保存在手機有限的內(nèi)存中，而最好采取外部文件的讀入讀出方法。</p><p>　　8. 用戶運行游戲時需要有分?jǐn)?shù)記錄的可能。如何采用合理的記分標(biāo)準(zhǔn)，需要進(jìn)行適當(dāng)?shù)脑O(shè)計。記錄分?jǐn)?shù)的存儲方式也需要有較好的解決方案。手機中由于處理器和內(nèi)存空間、存儲空間都十分

53、有限，其數(shù)據(jù)庫系統(tǒng)與普通PC大相徑庭。其數(shù)據(jù)庫結(jié)構(gòu)較為簡單，被稱之為RMS系統(tǒng)。</p><p>　　9. Java是基于虛擬機的半解釋型編譯系統(tǒng)，其執(zhí)行效率較C++等完全編譯后的程序會低很多，程序如果不進(jìn)行精簡和優(yōu)化，將可能導(dǎo)致運行的不流暢。除開發(fā)過程中對結(jié)構(gòu)上的控制、變量的使用、算法的優(yōu)化等優(yōu)化外，還可以使用混淆器(Obfuscator)進(jìn)行程序打包后的優(yōu)化。</p><p>　　以

54、上相關(guān)技術(shù)細(xì)節(jié)和整體流程將分別在以下小節(jié)闡述。</p><p><b>　　3.2 程序流程</b></p><p>　　MIDlet suite是MIDP應(yīng)用程序的最小單位，JAM負(fù)責(zé)將手機內(nèi)的MIDlet suite以圖形化的方式呈現(xiàn)，讓用戶能夠選取欲執(zhí)行的MIDlet suite，一旦選取了某個MIDlet suite，操作系統(tǒng)就會激活KVM執(zhí)行里面的MIDl

55、et。MIDlet及相關(guān)的支持類組成了MIDP應(yīng)用程序的實際內(nèi)容。</p><p>　　每個MIDlet都必須繼承javax.microedition.midlet.MIDlet這個抽象類。在MIDP規(guī)格中定義了MIDlet的生命周期，以及可以存在的三種狀態(tài)，包括Paused、Active以及Destroyed，每一個MIDlet在任何時刻只可能處于其中的一個狀態(tài)。這三種狀態(tài)的轉(zhuǎn)換關(guān)系如圖所示：</p>

56、;<p>　　本程序采用面向?qū)ο蟮脑O(shè)計模式，對游戲中的所有物體賦予對象的概念和屬性。運行程序后允許用戶選擇執(zhí)行選項菜單，在開始游戲后將先從外部文件載入地圖文件，對背景的所有物體進(jìn)行繪圖。在主程序運行的線程中，畫面刷新將以一定的頻率采用雙緩沖技術(shù)對屏幕重繪，實時反映整個游戲的進(jìn)行狀態(tài)。用戶控制的坦克運行在主線程中，隨屏幕刷新的頻率而步進(jìn)。敵方坦克將在游戲開始時逐漸新增線程，每增加一個敵方對象就新增加一條線程，一旦線程數(shù)滿到最

57、大值（本程序暫設(shè)置為6），就不允許敵人再繼續(xù)出現(xiàn)。用戶坦克自誕生之時起將擁有一發(fā)子彈，子彈雖然開在單獨的線程中，但運行結(jié)束后（比如撞到相關(guān)物體或敵方坦克時）并不結(jié)束子彈對象，只是將其線程終止。用戶再次發(fā)射子彈時只是將終止的線程再次激活。在屏幕重繪的主程序中，將在每次的循環(huán)中判斷若干事件。如：用戶坦克的生命是否已完全用盡，敵方坦克數(shù)是否已經(jīng)為零，屏幕上的坦克數(shù)量是否少于仍剩下的坦克數(shù)量等。以便程序進(jìn)入相關(guān)的分支執(zhí)行相關(guān)的反應(yīng)代碼，結(jié)束游戲

58、或統(tǒng)計分?jǐn)?shù)等。主程序流程如圖3-2所示：</p><p>　　程序為需要完成獨立功能的需顯示的模塊設(shè)置了單獨的類。TankMain類是繼承自MIDlet的控制主程序啟動的首先被載入系統(tǒng)的部分。載入程序后首先啟動的是程序介紹的信息畫面。閃過后載入StartChoice類，為用戶提供可選擇的選項。在選擇開始后，將運行BattleCanvas類中的總流程控制。它決定了游戲何時該結(jié)束，何時分配敵人數(shù)量，GameOver字

59、樣的閃現(xiàn)規(guī)則，地圖的繪制及整個游戲的調(diào)度。</p><p>　　圖3-3是程序中類之間的UML分析圖。敵方坦克與用戶坦克的相關(guān)功能和具體行為分別定義在EnemySprite和UserSprite類中，它們都繼承自TankSprite公共類，以簡化程序的代碼、理清結(jié)構(gòu)。</p><p>　　在每關(guān)的結(jié)束或死亡后都將載入ScoreScreen類，統(tǒng)計當(dāng)前的分?jǐn)?shù)。如果已死亡或完成所有的關(guān)數(shù)，程序

60、將用戶所得的分?jǐn)?shù)記載到RMS數(shù)據(jù)庫中，進(jìn)行永久性保存。載入過程中將對所得分?jǐn)?shù)與以往歷史比較，放置到合適的位置中，形成排序。</p><p>　　3.3 繪圖與MIDP2.0新增的GameCanvas包</p><p>　　3.3.1 提供低級繪制的Canvas類</p><p>　　為了能有程序開發(fā)人員控制接口的外觀和行為，需要使用大量的初級用戶接口類，尤其在游戲

61、程序中，幾乎完全依賴的就是Canvas抽象類進(jìn)行繪圖。從程序開發(fā)的觀點看，Canvas類可與高級Screen類交互，程序可在需要時在Canvas中摻入高級類的組件。Canvas提供了鍵盤事件、指點桿事件（如果設(shè)備支持），并定義了允許將鍵盤按鍵映射為游戲控制鍵的函數(shù)。鍵盤事件由鍵代碼指定，但這樣控制游戲會導(dǎo)致缺乏通用性，并不是每個設(shè)備的鍵盤布局都適合游戲的操作。應(yīng)當(dāng)將鍵代碼轉(zhuǎn)換為游戲鍵的代碼，以便硬件開發(fā)商能定義他們自己的游戲鍵布局。本程

62、序中，操縱用戶坦克運行的按鍵都定義為游戲控制鍵，這樣便能適應(yīng)所有的機器。</p><p>　　3.3.2 Graphics類</p><p>　　Graphics類提供了簡單的2D繪圖功能。它具有24位深度色彩的繪制能力，以三原色分別各占一個字節(jié)表示其顏色。程序只能在paint()函數(shù)中使用Graphics繪制，GameCanvas可調(diào)用getGraphics()函數(shù)直接繪制在緩沖區(qū)上，可

63、以在任何時間請求傳輸?shù)角芭_。其對象會被傳給Canvas的paint()函數(shù)，以便最終顯示。</p><p>　　3.3.3 PNG格式</p><p>　　PNG(Portable Network Graphics)格式是MIDlet唯一支持的圖象格式，PNG具體格式由PNG Specification,Version 1.0定義的。PNG格式提供透明背景的圖象，這對繪制游戲畫面和被操縱主

64、角極有幫助。坦克之間或與障礙物碰撞時就不會因為背景有特定的顏色，顯示出的效果像貼上的圖片而缺乏真實感，物體之間輕微重疊時最上層圖片也不會覆蓋超過其有效象素外的部分。</p><p>　　PNG格式圖片中包含許多定義其圖片特性的冗余部分(Chunks)。這些代碼包含在每一個單獨的png格式圖象中，然而如果將多個png圖象合并在一張幅面稍大一些的整圖中，多個chunks就可以得到精簡，圖片的大小可以得到控制。使用Im

65、age類中的createImage函數(shù)可從整圖中分割出所需要的元素。在Game包中的TiledLayer和Sprite類都整合了這樣的功能。本程序中的地圖元素都集成在一張tile.png圖片中，實現(xiàn)了方便的管理和程序體積的精簡。</p><p>　　3.3.4 Game包中的新功能</p><p>　　MIDP自2.0以后新增了Game包，為游戲的開發(fā)帶來了極大的便利。地圖繪制、主角的動

66、態(tài)顯示、按鍵的檢測、圖層的控制等游戲?qū)俚奶匦远嫉玫搅嗽谝苿釉O(shè)備上最大的發(fā)揮。</p><p>　　LayerManager（以下簡稱LM）提供控制整體畫面層的控制。它包括了一系列自動獲取了代號和位置的層，簡化了各層加入游戲畫面的過程，提供了自動排序和繪制的能力。</p><p>　　LM存儲了一個層的列表，新的層可以用append函數(shù)附加、刪除和插入。層的序號相當(dāng)于坐標(biāo)的Z軸，0層表示最

67、接近用戶視覺，層數(shù)越高，離用戶越遠(yuǎn)。層號總是連續(xù)的，即使有中間的層被移除，其他層的序號會作相應(yīng)的調(diào)整以保持整體的完整性。LM中的View Window控制著與LM相對坐標(biāo)的可視區(qū)域。改變View Window的位置可以制造出滾動屏幕的效果。</p><p>　　本程序中所有的地圖、坦克都采用LM控制，敵方坦克的生成由附加一個EnemySprite對象得到。唯有界面右側(cè)的計分欄由Graphics類繪制。</p

68、><p>　　Sprite類是繼承自Layer的用于存儲多楨的基本可視元素。不同的frame可交相顯示，構(gòu)成動態(tài)的效果。圖片可翻轉(zhuǎn)、顛倒、由一個主角圖片就可以方便的得到所有方向的顯示狀態(tài)，相比原先只能使用Canvas繪圖，需要將所有方向的主角圖象都繪制在png圖象中簡化了許多。Sprite也可以從整合的圖象中讀圖，讀圖時將把大圖分解為若干等寬等高的小圖。每個小圖按照其排列順序有相應(yīng)的序號，在程序中調(diào)用其序號，就可以繪

69、制出相應(yīng)的圖片。本程序中的雙方坦克、子彈都由Sprite繼承得到。在有些情況下，控制主角的翻轉(zhuǎn)，尤其是多幅圖片配合顯示的過程，如果將多圖的共享定位點設(shè)置在通常的左上角，將很不容易控制，因為許多翻轉(zhuǎn)都是以其他點為參考電的（比如，中心點）。由此，引入?yún)⒖键c的概念。參考點由defineReferencePixel函數(shù)確定未翻轉(zhuǎn)圖片狀態(tài)時的坐標(biāo)。默認(rèn)是(0,0)點，如果需要，可將參考點設(shè)置在畫面邊界之外。本程序中的坦克的參考點定義在圖片正中，以

70、便簡便的實現(xiàn)轉(zhuǎn)向等功能。子彈的參考點設(shè)置在子彈底部的中心，因為子彈一出炮筒的時候緊挨著坦克的象素就是其底部中心。</p><p>　　TiledLayer是有一組圖象格元素(grid of cells)組成的整塊虛擬圖象。該類使不需要高分辨率的圖象就能創(chuàng)建大幅圖面成為可能。這項技術(shù)通常應(yīng)用在2D游戲平臺的滾動背景的繪圖。一塊整圖可被分割成等大小的圖象格，每塊格有其對應(yīng)的序號，按照行列遞增。多塊格可由大塊同時替換組

71、合而模擬動態(tài)的背景，這不需要逐塊替換所有的靜態(tài)圖象格而顯得非常方便。</p><p>　　本程序中的地圖即為游戲背景。每塊障礙物都有其響應(yīng)的代號，其中，用戶需保護(hù)的總部因為體積稍大，使用了四塊圖象格顯示。地圖背景分為20*22個圖象格，每個格使用一個字節(jié)表示其中的障礙物，圖象文件存儲在外部文件中，以16進(jìn)制的整數(shù)串表示，因此每個地圖的大小為固定的440字節(jié)。如果整塊地圖均由繪圖產(chǎn)生，將導(dǎo)致體積迅速增加，且對坦克與

72、障礙物的碰撞也難以檢測。J2ME中并沒有J2SE中的File類，獲取外部文件的手段很有限，僅僅在Class類中提供了一個getResourceAsStream函數(shù)，將外部文件獲取為輸入流，再由InputStream的繼承類讀出。</p><p>　　3.3.5 有關(guān)繪圖的一些技術(shù)</p><p>　　在沒有MIDP2.0前，進(jìn)行游戲繪圖一般需要手動編程使用雙緩沖。需要在paint()方法

73、內(nèi)所想要畫的圖形畫在一張預(yù)先準(zhǔn)備好的背景，等所有繪圖操作都完成后再將背景的數(shù)據(jù)拷貝到實際的屏幕上。Image類提供了一個建立背景的靜態(tài)方法createImage(int width, int height)，再利用getGraphics()方法取得屬于這個背景的Graphics對象，所進(jìn)行的繪圖操作都會作用在背景上，等到全部的繪圖操作完成后，再調(diào)用drawImage()方法將背景的數(shù)據(jù)復(fù)制到實際顯示的屏幕上。</p>&l

74、t;p>　　這樣的技術(shù)在繪制動畫時特別有用。繪制動畫時經(jīng)常需要不斷地更新畫面，而更新畫面的操作就是先將屏幕以fillRect()的方式清除，再將下一張圖片畫在屏幕上，然而反復(fù)的清除及重繪會造成屏幕的閃爍現(xiàn)象（flicker），因此使用雙重緩沖的好處就是在背景進(jìn)行這個清除及重繪的操作，再將完成的繪圖拷貝到屏幕上，由于用戶看不到清除的操作，因此就不會出現(xiàn)閃爍的現(xiàn)象了。不過在某些MIDP的實現(xiàn)上已經(jīng)加上了雙重緩沖的支持，因此在處理前應(yīng)先

75、利用Canvas類的isDoubleBuffer()方法來判斷。</p><p>　　3.4 坦克的控制和敵方的智能運行</p><p>　　GameCanvas中提供了與以往MIDP1.0不同的鍵盤采樣功能。Canvas類中采取響應(yīng)鍵盤事件的方法，每次執(zhí)行周期時會讀取keyPressed函數(shù)中需執(zhí)行的代碼。這樣的機制并不適合某些游戲場合。在某些不支持keyRepeat功能的設(shè)備上，反

76、復(fù)執(zhí)行的按鍵，比如發(fā)射子彈，將不能因為長時間按壓而自動重復(fù)，這樣就需要用戶高頻率的手動擊鍵，這在操縱空間非常有限的移動設(shè)備上是非常困難的。同時，事件的執(zhí)行周期也并不一定適合游戲的場合，也許需要更高頻率執(zhí)行的按鍵卻只能在指定的周期內(nèi)規(guī)律的響應(yīng)。對此，針對游戲的開發(fā)，Game包提供的鍵盤狀態(tài)功能將顯得十分有效。</p><p>　　GameCanvas提供getKeyStates函數(shù)可獲取當(dāng)前鍵盤上的信息。將以位的形

77、式返回鍵盤上所有鍵的按與釋放的狀態(tài)，當(dāng)bit為1時，鍵就是被按下的狀態(tài)，為0時則為釋放狀態(tài)。只需要此一個函數(shù)的返回值就可以返回所有鍵的狀態(tài)。這保證了快速的按鍵和釋放也會被循環(huán)所捕捉。同時，這樣的機制也可檢測到幾個鍵同時按下的狀態(tài)，從而提供斜向運行等相應(yīng)功能。</p><p>　　敵方按照規(guī)則不能和用戶坦克重合，則它每行走一步就需要把用戶坦克掃描一次，判斷其是否碰撞到了用戶的坦克。Sprite類中提供了collid

78、esWith函數(shù)，用于判斷是否與某個TiledLayer、Sprite、Image的對象有圖象上的重合（即游戲中的碰撞）。然而不能僅僅將用戶坦克作為其Sprite參數(shù)傳遞給敵人的類進(jìn)行判斷。因為如果發(fā)生碰撞，collidesWith成立，則兩輛坦克已經(jīng)發(fā)生了圖象重合，違反了規(guī)則，甚至若再進(jìn)行collidesWith判斷的話，其結(jié)果將永為真。為了提前預(yù)知碰撞，可以將所有坦克的碰撞范圍設(shè)定為一個比坦克圖片稍大一些的矩形，此矩形僅在坦克前方比

79、坦克圖形多出一個象素。在多出的11個象素中，按照每個象素依次檢查此象素是否于外界發(fā)生碰撞，如果不是按照象素檢查，則當(dāng)坦克與障礙物錯位并同時與兩種物體接觸時將有可能忽略檢測其中的一樣物體。這樣，就可以提前一步判斷。如果發(fā)生碰撞，則坦克應(yīng)當(dāng)選擇掉轉(zhuǎn)方向，此時，兩輛碰撞的坦克又因為其矩形區(qū)域不重合而不符合collidesWith的條件，就可以繼續(xù)正常運行了。</p><p>　　敵方坦克由于需要具有一定的智能性，以便對

80、玩家攻擊，使之具有一定的可玩性。敵人可以自動行走，但是應(yīng)當(dāng)在以下適當(dāng)?shù)那闆r下轉(zhuǎn)向：首先是是否超出界面的邊界，其次是是否與地圖障礙物發(fā)生了碰撞，再次是是否與用戶坦克發(fā)生了碰撞。需要指出的是，當(dāng)發(fā)生阻礙不能在不變方向的情況下繼續(xù)行走時，并不一定立即需要采取轉(zhuǎn)向的對策。如果一定發(fā)生轉(zhuǎn)向，試想，當(dāng)敵方碰到玩家時，如果它立即轉(zhuǎn)向，將不會對玩家發(fā)射射向他的子彈，就不構(gòu)成任何威脅，當(dāng)然，也不能永遠(yuǎn)不轉(zhuǎn)向。本程序設(shè)置為：當(dāng)碰撞到障礙物或邊界時立即轉(zhuǎn)向，

81、但碰到玩家坦克時需要有一個等待的時間，這個時間由碰撞前隨機取得的在某方向上的持續(xù)行走步數(shù)決定，當(dāng)發(fā)生坦克間碰撞時，此隨機數(shù)將在下一次循環(huán)前減少為原來的2/3，這樣就實現(xiàn)了加快轉(zhuǎn)向的時間，避免死鎖在一個方向上靜止的停留過長的時間。另外，坦克的發(fā)炮間隔和轉(zhuǎn)后的具體方向都由隨機數(shù)決定。坦克之間由以上道理也不會發(fā)生重疊，但當(dāng)某坦克正從上方生成而正巧有另一輛阻礙在其生成點處，這將導(dǎo)致不可避免的重合。這是允許的，但需要對他們標(biāo)注狀態(tài)，即當(dāng)坦克剛出現(xiàn)

82、時暫時允許重合，一旦在某個時間他們脫離了重合狀態(tài)，就不能在允許重合，如果不設(shè)置這</p><p>　　3.5 子彈的運行和控制</p><p>　　每一個坦克都有他自己的一顆子彈，這顆子彈在任何一輛坦克被構(gòu)造時就一直存在，直至此坦克生命的結(jié)束，子彈的再次只是將屏幕上暫時掩蓋的圖象重新置于坦克炮筒才恰當(dāng)位置，并使其顯示出來，這與現(xiàn)實中每個子彈都是單獨的個體有所不同。</p>&

83、lt;p>　　子彈所需要完成的任務(wù)有：</p><p>　　它是一個繼承了Runnable虛類的可運行單獨線程的對象。在其出現(xiàn)在屏幕上的運行周期中，每一步都需要循環(huán)檢測以下條件：</p><p>　　是否與某坦克發(fā)生了碰撞，即擊中了這輛坦克。子彈使用的是象素級的碰撞檢測，因為子彈的圖片形狀不規(guī)則，如果使用矩形碰撞檢測，將有可能在子彈尚未接觸到物體時就已返回碰撞的真值。分為兩種情況，如

84、果此子彈來自于敵方，將只檢測玩家坦克，因為敵方之間的子彈必須允許可以透明的穿過，以保證不會在敵人之間發(fā)生子彈的消減。如果來自玩家，則每一步需掃描所有的敵方坦克，檢查是否發(fā)生碰撞，這可能會花費不少的CPU時間。</p><p>　　其次，子彈之間需要檢測是否碰撞。敵人之間顯然，如上已經(jīng)提過，不需要檢測，但敵人與玩家之間應(yīng)當(dāng)可以互相消除子彈，以便在狹窄的路口中仍有存活的機會。玩家的子彈需要在每一步檢測所有敵人的子彈的

85、運行狀態(tài)。這樣較多的運算也將不可避免的耗費大量CPU時間。</p><p>　　子彈對不同障礙物將有不同的反映。對磚墻將有能力將其擊毀，使之在畫面上消失；對水泥鋼筋將不能發(fā)生作用，子彈也不能通過；對于河流，坦克不可以通過，但子彈可以；對于草叢，子彈和坦克都可以通過。</p><p>　　3.6 RMS數(shù)據(jù)庫系統(tǒng)</p><p>　　MIDP為MIDlets提供了一種

86、永久存儲和后來讀出數(shù)據(jù)的數(shù)據(jù)庫解決方案，被稱為Record Managerment System(RMS)，是一種類簡單的基于記錄的數(shù)據(jù)庫。</p><p>　　很顯然，手機上的數(shù)據(jù)庫系統(tǒng)不可能有PC上的強大功能。微小的存儲空間也限制了它們的結(jié)構(gòu)不能過于復(fù)雜。RMS是專門針對移動設(shè)備的服務(wù)的。</p><p>　　RMS包中包括RecordStore類。在一個MIDlet suite包里的

87、所有MIDlet都允許創(chuàng)建多個記錄集，只要它們賦有不同的名稱。當(dāng)MIDlet包從平臺中被移除后，所有與該包有關(guān)的的記錄集都同時會被移除。同一個包內(nèi)的MIDlets可以直接互相訪問它們的記錄集，不同包內(nèi)也可產(chǎn)生共享，但這需要有包的授權(quán)屬性決定。訪問模式會在準(zhǔn)備提供共享的RecordStore被建立時被創(chuàng)建。訪問模式允許私有使用或訪問。</p><p>　　RecordStore的API采用了時間戳的概念，其長整型變

88、量由System的currentTimeMillis()函數(shù)返回決定。Record store 每次被修改后都會自動在其屬性上附加上時間戳，這為同步化引擎和程序的控制都極為有效。</p><p>　　記錄是字節(jié)數(shù)組。開發(fā)者可以利用InputStream的派生類DataInputStream、DataOutputStream以及ByteArrayInputStream、ByteArrayOutputStream將不

89、同種類的數(shù)據(jù)類型打包，以字節(jié)流的形式發(fā)送和接收。</p><p>　　區(qū)別記錄的唯一標(biāo)記是他們的ID值，作為記錄集的主鍵。第一項記錄的ID是1，其后的每個記錄ID遞增。</p><p>　　Record是以字節(jié)為基本單位來存放的，所以所有要寫入record的數(shù)據(jù)都必須先將其轉(zhuǎn)為字節(jié)才能寫入，從record所讀出來的數(shù)據(jù)也是字節(jié)，必須將其轉(zhuǎn)換為原先寫入時的數(shù)據(jù)類型才有意義。</p>

90、;<p>　　然而讀取或?qū)懭氲淖止?jié)數(shù)組都只能代表一個字段的信息，如果需要讀取或?qū)懭攵鄠€字段就必須要將數(shù)據(jù)轉(zhuǎn)換成字節(jié)信息，并且提供適當(dāng)?shù)臋C制來分隔這些信息。主要有兩種方法：</p><p><b>　　標(biāo)記法。</b></p><p>　　將所有要存放的數(shù)據(jù)用字符串表示，但是在字段和字段之間以一個特殊的符號作為分隔。符號不能和字段內(nèi)的數(shù)據(jù)相同的字符。<

91、;/p><p>　　2．利用輸入/輸出流</p><p>　　這一種方法較上一種復(fù)雜，但是較為實用。方法一中所有的字段只能以字符串的形式存儲，要對這些字段作進(jìn)一步的處理非常麻煩。利用輸入輸出流可以寫入及讀取不同數(shù)據(jù)類型的數(shù)據(jù)，做法是在寫入數(shù)據(jù)時先將一個DataOutputStream數(shù)據(jù)流對象串接到一個ByteArrayOutStream數(shù)據(jù)流對象，然后再依字段的數(shù)據(jù)類型用writeInt()

92、、writeBoolean()等方法寫入，最后把ByteArrayOutputStream內(nèi)的元素數(shù)據(jù)寫入record中。反之若要讀取數(shù)據(jù)，則先要串接一個DataInputStream對象和ByteArrayInputStream，依字段的數(shù)據(jù)類用readInt()、readBoolean()等方法讀取。</p><p>　　本程序中主要存放在永久區(qū)的內(nèi)容為用戶得到的最高分?jǐn)?shù)的記錄。一共可以存儲10條最高分。每次

93、有新的更高的記錄就會插入進(jìn)相應(yīng)的位置，將最低一名排擠出記錄。在輸入記錄前，要求用戶在TextField框中寫入他自己的名字。返回的getString可以將名字輸送給字節(jié)流。因為每個記錄包括用戶名和分?jǐn)?shù)，因此需要使用多字段的方式編入。打印到屏幕上時，記錄ID號即為排名，因此將顯示三項數(shù)據(jù)。</p><p>　　3.7 內(nèi)存使用的最佳化</p><p>　　通常在MIDP應(yīng)用程序的手機執(zhí)行環(huán)

94、境中，所牽涉的內(nèi)存有下列三種：</p><p><b>　　﹡應(yīng)用程序存儲內(nèi)存</b></p><p>　　﹡RecordStore存儲內(nèi)存</p><p>　　﹡執(zhí)行時期內(nèi)存(Java Heap)</p><p>　　其中前兩種是持久性的內(nèi)存，關(guān)閉電源后還能保持?jǐn)?shù)據(jù)的正確性，通常這兩種內(nèi)存所能存儲的容量是合并計算的，這

95、個上限對每種手機都不一樣，大部分在一兩百KB內(nèi)。在這樣的情況下需要在不影響原有功能的情況下適當(dāng)?shù)目s減JAR文件的大小，除了可以克服內(nèi)存空間的限制外，也能大幅度縮短下載的時間（費用也降低了），勢必會有更多的人愿意下載所開發(fā)的程序。其方法有：</p><p>　　第一，就是盡量縮短命名的長度。在應(yīng)用程序內(nèi)，對于所建立的類、接口、方法及變量名而言，都需要賦予一個識別的名稱，所命名的名稱每多一個字符就會在類文件內(nèi)多產(chǎn)生一

96、個字節(jié)，對于一個較復(fù)雜的應(yīng)用程序而言就會增加為數(shù)不小的數(shù)據(jù)量。所有這些可以借助混淆器來幫助實現(xiàn)。</p><p>　　第二是減少復(fù)雜的程序結(jié)構(gòu)，為一些共同的行為建立一個抽象類(Abstract Class) 來表示繼承的子類的共通性。</p><p>　　第三是減少圖形數(shù)據(jù)的大小。將PNG格式的小分辨率圖象合并在一張大的高分辨率圖象中，由于減少了chunks，將比合并前的總大小減少許多。&

97、lt;/p><p>　　3.8 混淆器(Obfuscator)的使用</p><p>　　Java 語言并沒有完全編譯成二進(jìn)制可執(zhí)行文件，編譯出的.class文件是一種介于源程序和二進(jìn)制之間的一中基于半解釋的字節(jié)碼，需要虛擬機來執(zhí)行。它包括了所有的信息。然而這樣會導(dǎo)致.class很容易被反編譯為源代碼，從而不能保護(hù)作者的知識成果。目前流行的如decode,JAD等反編譯工具可以以很快的速度生

98、成源文件。如果不加以施行有效的措施，將造成嚴(yán)重的后果。</p><p>　　由此引入混淆器的概念?；煜鲗⒋a中的所有變量、函數(shù)、類的名稱變?yōu)楹喍痰挠⑽淖帜复?，如果缺乏相?yīng)的函數(shù)名指示和程序注釋，即使被反編譯，也將難以閱讀。</p><p>　　混淆器的作用不僅僅是保護(hù)代碼，它也有精簡編譯后程序大小的作用。由于以上介紹的減少變量、函數(shù)的命名長度的關(guān)系，編譯后也會從.class文件中減少這

99、些冗余的信息?；煜?，體積大約能減少25%，這對當(dāng)前費用較貴的無線網(wǎng)絡(luò)傳輸是有一定意義的。</p><p>　　為了能與各種IDE集成，就像Java2 SDK一樣，混淆器采用命令行參數(shù)的形式，以便可被其調(diào)用。目前流行的Obfuscator有RetroGuard等。</p><p>　　3.9 模擬器的相關(guān)調(diào)試</p><p>　　IDE整合的Wireless To

100、ol Kit提供了許多在運行時監(jiān)視運行狀態(tài)的工具。 包括內(nèi)存狀況的檢測（手機上的內(nèi)存空間十分有限，必須時刻關(guān)注機載內(nèi)存是否大于程序所能使用到的最大可能的內(nèi)存空間），網(wǎng)絡(luò)狀況的檢測，運行函數(shù)的跟蹤等。如圖3-4，是內(nèi)存跟蹤測試隨時間變化的調(diào)試器。其中，允許強制垃圾回收(Garbage Collection)。由于Java語言中，不像許多其他的如C++語言，不需要指定回收函數(shù)中特定不使用的資源，資源回收機制將自動清空無效變量占用的空間。在程

101、序運行中也可以調(diào)用System類的gc()函數(shù)手動收回廢棄的內(nèi)存。</p><p>　　3.10 本章小結(jié)：</p><p>　　第三章中介紹了程序的流程、相關(guān)技術(shù)的思想及其在本程序中的應(yīng)用。分別對繪圖、數(shù)據(jù)庫、游戲基本算法等做了詳細(xì)敘述。具體算法的代碼實現(xiàn)和詳細(xì)流程將在下章介紹。</p><p>　　第四章 程序分析和具體實現(xiàn)</p><p&

102、gt;　　4.1 游戲進(jìn)入前的選擇</p><p>　　每個MIDlet程序都必須有一個主類，該類必須繼承自MIDlet。它控制著整個程序的運行，并且可以通過相應(yīng)函數(shù)從程序描述文件中獲取相關(guān)的信息。該類中擁有可以管理程序的創(chuàng)建、開始、暫停（手機中很可能有正在運行程序卻突然來電的情況，這時應(yīng)進(jìn)入暫停狀態(tài)。）、結(jié)束的函數(shù)。</p><p>　　進(jìn)入時，首先載入畫面的不是游戲運行狀態(tài)，而是提供

103、選項，當(dāng)再次選擇Start Game時才正式運行。運行畫面如圖4-1所示。因此，在TankMain的構(gòu)造函數(shù)中分配了StartChoice類，即選項畫面的內(nèi)存空間。在startApp()函數(shù)中，隨即調(diào)用了Displable的setCurrent()函數(shù)將當(dāng)前屏幕設(shè)置為startChoice。在顯示高級用戶界面前，建造了一個Alert類。Alert對象用于顯示提示、警告等告之用戶信息的臨時閃現(xiàn)的屏幕，它可作為setCurrent的參數(shù)，提

104、前顯示在最終需要顯示的屏幕前。當(dāng)將FOREVER作為Alert的參數(shù)時，將永久顯示，直到用戶點擊相應(yīng)按鈕手動結(jié)束。但是當(dāng)顯示的畫面元素超過一屏大小時，將自動轉(zhuǎn)換為永久狀態(tài)。在此，由于貼在Alert上的圖片大小超出了其范圍，故已成為永久狀態(tài)。效果如圖4-2所示。</p><p>　　startChoice繼承了接口commandListener，這樣，就可以使用高級界面的Command按鈕。繼承了commandLi

105、stener的類必須擁有commandAction()，以決定對按鍵采取什么樣的行為。即按鈕事件觸發(fā)后需執(zhí)行的函數(shù)。在設(shè)置好commandlistener后，需要調(diào)用setCommandListener()以將按鈕事件激活。鍵盤事件中，可用getCommandType()返回的Command類型來確定選擇的是什么按鈕。</p><p>　　startChoice繼承了List類，用于顯示列表選項，使用其appen