首页 > 代码库 > 如何扩展Chromium各层的接口

如何扩展Chromium各层的接口

添加新功能时,可能需要增加各层的接口,接口如何加?必然需要向Chromium的原则看齐。

首先Chromium的模块设计遵循依赖倒置原则,上层模块依赖于低层模块,低层模块不会依赖上层模块的实现。

再者要区分增加接口的两种目的:
  1. 提供功能供外部使用 (一些以功能定义的接口属于这类,如WebView,NavigationState等 )。
  2. 允许将一些业务逻辑在外部实现 (命名中带有client,observer或delegate属于这类)。
除了命名上不同外,可以参考的实现方式也不同。

 1. 使用IPC Message Filter

  Chromium为了避免添加新功能时使得接口类”膨胀”,特别提供了一系列的Helper (Observers)。当需要实现新功能时,可以通过这些observers,过滤IPC消息,实现自己的功能。

如果新功能可以向外派发或接收IPC消息完成通知或回调功能,则优先使用IPC Filter的模式。

   Renderer进程中实现RenderViewObserver接口可以接收处理RenderView上的IPC消息。ChromeExtensionHelper是一个用来监控Frame加载及关闭的示例。

  如果有一部分代码在WebKit里,不要直接扩展WebViewClient, 可以定义一个新的接口给WebKit调用,然后在Render端的实现。可以参考WebAutoFillClient的实现。
                                        技术分享
  Browser进程中通过实现WebContentsObserver的方式过滤IPC消息。具体的做法可以参考TabHelper。

  WebKit模块等其它类消息
    可以通过实现BrowserMessageFilter接口,在RenderProcessHostImpl::CreateMessageFilters()再将其加入到Filter列表中(render_process_host_impl.cc)。

 如果一个功能需要处理不同的IPC消息,就不要放在render_messages_internal.h里了,应当放到独立的文件里,比如pepper_file_messages.h。
 详情请参考:How to add new features

2. 提供独立的接口

如果功能相对独立,则可以在模块中增加新的接口提供出去。如blink模块中的很多功能,下面是其中WebImageCache的类图: 
技术分享
如果需要外部实现某些业务逻辑,则可以使用观察者模式或者允许以继承的方式实现,对应提供一个注册接口或接口类(interface)。
比如blink::Prerender需要外部定义实现blink::WebPrerenderingSupport时才有功能,这个blink::WebPrerenderingSupport就是一个要求上层类实现的接口类:
               技术分享

这是一个命名比较奇特的例子。在命名上注意client/delegate表示对外部业务逻辑依赖较重,而observer则表示逻辑上不存在对外部业务的依赖,仅仅是通知。

3. 以独立的方式扩展既有接口

如果是对既有功能的直接扩展,且无法分离成新的接口,则可以尝试使用如下方法扩展:
  a. 继承旧的接口或使用装饰器、组合等模式扩展接口功能。
     如果接口本身没有定义上的兼容性需求,上层模块可以根据需要选择使用新旧接口,就可以使用这个方式。
     WebViewClient可以近似看作一个示例:
          技术分享
  b. 封装到旧的接口中 (如组合,Helper class等方式) 
      如果接口需要保持兼容性,接口的定义不能修改,只能改变其行为,就可以应用这种方式。变更对上层模块透明。     

4. 修改原有接口

最后才能选择修改原有接口,但不建议直接修改接口函数定义,而是以新增接口函数的方式来实现。
如果使用C++实现,还应当将实现文件独立出来。

转载请注明出处: http://blog.csdn.net/horkychen



如何扩展Chromium各层的接口