内容简介：Qt Creator 源码学习 09：IPlugin
上一章我们说到， PluginSpec
描述了插件的“元数据”。这些“元数据”是静态数据，读取自一个插件描述文件。而所有的 Qt Creator 插件，都要继承 IPlugin
类。
IPlugin
类是所有插件的基类，每个插件都必须继承这个抽象类，并实现其中的纯虚函数（这是一个 不恰当
的命名，原本类名的前缀 I
代表 interface，但随着版本的迭代，这个类已经变成一个抽象类而不是接口。像 C++ 这种语言，并不区分 class 与 interface，所以这样带有前缀的名字很容易被人弄混，这是我们自己应该避免的）。Qt Creator 的插件包含两部分：一个描述文件（这个我们之前已经详细介绍过了）和一个至少包含了 IPlugin
实现的库文件。在这个库文件中，插件实现的 IPlugin
类需要与描述文件中的 name
属性相匹配。这个实现需要使用标准的 Qt 插件系统暴露给外界，使用 Q_PLUGIN_METADATA
宏，并且给定 IID 为 org.qt-project.Qt.QtCreatorPlugin
。
Q_PLUGIN_METADATA
宏是 Qt 5.0 新引入的。Qt 5 与 Qt 4 的插件机制完全不同，所以，这里只简单介绍 Qt 5 的插件机制。这个宏用于声明插件的元数据。当实例化插件对象时，这些元数据会作为该对象的一部分。这个宏需要声明一个 IID 属性，用于标识对象实现的接口；还需要一个文件的引用，该文件包含了插件的元数据。任何一个 Qt 插件都需要在源代码中添加这么一个宏，并且只允许添加一个。例如：
class MyInstance : public QObject
{
Q_PLUGIN_METADATA(IID "org.qt-project.Qt.QDummyPlugin" FILE "mymetadata.json")
};
使用这个宏的类必须有无参数的构造函数。 FILE
是可选的，指向一个 JSON 文件。这个文件必须能够被构建系统找到。
在这里，Qt Creator 规定其插件的 IID 必须是 org.qt-project.Qt.QtCreatorPlugin
。而这个 IID 所代表的，就是这个 IPlugin
。
IPlugin
提供了一系列回调函数，用于插件加载到一定阶段时进行回调。下面我们按照插件加载的顺序介绍 IPlugin
提供的一些函数。
当插件描述文件读取、并且所有依赖都满足之后，插件将开始进行加载。这一步分为三个阶段：
- 所有插件的库文件按照依赖树从根到叶子的顺序进行加载。
-
按照依赖树从根到叶子的顺序依次调用每个插件的
IPlugin::initialize()函数。该函数的签名如下：
virtual bool initialize(const QStringList &arguments, QString *errorString) = 0;
这是一个纯虚函数，因此每个插件都必须实现这个函数。该函数会在插件加载完成，并且创建了插件对应的 IPlugin
对象之后调用。该函数返回值是 bool
类型，当插件初始化成功，返回 true
；否则，需要在 errorString
参数中设置人可读的错误信息。注意，该函数的调用顺序是依赖树从根到叶子，因此，所有依赖该插件的插件的 initialize()
函数，都会在该插件自己的 initialize()
函数之后被调用。如果插件需要共享一些对象，就应该将这些共享对象放在这个函数中。
3. 按照依赖树从叶子到根的顺序依次调用每个插件的 IPlugin::extensionsInitialized()
函数。该函数的签名如下：
virtual void extensionsInitialized() = 0;
注意，这也是一个纯虚函数。该函数会在 IPlugin::initialize()
调用完毕、并且自己所依赖插件的 IPlugin::initialize()
和 IPlugin::extensionsInitialized()
调用完毕之后被调用。在这个函数中，插件可以假设自己所依赖的插件已经成功加载并且正常运行。当运行到这一阶段时，插件所依赖的其它插件都已经初始化完毕。这暗示着，该插件所依赖的各个插件提供的可被共享的对象都已经创建完毕（这是在 IPlugin::initialize()
函数中完成的），可以正常使用了。
如果插件的库文件加载失败，或者插件初始化失败，所有依赖该插件的插件都会失败。
除了 IPlugin::initialize()
和 IPlugin::extensionsInitialized()
两个函数之外，另外一个与启动有关的函数是
virtual bool delayedInitialize() { return false; }
该函数会在 所有插件
的 IPlugin::extensionsInitialized()
函数调用完成、同时所依赖插件的 IPlugin::delayedInitialize()
函数也调用完成之后才被调用，也就是延迟初始化。插件的 IPlugin::delayedInitialize()
函数会在程序运行之后才被调用，并且距离程序启动有几个毫秒的间隔。为避免不必要的延迟，插件对该函数的实现应该尽快返回。该函数的意义在于，有些插件可能需要进行一些重要的启动工作；这些工作虽然不必在启动时直接完成，但也应该在程序启动之后的较短时间内完成。该函数默认返回 false
，即不需要延迟初始化。如果插件有这类需求，就可以重写这个函数。
说完了启动时可能用到的函数，接下来是关闭时会用到的函数：
virtual ShutdownFlag aboutToShutdown() { return SynchronousShutdown; }
aboutToShutdown()
函数会以插件初始化的相反顺序调用。该函数应该用于与其它插件断开连接、隐藏所有 UI、优化关闭操作。如果插件需要延迟真正的关闭，例如，需要等待外部进程执行完毕，以便自己完全关闭，则应该返回 IPlugin::AsynchronousShutdown
。这么做的话会进入主事件循环，等待所有返回了 IPlugin::AsynchronousShutdown
的插件都发出了 asynchronousShutdownFinished()
信号之后，再执行相关操作。该函数默认实现是不作任何操作，直接返回 IPlugin::SynchronousShutdown
，即不等待其它插件关闭。自然， IPlugin
有一个相关的信号：
signals: void asynchronousShutdownFinished();
前面已经多次提到了一个概念：可被共享的对象。插件之间的依赖容易解决。比如，插件 B 依赖于插件 A，那么，如果 B 成功加载，我们可以肯定，A 一定是存在的。那么，我们就可以在 B 中使用 A 提供的各个函数。这一点很好理解。但是，还有另外一种情况：插件 B 扩展插件 A 的功能。例如，不同的插件提供了打开不同文件的功能：插件 A 提供打开文本文件的功能；插件 B 提供打开二进制文件的功能。那么，当我们的程序启动时，程序怎么知道自己能打开哪些文件呢？因为在程序启动时，并不知道哪些插件是可用的。Qt Creator 提供了一个对象池。A 可以打开文本，B 可以打开二进制文件，那么，把能打开文件的类实例放到对象池里面。程序启动之后，自己去对象池找，看有哪些关于打开文件的对象，就知道自己能打开什么文件了。
对象池可以理解为一个全局变量，里面会有很多不同插件提供的对象，其它插件只需要从这里面找到自己需要的对象即可使用。这种设计避免了插件要暴露很多接口的情况。如果没有对象池，那么，上面所说的插件 A 和 B 就需要主动注册自己能够打开哪些文件，这就要求主程序提供类似的注册接口——进一步说，程序需要将所有可能被扩展的功能都提供注册接口，这无疑会引起接口“爆炸”。而对象池的设计恰恰避免了这一点。对象池很像一个 IoC 容器，有自己的“好莱坞原则”。
有三个函数与对象池有关：
void addObject(QObject *obj)
{
PluginManager::addObject(obj);
}
void addAutoReleasedObject(QObject *obj)
{
d->addedObjectsInReverseOrder.prepend(obj);
PluginManager::addObject(obj);
}
void removeObject(QObject *obj)
{
PluginManager::removeObject(obj);
}
IPlugin
将对象池操作委托给 PluginManager
类。
值得一说的是 addAutoReleasedObject()
函数。通常，被添加到对象池的对象必须要手动析构。这里， IPlugin
提供了一个 工具 函数，能够帮助自动释放某些对象，即这里的 auto-released 对象。我们可以在 Internal::IPluginPrivate
类中找到 addedObjectsInReverseOrder
的定义：
namespace Internal {
class IPluginPrivate
{
public:
PluginSpec *pluginSpec;
QList<QObject *> addedObjectsInReverseOrder;
};
} // namespace Internal
该属性为 QList
类型，使用 prepend()
函数，每次在列表头部添加对象。因此，这里实际保存的是被添加顺序的倒序，所以可以用于以相反的顺序析构被添加的对象。有关对象池的实现细节，我们会在后面的章节中详细介绍。
另外， IPlugin
还提供了相关联的 PluginSpec
实例的访问：
PluginSpec *IPlugin::pluginSpec() const
{
return d->pluginSpec;
}
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
