我能做些什麼來減少我的可執行文件的大小（Delphi）？

我使用Delphi 2009爲桌面程序發佈單個可執行文件（.EXE）。我沒有任何程序運行所需的外部DLL或資源。我能做些什麼來減少我的可執行文件的大小（Delphi）？

我使用兩個組件：LMD Innovative's ELPack和Sergey Tkachenko's TRichView，它們被編譯到我的可執行文件中。

當我構建我的生產版本時，使用「Release」構建配置，生成的可執行文件爲13,533 KB。

在使用Delphi 2009之前，我使用的是Delphi 4.它生成的可執行文件只有2671 KB，同時包含相同的兩個組件，基本上與我的當前版本具有相同的代碼。

我的確明白Delphi 2009完全是Unicode（這是我升級的主要原因），而且Unicode可能會導致大小增加一倍。但是這大約是5倍。

是否有一個原因，爲什麼我的可執行文件必須保持5倍大？還是有一些簡單的方法來減少可執行文件的大小？

請注意。有些人正在回答壓縮Delphi EXE的方法。這不是我想要做的。我試圖簡單地看看爲什麼要使用這麼多的空間來刪除可能沒有必要的內容。如果這樣做，如果需要，壓縮仍然可以在之後完成。

安裝完成後，可執行文件的大小無關緊要。它用於下載目的，並最大限度地減少要壓縮的服務器負載和下載時間。我更喜歡使用Inno Setup並在安裝例程本身內部壓縮程序。然後在安裝時將其擴展爲完整大小。這既可以防止可能的病毒檢測，也可以消除在內存中解壓程序所需的額外啓動時間。此外我代碼簽署我的可執行文件和我的安裝例程，並且一些壓縮技術與此不兼容。

有關壓縮的詳細信息，請參見StackOverflow的問題：Delphi EXE compressor?

ldsandon問我，我用什麼選項來提供，所以在這裏，他們是：

Compiling Options http://www.beholdgenealogy.com/img/compilingoptions.jpg

Linking Options http://www.beholdgenealogy.com/img/linkingoptions.jpg

來源

2010-07-07 lkessler

您目前使用哪個編譯器開關？那些影響代碼大小的是那些將調試信息或控制代碼添加到項目中的代碼。 – 2010-07-08 07:18:53

@splash：我的約20個單元中有大約400 KB的我自己的代碼。它們包括14個使用大約500 KB的dfm文件的表單。這不包括我使用的兩個組件中的代碼。 – lkessler 2010-07-08 18:29:57

@ldsandon：我想我正在使用「發佈」版本配置的所有默認設置。 – lkessler 2010-07-08 18:31:42

當移動f從德爾福7到德爾福2010年，我們的.exe的增長例如從16兆到35兆。

幾周前，我在Embarcadero論壇上問了一個類似於你的問題。（link）在我的OP中，我列出了一系列有關此主題的鏈接，您可能會發現有幫助。

我們嘗試使用UPX壓縮我們的.exe文件。讓它工作了幾個小時顯著降低了我們的.exe文件，但我們可能不會在生產中使用它的原因如下：

我們有相當多的.exe文件的，不希望等待1/2每個版本的一天。（這有可能是我們能找到一個非蠻力的參數設置UPX，這將減少這...）
雖然.exe文件的大小減小，我們可交付不是，因爲我們的安裝（毫不奇怪）無法從已壓縮的文件中擠出更多的壓縮數據......但它能夠將原始的16兆.exe降低到8兆。
我讀過一些報道，在某些時候（很少但從不），UPX exe會引發各種反病毒程序來報告包含病毒的應用程序。（我不記得日期，地點或我在哪裏看到這些信息的細節，所以我在這裏報告這件事有點不公平。）但是，我們對於冒這種可能性的風險如此不利，以至於UPX是假表...

的英巴卡迪諾論壇的鏈接還包括link另一個有關這個主題的SO線程。

對於我們在移植到Delphi 2010時發現的代碼膨脹，我仍然感到驚訝和失望。正如Nick所指出的，Unicode的2X是相當過分的。

但是，移動到D2010時，膨脹是一個相對較小的折衷，因爲IMO，D2010在許多其他方面是如此驚人的升級。但是，它確實意味着我們可能不得不移動到運送2張CD而不是一張。我不期待看到我們組織對此的反應......

來源

2010-07-08 02:18:18 RobertFrank

@ Tom1952：你不能壓縮兩次。因此，最好使用安裝程序進行壓縮以減少下載大小。我使用InnoSetup，它包含我的13.5 MB程序到一個只有4.5 MB的安裝包中。安裝程序運行時，會將程序解壓縮爲全尺寸，因此不會有任何可能的病毒檢測問題。 – lkessler 2010-07-08 03:50:00

@ Tom1952：感謝您提供關於Embarcadero論壇上類似問題的鏈接。這是一個非常有趣的討論（包括Peter Below的一些評論）。你提到的一點是關於大圖標。那麼，我確實在我的程序中添加了一些大型的Vista圖標，可以在這個大小上添加一個MB。也許你寫的程序可能會幫助我。 – lkessler 2010-07-08 03:53:52

@ Tom1952：我還沒有看到其他的SO問題。這是一個很好的想法，並鏈接到一些有用的實用程序。 – lkessler 2010-07-08 04:02:22

從Unicode中分出預期的2倍增加，並最終得到一個2.5X增加不明。考慮到你跳過了多少個版本，這是有道理的。自Delphi 4以來，很多已被添加到VCL和RTL中，並不是所有的東西都可以很容易地被智能連接出來，即使你從不使用它。取決於你使用的單位數量，你可能會帶來相當多的額外行李。

Allen Bauer和編譯團隊增加了a new feature into D2010 to help reduce this，但顯然他們小心謹慎地行事，並沒有在儘可能多的地方使用它。希望我們會在2011年和隨後的發佈中看到更多的信號減少。

來源

2010-07-07 23:10:30

+13

對於Unicode來說2X是相當大的。 – 2010-07-08 00:29:52

我知道。這比公平的少一點，因爲並不是應用程序中的所有內容都是字符串。但我的主要觀點是，它的很多來自標準庫變得更大。 – 2010-07-08 00:35:05

我的下一次重大升級將用於64位或跨平臺編譯，以先到者爲準。我希望我的可執行文件不會增長到30 MB。 – lkessler 2010-07-08 01:12:50

沒有看到「發佈」版本配置使用的實際設置，因此解釋了這種規模的增加需要大量的推測。

除了一些可能不太可能的因素導致大量增加被「拖入」的代碼即使未被使用，增加的幅度最容易通過包含調試信息來解釋。

我會檢查你的編譯器和鏈接器設置：

調試信息（編譯器設置）
TD32信息（鏈接）
遠程調試信息（鏈接）

比較這些設置在Delphi 2009項目中與Delphi 4中的等效項相同。

來源

2010-07-07 23:39:38 Deltics

謝謝@Deltics：我相信我正在使用所有默認的Delphi 2009「Release」設置。在Delphi 2009中，TD32的設置已被鏈接調試信息（請參閱：http://blogs.embarcadero.com/chrishesik/2009/09/15/34920/）取代，我將其作爲「False」。鏈接器中的遠程調試符號爲False。但是我確實有將Debug信息編譯爲True，將符號調試爲真和本地符號奇怪地與它們對立爲False。然後鏈接器輸出爲「生成DCU」和「詳細映射文件」。我可以和那些人一起玩，但是如果他們非常拯救我，我會感到驚訝。 – lkessler 2010-07-08 00:57:39

您可能會對調試信息可以產生多少差異感到驚訝。至少它是值得關閉和發現。另外，您是否正在使用MadExcept或任何可能將MAP文件嵌入到可執行文件中的類似實用程序？ – Deltics 2010-07-08 01:17:13

@Deltics：我確實使用EurekaLog進行跟蹤錯誤，但我關閉了其大部分選項（包括內存泄漏）。完全關閉EurekaLog只會將可執行文件減少90 KB。 – lkessler 2010-07-08 04:21:39

使用「UPX - 壓縮或擴展的可執行文件」 @http://upx.sourceforge.net

如果你去工具/配置工具，並進行設置，這樣，你可以壓縮你的工作可執行輕鬆通過IDE中的菜單項。

Configuration

來源

2010-07-08 06:22:44

IMO，你最好在以後的部署過程中離開UPX。即不要在IDE中打擾它，它只會減慢你的速度。等到你準備好部署，並在同一個作業（.bat文件，Visual Build Pro等）中進行你的編碼，本地化，建立設置等。 – 2010-07-08 12:35:39

我問的問題不是簡單地減小可執行文件的大小，但要確定任何無用的多餘大小，並找出爲什麼它在Delphi版本之間增長很多。爲了減少下載時間，我使用InnoSetup來創建一個壓縮的安裝文件。看到我對Tom1952的回答的評論。 – lkessler 2010-07-08 13:43:47

如果你不想使用exe文件壓縮，那麼你應該給StripReloc一試。

來源

2010-07-08 06:51:10 splash

但是你可以使用StripReloc和一個壓縮器。 – philnext 2010-07-08 13:39:41

查看我對Adam的回答的評論。 – lkessler 2010-07-08 13:54:35

stripreloc是好的（因爲它不是壓縮器），但它不能減小尺寸 – VibeeshanRC 2010-11-11 04:50:31

另一種方法是看看'什麼單位增加尺寸？'。

爲此，我使用集成在JCL/JVCL安裝的IDE中的JCL'Project Analyzer IDE'，它向您顯示所有具有相應大小的單元。您可以將其導出爲文本文件。如果您在2種環境中使用（D4 & D2009），您將獲得大量相關信息。

來源

2010-07-08 13:35:36 philnext

Thans @philnext。不幸的是，當我去一臺新機器時，我沒有重新安裝Delphi 4。我需要老版本的ElPack和TRichView來處理它，我記得他們當時是一個安裝bug的工具，所以它永遠不值得費心，尤其是因爲我的新代碼是Unicode，並且現在完全與Delphi 4不兼容。 – lkessler 2010-07-08 13:47:33

這實際上是一個非常好的方式來追捕那些討厭的16k PNG圖像，潛入形式爲3MB位圖。 – 2014-11-19 08:41:47

您較新的delphi中的標準單元可能包含更多的字符串和常量（如錯誤字符串），即使禁用調試信息也會包含這些字符串和常量。檢查你的用途。

除了不使用特定單元或從中刪除不需要的數據之外，沒有太多的細節。

（我的經驗與德爾福5）

來源

2010-07-08 16:07:56

我會加幾句話。只有鏈接器能夠遵循代碼層次結構，鏈接器才能刪除未使用的過程和函數。下面列出的鏈接器的夢魘列表：

消息驅動的代碼，這個不幸的消息是，這個代碼不能被任何刪除，這就是爲什麼德爾福空白項目規模的不斷從版本增長到版本。每個新的Windows消息（例如，只要我最近介紹了WM_TOUCH）都會創建無法刪除的過程調用層次結構（即使您根本沒有計劃使用Touch API）。這是因爲每個的情況下WM_：片段是鏈接器無法決定是否會使用的東西。代碼和數據結構從單元的開始結束，初始化，結束部分訪問。在這裏你有一些控制，刪除不必要的調用或對象創建。即使你創造需求對象，只有釋放他們在最後確定部分，請仔細

來源

2010-07-09 09:49:31 informin

1）你生成一個詳細的地圖文件，因爲您已設置「使用調試的DCU」它也將包含RTL/VCL單元的符號。如果異常處理系統使用它來生成調用堆棧等，則可以將其添加到可執行文件中。如果不以某種方式壓縮，它可能會使你的.exe文件的大小非常大。

2）使用debug dcus也會讓你的.exe稍微大些，因爲通常它們是在沒有優化和調試選項的情況下編譯的，而且它們也會讓你的代碼變慢。它們不應該用於發佈版本。

3）調試信息應該只添加到設備的debig信息，而不是可執行文件，儘管需要IIRC生成映射文件。

來源

2010-07-09 18:46:35

我已經做了一些測試，看看D2007和D2010之間的區別，因爲我們正在升級到D2010。我測試了一箇中等規模的管理GUI應用程序，大約有60個表單（帶有詳細表單，框架等的表格）。我們正在使用TMS組件+ Remobjects。

D2007：
「正常」的編譯：18.8MB
與調試DCU的：18.8MB（同樣大小！）

D2010
正常：23.9
調試DCU的：（！）48.8mb

因此，使用調試DCU雙打我們的exe文件大小...

測試與我們的業務服務（沒有什麼大的DFM的）：
D2007：12.3MB
D2010：17.1mb