JRE極限精簡探求手冊[0]——JRE該減肥了*

PS:業餘繼續整理Loonframework-web部分源碼中，在業餘的業餘中抽空寫點雜說……

——————————————————————————————————————

   PS:本文JRE皆指Sun JRE。

   大家都知道，通常Java程式需要JVM與OS互動才能運作于本地環境之上，所謂魚與熊掌不可兼得，這樣做雖然極大降低了程式的移植難度，卻同時增加了程 序的環境要求，因為無論你用什麼方法，總需弄個虛拟機才能讓你的Java程式跑起來（JET之類轉Win32編譯的方式愚以為不如直接寫C++程式，那樣 更安全更高效） 。

   當面對企業級使用者時，虛拟機安裝這根本就算不上問題，布署之類事宜本就有專人負責，我們踏踏實實寫代碼就好，精簡JRE之類的瑣事與我何幹？或者說，根本就不存在精簡它的必要，又何必想要去精簡呢？

   然而，當你的軟體最終不是面向企業，而是面向個人使用者時，那麼JRE的安裝就絕對成了問題。

   我們想象一下，現在有兩套同期釋出的個人軟體，一套是Java開發，一套是Delphi開發，它們功能近似，售價近似，且都處在普及階段，同樣沒有多餘的 經費進行廣告宣傳，隐藏資料是：Java軟體實用性較強。而此刻人們無從得知其具體性能，隻能通過下載下傳免費試用版作比較。

   這對于Delphi開發的軟體似乎沒什麼說的，隻要老老實實打包釋出就好；可對Java軟體來講，麻煩卻找上門來了，那就是，我要怎麼布署安裝才合适呢？   

   方式一：老老實實把JRE打包進軟體中，一起釋出。理由：1、減少使用者操作複雜度，直接安裝即可使用，有利于使用者體驗。2、避免在已安裝JRE系統上産生版本沖突。

   Java方軟體大小：使用最适合Java程式釋出的Install4J打包，比如JRE1.6大約能夠壓縮到10MB以内，假設我們以jar形式釋出軟 件，釋出的jar及配置檔案等累計占用空間10M以内，那麼到了Install4J中至多也就是2-3MB，理想狀态下，我們的安裝程式可能隻有10MB 多一點左右甚至不到，當然，這已經接近極限了。

   Delphi方軟體大小：使用InstallShield打包，exe及dll與其他配置檔案累計占用空間5MB左右，打包後安裝檔案維持在2MB左右（實際上可能更小|||）。

   可能的結果：2MB VS 10MB的同類軟體，簡單化的說，就是下載下傳你一個Java程式的時間，夠下載下傳這Delphi程式5個|||。 

   我們都知道，如果你在網絡上下載下傳電影，隻要有1部以上，那麼通常講都會或自覺或不自覺地下載下傳速度較快那部，難道在下載下傳軟體時，人就會例外嗎？

   結 果是，使用者可不懂什麼叫Delphi那個是Java，他們隻關心那個快捷，那個友善，而看到這2MB和10MB的對比，他們則更多的會懷疑體積龐大一方的 技術，為什麼東樣的東西你做這麼大人家就占那麼點空間？懷疑你内置的東西，該不會這小子整合套遠端監控系統進來吧？……如果兩個軟體同時釋出，隻要 Java方沒有比Delphi方更高明的宣傳手段，那麼結果肯定是大家都一窩蜂的去下載下傳Delphi軟體，過一段時間，大家軟體用熟了，習慣成自然，自然 還是繼續使用Delphi方的，即便有幾個用Java方軟體感覺不錯，那也隻會成為類似Mac OS對比Windows的感歎罷了。

  方式二：利用網絡安裝手段，比如使用Sun提供的jinstall那套網絡安裝小工具，檔案大小都隻有幾百KB，或者直接令Install4J安裝程式進 行網絡下載下傳，而不直接打包JRE。理由：1、最大限度縮小安裝程式體積，增加使用者信賴度。 2、減少程式下載下傳時間，有利于使用者體驗。

  Java方軟體大小：由于沒有直接攜帶JRE，Install4J打包程式後我們的安裝檔案至多也不過2、3MB，看上去很可能比Delphi安裝程式更小。

  Delphi方軟體大小：見方式一。

  可能的結果：2MB左右 VS 2MB的同類軟體，此刻潛在使用者們實際上是很難抉擇的，大體上講不成倍數的軟體體積差距普通使用者基本是無視的，是以他們這時很可能會想要比較一下性能，也就是Delphi程式和Java程式各下載下傳一個看看，反正看上去空間占用都很小。

  然而，對Java來說，問題再次出現在某個場景之内......

  哇！某位使用Java版軟體的女使用者尖叫着呼喚她的XX：“快來看看，我這電腦怎麼了？自動下載下傳起來了~”，“什麼事啊？我看看……我靠，你這下載下傳什麼 呢？還十幾兆這麼大？！”，女：“不知道呀，我一安裝XXXX軟體，它就提示正在準備安裝，然後就聯網開始讓我下載下傳什麼Java，我一點選下載下傳，都1分鐘 了還沒完呢~”，男：“快中斷程序，肯定是個流氓軟體！”，女：“我X，什麼破東西啊，以後再也不用它了。”……

  結 果是,與這位女性有相同或類似經曆的使用者開始痛罵Java開發的XXXX軟體,進而發展到論壇甚至媒體,XXXX軟體盡管多方解釋,但無奈于我國的特殊國 情,最終被使用者歸類于服務差性能差的垃圾軟體一類,同時受輿論及自身安裝體驗影響,使用者大量湧向市場占有率本就非常接近的Delphi軟體一方……

 我們來看一下Sun提供的JRE1.6 Windows版安裝說明：

 系統要求

    * Vista

    * Windows 2000 (SP3+)

    * Windows XP Home

    * Windows XP Professional (SP1+)

    * Windows Server 2003 Editions

  支援Intel和100%相容處理器。推薦使用實體記憶體至少為 64MB 的 Pentium 166MHz 或更快處理器。此外，還應至少擁有 98MB 的可用磁盤空間。   

  無論我們怎樣替普通使用者布署JRE,一個完整的JRE始終都太大了,這對于大部分隻想完成單一功能,又沒有多少軟體知識的普通使用者來說,無疑是種負擔.  

  而事實上講，我們所使用的類庫往往隻是JRE提供給我們類庫中的極小一部分，大多數時候，不過是十之二、三甚至于十之一、二，更多的則僅僅是無意義的存在那裡，浪費着使用者的磁盤空間罷了。

  試想當年Applet何等風光，如果不是因為它太重太不友善，不是因為與微軟決裂及Flash等輕量級應用的雙重打擊，那麼今天那些寫Flash的家夥幹的事情，本就該歸我們Java程式員負責才對。

  于是我們渴望更小的，更實用的，輕量級的，消費型的JRE出現，以從根本上避免上述這些無謂的浪費與遺憾。

  慶幸的是，Sun已經開始意識到這些，開始嘗試JavaFX項目及Java Browser Edition計劃等一系列行動，但目前來說，依舊是遠水解不了近火，是以目前階段要想精簡JRE，還是要靠我們自己動手、豐衣足食了。

  下文開始，我将結合具體執行個體嘗試JRE的精簡與壓縮。

  ————————————————————————————————————————————————————

  睡覺，明天晚上回來繼續……

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