JRE極限精簡探求手冊[1]——精簡一個Swing的即時戰略遊戲

該作者資訊可以在[url]http://home.arcor.de/newbielein/[/url]獲得，這是一個德文網頁，作者也提供了其它一些小型Java遊戲的展示，比如：

有興趣的可以下載下傳作為參考。

ApoDefence 是一個Java制作的2D即時戰略遊戲,遊戲主題是本國要塞的加強及本國城堡的防護,雖然作者所提供的功能對比商業化遊戲遠不夠完全,但是即時戰略遊戲的 基本要素,如小地圖，點選對象,建築的搭建、修理、破壞、計時，建築更新，多兵種協作，敵我互動及地圖編輯都已經在由此遊戲中展現出來，應該這個程式說對 于開發Java即時類遊戲而言是一個不錯的參考範例。

ApoDefence主要檔案有兩部分，一是ApoDefence.jar本身，一是levels檔案夾下的腳本地圖，兩者累計大小為734KB。

應該說，如果它永遠隻有這麼大，将他放到同人遊戲站點上，下載下傳量是絕不會輸給其他語言開發的同類遊戲的。

<b>遊戲界面1：</b>

<b>遊戲界面2：</b>

但遺憾的是，這個遊戲是Java開發的，如果沒有動辄數十兆的虛拟機支援，它是很難跑得起來的。

試問你看到這麼一個小遊戲，記住，也僅僅是個小遊戲，它似乎很好玩，卻需要下載下傳十幾甚至幾十兆的安裝程式，你還會有興趣去嘗試嗎？我相信大多數人的答案會是否定的，是以，我開始試着精簡它。

<b>第一步：整理你的RT.JAR檔案</b>

我們都知道，JRE的完整版體積是很大的，在其檔案夾内充斥着無數的dll,jar及properties配置檔案，但要說到其中那個檔案最大，最占用空間，則首推rt.jar檔案莫屬。

以JRE1.6中的rt.jar為例，僅它一個jar，便占用了将近46MB的硬碟空間，這無疑是種壟斷，嚴重擠壓了其它jar同類的生存空間~~~

那麼，我們要開始精簡rt.jar了。

首先，我們制作一個簡單的bat批處理檔案，内容如下：java -jar GreenJVMMake.jar -t da -i ./ApoDefence.jar -o ./

為的是調用ApoDefence.jar圖形程式，并将精簡後的rt.jar在本地輸出。

我們可以看到，随着我們的操作，所有被調用過的類都被記錄下來了，事實上由于元件大多數都會重用的關系，隻要運作幾個典型界面，就可以把整個程式使用到的class全部打包進來了,而不必一直玩到通關。

現在我們來看看成果吧，一個原始大小将近46MB的“怪物”，現在在這個Swing遊戲環境中，還剩下多少呢？20MB嗎？10MB嗎？不，比那要小得多，答案是僅有不足3.2MB了。

這麼小的庫能夠跑得起來這個Swing遊戲嗎？我們可以先在本機試試看。

就結果來看，答案似乎是肯定的，我們精簡成功了。但事實果真如此嗎？未必。我們将程式釋出到一台從未配置過Java環境的機器看個究竟。

我們可以清楚地看到，雖然開始啟動後已經載入了作者的醜陋嘴臉~|||……但GreenJVM卻同時提示給我們一個Exception，顯示找不到sun.font.StandardGlyphVector類，但我們在本地調試得好好的啊，究竟為什麼呢？

其實原因很簡單，就在于我們的JRE是針對A系統環境而配置的，而并非B系統。

大家都知道，無論是JRE或者我們開發Java程式時，為了最大限度發揮Java跨平台特性，都會對不同的系統采取不同操作，進而提高本地環境下Java執行效率。

但是，當我們利用GreenJVMMake.jar進行rt.jar精簡後，則隻會獲得本機環境下需要的類，卻并非所有環境下都通用的類，異常産生的原因也在于此。那麼我們應該怎麼辦呢？

其實很好解決，第一、由于我們使用的是自帶JRE，決不會存在版本沖突問題，無論調用方式怎樣，最終的結果，絕對是特定版本産生的，也就是不可能存在針對版本優化而缺少類庫的顧慮。第二、事實上能夠針對不同環境的配置變更并不多，要說最常見的，那就是語言與字型。比較典型的就是我們剛才所見的font包異常，這類異常大多是由現有 Java字庫對本地環境的不支援所産生的，那麼針對在不同環境使用的程式，我們在精簡時可以刻意的保留下所有font及所有如zh_cn、en等針對不同語言所定制的對應類（英文程式則沒必要保留所有語言支援），這樣雖然程式體積比之前略大些，卻可以從根本上解決問題。

現在，我替精簡的rt.jar重新拷貝所有的font支援類（這部分我在GreenJVMMake.jar中添加了完整保留指定庫的功能，由于改動太少暫時沒有釋出，自己ctrl+c和ctrl+v也不麻煩）。

替換後的精簡rt.jar大小如圖：

<b>第二步：删減不必要的exe，dll及其它一切配置檔案。</b>

這 步說簡單也簡單，說麻煩便麻煩，簡單的是舉凡rt.jar中不調用的，除了jvm.dll(它調用一切)，我們盡管删掉即可；麻煩的是目前為止還沒有一個 工具提供了這樣的功能（考慮寫一個），現在我們隻能依據經驗來判定這些檔案是否會被rt.jar調用了，這部分我準備寫再下回時說，先賣個關子。但有一點 最基礎的大家可以注意一下，那就是通常這些檔案名會有和類名互相對應的部分。

<b>第三步：壓縮精簡後的JRE</b>

這時有兩類方式可供選擇。

一、使用Install4J等工具制作精簡JRE。

我這裡建議使用Install4J，這是目前為止對Java軟體支援最全面的安裝包制作工具，我個人目前所使用的是4.1.4版。

我們以Install4J為例，直接通過選擇[Create a JRE Bundle] ,建立一個自定義的JRE包。

選擇精簡後的JRE所在路徑，版本，及擴充名（Install4J識别用）。

此時的Install4J對JRE來說，會有兩種不同的壓縮方式，一是針對JRE1.5以下版本的直接壓縮，二是針對JRE1.5以上版本的pack200壓縮jar，再二次壓縮成JRE包。

當我們使用JRE1.5以下版本方式壓縮JRE包時，通常不會有任何問題，因為這時Install4J隻是單純的壓縮一個gz格式檔案。

如上圖所示，針對JRE1.5以下版本進行JRE壓縮成功，最後生成的檔案将位于Install4J目錄下jres檔案夾中，本例生成的JRE檔案大小約5MB。

而當我們以JRE1.5以上版本壓縮JRE時，問題就來了，因為此時Install4J将調用pack200進行jar壓縮。

對一個完整的JRE打包來說，擁有pack200相關功能當然不是問題，可在使用精簡的JRE時，卻變得不一定了。

瞧，剛才還能正常運轉的Install4J，此刻卻罷工了。理由很簡單，我們的精簡包中沒有打入pack的類支援，是的，運作Install4J的JRE1.5以上版本打包不光需要Pack200.exe檔案，同時需要rt.jar中的類庫支援。

沒辦法，我們制作一個完整調用pack類庫的小程式，而後以此生成僅有依賴庫的rt.jar，合并打包進自定義的rt.jar中，再次運作程式。OK，通過了。

經過Install4J打包的jre1.5以上版本jre能夠壓縮得相當厲害，我們原本将近10MB的檔案經其壓縮整理後隻有2MB多一點。

但是Install4J畢竟是一個收費軟體，況且現在的環境下流行綠色軟體，也就是所謂的免安裝無插件不修改系統資料庫或其它系統檔案的程式……畢竟我們有時也希望能将Java程式作為一個綠色軟體進行釋出。

二、使用7-Zip等工具制作精簡JRE。

現在，我們以7z格式制作一個jre壓縮包。

首先，我們學習Install4J的方法，先将所有jar進行pack200打包，由于pack200是針對jar定制的壓縮程式，是以能最大限度的減小jre中檔案體積。

由于本示例使用GreenJVM作為jar引導程式，是以包名字尾命名為[pack200]，當GreenJVM初始化時将自動調用unpack200.exe解壓檔案所在目錄及子目錄下所有[pack200]字尾的檔案。

其實，我們使用壓縮工具對JRE檔案夾進行壓縮，本例中我們使用7-zip進行壓縮。

此後我将将得到一個jre,現在這個總體積約5MB的jre包，就是最終可以執行此Swing遊戲的環境了（相較于Install4J壓縮後的JRE包而言，這個JRE壓縮檔案還是大了，利用某些機制還可以壓得更小，下回介紹）。

無論我們采取那種機制，這個JRE最終釋出版都會被維持在5MB以内。

<b>第四步，打包釋出。</b>

1、直接進行壓縮打包

這點其實沒什麼可說的，如果你使用GreenJVM制作的綠色Java程式，那麼你隻需把用到的程式連帶精簡後的JRE都丢給使用者就好。輕按兩下exe檔案運作我相信大部分使用過電腦的人還是明白的……

另外有一點需要補充說明，就是同種壓縮方式二次壓縮将很難使檔案再度縮減，比如本例我們以7z格式打包jre，那麼如果針對整個應用制作再次壓縮檔案則選用rar格式更合适。

2、使用Install4J進行打包釋出

比較大多數Java開發的程式而言，上面這個綠色釋出版的體積可說是相當小了，已經能滿足絕大多數Java遊戲的需要（除了沒聲音，因為原 遊戲沒調用），但是對比本地環境開發的程式來說依舊太大，使用者并不一定便會接受，這時我們為了讓他更小一些，單純的壓縮已經不能派上用場，非借助安裝工具 的多重壓縮精簡不可了。

依舊使用Install4J，它的視圖安裝方式極為簡單，正宗的傻瓜式“下一步”就可以搞定，時間關系這裡不作詳細說明，直接跳到設定媒體檔案模式。

<b>由于此示例基于windows系統開發，是以僅設定windows平台支援。</b>

經過一系列下一步後，選擇我們制作的JRE，靜态綁定。

最後，我們選擇建構一個Windows平台下的安裝程式。

看吧，這就是最終的結果。

一個僅僅1.25MB的Swing即時戰略遊戲，試問如果我們不說這是Java開發的程式，又有幾個人能想得到連虛拟機帶執行程式打包後也僅僅1.25MB呢？而且事實上，它還可以變得更小，乃至精簡到1MB之内。（留待下回說明）

現在，我們将它安裝到沒有JRE的計算機上去看看結果吧。

<b>炮彈照打，獅子照跑~~~完全OK。</b>

那麼下回，我們将進一步尋找究竟有哪些因素限制了JRE的體積，并進一步解放JRE。

（由于Install4J打包有一些細節準備下回分解，是以安裝程式暫時不發，透露一點，壓縮的JRE要想正常使用Install4J釋出，還需補充一些檔案，可參見Install4J正常安裝時釋放在temp中的某些東西～）

本文轉自 cping 51CTO部落格，原文連結:http://blog.51cto.com/cping1982/129630