谈谈模块的delay load

DLL的delay load,即延迟加载,是一项提高程序启动速度,减少进程地址空间的重要技术,用通俗一点的话来讲,就是对模块“呼之即来,挥之即去”的能力。很多程序缺乏这种灵活性,从而导致软件在第一次启动时需要加载所有可能需要的模块,严重影响了启动速度。狭义的delay load,是微软提供的一项技术,让模块在其symbol第一次被引用到时才被加载。但在广义上,我们其实有不少其他技术来实现这种“需要时才加载”的灵活性。

一、插件机制

软件定义好一些预设的接口,插件按要求在自己的模块中实现这些接口,然后通过一些配置文件,或者注册表信息,软件可以动态的加载该插件,并调用相关初始化代码实现“对接”。
相信熟悉编写VS插件的同学对此不会陌生,VS预定义了IDTExtensibility2,IDTCommandTarget供插件实现,插件的一些信息则存在一个.addin文件中,你需要在该配置文件中说明“该插件的实现模块”,“是否在VS启动时加载还是按需加载”等信息,然后当VS启动或者你激活了该插件中的某个命令时,VS的插件机制代码会加载该插件,实例化实现了接口的AddIn类,并调用其初始化代码 --- 插入完成。目前,很多主流的软件都支持这种插件机制。

另外一个比较简单但是明了的例子,在这两篇文章中有不错的讲解:C语言的插件机制(上)C语言的插件机制(下)

二、COM组件

感觉蛮多人对微软的COM技术颇有微词的。但是不论从COM的成绩,还是COM的思想上来看,其都是相当优秀的。

  1. COM是微软操作系统的基石,而且我们使用的很多组件,都是COM形式提供的(XML, DirectX...),各种大型桌面软件,都是以COM的形式暴露其编程接口便于二次开发(Office, VS, AutoCAD, Inventor...)
  2. COM规范对接口对象的强调与支持,在“面向对象编程范式”的道路上相比于C++更进了一步。孟岩在这片文章的谈到了这一点,感觉挺认同的。
有人说COM会影响速度,但是在C++层面,其实是通过vtable调用,不见得会慢多少(不敢确定,没有profile过);也有人说是因为COM的全局共享特点,会导致组件版本升级时不兼容,但其实微软早提供了registry-free的COM机制来解决这一问题。所以我怀疑很多人反对的原因多是因为不了解COM,而不了解COM的原因在太难,用起来比较复杂 --- 的确,我用了COM多年,也不敢说对其原理“很熟”。

说了不少题外话来帮COM正名:), 其实这里要提到的是,COM机制对模块的自动加载与卸载的能力, 又是其一大优点。当我们创建一个COM对象时,该对象所在的DLL(甚至exe)会被自动加载,全部使用完了,又可以帮你自动卸载,而你所要做的就是操作interface完成你要完成的事,完全不用操心加载卸载 --- 要多贴心就有多贴心。

也就是说,使用COM,你就使用了delay load!!!

三、LoadLibrary & GetProcAddress

当你决定使用这种方法时,你要意识到:

  1. 你必须自己LoadLibrary和FreeLibrary来管理模块,而且他们调用的次数必须相等 
  2. 这种方法只能调用导出的函数 ,类不行,数据也不行
  3. 为了调用某个函数,你需要:LoadLibrary - 定义函数原型 - GetProcAddress得到函数指针 - 调用, 如果说函数很多,你会很累
  4. 如果我修改了被调模块中某个函数的原型,你只能在运行时发现这个错误,所以维护起来不太容易
所以,一般情况下,这种方法是不建议使用的,但以下两种情况可以考虑使用:
  1. 需要调用的函数非常少,而且调完就“跑”,这样可以用一个函数封装一下,用RAII来加载与卸载DLL
  2. Hack,你没有源代码 ,通过查看该DLL的符号导出表,你强制调用其内部函数以达到你“不可见人”的目的:),产品代码中不建议使用。

四、Delay Load机制 

由于上面这种方式的种种不便,MS提供了一种相当聪明的机制,来帮我做掉那一系列的“维护”工作,而对你来讲,就只是简单的链接该DLL,并声明其为delay load就ok了。以下两个文件是其实现:

..\Microsoft Visual Studio 9.0\VC\include\delayhlp.cpp

..\Microsoft Visual Studio 9.0\VC\include\ delayimp.h

对于其工作原理,这篇文章有不错的解释。
可以看到,在我们第一次调用到该DLL中的代码时,该机制会帮助我们调用LoadLibrary完成加载。同时,你也可以unload一个被delay load的DLL,但需要使用/delay:unload设置和__FUnloadDelayLoadedDLL2函数,这里有详细介绍。 遗憾的是,用delay load机制调用起来的DLL,在主调模块退出时,其并不会被自动释放 - 不清楚MS没有做到这一步的原因,但做不到这一步始终是个问题,尤其当主调模块是一个COM组件时。结合上面提到的unload的方法和delayload机制提供的事件,我们可以自己实现一套方法来完成:在每个主调模块中声明一个静态对象,该对象为维护一个HMODULE链表,每load一个delay load的DLL就加入该链表,该对象析构时,unload链表中的所有模块。

 

以上几种delay load的机制,说到底都是对如何load以及如何获得类型信息以调用的权衡:

插件机制通过配置文件指定DLL,由插件框架读取并加载,调用是通过一系列预先设定的接口进行的。

COM机制通过注册表或配置文件指定DLL,由COM runtime加载,调用则是通过类型库tlb提供接口信息。

LoadLibrary和GetProcAddress显示指定加载DLL, 调用则是查看目标DLL的导出函数,定义相应函数指针类型

Delay load机制加载由dependency关系得到该DLL位置,由delay load机制实现加载,调用则是通过传统的链接关系,包含头文件实现。 

posted @ 2010-11-07 20:33  lzprgmr  阅读(3435)  评论(2编辑  收藏  举报

黄将军