WebKit最神奇的一點是JS能調到內核部分（c/c++），這是WebOS向外提供擴展能力的關鍵（實現或擴展W3C API）。要搞清楚一個JS的方法是如何調到後面c/c++的實現頗費周折，其實就是要把IDL和Bindings弄懂，先解釋一下這兩個名詞：
- IDL：接口定義語言，詳細解釋可見http://trac.webkit.org/wiki/WebKitIDL
- Bindings：WebKit動態生成與其他框架（如JavascriptCore, V8）整合的代碼
document.getElementById('domId')
WebKit知道document，也知道getElementById該做什麼事兒，但它不認識getElementById這個函數，不具備script解析和執行的能力，因此它需要第三方的解析器來幫助，這也就是JavascriptCore（JSCore）或V8需要乾的事兒。但JavascriptCore或V8很薄，能解析和執行javascript語言本身，不知道getElementById的具體實現，所以需要WebKit把具體實現注入進來，好了，說到這裏大家就大概明白爲啥需要IDL和Bindings了，其實就是爲了提供一個標準的方式（IDL），讓WebKit把JS API背後的實現注入給javascript解析器，另外，各個解析器的具體註冊和執行機制是不同的，所以需要有Bindings來動態生成與各個解析器結合的部分，這樣同一套標準的WebKit就能與各種解析器整合了。說了半天，看個圖就清楚了：
其中，V8/JSCore Bindings中包含的是基於IDL規範爲各個JS實現動態生成的產物，這些產物是會註冊到各個DOM上，並能被V8/JSCore識別，所以以v8上的document.getElementById爲例，調用流程如下：
- 編譯的時候，基於Document.idl爲Document.cpp和Document.h動態生成V8Document.cpp和V8Document.h(後面會講到動態生成這部分邏輯)
- V8Document.cpp和V8Document.h其實就是包含兩樣東西，一是對Document.cpp和Document.h各個方法的代理，二是js API和各個實現方法的對照表
- WebKit把V8Document中對照表註冊到document這個dom中
- WebKit中執行腳本document.getElementById
- WebKit按照最新的document的dom結構初始化V8的context
- V8解析和執行document.getElementById
- V8根據對照表執行getElementById方法對應的V8Document.cpp中的實現
- V8Document.cpp代理Document.cpp相應的實現
以上流程中的關鍵有兩點，一是動態生成bindings這塊，另外是如何註冊和執行bindings，後面這一點由於c/c++功力有限，沒完全看懂，留到後面再仔細琢磨，前面這一點是WebKit強大的編譯體系中的一部分，下面詳細解釋一下。
先抽出各個不同編譯平臺的差異點，WebKit就是通過WebCore/bindings/scripts/中的generate-bindings.pl perl腳本生成bindings中的代碼，它在Android平臺上會被Android.derived.v8bindings.mk調用到，在mac上被DerivedSources.make調用到，其大體流程是非常清晰的：
- 解析IDL
- 調用各個平臺相應的CodeGenerate腳本
- 生成最終bindings代碼
具體的實現邏輯就看看各個腳本源碼，這裏就不多說了。另外，對於腳本的註冊和執行那塊可以看看bindings下的ScriptController.cpp，當然，如何想看V8/JSCore中是如何調用對照表中的代碼，就需要再看看V8/JSCore本身的源碼，V8就看execution.cc，JSCore就看JITCode.h。
綜上所述，WebKit利用IDL和Bindings把自己從JS語言本身中脫離，讓自己既可以不需瞭解JS語言，又能實現JS API背後的邏輯，妙哉！