在本文中，将讨论如下内容：
1、系统资源，为后面讨论图片资源做一铺垫
2、SWT中的图片资源管理
3、Display hook销毁机制，JFace中图片资源管理的重要基础
4、JFace中的ImageDescripTor
5、JFace中的图片资源管理（ImageRegistry）
6、JFace中图片资源管理ImageRegistry所适用的场景和使用规则
7、Eclipse中插件share images机制
8、在Eclipse插件开发或者开发RCP程序时，使用图片资源需要的注意事项
【系统资源】
众所周知，Java开发人员在使用SWT/JFACE的时候，并不能借助于Java内置的垃圾回收机制来彻底完成 系统资源的清理（Java虚拟机只能帮助我们释放虚拟机内存中的系统资源句柄引用对象）。在SWT中系统 资源对象的定级类型是org.eclipse.swt.graphics.Resource，在类型明确说明了“Resources created by the application must be disposed”，这也让我们想起了关于Image使用的一句名言“谁创建，谁负 责”，当然，这个原则也同样适用于其他类型的系统资源。
我们之所以如此关注系统资源的使用，尤其是臭名昭著的图片资源，主要是因为我们怕了系统资源泄 漏引起的系统crash的问题。例如org.eclipse.swt.SWTError: No more handles异常有可能在我们试图创 建图片资源的时候发生，这说明当前系统句柄已经不足，造成这个问题的罪魁祸首当然是我们写代码的人 。
【SWT中的图片资源管理】
我们直接看一下SWT中图片资源类型的定义（org.eclipse.swt.graphics.Image），在类型说明中明确 指出了：“Application code must explicitly invoke the Image.dispose() method to release the operating system resources managed by each instance when those instances are no longer required”。我们再看一下另外一个我们熟悉的类型org.eclipse.swt.graphics.ImageData，我们可以将 其看作是Image对应的元数据模型对象，描述了具体创建Image需要的信息。
通过上面的说明，我们发现SWT唯一告诉我们的是：自己创建的图片资源，自己负责去销毁，通过调用 Image.dispose()。那我们在使用SWT的时候，应该如何释放图片资源呢？
我们知道SWT的widget在销毁的时候，也会销毁子widget，所以，覆写你自己的Component对应的 dispose方法，将你使用的系统资源销毁。目前，也只能这样了~_~。如果觉得不满意，接着看下面的 Display hook销毁机制。
【Display hook销毁机制】
在Display device中，我们看了如下一个hook接口：
/** *Causestherun()methodoftherunnableto *beinvokedbytheuser-interfacethreadjustbeforethe *receiverisdisposed. */ public void disposeExec (Runnable runnable) { //注册用户自定义runnable，在display release的时候回调此runnable 将runnable注册到disposeList } disposeList中的线程会在display release的时候被调用，如下： /***Releasesanyinternalresourcesbacktotheoperating*systemandclearsallfieldsexceptthedevicehandle.*/ protected void release () { …… //会执行用户注册的销毁线程 if (disposeList != null) { for (int i=0; i<disposeList.length; i++) { if (disposeList [i] != null) disposeList [i].run (); } } …… }
看来，SWT并没有把事情做绝了，还是给开发者留下一条后路的。Display允许开发者注册一个自定义 线程hook到Display的release过程，开发者可以用如下方式来确保开发者使用的系统资源在Display release的时候被销毁：
display.disposeExec(new Runnable() { public void run() { //销毁系统资源的逻辑代码 image.dispose(); ……. } });
以上方式其实也是JFace中图片资源管理（ImageRegistry、ResourceManager）能够确保Display release的时候能够彻底释放被ImageRegistry托管的图片资源。
到这里回顾一下，SWT中资源释放的途径吧：
1、覆写相应Component对应的dispose方法。这有别于Display的hook机制，因为其能够在Display运行 期间（未被release之前）就释放掉系统资源，最好的方式。
2、利用Display的hook机制，确保在Display被release的时候能够销毁资源。注意，请不要过多依赖 此方式，因为很容易造成在Display被release之前，已经发生了系统crash的问题。
【JFace中图片资源管理－－ImageDescripTor】
前面我们已经见过SWT中的Image和ImageData类型了，在继续下面的内容之前，我们先看一下在JFace 中我们最常用来创建图片资源的一个工厂类：ImageDescripTor。在ImageDescripTor的类型说明中告诉我 们，有两种使用ImageDescripTor创建图片的方式，分别通过createImage和createResource接口， “There are two ways to get an Image from an ImageDescripTor. The method createImage will always return a new Image which must be disposed by the caller. Alternatively, createResource() returns a shared Image. When the caller is done with an image obtained from createResource, they must call destroyResource() rather than disposing the Image directly.” 。分析如下：
首先看一下createResource方式，ImageDescripTor是一种DeviceResourceDescripTor，后者的对外操 作如下：
/** *CreatestheresourcedescribedbythisdescripTor */ public abstract Object createResource(Device device) throws DeviceResourceException; /** *Undoeseverythingthatwasdonebyapreviouscalltocreate(...) */ public abstract void destroyResource(Object previouslyCreatedObject);
这也就是说，ImageDescripTor提供了createResource / destroyResource接口来负责创建和销毁 Image资源。请注意这边的一点，在孤立使用ImageDescripTor（没有配合ResourceRegistry使用，例如 ImageRegistry）的时候，用户还是要负责通过调用destroyResource来释放创建的资源。
其次来看一下createImage的方式：
/***The returnedimagemustbeexplicitlydisposedusingtheimage'sdispose call.Theimagewillnotbeautomaticallygarbagecollected. */ public Image createImage(boolean returnMissingImageOnError, Device device) {}
这也就是说，ImageDescripTor提供的createImage的方式，也需要用户来显示的销毁资源。那 createImage和createResource两种方式之间的差别是什么呢？稍微分析一下ImageDescripTor的这两种创 建方式的实现，我们就可以看出来差别：
1、createImage每次都创建一个全新的图片资源（图片资源的创建是很耗时的~_~）
2、createResource的方式采用了缓存的方式复用已经创建过的资源，并不是每次都创建一个全新的资 源。这一点虽然带来了性能的提高，但是并没有解决图片资源释放的问题，倒是给开发者留下了一种假象 ，造成了随便使用ImageDescripTor的问题，反而造成了大量的图片资源（当然，更多的是由于调用 createImage的方式造成的，因为每次都创建一个全新的图片资源）没有释放。
到现在为止，我们看到JFace已经对SWT中的图片资源的管理做了一个小的补充：提供了 ImageDescripTor.createResource的方式，可以利用缓存效果，能够减少不必要的图片系统资源创建，而 且效率有所提高。关于如何释放，可以参考SWT中覆写Component.dispose的方式，例如在label provider 使用的图片资源，可以覆写对于provider的dispose方法，JFace框架会自动调用。
【JFace中图片 资源管理－－ImageRegistry & ResourceManager】
下面，我们接着看一下JFace中的 ImageRegistry的实现原理。
首先我们看一下JFace中的资源管理门面类（façade class） JFaceResources，我们由它来获取我们的JFace ImageRegistry：
public static ImageRegistry getImageRegistry() { if (imageRegistry == null) {imageRegistry = new ImageRegistry(getResources(Display.getCurrent())); } return imageRegistry;}public static ResourceManager getResources(final Display toQuery) { ResourceManager reg = (ResourceManager)registries.get(toQuery); if (reg == null) { final DeviceResourceManager mgr = new DeviceResourceManager (toQuery); //向Display hook了销毁线程toQuery.disposeExec(new Runnable() { public void run() { mgr.dispose(); registries.remove(toQuery); }}); } return reg;}
分析了一下ResourceManager（DeviceResourceManager）的实现，我们发现 ：DeviceResourceManager就是对DeviceResourceDescripTor（ImageDescripTor）进行了引用计数管理。 通过JFaceResources.getResources利用了前面说的Display的hook销毁机制（注意，如果不通过 JFaceResources.getResources来获取ResourceManager，则不会默认享受Display的hook销毁机制，需要 自己向Display注册），确保由被托管ImageDescripTor创建的残留在系统中的图片资源在Display release的时候会被彻底销毁。核心方法如下：
create(DeviceResourceDescripTor descripTor)
//如果是首次注册，创建引用技数，allocate资源并对资源进行缓存
//如果是已经注册，增加引用技数，直接返回缓存的系统资源
destroy(DeviceResourceDescripTor descripTor) //将
//如果引用技术==1，通过调用deallocate彻底销毁资源
//如果引用技术>1，削减引用计数（系统资源不会被销毁）
那就是说，如果一个ImageDescripTor被ResourceManager托管了，那由它创建的资源（注意：通过 ImageDescripTor.createResource的方式）由两种销毁的途径：
1、如果不通过JFaceResources.getResources的方式，单独使用ResourceManager，则只能利用 ResourceManager的引用计数管理来销毁资源（引用计数为0时），通过显示调用 ResourceManager.destroy来削减引用计数。
2、如果通过JFaceResources.getResources来使用ResourceManager，则除了能够使用到引用计数管理 资源，同时也默认使用了Display的hook销毁机制，JFace的ImageRegistry也很好的利用了这一点。
现在回头看一下ImageRegistry提供的核心操作，着重分析一下ImageRegistry在利用了 ResourceManager对ImageDescripTor进行管理的基础上，做了那些补充：
put(String key, Image image) //注册imageput(String key, ImageDescripTor descripTor) //注册descripTorImage get(String key) //获取imgeImageDescripTor getDescripTor(String key) //获取descripTorremove(String key) //取消注册dipose() //销毁资源
通过对ImageRegistry简要的分析之后，我们的结论如下：
1、如果以put(String key, ImageDescripTor descripTor)的方式注册，ImageRegistry直接讲 descripTor委托给ResourceManager委托管理，自己并不承担管理任务。而且，ImageRegistry对这种方式 注册的ImageDescripTor所创建的系统图片资源的销毁也委托给ResourceManager进行，并不是在以上自己 的dispose方法中进行，而是在ResourceManager.dispose方法中进行。
2、如果以put(String key, Image image)的方式注册，ImageRegistry做了部分的补充管理，其将 image包装进自己的OriginalImageDescripTor（ImageRegistry的一个内部类，继承自ImageDescripTor， 对图片资源本身增加引用计数）实现中，并对image本身进行了引用计数管理。同时，对这种方式注册的 图片资源的销毁是ImageRegistry自己承担的，在自身的dispose方法中完成。（注意，在ImageRegistry 的构造方法中，将ImageRegistry.dispose封装为一个runnable注册到了ResourceManage的dispose过程中 ，而ResourceManage.dispose已经在JFaceResources.getResources方法中被hook到了Display的资源销毁 过程中）。
3、通过1和2的结论，JFace ImageRegistry对系统资源的销毁已经做了两手准备，
其并不希望用户自己来销毁资源（无论是通过Image.dispose还是ImageDescripTor.desToryResource ，或者ImageRegistry.dispose），当然，ImageRegistry允许通过remove接口来取消注册。
JFaceResources
＋提供hook机制
ImageRegistry
＋自己管理部分资源
ResourceManager
＋管理ImageDescripTor及其创建的资源
【ImageRegistry的适用场景和使用规则】
通过上面的实现原理分析，我们知道ImageRegistry并不欢迎用户来过多地参与图片资源的释放过程， 所以ImageRegistry适用于如下场景：
1、决定共享和高度复用的图片资源。这种资源一般是被使用的特别频繁，同时，不急于销毁，只要在 Display release的时候销毁掉就可以了，所以既可以利用到图片资源本身缓存的优势（减少物理创建的 次数），又可以利用其Display的hook销毁机制，确保会被销毁。
2、用户可以直接使用ImageRegistry（不通过JFaceResources.getImageRegistry的方式使用），复用 部分ImageRegistry的管理功能，开发自己的缓存策略，但是，要确保自己会在合适的地方调用 ImageRegistry.dispose方法来销毁registry。Eclipse Workbench中的shared images机制就用了这一点 。
ImageRegistry的使用规则如下：
1、谁创建，谁负责。具体图片资源的创建是由ImageRegistry负责的，用户既然托管了，就不应该再 干预资源的释放。而且，注册进ImageRegistry的资源是共享的，一个用户释放了，会影响到其他用户的 使用。当然，对于比较熟悉JFace ImageRegistry原理的开发者，可以参与到引用计数的管理，通过这种 方式，以安全的、不影响其他用户使用的方式来间接参与释放的过程。
2、非共享图片资源请不要交由ImageRegistry托管。对于一个仅限于局部使用而且使用并不是十分频 繁的图片资源，这样做不会带来什么好处，而且，尤其是对于不能参与到引用计数管理的初级用户，这样 做反而会使得一个本可以马上释放的图片资源反而会一直占用，直到Display release的时候才销毁。
3、要投入精力对ImageRegistry的key值进行管理，否则，会引起混乱。因为ImageRegistry本质上可 以看作Eclipse平台中的一个全局对象，对其含有的key列表的管理是再所难免。
【Eclipse中插件share images机制】
在Eclipse，一个插件可以暴露（expose）自己的图片资源，以便提供给需要的插件使用，我们就称它 为插件之间的share images机制吧。上面提到过了，这其实是部分复用了JFace ImageRegistry的管理机 制。
如何共享（可以参照Workbench插件的share images实现）：
1、按照默认约定，创建一个ISharedImages接口，提供有意义key值
2、实现自己创建的ISharedImages接口，并结合ImageRegistry来管理图片资源；并提供显示的dipose 公共接口，负责释放自己管理的图片资源
3、在自己的插件中暴露ISharedImages
4、在合适时机，调用ISharedImages.dispose来释放资源。这个时机一般选择在Plugin stop的时候比 较合适，当然，也可以选择在其他时机。
如何使用：
1、获取目标插件的ISharedImages实现，并通过ISharedImages提供的key值来获取特定的图片资源。 以workbench插件share images为例：
PlatformUI.getWorkbench().getSharedImages().getImage(key)
2、暴露图片资源的插件负责图片资源的创建和销毁，其他插件不要参与销毁过程。换句话说，还是要 遵守谁创建、谁负责的原则。以workbench插件share images为例：
在workbench close的时候，会间接调用ISharedImages.dispose()。
【Eclipse中使用图片资源的经验总结】
1、坚持“谁创建，谁负责”的原则。分为如下：
a) 如果是用户自己创建的，请自己释放。例如通过覆写Component对于的dispose方法、通过覆写 label provider对应的dispose方法等等，这对于一些适用于局部的图片资源较为适合；当然，也可以变 态利用Display的hook释放机制（但是，一般对于长期使用的资源才会这样做！！！）。
b) 如果是通过JFaceResources.getImageRegistry的方式使用ImageRegistry时，请不要释放资源， 让ImageRegistry自己解决。一般使用于比较频繁使用的全局共享图片资源，例如想保持风格统一的图片 资源等。
c) 如果是使用了IShareImages的机制，请提供图片资源的插件自己负责释放。如何使用这种机制， 最好参照eclipse中已有的实现，保持风格统一，“有样学样”吧。
2、正确认识系统资源泄漏引起的crash问题的原因。导致原因有两种：
a) 首先，是没有释放，导致泄漏。请参照上面的“谁创建，谁负责”的原则。
b) 其次，是释放的过晚，导致积累过多。例如本来应该立即释放的资源，反而通过ImageRegistry进 行了托管，同时有没有控制引用计数的管理，导致到了Display release的时候才释放资源。同样道理， 本来不需要暴露给其他插件贡献的图片资源，反而暴露了，导致释放过完等。
3、正确认识系统资源的创建和销毁所带来的时间消耗，这是从系统性能的角度考虑。例如，可以用 ImageDescripTor.createResource的方式替换原始的new Image的方式，减少创建资源过于频繁和销毁资 源过于频繁所带来的时间占用。对于需要长期使用的贡献资源，可以使用ImageRegistry的方式等等。
4、对于特殊的场景，可以在参考以上原理（例如JFace中的图片管理的实现原理分析）的基础上自己 实现图片资源的管理策略。这对团队开发产品的情况下尤其适用，一方面可以优化管理策略，使之更切近 团队应用；再者，可以减少JFace ImageRegsitry使用的复杂度，并减少误用。例如，我们可以把插件间 share images的机制看成是对JFace ImageRegsitry的灵活使用。
5、无论使用那种管理策略（无论是来自eclipse还是其他），使用这前一定要仔细看API说明，并简要 分析一下实现原理。对于做上规模的插件产品/应用来讲，毕竟对图片这种系统资源的管理太重要了！！ ！对于做较为简单的开发，基本上本着“谁创建、谁负责”的原则，用完之后在自己感觉合适的地方销毁 掉就可以了，完全可以不去碰JFace中的ImageRegistry那套东东，引来不必要的负责度和复用，尤其是对 于新手来说。
PS：文章是昨天赶出来的，没有细看。有什么错误之处，欢迎大家指出~_~
观今宜鉴古，无古不成今。
