33558 www.Sina.com/ctkpluginframework技术是面向c的动态模型系统。 该系统可以实现插件之间的松耦合，为功能和数据的交换提供了合适的方法。 此外，插件没有预先限制，因此可以很容易地将插件的相关部分嵌入现有工具包中。“
体系结构ctk插件框架的设计受到了OSGI(Java动态组件系统)的很大启发，提供了可以用(动态)许多不同的、可复用的)组件构成APP演示的开发模型。 该模型允许组件之间通过唯一的对象——服务进行通信。
的层次模型。 如下图所示。
Plugins (插件)开发人员创建的CTK组件；
服务层：通过为C对象提供publish-find-bind模型，动态连接插件；
用于安装、启动、停止、更新和卸载生命周期层(Life Cycle Layer )插件的API；
安全(安全) (安全处理) )目前不可用。
插件插件是ctk插件框架的核心，模块化特性在这一层得到了很好的实现。 那么，到底什么是Plugin呢？
plugin :一种基于c/Qt的共享库，包含资源文件和元数据(metadata )。
元数据的目的是正确地描述Plugin的特征，除了CTK Plugin Framework适当地对Plugin进行各种各样的处理(例如，依赖分析)之外，还可以更好地识别Plugin，使得用户能够理解Plugin
元数据在MANIFEST.MF文件中定义，典型的MANIFEST.MF文件如下所示：
插件同步名称： helloctkplugin-activation policy : eager plugin-category 3360 demos plugin-contact address 33603330 3333333333333333333331 n fqdyl-description 3360 apluginforsayhelloplugin-name : helloctkplugin-vendor 3: fqdyl-version :1
插件标识符(必需) :唯一标识插件，由插件通用名称表示。
可读信息：使您能够更好地理解和使用Plugin，而不影响模块化特性。
对于插件名称、插件厂商等选项信息，ctk插件框架可能会忽略这些内容。
服务层服务可视为服务提供商与用户之间的一个协议，用户一般不考虑其实现细节，满足该协议(服务应当提供什么功能、应该满足什么格式)。 使用服务的过程还包括服务发现和共识的形式，即需要通过服务的特征特征来找到相应的服务。
插件可以创建对象并使用CTK Service Registry在一个或多个接口(通常只有纯虚拟方法的c类)中注册这些对象。 其他插件可以请求registry列出在特定接口中注册的所有服务(对象)。 插件还可以等待特定服务出现并接收回复。
因此，插件可以注册服务、获取服务或监视服务的出现和消失。 可以有任意数量的插件在同一界面中注册服务，任意数量的插件可以获得相同的服务，如下图(publish-find-bind模型)所示。
如果多个插件在同一界面下注册了对象，则可以通过它们的属性进行区分。 每个服务注册都有标准的自定义属性，您可以使用筛选器选择感兴趣的服务。 属性也可用于APP级别的其他角色。
要使发布服务的其他Plugin能够发现此服务，必须在上下文中注册服务。 需要接口名称、服务对象(接口的具体实现)和可选ctkDictionary类型的属性信息。
ctkDictionaryproperties； properties.insert('name '，' xrpdxte )； Properties.insert('age '，18 )； ckserviceregistrationregistration=上下文注册服务(newhelloimpl )，properties )； 这将生成ctkServiceRegistration对象，并允许您更新服务属性。
registration.setproperties；
也可以直接把这个服务移除：
registration.unregister();注意：这个 registration 对象不能和其他 Plugin 共享，因为它和发布服务的 Plugin 的生命周期相互依存。也就是说，如果这个 Plugin 已经不存在于框架执行环境中，那么这个对象也不应该存在了—— “皮之不存，毛将焉附”。
此外，如果在删除发布的服务之前 Plugin 停止了，框架会帮助你删除这些服务。
获取服务一旦服务被发布，它将对其他 Plugin 可用。获取服务的方式非常简单，只需要提供一个接口名即可：
ctkServiceReference reference = context->getServiceReference<HelloService>();注意：这里的 reference 是服务对象的间接引用，可为什么要用间接引用而不直接返回实际的服务对象呢？
实际上，这是为了将服务的使用和服务的实现进行解耦。将服务注册表作为两者的中间人，不仅能够达到跟踪和控制服务的目的，同时还可以在服务消失以后通知使用者。
这个方法的返回类型是 ctkServiceReference，它可以在 Plugin 之间互享，因为它和使用服务的 Plugin 的生命周期无关。
生命周期层生命周期层主要用于控制 Plugin 的安装、启动、停止、更新和卸载，它可以让我们从外部管理应用或者建立能够自我管理的应用（或将两者相结合），并且给了应用本身很大的动态性。
前面已经了解了 Plugin 的概念和作用，但要真正使用 Plugin，则需要使用生命周期层的 API 来和 CTK Plugin Framework 的生命周期层进行交互。
下图为 Plugin 生命周期的状态转换图：
生命周期层的 API 主要由三个核心部分组成：ctkPluginActivator、ctkPluginContext 和 ctkPlugin。
ctkPluginActivatorctkPluginActivator：自定义 plugin 的启动和停止。
ctkPluginActivator 是一个接口，必须由框架中的每个插件实现。框架可以根据需要创建一个插件的 ctkPluginActivator 实例。如果一个实例的 ctkPluginActivator::start() 方法成功执行，则需要保证在插件停止时调用同一个实例的 ctkPluginActivator::stop() 方法。
ctkPluginContextctkPluginContext：一个 plugin 在框架内的执行上下文，该上下文用于授予对其他方法的访问，以便该插件可以与框架交互。
ctkPluginContext 提供的方法允许插件：
订阅由框架发布的事件；
使用 Framework Service Registry 注册服务对象；
从 Framework Service Registry 检索 ServiceReferences；
为引用的服务获取和发布服务对象；
在框架中安装新的插件；
获取框架中安装的插件列表；
获得一个插件的 ctkPlugin 对象；
为（由框架为插件提供的）持久存储区域中为文件创建 QFile 对象。
当使用 ctkPluginActivator::start() 方法启动时，将创建一个 ctkPluginContext 对象，并将其提供给与此上下文关联的插件。当使用 ctkPluginActivator::stop() 方法停止时，相同的 ctkPluginContext 对象将被传递给与此上下文关联的插件。ctkPluginContext 对象通常用于其关联插件的私有用途，并不意味着与插件环境中的其他插件共享。
与 ctkPluginContext 对象关联的 ctkPlugin 对象称为上下文插件。
ctkPluginContext 对象只有在它的上下文插件执行时才有效；也就是说，在上下文插件处于 STARTING、STOPPING、和 ACTIVE 状态的时段内。如果随后使用 ctkPluginContext 对象，则必须抛出一个 ctkIllegalStateException 异常。当上下文插件停止后，ctkPluginContext 对象不能被重用。
Framework 是唯一能够创建 ctkPluginContext 对象的实体，并且这些对象仅在创建它们的 Framework 中有效。
ctkPluginctkPlugin：Framework 中已安装的插件。
ctkPlugin 对象是定义一个已安装插件的生命周期的访问点，在插件环境中安装的每个插件都必须有一个相关的 ctkPlugin 对象。此外，插件必须有一个唯一的标识，在插件的生命周期中，这个标识不能改变（即使是在插件更新时），卸载和重新安装插件必须创建一个新的唯一标识。
插件有以下状态（状态是动态可变的，这些状态在特定条件下可以互相转换，见上图）：
UNINSTALLED
INSTALLED
RESOLVED
STARTING
STOPPING
ACTIVE
要确定插件是否处于有效状态之一，可以使用 States 类型进行“或”运算。
插件只能在状态为 STARTING、ACTIVE 或 STOPPING 状态时执行代码。一个 UNINSTALLED 插件不能被设置为另一个状态，它是一个“僵尸”。
Framework 是唯一允许创建 ctkPlugin 对象的实体，并且这些对象仅在创建它们的 Framework 内有效。