SWT 和 JFace 提供了幾個不同的類，幫助您在幾個緩存中管理 GDI 資源。 緩存往往比您想的更靈巧。如何以及何時使用緩存并不總是顯而易見的。 設(shè)計時應(yīng)該注意的幾個問題是：

    GDI 泄漏總是不可接受的，必須進行處理。
    處理完泄漏后，您應(yīng)該考慮下面兩個問題：
        應(yīng)用程序需要的總共的 GDI 資源數(shù)目。
        創(chuàng)建這些資源導(dǎo)致的開銷。

總共的 GDI 資源數(shù)目

您需要清醒地了解應(yīng)用程序所需要的總共的 GDI 資源數(shù)目， 以及有多少資源是副本。 副本相當重要，因為您只要有可能應(yīng)該共享 GDI 資源以便降低應(yīng)用程序使用的資源數(shù)目。 很容易創(chuàng)建副本，而且您可以都沒有意識到（我曾修改了 Sleak 工具使之發(fā)現(xiàn)副本， 并將此改變以及其他有用的改變添加到 Eclipse 中。）

創(chuàng)建 GDI 資源所需的開銷

一般而言，創(chuàng)建字體和圖像耗費的資源比創(chuàng)建顏色多。 根據(jù)應(yīng)用程序的不同，圖像的創(chuàng)建可能成為某些用戶動作的重大開銷。 如果遇到這種情況，您可以考慮使用一些 SWT/JFace 所提供的緩存。

如果可能，應(yīng)讓平臺來管理資源。當您 在平臺擴展中指定圖像或圖標屬性時 —— 比如視圖、動作等 —— 平臺負責(zé)保證資源被正確地創(chuàng)建和刪除。 好的代碼往往是您無需編寫并維護的代碼。 上述提示的合理推論是可能時使用當前平臺的字體和圖像以提高共享。

只要有可能，應(yīng)共享資源。為此，行之有效的方法是把資源集中到 一個公共包中。您可以將此視為重構(gòu)公共資源。

每個 UI 包都有一個與之相關(guān)的 ImageRegistry。 該注冊項可用于存儲常用圖像。這里的關(guān)鍵是常用。我曾見到過開發(fā)人員把所有的資源都 放到了這個注冊項內(nèi)，這并不合適。該注冊項維護著一個由名稱 > 圖像或名稱 > 圖像描述符構(gòu)成的映射。 圖像描述符是對圖像的輕量描述；它們并沒有與之相關(guān)的任何 GDI。 您可以用圖像描述符提前得到圖像注冊項，那么當 首次需要用到該圖像時，注冊項會為您創(chuàng)建它。

對于較為不常用的圖像，您可以自行創(chuàng)建或刪除之，此外您還可以使用 LocalResourceManager。其構(gòu)造函數(shù)的一種形式采用了小部件。 以此方式創(chuàng)建時，LocalResourceManager 會在銷毀小部件時清空 與之相關(guān)的資源。

偵聽器泄漏（Listener leaking）

偵聽器相關(guān)的泄漏是 UI 代碼常常出現(xiàn)的問題（請參閱 參考資料）。 偵聽器泄漏往往會浪費內(nèi)存和時間。當您向一個對象添加偵聽器時， 您是在小部件和偵聽器之間創(chuàng)建了一個直接的、牢固的關(guān)聯(lián)（參看圖 2）。只要小部件存在， 偵聽器及其引用的一切都會一直駐留在內(nèi)存中。 當小部件或它的父容器被關(guān)閉， SWT 刪除偵聽器，從而打破那個牢固的關(guān)聯(lián)。 我曾見過的很多代碼都說明了開發(fā)人員往往在這個問題上不甚清楚。

只要從中添加偵聽器的對象會及時刪除，您無需刪除 JFace/SWT 偵聽器。 關(guān)鍵是理解從中添加偵聽器的對象的生命周期。 不管什么時候要向某個對象中添加偵聽器，您都需要自問一下， 偵聽器被添加到哪個對象，偵聽器的生命期有多長。

舉例而言，假設(shè)應(yīng)用程序創(chuàng)建了一個視圖。該視圖包含一個按鈕。 在您構(gòu)建該視圖時，您為按鈕添加了一個選擇偵聽器，以便應(yīng)用程序能夠?qū)Π粹o單擊作出響應(yīng)。 您無需為刪除按鈕的偵聽器而對視圖添加一個刪除偵聽器， 您也無需為按鈕被撤銷時刪除按鈕的偵聽器而對按鈕再添加一個刪除偵聽器。 SWT 會在按鈕被撤銷時執(zhí)行對按鈕偵聽器的刪除。您不必寫這些冗余的代碼和管理多余的工作。

在 RCP 應(yīng)用程序中，經(jīng)常會有某人創(chuàng)建一個視圖并將其自身添加為 workbench 頁偵聽器。 Workbench 頁 往往很長壽，直到該應(yīng)用程序關(guān)閉，workbench 頁才會被關(guān)閉（從而清空偵聽器）。 在此情況下，您不應(yīng)該依賴 workbench 頁清空偵聽器關(guān)聯(lián)。您應(yīng)當在視圖被關(guān)閉時把該視圖作為偵聽器刪除。

我曾在一個聊天程序中看到過另一個受惑于對象生命周期的例子。 每當打開一個聊天窗口，都會向伙伴列表添加一個偵聽器。 聊天窗口永遠不刪除偵聽器，只要伙伴列表沒有被撤銷，不會有什么問題。 終結(jié)果是越來越多的偵聽器被添加到伙伴列表，而且它們永遠不會被刪除。 需要強調(diào)的是這不僅是內(nèi)存泄漏，也是對性能的破壞。 偵聽器泄漏的后果是，每個聊天窗口以及它所有可訪問的對象都駐留在內(nèi)存。 同時，每次當伙伴列表向列表內(nèi)的偵聽器發(fā)信號，都會浪費時間去通知那些本來已經(jīng)被關(guān)閉的聊天窗口。

還有一種常見的情形，是把偵聽器添加到偏好存儲以便您能夠在偏好改變時更新 UI。 我曾見過有開發(fā)人員在創(chuàng)建視圖或創(chuàng)建動作時添加偏好存儲偵聽器。 問題在于如果您不刪除偏好存儲偵聽器，您會導(dǎo)致偵聽器累積，因為 一般而言，偏好存儲只有在應(yīng)用程序關(guān)閉時才會被關(guān)閉。

動作是一個特殊的例子。動作并不真的有生命周期。 它們被創(chuàng)建后，即使被撤銷或不再使用，您也并沒有對它有什么控制能力。 這意味著當您創(chuàng)建一個動作時，您一般不應(yīng)該向其他對象添加偵聽器， 因為您并沒有好的方法以刪除那些偵聽器。

如何發(fā)現(xiàn)偵聽器泄漏
為發(fā)現(xiàn)偵聽器泄漏，我推薦兩個方法：

    審查代碼：我會搜尋應(yīng)用程序代碼中向?qū)ο筇砑觽陕犉鞯奈恢�，在那些位置上我認為 偵聽器的生存時間超過我的預(yù)期。對這些偵聽器列表后，我一般在運行時使用調(diào)試器 驗證我的假設(shè)。即使每個 addListener 都對應(yīng)有 removeListener 也并不代表沒有問題， 因為開發(fā)人員往往會犯一個錯誤，是把 removeListener 包含到某個方法中， 他們以為該方法會被調(diào)用而實際上卻沒有。

    使用剖析器或差異分析，按如下步驟：
        啟動應(yīng)用程序。
        預(yù)熱。
        得到一個內(nèi)存快照。
        做 5 次動作（打開聊天窗口、讀取郵件消息等）。
        得到一個內(nèi)存快照。
        分析應(yīng)用程序?qū)ο蟮膶嵗龜?shù)目。 如果有偵聽器泄漏的話，比如說，您可能會發(fā)現(xiàn)有多出的 5 個本不應(yīng)存在的偵聽器。

結(jié)束語

我希望本文能為您提供一些關(guān)于如何在不同構(gòu)建之間度量應(yīng)用程序中堆使用的想法， 還有幾個手工技術(shù)用于發(fā)現(xiàn)并處理不可避免的泄漏。 如果您還沒有做好準備，試著跟蹤應(yīng)用程序在構(gòu)建時耗費的資源量。 做了這些之后，您可以嘗試進行堆分析。 即便您一開始對于堆轉(zhuǎn)儲還做不了什么，在構(gòu)建時收集這些轉(zhuǎn)儲對于日后使用具有極大價值。 開始收集堆轉(zhuǎn)儲之后，您能夠?qū)τ驅(qū)ο笞霾町惙治觥�從小做起，當您熟悉這些技術(shù)后可以加入更多的分析。