怎样扩展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的实现。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvSG9ya3lDaGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

Browser进程中通过实现WebContentsObserver的方式过滤IPC消息。

详细的做法能够參考TabHelper。

WebKit模块等其他类消息

能够通过实现BrowserMessageFilter接口，在RenderProcessHostImpl::CreateMessageFilters()再将其加入到Filter列表中(render_process_host_impl.cc)。

假设一个功能须要处理不同的IPC消息。就不要放在render_messages.h里了，应当放到独立的文件中。比方pepper_messages.h。

详情请參考:How to add new features

2. 提供独立的接口

假设功能相对独立，则能够在模块中添加新的接口提供出去。如blink模块中的非常多功能，以下是当中WebImageCache的类图:

假设须要外部实现某些业务逻辑，则能够使用观察者模式或者同意以继承的方式实现，相应提供一个注冊接口或接口类(interface)。

比方blink::Prerender须要外部定义实现blink::WebPrerenderingSupport时才有功能，这个blink::WebPrerenderingSupport就是一个要求上层类实现的接口类:

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvSG9ya3lDaGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

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

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

假设是对既有功能的直接扩展，且无法分离成新的接口，则能够尝试使用例如以下方法扩展:

a. 继承旧的接口或使用装饰器、组合等模式扩展接口功能。

假设接口本身未定义上的兼容性需求，上层模块能够依据须要选择使用新旧接口。就能够使用这个方式。

WebViewClient能够近似看作一个演示样例：

b. 封装到旧的接口中 (如组合，Helper class等方式)

假设接口须要保持兼容性，接口的定义不能改动，只能改变其行为，就能够应用这样的方式。变更对上层模块透明。

4. 改动原有接口

最后才干选择改动原有接口，但不建议直接改动接口函数定义，而是以新增接口函数的方式来实现。

假设使用C++实现，还应当将实现文件独立出来。

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